API攻撃から自分を守る方法

現代のクラウド戦略は、ホストされたサービスへの制御されたインタラクティブなアクセスのためにAPIを多用しています。しかし、そのアクセスが制御されるのは、APIが安全に実装され、悪用されない場合だけです。

Web API

アプリケーションプログラミングインターフェース（API）は、ソフトウェアが他のソフトウェアと話すことを可能にします。それには一連の仕様が必要です。APIエンドポイントが提供する関数の文書化されたセットと、それらの関数を使用するためにAPIクライアントが行うべきルールが必要です。APIによって返されるデータの種類と形式は、各関数について定義されなければなりません。通常、APIへのアクセスを制限したいと思うので、APIクライアントは何らかの方法で認証を行う必要があります。制限されたAPIでは、リクエストはAPIエンドポイントがリクエストが正当であると確認した場合にのみ処理されなければなりません。

すべてのソフトウェア開発において、設計段階からのセキュリティ手法は、「まず作って、後からセキュリティを確保する」アプローチよりもはるかに優れています。Peloton APIの惨事はこれを完璧に示しています。今は修正された欠陥のあるAPI実装が、認証されていないAPIコールにサービスを提供することを可能にしていました。

誰でもペロトンの顧客に関する個人データを引き出すことができました。最初の「修正」は、APIをペロトンの所有者に制限するものでした。これはわずかに改善されただけでした。最終的な修正が行われたことで、ペロトンのユーザーのデータはようやくプライベートになり、ユーザーが明示的に共有することを選択しない限り、他人に見られることはありません。

設計が不十分なAPIや弱いAPIの例は他にもたくさんあります。Facebookは、APIが電話番号を使ってデータベースを検索することを誰でも可能にしたため、5億3,300万人のユーザーの個人データを公開しました-その検索速度は1分あたり最大1000件です。

インターネットトラフィックの80％以上はAPIトラフィックです。それは多くのAPIを意味します。2021年半ばの時点で、オープンウェブアプリケーションセキュリティプロジェクト（OWASP）のトップ10のセキュリティリスクは数年間変わっていません。残念ながら、同じ脆弱性につながる同じ間違いが繰り返されています。そして、それはサイバー犯罪者にとって無視できないほど魅力的です。

開発の利害関係者

APIはしばしばウェブサイトやモバイルアプリよりも保護が不十分です。パフォーマンス要件のために、開発チームはそれらをスリムで効率的に作ることに集中せざるを得なくなります。あまりにもスリムなため、APIを保護するためのコードがほとんど、あるいは全く含まれていないことがあります。設計が不十分または実装が不適切なAPIには、悪用される可能性のある弱点が存在します。適切な改善策は、上からバンデージを貼って穴を塞ごうとすることではありません。コード、あるいはAPIに組み込まれたビジネスロジックを修正する必要があります。

多くのソフトウェアコンポーネントがAPI呼び出しを介して相互に通信する場合、たとえばマイクロサービスのように、ビジネスレイヤープロセスのエラーを特定するのが非常に難しくなります。あなたのコードはユニットテスト、回帰テスト、その他のテストに合格するかもしれません。クラッシュが発生しないかもしれません。すべてのログはクリーンです。しかし、それは論理が正しいことを意味するわけではなく、すべての潜在的な脆弱性が考慮されているわけでもありません。セキュリティチームと開発チームを一緒にすることで驚くべき洞察が得られることがあります。

開発チームは、要求される機能を提供するAPIを書く責任があります。セキュリティチームは、APIを介してサービスされるデータを保護する責任があります。両者は、開発プロセスの成功において利害関係者です。開発者はセキュリティ、脅威、攻撃についてセキュリティチームのように考えることはありません。なぜ両方の専門知識を問題に生かさないのでしょうか？

攻撃の種類

遭遇する一般的な攻撃タイプは、その攻撃手法に応じてグループ化することができます。

クレデンシャルスタッフィング: これはパスワードのブルートフォース攻撃に似ていますが、ユーザーアカウントのパスワードの代わりにAPIクレデンシャルを使用します。
インジェクション攻撃: インジェクション攻撃では、サイバー犯罪者がAPIリクエストにコンピュータ命令を追加し、埋め込まれた命令がAPIエンドポイントに作用するようにします。SQLインジェクションは、SQLデータベースを悪用する攻撃です。しばしば、API呼び出しのどのテキスト要素がSQL文に含まれるかを簡単に特定できます。これらのAPI関数呼び出しにSQL文を追加すると、それらのSQLスニペットがAPIエンドポイントのSQLサーバーによって実行される可能性があります。クロスサイトスクリプティングも同様の攻撃で、埋め込まれた命令は通常JavaScriptなどのスクリプト言語で書かれています。
分散型サービス拒否攻撃（DDoS）: これらの攻撃は、ウェブサイトにトラフィックを押し寄せて正当なリクエストへのサービスを妨げるDDoS攻撃に非常に似ています。APIエンドポイントを対象としたDDoS攻撃は、脅威のある行為者の間で人気が高まっています。
中間者攻撃 (MitM) これらの攻撃は、本物の無垢なAPIクライアントとAPIエンドポイントの間のトラフィックを傍受することに依存しています。APIの認証情報がキャプチャされると、それを使用して本物のAPIクライアントを装って再接続することができます。時には、本物のクライアントから行われるAPIコールが変更され、APIエンドポイントが実際のクライアントが望むことではなく、攻撃者が望むことを行うようになります。

