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

Transcript

1. PCI DSS 準拠から学ぶサステナブルな AWS クラウドネイティブの運用 2022-10-08 株式会社野村総合研究所 新井雅也
2. 新井 雅也 M a s a y a A R A I msy78 金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当。 UI/UXデザインやスマホApp、バックエンドAPIなど、フルスタック領域な守備範囲を持ちつつ、 クラウドを活用した全体のアーキテクチャ設計・開発が得意。 好きな技術・サービスは、ECS、Fargate、App Runner、Kubernetes、Golang、Pulumi テックリード / インフラチームリーダー
3. 本日のゴール uPCI DSSに準拠したプロダクト事例から、 クラウドネイティブ構成におけるセキュリティを高める設計事例を共有 u一定の開発スピードを維持しつつも、 持続的なコンプライアンス準拠が可能な運用事例をご紹介
4. ⚠ おことわり ⚠ PCI DSS準拠に関する妥当性は、提供するサービス、 採用するテクノロジーやアーキテクチャ、 実際に監査を実施する評価機関(QSA)の判断にも依存します。 本発表の目的は情報提供のみであり、 PCI DSS準拠等の確実性を保証するものではありません。
5. プロダクト事例のご紹介：次世代クレジットカードサービス Nudge
6. アプリで簡単申込み 氏名・生年月日・住所+本人確認書類1点で申込 アプリベースで管理も手軽に 決済金額はリアルタイムでアプリに通知・反映 返済は自分のタイミングに合わせて 自分に合った金額を、自由なタイミングで返済可能 利便性の高い少額VISAクレジットカード 上限金額10万円も、返済すれば即時に利用枠は復活 利用者にとって安心で便利なクレジットカード
7. ユーザーに使う楽しみを：「好き」に貢献できるカード ユーザー（ファン）が普段通りクレジットカード支払いをするだけで、 「好き」なスポーツチームやアーティスト等に貢献でき、お返しとして”特典”をもらえる仕組み ファンの方々 （ユーザー様） 還元（応援） 通常のクレカのポイント相当分 特典 スポーツチーム・アスリート アーティスト etc 店舗・EC等 クレカ決済 日常のお買い物をナッジカードで クレジットカード 手数料
8. 1枚からでも発行可能な「次世代型提携カード」 1枚からでも発行可能なため、より手軽に、 様々な単位での提携カード発行が可能 数万枚の最小ロットにコミットして 初めて発行が可能 大規模な顧客基盤を持つ 事業者（小売・航空） 少人数でも「狭く深い」 ファンを抱える人物・事業者 これまでの提携カード 次世代型提携カード
9. 01. プロジェクトの背景とお客様の特徴 ユーザー クレジットカード スマホアプリ お店 (加盟店) 外部接続システム群 (ペイメント機能等) サービス プラットフォーム コンビニ NRIはNudgeと併走しながらAWSサービスプラットフォームの開発・運用 AWS
10. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者Web 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム (カード印刷関連) スマホアプリ用 フロントAPI 管理者Web用 フロントAPI 外接システム用 フロントAPI マイクロサービス別 各API 腐敗防止層 外接向けAPI カード 返済 申込 通知 指定信用情報機関 (CIC) バッチ連携 決済 会員 管理者 外部接続システム (金融機関) データ ベース ナッジにおけるAWSサービスプラットフォームの概要 バックエンド機能はマイクロサービスをベースとしたAPI群で構成。 コンテンツ
11. カードビジネスを成立させるために必要なPCI DSS準拠
12. クレジットカード ユーザー スマホアプリ お店 (加盟店) 外部接続システム群 (ペイメント機能等) サービス プラットフォーム コンビニ PCI DSS 準拠 コンプライアンスに準拠した 開発が必須 ナッジがクレジットカードに関するビジネスを成立させるためには PCIDSSの準拠が必須 AWS
13. サービス プラットフォーム AWS クレジットカードに関する情報を安全に取り扱うために 策定された国際的なセキュリティ基準 PCI DSS 準拠
15. (1)カード番号 (2)カード会員名 (3)有効期限 (4)サービスコード ※磁気ストライプ情報の読み取り方法と制限事項 (5)磁気ストライプデータ (6)PIN/PINブロック (7)セキュリティコード カード会員データ 機密認証データ カード会員データもしくは機密認証データを 「処理」「通過」「保持」する事業体のシステムはPCI DSS準拠が必須
16. カード発行主体（イシュアー）として、 PCI DSS準拠はビジネスを実現する上での「当然の責務」
17. クレジットカード番号等取扱業者は、経済産業省令で定める基準に従い、その取り扱うクレジット カード番号等の漏えい、滅失又は毀損の防止その他のクレジットカード番号等の適切な管理のために必 要な措置を講じなければならない。 割賦販売法 第三十五条の十六より カード発行主体（イシュアー）として、 PCI DSS準拠はビジネスを実現する上での「当然の責務」 万一、セキュリティ保護のための社内体制整備や措置が不十分な包括信用購入あっせん業者が存在し た場合、速やかに業務を 停止させた上で、措置の是正や早急の体制整備（体制整備の後、業務を再開 させる）が必要として、業務停止命令を導入。 割賦販売法の令和２年改正後の 主な動向と課題
18. サービス プラットフォーム AWS PCI DSS 準拠
19. サービス プラットフォーム AWS PCI DSS 準拠 網羅的な セキュリティ設計と実装 継続的な準拠 ビジネスアジリティとのバランスを前提として PCI DSSに準拠するために考慮すべきこと
20. PCI DSS準拠に必要なセキュリティ設計と構築
21. サービス プラットフォーム AWS PCI DSS 準拠 網羅的な セキュリティ設計と実装 継続的な準拠 ビジネスアジリティとのバランスを前提として PCI DSSに準拠するために考慮すべきこと こちら から 再掲
22. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要
23. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 1.カード会員データを保護するために、ファイアウォールをインストールして維持する 2.システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない 3.保存されるカード会員データを保護する 4.オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する 5.マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する 6.安全性の高いシステムとアプリケーションを開発し、保守する 7.カード会員データへのアクセスを、業務上必要な範囲内に制限する 8.システムコンポーネントへのアクセスを識別・認証する 9.カード会員データへの物理アクセスを制限する 10.ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する 11.セキュリティシステムおよびプロセスを定期的にテストする 12.すべての担当者の情報セキュリティに対応するポリシーを整備する (56項目) (38項目) (42項目) (78項目) (70項目) (47項目)
24. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム セキュリティ設計に 落としていく必要あり
25. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム
26. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者Web 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム (カード印刷関連) スマホアプリ用 フロントAPI 管理者Web用 フロントAPI 外接システム用 フロントAPI マイクロサービス別 各API 腐敗防止層 外接向けAPI カード 返済 申込 通知 指定信用情報機関 (CIC) バッチ連携 決済 会員 管理者 外部接続システム (金融機関) データ ベース ナッジにおけるAWSサービスプラットフォームの概要 バックエンド機能はマイクロサービスをベースとしたAPI群で構成。 コンテンツ
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群で構成。
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の準拠範囲を確定させる （スコーピングおよびセグメンテーション）
29. 1.1 以下を含むファイアウォールとルーターの構成基準を確立し、実施する: 1.1.3 システムとネットワーク内でのカード会員データのフローを示す最新図 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「安全なネットワークの構築維持」に関するPCI DSS要件 (要件1.1)
30. 保護すべき情報が処理・通過・保持する処理を 可視化することでセキュリティ保護可能な対象が明確になる
31. 1.3 インターネットとカード会員データ環境内のすべてのシステムコンポーネント間の、 直接的なパブリックアクセスを禁止する。 1.3.1 DMZ を実装し、承認された公開サービス、プロトコル、ポートを提供する システムコンポーネントのみへの着信トラフィックに制限する。 1.3.2 着信インターネットトラフィックを DMZ 内の IP アドレスに制限する。 1.3.4 カード会員データ環境からインターネットへの未承認の発信トラフィックを禁止する。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「安全なネットワークの構築維持」に関するPCI DSS要件 (要件1.3)
32. カード発行主体（イシュアー）として、 PCI DSS準拠はビジネスを実現する上での「当然の責務」
33. セキュリティグループごとにインバウンドと アウトバウンドを明確にする DMZの実装。 HTTPS/443のみ許可 ・VPCリンクで特定の NLBのみアクセス可能 ・NLB元のENI IPアドレス 範囲からのアクセス許可 ・発信はVPC内のみ ・VPC内からの アクセス許可 ・発信はカード連携のみ ・ VPC内からの アクセス許可 ・発信は外部連携のみ ・カード管理用ALBの アクセス許可 ・発信はVPC内のみ ・外部連携用ALBの アクセス許可 ・発信はVPC内のみ ・各種マイクロサービスからの アクセス許可 ・発信は禁止
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)
35. 技術スタックのレイヤごとに、 システム強化基準を満たしていることを保証する必要がある セキュアコーディングの スコープなので割愛
36. 技術スタックのレイヤごとに、 システム強化基準を満たしていることを保証する必要がある セキュアコーディングの スコープなので割愛
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には未対応。
38. AWSコンポーネントに関しては、 AWS Security Hubを活用することで、CIS準拠状態を集約して管理可能
39. 技術スタックのレイヤごとに、 システム強化基準を満たしていることを保証する必要がある セキュアコーディングの スコープなので割愛
40. コンテナレイヤはDockleを活用して、開発段階から自然なCIS準拠を目指す 引用：https://github.com/goodwithtech/dockle ※CIS Benchmarkに全て対応しているわけではないので サポートの位置付けとして活用
41. コンテナレイヤはDockleを活用して、開発段階から自然なCIS準拠を目指す GitHub CodePipeline CodeBuild CodeDeploy ECR ECS CI/CD時チェック 開発時における早期発見が狙い（シフトレフト） デプロイ イメージ 取得
42. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
43. 4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、 以下のような、強力な暗号化とセキュリティプロトコルを使用して保護する。 ・ 信頼できる鍵と証明書のみを受け入れる ・ 使用されているプロトコルが、安全なバージョンまたは構成のみをサポートしている ・ 暗号化の強度が使用中の暗号化方式に適している 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「カード会員データの保護」に関するPCI DSS要件 (要件4.1)
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)
45. 「カード会員データの保護」に関するPCI DSS要件 (要件4.1)
46. HTTPS通信では、TLS のバージョンやサポートされるCipher Suiteにも注意を払う API Gatewayのセキュリティポリシー例 TLS-1-2のほうが強度が高いため採用 ・CloudFrontやALBに関しても適切な セキュリティポリシーを選択する ・セキュリティポリシーは不定期に 更新されるため、定期的に見直す ・システム間接続のケースでは、 対向側として利用可能なCipher Suiteに 制約がある可能性も考慮する
47. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
48. 6.1 セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、新たに 発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を割り当てるプロ セスを確立する。 6.2 すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインス トールされ、既知の脆弱性から保護されている。 重要なセキュリティパッチは、リリース後 1 カ月以内にインストールする。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「カード会員データの保護」に関するPCI DSS要件 (要件6.1/6.2)
49. 脆弱性に関する情報は、技術スタックのレイヤごとに 適切な情報源を参照して対処する AWSサービス （マネージドサービス） ミドルウェア コンテナ （OSパッケージ） アプリケーション （ライブラリ）
50. AWSのサービス自体に関する脆弱性情報は、 AWS Security Bulletinsの掲載情報を活用 Ref. https://aws.amazon.com/security/security-bulletins/ AWSサービス （マネージドサービス） ミドルウェア コンテナ （OSパッケージ） アプリケーション （ライブラリ） RSSフィード
51. ミドルウェアは広範囲に及ぶため、JPCERT/CC(JVN)等から 該当のソフトウェアに関する情報をトリアージ AWSサービス （マネージドサービス） ミドルウェア コンテナ （OSパッケージ） アプリケーション （ライブラリ） ※「https://www.jpcert.or.jp/about/06_3.html」より図1を引用 API等により 取得可能
52. コンテナおよびアプリケーションの脆弱性検出はTrivyを活用 AWSサービス （マネージドサービス） ミドルウェア コンテナ （OSパッケージ） アプリケーション （ライブラリ） コンテナスキャンとして非常に有用なOSS 例）英国政府デジタルサービス GitLabイメージスキャナ Red Hat認定スキャナ
53. ナッジでは、CI/CD時におけるスキャンと日次スキャンの ハイブリッド構成で脆弱性の早期検出に努めている AWSサービス （マネージドサービス） ミドルウェア コンテナ （OSパッケージ） アプリケーション （ライブラリ） GitHub CodePipeline CodeBuild CodeDeploy ECR ECS CI/CD時スキャン 開発時における脆弱性の早期発見が狙い（シフトレフト） デプロイ イメージ 取得
54. ナッジでは、CI/CD時におけるスキャンと日次スキャンの ハイブリッド構成で脆弱性の早期検出に努めている AWSサービス （マネージドサービス） ミドルウェア コンテナ （OSパッケージ） アプリケーション （ライブラリ） 日次スキャン 脆弱性検知の取りこぼし防止が狙い EventBridge ECSタスク Security Hub Slack ※2021-11にリリースされたAmazon Inspector統合によるECR拡張イメージスキャンも有効 ECR イメージ 取得 日次で起動 登録 通知
55. 6.4 システムコンポーネントへのすべての変更において、変更管理のプロセスおよび手順に従う。 これらのプロセスには、以下を含める必要がある。 6.4.1 開発/テスト環境を本番環境から分離し、分離を実施するためのアクセス制御を行う。 6.4.2 開発/テスト環境と本番環境での責務の分離 6.4.3 テストまたは開発に本番環境データ（実際の PAN）を使用しない 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「カード会員データの保護」に関するPCI DSS要件 (要件6.4)
56. AWSアカウント(共通) VPC (開発環境) VPC (ステージング環境) VPC (本番環境) AWSアカウント(開発環境) VPC AWSアカウント(ステージング環境) VPC AWSアカウント(本番環境) VPC パターン1： VPCによる分離 パターン2： AWSアカウントによる分離 IAM IAM IAM IAM 権限周りの設定が 煩雑になりがち 環境間で設定内容は 統一しつつ、 リソースの分離が容易
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)
58. 開発/ステージング/本番環境の分離はAWSアカウント単位で実施 AWSアカウント(共通) VPC (開発環境) VPC (ステージング環境) VPC (本番環境) AWSアカウント(開発環境) VPC AWSアカウント(ステージング環境) VPC AWSアカウント(本番環境) VPC パターン1： VPCによる分離 パターン2： AWSアカウントによる分離 IAM IAM IAM IAM 権限周りの設定が 煩雑になりがち 環境間で設定内容は 統一しつつ、 リソースの分離が容易
59. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
60. 8.1 ポリシーと手順を定義して実装することで、次のように、すべてのシステムコンポーネントで、 非消費者ユーザと管理者のための適切なユーザ識別管理が行われるようにする。 8.1.1システムコンポーネントまたはカード会員データへのアクセスを許可する前に、 すべてのユーザに一意のIDを割り当てる。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「強力なアクセス制御手法の導入」に関するPCI DSS要件 (要件8.1)
61. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント(本番環境) IAMユーザ IAMユーザ IAMユーザ Aさん （システム担当者） 各環境用のAWSアカウント上に一意のIAMユーザを作成すると 管理の観点から煩雑になりがち ・管理自体が煩雑 (人数 x 環境 x 権限?) ・担当者が増減するたびに全環境の変更が発生
62. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント(本番環境) IAMユーザ管理用のAWSアカウントを準備し、スイッチロール経由で 各環境を利用することで要件に準拠しつつ管理しやすい形に AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん （システム担当者） IAMユーザ (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン 職能に応じた IAMロールを用意 ユーザ管理は 専用アカウントで 集中管理
63. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント(本番環境) IAMユーザ管理用のAWSアカウントを準備し、スイッチロール経由で 各環境を利用することで要件に準拠しつつ管理しやすい形に AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん （システム担当者） IAMユーザ (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン 職能に応じた IAMロールを用意 開発・ステージング環境向けIAM操作時に 本番のIAM操作に関する統制制約が発生
64. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント(本番環境) AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん （システム担当者） IAMユーザ (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン AWSアカウント (IAMユーザ/本番) IAMユーザ (Aさん用) スイッチ ロール ログイン 本番環境にアクセスに関して、 本番向けIAMユーザ集約用のAWSアカウントからスイッチ 統制面を考慮して、 本番アクセスが必要な IAMユーザのみ管理 承認 プロセス あり
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
66. 一部の基本的なPCI DSS要件が満たされないため、 AWS Identity Center (旧 AWS SSO)の採用は見送り 8.2.4 ユーザパスワード/パスフレーズは、少なくとも 1 回は 90 日ごと変更する。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 AWS Identity Centerに関して、パスワードの有効期限を有効にする機能はない。 AWSサポート回答より 最初はAWS内で完結するスイッチロール、規模が拡大したらIdP連携を検討
67. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離
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)
69. 保護すべき情報が処理・通過・保持する箇所は 個別に可視化することでセキュリティ保護可能な対象が明確になる Amazon S3
70. PCI DSSでスコーピングした領域の各種サービスへの アクセスログを集中的に管理し、監査証跡として保存 Amazon S3 1. WAFのログ 2. API Gatewayのログ 3. Auroraのログ 4. ALBのログ 5. ECSタスクの アプリケーションログ 5. ECSタスク(Bastion)の 操作ログ 7. AWSの監査ログ (CloudTrail)
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に対しても出力可能 ログ
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転送がシンプル ログ
73. Amazon AuroraのログはS3バケットへの直接出力が不可 Amazon Aurora Amazon S3 ログが出力可能なサービスはAmazon CloudWatchのみ Amazon Kinesis Data Firehose Amazon CloudWatch サブスクリプションフィルターにて Firehoseに連携 ログ
74. ALBのログはS3バケットへの直接出力が可能 Application Load Balancer Amazon S3 ログ
75. ECS/Fargateタスクのアプリケーションログは S3バケットへの直接出力が不可 ECSタスク Amazon S3 App Firelens Firelens(fluentbit)を経由させることで、S3バケットにログを直接転送可能 ログ
76. Bastion(ECSタスク)の操作ログはSSMセッションマネージャの ロギング機能にて、S3バケットへの直接出力が可能 ECSタスク Amazon S3 Bastion(踏み台) ログ
77. AWS CloudTrail Amazon S3 AWS CloudTrailのログはS3バケットへの直接出力が可能 ログ
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サービス構成例 備考
79. 10.5 変更できないよう監査証跡をセキュリティで保護する。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「ネットワークの定期的な監視およびテスト」に関するPCI DSS要件 (要件10.5)
80. Standard S3(監査ログアーカイブバケット) ログの変更禁止にはS3のオブジェクトロックを活用する オブジェクトロックを有効化 （コンプライアンスモード） rootユーザ操作を含む 如何なる変更・削除が不可
81. 10.7 監査証跡の履歴を少なくとも 1 年間保持する。少なくとも 3 カ月はすぐに分析できる 状態にしておく（オンライン、アーカイブ、バックアップから復元可能など）。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「ネットワークの定期的な監視およびテスト」に関するPCI DSS要件 (要件10.7)
82. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用 Standard S3(監査ログアーカイブバケット)
83. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用 Standard Standard IA S3(監査ログアーカイブバケット) Glacier Flexible Retrieval 30日後 10年後 削除 90日後
84. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用 Standard Standard IA S3(監査ログアーカイブバケット) Glacier Flexible Retrieval 30日後 90日後 10年後 削除 少なくとも、３ヶ月(90日)は ログをすぐに分析可能 その他法令(e.g. 民法, 反収法)に 関する保持要件を加味して削除
85. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
86. コンプライアンス準拠と共存するためのサステナブルな運用戦略
87. サービス プラットフォーム AWS PCI DSS 準拠 網羅的な セキュリティ設計と実装 継続的な準拠 ビジネスアジリティとのバランスを前提として PCI DSSに準拠するために考慮すべきこと 次は こちら
88. PCI DSSは初回に準拠して「はい終了」ではなく、 全ての項目に関する継続的な準拠の証明が必須。 PCI DSS要件の適用範囲： 少なくとも年に一度、毎年の評価前に、評価対象の事業体はカード会員データの場所とフ ローをすべて特定し、（途中省略）PCI DSS の範囲の正確性を確認する必要があります。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用
89. PCI DSSは初回に準拠して「はい終了」ではなく、 全ての項目に関する継続的な準拠の証明が必須。 PCI DSS要件の適用範囲： 少なくとも年に一度、毎年の評価前に、評価対象の事業体はカード会員データの場所とフ ローをすべて特定し、（途中省略）PCI DSS の範囲の正確性を確認する必要があります。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 自分たちの日常業務や求める開発スピードと照らし合わせて いかに持続可能な（サステナブルな）形で運用を醸成できるかがポイント クラウドネイティブアーキテクチャではクラウド側への責任委譲の恩恵をより受けられる
90. 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 再掲 PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要
91. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 想定外のNW変更が発 生したらどう気づく？ 高頻度なリリース・ 障害対応においても 効率的な 承認プロセスは？ 再掲
92. 基本戦略として、ナッジではSlack中心のChatOpsを活用 コミュニケーションの中心がSlackであり、 日常的なオペレーションとの親和性が高い Slack Chatbot AWSリソース 操作(送信) Slack Chatbot AWSリソース 連携 操作・更新 状態検知 連携 通知 定期的かつ 一時的な操作 想定外の 事象検知
93. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 高頻度なリリース・ 障害対応においても 効率的な 承認プロセスは？ 再掲 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 想定外のNW変更が発 生したらどう気づく？
94. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用 VPC VPCの変更 セキュリティグループの変更 NACLの変更 ゲートウェイリソースの変更 ルートテーブルの変更 ：
95. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用 Security Hub CloudTrail CloudWatch Logs Chatbot Slack メトリクスフィルター作成が CIS Benchmark 1.2の 一部準拠要件になっている VPC アラーム (イベント) SNS VPCの変更 セキュリティグループの変更 NACLの変更 ゲートウェイリソースの変更 ルートテーブルの変更 ： CloudWatch メトリクス
96. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用 Slack SRE担当者が参加している チャンネル全体に通知 (info/error/criticalでレベル分け) リリース等の作業影響であれば その旨スタンプ＆コメント
97. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 再掲 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 想定外のNW変更が発 生したらどう気づく？ e.g. IAMロールによる職務分離 高頻度なリリース・ 障害対応においても 効率的な 承認プロセスは？
98. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん （システム担当者） IAMユーザ (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン ログイン 統制面を考慮して、 本番アクセスが必要な IAMユーザのみ管理 再掲 AWSアカウント(本番環境) IAMロール (システム担当者) IAMロール (アプリ開発者) AWSアカウント (IAMユーザ/本番) IAMユーザ (Aさん用) スイッチ ロール 承認 プロセス あり 本番環境にアクセスに関して、 本番向けIAMユーザ集約用のAWSアカウントからスイッチ
99. 本番環境にアクセスに関して、 本番向けIAMユーザ集約用のAWSアカウントからスイッチ AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん （システム担当者） IAMユーザ (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン ログイン 統制面を考慮して、 本番アクセスが必要な IAMユーザのみ管理 再掲 AWSアカウント(本番環境) IAMロール (システム担当者) IAMロール (アプリ開発者) AWSアカウント (IAMユーザ/本番) IAMユーザ (Aさん用) スイッチ ロール 承認 プロセス あり
100. Slack Chatbot Lambda IAM グループ (システム担当者用) IAMグループ (アプリ開発者用) IAMユーザ (Aさん用) IAM AWSアカウント (IAMユーザ/本番) AWSアカウント(本番環境) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチロール スイッチロール 承認者がSlackのワークフローを実行することで、 一時的にアクセスの有効化・無効化を制御 承認者 通常時は スイッチロール不可
101. Chatbot Lambda IAM グループ (システム担当者用) IAMグループ (アプリ開発者用) IAMユーザ (Aさん用) IAM AWSアカウント (IAMユーザ/本番) AWSアカウント(本番環境) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチロール スイッチロール Slack 承認者 承認者はアクセスが必要な ユーザーとIAMロール(権限) を指定して実行 承認者がSlackのワークフローを実行することで、 一時的にアクセスの有効化・無効化を制御
102. Slack Chatbot Lambda IAM グループ (システム担当者用) IAMグループ (アプリ開発者用) IAMユーザ (Aさん用) IAM AWSアカウント (IAMユーザ/本番) AWSアカウント(本番環境) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチロール スイッチロール 承認者 スイッチ可能なIAMグループに 対象ユーザが追加 承認者がSlackのワークフローを実行することで、 一時的にアクセスの有効化・無効化を制御 作業完了後も同じ流れ
103. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 再掲 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 想定外のNW変更が発 生したらどう気づく？ e.g. IAMロールによる職務分離 高頻度なリリース・ 障害対応においても 効率的な 承認プロセスは？
104. サービス プラットフォーム AWS PCI DSS 準拠 網羅的な セキュリティ設計と実装 継続的な準拠 ビジネスアジリティとのバランスを前提として PCI DSSに準拠するために考慮すべきこと 再掲
105. まとめ
106. まとめ uPCI DSSに準拠したプロダクト事例から、 クラウドネイティブ構成におけるセキュリティを高める設計事例を共有 u一定の開発スピードを維持しつつも、 持続的なコンプライアンス準拠が可能な運用事例をご紹介
107. ご清聴いただき、ありがとうございました。