LLMアプリケーションのためのOWASP Top 10とは？

OWASPとは——それは何者なのか？

「OWASPは、ソフトウェアセキュリティの向上を目的とする非営利団体です。オープンソースのコミュニティ主導プロジェクトや、世界各地のローカルチャプター、多くのメンバー、教育・トレーニング関連のカンファレンスなどを通じて、開発者や技術者がWebセキュリティを高めるための情報拠点となっています。」

OWASP.org

OWASPの活動を支える3つの柱：

冒頭でも触れたように、OWASPの活動は次の3つの領域に分類されます。

• ツールとリソース(Tools and Resources)
• コミュニティとネットワーキング(Community and Networking)
• 教育・トレーニング(Education & Training)

Kubernetesのための OWASP Top 10

以前の投稿では、クラウドネイティブなコンテナオーケストレーションプラットフォームであるKubernetesに特化した、専用のOWASP Top 10が必要である背景について解説しました。以下に挙げるコントロール項目は、Kubernetesを用いて本番環境でWebアプリケーションをデプロイ・保護する際の、オーケストレーションレイヤーに完全に焦点を当てたものです。

これは、より広い範囲を対象とする「クラウドネイティブアプリケーションのためのOWASP Top 10」とは区別する必要があります。後者は、クラウドプロバイダー自体の保護や、関連するクラウドサービス、それらサービス内でのアセット管理、さらにはアプリケーション層・クラウドイベント・クラウドサービスにおける潜在的なインジェクションの欠陥といった、より広範なユースケースを扱うものです。

Kubernetes向けOWASP Top 10の最新版は、2024年にいくつかの軽微な更新が加えられ、以下の項目で構成されています。

K01: 安全性の低いワークロード構成(Insecure Workload Configurations)

K02: サプライチェーンの脆弱性(Supply Chain Vulnerabilities)

K03: 過度に許可的なRBAC構成(Overly Permissive RBAC Configurations)

K04: 集中的なポリシー適用の欠如(Lack of Centralized Policy Enforcement)

K05: 不十分なログ記録とモニタリング(Inadequate Logging and Monitoring)

K06:不備のある認証メカニズム(Broken Authentication Mechanisms)

K07: ネットワークセグメンテーション制御の欠如(Missing Network Segmentation Controls)

K08: シークレット管理の不備(Secrets Management Failures)

K09: 誤って構成されたクラスターコンポーネント(Misconfigured Cluster Components)

K10: 古く脆弱性のあるKubernetesコンポーネント(Outdated and Vulnerable Kubernetes Components)Outdated and Vulnerable Kubernetes Components

LLMワークロードは、コンテナオーケストレーションによるスケーラビリティの利点を活かすため、Kubernetesクラスター上にデプロイされることが多くあります。そのため、LLMベースのワークロード特有のベストプラクティスと、それらが稼働する環境——コンテナ、Kubernetes、クラウド——に関するベストプラクティスとの間には、しばしば重なりが生じます。これは、LLM向けのOWASP Top 10を形成する上で、非常に理にかなった土台となります。

CISOにとってのAIワークロード保護の緊急性  

詳しく見る

LLMのためのOWASP Top 10

LLMのためのOWASP Top 10(大規模言語モデル)は、LLMベースのAI技術を活用したアプリケーションやプラグインの設計・構築を任されている開発者、データサイエンティスト、セキュリティ専門家が対応すべき、最も一般的な領域を優先順位付けしてまとめたリストです。以下では、これらの領域を一つずつ挙げ、それぞれが何を意味するのかを簡単に説明します。

LLM01: プロンプトインジェクション(Prompt Injection)
プロンプトインジェクションの脆弱性は、攻撃者が巧妙に作り込んだ入力を使ってLLMを操作することで発生します。その手法には、システムプロンプトを直接上書きする方法(いわゆる「ジェイルブレイク」)と、Webサイトやファイルなどの外部ソースを介した間接的な方法があります。これにより攻撃者はLLMの挙動を制御できるようになり、データ漏えい、プラグインの不正利用、ソーシャルエンジニアリング攻撃などにつながる可能性があります。より高度なケースでは、LLMが標準的な安全対策を意図せず回避してしまい、ユーザーに警告を発したりセキュリティ対策を作動させたりすることなく、攻撃者の目的達成を助けてしまうこともあります。

