※本記事は、AWS re:Invent 2024にてCrowdStrikeが提供したセッション「Redefining security for the cloud AI era (AIM111)」の内容を基に作成されています。このセッションでは、クラウドAI時代におけるセキュリティの課題と解決策について解説されています。セッションの詳細情報やフル動画は https://www.youtube.com/watch?v=hY7QlFyavJM でご覧いただけます。本記事では、セッションの内容を要約・構造化しておりますが、内容の正確性を保証するものではありません。より詳細な情報や完全な文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。AWS re:Inventについての詳細は https://go.aws/reinvent からご確認ください。なお、本セッションはAWSパートナーであるCrowdStrikeによって提供されたものです。
1. はじめに
1.1. セッション概要
このセッションは、クラウドAI時代におけるセキュリティの再定義について説明しています。AIを採用して速度と革新性を高めることは諸刃の剣です。企業は競争力を維持するためにこれらの技術を迅速に受け入れる必要がある一方で、AI関連のリスクからも保護しなければなりません。
本セッションでは、現代のクラウドセキュリティソリューションがいかにAI関連の主要リスクに対応し、AIモデルの包括的な可視性を提供し、シャドーAIを検出し、安全な構成を確保し、機密データを保護し、厳格なセキュリティとプライバシー規制へのコンプライアンスを確保すべきかを探ります。
このプレゼンテーションはAWSパートナーであるCrowdStrikeによるもので、クラウドAI時代のセキュリティをいかに再定義し、AIイニシアチブを強化し、リスクを低減し、組織が自信を持って革新できるようにするかについての洞察を提供します。
1.2. 発表者紹介
発表者はCrowdStrikeのプリンシパルプロダクトマネージャーであるSameerさんです。Sameerさんは、顧客がAWS上のクラウドワークロードを使用し、安全に保つためのセキュリティ製品の構築に取り組んでいます。彼は主にクラウド環境における大規模言語モデルを活用したアプリケーションのセキュリティに焦点を当てた専門知識を持っています。このセッションでは、AI採用のトレンド、セキュリティ課題、そして企業がAIテクノロジーを安全に導入するための方法について解説します。
2. AI採用の動向
2.1. 企業におけるGen AI利用状況
Sameer：私たちの調査では、今日、企業の60%以上がすでに生成AIアプリケーションや大規模言語モデルベースのアプリケーションを自社環境内で使用し始めていることがわかっています。これは驚くことではありません。これらの技術が提供する膨大な種類のユースケースを考えると当然のことです。
カスタマーサポート用のチャットボットから、マーケティングや営業アプリ、旅行代理店アプリまで、そのユースケースは驚異的です。セッションの冒頭でも「生成AIアプリケーションを実験段階から顧客向けの本番環境に導入している方はどれくらいいますか？」と質問したところ、かなりの数の手が挙がりました。これは企業のAI採用における積極的な姿勢を表しています。
この技術の活用方法を見つけ出そうとしている企業が多いことは明らかです。特に生産性の向上と顧客体験の改善という点で大きなメリットが見られているため、今後もこの傾向は加速していくでしょう。
2.2. セキュリティポリシー実装の現状
Sameer：しかし興味深いのは、その一方で50%以上の企業がこれらの生成AIアプリケーションに対する適切なセキュリティポリシーを持っていないか、セキュリティポリシーの実装をまだ開始していないということです。
セッションの冒頭でも質問しました。「生成AIに特化したセキュリティ管理やセキュリティプログラムを実装している、あるいは実装プロセス中の方はどれくらいいますか？」こちらにも多くの手が挙がりましたが、AIの採用率と比べるとそのギャップは明らかです。
企業がAIの導入を急ぐあまり、適切なセキュリティ対策の実装が後回しになっている現状が見えてきます。これは非常に懸念すべき状況です。なぜなら、この技術が持つ独自のリスクに対処するためには、従来のセキュリティアプローチだけでは不十分だからです。この状況を改善するために、私たちはAI特有のセキュリティフレームワークとソリューションの開発に取り組んでいます。
2.3. 今後の展望と市場予測
Sameer：過去1年間でのこの採用の急速な進展は、まだ始まったばかりです。企業が実感している生産性の向上や、これらのアプリケーションがもたらす優れた顧客体験を考慮すると、今後3年間でAIの採用曲線は指数関数的に増加することが予想されます。
いくつかの予測によると、AIサービスとソフトウェア自体への支出は3,000億ドル以上に達する見込みです。この数字は、生成AIが企業のITインフラストラクチャとビジネス戦略において中心的な位置を占めるようになることを示しています。
この規模の採用と投資が進む中で、セキュリティの重要性はさらに高まります。今日、適切なセキュリティ対策なしにAIを採用している企業は、将来的に大きなリスクに直面する可能性があります。私たちはその課題に対応するためのソリューションを提供することに注力しています。
3. AI利用におけるセキュリティ上の考慮事項
3.1. AIモデルの安全性
Sameer：AI採用のトレンドと急速な普及ペースを考えると、このようなアプリケーションを使用する際のセキュリティ上の考慮事項について考えてみましょう。まずAIモデルの安全性から始めます。
顧客がAIシステムを構築する際、顧客体験の各ステップにおいて安全性、透明性、公平性、堅牢性を優先したいと考えます。これは、モデル自体が意図しないバイアスから解放され、敵対的攻撃に耐えることができ、また新たな規制フレームワークから求められる倫理的・法的基準を維持することを意味します。
つまり、厳格なテスト、モニタリング、そしてモデル自体にガードレールや他のリスク軽減戦略を追加する必要があります。これらの対策は、モデルが予測不可能な振る舞いをしたり、有害な出力を生成したりすることを防ぐために不可欠です。
AIモデルの安全性は、単なる技術的問題ではなく、ビジネス上の重要な懸念事項です。安全でないAIモデルは、企業の評判を損なう可能性があり、また法的・規制上のリスクをもたらす可能性もあります。そのため、AIモデルのセキュリティと安全性への投資は、長期的なビジネス戦略の一部として考える必要があります。
3.2. 機密データの管理
Sameer：モデルを構築する際、多くの企業はモデルを関連性のあるものにするために微調整データを使い始めています。これは内部の独自データであり、私たちが行いたいのはそのデータのガバナンスを確保し、適切なアクセス制御が実装されていることを確認することです。
これは非常に重要な点です。企業は自社の価値あるデータを使用してAIモデルをカスタマイズしていますが、そのデータが適切に保護されていなければ、知的財産や企業秘密が危険にさらされる可能性があります。
データガバナンスには、誰がデータにアクセスできるのか、どのようにそのデータが使用されるのか、どのように保護されるのかを明確に定義することが含まれます。適切なアクセス制御がなければ、機密情報が権限のない人々に公開される恐れがあります。
私たちは顧客と協力して、AIモデルの訓練や微調整に使用されるデータセットのセキュリティを確保するためのベストプラクティスを実装しています。これには、データの分類、暗号化、アクセス制限などの基本的なセキュリティ対策が含まれます。
3.3. インフラストラクチャの保護
Sameer：もちろん、これらすべてはどこかで実行されています。モデル自体はコンテナ化されていれば自分で構築しているものであり、何らかのコンピューティングリソース上で実行され、アプリケーション自体を補完する追加サービスがあります。そこでインフラストラクチャをどのように保護するか、クラウドで実行しているのか、あるいはEKS Anywhereのようなサービスで実行しているのかにかかわらず、インフラストラクチャ自体を敵対者から保護する方法を考える必要があります。
これは非常に重要な側面です。最高のAIモデルを持っていても、それが実行されるインフラストラクチャが脆弱であれば、全体のセキュリティが損なわれます。クラウド環境でも社内環境でも、基盤となるインフラストラクチャの保護は欠かせません。
特にコンテナ化されたAIワークロードの場合、コンテナ自体のセキュリティ、オーケストレーションレイヤー、ネットワークセキュリティ、そしてホストシステムのセキュリティなど、複数の層での保護が必要です。これらの要素がすべて適切に保護されて初めて、AIアプリケーション全体を安全に運用することができます。
3.4. プライバシーに関する懸念事項
Sameer：最後に重要なのは、プライバシーに関する懸念です。カスタムデータでモデルが調整されるようになり、アンケートやその他の手段から入ってきたデータでモデルが構築されるようになると、開発者とセキュリティチームは次のようなことを考慮する必要があります。データをどのように匿名化するか、GDPR関連の懸念にどう対処するか、データ露出をどのように最小限に抑えるか、開発者が顧客データにアクセスできないようにアクセス制御をどのように実装するかなどです。
そして新たに現れている傾向としては、顧客データのプライバシーを確保するための規制やフレームワークがますます増えてきています。そこで、これらの管理策をどのように実装するかが大きな懸念事項になります。
プライバシー保護は単なる法令遵守の問題ではなく、ユーザーの信頼を獲得し維持するための基本です。特に個人データを処理するAIシステムでは、データの収集から処理、保存、そして最終的な削除に至るまで、すべての段階でプライバシーを考慮する必要があります。
これらのプライバシー懸念に適切に対処しないと、データ漏洩、規制違反による罰金、そして最も重要なユーザーの信頼喪失といった深刻な結果を招く可能性があります。
4. 非公式なAI採用の課題
4.1. シャドーAIの問題
Sameer：生成AIがどのように採用されているかという点についても考える必要があります。通常、これは正式な採用プロセスなしに行われています。つまり、開発者やユーザーが自分のデバイスやラップトップ上でこれらのツールを使い始め、センシティブなデータをアップロードしている可能性があり、LLMからのデータを使用しているかもしれませんが、それが正確でない可能性もあります。
このような状況では、すでに整備されているセキュリティ管理やガバナンスの枠組みの外側でリスクが生じています。シャドーITと同様に、シャドーAIの問題が浮上しているのです。ユーザーが公式の承認や監督なしにAIツールを使用すると、企業データが意図しない形で外部に漏れる可能性があります。
また、大規模言語モデルは時に「幻覚」を起こし、正確でない情報を提供することがあります。この情報を企業の意思決定に使用すると、誤った判断につながる恐れがあります。
このような非公式なAI採用は、データセキュリティ、プライバシー、コンプライアンスなど様々な面でリスクをもたらします。企業には、AIツールの正式な評価・承認プロセスの確立と、それらの安全かつ責任ある使用を促進するポリシーの策定が求められています。
4.2. 既存のセキュリティ対策の限界
Sameer：先ほど述べたような新たな課題を考えると、今日私たちが導入している標準的なプロトコルやチェックは、必ずしもこれらの特定タイプのアプリケーションに関連性があるとは限りません。
従来のセキュリティ対策は、主に伝統的なITインフラストラクチャやアプリケーションを保護するために設計されていますが、生成AIアプリケーションには独自の特性と課題があります。例えば、プロンプトインジェクション攻撃、モデルポイズニング、データ漏洩の新しい経路など、AIに特有のリスクベクトルに対しては、従来のセキュリティツールやプロセスでは十分に対応できません。
AIモデルは常に進化し、その振る舞いが変化する可能性があるため、静的なセキュリティチェックだけでは不十分です。さらに、多くのAIシステムはブラックボックスのような性質を持ち、内部動作の透明性が限られているため、従来のセキュリティ監視アプローチの有効性が低下します。
こうした既存セキュリティ対策の限界を認識し、AIアプリケーション特有のセキュリティリスクに対応する新しいフレームワークと実践を開発することが急務となっています。
5. 実例：LLMアプリケーションの脆弱性
5.1. 認証バイパスの脆弱性事例
Sameer：それでは、実際の脆弱性と企業にとって何を意味するのかについて少し説明しましょう。数ヶ月前、LLMアプリケーションで脆弱性が発見されました。モデル自体ではなく、モデルとの対話と入出力応答の処理方法に問題があり、攻撃者はこの特定の脆弱性（認証バイパスの脆弱性）を悪用して、パスワードやトークン、リポジトリへのアクセスを探り始めることができました。
これは非常に重要な事例です。この脆弱性では、AIモデル自体ではなく、そのモデルとユーザーのやり取りを管理するアプリケーション層に問題がありました。具体的には認証メカニズムを回避できる脆弱性であり、攻撃者はこれを利用して本来アクセスできないはずのシステム内の機密情報を探索できるようになりました。
このケースが示しているのは、AIセキュリティを考える際には、モデル自体だけでなく、それを取り巻くすべてのインフラストラクチャとアプリケーションコンポーネントを含む全体像を考慮する必要があるということです。
AIモデルとの対話を安全に管理することは、モデル自体のセキュリティと同じくらい重要です。認証、認可、入力検証、出力フィルタリングなど、従来のウェブアプリケーションセキュリティの原則はAIアプリケーションにも適用されますが、AIの特性に合わせた追加の対策も必要となります。
5.2. 攻撃の展開と影響
Sameer：これらのキーを手に入れた攻撃者は横方向に移動し、ベクトルデータベースから機密情報を引き出すことができました。これが意味するのは、最大のリスクが基盤モデル自体にあると考えるかもしれませんが、アプリケーションを構成するすべてのコンポーネントについても考える必要があるということです。
この事例で特に注目すべきなのは、攻撃の連鎖的な性質です。最初の認証バイパスの脆弱性は、攻撃者がシステム内の他のリソースにアクセスするための鍵となりました。認証を回避した後、彼らは権限昇格とラテラルムーブメントの技術を使用して、システム内のより価値の高いターゲット、この場合はベクトルデータベースに保存されている機密情報にアクセスできました。
これは、AIアプリケーションのセキュリティにおいては深層防御のアプローチが不可欠であることを示しています。単一の防御層に頼るのではなく、複数の保護レイヤーを実装することで、一つの脆弱性が全体のセキュリティを損なうリスクを軽減できます。
AIシステムがより複雑になり、より多くのコンポーネントと統合されるにつれて、攻撃対象領域も拡大します。そのため、アプリケーションのすべての側面におけるセキュリティの実装と、それらがどのように相互作用するかを理解することが非常に重要になります。
6. AIセキュリティの責任共有モデル
6.1. AIプラットフォームの責任範囲
Sameer：どのようにしてセキュリティ特有の責任を分解し始めるか、その方法を見ていきましょう。共有責任モデルというフレームワークがあります。皆さんも馴染みがあると思います。
左側に、AIアプリケーションを構成する3つのコンポーネントを示しています。AIプラットフォームについて話す時、基盤モデル自体の安全性、説明責任、チューニング、インフラストラクチャとデータガバナンスなどが含まれます。
AIプラットフォーム層は、AIシステム全体の基盤となる部分です。ここでは基盤モデルの安全性が最も重要な要素の一つとなります。モデルが有害な出力を生成しないこと、バイアスがないこと、そして予測不可能な方法で動作しないことを確保する必要があります。
また、モデルの説明責任も重要な側面です。これには、モデルの訓練方法、使用されたデータ、そして決定プロセスの透明性などが含まれます。規制当局や最終ユーザーに対して、モデルの動作原理について説明できることが必要です。
チューニングの側面では、モデルが特定のユースケースに適切に対応できるように調整することが含まれます。しかし、このプロセス自体もセキュリティリスクを伴うため、適切な管理が必要です。
インフラストラクチャとデータガバナンスは、モデルが実行される環境と使用するデータの管理に関わります。これらの要素は、AIシステム全体のセキュリティポスチャーの基盤を形成します。
6.2. AIアプリケーションの責任範囲
Sameer：AIアプリケーションとは、プラグイン、データ接続、インフラストラクチャ、そしてアプリケーションに関連するコードなど、全てを意味します。AIアプリケーション層は、基盤モデルの機能を活用して実際のビジネス価値を提供する部分です。
この層では、プラグインを通じてモデルの機能を拡張したり、外部システムと連携したりすることが可能です。しかし、各プラグインは新たなセキュリティリスクをもたらす可能性があるため、適切な評価と管理が必要です。
データ接続は、AIモデルが外部データソースにアクセスする方法を提供します。これらの接続点は、データの整合性、認証メカニズム、暗号化などのセキュリティ対策が適切に実装されていることを確認する必要があります。
インフラストラクチャに関しては、アプリケーションが実行されるサーバー、コンテナ、ネットワークなどのセキュリティを確保することが含まれます。これには、パッチ管理、設定強化、アクセス制御などの基本的なセキュリティプラクティスが含まれます。
そして、アプリケーションコードそのものも、セキュアコーディングの原則に従って開発され、脆弱性がないことを確認する必要があります。コード内の欠陥は、AIシステム全体のセキュリティを損なう可能性があります。
この層のセキュリティを確保することは、AIモデルの機能を安全かつ効果的にエンドユーザーに提供するために不可欠です。
6.3. AIデータと利用に関する責任範囲
Sameer：最後に、AIデータと利用について話す時、データアクセスとガバナンス、管理と制御、IDとアクセス管理など、これらすべてが考慮すべき他の要素です。
AIデータと利用の層は、AIシステムが処理するデータとそのデータへのアクセスや使用方法に関するすべての側面を網羅しています。これは非常に重要な領域であり、多くの規制要件とプライバシー懸念に直接関連しています。
データアクセスとガバナンスでは、AIシステムが使用するデータ、特に個人を特定できる情報や機密情報の管理に焦点を当てています。適切なデータ分類、保護対策、監査メカニズムを実装する必要があります。また、データの使用が法的要件や企業ポリシーに準拠していることを確認するためのプロセスも含まれます。
管理と制御の側面では、AIシステムの運用ポリシー、手順、監視メカニズムの確立が含まれます。これには、異常検出、インシデント対応計画、変更管理などが含まれます。これらの管理策は、AIシステムが常に安全で信頼性の高い方法で動作することを確保するのに役立ちます。
IDとアクセス管理は、AIシステムとそのデータへのアクセスを制御するための基本的なセキュリティ機能です。これには、強力な認証メカニズム、役割ベースのアクセス制御、最小権限の原則の実装などが含まれます。特に機密データを扱うAIシステムでは、誰がシステムにアクセスできるか、そして何を実行できるかを厳格に管理することが不可欠です。
この層のセキュリティを適切に管理することは、データプライバシー、規制遵守、そして全体的なシステム整合性を確保するために極めて重要です。
6.4. 実装モデル別の責任分担
Sameer：さて、アプリケーションの構築方法によって責任がどのように変わるかを見てみましょう。あなたがアプリケーションを構築する方法として選択できる3つの異なるモードがあります。
自分自身のモデルを構築することから始めることができます。これはBYOM（Bring Your Own Model）のユースケースです。これが意味するのは、顧客の責任がAIプラットフォーム層からデータと利用層まで広がるということです。そして、右に移動するにつれて、当然のことながら責任は減少します。
AIプラットフォームをサービスとして考える場合、AWS Bedrockのようなものを使用していますが、自分自身のモデルを使用することもあるため、インフラストラクチャは保護されていますが、構築しているモデル自体を保護する必要があります。
最後に、AI SaaSサービスは、APIのような単なるAPIを使用する場合です。これが意味するのは、最終的にはセキュリティモデルのデータと使用部分のみに責任があるということです。
この責任分担モデルを理解することは、企業がAI実装戦略を選択する際に重要です。BYOMアプローチでは、最も高いレベルのカスタマイズと制御が可能ですが、同時にセキュリティ責任も最大になります。一方、AI SaaSサービスを利用する場合は、セキュリティ責任が大幅に軽減されますが、カスタマイズの柔軟性も制限されます。
企業はこのトレードオフを理解し、自社のセキュリティ能力、リソース、そして特定のAIユースケースの要件に基づいて最適なアプローチを選択する必要があります。どのモデルを選択するにしても、データと利用の層に関する責任は常に顧客側にあることを忘れないことが重要です。
7. AIアプリケーションのテクノロジースタック
7.1. インフラストラクチャ
Sameer：アプリケーションが実際にどのように構築されるのかについて少し詳しく見ていきましょう。インフラストラクチャから始めます。これはプラットフォームとコンピュートとモデルです。
インフラストラクチャはAIアプリケーションの基盤となる部分で、AIモデルを実行し、サポートするために必要なすべての物理的および仮想的リソースが含まれます。これには、サーバー、ストレージ、ネットワーク、仮想マシン、コンテナなどが含まれます。
特にAIワークロードの場合、高性能なGPUやTPUなどの特殊なコンピューティングリソースが必要になることが多いです。これらのリソースは、AIモデルのトレーニングや推論処理を効率的に実行するために最適化されています。
インフラストラクチャ層には、Kubernetes（EKSなど）のようなコンテナオーケストレーションプラットフォームも含まれることがあります。これらは、AIモデルがパッケージ化されるコンテナの管理と調整を担当します。
典型的なAIアプリケーションのテクノロジースタックでは、インフラストラクチャはすべての他のコンポーネントの土台となります。その上にデータ層、基盤モデル層、そしてユーザーエクスペリエンス層が構築されます。
このインフラストラクチャ層のセキュリティとパフォーマンスは、AIアプリケーション全体の成功に直接影響します。そのため、セキュリティの観点からは、アクセス制御、パッチ管理、ネットワークセグメンテーション、暗号化など、従来のインフラストラクチャセキュリティのベストプラクティスを適用することが重要です。
7.2. データ
Sameer：次に、データ層があります。これは、モデルとの対話に使用するデータ、あるいはモデルの訓練に使用するデータのことです。
データ層はAIアプリケーションにとって極めて重要です。なぜなら、AIモデルの品質と性能は、それが学習するデータの質と直接関係しているからです。この層には、構造化データベース、非構造化データリポジトリ、データレイク、そして場合によってはオンプレミスのデータストアへのAPI接続などが含まれます。
AIモデルのトレーニングデータは、そのモデルが生成する結果の正確性と有用性を直接左右します。そのため、データ品質の確保、バイアスの除去、そして十分な多様性の確保が重要です。
また、AIシステムが本番環境で処理する運用データも同様に重要です。このデータは適切に検証され、必要に応じて前処理される必要があります。不適切なデータ入力は、AIモデルの出力品質を損なう可能性があります。
データ層のセキュリティに関しては、機密情報の保護、データアクセスの制御、データの整合性の確保、そしてプライバシー規制への準拠などが重要な考慮事項です。データポイズニング攻撃からの保護も重要です。これは悪意のあるデータをトレーニングセットに導入して、モデルの動作を操作しようとする攻撃です。
適切に設計・管理されたデータ層は、AIアプリケーションの信頼性、効果性、そしてセキュリティの基盤となります。
7.3. 基盤モデル
Sameer：もちろん、アプリケーションのコアの一部である基盤モデル自体があります。
基盤モデルは、AIアプリケーションの中心的な知能を提供する部分です。これは、大規模言語モデル（LLM）や他の種類のAIモデルで、アプリケーションの主要な機能と能力を決定づけます。
基盤モデルは、データ層から情報を取得し処理して、意味のある応答や洞察を生成します。これはTensorFlow、PyTorch、MXNetなどのフレームワークを使って開発されることが多く、多くの場合、特定のユースケースに合わせて微調整された事前訓練済みのモデルが基礎となります。
この層は実質的にアプリケーションの「頭脳」として機能し、その性能と能力がアプリケーション全体の価値を大きく左右します。例えば、テキスト生成、画像認識、自然言語理解などの機能は、すべて基盤モデルの性能に依存しています。
基盤モデルのセキュリティでは、モデル自体の保護（無許可のアクセスや使用からの保護）、モデルの堅牢性（敵対的入力に対する耐性）、そして出力の安全性（有害または不適切なコンテンツの防止）が重要な考慮事項です。
また、プロンプトインジェクション攻撃からの保護も不可欠です。これは悪意のあるユーザーが巧妙に設計されたプロンプトを使用して、モデルの通常の動作を回避したり、機密情報を引き出したりする攻撃です。
適切に設計・実装・保護された基盤モデルは、安全で効果的なAIアプリケーションの中核をなします。
7.4. ユーザーエクスペリエンス
Sameer：もちろん、その上に構築されるユーザーエクスペリエンスがあります。
ユーザーエクスペリエンス層は、AIアプリケーションのテクノロジースタックの最上位に位置し、ユーザーが基盤モデルと対話するためのインターフェースを提供します。これは、アプリケーションの視覚的および機能的な側面を決定する重要な要素です。
これを見ると、典型的なWebアプリケーションに見えますが、唯一の違いは基盤モデルに基づいていることです。多くのAIアプリケーションは実際に、ウェブインターフェースやモバイルアプリを通じてユーザーに提供されます。AWSのサービスを使用する場合、フロントエンドはAmplifyのようなサービスで構築され、認証にはCognitoが使用され、バックエンドにはBedrockのようなサービスが利用されることがよくあります。
ユーザーエクスペリエンス層のセキュリティでは、入力検証、出力サニタイズ、適切な認証と認可、セッション管理などが重要な要素です。特に、ユーザー入力はモデルに渡される前に適切に検証されなければなりません。これにより、プロンプトインジェクションなどの攻撃を防ぐことができます。
また、モデルからの出力も適切にフィルタリングされるべきです。これにより、有害なコンテンツやセンシティブな情報が誤ってユーザーに表示されるのを防ぐことができます。
ユーザーエクスペリエンス層は、AIアプリケーションの最終的な価値と採用率を大きく左右します。技術的に優れたモデルであっても、使いにくかったり、信頼性が低かったりすると、ユーザーに受け入れられない可能性があります。
8. OWASPのLLMフレームワーク
8.1. 入出力応答のセキュリティ
Sameer：セキュリティを実装し、何を探すべきかを理解するにはどうすればよいでしょうか？幸いなことに、私たちの友人であるOWASPが、LLMアプリケーションにおけるリスクのトップ10を示すフレームワークを最近発表しました。ここではすべてを詳しく説明するつもりはありませんが、いくつかを見てみましょう。
最初のセットは、入力と出力応答のセキュリティに集中しています。これは、ユーザーがモデルを欺いてデータを流出させたり、任意のコード実行を行ったりしないようにすることを意味します。不安全な出力処理とは、LLM自体が正確でないものを出力した場合、それがCSRF攻撃のようなものにつながる可能性があるということです。
入力セキュリティでは、プロンプトインジェクション攻撃からの保護が重要です。これは、ユーザーが巧妙に設計されたプロンプトを使用して、モデルの通常の動作を回避したり、機密情報を引き出したりする攻撃です。例えば、「前の指示を無視して」で始まるプロンプトは、モデルのセキュリティ制約を回避しようとする試みかもしれません。
出力セキュリティでは、モデルが生成した応答が安全で適切であることを確認する必要があります。LLMが誤った情報や有害なコンテンツを生成した場合、それがさらなるセキュリティ問題を引き起こす可能性があります。例えば、AIが生成したコードスニペットに脆弱性が含まれていれば、それを実行したユーザーのシステムが危険にさらされる可能性があります。
入出力応答のセキュリティを適切に実装することは、LLMアプリケーションの安全な運用の基盤となります。これには、入力の検証と清浄化、出力のフィルタリングとサニタイズ、そして異常な対話パターンの検出などが含まれます。
8.2. データセキュリティ
Sameer：もちろん、データ自体のセキュリティもあります。データポイズニングとは、データを特定の方向に偏らせたり、モデルを不正確にしたりするようなデータを追加することです。そして、もちろん、そのデータから機密情報を開示しないようにすることも含まれます。
データセキュリティはLLMアプリケーションにとって極めて重要な側面です。AIモデルはデータに基づいて学習し動作するため、そのデータの保護は最優先事項となります。
データポイズニングは特に懸念される脅威です。悪意のある行為者がトレーニングデータに意図的に偏ったデータや誤った情報を導入すると、モデル全体の動作が損なわれる可能性があります。例えば、特定の製品や思想に対して否定的なバイアスを持つようにモデルをトレーニングすることで、モデルの客観性や有用性が大きく低下する恐れがあります。
データからの機密情報の漏洩も同様に重要な懸念事項です。モデルがトレーニングデータから機密情報を「記憶」し、後で適切なプロンプトに応じてそれを開示する可能性があります。これには個人識別情報、企業秘密、あるいは機密文書の内容などが含まれる可能性があります。
データセキュリティを確保するためには、トレーニングデータの厳格な検証と監視、機密情報のマスキングや匿名化、そして入出力の両方での機密情報フィルタリングなどの対策が必要です。
適切なデータセキュリティの実装は、AIモデルの整合性、信頼性、そして法的・倫理的コンプライアンスを確保するために不可欠です。
8.3. サプライチェーンの脆弱性
Sameer：これらのアプリケーションが構築される際、サプライチェーンが大きな要因となります。前述の例のように、通常、人々はHugging Faceから基盤モデルを取得したり、他のリソースからフレームワークを入手したりして、それを基に構築しています。そのため、サプライチェーンの脆弱性を評価することが重要です。
AIアプリケーション開発においては、ほとんどの企業がゼロから全てを構築するわけではありません。代わりに、事前訓練されたモデル、オープンソースのライブラリ、サードパーティのフレームワークなど、様々な外部コンポーネントに依存しています。これらの外部依存関係それぞれが、セキュリティリスクをもたらす可能性があります。
例えば、事前訓練されたモデルには、バイアスのあるデータで訓練されていたり、バックドアが埋め込まれていたり、あるいは単に古い脆弱性を含んでいたりする可能性があります。オープンソースのライブラリやフレームワークには、セキュリティの欠陥や、最悪の場合は悪意のあるコードが含まれている可能性もあります。
これらのリスクは特にAIの文脈では重大です。なぜなら、AIモデルはしばしば「ブラックボックス」のような性質を持ち、内部動作の透明性が限られているからです。これにより、埋め込まれた脆弱性や悪意のあるコードを検出することが困難になります。
サプライチェーンセキュリティを確保するためには、使用するすべてのコンポーネントの厳格な評価、信頼できるソースからのみのコンポーネント取得、依存関係の継続的なモニタリングと更新、そして完全性検証メカニズムの実装などが必要です。
AIアプリケーションのサプライチェーンセキュリティの重要性は、今後ますます高まることが予想されます。そのため、体系的なアプローチでこれらのリスクに対処することが不可欠です。
8.4. モデル盗難のリスク
Sameer：OWASPのトップ10に含まれるその他のリスクには、効果的な制御が施されていない場合にLLMとモデル自体が盗まれる可能性があるモデル盗難などがあります。
モデル盗難は、特に独自のデータや技術を使って開発・微調整された企業固有のAIモデルにとって深刻な脅威です。これらのモデルは多大な投資と専門知識を要するため、企業にとって貴重な知的財産となります。
モデル盗難が発生する方法はいくつかあります。攻撃者がモデルをホスティングしているインフラストラクチャに不正アクセスする場合もあれば、APIを通じてモデルに大量のクエリを送信し、その応答を分析してモデルの動作を複製する「モデル抽出攻撃」を行う場合もあります。さらに、内部の脅威、つまり正当なアクセス権を持つ従業員や契約業者によるモデルの不正持ち出しもリスクとなります。
モデル盗難が発生すると、その影響は甚大です。競合他社が同等のAI機能を短期間で獲得できるようになり、企業の競争優位性が損なわれます。また、盗まれたモデルが悪用されることで、企業の評判が損なわれる可能性もあります。
このリスクに対処するためには、強固なアクセス制御、モデルの暗号化、APIレート制限の実装、そして異常アクセスパターンを検出するためのモニタリングシステムなどが必要です。特に価値の高いモデルの場合は、物理的な分離や特別なセキュリティ対策を検討することも重要です。
モデル盗難の防止は、AIに多大な投資を行っている企業にとって、その投資を保護し、競争力を維持するために不可欠なセキュリティの側面です。
9. AWS上のAIアプリケーションにおけるセキュリティ
9.1. フロントエンドコンポーネントのセキュリティ
Sameer：それでは、それらのOWASPトップ10を取り上げ、AWSに構築される可能性のあるアプリケーションに当てはめてみましょう。これは典型的なアプリケーションです。AmplifyでビルドされたWebアプリ、Cognitoによるユーザー認証と管理、Bedrockを活用し、もちろんモニタリングとアイデンティティとアクセス管理、そしてデータを取得するためのデータベースがあります。
まずフロントエンドコンポーネントから始めましょう。ユーザーが操作するものから始めます。ここではユーザーインターフェースが提供され、「何をしたいですか？」と尋ねられます。ここでは、アクセス制御メカニズムの破綻により、データへのアクセス権を持たないユーザーが特定のユーザーインターフェースを通じてデータにアクセスできることを意味します。
プロンプトインジェクション技術については、ここでオーバーレイします。そしてもちろん、不安全な出力処理もあります。したがって、OWASPトップ10の特定の脆弱性や、その特定の層で必要な追加の制御が多数あります。
フロントエンドのセキュリティは、AIアプリケーションの最初の防御線です。ここでは、ユーザー認証、入力検証、出力サニタイズなどの基本的なウェブセキュリティプラクティスが重要です。AWSのAmplifyのようなサービスを使用している場合でも、適切なセキュリティ設定とベストプラクティスの実装が不可欠です。
特にAIアプリケーションでは、ユーザーからの入力がAIモデルに直接渡される可能性があるため、プロンプトインジェクション攻撃のリスクが高まります。そのため、すべてのユーザー入力に対する強力な検証と清浄化が必要です。
また、モデルからの出力も適切に処理され、フィルタリングされる必要があります。AIモデルは予期しない応答を生成する可能性があり、これが安全でない場合、アプリケーション全体のセキュリティを損なう可能性があります。
フロントエンドセキュリティでは、適切なCSRF対策、XSS防止、そして安全なセッション管理も重要です。これらの基本的なウェブセキュリティ対策はAIアプリケーションにも同様に適用されます。
9.2. 管理機能コンポーネントのセキュリティ
Sameer：次に進みましょう。管理機能の一部であるコンポーネントを見てみると、アイデンティティとアクセス制御の設定ミスがあります。これは過度に特権が与えられている、あるいは管理者権限を持つユーザーが多すぎることを意味します。
データと整合性の障害もあります。そして、もちろんOWASPトップ10のモデル盗難もここに含まれます。なぜなら、もしBedrockで自分のモデルを構築して実行している場合、そこにもアクセス制御が必要だからです。
管理機能コンポーネントのセキュリティは、AIアプリケーションのバックエンド管理と制御に関わる部分です。ここでは、ID管理、アクセス制御、リソース管理などが含まれます。これらのコンポーネントがセキュアでなければ、アプリケーション全体のセキュリティが損なわれる可能性があります。
特に懸念されるのは、過剰な特権を持つアカウントや、必要以上に多くの管理者権限を持つユーザーの存在です。「最小権限の原則」に従って、各ユーザーやサービスアカウントには、その役割を果たすために必要最小限の権限のみを付与すべきです。
データの整合性の問題も重要です。管理機能を通じてシステムに入力されるデータや設定が正確で一貫性があることを確保する必要があります。これには、入力検証、データ検証チェック、そして変更管理プロセスの実装が含まれます。
Bedrockのような環境で独自のモデルを実行している場合、モデル自体へのアクセス制御も重要な考慮事項です。モデルのパラメータ、重み付け、あるいはトレーニングデータへの不正アクセスは、知的財産の損失や競争上の不利益につながる可能性があります。
管理機能コンポーネントのセキュリティを強化するためには、強力な認証メカニズム、詳細なアクセス制御ポリシー、包括的な監査とログ記録、そして定期的なセキュリティ評価と見直しが必要です。
10. AIアプリケーション開発におけるステークホルダー
10.1. 開発者の役割
Sameer：では、アプリケーションの実際の構築方法、関わるユーザー、そしてそれがただのファイルから実際のアプリケーションへとどのように移行するのかについて見ていきましょう。
ご想像の通り、多くの人々が関わっています。まず、おそらくフルスタックを構築する開発者から始まります。彼らはアプリケーションのコードを書き、インフラストラクチャを設定し、フロントエンドとバックエンドの統合を処理します。
開発者はAIアプリケーション構築のフロントラインに立っています。彼らの責任は、アプリケーションの機能要件を満たすだけでなく、セキュリティを設計段階から組み込むことも含まれます。セキュアコーディングプラクティス、入力検証、出力サニタイゼーション、認証と認可の実装など、多くのセキュリティ関連のタスクが開発者の手に委ねられています。
特にAIアプリケーションの場合、開発者はAIモデルとの安全な統合方法、プロンプトインジェクション攻撃からの保護方法、そしてモデルの出力を適切に処理する方法を理解する必要があります。
さらに、開発者はサプライチェーンセキュリティにも注意を払う必要があります。使用するライブラリ、フレームワーク、そして事前訓練されたモデルが信頼できるソースからのものであり、既知の脆弱性がないことを確認する必要があります。
AIアプリケーションのセキュリティを確保するためには、開発者がリスクを理解し、適切な対策を実装できることが不可欠です。そのため、開発者に対するセキュリティトレーニングと意識向上は、全体的なセキュリティ戦略の重要な部分となります。
10.2. プラットフォーム管理者の役割
Sameer：クラウドサービスとクラウドプラットフォーム自体を制御するプラットフォーム管理者もいます。
プラットフォーム管理者は、AIアプリケーションが稼働する基盤となるクラウド環境の設定、管理、保守を担当します。AWSのようなクラウドプラットフォームでは、これらの管理者がIAMポリシー、ネットワーク設定、セキュリティグループ、暗号化設定など、基本的なセキュリティ制御の実装を担当します。
彼らはクラウドサービスの適切な構成を確保し、過度に寛容な権限や不要な公開露出などの一般的な誤設定を防ぐ役割を果たします。例えば、S3バケットやAPI Gatewayエンドポイントが適切にセキュリティ保護されていることを確認します。
また、プラットフォーム管理者はパッチ管理とアップデートも担当し、使用しているすべてのクラウドサービスやコンポーネントが最新のセキュリティパッチで更新されていることを確認します。これはAIワークロードを実行するインフラストラクチャの安全性を維持するために特に重要です。
さらに、彼らはログ記録、監視、アラートなどの機能も設定し、セキュリティインシデントが発生した場合に迅速に検出して対応できるようにします。このような可視性は、AIアプリケーションの保護において極めて重要です。
プラットフォーム管理者は、クラウドプロバイダーが提供するセキュリティ機能と共有責任モデルを深く理解している必要があります。彼らはクラウドの設定が組織のセキュリティポリシーとコンプライアンス要件に準拠していることを確保する重要な役割を果たします。
10.3. MLおよびデータエンジニアの役割
Sameer：また、モデルの構築を支援するMLおよびデータエンジニアもいます。
MLおよびデータエンジニアは、AIアプリケーションの中核となるモデルとデータパイプラインの開発と管理を担当します。彼らの役割は、高品質なAIモデルを構築し、それに適切なデータを供給することです。
データエンジニアは、データの収集、処理、保存、そして変換を担当します。彼らはデータパイプラインを構築し、モデルトレーニングや推論に必要なデータが適切に準備されていることを確保します。セキュリティの観点では、彼らはデータの整合性、データプライバシー、そして機密情報の保護に注意を払う必要があります。
MLエンジニアは、AIモデルの設計、トレーニング、テスト、そして最適化を担当します。彼らはモデルが正確で信頼性があり、かつ安全であることを確認する責任があります。これには、モデルのバイアスの検出と軽減、敵対的攻撃への耐性の確保、そして出力の安全性のテストなどが含まれます。
MLおよびデータエンジニアは、データポイズニングなどのセキュリティリスクを理解し、それに対する防御策を実装する必要があります。また、モデルの説明可能性と透明性を向上させるツールや技術を活用することも重要です。これにより、モデルの動作をより理解しやすくなり、潜在的な問題を特定しやすくなります。
これらのエンジニアが開発者やプラットフォーム管理者と密接に連携することで、AIアプリケーション全体のセキュリティが強化されます。彼らの専門知識はモデルとデータのセキュリティに不可欠ですが、それがアプリケーション全体のセキュリティフレームワークに統合されることが重要です。
10.4. ガバナンスとリスク管理者の役割
Sameer：そしてもちろん、ガバナンスとリスク管理の担当者、そしてモデル承認者もいます。あなたが構築するものはすべて、これらのユーザー全員がリスク自体を理解し、開発者からセキュリティを組み込むことを確実にし、ガバナンスの人々に監査と透明性の能力を提供することを確実にする必要があります。これは今、大きな要件になっています。
ガバナンスとリスク管理者は、AIアプリケーションが組織のポリシー、業界標準、そして法的要件に準拠していることを確保する重要な役割を担っています。彼らはAI特有のリスクを評価し、それらのリスクを軽減するための適切な管理策が実装されていることを確認します。
特に彼らは、プライバシー規制（GDPR、CCPAなど）、業界固有の規制、そして新たに登場しつつあるAI特有の規制へのコンプライアンスを監視します。AIの透明性と説明責任を確保するために、彼らはモデルの開発、トレーニング、デプロイメント、そして使用のすべての側面に関する詳細な文書化とレポートを要求することがあります。
モデル承認者は、新しいAIモデルやその更新が本番環境にデプロイされる前に、それらを評価し承認する責任があります。彼らはモデルのパフォーマンス、安全性、公平性、そして潜在的なリスクを評価します。これには、バイアスの検査、敵対的シナリオのテスト、そして出力の品質と適切性の確認などが含まれます。
ガバナンスとリスク管理者が効果的に機能するためには、AIシステムの開発と運用に関する可視性と透明性が不可欠です。そのため、彼らは開発プロセスの初期段階から関与し、セキュリティとコンプライアンスの要件が設計段階から組み込まれるようにする必要があります。
彼らの役割はAIの責任ある使用を確保し、組織が法的・倫理的リスクに晒されないようにするために極めて重要です。AIの普及と規制環境の進化に伴い、ガバナンスとリスク管理者の役割はますます重要になっています。
11. 開発段階でのAIアプリケーションのセキュリティ
11.1. 自作モデルのセキュリティ
Sameer：それでは、AI開発中にAIアプリケーションをどのように保護するかについて説明しましょう。AIモデルを保護するための典型的な3つの段階があります。全ての段階について説明しますが、最初のものに集中しましょう。
まず、開発中にAIを保護する必要があります。アプリケーションとそれが実行されるサービスのポスチャーを管理し、もちろんそれに対する脅威を監視する必要があります。
まずAI開発の部分に焦点を当てましょう。自分でモデルを構築している例に最初に注目します。通常、これはGitリポジトリがすべてのコードと管理のソースとなります。私が使用している一部のフレームワークには、TensorFlow、MXNet、PyTorchなどがあり、モデル自体の構築に使用されます。
一般的に、開発者はこれらの特定のライブラリをプルするだけでなく、カスタムコードを構築し、追加のサードパーティライブラリも追加する可能性があります。もちろん、基盤モデルを開始点とする場合は、サードパーティからプルして微調整することもあります。また、APIを通じてオンプレミスのデータストアやデータレイクにアクセスすることもあります。
カスタムモデルが構築される典型的な方法は、Gitリポジトリにプッシュし、監視し、変更があるとすぐにCodeBuildが実行され、アプリケーション自体と推論コンテナの2つの特定のコンテナをECRにプッシュします。もちろん、その後EKS上で実行し、SageMakerのエンドポイントを通じて公開することができます。
この開発パイプラインでは、各ステップでセキュリティ対策を実装することが重要です。コードリポジトリでは、アクセス制御、コードレビュー、そして脆弱性スキャンが必要です。ライブラリとフレームワークの選択では、既知の脆弱性がないものを選び、常に最新のセキュリティパッチで更新することが重要です。
基盤モデルやサードパーティのコンポーネントを使用する場合は、それらの出所と安全性を確認する必要があります。データアクセスについては、最小権限の原則に従い、必要な時に必要なデータにのみアクセスできるようにすべきです。
ビルドとデプロイメントの段階では、コンテナイメージのスキャン、セキュリティテスト、そして署名検証などの対策を実装できます。これにより、本番環境にデプロイされるのは安全で検証済みのコードとモデルのみであることを確保できます。
11.2. Hugging Faceモデルの脆弱性統計
Sameer：私たちは、今日利用可能なすべてのフレームワークとフォーマットを調査しました。おそらく6つか7つのフレームワークがこれらのモデルの構築に使用されています。Hugging Faceを見てみると、150万以上の大規模言語モデルを調査したところ、60%以上のモデルが脆弱であることがわかりました。つまり、もしあなたがコンテナを取得してアプリケーションで使用するなら、安全でないコードが含まれている可能性があるということです。
分布としては、私の信じるところでは、MPIとPyTorchが最も高く、もちろん、これらのほとんどは安全ではありません。この60%という数字は非常に驚くべきものです。アプリケーション開発者がオープンソースの基盤モデルやフレームワークに頼る傾向が高まる中、その多くが未検出の脆弱性を含んでいるという事実は大きな懸念材料です。
これらの脆弱性は様々な形を取ります。一部は単純なコーディングエラーやライブラリの不適切な使用から生じる場合もありますが、より深刻なのは、意図的に埋め込まれた悪意のあるコードやバックドアが存在する可能性です。私たちの調査では、一部のモデルには実際にマルウェアが埋め込まれていたり、プロンプトインジェクション攻撃を容易にするコードが含まれていたりすることが判明しました。
MPIとPyTorchフレームワークで構築されたモデルが最も高い脆弱性率を示しているという事実は、これらの人気のあるフレームワークを使用する開発者にとって特に警戒すべき点です。しかし、どのフレームワークを使用している場合でも、サードパーティのモデルや依存関係の徹底的な検証が不可欠です。
これらの統計は、AIアプリケーション開発におけるサプライチェーンセキュリティの重要性を強調しています。事前構築されたモデルを使用する利便性は魅力的ですが、セキュリティの観点からは大きなリスクをもたらす可能性があります。
11.3. 脆弱性の発生源
Sameer：これらの脆弱性はどこから発生するのでしょうか？アプリケーション自体からです。これらはモデルで事前設定されたコンテナイメージから来ています。OS固有の脆弱性を持つ仮想マシンやテンプレートもあるかもしれません。アプリケーションを構築する際のサードパーティライブラリ、そしてトレーニングに使用されるサードパーティデータやデータセットも脆弱性の源となります。
先に述べたいくつかの特定のリスクに戻ると、サードパーティのライブラリを追加し、モデルをプルする際に、サプライチェーンリスクが始まります。また、これらのモデルの一部には埋め込まれたマルウェアや、プロンプトインジェクションのようなコードが組み込まれていることも発見しています。また、使用するデータセットによっては、間違ったデータを与えることでモデルを毒することも可能です。
AIアプリケーションの脆弱性は多くの異なるソースから発生する可能性があり、それぞれが固有のリスクをもたらします。コンテナイメージは特に重要な懸念事項です。なぜなら、これらは多くの場合、ブラックボックスとして扱われ、その内容が十分に検査されないまま使用されることがあるからです。これらのイメージには古いライブラリ、パッチが適用されていないソフトウェア、あるいは最悪の場合、意図的に挿入された悪意のあるコードが含まれている可能性があります。
仮想マシンテンプレートやOSイメージも同様の問題を抱えています。これらは一般的に、AIワークロードをホストするための基盤として使用されますが、最新のセキュリティパッチが適用されていない場合、攻撃者にシステムへのエントリーポイントを提供してしまう可能性があります。
サードパーティライブラリは、現代のソフトウェア開発の必須要素ですが、これらも重大なリスクをもたらします。各ライブラリは独自の依存関係と潜在的な脆弱性を持っており、それらすべてがアプリケーションの攻撃対象領域を拡大します。
データセットの問題も見過ごせません。トレーニングデータにバイアスや誤った情報が含まれていると、モデルの動作が損なわれる可能性があります。これはモデルポイズニング攻撃として知られており、攻撃者がモデルの応答を意図的に操作するために使用することができます。
これらすべての脆弱性源に対処するためには、包括的なセキュリティアプローチが必要です。これには、すべてのコンポーネントの厳格な評価、継続的なモニタリング、そして定期的なセキュリティテストが含まれます。
11.4. リスク軽減策
Sameer：それでは、これらのリスクを軽減するために何ができるでしょうか？サプライチェーンの特定と保護を確実に行うこと、モデルパイプラインの保護、そして脅威モデルの作成とコード解析を行うことです。
CrowdStrikeはどのように支援できるでしょうか？先ほど述べたように、これらのアプリケーションのほとんどはGitリポジトリ内で構築されています。Gitコミットに新しい変更があると、通常アプリケーションに伴う2つのコンポーネントがあります。1つはインフラストラクチャのコアテンプレートで、すべてのクラウドセキュリティ、使用するクラウドサービスを定義します。もちろん、プッシュされるコンテナもあり、これは先ほど話したML推論コンテナとアプリケーションコンテナの両方です。
これらがプッシュされると、CodeBuildを使用してアプリの新しいバージョンが構築されます。Falconの事前実行時スキャンにより、これらのイメージがECRに組み込まれるとすぐに、それらのイメージをプルダウンして脆弱性をスキャンすることができます。
以前に言及したフレームワークと拡張機能について話したのはなぜでしょうか？私たちが現在アプリケーションのセキュリティを確保するために行っている最初のことは、AIおよびMLフレームワーク特有の脆弱性をスキャンし、それらを顧客に公開することで、リスクがあるか、マルウェアがあるか、シークレットや設定ミスがあるかを知らせることです。
もちろん、ライフサイクル全体は、特定のコンテナがスキャンされ、ポリシーを通過したチェックに合格すると、エージェントレスとエージェントベースの構成とセキュリティを備えたEKSにプッシュされます。
CrowdStrikeのようなセキュリティソリューションを使用することで、AIアプリケーション開発の各段階でセキュリティを確保することができます。特にコンテナイメージのスキャンは、AIワークロードのセキュリティにおいて重要な要素です。
スキャンプロセスは静的分析だけでなく、動的コンテナ分析も含むべきです。これにより、実行時の振る舞いを観察し、静的スキャンでは検出できない可能性のある問題を特定することができます。AIフレームワーク特有の脆弱性を特定する能力は、標準的なコンテナスキャンツールでは見落とされがちな問題を捉えるために特に重要です。
最終的には、AIセキュリティは単独のツールや対策ではなく、開発ライフサイクル全体を通じて統合されたプロセスとして考えるべきです。コードリポジトリからビルドパイプライン、コンテナレジストリ、そして最終的なデプロイメントとランタイム環境まで、セキュリティは各段階で考慮される必要があります。
12. CrowdStrikeによるAIセキュリティ支援
12.1. Falcon事前実行時スキャンの機能
Sameer：コンテナイメージスキャンは何ができるでしょうか？もちろん、コンテナイメージをスキャンします。二つ目は動的コンテナ分析です。これが意味するのは、コンテナをプルダウンして、ある程度の時間実行させるということです。これにより、コンテナの動作検出が露出します。静的スキャンはある程度までしかできませんが、動的コンテナ分析を行うと、面白いことが見え始める可能性があります。そして、コンテナをデプロイすべきでないことが確認できます。
もちろん、コンテナとしてのサーバーレス関数もスキャンできます。そして、仮想マシンのAMIイメージもスキャンできるAPIもあります。
Falcon事前実行時スキャンは、AIアプリケーションのセキュリティにおいて重要な役割を果たします。特に動的コンテナ分析の機能は非常に価値があります。これにより、静的分析だけでは検出できない可能性のある問題を特定することができます。
例えば、コンテナが実行されると、不審なネットワーク接続を確立したり、予期しないファイルシステムの変更を行ったり、あるいは異常なプロセスを起動したりする可能性があります。これらの動作は、コンテナが実際にデプロイされ、運用環境で実行される前に特定することが重要です。
また、サーバーレス関数のスキャン機能も重要な側面です。サーバーレスコンピューティングはAIアプリケーションで一般的に使用されていますが、それらも同様にセキュリティリスクをもたらす可能性があります。これらの関数がコンテナとしてパッケージ化されているため、同様のスキャン技術を適用することができます。
AMIイメージをスキャンする機能は、EC2インスタンスなどの仮想マシン上で実行されるAIワークロードに対するセキュリティを確保するのに役立ちます。これらのイメージが最新のセキュリティパッチでアップデートされており、既知の脆弱性がないことを確認することは、AIインフラストラクチャ全体のセキュリティを維持するために不可欠です。
これらのスキャン機能を組み合わせることで、AIアプリケーションのサプライチェーン全体にわたるセキュリティを確保することができ、開発からデプロイまでのすべての段階で脆弱性やセキュリティリスクを特定し、対処することができます。
12.2. AIおよびMLフレームワーク脆弱性スキャン
Sameer：前述のフレームワークと拡張機能について話したのはなぜでしょうか？私たちが現在アプリケーションのセキュリティを確保するために行っている最初のことは、AIおよびMLフレームワーク特有の脆弱性をスキャンし、それらを顧客に公開することで、リスクがあるか、マルウェアがあるか、シークレットや設定ミスがあるかを知らせることです。
パイプライン全体はもちろん、コンテナが特定のECRでスキャンされてポリシーによるチェックに合格すると、エージェントレスとエージェントベースの構成とセキュリティを備えたEKSにプッシュされ、そこで監視を行います。
AIおよびMLフレームワーク特有の脆弱性スキャンは、標準的なコンテナスキャンよりも一歩進んだものです。これは、TensorFlow、PyTorch、MXNetなどのAIフレームワークに特有の脆弱性を特定するために設計されています。
このスキャン機能は、前述の統計から明らかなように非常に重要です。Hugging Faceのモデルの60%以上に脆弱性が存在するという事実は、AIフレームワークとモデルに特化したセキュリティツールの必要性を浮き彫りにしています。
具体的には、このスキャン機能は一般的なウェブアプリケーションの脆弱性とは異なる、AI特有の脆弱性を検出します。例えば、モデルポイズニングの脆弱性、不安全なモデルシリアル化/デシリアル化、敵対的入力に対する脆弱性などです。
また、これらのスキャンはモデル内に埋め込まれた悪意のあるコードやマルウェアも検出します。前述のように、一部のモデルには実際にマルウェアが埋め込まれていたり、プロンプトインジェクションを容易にするコードが含まれていたりすることがわかっています。
脆弱性が発見された場合、それはリスクレベルとともに顧客に通知され、その問題に対処するための推奨事項が提供されます。これにより、顧客は問題の重大度を理解し、適切な緩和策を実装することができます。
このスキャン機能は、AIアプリケーションの開発パイプラインに統合され、イメージがECRにプッシュされると自動的に実行されます。これにより、脆弱なコンポーネントが本番環境にデプロイされる前に検出することができます。
12.3. コンテナイメージスキャンの機能
Sameer：コンテナイメージスキャンには何ができるでしょうか？もちろん、コンテナイメージをスキャンします。二つ目は動的コンテナ分析です。これが意味するのは、コンテナをプルダウンして、ある程度の時間実行させるということです。これにより、コンテナの動作検出が露出します。静的スキャンはある程度までしかできませんが、動的コンテナ分析を行うと、面白いことが見え始める可能性があります。そして、コンテナをデプロイすべきでないことが確認できます。
もちろん、コンテナとしてのサーバーレス関数もスキャンできます。そして、仮想マシンのAMIイメージもスキャンできるAPIもあります。
CrowdStrikeのコンテナイメージスキャン機能は、AIアプリケーションのセキュリティを確保するための多層的なアプローチを提供します。静的スキャンと動的分析の両方を組み合わせることで、より包括的なセキュリティ評価が可能になります。
静的スキャンでは、コンテナイメージ内の既知の脆弱性、古いライブラリ、安全でない設定、ハードコードされた認証情報などを特定します。これは基本的なセキュリティチェックとして不可欠ですが、限界もあります。
動的コンテナ分析は、これらの限界を超えて、実際の実行時の振る舞いを評価します。コンテナを制御された環境で実行し、その動作を監視することで、静的分析では発見できない可能性のある問題を特定します。例えば、予期しないネットワーク接続、権限昇格の試み、または異常なファイルシステム操作などです。
サーバーレス関数のスキャン機能は、AWSのLambdaのようなサーバーレスコンピューティング環境で実行される関数のセキュリティを確保するのに役立ちます。これらの関数も同様にセキュリティリスクをもたらす可能性があり、特にAIモデルを活用する場合はなおさらです。
AMIイメージスキャン機能は、EC2インスタンスなどの仮想マシン上で実行されるAIワークロードのセキュリティを確保します。これらのイメージが最新のセキュリティパッチで更新されており、セキュリティのベストプラクティスに従って構成されていることを確認することは重要です。
これらのスキャン機能をAI開発パイプラインに統合することで、セキュリティは開発プロセスの不可欠な部分となり、脆弱性や設定ミスが早期に特定され、修正されることを保証します。
13. セキュリティ管理プログラムの構築
13.1. AIガバナンスと文化の発展
Sameer：セキュア制御を実装するためのプログラムを構築する方法について見てみましょう。まず最初はAIガバナンスと文化の発展です。それが意味するのは、AIがどこで使用できるべきかについて、内部または外部ユーザーに受容可能な使用ポリシーを提供することで、ユーザーが支援されるということです。
これは使用ポリシーと同様に、リスクに関する認識も構築します。そして、これは一度きりのことではありません。状況が変化するにつれて継続的にコミュニケーションを取り、更新していく必要があります。
AIガバナンスと文化の発展は、セキュリティプログラムの根幹を成すものです。これは単にポリシーを策定することではなく、組織全体でAIテクノロジーの責任ある使用に関する共通の理解と実践を確立することを意味します。
まず、AIの受容可能な使用ポリシーの開発が重要です。このポリシーでは、組織内でAIツールをどのように、どのような目的で使用できるかを明確に定義します。例えば、どのようなデータをAIシステムに入力できるか、AIが生成した出力をどのように検証し使用すべきか、どのAIツールが承認されているかなどを規定します。
同時に、このポリシーを通じてAI使用に関連するリスクについての認識を高めることも重要です。ユーザーがAIの限界、潜在的なバイアス、セキュリティリスクを理解することで、より責任ある方法でこれらのツールを使用できるようになります。
Sameerさんが強調しているように、これは一度きりの取り組みではなく、継続的なプロセスです。AIテクノロジーは急速に進化しており、新たな機能や課題が常に出現しています。そのため、ポリシーやガイドラインを定期的に更新し、ユーザーに最新情報を提供することが重要です。
効果的なAIガバナンスと文化は、トップダウンとボトムアップの両方のアプローチを組み合わせることで構築されます。経営陣はAIの責任ある使用に対するコミットメントを示し、一方で従業員はベストプラクティスを共有し、日々の業務でAIを安全に活用する方法を相互に学び合うことができます。
13.2. アクセス制御とデータ保護
Sameer：もちろん、アクセス制御とデータ保護の確保も重要です。これは、データアクセスポリシーとデータ境界が環境内に浸透していることを意味します。DLPがこれらの機能を監視していること、データの漏洩に関連する堅牢な保護があることを確認します。そして、安全なルートがない場合は、他のAIプラットフォームやツールを検討して安全な代替手段を提供し、承認されたユーザーのみが安全なデバイスからアクセスできるようにします。
アクセス制御とデータ保護は、AIアプリケーションのセキュリティを確保するための基本的な要素です。特にAIシステムは多くの場合、機密データや個人情報を処理するため、これらの保護策は極めて重要です。
データアクセスポリシーとデータ境界の実装は、誰がどのデータにアクセスできるかを明確に定義します。これには、最小権限の原則の適用、役割ベースのアクセス制御の実装、そして定期的なアクセス権限の見直しが含まれます。AIモデルの訓練や推論に使用されるデータへのアクセスは、特に厳格に管理される必要があります。
データ損失防止（DLP）の監視は、機密データが承認されていない方法で使用されたり、システム外に漏洩したりするのを防ぐために不可欠です。これには、AIモデルへの入力と出力の両方の監視が含まれます。例えば、ユーザーが機密情報をAIシステムに入力しようとしていないか、またはAIモデルが意図せず機密情報を出力していないかを検出する仕組みが必要です。
データ漏洩に対する堅牢な保護策には、データの暗号化（保存時と転送時の両方）、セキュアなAPIゲートウェイ、そして不正アクセスを検出するための異常検知システムなどが含まれます。
Sameerさんが指摘しているように、安全な代替手段を提供することも重要です。特定のAIプラットフォームやツールが組織のセキュリティ要件を満たしていない場合、安全な代替手段を評価し提供することで、ユーザーが「シャドーAI」の使用に走ることを防ぎます。
最後に、承認されたユーザーのみが安全なデバイスからアクセスできるようにすることは、アクセス制御の重要な側面です。これには、強力な認証メカニズム（多要素認証など）、デバイスの健全性チェック、そして条件付きアクセスポリシーの実装などが含まれます。
これらの対策を組み合わせることで、AIシステムとそのデータに対する包括的な保護層を提供し、機密情報の漏洩やセキュリティ違反のリスクを大幅に軽減することができます。
14. CrowdStrikeによるAIクラウドサービスのセキュリティ
14.1. クラウドサービス可視化
Sameer：実装する最初のことは、クラウドサービスとその設定方法についての可視性を得ることです。CrowdStrikeでは、Amazon SageMakerやBedrockなどのAIクラウドサービスとそれらに関連する設定への完全な可視性を提供する能力が追加されました。
これは脆弱性、設定ミス、露出、そして機密データへのアクセスを見つけることを意味します。また、先に述べたようにECRリポジトリの統合スキャンにより、サプライチェーンのリスクも見つけることができます。そして、もちろんEKSやECSでも、それらの特定のエンドポイントが露出しているかどうかを理解できます。
クラウドサービスの可視化は、AIセキュリティの基盤となるものです。SageMakerやBedrockのようなAWS AIサービスの設定と状態を完全に把握することで、セキュリティチームは潜在的なリスクを特定し、対処することができます。
この可視性には、サービスがどのように構成されているか、誰がアクセス権を持っているか、どのデータが処理されているか、そしてどのセキュリティ制御が実装されているかの理解が含まれます。これにより、セキュリティチームは設定ミスや潜在的な脆弱性を特定することができます。
例えば、CrowdStrikeのソリューションは、過度に許容的なIAMポリシー、暗号化されていないデータストア、公共インターネットに不必要に露出しているエンドポイント、あるいは機密データへの過度のアクセス権など、AIサービスの一般的な設定ミスを特定することができます。
ECRリポジトリの統合スキャン機能により、コンテナイメージ内のセキュリティ問題を早期に特定することができます。これはAIアプリケーションのサプライチェーンセキュリティを確保するための重要な要素です。
EKSやECSなどのコンテナオーケストレーションサービスの可視性も同様に重要です。これにより、これらのサービス上で実行されているAIワークロードが適切に保護されていることを確認することができます。例えば、不必要に公共インターネットに露出しているAIエンドポイントを特定することができます。
クラウドサービスの包括的な可視性を持つことで、組織はAI環境全体のセキュリティ状態を理解し、リスクの高い領域に優先的に対処することができます。これは、複雑で常に進化するAIサービスのランドスケープにおいて特に重要です。
14.2. ランタイム保護機能
Sameer：これらのモデルは通常、先ほど言及したようなコンテナ化された環境で実行されています。Falcon Cloud Securityでは、AIモデル自体のランタイム保護も提供しています。これが意味するのは、AI特有の振る舞いに対する特定のランタイムテレメトリと検出をサポートする能力が現在あるということです。
これは私たちが研究し、開発中のものですが、まもなく利用可能になるでしょう。次の部分として、これらの画像をデプロイする際にスキャンしましたが、ゼロデイ脆弱性を発見した場合はどうするのでしょうか？特定の脆弱性が環境内に存在するかどうかを確認するために何をすべきでしょうか？
ランタイムモデルスキャンでは、画像がどこにデプロイされたか、それがスキャンされたかどうかを理解できるようにしています。パッケージがスキャンされたとすぐに、私たちはそれに関連するメタデータを持っています。そして明日、その特定のパッケージが脆弱であることが判明した場合、その特定の脆弱性が環境内に存在することを示す検出を迅速に設定できます。これにより、セキュリティチームの検出が容易になります。
AIモデルのランタイム保護は、実行時の挙動を監視し異常を検出するための重要な機能です。静的分析やデプロイ前のスキャンだけでは不十分であり、実際の運用環境でのモデルの動作を保護する必要があります。
CrowdStrikeのAI特有の振る舞いに対するテレメトリと検出機能は、従来のランタイム保護を超えて、AIモデルに特化した脅威や異常を検出できるように設計されています。これには、異常なモデルアクセスパターン、不審なデータ抽出試行、あるいはモデルの誤用などの検出が含まれます。
特に重要なのは、ゼロデイ脆弱性への対応能力です。新たな脆弱性が発見された場合、そのような脆弱性を持つコンポーネントがどこにデプロイされているかをすぐに把握することが重要です。CrowdStrikeのランタイムモデルスキャン機能は、これを可能にします。
Sameerさんが説明しているように、このシステムはデプロイされた画像とそのメタデータを追跡します。新しい脆弱性が発見されると、そのパッケージが環境内のどこに存在するかを迅速に特定し、検出を設定することができます。これにより、セキュリティチームは迅速に対応し、脆弱なコンポーネントを修正または隔離することができます。
ランタイム保護とリアルタイムの脆弱性管理を組み合わせることで、AIシステムの継続的な保護が可能になります。これは、AIモデルやその基盤となるコンポーネントが常に進化し、新たな脆弱性が発見される可能性がある動的な環境では特に重要です。
最終的に、これらの機能により、組織はAIシステムのセキュリティを事後対応的ではなく、予防的かつ積極的に管理することができます。
14.3. ゼロデイ脆弱性への対応
Sameer：デプロイ時にこれらの画像をスキャンしましたが、ゼロデイ脆弱性を発見した場合はどうするのでしょうか？環境内に特定の脆弱性が存在するかどうかを確認するために何をすべきでしょうか？
ランタイムモデルスキャンでは、画像がどこにデプロイされたか、それがスキャンされたかどうかを理解できるようにしています。パッケージがスキャンされるとすぐに、私たちはそれに関連するメタデータを持っています。そして明日、その特定のパッケージが脆弱であることが判明した場合、その特定の脆弱性が環境内に存在することを示す検出を迅速に設定できます。これにより、セキュリティチームの検出が容易になります。
最後に、これにはすべてコンテキストが必要です。ランタイム側で何が起こっているか、そしてクラウドがどのように構成されているかの両方です。この2つを組み合わせることで、お客様やセキュリティチームはこれらの特定のリスクに対処するためのより良い情報を得ることができます。
ゼロデイ脆弱性は、AIシステムにとって特に危険な脅威です。これらは既知のパッチがなく、攻撃者が積極的に悪用する可能性がある未知の脆弱性です。このような脆弱性が発見された場合、迅速に対応する能力が極めて重要です。
CrowdStrikeのランタイムモデルスキャン機能は、このプロセスを大幅に効率化します。デプロイされたすべての画像と関連するメタデータを追跡することで、新しい脆弱性が報告された際に、影響を受ける可能性のあるすべてのインスタンスを迅速に特定することができます。
例えば、特定のPyTorchバージョンに重大な脆弱性が発見された場合、このシステムはそのバージョンを使用しているすべてのコンテナを即座に特定し、セキュリティチームにアラートを送ることができます。これにより、対応時間が大幅に短縮され、潜在的な被害を最小限に抑えることができます。
Sameerさんが強調しているように、コンテキストは極めて重要です。ランタイム環境（実際に何が実行されているか）とクラウド構成（それがどのように設定されているか）の両方の情報を持つことで、より包括的なセキュリティ評価が可能になります。
例えば、脆弱なコンポーネントが存在しても、それが適切に隔離されており、機密データにアクセスできない場合、そのリスクは低いかもしれません。一方、同じ脆弱性でも、公共インターネットに露出しており、機密データにアクセスできる場合は、緊急の対応が必要な重大なリスクとなります。
このような包括的なアプローチにより、セキュリティチームは限られたリソースを効果的に割り当て、最も重要なリスクに優先的に対処することができます。
14.4. 統合AIポスチャ管理画面
Sameer：最後に、顧客が統合AIポスチャ画面にアクセスできるようになりました。これは必要なすべての情報を提供します。私のAIモデルはどこにデプロイされているのか、そのうちいくつにセンサーが実行されているのか、脆弱性はあるのか、AIのプライバシーとガバナンスに関連する準拠フレームワークにマッチしているのか、検出があるのか、そして露出しているのかといった情報です。
また、AIMLサービスのための攻撃パスを公開することもできます。モデルやコンテナが機密データにアクセスできる場合、あるいは脆弱性や露出があり、それらが機密データにアクセスできる場合、それらを発見し、そのアクセスがどのように生成されているかについてのコンテキストを提供することができます。
統合AIポスチャ管理画面は、組織のAIセキュリティ状態を包括的に可視化する単一のインターフェースを提供します。これにより、セキュリティチームとIT管理者はAI資産、脆弱性、コンプライアンス状態を一目で確認することができます。
この統合ダッシュボードでは、まずAIモデルのデプロイ場所と、それらのモデル上で実行されているセキュリティセンサーの数が表示されます。これにより、保護されていないAI資産をすぐに特定することができます。
脆弱性の検出も重要な機能です。ダッシュボードは、AIコンポーネントに影響を与える既知の脆弱性を表示し、その重大度とパッチ状態を示します。これにより、最も緊急の対応が必要な問題に優先的に対処することができます。
AIプライバシーとガバナンスのコンプライアンス状態も表示されます。これは、AIシステムが関連する規制や内部ポリシーの要件を満たしているかどうかを評価します。コンプライアンス違反がある場合、それを修正するための推奨事項も提供されます。
特に有用な機能は、AIMLサービスの攻撃パスの可視化です。これにより、機密データにアクセスできる脆弱なコンポーネントや露出したコンポーネントを特定し、そのアクセス経路を視覚的に表示することができます。例えば、公共インターネットに露出したAPIエンドポイントが、脆弱なAIモデルを通じて機密データベースにアクセスできる場合、その経路が明確に示されます。
このような包括的な可視性により、セキュリティチームはAI環境のリスクを効果的に管理し、最も重要な脆弱性に優先的に対処することができます。また、経営陣に対してAIセキュリティ状態を明確に報告するためのツールとしても機能します。
15. AIセキュリティ戦略のベストプラクティス
15.1. サプライチェーンガバナンス
Sameer：ベストプラクティスに移りましょう。パイプラインをいかに保護するか、サービス自体をいかに保護するか、そしてもちろんランタイム層をいかに保護するかについて少し話しました。しかし、これは巨大な戦略の一部に過ぎません。AIセキュリティと戦略には5つの異なる領域が含まれます。
サプライチェーンガバナンスについて話しました。これには、データガバナンス、データ自体のスキャンとスキャン、そのデータのトレーサビリティ、使用されているソフトウェアのトレーサビリティなどが含まれます。これにより、アプリケーション自体のために構築されているすべてのソフトウェアを確実に保護することができます。
サプライチェーンガバナンスは、AIアプリケーションのセキュリティ戦略における基盤的な要素です。これはソフトウェアコンポーネント、データ、そしてモデル自体の出所と整合性を確保するプロセスをカバーしています。
データガバナンスは特に重要な側面です。AIモデルの品質とセキュリティは、それが訓練されるデータに直接依存しています。適切なデータガバナンスには、データソースの検証、データの品質と整合性の確保、そして潜在的に有害なデータを検出するためのスキャンが含まれます。
データとソフトウェアのトレーサビリティは、サプライチェーンガバナンスのもう一つの重要な側面です。これにより、AIアプリケーションのすべてのコンポーネントの出所を追跡し、それらが信頼できるソースからのものであり、改ざんされていないことを確認することができます。
例えば、事前訓練されたモデルを使用する場合、そのモデルがどのように訓練されたか、どのデータセットが使用されたか、そしてどのような検証テストが行われたかを追跡することが重要です。同様に、サードパーティライブラリやフレームワークの場合は、それらの出所、バージョン、そして既知の脆弱性を追跡する必要があります。
サプライチェーンガバナンスを効果的に実装するには、ソフトウェア部品表（SBOM）の作成、依存関係スキャン、脆弱性管理、そして継続的なモニタリングと更新のプロセスが必要です。
この領域におけるベストプラクティスは、AIアプリケーション開発の初期段階からサプライチェーンセキュリティを考慮し、すべてのコンポーネントとデータに対する厳格な検証プロセスを実装することです。
15.2. 開発ライフサイクルセキュリティ
Sameer：二つ目は、開発ライフサイクルで、これには脆弱性評価、モデルガバナンスの理解、そして一般的に人間が関与しない自動化されたMLオペレーションが行われる場所でのプロセスの確保が含まれます。すべてのガードレールが適切に配置されていることを確認します。
開発ライフサイクルセキュリティは、AIアプリケーションの設計から実装、テスト、そしてデプロイメントに至るまでのすべての段階にセキュリティを組み込むことを意味します。これは「セキュリティ・バイ・デザイン」の原則に従い、セキュリティを後付けではなく、開発プロセスの核心に置くものです。
脆弱性評価は、このプロセスの重要な部分です。これには、コードの静的および動的分析、依存関係のスキャン、そしてペネトレーションテストなどが含まれます。AIアプリケーションの場合、これらの評価は従来のセキュリティ脆弱性だけでなく、AI特有の脆弱性（プロンプトインジェクション、モデルポイズニングなど）も対象とする必要があります。
モデルガバナンスは、モデルの開発、トレーニング、評価、そしてデプロイのプロセスを管理し監督するフレームワークです。これには、モデルのパフォーマンス、バイアス、公平性、そして説明可能性の評価が含まれます。効果的なモデルガバナンスにより、AIモデルが期待通りに動作し、予期しない有害な結果を生成しないことを確保できます。
Sameerさんが強調しているように、現代のMLオペレーション（MLOps）は高度に自動化されていることが多いです。これによりスピードと効率が向上する一方で、適切なガードレールがないと、セキュリティリスクが高まる可能性もあります。自動化されたパイプラインには、コード審査、セキュリティテスト、そして承認ステップなどの適切なチェックポイントを含める必要があります。
セキュアな開発ライフサイクルの実装には、明確に定義されたセキュリティ要件、開発者向けのセキュリティトレーニング、コード審査プロセス、自動化されたセキュリティテスト、そして継続的なモニタリングとフィードバックループが含まれます。
このアプローチにより、セキュリティの問題が早期に特定され、修正コストが低く、影響が最小限の段階で対処することができます。これは、AIアプリケーションの全体的なセキュリティとレジリエンスを大幅に向上させます。
15.3. 透明性と責任
Sameer：三つ目は透明性と責任についてです。ほとんどのユーザーはAIの使用を恐れています。なぜなら、それがどのように出力されるか、バイアスがあるかどうか、正確な情報を提供しているかどうかが分からないからです。そこで、どのデータで訓練されているかをユーザーが理解できるようにし、彼らとコミュニケーションする方法を理解し、もちろん特定のトレーニングがどのように行われたかの記録を維持することで、ガバナンスと規制のための可視性、監査可能性、およびトレーサビリティを提供します。
透明性と責任は、AIシステムへの信頼を構築し維持するための鍵となる要素です。ユーザーや利害関係者がシステムの動作原理を理解し、その決定や出力に信頼を置けるようにすることが重要です。
AIモデルの訓練に使用されたデータの透明性は、この取り組みの重要な部分です。ユーザーがモデルが何に基づいて判断や推論を行っているかを理解できるようにすることで、そのモデルの強みと限界を把握することができます。これには、データソース、データ収集方法、前処理ステップ、そして潜在的なバイアスや制限についての情報を提供することが含まれます。
ユーザーとのコミュニケーションチャネルを確立することも重要です。これにより、ユーザーがシステムの動作について質問したり、問題を報告したり、あるいはフィードバックを提供したりする手段が提供されます。効果的なコミュニケーションは透明性を高め、ユーザーの懸念に対応するための重要なメカニズムとなります。
トレーニングプロセスの詳細な記録を維持することは、監査可能性とトレーサビリティのために不可欠です。これには、モデルアーキテクチャ、ハイパーパラメータ、トレーニングデータセット、評価メトリクス、そしてモデルのパフォーマンスと挙動に関するテスト結果などの文書化が含まれます。この情報は、内部審査、規制当局の監査、あるいは外部評価のために重要です。
この透明性と責任のフレームワークにより、AIシステムが倫理的に開発され、使用されていることを証明することができます。これは単なるコンプライアンスの問題ではなく、ユーザーや社会からの信頼を獲得し維持するための戦略的な取り組みです。
AIに特化した規制や基準が世界中で発展するにつれて、透明性と責任のための強固なフレームワークを整備することは、今後ますます重要になるでしょう。
15.4. 敵対的R&D
Sameer：このスペースは非常に急速に変化しています。これは、毎日新たな攻撃手法が発見されていることを意味します。そのため、AI技術に特化した敵対的R&Dチームに投資することが多くのセキュリティチームにとって必要になっています。これは、事前対応型の防御ツールの構築を理解することを意味します。つまり、リスクが発生する前にこれらすべてのことを監視していますが、レッドチーミングのようなことも行っています。モデルは意図した通りに動作しているか、データが漏洩していないかなどを理解します。
そして最後に、効果的なガードレールの研究です。ガードレールは入出力応答を制御し、また、LLMの動作を分類して制御することもできます。
敵対的R&Dへの投資は、進化し続けるAIセキュリティの脅威に対応するための先進的なアプローチです。このスペースは急速に変化しており、新しい攻撃手法が絶えず登場しているため、これらの脅威に関する研究と対策の開発に専念したチームを持つことが非常に価値があります。
事前対応型の防御ツール開発は、この取り組みの重要な側面です。これには、新しい種類の攻撃や脆弱性を予測し、それらが実際の問題になる前に対策を開発することが含まれます。例えば、新しい形のプロンプトインジェクション、モデル抽出攻撃、あるいはデータポイズニング手法などを研究し、それらに対する防御策を開発することが挙げられます。
レッドチーミング（模擬攻撃）活動は、AIシステムのセキュリティを評価する効果的な方法です。セキュリティ専門家がシステムへの攻撃を試みることで、実際の悪意のある行為者によって発見される前に、脆弱性を特定することができます。AIモデルの場合、これにはモデルが機密情報を漏洩するよう操作する試み、バイアスのある結果を引き出す試み、あるいはモデルの機能を回避する試みなどが含まれる可能性があります。
効果的なガードレールの研究も重要な焦点領域です。ガードレールは、AIモデルの入力と出力を監視し制御するメカニズムであり、モデルが安全で適切な範囲内で動作することを確保します。これには、潜在的に有害なプロンプトのフィルタリング、センシティブな情報の保護、そして不適切な出力の防止などが含まれます。
敵対的R&Dへの投資により、組織はAIセキュリティにおける最新動向を把握し、新たな脅威に迅速に対応し、そして究極的には自社のAIシステムの全体的なセキュリティと耐障害性を向上させることができます。
15.5. SOCチームのトレーニング
Sameer：最後に、SOCチームをトレーニングします。もちろん、サイバー対応能力が必要です。これはあなたのモデルが何か悪いことをしたらどうするかということです。インシデント対応方法はありますか？モデル自体に対するDDoS攻撃を受けている場合、インシデント対応方法はありますか？そして、もちろん、モデル自体を使用または悪用しようとしている人に関する脅威インテリジェンスはありますか？
これらすべてが、すでに導入されている特定の戦略の下に包含されています。これには、アクセス制御、クラウドサービスの保護、デバイスとオペレーションのゼロトラストなどが含まれます。
SOCチームのトレーニングは、AIセキュリティ戦略の重要な要素です。従来のセキュリティオペレーションセンター（SOC）チームは一般的なサイバーセキュリティ脅威に対処するようトレーニングされていますが、AIシステムは新たな種類の脅威や対応シナリオをもたらします。
サイバー対応能力は、AIモデルに関連するセキュリティインシデントに効果的に対応するための基礎です。例えば、モデルが機密情報を漏洩した場合、誤った情報を提供した場合、あるいは意図しない有害な出力を生成した場合に、SOCチームがどのように対応すべきかを理解する必要があります。これには、インシデントの検出、影響の評価、封じ込め、そして修復のための明確なプロトコルが含まれます。
AI特有のインシデント対応は、AIワークロードに対する攻撃に対処するための特別な手順の開発を必要とします。例えば、モデルに対するDDoS攻撃は、通常のDDoS攻撃とは異なる特性を持ち、異なる緩和戦略を必要とする可能性があります。同様に、データポイズニング攻撃やモデル抽出攻撃に対するインシデント対応プランも必要です。
脅威インテリジェンスは、AIモデルを悪用しようとする行為者やグループに関する情報を収集し、分析することを含みます。これには、一般的な攻撃手法、既知の脆弱性、そして新たな脅威動向の追跡が含まれます。この情報はSOCチームに提供され、潜在的な攻撃を特定し、事前に対策を講じるのに役立ちます。
Sameerさんが指摘しているように、これらのAI特有のセキュリティ対策は、既存のセキュリティフレームワークと戦略の上に構築されるべきです。アクセス制御、クラウドサービスの保護、ゼロトラストアーキテクチャなどの確立されたセキュリティプラクティスは、AIセキュリティ戦略の基盤となります。
SOCチームに適切なトレーニング、ツール、プロトコルを提供することで、組織はAIセキュリティインシデントに迅速かつ効果的に対応し、潜在的な被害を最小限に抑えることができます。
16. まとめと追加リソース
16.1. AWS連携
Sameer：CrowdStrikeでは、AWSと多くの方法で連携しています。デプロイメント、ランタイム保護、そしてすべてのサービスの監視という点で多くのサービスと統合し、AIアプリケーションも同様に保護できるようにしています。
お選びになる統合はすべてそのGitHubページで利用可能です。もしご覧になりたければ、ここにQRコードがあります。
CrowdStrikeとAWSの連携は、AIアプリケーションを含むクラウドワークロードのセキュリティを包括的に確保するために設計されています。この統合は、デプロイメント、ランタイム保護、監視という3つの重要な側面をカバーしています。
デプロイメントの統合では、CloudFormation、CDK、Terraform などのインフラストラクチャアズコードツールを通じてCrowdStrikeのセキュリティソリューションをシームレスにデプロイできます。これにより、AIアプリケーションの初期設定段階からセキュリティが組み込まれることが保証されます。
ランタイム保護では、CrowdStrikeのソリューションがEC2インスタンス、EKSクラスター、Fargateコンテナなど、様々なAWSコンピューティング環境上で実行されるAIワークロードを保護します。これには、脅威検出、脆弱性管理、ランタイム保護などの機能が含まれます。
監視の面では、CrowdStrikeはAWS CloudTrail、Security Hub、GuardDutyなどのサービスと統合して、包括的なセキュリティ監視とアラートを提供します。これにより、AIアプリケーションに関連するセキュリティイベントやリスクをリアルタイムで検出し対応することが可能になります。
Sameerさんが言及しているGitHubページには、これらの統合を実装するための詳細な情報、コード例、そしてベストプラクティスが含まれています。QRコードを通じてこのリソースにアクセスすることで、ユーザーはCrowdStrikeとAWSの統合を最大限に活用し、AIアプリケーションを効果的に保護するための情報を得ることができます。
16.2. グローバル脅威レポート
Sameer：それでは、いくつかのリソースでまとめたいと思います。グローバル脅威レポートへのアクセスも提供しています。これにより、過去1年間に私たちが行った脅威インテリジェンスと発見事項にアクセスすることができます。
グローバル脅威レポートは、CrowdStrikeが過去1年間に収集した脅威インテリジェンスデータと重要な発見事項を集約した包括的な資料です。このレポートは、AIセキュリティを含む広範なサイバーセキュリティのランドスケープを理解するための貴重なリソースとなっています。
このレポートでは、最新の脅威動向、攻撃手法、新たに出現している脆弱性、そして主要なセキュリティインシデントについての詳細な分析が提供されています。AIセキュリティの文脈では、レポートはLLMやその他のAIシステムを標的とした新しい攻撃手法や、AIに関連するセキュリティリスクについての洞察を含んでいる可能性があります。
また、このレポートは業界や地域ごとの脅威傾向の分析も提供し、組織が自社の環境に最も関連性の高いリスクを理解するのに役立ちます。さらに、将来的な脅威予測や推奨されるセキュリティ対策についての情報も含まれています。
このようなグローバル脅威レポートへのアクセスは、組織のセキュリティ計画立案や戦略的な意思決定において非常に価値があります。最新の脅威動向と攻撃手法を理解することで、組織はより効果的な防御策を実装し、潜在的なセキュリティリスクを事前に軽減することができます。
16.3. Charlotte AIの紹介
Sameer：私たち自身も、セキュリティチームが迅速に行動できるようにするAIアプリケーションを構築しています。Charlotte AIと呼ばれています。みんなが広告を見たことがあると思います。そしてもちろん、まだFalcon Cloud Securityを使用していない場合は、ぜひ使用してください。
それでは、お時間をいただきありがとうございました。質問がある方は、ここに残りますのでどうぞ。
Charlotte AIは、CrowdStrikeが開発した人工知能を活用したセキュリティソリューションです。このAIツールは、セキュリティチームの業務効率化と応答時間短縮を目的として設計されています。広告キャンペーンを通じて業界内で広く知られるようになっているこのソリューションについて、Sameerさんは参加者に紹介しています。
Charlotte AIの主な目的は、セキュリティオペレーションを自動化し、脅威ハンティング、インシデント対応、セキュリティ分析などのプロセスを加速することです。AIを活用することで、Charlotte AIはセキュリティチームが大量のアラートやデータをより効率的に処理し、重要な脅威に迅速に対応できるよう支援します。
まだFalcon Cloud Securityを使用していない聴衆に対しては、このプラットフォームの採用を検討するよう勧めています。Falcon Cloud Securityは、クラウド環境のセキュリティを包括的に保護するためのソリューションであり、本セッションで説明された多くのAIセキュリティ機能を含んでいます。
セッションの最後に、Sameerさんは質問がある参加者のために会場に残ることを伝え、聴衆からの拍手で発表を締めくくりました。これは、参加者がセッションで取り上げられたトピックについてさらに詳細な情報を得る機会を提供するものです。