本記事は
基盤デザインウィーク
6日目の記事です。
🌈
5日目
▶▶ 本記事 ▶▶
7日目
💻
はじめに
初めてブログを執筆する事になりました。 基盤デザイン事業部所属の川島と申します。 2022年11月にキャリア入社しまして、1年と2か月が経ちました。(一瞬でした。。)
入社してから一貫してAWS上でのシステムの構築・運用を行っています。
今回は、PCI DSS v4.0の改正に伴い必要になった対応の一部として CSP (Content Security Policy) レポートの抽出について書きたいと思います。
「PCI DSS」も「CSP」という用語も今のシステムを担当してから初めて知りました・・
知識の整理も含めてまとめてみます。
PCI DSS の概要
PCI DSS（Payment Card Industry Data Security Standard）は、クレジットカード情報の取り扱いに関する国際的なセキュリティ基準です。 この基準は、オンラインショッピングの普及とそれに伴うセキュリティリスクの増加、さらには加盟店の負担軽減を目的として設立されました。
もともとは、各国際カードブランドが個別にセキュリティ基準を設けていましたが、業界の統一と効率化を図るため、American Express、Discover、JCB、MasterCard、VISAの国際カードブランド5社が協力してPCI DSSを開発しました。そして、その5社によって組織されたPCI SSC（Payment Card Industry Security Standards Council）によって運用・管理が行われています。この基準は、クレジットカードデータの安全な取り扱いを保証し、顧客情報の保護を最優先にしています。
クレジットカードデータを扱うシステムに該当する場合、本基準に準拠する必要があります。 そして近年大きな改定があり、「PCI DSS v4.0」がリリースされました。
PCI DSS v4.0 の概要
PCI DSS v4.0 は、2022年3月にリリースされました。 PCI DSS v3.0 の2013年11月リリース以来、約8年ぶりのメジャーアップデートとなっております。
この新バージョンでは、基本的な従来の12要件を維持しつつリスクベースのアプローチを新たに導入しています。
また、クラウドコンピューティングやマルチテナント環境など、現代のシステム環境の変化に対応するためのアップデートも含まれています。
v4.0の変更点のうち、今回はクレジット決済ページの改ざん防止のために追加された要件6.4.3について掘り下げていきたいと思います。
要件6.4.3の詳細
「要件６：安全なシステムおよびソフトウェアの開発と維持」の中で新規要件として追加された「要件6.4.3」ですが、以下の記載がございます。
PCI-DSS-v4_0-JA.pdf より引用
6.4.3 消費者のブラウザに読み込まれ実行されるすべての決済ページスクリプトは、以下のように管理される。
• 各スクリプトが認可されていることを確認するための方法が実装されている。
• 各スクリプトの整合性を保証するための方法が実装されている。
• すべてのスクリプトのインベントリが、それぞれのスクリプトが必要な理由を説明した文書とともに維持される。
また、NRIセキュア 様のブログ では、特徴と「要件6.4.3」が追加された背景を考察されております。
特徴
PCI DSS v4.0の主な特徴としては以下3点が挙げられる。
①リスクベースの考え方の取り込み
②昨今のクレジットカード情報漏洩の傾向を踏まえた新要件の追加
③既存要件で求められる対策の更なる強化
背景
PCI DSS v4.0要件の主な変更点
昨今、決済ページのスクリプトが改ざんされることによるカード情報の漏洩が多発していることを踏まえ、
決済ページの改ざんを防ぐための要件が新規追加されたと想定される。
決済ページのスクリプト改ざんによるカード情報の漏洩が多発している事が背景にあるわけですね。 では、ページ改ざんをどのように検知するか、ここでCSPが活躍してくれます。
CSP (Content Security Policy)
概要
MDN web docs から概要に関して引用します。
コンテンツセキュリティポリシー (CSP) は、クロスサイトスクリプティング (Cross-site_scripting) やデータインジェクション攻撃などのような、特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。 これらの攻撃はデータの窃取からサイトの改ざん、マルウェアの拡散に至るまで、様々な目的に用いられます。
特に、決済ページ表示の際にクロスサイトスクリプティング攻撃が成立してしまうとクレジットカード情報の窃取に繋がるので大変です。
サーバ側でレスポンスヘッダを付与してあげることで、ブラウザ側ではサーバ側から許可されたドメインのスクリプト以外は無視できるというものです。
これにより、意図していないページの改ざんを防ぐ事ができる、という事です。
CSP レポート とは
CSPのディレクティブの1つに「Reportingディレクティブ」があります。
「report-uri」や「report-to」ディレクティブを設定する事で、CSP違反となった情報をJSON形式で受け取る事ができるようになります。
このJSON形式で情報を受け取る事ができるレポーティング機能を「CSPレポート」と呼んでおります。
また、「Content-Security-Policy-Report-Only」というレスポンスヘッダで指定すると、CSP違反を検知して報告のみを実施するという事も可能です。
ポリシーの強制も実施したいか、レポートを受信するだけで良いのか、利用場面に応じて使い分ける必要があるかと思います。
適用例
適用例をいくつか見ていきましょう。 下記もMDNのドキュメント から引用して掲載しております。
例 1
すべてのコンテンツをサイト自身のドメイン（サブドメインを除く）から取得させたい場合
Content-Security-Policy: default-src 'self'
上記は完全に外部からスクリプトを読み込ませたくない場合に使えそうです。
一方で、Googleタグマネージャー等の外部からスクリプトを読み込む必要がある場合は別の方法が必要です。
例２
サイト管理者が、信頼されたドメインとそのすべてのサブドメインからのコンテンツを許可したい場合（CSPがセットされたドメインと同一とは限らない）。
Content-Security-Policy: default-src 'self' example.com *.example.com
特定のドメインからのコンテンツの読み込みは許可したいという場合です。「*」が利用できるので、example.com のすべてのサブドメインを許可したい場合に利用できます。
例３
Content-Security-Policy-Report-Only: default-src https:; report-uri https://example.com/csp-report
上記はhttps からのコンテンツ読み込みに違反していた場合 (httpのソースから読み込む等) は、違反情報をJSON形式で「https://example.com/csp-report」へ送信します。
ヘッダ名が「Content-Security-Policy-Report-Only」なので実際にブロックはせずにレポートの送信のみ実施します。
CORSによる別オリジンからJSファイル等を読み込みたい場合は、上記のように明示的にドメインを追記する事で解決できます。
その他にも適用例がございますので、興味がある場合はMDNのWeb Docsを参照していただければ幸いです。
コンテンツセキュリティポリシー (CSP) - HTTP | MDN
基盤側の対応
実際はCSPをレスポンスヘッダへ渡す対応とCSPレポートをブラウザから送信する機能追加は、アプリチームさんが実施してくださっております。
残りの要件としてはCSPレポートが検知された際に、すぐに対応する事ができる監視基盤の作成です。
下記は、基盤側で実施した監視基盤構成の図表になります。
図表の通り、基盤側ではAWSサービスを利用して以下の様な対応を行っています。
1. CSPレポートを送信する受け口を作成する（API Gateway＆WAF）
2. Lambdaを利用して、指定ロググループへ書き出しを行う (Lambda)
3. 書き出されたログを検知し、アラームを動作させる (CloudWatch Logs ＆ Alarm)
4. SNSへの経路を作成して、Slackやコールする仕組みを用意する (SNS)
上記はあくまで一例ですが、サブスクリプションフィルターを設定し、検知したログの内容をSlackに通知させる等の実装へ変更すると一次対応の切り分けもよりやりやすくなるのではとも考えております。
さいごに
今回はPCI DSS v4.0 と CSPレポートの利用に関してまとめてみました。
PCI DSS v4.0では対応すべき項目が他にもありますが、対応されている方は共に頑張りましょう！
この記事が誰かの参考になれば幸いです。
