ソフトウェア・インテグリティ

 

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

最近のシステムは、さまざまなネットワークを介してAPIを公開する複雑なシステムに依存しています。APIセキュリティとは何でしょうか。また、セキュリティ・プログラムにどのように組み込まれるものでしょうか。

APIセキュリティとは何でしょうか。また、セキュリティ・プログラムにどのように組み込まれるものでしょうか。

シノプシスのCybersecurity Research Center(CyRC)APIセキュリティ・グループ(Travis BiehnJohn TappJamie Boote

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

「APIセキュリティ」とは

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

APIセキュリティへの対処

一般的なソフトウェア開発の傾向により、SSIに関連するソフトウェアの単位は「アプリケーション」(モノリス)から、存在する必要がある独自のセキュリティ・コントロールを備え、APIを公開する多くのサブコンポーネントへと進化しています。

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

APIの設計

APIはフロントエンド・クライアント(シック・クライアント、ブラウザ)とバックエンド・システムの間、およびバックエンド・コンポーネント間で使用されます。さらに、単一のAPIエンドポイントにフロントエンドとバックエンドのリクエストが混在する場合があります。個々のAPIエンドポイントが既知および未知のさまざまな呼び出し元(ゲートウェイまたはロード・バランサーによってアップストリームで使用、構成、またはラップされる)に公開される場合、個々のAPIエンドポイントが適用する必要のあるセキュリティ・コントロールを判断することは困難です。アプリケーション・セキュリティのリーダーが行うことができる1つの決定は、プロバイダーとコンシューマーの両方に対して想定されるセキュリティの責任を明示的に文書化するAPIを推進することです。

個々のAPIエンドポイントが既知および未知のさまざまな呼び出し元に公開される場合、個々のAPIエンドポイントが適用する必要のあるセキュリティ・コントロールを判断することは困難です。

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

セキュリティコントロール

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

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

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

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

脅威モデリングはAPIセキュリティの評価を開始する入口としては適しています。

インベントリ

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

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

ブラックボックスの検出は未知のAPIの発掘に役立ちます。

セキュリティ・テスト

最近のセキュリティ・テストは、従来と変わらず、アップストリーム・ソフトウェア・セキュリティの実効性に関する洞察を得るのに適しています。APIのセキュリティ・テストは、手動、自動、ハイブリッドのアクティビティに新たな課題をもたらします。コンテキストはそのようなギャップの1つであり、APIを受け取るテスターが入力を形成したり、脅威モデルを直観する能力を備えていなければ、SSIの向上に課題をもたらす重要な問題を見つけることができません。確かに、ツールもあまり有効とはいえません。

静的解析ツールは言語固有のソフトウェア・セキュリティの問題や、熟知されているインジェクション攻撃のクラスを特定するには有効であり、APIを多用するコードベースに対しても依然として有効ですが、それには、ツールがAPIのルートを公開するために使用するライブラリやプラットフォームをモデル化する必要があります。静的コード解析ツールはビジネス・ロジックの欠陥を発見するにはあまり役立ちません。APIを多用するプロジェクトには、このギャップをさらに悪化させるコードベース横断的な推論機能が必要です。静的解析ツールがツールボックスの重要なツールであることに変わりはありませんが、リーダーは、特に普及度の高いAPIプラットフォームで記述されたコードの欠陥を検出するツールの能力を評価する必要があります。幸いにも、セキュリティ・コントロールの導入を推進するために静的分析アプローチ(認証ライブラリや認可ライブラリの使用など)を採用している組織は、APIセキュリティに対してその戦略が依然として有効であることに気付くはずです。

APIカバレッジを生成できる動的解析の一般的なアプローチには、クライアント(またはハーネス)でのテスト、動作テストを用いたテスト、仕様を用いたテストなどがあります。ここで紹介するソリューションは、構築してテストツールに投入することを開発チームに求めることではなく、可能な限り多様なテスト準備をサポートすることを目的にしています。リーダーは、プロジェクトにインセンティブを与える方法を探し、テスタビリティを高める方法を採用する必要があります。手始めに行うには、コストとスピードの2つが適しています。

最近のアプリケーションやシステムは、さまざまなパブリックおよびプライベート・ネットワークで公開される複雑なAPIシステムに依存しています。これらの変更がソフトウェア・セキュリティ対策のさまざまな要素に与える影響を理解し、APIを公開または使用するソフトウェアに適切な場所、適切なタイミングでセキュリティが組み込まれていることは簡単な手順で確認することができます。

APIセキュリティのプロに相談する

この投稿はBSIMMコミュニティで発表された記事を元にしています。BSIMMについて、およびBSIMMコミュニティへの参加方法についてはこちらをご覧ください。