API のエンドツーエンドセキュリティ：開発から廃止まで

2024 年 6 月、Akamai は Noname Security を買収しました。これは 2022 年 10 月 5 日に公開され、現在アーカイブされているブログ記事です。

アプリケーション・プログラミング・インターフェース（API）の適切なセキュリティ保護は、単なるセキュリティに留まりません。また、セキュリティの成果を上げる IT の運用とアーキテクチャ上の問題にも繋がります。API セキュリティをソフトウェアライフサイクル全体を網羅するエンドツーエンドのプロセスと見なすことが、成功の鍵です。開発から始まり、実行期間を経てサービス終了まで継続するプロセスです。

API セキュリティは、古い仮説を疑うことから始まります。たとえば、ソフトウェア開発は、コードを本番環境に展開したら終了すると考えている人がいるかもしれません。これはもはや正しいことではありません。ソフトウェア開発は、コード記述という基本的なプロセスに留まりません。

開発は、継続的インテグレーションと継続的デプロイメント（CI/CD）という考え方に組み込まれた継続的なプロセスです。同時にソフトウェアは、DevOps、つまり従来からある連続した手順に沿って行われるソフトウェア開発（Dev）と、IT 運用（Ops）によるソフトウェアの本番環境への展開が融合する中で成立します。

現在、DevOps チームは、あるコードを本番環境に展開するとすぐにそのアプリケーションの別バージョン展開に向けて準備を開始しています。次の展開は 1 時間後かもしれません。DevOps では、開発イコール運用と見なされます。プロセスの運用側と開発側の区別はつかなくなりました。したがって、アプリケーションのセキュリティについては開発と運用の連続したステージ全体で対応する必要があります。

さらに、最新のソフトウェアは単なるコードではありません。マイクロサービス、API、コードライブラリなどのコンポーネント間が結びついたものでもあります。API のセキュリティを確保するためには、これらの接続の仕組みや場所、また攻撃者にとってどれほど脆弱性かを把握することが重要です。この要件もまた、API インベントリの作成や API トラフィックの監視などの運用タスクを含んでおり、一般のセキュリティ慣行を超えています。

API セキュリティは、アプリケーションの開発段階から実行、およびその先まで、ソフトウェア開発ライフサイクル（SDLC）全体を通じてアクティブになっている必要があります。開発段階から、開発者はアプリケーションに対して API コールを介して API 機能を呼び出すように指示したり、アプリケーションの機能やデータを他のソフトウェアアプリケーションに公開する API を作成したりすることができます。どちらの方法で API を操作しても、リスクにさらされる可能性はあります。

API のセキュリティリスクはさまざまな理由で発生しますが、多くの場合、ユーザーの認証と認可に影響を与える API 設定の問題に関係しています。API の設定が誤っていると、不明なユーザーが機密データにアクセスできる可能性があります。また、設定を誤った場合、ユーザーは許可されている範囲を超えてデータを取得できてしまいます。その他の設定の問題により、攻撃者は API を呼び出して過負荷にし、サービス妨害（DoS）攻撃を実行する可能性があります。 

開発段階

API セキュリティテストを行うことで、開発段階でこのような API リスクを緩和できます。テストは API 専用のものである必要があります。一般的なアプリケーションテストでは API の設定ミスなどの問題を検知できないからです。代わりに、専用の API セキュリティテストのスイートでは、API の脆弱性を特定し、ソフトウェアを展開する前に脆弱性の修正を促進する必要があります。

API セキュリティテストを有効活用するためには、開発プロセスの早い段階で取り入れる、いわゆるシフトレフトアプローチを採用すべきです。また、テストスイートの CI/CD パイプラインとの統合も必要です。そうしないと、セキュリティの修復プロセスは DevOps チームメンバーが対処しきれないほど過剰に複雑化してしまいます。

実行時

実行時においては、API セキュリティは、リアルタイムで脅威を阻止することを意味します。これには、API セキュリティ監視が必要です。API セキュリティソリューションは、API トラフィックを常に把握し、異常な動作や攻撃シグニチャに気付いた場合に管理者に警告する必要があります。また、脅威を検知したときに API を自動的にブロックするための追加の手順を取る場合もあります。

API 実行時のセキュリティは比較的分かりやすいものです。ただし、API セキュリティソリューションがすべての API の場所を認識している場合にのみ機能します。セキュリティを確保するために、API は API 探索のプロセスを含む API ポスチャ管理の対象となる必要があります。セキュリティソリューションは、見えない API を防御することはできません。そのため、API のインベントリを作成する必要があります。API 探索も必要です。API ゲートウェイと Web アプリケーションファイアウォール（WAF）では、ユーザーの考えにかかわらず、環境内のすべての API が自動的にインベントリされるわけではないからです。

不正、ゾンビ、シャドウ：大変！

API の探索プロセスによってどの IT 管理者も例外なく、自社の環境に多数の「不正」、「ゾンビ」、「シャドウ」API が含まれているという驚くべき事態に直面します。

• 不正な API は、時間の経過とともに何らかの形で失われた API です。オフになっていない古いバージョンの API かもしれません。それは、誰も知らない、商用パッケージのソフトウェアアプリケーションに公開された API かもしれません。 
• ゾンビ API は、レーダースクリーン外にありながらも機能している API です。 
• シャドウ API は、API の構築担当者が作成したものの、IT 部門に報告していない API です。

探索されていない 3 種類の API はすべて、リスクにさらされています。これらは目に見えないため、セキュリティポリシーを適用できません。セキュリティ用に設定されていない場合（そしてほとんどの場合、設定が誤っているか、パッチが当てられていません）、攻撃者は不適切なアクセスを行うことができます。

以前から未知の API に対して何をすべきかを把握することは困難になりえます。運用を継続する場合は、設定、認証などに関するポリシーに準拠する必要があります。探索されたばかりの API をシャットダウンするのが最良の選択ですが、これによって問題が起こることも考えられます。

たとえば、古いバージョンの API を使い続けている場合、置き換えによって無効になっても、それがオフになったことでアプリケーションが停止する可能性があります。API をオフラインにする決定を下す際に誰かがトラブルに巻き込まれるかもしれません。必要なのは、適切な判断を下すために必要な情報を管理者に提供するツールセットです。

API セキュリティをエンドツーエンドで実行するためには、適切なツールが必要です。効果的なエンドツーエンド API セキュリティソリューションとは、API セキュリティテスト、API ランタイムセキュリティ、API セキュリティポスチャ管理およびインベントリを処理できるソリューションのことです。ほとんどの WAF および API ゲートウェイは開発、テスト、ランタイム監視、インベントリをカバーしていないため、既存のツールを検討する際は細心の注意を払う必要があります。

また、API セキュリティソリューションは、ネットワークや API パフォーマンスに影響を与えることなく運用できることが理想です。たとえば、 Akamai API セキュリティソリューションは、ネットワークトラフィックのコピーを監視することで機能します。このコピーされたネットワークトラフィックで API コールを検出し、プロセス内の未知の API とセキュリティ上の脅威を特定できます。

API セキュリティは、API の開発、運用、廃止までの全フェーズを網羅していなければなりません。技術的にはセキュリティに関係しない、API インベントリなどのプロセスもセキュリティの一環に含めます。未知の API はリスクになりえるため、その API を特定することでアプリケーションのセキュリティを向上させることができます。これはエンドツーエンドで対応すべき課題です。API セキュリティ対策がより完全になれば、環境全体のセキュリティを強化することができるのです。