LLM02: 安全でない出力の処理(Insecure Output Handling)
LLMが生成した出力が、後続のシステムに渡される前に適切に検証・サニタイズされていない場合、プログラムはビジネスに対する脆弱性を露呈するおそれがあります。プロンプトの入力によってLLMが生成するコンテンツを制御できてしまうため、このリスクは、ユーザーに間接的に追加機能へのアクセスを許してしまうことと似た性質を持ちます。安全でない出力処理を悪用されると、XSS、CSRF、SSRF、権限昇格、リモートコード実行といった攻撃につながる可能性があります。この影響は、LLMに過剰な権限が付与されている場合、アプリケーションが間接的なプロンプトインジェクションに対して脆弱な場合、またはサードパーティ製プラグインが入力を適切に検証していない場合に、さらに大きくなります。例えば、LLMの出力がシステムシェルに直接入力されたり、execやevalといった関数に渡されたりすると、リモートコード実行につながる可能性があります。

LLM03：学習データの汚染(Training Data Poisoning)

機械学習における「データポイズニング」とは、学習データの操作や、ファインチューニングや埋め込み処理で使用されるデータセットの操作を指し、これによってバックドアが仕込まれたり、モデルのセキュリティ・有効性・倫理的な振る舞いを損なうバイアスが生じたりする可能性があります。汚染されたデータは、有害な出力、性能の低下、さらには企業の信用失墜にもつながりかねません。この攻撃はモデルが正確な予測を生成する能力に影響を及ぼすものであり、虚偽の情報や偏った内容を含みうる外部データソースを学習に用いる場合には特にリスクが高く、モデルに対する完全性)への攻撃と言えます。

LLM04：モデルのサービス拒否(Model Denial of Service)

攻撃者は、LLMに過剰なリソースを消費させることで、ユーザー向けのサービス品質を低下させたり、高額なコストを発生させたりする可能性があります。これは、他のWebアプリケーションに対するDoS/DDoS攻撃と本質的に変わりません。LLMベースのWebアプリケーションの場合、特に懸念が高まっているのは、LLMのコンテキストウィンドウを操作する攻撃です。これにより、プログラムの挙動が予測不能になる可能性があります。LLMがリソースを多く消費するアプリケーションで使われる場面が増える中、この脆弱性——モデルのアーキテクチャに起因し、モデルが一度に処理できる入力・出力の量を規定するもの——について、多くの開発者はまだ十分に認識していません。

LLM05：サプライチェーンの脆弱性(Supply Chain Vulnerabilities)

LLMのサプライチェーンは、Kubernetesのサプライチェーンコンポーネントと同様に、攻撃に対して脆弱です。古くなったサプライチェーンコンポーネントが悪用されると、学習モデルの完全性が損なわれる可能性があります。偏った結果を招くだけでなく、組織はこうした脆弱性の悪用によって、直接的なセキュリティ侵害やシステム障害に見舞われることもあります。従来のソフトウェアの脆弱性とは異なり、機械学習プログラムには、事前学習済みモデルやサードパーティのデータに起因するリスクが存在し、これらは改ざんや汚染の対象となり得ます。さらに、LLMプラグインの拡張機能も追加のリスクをもたらします。これについては「LLM07:安全でないプラグイン設計」で詳しく取り上げており、プラグインの安全な開発と、サードパーティ製プラグインに対する徹底した評価の必要性が指摘されています。

LLM06：機密情報の漏えい(Sensitive Information Disclosure)

LLMアプリケーションは、その出力を通じて、機密情報、独自のアルゴリズム、または非公開の詳細情報を意図せず露出させてしまう可能性があり、セキュリティ侵害やプライバシー侵害につながります。このリスクを軽減するには、機密性の高いユーザーデータが学習モデルに取り込まれないよう、適切なデータのサニタイズを行う必要があります。また、データ処理の内容やオプトアウトの選択肢について、明確な利用規約でユーザーに知らせるべきです。LLMへの入力・出力のいずれも完全に信頼することはできないため、システムプロンプト内に制限を設けることでデータ漏えいを減らす助けにはなりますが、LLMの予測不能な性質上、こうした対策だけでは機密情報の漏えいを常に防げるわけではありません。

LLM07：安全でないプラグイン設計(Insecure Plugin Design)

