ブログ

AIファクトリー向けAPI保護: AIセキュリティへの第一歩

バイロン・マクノートのサムネイル
バイロン・マクノート
2024 年 12 月 19 日公開

AIに非常に関連のある古い諺があります。「千里の道も一歩から」

AIapplicationsとエコシステムは世界中で急速に普及しており、すべての組織がその準備状況を評価することが求められています。 F5 では、AI の道を歩んでいる組織には 2 つのタイプがあると考えています。自動運転車や大規模言語モデル (LLM) などの戦略的投資を通じて差別化されたソリューションを開発している組織と、効率性と組織の革新のために AI を導入して最適化している企業です。 ビジネス リーダーは、生産性を向上させるために生成 AI 機能とアプリを導入することに熱心であり、一方でセキュリティおよびリスク管理のリーダーは、新興 AI アプリと、それらを提供、最適化、保護するためのインフラストラクチャ、ツール、モデル、フレームワーク、および関連サービスの急成長するエコシステムを安全に導入するためのガバナンスを確保しようと奮闘しています。 AI ファクトリーは、AI を活用した差別化製品やサービスを実装するための青写真として登場しています。

それで、AIは誇大宣伝なのでしょうか? 狂乱? 革命? それとも黙示録でしょうか? 将来はまだ分からない。 

一歩引いて全体像を見ると、AI アプリの結合組織は API であることが明らかになります。 実際、私たちが世界中のお客様と話し合う共通のテーマは、「AI の世界は API の世界である」ということです。 API は、AI モデルをトレーニングし、そのモデルを使用するために使用するインターフェースです。 これらは、悪意のある人物がモデルからデータを盗んだり、AI モデルの脱獄や悪用を試みたり、さらにはモデル自体を反転させて盗んだりするために使用するのと同じインターフェースでもあります。 防御側がクラウドにおける API の可視性とセキュリティの重要性、およびマイクロサービスに基づく最新のアプリへの移行を見逃したのと同じように、大きな「ひらめき」の瞬間は、AI モデルを保護するには、それらを提供するインターフェースを保護する必要があるという認識です。

AI を活用したapplicationsの構築と提供において API が中心的な役割を果たすことを考えると、早い段階で API の可視性、セキュリティ、ガバナンスを AI 開発およびトレーニング プロセスに組み込むことが重要です。  また、設計段階で、レート制限やデータ サニタイズなどの通常の使用パターンと制御が組み込まれることも重要です。 このアプローチにより、安全な AI 導入がそれほど難しくなくなります。 生成 AI アプリは特に API に依存しているため、API セキュリティは AIapplicationsを保護するために不可欠です。 こうして、AI の旅の第一歩が始まります。 ここでは、AI セキュリティと AI ファクトリーの安全な導入に API セキュリティが必要な理由について、4 つの重要な主張を紹介します。

主張 #1: AI アプリは最新のアプリの中でも最も最新です

以前の AI ファクトリー シリーズでは、 AI ファクトリーを、大容量で高性能なトレーニングと推論の要件を満たす大規模なストレージ、ネットワーク、コンピューティングへの投資と定義しました。 従来の製造工場と同様に、AI 工場は事前トレーニング済みの AI モデルを活用してロー データをインテリジェンスに変換します。 AI アプリは、API を介して緊密に接続され、高度に分散された、最新のアプリです。

まず、AI アプリは最新のアプリであり、配信、セキュリティ、運用に関して同じよくある課題を抱えており、AI モデルによって配信とセキュリティを必要とする API の数が大幅に増加するという前提から始めます。 

ということで、ミッションは完了です! 大丈夫だよ、ね? 私たちは最新のアプリを安全に配信する方法を知っています。 当社はapplicationセキュリティのベスト プラクティスを確立しており、API を保護するための複雑さを理解しています。 当社には、分散環境全体にわたって包括的な保護と一貫したセキュリティを提供するソリューションがあります。

そんなに急がなくても! GPT をそのままにして、詳細を簡単に説明します。

