PCI DSS v4.0 API セキュリティコンプライアンスの遵守に役立つベストプラクティス

最初のバージョンの要件で対象となっていたのはセキュリティの根幹ともいえる部分であり、現在でもその重要性は 2006 年の公開当時と変わりません。以下に例を示します。

• カード所有者データを処理または保存する IT システムのすべての管理者アカウントに対するアクセスを監視および制御

• システムおよびカード所有者データへのアクセス権は、知る必要がある場合に限り割り当てるものとし、ロールごとにアクセス要件を定義

問題は、現在の脅威の状況が 2006 年よりも複雑になっていることです。

組織は依然として、特権アカウントや過剰な権限を持つユーザーのような標的となる領域に狙いを定める攻撃者に対処しなくてはなりません。しかし、それに加えて今日では、決済テクノロジーでよく使われる数千もの API を標的とする攻撃者に対応できるよう、コンプライアンスプログラムを適応させる必要もあります。こうした攻撃者は、API が悪用しやすく、カード所有者データを効率的に盗む手段となり得ることを知っています。

したがって、PCI DSS v4.0に準拠するためには、組織は API の脅威を理解したうえで防御する必要があります。このブログの投稿では、リスク、要件、コンプライアンスの方法に関する知見をご紹介します。

全体的に、PCI DSS v4.0 は、主に次の 4 つの目的を中心に据えています。

1. 決済業界のセキュリティニーズを引き続き満たすこと

2. セキュリティが継続的なプロセスであることを認識してもらうこと

3. エンタープライズ組織が要件を満たす手法に柔軟性（新しいツール、新しい制御など）を持たせること

4. 検証方法とプロセスを強化すること

PCI DSS v4.0 は、可視化と保護を必要とする重要な領域として API を明示的に規定しています。4 つの目的がすべて関係してはいますが、API に固有のリスクを考慮すると、3 番目（新しいツールと制御を使用する柔軟性）が特に重要です。以下に例を示します。

• API は、顧客向けのデジタル製品やサービスの中核を担っています。規模にもよりますが、平均的なエンタープライズ組織の API の数は 15,000 から 25,000 ほどになり、そのすべてがデータをノンストップで交換するよう設計されています。

• このデータには、機密性の高い顧客情報が含まれます。すべてのデジタル決済には、その裏で API が動いており、アプリケーション、システム、サードパーティなどの間でデータを送信しています。

• たった 1 つの API が侵害されただけでも、数百万もの記録が盗難されたり、身代金を要求されたり、世界中にさらされたりする恐れがあります。公開されている API や設定ミスのある API は至るところにありますが、侵害されやすく、保護や可視化、管理が不十分になる傾向があります。

規制当局は API のリスクを認識しています。そのため、企業は、データの侵害を防ぐための可視性と制御を備えていることを示せなくてはなりません。

Verizon の 2023 Data Breach Investigations Report（データ漏えい調査レポート）によると、ペイメントカードのデータが侵害される割合は 37% と、3 分の 1 を超えています。PCI DSS v4.0 では、 多要素認証 とパスワードの長さに関する新たな要件が含まれており、決済業界のアタックサーフェスにおける人的要素のセキュリティ確保を図っています。

しかし、ここで注意しなければならないことは、 データ漏えい は、従業員パスワードの フィッシング のようによく知られた人間中心の攻撃手法が原因であるとは限りません。

たとえば、e コマース企業への攻撃の 18% では、カードを処理する Web ページに埋め込まれた悪性のコードが関与しています。今日の攻撃者はますます巧妙になっており、API のように適切に保護されないことが多い IT 環境の要素のうち、人手を介さない自動的なものに狙いを定めます。

Akamai の調査によると、企業の 78% が API 関連のセキュリティインシデントを経験しています。 API の脅威には緊急を要するという認識に立ち、PCI DSS v4.0 には、新しい API セキュリティルール、ガイドライン、およびベストプラクティスが含まれています。まず、要件 6.2.3 について詳しく説明します。

要件 6.2.3 では、組織がカスタム・アプリケーション・コード（標準的な市販の商用アプリケーションではない、サードパーティベンダーによって開発されたアプリケーション）を確認し、脆弱性が本番環境に入り込まないようにすることの必要性に重点が置かれています。

この要件は、組織のソフトウェアが外部コンポーネントの機能（ライブラリ、フレームワーク、API など）を安全に使用していることを確認するためのガイダンスとなっており、API が幅広いソフトウェア・サプライ・チェーンで果たす重要な役割と、API の保護に必要なものについて言及しています。

API は、最新のアプリケーション環境での接続とデータ交換のデフォルトの方法となっています。そのため、攻撃時にデジタルビジネスの耐障害性を確保するためには、本番環境の前（シフトレフト）と後（シールドライト）の両方のアプローチで API を保護することが不可欠です。

ここでは、要件 6.2.3 への準拠に役立つ 6 つの API セキュリティのベストプラクティスについて説明します。

1. API ベースのコンポーネントの使用とそのセキュリティ対策を確認（たとえば、この基準で指摘されているような貧弱な暗号の使用など、脆弱性につながる設定ミスなどを見つけます）

2. 使用する API に期待される正常なふるまいを検証し、攻撃者によるシステムの悪用を阻止するための制御を実装（たとえば、アプリケーションのふるまいをチェックして論理的な脆弱性を検知します）

3. API を強化するために使用されるサードパーティフレームワークを検出し、それが古くて脆弱かどうかを判断

4. 実行している API のさまざまなバージョンを含むすべての API の完全なインベントリを作成し、これにより、ドキュメント化されていない可能性のある機能や、管理する必要があるバックドアを把握

5. API コードのセキュリティを検証し、API 関連の脆弱性が本番環境に紛れ込むことを回避

6. API のための安全なコーディングのベストプラクティスを実装し、これにより、コードを継続的に安全に配信するためのプログラム的なアプローチを採用

PCI SSC は、API セキュリティを構成する 2 つのセクションも PCI DSS v4.0 に追加しています。ここでは、お客様が満たす必要がある 2 つの追加要件の概要を示します。

• 要件 6.3.2 は、カスタマイズされた特別仕様のソフトウェアと、そうしたソフトウェアに組み込まれたサードパーティ製ソフトウェアのコンポーネントのインベントリの維持に適用されています。その目的は、脆弱性およびパッチの管理の円滑化です。

• 要件 6.2.2 は、カスタマイズされた特別仕様のソフトウェアを扱うソフトウェア開発担当者のトレーニングに対応しています。安全なソフトウェア設計や安全なコーディング手法など、職務に関連するセキュリティについて 12 か月に 1 回以上の頻度で開発者がトレーニングを受ける必要があることについて言及しています。このトレーニングの内容には、セキュリティ・テスト・ツールや、ソフトウェアの脆弱性を検出するためのツールの使用方法が盛り込まれています。