PCI DSS準拠から学ぶサステナブルなAWSクラウドネイティブの運用 / Sustainable PCIDSS operation on AWS

Transcript

1. PCI DSS 準拠から学ぶサステナブルな
   AWS クラウドネイティブの運用
   2022-10-08
   株式会社野村総合研究所 新井雅也
   

   View Slide

2. 新井 雅也
   M a s a y a A R A I
   msy78
   金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当。
   UI/UXデザインやスマホApp、バックエンドAPIなど、フルスタック領域な守備範囲を持ちつつ、
   クラウドを活用した全体のアーキテクチャ設計・開発が得意。
   好きな技術・サービスは、ECS、Fargate、App Runner、Kubernetes、Golang、Pulumi
   テックリード / インフラチームリーダー
   

   View Slide

3. 本日のゴール
   uPCI DSSに準拠したプロダクト事例から、
   クラウドネイティブ構成におけるセキュリティを高める設計事例を共有
   u一定の開発スピードを維持しつつも、
   持続的なコンプライアンス準拠が可能な運用事例をご紹介
   

   View Slide

4. ⚠ おことわり ⚠
   PCI DSS準拠に関する妥当性は、提供するサービス、
   採用するテクノロジーやアーキテクチャ、
   実際に監査を実施する評価機関(QSA)の判断にも依存します。
   本発表の目的は情報提供のみであり、
   PCI DSS準拠等の確実性を保証するものではありません。
   

   View Slide

5. プロダクト事例のご紹介：次世代クレジットカードサービス Nudge
   

   View Slide

6. アプリで簡単申込み
   氏名・生年月日・住所+本人確認書類1点で申込
   アプリベースで管理も手軽に
   決済金額はリアルタイムでアプリに通知・反映
   返済は自分のタイミングに合わせて
   自分に合った金額を、自由なタイミングで返済可能
   利便性の高い少額VISAクレジットカード
   上限金額10万円も、返済すれば即時に利用枠は復活
   利用者にとって安心で便利なクレジットカード
   

   View Slide

7. ユーザーに使う楽しみを：「好き」に貢献できるカード
   ユーザー（ファン）が普段通りクレジットカード支払いをするだけで、
   「好き」なスポーツチームやアーティスト等に貢献でき、お返しとして”特典”をもらえる仕組み
   ファンの方々
   （ユーザー様）
   還元（応援）
   通常のクレカのポイント相当分
   特典
   スポーツチーム・アスリート
   アーティスト etc
   店舗・EC等
   クレカ決済
   日常のお買い物をナッジカードで
   クレジットカード
   手数料
   

   View Slide

8. 1枚からでも発行可能な「次世代型提携カード」
   1枚からでも発行可能なため、より手軽に、
   様々な単位での提携カード発行が可能
   数万枚の最小ロットにコミットして
   初めて発行が可能
   大規模な顧客基盤を持つ
   事業者（小売・航空）
   少人数でも「狭く深い」
   ファンを抱える人物・事業者
   これまでの提携カード 次世代型提携カード
   

   View Slide

9. 01. プロジェクトの背景とお客様の特徴
   ユーザー クレジットカード
   スマホアプリ
   お店
   (加盟店)
   外部接続システム群
   (ペイメント機能等)
   サービス
   プラットフォーム
   コンビニ
   NRIはNudgeと併走しながらAWSサービスプラットフォームの開発・運用
   AWS
   

   View Slide

10. スマホアプリ
    外部接続システム
    (返済機能)
    サービスプラットフォーム
    管理者Web
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    スマホアプリ用
    フロントAPI
    管理者Web用
    フロントAPI
    外接システム用
    フロントAPI
    マイクロサービス別
    各API
    腐敗防止層
    外接向けAPI
    カード
    返済
    申込
    通知
    指定信用情報機関
    (CIC)
    バッチ連携
    決済
    会員
    管理者
    外部接続システム
    (金融機関)
    データ
    ベース
    ナッジにおけるAWSサービスプラットフォームの概要
    バックエンド機能はマイクロサービスをベースとしたAPI群で構成。
    コンテンツ
    

    View Slide

11. カードビジネスを成立させるために必要なPCI DSS準拠
    

    View Slide

12. クレジットカード
    ユーザー
    スマホアプリ
    お店
    (加盟店)
    外部接続システム群
    (ペイメント機能等)
    サービス
    プラットフォーム
    コンビニ
    PCI DSS
    準拠
    コンプライアンスに準拠した
    開発が必須
    ナッジがクレジットカードに関するビジネスを成立させるためには
    PCIDSSの準拠が必須
    AWS
    

    View Slide

13. サービス
    プラットフォーム
    AWS
    クレジットカードに関する情報を安全に取り扱うために
    策定された国際的なセキュリティ基準
    PCI DSS
    準拠
    

    View Slide

14. View Slide

15. (1)カード番号 (2)カード会員名 (3)有効期限 (4)サービスコード
    ※磁気ストライプ情報の読み取り方法と制限事項
    (5)磁気ストライプデータ
    (6)PIN/PINブロック
    (7)セキュリティコード
    カード会員データ
    機密認証データ
    カード会員データもしくは機密認証データを
    「処理」「通過」「保持」する事業体のシステムはPCI DSS準拠が必須
    

    View Slide

