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

by iselegant

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

スマホアプリ外部接続システム (返済機能) サービスプラットフォーム管理者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群で構成。

Slide 28

Slide 28 text

スマホアプリ外部接続システム (返済機能) サービスプラットフォーム管理者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の準拠範囲を確定させる（スコーピングおよびセグメンテーション）

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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には未対応。

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

スマホアプリ外部接続システム (返済機能) サービスプラットフォーム管理者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)

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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)

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

一部の基本的な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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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)

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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転送がシンプルログ

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

各種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サービス構成例備考

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

まとめ

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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