Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

iselegant
October 08, 2022

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

iselegant

October 08, 2022
Tweet

More Decks by iselegant

Other Decks in Technology

Transcript

  1. 新井 雅也 M a s a y a A R

    A I msy78 金融業界のお客様に向けたビジネス提案やシステム設計、開発、運用を担当。 UI/UXデザインやスマホApp、バックエンドAPIなど、フルスタック領域な守備範囲を持ちつつ、 クラウドを活用した全体のアーキテクチャ設計・開発が得意。 好きな技術・サービスは、ECS、Fargate、App Runner、Kubernetes、Golang、Pulumi テックリード / インフラチームリーダー
  2. 01. プロジェクトの背景とお客様の特徴 ユーザー クレジットカード スマホアプリ お店 (加盟店) 外部接続システム群 (ペイメント機能等) サービス

    プラットフォーム コンビニ NRIはNudgeと併走しながらAWSサービスプラットフォームの開発・運用 AWS
  3. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者Web 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム

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

    PCI DSS 準拠 コンプライアンスに準拠した 開発が必須 ナッジがクレジットカードに関するビジネスを成立させるためには PCIDSSの準拠が必須 AWS
  5. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

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

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

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム
  8. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者Web 外部接続システム (eKYC機能) 外部接続システム (ペイメント関連) 外部接続システム

    (カード印刷関連) スマホアプリ用 フロントAPI 管理者Web用 フロントAPI 外接システム用 フロントAPI マイクロサービス別 各API 腐敗防止層 外接向けAPI カード 返済 申込 通知 指定信用情報機関 (CIC) バッチ連携 決済 会員 管理者 外部接続システム (金融機関) データ ベース ナッジにおけるAWSサービスプラットフォームの概要 バックエンド機能はマイクロサービスをベースとしたAPI群で構成。 コンテンツ
  9. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者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群で構成。
  10. スマホアプリ 外部接続システム (返済機能) サービスプラットフォーム 管理者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の準拠範囲を確定させる (スコーピングおよびセグメンテーション)
  11. 1.3 インターネットとカード会員データ環境内のすべてのシステムコンポーネント間の、 直接的なパブリックアクセスを禁止する。 1.3.1 DMZ を実装し、承認された公開サービス、プロトコル、ポートを提供する システムコンポーネントのみへの着信トラフィックに制限する。 1.3.2 着信インターネットトラフィックを DMZ

    内の IP アドレスに制限する。 1.3.4 カード会員データ環境からインターネットへの未承認の発信トラフィックを禁止する。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「安全なネットワークの構築維持」に関するPCI DSS要件 (要件1.3)
  12. セキュリティグループごとにインバウンドと アウトバウンドを明確にする DMZの実装。 HTTPS/443のみ許可 ・VPCリンクで特定の NLBのみアクセス可能 ・NLB元のENI IPアドレス 範囲からのアクセス許可 ・発信はVPC内のみ

    ・VPC内からの アクセス許可 ・発信はカード連携のみ ・ VPC内からの アクセス許可 ・発信は外部連携のみ ・カード管理用ALBの アクセス許可 ・発信はVPC内のみ ・外部連携用ALBの アクセス許可 ・発信はVPC内のみ ・各種マイクロサービスからの アクセス許可 ・発信は禁止
  13. 2.2 すべてのシステムコンポーネントについて、構成基準を作成する。この基準は、すべての既知のセ キュリティ脆弱性をカバーし、また業界で認知されたシステム強化基準と一致している必要がある。 業界で認知されたシステム強化基準のソースには以下が含まれる(これらに限定されない)。 - Center for Internet Security(CIS) -

    国際標準化機構(ISO) - SysAdmin Audit Network Security(SANS)Institute - 米国国立標準技術研究所(NIST) 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 「安全なネットワークの構築維持」に関するPCI DSS要件 (要件2.2)
  14. 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には未対応。
  15. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

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

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) e.g. 公共ネットワーク〜VPC間のネットワーク暗号化
  18. ナッジでは、CI/CD時におけるスキャンと日次スキャンの ハイブリッド構成で脆弱性の早期検出に努めている AWSサービス (マネージドサービス) ミドルウェア コンテナ (OSパッケージ) アプリケーション (ライブラリ) 日次スキャン

    脆弱性検知の取りこぼし防止が狙い EventBridge ECSタスク Security Hub Slack ※2021-11にリリースされたAmazon Inspector統合によるECR拡張イメージスキャンも有効 ECR イメージ 取得 日次で起動 登録 通知
  19. AWSアカウント(共通) VPC (開発環境) VPC (ステージング環境) VPC (本番環境) AWSアカウント(開発環境) VPC AWSアカウント(ステージング環境)

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

    AWSアカウント(ステージング環境) VPC AWSアカウント(本番環境) VPC パターン1: VPCによる分離 パターン2: AWSアカウントによる分離 IAM IAM IAM IAM 権限周りの設定が 煩雑になりがち 環境間で設定内容は 統一しつつ、 リソースの分離が容易
  22. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離
  23. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント(本番環境) IAMユーザ管理用のAWSアカウントを準備し、スイッチロール経由で 各環境を利用することで要件に準拠しつつ管理しやすい形に AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん

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

    (システム担当者) IAMユーザ (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン 職能に応じた IAMロールを用意 開発・ステージング環境向けIAM操作時に 本番のIAM操作に関する統制制約が発生
  25. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント(本番環境) AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん (システム担当者) IAMユーザ

    (Aさん用) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチ ロール ログイン AWSアカウント (IAMユーザ/本番) IAMユーザ (Aさん用) スイッチ ロール ログイン 本番環境にアクセスに関して、 本番向けIAMユーザ集約用のAWSアカウントからスイッチ 統制面を考慮して、 本番アクセスが必要な IAMユーザのみ管理 承認 プロセス あり
  26. 一部の基本的な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
  27. 一部の基本的なPCI DSS要件が満たされないため、 AWS Identity Center (旧 AWS SSO)の採用は見送り 8.2.4 ユーザパスワード/パスフレーズは、少なくとも

    1 回は 90 日ごと変更する。 「PCI DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 AWS Identity Centerに関して、パスワードの有効期限を有効にする機能はない。 AWSサポート回答より 最初はAWS内で完結するスイッチロール、規模が拡大したらIdP連携を検討
  28. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 AWS サービス プラットフォーム e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離
  29. 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)
  30. PCI DSSでスコーピングした領域の各種サービスへの アクセスログを集中的に管理し、監査証跡として保存 Amazon S3 1. WAFのログ 2. API Gatewayのログ

    3. Auroraのログ 4. ALBのログ 5. ECSタスクの アプリケーションログ 5. ECSタスク(Bastion)の 操作ログ 7. AWSの監査ログ (CloudTrail)
  31. 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転送がシンプル ログ
  32. 各種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サービス構成例 備考
  33. コスト最適化とのバランスを鑑みてS3ライフサイクルルールを適用 Standard Standard IA S3(監査ログアーカイブバケット) Glacier Flexible Retrieval 30日後 90日後

    10年後 削除 少なくとも、3ヶ月(90日)は ログをすぐに分析可能 その他法令(e.g. 民法, 反収法)に 関する保持要件を加味して削除
  34. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用)
  35. PCI DSSは初回に準拠して「はい終了」ではなく、 全ての項目に関する継続的な準拠の証明が必須。 PCI DSS要件の適用範囲: 少なくとも年に一度、毎年の評価前に、評価対象の事業体はカード会員データの場所とフ ローをすべて特定し、(途中省略)PCI DSS の範囲の正確性を確認する必要があります。 「PCI

    DSS 要件とセキュリティ評価手順、バージョン3.2.1」より一部引用 自分たちの日常業務や求める開発スピードと照らし合わせて いかに持続可能な(サステナブルな)形で運用を醸成できるかがポイント クラウドネイティブアーキテクチャではクラウド側への責任委譲の恩恵をより受けられる
  36. 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法 の導入 ネットワークの定期的な 監視およびテスト

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

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

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. IAMロールによる職務分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 高頻度なリリース・ 障害対応においても 効率的な 承認プロセスは? 再掲 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 想定外のNW変更が発 生したらどう気づく?
  39. 重要なAWSリソースの変更検知はCloudTrailとCloudWatchを活用 Security Hub CloudTrail CloudWatch Logs Chatbot Slack メトリクスフィルター作成が CIS

    Benchmark 1.2の 一部準拠要件になっている VPC アラーム (イベント) SNS VPCの変更 セキュリティグループの変更 NACLの変更 ゲートウェイリソースの変更 ルートテーブルの変更 : CloudWatch メトリクス
  40. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

    の導入 ネットワークの定期的な 監視およびテスト 情報セキュリティ ポリシーの維持 e.g. 公共ネットワーク〜VPC間のネットワーク暗号化 e.g. コンテナ脆弱性の適切な管理と対処、開発環境と本番環境の分離 e.g. 監査証跡の取得と変更統制、ログアーカイブ AWSに関する設計・構築ではなく、 組織のセキュリティポリシーに関する項目であるため対象外 再掲 e.g. ネットワーク境界に対するセキュリティの考慮(セキュリティグループ等)、 CISによる標準セキュリティ基準の準拠 (Security HubとDockleの活用) 想定外のNW変更が発 生したらどう気づく? e.g. IAMロールによる職務分離 高頻度なリリース・ 障害対応においても 効率的な 承認プロセスは?
  41. AWSアカウント(開発環境) AWSアカウント(ステージング環境) AWSアカウント (IAMユーザ集約) IAMロール (システム担当者) Aさん (システム担当者) IAMユーザ (Aさん用)

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

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

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

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

    IAM AWSアカウント (IAMユーザ/本番) AWSアカウント(本番環境) IAMロール (システム担当者) IAMロール (アプリ開発者) スイッチロール スイッチロール 承認者 スイッチ可能なIAMグループに 対象ユーザが追加 承認者がSlackのワークフローを実行することで、 一時的にアクセスの有効化・無効化を制御 作業完了後も同じ流れ
  46. PCI DSSは6つの目標と12の要件から構成され、 イシュアーは331項目の方針検討と準拠が必要 安全なネットワークの 構築維持 カード会員データの 保護 脆弱性管理プログラムの 維持 強力なアクセス制御手法

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