16. カード発行主体（イシュアー）として、
    PCI DSS準拠はビジネスを実現する上での「当然の責務」
    

    View Slide

17. クレジットカード番号等取扱業者は、経済産業省令で定める基準に従い、その取り扱うクレジット
    カード番号等の漏えい、滅失又は毀損の防止その他のクレジットカード番号等の適切な管理のために必
    要な措置を講じなければならない。
    割賦販売法 第三十五条の十六より
    カード発行主体（イシュアー）として、
    PCI DSS準拠はビジネスを実現する上での「当然の責務」
    万一、セキュリティ保護のための社内体制整備や措置が不十分な包括信用購入あっせん業者が存在し
    た場合、速やかに業務を 停止させた上で、措置の是正や早急の体制整備（体制整備の後、業務を再開
    させる）が必要として、業務停止命令を導入。
    割賦販売法の令和２年改正後の 主な動向と課題
    

    View Slide

18. サービス
    プラットフォーム
    AWS
    PCI DSS
    準拠
    

    View Slide

19. サービス
    プラットフォーム
    AWS
    PCI DSS
    準拠
    網羅的な
    セキュリティ設計と実装
    継続的な準拠
    ビジネスアジリティとのバランスを前提として
    PCI DSSに準拠するために考慮すべきこと
    

    View Slide

20. PCI DSS準拠に必要なセキュリティ設計と構築
    

    View Slide

21. サービス
    プラットフォーム
    AWS
    PCI DSS
    準拠
    網羅的な
    セキュリティ設計と実装
    継続的な準拠
    ビジネスアジリティとのバランスを前提として
    PCI DSSに準拠するために考慮すべきこと
    こちら
    から
    再掲
    

    View Slide

22. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    

    View Slide

23. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    1.カード会員データを保護するために、ファイアウォールをインストールして維持する
    2.システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
    3.保存されるカード会員データを保護する
    4.オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
    5.マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する
    6.安全性の高いシステムとアプリケーションを開発し、保守する
    7.カード会員データへのアクセスを、業務上必要な範囲内に制限する
    8.システムコンポーネントへのアクセスを識別・認証する
    9.カード会員データへの物理アクセスを制限する
    10.ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
    11.セキュリティシステムおよびプロセスを定期的にテストする
    12.すべての担当者の情報セキュリティに対応するポリシーを整備する
    (56項目)
    (38項目)
    (42項目)
    (78項目)
    (70項目)
    (47項目)
    

    View Slide

24. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    セキュリティ設計に
    落としていく必要あり
    

    View Slide

25. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    

    View Slide

26. スマホアプリ
    外部接続システム
    (返済機能)
    サービスプラットフォーム
    管理者Web
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    スマホアプリ用
    フロントAPI
    管理者Web用
    フロントAPI
    外接システム用
    フロントAPI
    マイクロサービス別
    各API
    腐敗防止層
    外接向けAPI
    カード
    返済
    申込
    通知
    指定信用情報機関
    (CIC)
    バッチ連携
    決済
    会員
    管理者
    外部接続システム
    (金融機関)
    データ
    ベース
    ナッジにおけるAWSサービスプラットフォームの概要
    バックエンド機能はマイクロサービスをベースとしたAPI群で構成。
    コンテンツ
    

    View Slide

27. スマホアプリ
    外部接続システム
    (返済機能)
    サービスプラットフォーム
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    API
    ALB
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon Aurora
    Amazon ECS
    バッチ用S3
    バケット
    バッチ用
    AWS Step
    Functions
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    会員系API
    決済系API
    管理者API
    コンテンツ用
    S3バケット
    Amazon
    CloudFront
    ナッジにおけるAWSサービスプラットフォームの概要
    バックエンド機能はマイクロサービスをベースとしたAPI群で構成。
    

    View Slide

28. スマホアプリ
    外部接続システム
    (返済機能)
    サービスプラットフォーム
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    API
    ALB
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon Aurora
    Amazon ECS
    バッチ用S3
    バケット
    バッチ用
    AWS Step
    Functions
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    会員系API
    決済系API
    管理者API
    Amazon
    CloudFront
    機密認証データが
    通過・保持
    (PCI DSS規制対象)
    コンテンツ用
    S3バケット
    保護すべき対象を明確にし、PCI DSSの準拠範囲を確定させる
    （スコーピングおよびセグメンテーション）
    

    View Slide

29. 1.1 以下を含むファイアウォールとルーターの構成基準を確立し、実施する:
    1.1.3 システムとネットワーク内でのカード会員データのフローを示す最新図
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「安全なネットワークの構築維持」に関するPCI DSS要件 (要件1.1)
    

    View Slide

30. 保護すべき情報が処理・通過・保持する処理を
    可視化することでセキュリティ保護可能な対象が明確になる
    

    View Slide

