APIセキュリティの準備はできていますか？

すべてのアプリケーションは、API（カーネル、ソフトウェア開発キット、暗号ライブラリ、SOAPなどへの呼び出し）を使用しています。別に新しいものではありません。今日のベンダーが「APIセキュリティ」と呼んでいるものは、それらのAPIのサブセット（ネットワーク上で公開されているもの）を指します。ネットワークに公開されたこれらのAPIは、その性質上、情報の自由な流れとソフトウェアコンポーネント間の相互作用を可能にします。エンドポイントをパブリック/クラウド/プライベートネットワークに公開することにより、システムのこれらのコンポーネントを調べ上げる新しい機会が攻撃者に与えられます。私たちは、いくつかの有名な企業（USPS、T-Mobile、Salesforceなど）で、安全でないAPIエンドポイントの暴露や使用に起因する注目度の高い侵害を見てきました。そこでは、使用および作成するAPIのセキュリティを確保するために必要なコントロールにソフトウェアセキュリティ対策が対応しているかどうかをどうやって確認するかが問題になります。この問題に答えるためには、まず「APIセキュリティ」を定義する必要があります。

「APIセキュリティ」とは

APIセキュリティとは、組織が作成および使用し、ネットワークに公開するAPIを保護することです。もちろん、これはAPI（レート制限と認証、ユーザー、サービス、およびリクエストの認証と認可）に密接に関連した共通のセキュリティ対策を利用することを意味します。また、データ来歴を把握し、構成されたシステムを見るとき、設計やレビューの話し合いの際にコンテキストを探す具体的な場所を理解することを意味します。リーダーにとっては、アプリケーション・セキュリティ・プログラムがAPIを公開または使用するソフトウェアに対して適切なタイミングでアクティビティをキャプチャして適用することを意味します。堅牢なAPIセキュリティは、単に新しいツールを購入するだけでなく、ソフトウェア・セキュリティ対策全体の活動を伴うセキュリティの文化に由来します。

APIセキュリティへの対処

マイクロサービス・アーキテクチャなどの一般的なソフトウェア開発の傾向により、SSIに関連するソフトウェアの単位は「アプリケーション」（モノリス）から、独自のライフサイクルと保持するコントラクト、および存在する必要があるセキュリティ対策を備え、APIを公開する多くのサブコンポーネントへと進化しています。ソフトウェアセキュリティのリーダーは、次の分野で改善の機会を見つけることができます。

また、設計者はAPIの横断的な問題の特定にも直面しています。セキュリティリーダーは、アクセス制御の統一などのセキュリティ対策や、顧客IDの統一などのビジネスロジックに近いセキュリティ対策に注意を払う必要があります。

セキュリティ対策

セキュリティ対策に関しては、APIセキュリティ内に、ビジネスロジック内の対策（悪用事例に対する保護）、ビジネスロジックを保護する対策（認証と認可）、アーキテクチャによって有効化または定義されたアーキテクチャ上のセキュリティ対策（APIゲートウェイ、マイクロセグメンテーション）といった複数の抽象化レベルがあります。

アーキテクチャ上の決定によって有効になるセキュリティ対策は、APIセキュリティのコンテキストでのアプリケーション開発においては比較的新しいものです。セキュリティ対策は、ビジネスロジック以外に、速度チェック、認証、認可の決定などの懸念事項にも適用されます。また、ゲートウェイによって重要なセキュリティ対策を有効にできるAPIのクラスターを分離する最善の方法についての問題もあります。たとえば、マイクロセグメンテーションは目的を達成するでしょうか？ サービスメッシュが提供する対策はどの程度効果があるでしょうか？

アーキテクチャ上の決定では、セキュリティアーキテクトがこうした分散システムの洞察を深めることができるように、チョークポイントの提供を目指す場合があります。アーキテクチャ上の決定には、一元管理アプローチが必要な場合もあれば、エンドポイントに適用されるアプローチを有効にする場合もあります。それ以外は自由です。また、新しいアプリケーションファイアウォールとデータ損失防止（DLP）メカニズムで市場に参入するベンダーの主張について話し合い、検討する必要があります。

もちろん、脅威モデリングをお勧めします。アプリケーションセキュリティのリーダーは、さまざまな種類のAPI（ファーストパーティ、サードパーティ、クライアント、コンシューマー）に対するリスク、各APIエンドポイントの主要な対策、APIを多用するアーキテクチャ（マイクロサービスなど）によって生じる問題への許容可能なソリューション、およびベンダーの主張をリスク管理プログラムの一部として受け入れるかどうかを判定するプロセスを開始する必要があります。

インベントリ

リーダーは、組織のAPIフットプリントを可視化して、これに対応する取り組みをプロセスとツールで測定し、進行中のセキュリティアクティビティを追跡、記録、優先順位付けし、さまざまな種類のセキュリティ解析に関する豊富なコンテキストを提供する必要があります。APIセキュリティについてプログラムの所有者と話をすると、多くの場合、既存のインベントリソリューションではこの洞察が得られていないことが分かります。プログラムの所有者は、既存のインベントリソリューションを適応させることができるか、または新しいソリューションを採用する必要があるかどうかを慎重に検討する余地があります。

インベントリに正確な情報を投入することは全く別の問題です。情報は開発グループから入手できますが、プロセスの脱漏の検出に投資する必要があります。情報源には、クライアントおよびサービスのコードベース（あるいはバイナリまたはライブインスタンス）に導入されたセンサー、ネットワーク検査、OSINT技術、完全なブラックボックス検出などがあります。一日の終わりには、検出用センサーの結果をインベントリに投入し、全く知らないAPIを操作できるようになるはずです。