BOPLA は、Broken Object Property Level Authorization（オブジェクト・プロパティ・レベルの認可の不備）の略です。BOLA はオブジェクト全体を指すのに対し、BOPLA はオブジェクト内のプロパティを指します。BOLA に対する API 保護では BOPLA を確実にカバーできないため、両方のタイプの攻撃を防ぐセキュリティ製品を選択することが重要です。
API 保護には、攻撃者による攻撃や悪用からアプリケーション・プログラミング・インターフェース（API）を守る一連のプロセス、プラクティス、およびテクノロジーが含まれます。API 保護は現代の サイバーセキュリティプログラムに欠かせない要素であり、セキュリティチームの最優先事項です。
API とは
アプリケーション・プログラミング・インターフェース（API）とは、異なるソフトウェアプログラムやコンポーネントが相互に通信してデータや機能を共有できるようにする一連のプロトコルと定義です。また、API はアプリケーション同士のどのようなインタラクションを許可するかを統制し、リクエストの実行方法やプログラム間で交換されるリクエストの種類を制御します。
API は多くの IT 環境が利用するクラウドサービス、マイクロサービス、 サーバーレスアーキテクチャ、IoT（モノのインターネット）に欠かせない要素です。API はアプリケーションのロジックとリソースを公開し、機微な情報の転送を伴うことが多いため、ハッカーにとって魅力的なターゲットです。API のセキュリティが確保されていない場合、本来は安全であるはずの IT 資産に攻撃者がアクセスできるようになる可能性があります。そのため、API 保護は、ネットワークとアプリケーションのセキュリティを維持し、データ漏えいやその他のセキュリティ問題を防止するために不可欠です。
API セキュリティのリスク
よくある API セキュリティのリスクは、いくつかのカテゴリーに分類されます。
- 脆弱性の悪用。このタイプの API 攻撃では、攻撃者が API の構築方法やコード方法の欠陥を利用して API に不正アクセスします。
- 認可エラー。認可が注意深く管理されていない場合、API とのインタラクションを行うクライアントは、使用できないはずのデータにアクセスできる可能性があり、データ漏えいのリスクが高まります。
- 認証の問題。ユーザー認証プロセスが侵害されると、API は不正なソースや悪性のソースからの要求を受け入れる可能性があります。
- 分散型サービス妨害攻撃。大量の要求で API を過負荷状態にすることで、DoS 攻撃や DDoS 攻撃は API を応答不能にしたり、クラッシュさせたりします。
OWASP API Security Top 10 とは
Open Worldwide Application Security Project（OWASP）は、ソフトウェアセキュリティの向上を目的とした非営利団体です。OWASP は毎年、API のセキュリティリスク上位 10 件のリストを公開します。2023 OWASP API Security Top 10 リストには、次のセキュリティ脅威が含まれています。
- オブジェクトレベル認可の不備（BOLA）：API によってオブジェクト識別子を処理するエンドポイントが公開され、オブジェクトレベルのアクセス制御の問題の大きなアタックサーフェスが生じることがよくあります。
- 認証の不備（BA）：認証メカニズムが正しく実装されていない場合、攻撃者が認証トークンを侵害したり、実装の欠陥を悪用したりできる可能性があります。
- オブジェクト・プロパティ・レベルの認可の不備（BOPLA）：オブジェクト・プロパティ・レベルの認可検証が不適切である場合、情報が攻撃者によって公開または操作される可能性があります。
- 制限のないリソース消費：API 要求を満たす際に CPU、メモリー、ストレージ、およびネットワーク帯域幅の特定のリソースが消費されるため、API を無制限に使用するとサービス妨害やコストの増加につながる可能性があります。
- 機能レベルの認可の不備（BFLA）：複雑なアクセス制御ポリシーは、認可の欠陥につながる可能性があります。
- 機密性の高いフローへの制限のないアクセス：ビジネスフローが一般に公開されると、自動化された方法でそれを過剰に使用してプロセスを混乱させられる可能性があります。
- サーバーサイドリクエストフォージェリ（SSRF）：API がユーザーから供給された URL を検証せずにリモートリソースをフェッチすると、攻撃者がアプリケーションに細工された要求を予期しない宛先へ送信させる可能性があります。
- セキュリティの設定ミス：多くの場合、API にはソフトウェアエンジニアや DevOps エンジニアによる誤設定があるため、さまざまな攻撃を受ける可能性があります。
- 不適切なインベントリ管理：インベントリやドキュメントが適切に更新されていない場合、非推奨の API バージョンやデバッグエンドポイントの公開といった問題が発生する可能性があります。
- API の安全でない使用：ユーザーの入力よりもサードパーティの API から受信したデータの方が信頼される傾向があるため、開発者は特定の API に対して脆弱なセキュリティ標準を適用する可能性があります。
API セキュリティとアプリケーションセキュリティの違い
API 保護には、Web セキュリティと同じセキュリティ原則が多数含まれますが、攻撃からの API の保護にはいくつかの固有の課題があります。現代のアプリケーションシステムで使用されている API の数は非常に多いため、セキュリティチームが API の脆弱性を特定し保護を更新することが難しくなっています。API はサードパーティのアプリケーションやサービスからアクセスされるように設計されているため、多くの場合、従来の Web アプリケーションよりも広範な潜在的脅威にさらされます。また、柔軟性とカスタマイズ性も API が攻撃に対して脆弱である理由の一つです。さらに、API はトークンやその他のタイプの認証を頻繁に使用してアクセスを制御するため、トークンが盗まれたり侵害されたりした場合に攻撃を受ける可能性があります。
API ゲートウェイセキュリティとは
API ゲートウェイは、API コールまたはクライアント要求を管理し、API エンドポイントから応答を返すための単一のエントリーポイントとして機能するソフトウェアのレイヤーです。API ゲートウェイ・セキュリティ・ソリューションは、レート制限とスロットルを実行して、 API が悪用されないようにします。ゲートウェイは、適切なバックエンドサービスおよびフロントエンドエンドポイントへの API コールを認可およびルーティングすることによって API を保護できます。また、API ゲートウェイセキュリティには、認証情報の認証とトークンの検証によるアイデンティティの検証も含まれます。ゲートウェイは API 保護の重要な要素ですが、API を適切に保護するためには API ゲートウェイセキュリティだけでは不十分です。ゲートウェイは API アーキテクチャ全体を可視化して制御することはできません。また、API の誤設定、シャドー API、悪性ボットのアクティビティを特定できない可能性があります。
API セキュリティのベストプラクティス
API 保護の強化には、次のような制御、プロトコル、セキュリティソリューションが役立ちます。
- すべての API の探索と追跡。セキュリティチームが API を認識していない場合、脆弱性を特定して、セキュリティパッチを更新し、適切な API 保護を確立することはできません。
- 脆弱性の特定。セキュリティ・テスト・ツールは、各 API 内に存在する脆弱性を特定するために役立ちます。脆弱性が特定されたら、リスク許容度に基づいて、修復、緩和、設定の修正のために優先順位を付けます。
- 包括的な API セキュリティポリシーの確立。。API 管理チームとセキュリティチームは、API ごとに固有のポリシーを適用するのではなく、すべての API または特定のクラスの API に対するポリシーを設定する必要があります。これにより、個別の API にポリシーを直接コードする必要がなくなります。
- 認証と認可の実行。API を悪用から保護するためには、ユーザーとアプリケーションの認証と認可が不可欠です。
- レート制限とスロットルの実行。これらの手法は、API を呼び出すことができる頻度を定めることにより、 サービス妨害につながる可能性のある悪性リクエストの急増を防止します。
- データの暗号化。API を介して通信される機微な情報を保護するためには、データ暗号化が不可欠です。
- Web Application Firewall（WAF）の設定。ネットワークセキュリティで WAF を使用すると、ローカルネットワーク外からの悪性 API トラフィックに対する保護レイヤーが追加されます。
- API ゲートウェイの実装。優れたゲートウェイはさまざまな保護機能を提供するため、API がどのようにアクセスされているかを分析するのに役立ちます。
- OAuth の展開。OAuth は OpenAPI セキュリティモデルであり、ユーザーが元の認証情報を共有せずにリソースへのアクセスを安全に委任できるようにすることで API を保護できます。
- ふるまい分析の活用。効果的な API 検知および応答ソリューションにより、セキュリティチームは、ふるまい分析を用いてすべての API のふるまいを記録し、異常なふるまいを特定して対応できます。
- B2B API の保護。ほとんどの API 保護は B2C API に重点を置いていますが、極めて機微な情報が、安全であると思われる B2B API と共有される場合があります。ふるまい分析ソリューションは、B2B API を監視し、疑わしいアクティビティに関するアラートを発します。
- データレイクの活用。すべての API アクティビティは、30 日以上データレイクに保存する必要があります。それにより、アラートや潜在的な脅威に関するコンテキストが提供されます。さらに、このデータレイクから調査結果を引き出して、セキュリティ体制を強化することができます。
よくあるご質問（FAQ）
OpenAPI は API を構築するための仕様であり、言語に依存しない標準インターフェースを定義して、ソースコードやドキュメントにアクセスしなくても人間とコンピューターの両方が理解できる方法で、API とその機能を記述します。OpenAPI セキュリティには、API の完全性、可用性、機密性を保護するための認証、暗号化、認可、その他の対策に関するプラクティスが含まれます。
BOLA は Broken Object Level Authorization（オブジェクトレベルの認可の不備）の略であり、発見が非常に困難であるため、API 保護セキュリティにおける最大の脅威と考えられています。この脆弱性を悪用することで、攻撃者は URL パラメーターやリクエストペイロードなどの入力を操作して、不正にデータにアクセスしたりアクションを実行したりできます。
Akamai が選ばれる理由
Akamai はオンラインライフの力となり、守っています。世界中のトップ企業が Akamai を選び、安全なデジタル体験を構築して提供することで、毎日、いつでもどこでも、世界中の人々の人生をより豊かにしています。 Akamai Connected Cloudは、超分散型のエッジおよび クラウドプラットフォームです。ユーザーに近いロケーションからアプリや体験を提供し、ユーザーから脅威を遠ざけます。