31. 1.3 インターネットとカード会員データ環境内のすべてのシステムコンポーネント間の、
    直接的なパブリックアクセスを禁止する。
    1.3.1 DMZ を実装し、承認された公開サービス、プロトコル、ポートを提供する
    システムコンポーネントのみへの着信トラフィックに制限する。
    1.3.2 着信インターネットトラフィックを DMZ 内の IP アドレスに制限する。
    1.3.4 カード会員データ環境からインターネットへの未承認の発信トラフィックを禁止する。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「安全なネットワークの構築維持」に関するPCI DSS要件 (要件1.3)
    

    View Slide

32. カード発行主体（イシュアー）として、
    PCI DSS準拠はビジネスを実現する上での「当然の責務」
    

    View Slide

33. セキュリティグループごとにインバウンドと
    アウトバウンドを明確にする
    DMZの実装。
    HTTPS/443のみ許可
    ・VPCリンクで特定の
    NLBのみアクセス可能
    ・NLB元のENI IPアドレス
    範囲からのアクセス許可
    ・発信はVPC内のみ
    ・VPC内からの
    アクセス許可
    ・発信はカード連携のみ
    ・ VPC内からの
    アクセス許可
    ・発信は外部連携のみ
    ・カード管理用ALBの
    アクセス許可
    ・発信はVPC内のみ
    ・外部連携用ALBの
    アクセス許可
    ・発信はVPC内のみ
    ・各種マイクロサービスからの
    アクセス許可
    ・発信は禁止
    

    View Slide

34. 2.2 すべてのシステムコンポーネントについて、構成基準を作成する。この基準は、すべての既知のセ
    キュリティ脆弱性をカバーし、また業界で認知されたシステム強化基準と一致している必要がある。
    業界で認知されたシステム強化基準のソースには以下が含まれる（これらに限定されない）。
    - Center for Internet Security（CIS）
    - 国際標準化機構（ISO）
    - SysAdmin Audit Network Security（SANS）Institute
    - 米国国立標準技術研究所（NIST）
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「安全なネットワークの構築維持」に関するPCI DSS要件 (要件2.2)
    

    View Slide

35. 技術スタックのレイヤごとに、
    システム強化基準を満たしていることを保証する必要がある
    セキュアコーディングの
    スコープなので割愛
    

    View Slide

36. 技術スタックのレイヤごとに、
    システム強化基準を満たしていることを保証する必要がある
    セキュアコーディングの
    スコープなので割愛
    

    View Slide

37. AWSコンポーネントに関しては、
    AWS Security Hubを活用することで、CIS準拠状態を集約して管理可能
    AWS Foundational Security Best Practices v1.0.0
    CIS AWS Foundational Benchmark v1.2.0
    PCI DSS v3.2.1
    ※本発表時点において、Security HubはCIS の Amazon Web Services Foundations
    Benchmark version 1.4.0に未対応であるため、差分の確認は必要。
    ※一部の準拠項目に関する検証項目をサポート。
    本発表時点において、PCI DSS 最新バージョンである v.4.0.0には未対応。
    

    View Slide

38. AWSコンポーネントに関しては、
    AWS Security Hubを活用することで、CIS準拠状態を集約して管理可能
    

    View Slide

39. 技術スタックのレイヤごとに、
    システム強化基準を満たしていることを保証する必要がある
    セキュアコーディングの
    スコープなので割愛
    

    View Slide

40. コンテナレイヤはDockleを活用して、開発段階から自然なCIS準拠を目指す
    引用：https://github.com/goodwithtech/dockle
    ※CIS Benchmarkに全て対応しているわけではないので
    サポートの位置付けとして活用
    

    View Slide

41. コンテナレイヤはDockleを活用して、開発段階から自然なCIS準拠を目指す
    GitHub
    CodePipeline
    CodeBuild CodeDeploy
    ECR
    ECS
    CI/CD時チェック
    開発時における早期発見が狙い（シフトレフト）
    デプロイ
    イメージ
    取得
    

    View Slide

42. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    

    View Slide

43. 4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、
    以下のような、強力な暗号化とセキュリティプロトコルを使用して保護する。
    ・ 信頼できる鍵と証明書のみを受け入れる
    ・ 使用されているプロトコルが、安全なバージョンまたは構成のみをサポートしている
    ・ 暗号化の強度が使用中の暗号化方式に適している
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「カード会員データの保護」に関するPCI DSS要件 (要件4.1)
    

    View Slide

44. スマホアプリ
    外部接続システム
    (返済機能)
    サービスプラットフォーム
    管理者Web
    マイクロサービス別
    各API
    Amazon
    API Gateway
    NLB
    API
    NLB
    API
    API
    ALB
    カード管理API
    返済系API
    申込系API
    通知系API
    外接連携API
    Amazon Aurora
    Amazon ECS
    バッチ用S3
    バケット
    バッチ用
    AWS Step
    Functions
    IAMロール IAMロール
    Amazon
    API Gateway
    指定信用情報機関
    (CIC)
    外部接続システム
    (eKYC機能)
    外部接続システム
    (ペイメント関連)
    外部接続システム
    (カード印刷関連)
    外部接続システム
    (金融機関)
    会員系API
    決済系API
    管理者API
    Amazon
    CloudFront
    機密認証データが
    通過・保持
    (PCI DSS規制対象)
    コンテンツ用
    S3バケット
    「カード会員データの保護」に関するPCI DSS要件 (要件4.1)
    

    View Slide

