API セキュリティを規制コンプライアンスに組み込む：注目すべき 6 つの例

これは、企業のコンプライアンスプログラムにどのような影響を与えるのでしょうか？ 

プロアクティブなアプローチによって すべての API を見つけて、それぞれのリスクを評価し、侵害から保護すれば、まさに規制当局が阻止しようとしている影響からデータを保護できます。

このブログ記事では、API 保護の必要性を示している 6 つの規制とガイドラインに関するハイレベルのレビューを行い、準拠方法の主な例を紹介します。

6 つの重要な規制とフレームワーク

1.Payment Card Industry Data Security Standard（PCI DSS）Version 4.0

PCI DSS は、決済データを保護するためのグローバルスタンダードになりました。主要なクレジットカードを受け入れて、カード所有者データを電子的に処理、保存、送信する企業は、この標準に準拠しなければなりません。 

PCI DSS 4.0 の要件 6.2.3 では、組織がカスタム・アプリケーション・コードを確認し、脆弱性が本番環境にリリースされないようにすることの必要性に重点が置かれています。特に API に関して、この要件は、組織のソフトウェアが外部コンポーネントの機能（ライブラリー、フレームワーク、API など）を安全に使用していることを確認するためのガイドラインを提示しています。 

数ある準拠方法のうちの 1 つは次のとおりです。使用する API に期待される正常なふるまいを検証し、攻撃者によるシステムの悪用を阻止するための制御を実装します（たとえば、アプリケーションのふるまいをチェックして論理的な脆弱性を検知します）。

2.一般データ保護規則（GDPR）

GDPR は、欧州連合内の個人のデータ保護を強化し統一することを目的とした欧州連合の法律です。しかし、GDPR の対象は EU を拠点とする企業だけではなく、EU で消費財やサービスを提供するあらゆる組織が遵守しなければなりません。

GDPR 第 25 条は最小権限という概念に根差しており、「個々の特定の目的のために必要な個人データのみが取扱われることをデフォルトで確保するための適切な技術的措置及び組織的措置を実装する」ことを企業に求めています。そのため、API 開発者は、API を通過する機微な情報を保護するために、ユーザー認証と認可の制御を実装する必要があります。 

これは、API セキュリティがエンタープライズの大局的なセキュリティプログラムやコンプライアンスプログラムにどのように組み込まれるかを示す良い例です。最小権限などの概念は、私たち人間だけに関わるものではありません。API にも、機能を果たす上で適切なレベルのアクセス権限を持たせる必要があります。

3.デジタル・オペレーショナル・レジリエンス法（DORA）

合計すると、22,000 以上の金融機関と欧州連合の IT サービスプロバイダーが DORA の要件の影響を受けます。DORA の目的は、組織がサイバー攻撃に耐え、復旧するための支援をすることです。 

API セキュリティはどのように DORA に組み込まれているのでしょうか？それを知るために、 DORA 第 3 条の性質について考えてみましょう。この条文は、次のことを行う ICT ソリューションやプロセスを使用することを企業に求めています。

• データ関連のリスク、不正アクセス、技術的な欠陥を最小限に抑える

• データの可用性の喪失、データ損失、完全性と機密性の欠陥を防止する

• データ転送のセキュリティを確保する

API の主な目的はデータ転送であることを考慮すると、認証制御の欠如や公衆インターネットへの意図しないアクセスなどの脆弱性がないか、API を定期的にテストすることは不可欠です。API のテストにシフトレフトのアプローチを適用することで、脆弱性が本番環境に達するのを防ぐことができます。

4.Health Insurance and Portability and Accountability Act（医療保険の携行性と責任に関する法律、HIPAA）

HIPAA は、電子カルテおよびヘルスケア IT システム内の保護対象保健情報（PHI）を保護するためのデータプライバシー規則やセキュリティ規則にフォーカスしています。PHI を電子的に保存または送信する米国のヘルスケアプロバイダー、保険管理業者、クリアリングハウスは、HIPAA を遵守する必要があります。

HIPAA のプライバシー規則では、対象となる事業体は「従業員の特定の役割に基づいて保護対象保健情報へのアクセスとその使用を制限するポリシーと手順を考案し、実装しなければならない」と定められています。 

そのため、組織の API 開発者は、認証、一意のユーザー ID、ロールベースのアクセス制御などの技術的な保護手段を組み込み、最小権限が適用されるようにする必要があります。

5.Network and Information Security Directive（ネットワークおよび情報セキュリティ指令、NIS2）

欧州連合（EU）は、2023 年 1 月に NIS 指令のバージョン 2.0 を採択しました。この指令は、IT インフラのセキュリティ確保とインシデントの報告に関する元のバージョンのガイドラインに基づいて作成されています。 

注目すべきは、 NIS2 では新たに、サプライチェーンのセキュリティ確保に重点が置かれていることです。エンタープライズは今後、リスクを評価して、IT サプライチェーンやサードパーティサプライヤーとの関係を保護する必要があります。 

API は多くの場合、ソフトウェアベンダーからクラウド・サービス・プロバイダーまで、外部サービスを統合するために使用されます。そのため、企業が顧客のデータと広範なサプライチェーンを攻撃から保護していることを規制当局に示すためには、API セキュリティが重要です。

6.Federal Financial Institutions Examination Council（米国連邦金融機関検査協議会、FFIEC） 

FFIEC は、米国の金融業界を監督する連邦規制当局のための指針と基準を作成します。これには、連邦準備制度理事会（FRB）や連邦預金保険公社（FDIC）が含まれます。同協議会の使命は、消費者と投資家を詐欺、悪用、不正行為から保護することです。

FFIEC のガイドラインを確認すれば、 組織が不正行為やアイデンティティの窃取から消費者を保護する上で、API のセキュリティを確保することがどのように役立つのか は明白です。たとえば、FFIEC は、エンタープライズが認証とアクセス制御を必要とするすべての情報システム（API を含む）のインベントリーを構築することを推奨しています。 

認可も極めて重要です。FFIEC は、アクティビティの監視、ロギング、報告などの階層化されたセキュリティを実装して、不正な API アクセスを特定し、追跡することを推奨しています。 

API のセキュリティを確保することは、信頼を守ることにつながる

このブログ記事で取り上げた 6 つの規制とガイドラインには共通点があります。それは、他人に託されたデータを保護することです。 

ご存知のとおり、 API データ漏えい のリスクは罰金だけではありません。顧客、従業員、さらには自社の業界を対象としている規制当局の間での信頼と評判も懸かっています。規制当局は、上記のような攻撃の発生を阻止するために、企業が人、プロセス、ツールを適切に組み合わせていることを確認する必要があります。

詳細はこちら

この記事で取り上げた 6 つの規制の API 関連要件について、理解を深めたいですか？