PCI DSS v4.0 に準拠するために CSP レポート分析基盤を構築しました

STORES 技術推進本部の id:atpons です。普段は STORES 全体の技術課題をいい感じにしたり、パブリッククラウドの管理、運用をしています。

今回は STORES ネットショップで PCI DSS v4.0 に準拠するにあたり必要となった CSP レポートの分析システムについて、さまざまな検討を行った結果、内製することにした経緯を紹介します。

CSP レポートとは

Content Security Policy（CSP）は、Web サイトのセキュリティを向上させるためのセキュリティ機構です。CSP ヘッダを設定すると、ブラウザ上で読み込まれるリソース（スクリプト、スタイルシートなど）を特定のものに制限することができます。

一方で、普段我々は決済に利用しているスクリプトやその他サードパーティから提供されているスクリプトも多くあります。それらをブロックしないように分析を行い、ポリシーを厳しくしていくことで段階的な導入を目指すことができます。

その際、役立つのが CSP レポートです。CSP レポートは、CSP によってブロックされたリソースの情報を含む JSON です。

{
  "csp-report": {
    "document-uri": "http://example.com/",
    "referrer": "",
    "violated-directive": "script-src-elem",
    "effective-directive": "script-src-elem",
    "original-policy": "script-src 'self'; report-uri http://report.example.com/report",
    "disposition": "report",
    "blocked-uri": "http://third-party.example.com/script.js",
    "status-code": 200
  }
}

PCI DSS v4.0 と CSP の関係

STORES ネットショップでは従前より PCI DSS に準拠していましたが、PCI DSS v4.0 へのアップデートに伴い、さらなる対応を実施する必要がありました。具体的には、要件6.4.3および要件11.6.1にて、不正なスクリプトの挿入（ペイメントアプリケーション改ざんなど）に対する保護が新たに求められるようになりました。

CSP はこのような攻撃から保護するための効果的な手段の一つです。ペイメントアプリケーション改ざんによる被害を検知するためにも、適切な CSP の設定を行い、普段から外部のスクリプト読み込みを監視しておく必要があります。

CSP レポート分析ツールの導入検討について

CSP レポートはブラウザから JSON 形式で送信されますが、これらのレポートを適切に分析し、検知する必要があります。当初、外部の製品を導入することも検討しましたが、必要な要件を整理していくことで内製でも問題ないと判断しました。具体的には、以下の要因がありました。

スクリプトの脅威分析は困難だった

CSP レポートを用いて収集したサードパーティのスクリプトについてはほとんど難読化されており、正確に脅威を判定することが難しい
- 内容の判断は難しいが、変更を検知するシステムであれば、内製で問題ないと判断した

スクリプトの変更検知を行いたかった

今回導入検討したソリューションの中には、サードパーティのスクリプトの変更検知もできるものがありました
- 変更検知の実装については、内製してもシンプルな実装で完結すると考えました

上記のポイントを抑えるだけであれば、内製することで構成もシンプルにできコスト面も非常に安価に抑えることができると考え、内製を行うことにしました。

内製したシステムの構成

システム構成としては、Go で記述されたシンプルな Web アプリケーションです。受信した CSP レポートは構造化ログとして出力し、Firelens（Amazon ECS のログルーティング機能）を用いて受信したログを S3 に保存しています。S3 に保存したデータは Athena でクエリできるようにしています。

スクリプトの変更検知については、CSP レポート収集システムとは切り離して開発することにしました。監視対象のスクリプトを定期的にウォッチし、ハッシュを保存して差分があれば記録したものを通知する形にしています。