45. 「カード会員データの保護」に関するPCI DSS要件 (要件4.1)
    

    View Slide

46. HTTPS通信では、TLS のバージョンやサポートされるCipher Suiteにも注意を払う
    API Gatewayのセキュリティポリシー例
    TLS-1-2のほうが強度が高いため採用
    ・CloudFrontやALBに関しても適切な
    セキュリティポリシーを選択する
    ・セキュリティポリシーは不定期に
    更新されるため、定期的に見直す
    ・システム間接続のケースでは、
    対向側として利用可能なCipher Suiteに
    制約がある可能性も考慮する
    

    View Slide

47. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    

    View Slide

48. 6.1 セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、新たに
    発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を割り当てるプロ
    セスを確立する。
    6.2 すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインス
    トールされ、既知の脆弱性から保護されている。
    重要なセキュリティパッチは、リリース後 1 カ月以内にインストールする。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「カード会員データの保護」に関するPCI DSS要件 (要件6.1/6.2)
    

    View Slide

49. 脆弱性に関する情報は、技術スタックのレイヤごとに
    適切な情報源を参照して対処する
    AWSサービス
    （マネージドサービス）
    ミドルウェア
    コンテナ
    （OSパッケージ）
    アプリケーション
    （ライブラリ）
    

    View Slide

50. AWSのサービス自体に関する脆弱性情報は、
    AWS Security Bulletinsの掲載情報を活用
    Ref. https://aws.amazon.com/security/security-bulletins/
    AWSサービス
    （マネージドサービス）
    ミドルウェア
    コンテナ
    （OSパッケージ）
    アプリケーション
    （ライブラリ）
    RSSフィード
    

    View Slide

51. ミドルウェアは広範囲に及ぶため、JPCERT/CC(JVN)等から
    該当のソフトウェアに関する情報をトリアージ
    AWSサービス
    （マネージドサービス）
    ミドルウェア
    コンテナ
    （OSパッケージ）
    アプリケーション
    （ライブラリ）
    ※「https://www.jpcert.or.jp/about/06_3.html」より図1を引用
    API等により
    取得可能
    

    View Slide

52. コンテナおよびアプリケーションの脆弱性検出はTrivyを活用
    AWSサービス
    （マネージドサービス）
    ミドルウェア
    コンテナ
    （OSパッケージ）
    アプリケーション
    （ライブラリ）
    コンテナスキャンとして非常に有用なOSS
    例）英国政府デジタルサービス
    GitLabイメージスキャナ
    Red Hat認定スキャナ
    

    View Slide

53. ナッジでは、CI/CD時におけるスキャンと日次スキャンの
    ハイブリッド構成で脆弱性の早期検出に努めている
    AWSサービス
    （マネージドサービス）
    ミドルウェア
    コンテナ
    （OSパッケージ）
    アプリケーション
    （ライブラリ）
    GitHub
    CodePipeline
    CodeBuild CodeDeploy
    ECR
    ECS
    CI/CD時スキャン
    開発時における脆弱性の早期発見が狙い（シフトレフト）
    デプロイ
    イメージ
    取得
    

    View Slide

54. ナッジでは、CI/CD時におけるスキャンと日次スキャンの
    ハイブリッド構成で脆弱性の早期検出に努めている
    AWSサービス
    （マネージドサービス）
    ミドルウェア
    コンテナ
    （OSパッケージ）
    アプリケーション
    （ライブラリ）
    日次スキャン
    脆弱性検知の取りこぼし防止が狙い
    EventBridge
    ECSタスク
    Security Hub
    Slack
    ※2021-11にリリースされたAmazon Inspector統合によるECR拡張イメージスキャンも有効
    ECR
    イメージ
    取得
    日次で起動
    登録
    通知
    

    View Slide

55. 6.4 システムコンポーネントへのすべての変更において、変更管理のプロセスおよび手順に従う。
    これらのプロセスには、以下を含める必要がある。
    6.4.1 開発/テスト環境を本番環境から分離し、分離を実施するためのアクセス制御を行う。
    6.4.2 開発/テスト環境と本番環境での責務の分離
    6.4.3 テストまたは開発に本番環境データ（実際の PAN）を使用しない
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「カード会員データの保護」に関するPCI DSS要件 (要件6.4)
    

    View Slide

56. AWSアカウント(共通)
    VPC (開発環境)
    VPC (ステージング環境)
    VPC (本番環境)
    AWSアカウント(開発環境)
    VPC
    AWSアカウント(ステージング環境)
    VPC
    AWSアカウント(本番環境)
    VPC
    パターン1： VPCによる分離 パターン2： AWSアカウントによる分離
    IAM
    IAM
    IAM
    IAM
    権限周りの設定が
    煩雑になりがち
    環境間で設定内容は
    統一しつつ、
    リソースの分離が容易
    

    View Slide