AI アプリは、最新のアプリ (どちらも基本的に API ベースのシステム) と同じリスクと課題を抱えていますが、トレーニング、微調整、推論、検索拡張生成 (RAG)、AI ファクトリーへの挿入ポイントなど、特定の影響があります。

つまり、AI アプリは、最新のアプリと同様に、高度に分散された性質を持ち、ツールが無秩序に拡散し、ハイブリッドおよびマルチクラウド アーキテクチャ全体にわたって一貫した可視性、統一されたセキュリティ ポリシーの適用、脅威の普遍的な修復を維持するための取り組みが複雑になります。 防御側は、リスクと複雑さのこの「火の玉」と格闘するだけでなく、人間のリクエストのランダムな性質や、予測不可能な AI 応答につながる可能性のある AI が調達したコンテンツの非常に変動しやすい性質、さらにはデータの正規化、トークン化、埋め込み、ベクター データベースへの入力に関する考慮事項にも対処する必要があります。

データを AI ファクトリーに統合すると、全体的かつ接続されたエンタープライズ エコシステムが構築されます。また、これらすべての可動部分の統合とインターフェイスには、堅牢な API セキュリティ体制が必要です。

火の玉の図

今日の企業は、ますます複雑化するハイブリッド マルチクラウド環境全体で、爆発的に増加するアプリと API を管理しています。 F5 では、増大するリスクと複雑さを「火の玉」と呼んでいます。

主張その2: AI アプリは API によって相互接続されます

急速な近代化の取り組みによる API ベースのシステムの台頭により、データ センター、パブリック クラウド、エッジにわたるアーキテクチャが急増しました。 これは、 2024 年のapplication戦略の現状レポートを含む F5 の年次調査で記録されています。 API セキュリティ | API の秘密の生活レポート。

ハイブリッドおよびマルチクラウド アーキテクチャの複雑さは、AI アプリによってさらに増大します。 組織は、多数のAIアプリと基盤となるAIモデルのガバナンス戦略を迅速に評価し、熱心に採用し、最終的にAI-SaaS、クラウドホスト、セルフホスト、エッジホストのいずれかを決定します。 アプローチは、ユースケースやアプリごとに異なる場合もあります。 たとえば、一部のユースケースでは、推論がエッジで実行される場合、実稼働前にデータセンターでトレーニングを行う必要があります。

これらのモデルおよび関連サービスへの接続は、主に API を通じて容易になります。 たとえば、推論用の一般的なサービスへの接続などです。 AI アプリでは、単一の API に最終的に何千ものエンドポイントが存在する可能性があり、API 呼び出しがセキュリティ チームの管轄外のビジネス ロジックの奥深くに埋め込まれる可能性があるため、API の使用量が急増します。 これにより、許容できない複雑さが生じ、リスク管理に深刻な影響が生じます。

結局、クラウドが世界を席巻したのではなく、API が席巻したのです。 そしてAIはすべてを食べてしまいます。 弊社のブログ記事「ハイブリッド、マルチクラウドが企業にとって新たな標準である 6 つの理由」で説明されているように、高度に分散された環境は、パフォーマンス、セキュリティ、効率、精度を保証する AI アプリと関連サービスの展開に柔軟性を提供します。 これは、データの重力に関する懸念にとって特に重要です。 組織の 80% が AI アプリをパブリック クラウドで実行し、54% がオンプレミスで実行していることは驚くことではありません。 アプローチに関係なく、アーキテクチャのあらゆる側面を保護する必要があり、API の保護が最初の出発点となります。 

主張 #3: AI アプリは既知のリスクと新たなリスクの両方にさらされている

