ゼロトラストの世界における API セキュリティ

1.「すべてのデータソースとコンピューティングサービスはリソースと見なされます」

ZTA の範囲内のアプリケーションやデータソースの多くは、直接のユーザーインターフェースだけでなく API を介してアクセスできます。したがって、ZTA 評価およびポリシー適用モデルには API インターフェースを含める必要があります。

2.「ネットワークの場所に関係なく、すべての通信が保護されます」

API がプライベート・データ・センターまたはクラウド環境内での内部使用のみを目的としている場合でも、外部と接しているかのように暗号化、認証、認可を実行し、データの機密性と完全性を確保するする必要があります。

3.「個々のエンタープライズリソースへのアクセスは、セッションごとに許可されます」

API リソースへのアクセスを許可する前に、信頼性を評価する必要があります。アクセス権を付与する際は、可能な限り最小限の権限を付与する必要があります。ふるまい分析を使用して API の使用状況を監視し、継続的に信頼性を評価します。

4.「リソースへのアクセスは動的なポリシー（クライアントアイデンティティ、アプリケーション／サービス、および要求元資産の観測可能な状態など）によって決定されます。また、ふるまいや環境に関するその他の属性が含まれる場合があります」

ZTA を API に適用するためには、関与するエンティティを特定し、ビジネスコンテキストを推測し、ふるまい分析を使用して通常の使用パターンからの逸脱を特定できなければなりません。

注目すべきふるまいの属性として、迅速な API 呼び出しによるサービス妨害があげられます。

そのため、 API レート制限 の欠如は、 Open Worldwide Application Security Project（OWASP）API Security Top 10において「機密性の高いフローへの制限のないアクセス」に分類されています。 NIST は、「これらのルールと属性はビジネスプロセスのニーズと許容可能なリスクレベルに基づきます」と述べています。 

5.「エンタープライズは所有するすべての関連資産の完全性とセキュリティの状態を監視し、測定します」 

この要件は、 米国サイバーセキュリティ・社会基盤安全保障庁（CISA）が定義する継続的な診断および緩和（CDM）の概念に基づいています。CDM には、アセット管理、脆弱性管理、構成／設定管理などの要素が含まれます。 

物理的な資産と同様に、 API は継続的に探索、分類、追跡する必要があります。同様に、継続的な脆弱性評価を、従来のネットワークや アプリケーションセキュリティ の枠を超えて拡張し、潜在的な API ベースの脆弱性を含める必要があります。

6.「すべてのリソース認証と認可は動的であり、アクセスが許可される前に厳密に実行されます」

この概念は API に拡張可能であり、拡張する必要があります。ZTA を導入している組織は、認証および認可された API トラフィック内で異常なふるまいまたは不正なふるまいが検知された場合に応答するために、API の使用状況を継続的に監視し、自動化されたテクノロジー（ブロック、制限、認証情報の無効化など）を使用する必要があります。

7.「エンタープライズは、資産、ネットワークインフラ、通信の現状について可能な限り多くの情報を収集し、それを使用してセキュリティ体制を改善します」 

API セキュリティ対策が ZTA の有効な要素となるためには、長期間（理想的にはわずかな API の悪用を検知するのに十分な期間）にわたってデータを収集できなければなりません。

リアルタイムのリスク評価と ZTA 設計の継続的な改善の両方を目的としてふるまい分析を実行するためには、このレベルの詳細さが必要です。これには、考え得るポリシーの改善点を特定するために、脅威ハンターに API や脅威データへのオンデマンドアクセスを提供することが含まれます。また、チームが使用する開発や運用のツールおよびワークフローでも、同様の統合ポイントを作成する必要があります。