57. AWS Well-Architected フレームワークのセキュリティ柱においても
    マルチアカウントによる環境分離を推奨している
    アカウントを使用してワークロードを分ける:
    開発環境およびテスト環境から本番環境を分離する場合、または外部コンプライアンス要件 (PCI-DSS
    や HIPAA など) で定義されている機密レベルの異なるデータを処理するワークロードとそうでないワー
    クロードとの間に強力な論理的境界を設ける場合は、アカウントレベルの分離を強くお勧めします。
    「AWS Well-Architectedフレームワーク – セキュリティの柱 – AWSアカウントの管理と分離」より一部引用
    (https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)
    

    View Slide

58. 開発/ステージング/本番環境の分離はAWSアカウント単位で実施
    AWSアカウント(共通)
    VPC (開発環境)
    VPC (ステージング環境)
    VPC (本番環境)
    AWSアカウント(開発環境)
    VPC
    AWSアカウント(ステージング環境)
    VPC
    AWSアカウント(本番環境)
    VPC
    パターン1： VPCによる分離 パターン2： AWSアカウントによる分離
    IAM
    IAM
    IAM
    IAM
    権限周りの設定が
    煩雑になりがち
    環境間で設定内容は
    統一しつつ、
    リソースの分離が容易
    

    View Slide

59. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    AWS サービス
    プラットフォーム
    AWS サービス
    プラットフォーム
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    

    View Slide

60. 8.1 ポリシーと手順を定義して実装することで、次のように、すべてのシステムコンポーネントで、
    非消費者ユーザと管理者のための適切なユーザ識別管理が行われるようにする。
    8.1.1システムコンポーネントまたはカード会員データへのアクセスを許可する前に、
    すべてのユーザに一意のIDを割り当てる。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「強力なアクセス制御手法の導入」に関するPCI DSS要件 (要件8.1)
    

    View Slide

61. AWSアカウント(開発環境)
    AWSアカウント(ステージング環境)
    AWSアカウント(本番環境)
    IAMユーザ
    IAMユーザ
    IAMユーザ
    Aさん
    （システム担当者）
    各環境用のAWSアカウント上に一意のIAMユーザを作成すると
    管理の観点から煩雑になりがち
    ・管理自体が煩雑 (人数 x 環境 x 権限?)
    ・担当者が増減するたびに全環境の変更が発生
    

    View Slide

62. AWSアカウント(開発環境)
    AWSアカウント(ステージング環境)
    AWSアカウント(本番環境)
    IAMユーザ管理用のAWSアカウントを準備し、スイッチロール経由で
    各環境を利用することで要件に準拠しつつ管理しやすい形に
    AWSアカウント
    (IAMユーザ集約) IAMロール
    (システム担当者)
    Aさん
    （システム担当者）
    IAMユーザ
    (Aさん用)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    スイッチ
    ロール
    ログイン
    職能に応じた
    IAMロールを用意
    ユーザ管理は
    専用アカウントで
    集中管理
    

    View Slide

63. AWSアカウント(開発環境)
    AWSアカウント(ステージング環境)
    AWSアカウント(本番環境)
    IAMユーザ管理用のAWSアカウントを準備し、スイッチロール経由で
    各環境を利用することで要件に準拠しつつ管理しやすい形に
    AWSアカウント
    (IAMユーザ集約) IAMロール
    (システム担当者)
    Aさん
    （システム担当者）
    IAMユーザ
    (Aさん用)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    スイッチ
    ロール
    ログイン
    職能に応じた
    IAMロールを用意
    開発・ステージング環境向けIAM操作時に
    本番のIAM操作に関する統制制約が発生
    

    View Slide

64. AWSアカウント(開発環境)
    AWSアカウント(ステージング環境)
    AWSアカウント(本番環境)
    AWSアカウント
    (IAMユーザ集約) IAMロール
    (システム担当者)
    Aさん
    （システム担当者）
    IAMユーザ
    (Aさん用)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    スイッチ
    ロール
    ログイン
    AWSアカウント
    (IAMユーザ/本番)
    IAMユーザ
    (Aさん用)
    スイッチ
    ロール
    ログイン
    本番環境にアクセスに関して、
    本番向けIAMユーザ集約用のAWSアカウントからスイッチ
    統制面を考慮して、
    本番アクセスが必要な
    IAMユーザのみ管理
    承認
    プロセス
    あり
    

    View Slide

65. 一部の基本的なPCI DSS要件が満たされないため、
    AWS Identity Center (旧 AWS SSO)の採用は見送り
    8.2.5 これまでに使用した最後の 4 つのパスワード/パスフレーズのいずれかと同じである新しいパス
    ワード/パスフレーズを許可しない。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    The last three passwords cannot be reused.
    「 AWS IAM Identity Center – Password requirements when managing identities in IAM Identity Center」より一部引用
    https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html
    

    View Slide

66. 一部の基本的なPCI DSS要件が満たされないため、
    AWS Identity Center (旧 AWS SSO)の採用は見送り
    8.2.4 ユーザパスワード/パスフレーズは、少なくとも 1 回は 90 日ごと変更する。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    AWS Identity Centerに関して、パスワードの有効期限を有効にする機能はない。
    AWSサポート回答より
    最初はAWS内で完結するスイッチロール、規模が拡大したらIdP連携を検討
    

    View Slide

67. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    AWS サービス
    プラットフォーム
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    e.g. IAMロールによる職務分離
    

    View Slide