AIapplication機能やデータ交換へのゲートウェイとなる API をセキュリティ リスクから保護することが重要です。 同じ脆弱性の悪用、ビジネス ロジック攻撃、ボットによる悪用、サービス拒否 (DoS) のリスクが適用されますが、AI ファクトリー内の新規および変更された挿入ポイント、およびトレーニング、微調整、推論、RAG 中の自然言語処理 (NLP) インターフェイス、プラグイン、データ コネクタ、ダウンストリーム サービスによる LLM へのリスクについても追加の考慮事項があります。 さらに、DoS などの既知の攻撃には追加の考慮事項があり、ボリューム型 DDoS や L7applicationDoS の緩和策では、モデルDoS のリスクを完全に相殺することはできません。 AI アプリには説明可能性のパラドックスもあり、幻覚、偏見、偽情報を相殺するための追跡可能性の重要性を強調しています。

そして、攻撃者は手をこまねいているわけではありません。 生成 AI は攻撃を民主化し、サイバー犯罪者や国家による攻撃の高度化を促進します。 LLM エージェントは、Web アプリや API を自律的にハッキングできるようになりました。たとえば、脆弱性を事前に知る必要がなく、ブラインド データベース スキーマ抽出や SQL インジェクションなどの複雑なタスクを実行できます。

新しい AI リスクが大きな話題を呼んでいる一方で、AI ファクトリーにおける API セキュリティの重要性は強調しすぎることはありません。 緊急です。 AI アプリの API サーフェスの増加は驚異的です。 すべての CISO は、AI ガバナンス プログラムの一部として API セキュリティを組み込む必要があります。これは、あらゆるCISO サバイバル ガイドの核となるマントラが「見えないものは保護できない」である必要があるためです。 AI アプリの背後にあるインターフェースのインベントリがない場合、脅威モデルが不完全になり、セキュリティ体制にギャップが生じます。

主張 #4: 守備側は適応しなければならない

AIapplicationsは動的、可変的、かつ予測不可能です。 AI アプリを安全に導入するには、有効性、堅牢なポリシーの作成、自動化された操作をより重視する必要があります。 検査技術はセキュリティにおいて重要な、進化し続ける役割を果たします。

特に、AI アプリとエコシステム内の API セキュリティについては、組織は、すでに広く導入されているインバウンド セキュリティ制御に加えて、アウトバウンド API 呼び出しと関連するユース ケースのセキュリティを設計することで、サードパーティ API の安全でない使用の可能性の増加を相殺する必要があります。 たとえば RAG ワークフローからのサービス間トラフィックや東西トラフィックの増加を考えると、ボット管理ソリューションは「人間」または「マシン」の識別だけに頼ることはできません。 また、LLMapplicationsのサプライ チェーンは脆弱であり、トレーニング データ、モデル、デプロイメント プラットフォーム (多くの場合、サード パーティから提供され、改ざんやポイズニング攻撃によって操作される可能性があります) の整合性に影響を与える可能性があるため、データ センター、クラウド全体、エッジ、コードからテスト、運用まで、あらゆる場所でセキュリティ制御を実装する必要があります。  

AI ゲートウェイ テクノロジーは、セキュリティ チームとリスク チームが LLM への迅速なインジェクションや機密情報の漏洩などのリスクを軽減する上で重要な役割を果たしますが、AI セキュリティへの取り組みの第一歩は、AI アプリのライフサイクル全体にわたってセキュリティを組み込むことで、AI アプリと AI エコシステムを接続する API を保護することから始まります。

AI リファレンス アーキテクチャ内の API セキュリティ

フロントエンドapplicationと推論サービス API 間のやり取りの保護、AI-SaaS アプリとのユーザーやり取りの検査、プラグイン、データ コネクタ、ダウンストリーム サービス間の接続の保護など、AI アプリと AI ファクトリーの安全な導入は API セキュリティにかかっています。

F5 プラットフォームは、継続的な API 防御と一貫したセキュリティ体制を提供し、セキュリティ チームとリスク チームに AI ファクトリーを安全に構築するために必要な機能を提供することで、ビジネス リーダーが自信を持ってイノベーションを起こせるようにします。

F5 AIリファレンスアーキテクチャ

F5 の AI への注力はこれで終わりではありません。F5が AI アプリをあらゆる場所で保護し、配信する方法をご覧ください。