API セキュリティにゼロトラストフレームワークを使用するには?

API セキュリティを多層防御からゼロトラスト モデルに拡張する方法の説明 「パンデミックにより、あらゆる種類のデジタルトランスフォーメーションプロジェクトを可能な限り迅速に実行することが企業に非常に緊急に迫られました。これが、この攻撃の急増の背後にある要因であることはほぼ間違いありません。」 — 、 のテクノロジー担当ディレクター。 ピーター・クリメック Imperva DYKT API は 20 年以上使用されています。それ以来、API は劇的に進化しました。API を使用して特定のニーズに取り組む限られた企業から、最近では、あらゆる規模の DevOps 環境における無限のユースケースのコレクションに至るまでです。 API は、アジャイル開発、サービスによる顧客とパートナーの接続、およびデジタル トランスフォーメーション イニシアチブの強化など、アプリ開発全体で見つけることができます。 しかし、サイバーセキュリティに関しては、 の調査によると、 。しかし、普及が進むにつれて、API はこれまで以上に機密データを公開するようになり、攻撃の貴重な標的となっています。 ProgrammableWeb 2019 年以降、毎月平均 220 の新しい API が追加されています この投稿は、多層防御からゼロ トラスト モデルまで、API セキュリティの要件をマッピングする方法の紹介です。 背景 - API セキュリティの現状 API を保護する方法に入る前に、API セキュリティの現在の脅威の状況を見てみましょう。 Salt Security による State of API Security Report によると: 過去 12 か月で API 攻撃が 681% 増加 回答者の 95% が過去 1 年以内に API セキュリティ インシデントを経験しています 回答者の 34% が API セキュリティ戦略を欠いている 調査回答者の 62% が、API のセキュリティ上の懸念により、新しいアプリケーションの展開が遅れていることを認めています つまり、ほとんどの企業は API ベースの攻撃に対して準備ができていないことがわかります。また、Web アプリケーション ファイアウォール (WAF) や API ゲートウェイなどの既存のセキュリティおよび API 管理ツールへの依存は、セキュリティ インシデントを効果的に防止し、セキュリティに対する誤った認識をもたらした可能性があります。 Shift-Left はどうですか? このレポートは、少なくとも API セキュリティに関しては、シフトレフト戦術が役立たないことを強調しています。回答者の 50% 以上が、開発者、DevOps、または DevSecOps チームが API セキュリティを担当していると述べています。導入前の取り組みにより多くの費用を費やしている企業には、次のようなものがあります。 安全なコーディングのベスト プラクティス、 コードスキャン、および 手動テスト ただし、 、これらの DevOps セキュリティ プラクティスは重要ではあるものの、十分ではないことを証明しています。 85% は、セキュリティ ツールが API 攻撃の防止に効果がないことを認めており では、組織は API 攻撃を防御するためにどのような保護を構築または採用する必要があるでしょうか?この質問に答えるには、まず、API に対する一般的な攻撃を理解する必要があります。 現在の脅威の状況 に関する最近のレポート では、API セキュリティの脅威の原因は次のとおりです。 Google Cloud による API セキュリティ API の構成ミス (40%)、 時代遅れの API、データ、およびコンポーネント (35%)、 スパム、悪用、ボット (34%)。 「API の設定ミス」または「セキュリティの設定ミス」は、カテゴリとして最も多く特定されている脅威源です。 による別の調査によると、 271% も跳ね上がりました。ハッカーは、RCE または RFI 攻撃を使用して、会社の情報を盗んだり、サーバーや Web サイトを改ざんしたり、さらには Web サイトを制御したりします。 Imperva Research Labs 最も重大な攻撃はリモート コード実行 (RCE) またはリモート ファイル インクルージョン (RFI) で、 OWASP API セキュリティのトップ 10 によると、その他の API の脆弱性は次のとおりです。 API DDOS ファンアウト、 ゼロデイ API 攻撃、 盗まれた資格情報、 境界違反、 違反の横方向の動き、 出口でのデータ漏洩、または リソースハイジャック サイバーセキュリティ: API は新しいエンドポイント 前述のように、API のセキュリティ リスクが増大する最初の理由は、環境内の多くの API の 。たとえば、Kubernetes アプリケーションには数百のポッドとマイクロサービスがあります。それぞれが 6 つ以上の API を管理しています。 (これは、DevOps 環境での典型的なシナリオです)。 採用の急増です ここで、これらのマイクロサービス ワークロード (したがって API 呼び出し) は一時的なものであり、クラウド全体で実行され、多言語で記述され、さまざまなプロトコルを使用することを追加します。つまり、API は複雑な環境を作り出し、セキュリティ チームが API 操作を監視するのは困難です。 第二に、API は外部に公開されることを意図したものではありませんでした。しかし、これがネットワーク プロトコル スタック内で見つかった脆弱性に直面したものです。それらの開発者は、自分の作品が今日の規模で採用されるとは想像もしていませんでした。その結果、API には固有の脆弱性とリスクが組み込まれています。 第 3 に、攻撃と侵害はますます巧妙化しており、特に認証および承認後の段階で実行されるものは顕著です。それらは、API データ ペイロード内でもより深遠です。 したがって、認証と承認を超えたセキュリティ、さらにはアプリケーションと API データ ペイロード レイヤーに目を向ける必要があります。そのための 1 つの方法は 、API セキュリティを従来のエンドポイント セキュリティに類似したものと考えることです。 DiD（多層防御）、再び！ セキュリティの問題は、コンピュータ以外の日常生活でも発生します。人類の歴史の初期段階から、さまざまな国が複数の防御メカニズムと要塞を探求し、実践してきました。これらの経験とアイデアは、エンドポイント、ネットワーク、および API セキュリティにも適用されます。 Endpoint Software が城に似ているとしましょう。 身元認証は司令官の身元証明と同等であり、 ハニーポット (または戦争のおとり) は、注目を集めるターゲットから攻撃者を引き離します。 これらの戦争戦略の中で最も効果的な方法の 1 つは、多層防御 (DiD) です。 DiD アプローチは、次の 2 つの領域に分けることができます。 境界防御 (マルウェア対策シグネチャ) 侵入検知/防止 (IDS/IPS/EDR) これらの DiD 領域を使用した API セキュリティについて、1 つずつ説明します。 1# 境界防御 境界防御は、防御の最も基本的なタイプです。ほとんどすべての企業が境界防御に投資しています。エンドポイント セキュリティでは、署名と IP 拒否リストを使用して、 既知の攻撃方法から防御します。 保護の最前線として、このレイヤーは、確かな技術的ノウハウやハッカーの考え方を持たない未熟な個人によって開始された、標的を定めていない、すべての攻撃の 90% を阻止することを目指しています。このシナリオでは、 境界防御はこれらの無差別攻撃に十分に耐えることができます。 API セキュリティでは、WAF はこの分野で優れた仕事をしています。境界防御のための標準機能を提供します。 · IP許可リストと拒否リスト、 ・WAFルールエンジン、 · レート制限、および · フォールト注入/ファジング。 組み合わせると、ほぼすべてのコモディティ攻撃をブロックできます。 2# 侵入検知 (++) セキュリティの可視性は、攻撃防止の重要な要素です。ハッカーが境界を突破した後、悪意のある攻撃に関連している可能性が高いファイル/プロセス/トラフィックを特定する適切な方法が必要です。エンドポイント ソフトウェアでは、 を使用して、フロント ゲートを通過するすべてのリクエストを検査します。 ホストベースの IDS/IPS APT 検出や機械学習などの他の検出方法は、標的型攻撃に対してより直感的に評価できる可能性があります。 行動分析を実装するその他の典型的な方法は次のとおりです。 · ハニーポット、 · EDR (エンドポイントの検出と応答)、および · 脅威インテリジェンス (ファイルとプロセス)。 これらすべての方法の中で、ハニーポットは (戦争が始まって以来) 最も古いものの 1 つです。価値の高いターゲットをトラップ/おとりに誘い込むことで、敵の行動を分析し、位置を特定することさえできます。今日、私たちはこれらの戦術を採用し、それらを欺瞞技術に変えています。 現代の世界では、API セキュリティ ソリューションは前述の手法の組み合わせを提供します。たとえば、ハニーポットで収集されたアーティファクトは、WAF または Web アプリケーションと API 保護 (WAAP) の消費のために脅威インテリジェンス フィードに送信できます。このレイヤーには、可視性を高め、攻撃を阻止する速度を高めるための同様の手法があります。 · ネットワーク ハニーポット · NDR (ネットワーク検出と応答)、および · 脅威インテリジェンス (ペイロードとネットワーク)。 ボットを使用して「資格情報の詰め込み」攻撃を実行することも、一般的な攻撃戦術の 1 つです。価値の高い資産を盗もうとします。この戦略は、漏えいした電子メール/パスワードなどのログイン情報を取得する方法を見つけてから、ネットワーク ロケーションへのアクセスをバッチで試行することです (横方向の移動)。 Credential Stuffing に対抗するための最も効率的な防御策は、ソースからのものです。実際のユーザーからボットを識別して、ボットによるすべてのリクエストを傍受します。 そのため、一部の AppSec ツールには、API セキュリティの一部として特定の種類の動作検出であるアンチボット機能も装備されています。 API セキュリティがゼロトラストと出会うとき DiDが役に立たないと言っているのではありません。コモディティ攻撃から組織を保護する WAF などの API およびアプリケーション セキュリティ ソリューション。ただし、前述のように、API は複雑な環境を作成し、構成ミスは問題を悪化させます。 不明な境界では、DiD アプローチ以上のものが必要になる場合があります。ゼロトラストは基本的に、攻撃者にとってあらゆる場所に障害物を置き、攻撃者が環境内を横方向に移動することを不可能にします。 ゼロ トラストは、包括的なセキュリティ フレームワークと戦略です。すべての端末、BYOD (Bring Your Own Devices)、サーバー、API、マイクロサービス、データ ストレージ、および内部サービスに対して、厳格で統一された検証手順が必要です。 ゼロ トラストの主なアイデアは、API を含む です。内部アクセスの外部要求、携帯電話または PC、API 呼び出しまたは HTTP 要求、一般の従業員または CEO のいずれであっても、信頼できるものはありません。 アプリケーションのすべてのパスで、一元化された実施ポイントを複数のマイクロ チェックポイントに変えること アプリケーションを停止したり遅くしたりせずにこのような目標を効果的に達成するには、 が決定的な重要なステップになります。 オーケストレーションと自動化 オーケストレーションと自動化がゼロ トラスト API セキュリティにとって重要な理由 ZTA、NIST SP800–207 |著者による画像 この 2 つの必要性を説明するために、ゼロ トラスト アーキテクチャの 1 つの柱で 詳しく見てみましょう。この防御方法は、空港のチェックポイントでパスポートと ID カードを提示してアルコールを購入するのと似ています。 あるユーザー/デバイス アクセスの信頼を 対応する ID と権限がなければ、関連するシステムに入ることができません。これは、いくつかの主要な認証機能を提供するため、API ゲートウェイが強力になる場所です。 キーの自動ローテーション OKTA や Auth 2.0 などの複数の認証システムとの統合 トラフィックの TLS および mTLS 暗号化をサポート ユーザーとデバイスの信頼には、次の 2 つのコア コンポーネントがあります。 ID およびアクセス管理 セキュリティが統合された API ゲートウェイ 空港や高速鉄道など、 。また、すべての輸送ハブとの間のすべてのルートを理解し、セーフガードを実装する必要があります。 すべての輸送ハブに識別機器を追加することを想像してみてください 大企業では、数百のシステム、数万の API とマイクロサービス、数十万のクライアントが存在します。無制限のリソースと時間がない限り、DevOps、セキュリティ、またはアプリケーション チームは、最新のアプリケーションで何十万ものマイクロ ID チェックを定義して手動で追加することはできません。 ゼロ トラスト 他のすべての柱も、採用のために同じロジックを必要とします。必要なのは、次のようなソリューションです。 アーキテクチャ、アプリケーション、ワークロード、およびデータの モダンな建築を採用し、 異種環境で動作し、 これらのリスクを（コモディティだけでなく）軽減し、 マルチクラウド環境全体で自動化された方法でこれらすべてを実行します (オプション) 技術の俊敏性と創造性を可能にするオープンソース。 アイデア ゼロ トラスト API セキュリティはどのようなものですか? API で複雑な異種環境を採用するには、ゼロ トラスト API セキュリティ ソリューションを 。次に例を示します。 複数の形式で展開できる必要があり、さまざまな設定をサポートする必要があります Dockerコンテナ、 スタンドアロンのリバース プロキシ、 Web/アプリケーション サーバーのエージェント、または Kubernetes Ingress Controller に組み込まれています。 クラウドと最新のアプリケーション アーキテクチャのサポートにより、自動化とスケーラビリティが考慮されます。 ただし、オーケストレーションを維持するには、「エージェント」(またはマイクロ強制ポイント) 展開できる必要があります。 を既存のアーキテクチャを変更せずに既存のアプリケーションの上に 展開とアーキテクチャのフォーム ファクターを考慮した上で、セキュリティ レベルが低下しないことも不可欠です。真のゼロ トラストを採用するには、 。 セキュリティ処理を他のクラウドや分析用のクラウド サンドボックスなどのエンジンに送信することなく、ローカルで行う必要があります 外部関係者が当社の管理下にない場合、データ/ネットワーク アクセスの信頼を検証することは困難です。ローカルで行うことには、次のような利点があります。 機密データは、保護された環境から離れません。 証明書と秘密鍵をサード パーティと共有する必要はありません。 トラフィックを処理するためのサードパーティの稼働時間に依存しません。 理想的には、オーケストレーターがこれらのエージェントを管理し、次の操作を処理できる一方で、アプリケーション環境に注入できるソリューションが必要です。 最後の部分は、オーケストレーションを検討することです。 エージェントの登録/登録解除 ポリシーの更新 構成の更新 ソフトウェアの更新 ロギングと データ同期。 要するに、ゼロトラステッド API セキュリティは、最新のアプリ環境に注入するためにさまざまな形である必要があります。一方、最適なソリューションは、オーケストレーションと、従来のソリューションが提供できるすべてのセキュリティ機能を提供できる必要があります。 ご存知のように、ゼロ トラストは完璧ではありません。ゼロトラスト ソリューションは、ゼロデイ攻撃やソーシャル エンジニアリング攻撃を完全に防御することはできませんが、攻撃対象領域と影響を大幅に減らすことはできます。 ゼロ トラスト アーキテクチャについて学ぶには: 。 ゼロ トラスト セキュリティ アーキテクチャの紹介 - 製品ではなく概念です 最後の言葉 API は、最新のアプリケーションの中枢神経系となっており、アプリケーションのある部分から別の部分へ、またはあるアプリケーションから別のアプリケーションへと重要な情報やデータをもたらします。そのため、アプリケーションを保護する際には、API セキュリティを優先する必要があります。これは、世界中のユーザーがソフトウェア コンポーネントや機密データにアクセスするパブリック API に特に当てはまります。 ゼロ トラスト フレームワークを採用すると、単一のセーフガードからさまざまな柱 (ユーザー、デバイス、ネットワーク、アプリケーション、およびデータ) に焦点が移ります。これにより、境界の内外を問わず、API アクセスのすべての部分が最小限の特権アプローチの下にあり、継続的に監視されていることを確認できます。 読んでくれてありがとう。 InfoSec があなたと共にありますように🖖。