APIを保護する

ITインフラの一部を確保しようとしているとき、特定の新しいソリューションを探すのは魅力的かもしれません。しかし、サイバーセキュリティの基本を忘れないでください。

対処していることを定量化する

自分が持っているものがわからなければ、それを管理することはできません。自分が作成したものであろうとなかろうと、使用しているすべてのAPIを特定し、特徴づける必要があります。API監査の結果は、APIの使用を簡素化または合理化する機会を明らかにするかもしれません。また、更新または停止が必要な古いAPIや孤立したAPIも強調されるでしょう。

APIが何であるか、それらが何をするのか、どのように保護されているのか、そしてどのように強靭に作られているのかがわかったら、APIセキュリティ戦略を文書化することができます。セキュリティ主導の開発のための基本ルールを設定する機会を活用し、APIのロードマップを計画してください。

API呼び出しを通じてアクセスできるデータは何ですか？それは個人を特定できる情報ですか、それとも他の方法で機密ですか？そのデータの分類は何ですか？あなたのデータ保護ポリシーが正しく実施されているなら、それらにはすでにこの情報が含まれているでしょう。データへのアクセスを厳密にレビューしてください。必要以上のデータを公開していますか？

APIを簡潔に作成する

データ消費者にとってAPIを豊かな体験にしようとすることは、過剰な報告につながり、APIエンドポイント自体の詳細を無駄に公開することになります。データサブジェクト、暗号化キー、認証トークンに関する情報は、冗長なAPIによって漏洩されたことがあります。より考慮された安全なアプローチは、APIクライアントが要求された機能を満たすために必要な最小限のデータを返すことです。

これは、サイバーセキュリティの基本である最小権限の原則に関するものです。ユーザー、プロセス、IoTデバイス、またはあなたのITとやり取りするその他のものには、その役割や機能を果たすために必要な最小限の権限のみを付与すべきです。あなたのAPIにも同様のことを行ってください。

暗号化を使用してください

APIトラフィックをSSLの後継であるTSLを使って暗号化してください。データの価値に基づいて行動しないでください。APIクライアント認証トークンも保護していることを忘れないでください。攻撃者はデータに興味を持たないかもしれません。しかし、認証トークンを取得すれば、APIを利用してシステムのさらなる手がかりを引き出し、別の攻撃を仕掛ける可能性があります。

認証および入力値

明らかに、強力な認証システムが必要です。車輪を再発明しないでください。可能な限り、OAuth2.0のような認識された解決策を使用してください。内部APIは認証が必要ないと感じるかもしれません。しかし、内部APIが誤って公開されることがないと保証できますか？別のプロジェクトで再利用される可能性があるためです。

APIからの入力を事前に検証せずに盲目的に受け入れてはいけません。内容の不正Formatting、埋め込まれたスクリプト、及びオーバーラン攻撃の有無を確認してください。

接続要求の頻度に注意し、適切なレート制限対策を講じてください。高頻度の訪問者は、侵入しようとしているのか、それともデータベースからデータを抜き取ろうとしているのか、要求ごとにですか？

アライドテクノロジーズ

ウェブアプリケーションファイアウォール（WAF）は、保護されたリソースへのトラフィックをフィルタリングし、監視することで、ウェブサイト、ホストされたアプリケーション、およびAPIを保護します。WAFは、クロスサイトスクリプティングやSQLインジェクションなどの攻撃を検出することができます。WAFはアプリケーション層の保護技術（ISOモデルのレベル7）であり、ウェブサイトやAPIのセキュリティに対するすべての解決策ではありません。WAFは、層状の防御対策の一要素として展開するのが最も効果的です。

APIゲートウェイは、APIエンドポイントとAPIクライアントの間に座っています。彼らはクライアントとAPIエンドポイントの間でAPIリクエストを仲介し、時にはリクエストを異なるバックエンドマイクロサービスによってサービスされる小さな部分に分割することがあります。応答は収集され、APIクライアントに返されます。APIゲートウェイは、認証およびレート制限機能と統合したり、提供したりすることができます。高可用性と自動スケーリングを提供するSoftware-as-a-Service APIゲートウェイもあります。

APIは最前線にいます

クラウドとマイクロサービスの止まらない成長とともに、APIはサイバー攻撃の最前線に置かれています。サイバー犯罪者は、有利な条件が整った場合に活動することを好みます。これほど多くのAPIが存在する中で、その多くが適切に保護されていないか、あるいは全く保護されていないのは避けられません。あなたのAPIがそのような状態にならないようにしましょう。