68. 10.1 システムコンポーネントへのすべてのアクセスを各ユーザにリンクする監査証跡を確立する。
    10.2 次のイベントを再現するために、すべてのシステムコンポーネントの自動監査証跡を実装する。
    10.2.1 カード会員データへのすべての個人アクセス
    10.2.2 ルート権限または管理権限を持つ個人によって行われたすべてのアクション
    10.2.3 すべての監査証跡へのアクセス
    10.2.4 無効な論理アクセス試行
    10.2.5 識別と認証メカニズムの使用および変更、およびルートまたは管理者権限をもつ
    アカウントの変更、追加、削除のすべて
    10.2.6 監査ログの初期化、停止、一時停止
    10.2.7 システムレベルオブジェクトの作成および削除
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「ネットワークの定期的な監視およびテスト」に関するPCI DSS要件 (要件10.1/10.2)
    

    View Slide

69. 保護すべき情報が処理・通過・保持する箇所は
    個別に可視化することでセキュリティ保護可能な対象が明確になる
    Amazon S3
    

    View Slide

70. PCI DSSでスコーピングした領域の各種サービスへの
    アクセスログを集中的に管理し、監査証跡として保存
    Amazon S3
    1. WAFのログ 2. API Gatewayのログ
    3. Auroraのログ
    4. ALBのログ
    5. ECSタスクの
    アプリケーションログ
    5. ECSタスク(Bastion)の
    操作ログ
    7. AWSの監査ログ
    (CloudTrail)
    

    View Slide

71. AWS WAF Amazon S3
    S3バケット名は「aws-waf-logs-」の
    プレフィックスで始まる必要がある
    ※AWS WAFのログは2021-11-15以前においては、Firehose経由のみであった。
    現状、NudgeはFirehoseを経由する構成となっており、今後改善予定。
    AWS WAFのログはS3バケットへの直接出力が可能
    S3以外に、CloudWatchもしくはKinesis Data Firehoseに対しても出力可能
    ログ
    

    View Slide

72. Amazon API GatewayのログはS3バケットへの直接出力が不可
    CloudWatchもしくはKinesis Data Firehoseに一度出力させた後にS3への転送が必要
    Amazon API
    Gateway
    Amazon S3
    ストリーム名は「amazon-apigateway-」の
    プレフィックスで始まる必要がある
    Amazon Kinesis
    Data Firehose
    CloudWatch Logs Insights等によるアドホック分析用途と比較し、
    S3へのログ保存が主の目的であれば、Firehose利用によるS3転送がシンプル
    ログ
    

    View Slide

73. Amazon AuroraのログはS3バケットへの直接出力が不可
    Amazon
    Aurora
    Amazon S3
    ログが出力可能なサービスはAmazon CloudWatchのみ
    Amazon Kinesis
    Data Firehose
    Amazon CloudWatch
    サブスクリプションフィルターにて
    Firehoseに連携
    ログ
    

    View Slide

74. ALBのログはS3バケットへの直接出力が可能
    Application
    Load Balancer
    Amazon S3
    ログ
    

    View Slide

75. ECS/Fargateタスクのアプリケーションログは
    S3バケットへの直接出力が不可
    ECSタスク
    Amazon S3
    App Firelens
    Firelens(fluentbit)を経由させることで、S3バケットにログを直接転送可能
    ログ
    

    View Slide

76. Bastion(ECSタスク)の操作ログはSSMセッションマネージャの
    ロギング機能にて、S3バケットへの直接出力が可能
    ECSタスク
    Amazon S3
    Bastion(踏み台) ログ
    

    View Slide

77. AWS CloudTrail Amazon S3
    AWS CloudTrailのログはS3バケットへの直接出力が可能
    ログ
    

    View Slide

78. 各種AWSサービスごとのログ方式を押さえておく
    AWS WAF ○
    S3バケット名の制約あり
    Firehose, CloudWatch Logsへも出力可能
    Amazon API
    Gateway × Firehose配信ストリーム名の制約あり
    Amazon Aurora ×
    サブスクリプションフィルター
    との連携が必要
    ALB ○
    ECS/Fargate
    アプリケーション
    × fluentbit経由で出力
    ECS/Fargate
    Bastion
    ○ セッションマネージャの機能を利用
    CloudWatch Logsへも出力可能
    CloudTrail ○ CloudWatch Logsへも出力可能
    サービス名
    S3への
    ログ直接出力
    AWSサービス構成例 備考
    

    View Slide

79. 10.5 変更できないよう監査証跡をセキュリティで保護する。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「ネットワークの定期的な監視およびテスト」に関するPCI DSS要件 (要件10.5)
    

    View Slide

80. Standard
    S3(監査ログアーカイブバケット)
    ログの変更禁止にはS3のオブジェクトロックを活用する
    オブジェクトロックを有効化
    （コンプライアンスモード）
    rootユーザ操作を含む
    如何なる変更・削除が不可
    

    View Slide

81. 10.7 監査証跡の履歴を少なくとも 1 年間保持する。少なくとも 3 カ月はすぐに分析できる
    状態にしておく（オンライン、アーカイブ、バックアップから復元可能など）。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    「ネットワークの定期的な監視およびテスト」に関するPCI DSS要件 (要件10.7)
    

    View Slide

82. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用
    Standard
    S3(監査ログアーカイブバケット)
    

    View Slide

83. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用
    Standard Standard
    IA
    S3(監査ログアーカイブバケット)
    Glacier
    Flexible Retrieval
    30日後 10年後
    削除
    90日後
    

    View Slide

84. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用
    Standard Standard
    IA
    S3(監査ログアーカイブバケット)
    Glacier
    Flexible Retrieval
    30日後 90日後 10年後
    削除
    少なくとも、３ヶ月(90日)は
    ログをすぐに分析可能
    その他法令(e.g. 民法, 反収法)に
    関する保持要件を加味して削除
    

    View Slide

85. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    e.g. IAMロールによる職務分離
    e.g. 監査証跡の取得と変更統制、ログアーカイブ
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    

    View Slide

86. コンプライアンス準拠と共存するためのサステナブルな運用戦略
    

    View Slide

87. サービス
    プラットフォーム
    AWS
    PCI DSS
    準拠
    網羅的な
    セキュリティ設計と実装
    継続的な準拠
    ビジネスアジリティとのバランスを前提として
    PCI DSSに準拠するために考慮すべきこと
    次は
    こちら
    

    View Slide

88. PCI DSSは初回に準拠して「はい終了」ではなく、
    全ての項目に関する継続的な準拠の証明が必須。
    PCI DSS要件の適用範囲：
    少なくとも年に一度、毎年の評価前に、評価対象の事業体はカード会員データの場所とフ
    ローをすべて特定し、（途中省略）PCI DSS の範囲の正確性を確認する必要があります。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    

    View Slide

89. PCI DSSは初回に準拠して「はい終了」ではなく、
    全ての項目に関する継続的な準拠の証明が必須。
    PCI DSS要件の適用範囲：
    少なくとも年に一度、毎年の評価前に、評価対象の事業体はカード会員データの場所とフ
    ローをすべて特定し、（途中省略）PCI DSS の範囲の正確性を確認する必要があります。
    「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
    自分たちの日常業務や求める開発スピードと照らし合わせて
    いかに持続可能な（サステナブルな）形で運用を醸成できるかがポイント
    クラウドネイティブアーキテクチャではクラウド側への責任委譲の恩恵をより受けられる
    

    View Slide

90. 安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    e.g. IAMロールによる職務分離
    e.g. 監査証跡の取得と変更統制、ログアーカイブ
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    再掲
    PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    

    View Slide

91. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    e.g. IAMロールによる職務分離
    e.g. 監査証跡の取得と変更統制、ログアーカイブ
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    想定外のNW変更が発
    生したらどう気づく？
    高頻度なリリース・
    障害対応においても
    効率的な
    承認プロセスは？
    再掲
    

    View Slide

92. 基本戦略として、ナッジではSlack中心のChatOpsを活用
    コミュニケーションの中心がSlackであり、
    日常的なオペレーションとの親和性が高い
    Slack
    Chatbot AWSリソース
    操作(送信)
    Slack
    Chatbot
    AWSリソース
    連携 操作・更新
    状態検知
    連携
    通知
    定期的かつ
    一時的な操作
    想定外の
    事象検知
    

    View Slide

93. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    e.g. IAMロールによる職務分離
    e.g. 監査証跡の取得と変更統制、ログアーカイブ
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    高頻度なリリース・
    障害対応においても
    効率的な
    承認プロセスは？
    再掲
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    想定外のNW変更が発
    生したらどう気づく？
    

    View Slide

94. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用
    VPC
    VPCの変更
    セキュリティグループの変更
    NACLの変更
    ゲートウェイリソースの変更
    ルートテーブルの変更
    ：
    

    View Slide

95. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用
    Security Hub
    CloudTrail CloudWatch
    Logs
    Chatbot Slack
    メトリクスフィルター作成が
    CIS Benchmark 1.2の
    一部準拠要件になっている
    VPC
    アラーム
    (イベント)
    SNS
    VPCの変更
    セキュリティグループの変更
    NACLの変更
    ゲートウェイリソースの変更
    ルートテーブルの変更
    ：
    CloudWatch
    メトリクス
    

    View Slide

96. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用
    Slack
    SRE担当者が参加している
    チャンネル全体に通知
    (info/error/criticalでレベル分け)
    リリース等の作業影響であれば
    その旨スタンプ＆コメント
    

    View Slide

97. PCI DSSは6つの目標と12の要件から構成され、
    イシュアーは331項目の方針検討と準拠が必要
    安全なネットワークの
    構築維持
    カード会員データの
    保護
    脆弱性管理プログラムの
    維持
    強力なアクセス制御手法
    の導入
    ネットワークの定期的な
    監視およびテスト
    情報セキュリティ
    ポリシーの維持
    e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
    e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
    e.g. 監査証跡の取得と変更統制、ログアーカイブ
    AWSに関する設計・構築ではなく、
    組織のセキュリティポリシーに関する項目であるため対象外
    再掲
    e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
    CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
    想定外のNW変更が発
    生したらどう気づく？
    e.g. IAMロールによる職務分離
    高頻度なリリース・
    障害対応においても
    効率的な
    承認プロセスは？
    

    View Slide