LLMプラグインは、ユーザーとのやり取りの中で自動的に起動する拡張機能であり、特にサードパーティによってホストされている場合、アプリケーション側の制御が及ばないことが多くあります。これらのプラグインは、検証を行わずに自由形式のテキスト入力を受け付けてしまうことがあり、攻撃者が悪意のあるリクエストを送信できてしまう結果、データ侵害、リモートコード実行、権限昇格などにつながる可能性があります。プラグインが十分なアクセス制御を備えておらず、認可の確認を行わずに他のプラグインやユーザーからの入力を無条件に信頼してしまう場合、このリスクはさらに高まります。この脆弱性は、サードパーティ製プラグインのリスクとは区別される、LLMプラグイン自体の作成に特化した問題を指します。

LLM08：過剰な代理行動(Excessive Agency)

これは、LLMベースのシステムに過剰な機能、権限、または自律性が与えられ、予期しない、あるいは曖昧な出力に対して被害をもたらす行動を取れてしまう状態を指します。この問題は、ハルシネーション、プロンプトインジェクション、悪意のあるプラグイン、設計の甘いプロンプトといった要因によって引き起こされることがあります。LLMの出力そのものを精査する「安全でない出力の処理」とは異なり、「過剰な代理行動」は、システムが十分な監督を受けずに行動を実行できてしまう能力そのものに起因します。その影響は、LLMがどのシステムと連携しているかによって、機密性の侵害からシステムの完全性・可用性の侵害まで多岐にわたります。Sysdigは、実際のWebアプリケーションにおいて「過剰な代理行動」がどのように悪用されるかを検証・報告しています。

LLM09：過度な依存(Overreliance)

事前学習済みモデルに過度に依存すると、モデルが権威ありげに聞こえるものの、実際には誤っている、あるいは安全でない情報を生成してしまう、「コンファビュレーション(作話)」と呼ばれる問題によって、重大な支障が生じる可能性があります。例えば、事前学習済みモデルが生成した欠陥のあるソースコードが、適切なレビューを経ずに別のWebアプリケーションへ組み込まれてしまった場合、重大なセキュリティ上の脆弱性を生じさせるおそれがあります。このリスクは、厳格な監督、継続的な検証の仕組み、そして潜在的な不正確性についての明確な免責事項が明らかに必要であることを示しています。

LLM10：モデルの盗用(Model Theft)

悪意ある第三者によるLLMモデルへの盗用は、これらのモデルが貴重な知的財産であることから、重大なセキュリティリスクとなります。LLMモデルが侵害され、コピーされたり、その重みやパラメータが抽出されたりすると、ブランドの信用に大きな損害を与えるだけでなく、さらに悪い場合には、攻撃者によってモデルの機密データが公に晒されてしまう可能性もあります。このリスクを軽減するために、組織はより強固なアクセス制御を実施するとともに、通信中のトラフィックだけでなく、保存データについても暗号化を行うことができます。LLM向けOWASP Top 10に挙げられている他のすべてのコントロールと同様に、LLMモデルにおけるドリフト(挙動の変化)を適切に把握し、最終的には自社の知的財産を守るためには、継続的な監視が必要です。

LLMjackingの深まる脅威——進化する手口と制裁回避の実態                                

詳細を読む

‍

セキュリティ&ガバナンス チェックリスト

OWASPチームは、CISO(最高情報セキュリティ責任者)や他のセキュリティリーダーが、組織内で生成AI(Gen AI)技術を管理する際の助けとなるセキュリティ&ガバナンスチェックリストを発表しました。この新しいテクノロジーへの備えについて不安を抱く企業が多い中、この「LLMアプリケーションのためのOWASP Top 10チェックリスト」は、経営層、技術、サイバーセキュリティ、プライバシー、コンプライアンス、法務といった各領域にわたるガイダンスを提供します。このリソースは、安全性の低い実装に伴うリスクを軽減しながら、急速に進むAIの進化に対応しようとする人々のために設計されています。業界がまだ堅牢なAIガバナンスの実現に向けた競争の途上にある中、このチェックリストは、リーダーやチームがLLMのリスクとメリットを理解し、進化を続ける脅威に対する防御戦略を強化する助けとなります。

次のステップ

LLMアプリケーションのためのOWASP Top 10について理解が深まったところで、いよいよAIワークロードのセキュリティ強化に向けた取り組みを一歩進めていきましょう。この分野への理解をさらに深めるために、OWASPコミュニティへの参加を検討することをお勧めします。OWASP Slackに登録し、ワーキンググループの**#project-top10-for-llm**チャンネルに参加することで、最新情報を追いながら、この分野に携わる他のメンバーと協力することができます。

また、Sysdigの脅威リサーチチームが発見した、LLMを標的とする攻撃手法である「LLMjacking」についても、ぜひブログ記事をご覧ください。