98. AWSアカウント(開発環境)
    AWSアカウント(ステージング環境)
    AWSアカウント
    (IAMユーザ集約) IAMロール
    (システム担当者)
    Aさん
    （システム担当者）
    IAMユーザ
    (Aさん用)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    スイッチ
    ロール
    ログイン
    ログイン
    統制面を考慮して、
    本番アクセスが必要な
    IAMユーザのみ管理
    再掲
    AWSアカウント(本番環境)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    AWSアカウント
    (IAMユーザ/本番)
    IAMユーザ
    (Aさん用)
    スイッチ
    ロール
    承認
    プロセス
    あり
    本番環境にアクセスに関して、
    本番向けIAMユーザ集約用のAWSアカウントからスイッチ
    

    View Slide

99. 本番環境にアクセスに関して、
    本番向けIAMユーザ集約用のAWSアカウントからスイッチ
    AWSアカウント(開発環境)
    AWSアカウント(ステージング環境)
    AWSアカウント
    (IAMユーザ集約) IAMロール
    (システム担当者)
    Aさん
    （システム担当者）
    IAMユーザ
    (Aさん用)
    IAMロール
    (アプリ開発者)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    スイッチ
    ロール
    ログイン
    ログイン
    統制面を考慮して、
    本番アクセスが必要な
    IAMユーザのみ管理
    再掲
    AWSアカウント(本番環境)
    IAMロール
    (システム担当者)
    IAMロール
    (アプリ開発者)
    AWSアカウント
    (IAMユーザ/本番)
    IAMユーザ
    (Aさん用)
    スイッチ
    ロール
    承認
    プロセス
    あり
    

    View Slide

100. Slack Chatbot Lambda
     IAM グループ
     (システム担当者用)
     IAMグループ
     (アプリ開発者用)
     IAMユーザ
     (Aさん用)
     IAM
     AWSアカウント
     (IAMユーザ/本番)
     AWSアカウント(本番環境)
     IAMロール
     (システム担当者)
     IAMロール
     (アプリ開発者)
     スイッチロール
     スイッチロール
     承認者がSlackのワークフローを実行することで、
     一時的にアクセスの有効化・無効化を制御
     承認者
     通常時は
     スイッチロール不可
     

     View Slide

101. Chatbot Lambda
     IAM グループ
     (システム担当者用)
     IAMグループ
     (アプリ開発者用)
     IAMユーザ
     (Aさん用)
     IAM
     AWSアカウント
     (IAMユーザ/本番)
     AWSアカウント(本番環境)
     IAMロール
     (システム担当者)
     IAMロール
     (アプリ開発者)
     スイッチロール
     スイッチロール
     Slack
     承認者
     承認者はアクセスが必要な
     ユーザーとIAMロール(権限)
     を指定して実行
     承認者がSlackのワークフローを実行することで、
     一時的にアクセスの有効化・無効化を制御
     

     View Slide

102. Slack Chatbot Lambda
     IAM グループ
     (システム担当者用)
     IAMグループ
     (アプリ開発者用)
     IAMユーザ
     (Aさん用)
     IAM
     AWSアカウント
     (IAMユーザ/本番)
     AWSアカウント(本番環境)
     IAMロール
     (システム担当者)
     IAMロール
     (アプリ開発者)
     スイッチロール
     スイッチロール
     承認者
     スイッチ可能なIAMグループに
     対象ユーザが追加
     承認者がSlackのワークフローを実行することで、
     一時的にアクセスの有効化・無効化を制御
     作業完了後も同じ流れ
     

     View Slide

103. PCI DSSは6つの目標と12の要件から構成され、
     イシュアーは331項目の方針検討と準拠が必要
     安全なネットワークの
     構築維持
     カード会員データの
     保護
     脆弱性管理プログラムの
     維持
     強力なアクセス制御手法
     の導入
     ネットワークの定期的な
     監視およびテスト
     情報セキュリティ
     ポリシーの維持
     e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
     e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
     e.g. 監査証跡の取得と変更統制、ログアーカイブ
     AWSに関する設計・構築ではなく、
     組織のセキュリティポリシーに関する項目であるため対象外
     再掲
     e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、
     CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
     想定外のNW変更が発
     生したらどう気づく？
     e.g. IAMロールによる職務分離
     高頻度なリリース・
     障害対応においても
     効率的な
     承認プロセスは？
     

     View Slide

104. サービス
     プラットフォーム
     AWS
     PCI DSS
     準拠
     網羅的な
     セキュリティ設計と実装
     継続的な準拠
     ビジネスアジリティとのバランスを前提として
     PCI DSSに準拠するために考慮すべきこと
     再掲
     

     View Slide

105. まとめ
     

     View Slide

106. まとめ
     uPCI DSSに準拠したプロダクト事例から、
     クラウドネイティブ構成におけるセキュリティを高める設計事例を共有
     u一定の開発スピードを維持しつつも、
     持続的なコンプライアンス準拠が可能な運用事例をご紹介
     

     View Slide

107. ご清聴いただき、ありがとうございました。
     

     View Slide