はじめに

こんにちは、KINTO テクノロジーズ Security CoE グループの多田です。普段は大阪のオフィスで勤務しています。我々のグループでは、マルチクラウド環境の「ガードレール監視とカイゼン活動をリアルタイムで実施する」をミッションに、クラウドセキュリティに関する多くのことにチャレンジしています。メンバが日々、どのような活動を実施しているかは、こちらのブログにもまとめていますので、ぜひご覧ください。

背景

世間の LLM ( 大規模言語モデル ) アプリケーション開発の流れに乗り、当社のプロダクトチームでは、多くの LLM アプリケーションを開発しており、PoC やプロダクトレディの状態に進展しています。一方で、クラウドセキュリティを監視するグループとしては、これらのアプリケーションのセキュリティについても適切な対策を講じる必要があります。

当社の LLM アプリケーションは、主に AWS、Google Cloud、Azure 上で開発されており、クラウドベンダーが提供する生成 AI サービスを活用して構築されることが多い状況です。当グループでは Cloud Security Posture Management ( CSPM ) の監視および運用を行っています。しかし、現時点では、生成 AI 関連サービスに特化した CSPM のコントロールは提供されていないのが現状です。例えば、AWS の場合、AWS Foundational Security Best Practices ( FSBP ) や Center for Internet Security ( CIS ) では、生成 AI サービスに関する直接的なコントロールが提供されていません。

そこで当グループでは、各クラウドベンダーの生成 AI サービスを利用して LLM アプリケーションを開発する際に遵守すべきガイドラインを策定しました。このガイドラインには、クラウドベンダーが提供する生成 AI 関連サービスの利用推奨や設定方法についても記載しています。言い換えれば、ガイドラインに記載した設定方法は、CSPM として監視すべきコントロールとなります。さらに、コントロールを Rego 言語 で実装し、AWS Bedrock の CSPM として運用を行っています。

タイトルにある、AI-SPM は、AI Security Posture Management の略で、「 AI や機械学習 ( ML ) 、生成 AI モデルなどの AI 関連資産のセキュリティリスクやコンプライアンスリスクを可視化・管理・軽減するためのソリューション」というような定義がされているようなので、今回の取組みについても、あえて、AI-SPM という名前にしてみました。

LLM アプリケーションで遵守すべきセキュリティガイドライン

ガイドラインを作成するにあたっては、OWASP Top 10 for LLM Applications 2025 を参考にしました。おそらく、LLM アプリケーションのセキュリティを語るうえでは、最早、鉄板ともいうべき資料かと思います。この OWASP の資料では、LLM アプリケーションでよく見られる最も重大な脆弱性 Top 10 がリストされており、「概要」「脆弱性の例」「防御や軽減策」「攻撃シナリオ」などが記載されています。これらの内容を基に、各クラウドサービスで LLM アプリケーションを開発する場合、利用するサービス、機能の選定やベストプラクティスについて検討を行いました。

Top 10 の最初に記載のあるリスクは「 LLM01：Prompt Injection 」です。

このリスクは、悪意ある入力によって LLM の振る舞いが意図せず操作され、情報漏洩や不正な動作を引き起こすリスク です。このリスクの予防・緩和策としては、LLM への入力の検証・フィルタリング が有効となります。
そして、この予防・緩和策をクラウドサービス上で実装する場合にどうすべきかというと、AWS であれば、Amazon Bedrock Guardrails に Prompt Attack をフィルタする機能があるので、この機能を有効化することが対策となります。あとは、CSPM のコントロールとして、この機能が有効化されているかどうかをチェックすることで、可視化とカイゼンが実施できるようになります。

以下に、Top 10 の中の代表的なリスクと AWS サービスでの「予防・緩和策」と「 CSPM コントロールとしての実装」をまとめますので参考にしてください。

上記の内容については、5 月に実施した共催イベント Cloud Security Night #2 で登壇していますので、こちらの資料も参考していただければと思います。

Rego による CSPM コントロールの実装

CSPM のコントロールの定義はできたので、コントロールの内容をチェックする仕組みを開発していきます。当グループでは、CSPM の運用に、AWS であれば、Security Hub、Google Cloud であれば、Sysdig、Azure であれば Defender for Cloud を利用しています。もちろん、統合したツールを使う方が良いのでしょうが、コンソールをゴリゴリ使うというよりは、それぞれ、API 等を通じて、CSPM のアラート状況を確認し、必要に応じてSlack 通知するなどしていますので、ツールが統合されてないことに不自由は感じていません。

LLM アプリケーションの CSPM コントロールについては、Sysdig の CSPM 機能で利用されている Rego で開発することにしました。Rego を採用した理由は、OSS であることと CSPM のようなクラウドインフラの設定の判定ロジックを記載するのであれば、それほど学習コストも必要なく開発できると思ったからです。

以下が LLM01：Prompt Injection コントロールを Rego で実装したものになります。やってることは、risky == true ( リスクあり ) をデフォルト値に設定し、Bedrock Guardrails の設定 ContentPolicy.Filters の値が Type == PROMPT_ATTACK と InputStrength==HIGH であれば、Prompt attack が有効化され、閾値が High に設定されているとして、risky == false とし、リスクなしと判断しています。

default risky := true

risky := false if {
	some filter in input.ContentPolicy.Filters
    lower(filter.Type) == "prompt_attack"
    lower(filter.InputStrength) == "high"
}

この Rego を Sysdig のカスタムコントロールとして、Sysdig にデプロイする必要があります。詳細なカスタムコントロールの作成方法やデプロイ手順については、Sysdig 公式ブログで紹介されていますので、こちら を参考にしてください。我々もこちらを参考にすることで開発を進めました。本ブログに記載していませんが、カスタムコントロールを作成するにあたっての多くのノウハウも貯まりました。

カスタムコントロールは、Sysdig に terraform としてデプロイする必要があります。以下が最終的に作成したカスタムコントロールの main.tf になります。

terraform {
    required_providers {
        sysdig = {
            source = "sysdiglabs/sysdig"
            version = ">=0.5"
        }
    }
}
variable "sysdig_secure_api_token" {
  description = "Sysdig Secure API Token"
  type        = string
}
provider "sysdig" {
    sysdig_secure_url="https://app.us4.sysdig.com"
    sysdig_secure_api_token = var.sysdig_secure_api_token
}
resource "sysdig_secure_posture_control" "configure_prompt_attack_strength_for_amazon_bedrock_guardrails" {
  name = "Configure Prompt Attack Strength for Amazon Bedrock Guardrails"
  description = "Ensure that prompt attack strength is set to HIGH for your Amazon Bedrock guardrails. Setting prompt attack strength to HIGH in guardrails helps protect against malicious inputs designed to bypass safety measures and generate harmful content."
  resource_kind = "AWS_BEDROCK_GUARDRAIL"
  severity = "High"
  rego = <<-EOF
    package sysdig
    
    import future.keywords.if
    import future.keywords.in

    default risky := true

    risky := false if {
		  some filter in input.ContentPolicy.Filters
    	  lower(filter.Type) == "prompt_attack"
    	  lower(filter.InputStrength) == "high"
      }
  EOF
  remediation_details = <<-EOF
    ## Remediation Impact
    This control will help you ensure that your Amazon Bedrock guardrails are configured with high prompt attack strength, which is crucial for protecting against malicious inputs designed to bypass safety measures and generate harmful content.

    ## Remediation Steps
    1. Navigate to the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/home).
    2. Select the guardrail you want to modify.
    3. In the guardrail settings, locate the "Content Policy" section.
    4. Ensure that the "Prompt Attack" filter is set to "High" for the "Input Strength".
    5. Save the changes to the guardrail configuration.
    6. Repeat this process for any other guardrails in your AWS environment.

    ## Remediate Using Command Line
    You can use the AWS CLI to update the guardrail configuration. Run the following command to set the prompt attack strength to HIGH for a specific guardrail:

    ```bash
    aws bedrock update-guardrail --guardrail-id <guardrail-id> --content-policy '{"Filters": [{"Type": "prompt_attack", "InputStrength": "high"}]}'
    ```
    Replace `<guardrail-id>` with the ID of your guardrail.
    Repeat this command for other guardrails in your AWS environment.
    
    ## Additional Information
    For more information on configuring Amazon Bedrock guardrails, refer to the [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html).

    ## Contact Information
    Slack Channel: #security-coe-group
  EOF
}

実は当初、Sysdig は、CSPM の対象リソースとして Amazon Bedrock をサポートしていませんでした。Sysdig に相談したところ、ものすごい速さで対応いただき、今回の取組みに繋がりました。機能的な部分の満足度もありますが、この辺りのスピード感は、Sysdig ユーザとして非常に心強いです。

あとは、同じ要領で、LLM アプリケーションで遵守すべきセキュリティガイドライン に記載したコントロールをいくつか Rego で実装し、Sysdig にデプロイしています。

Sysdig による AI-SPM 運用

デプロイしたいくつかのカスタムコントロールは、カスタムポリシーとして定義し、AWS Bedrock リソースを可視化しています。可視化の結果、問題があれば、カイゼンするという運用になります。当社の場合、当グループからプロダクト開発グループに対して、カイゼン依頼を行いますが、その時に、カイゼン方法と合わせて、カイゼン依頼をするようにしています。

下の画面は、Sysdig コンソール画面で、LLM01：Prompt Injection の CSPM コントロールを確認している画面となります。コントロール名は、Configure Prompt Attack Strength for Amazon Bedrock Guardrails です。名前は、それっぽく、こちらで付けています。状況としては、AWS Bedrock Guardrail のリソースが 3 つ存在し、1 つが Failling、残り 2 つが Passing していることを示しています。

上記画面をドリルダウンすることで、カイゼンの影響やカイゼン方法などを参照することができます。こちらの内容も main.tf に記載した内容が反映されています。

ただ、実際の運用では、Sysdig コンソール画面にアクセスすることはそれほどなく、アラートの確認等はSysdig API を経由して確認するようにしています。

まとめ

今回は、LLM アプリケーションのセキュリティ対策として、Amazon Bedrock の 設定のチェックロジックを Rego で開発し、Sysdig で運用する方法についてご紹介しました。ガイドラインでは、Amazon Bedrock だけでなく、Azure AI Foundry や Google Cloud Vertex AI も整理しているため、今後は、同様に Rego の開発、Sysdig による運用を進めていきます。

また、従来の CSPM に加え、AI-SPM では、クラウドインフラ全体のセキュリティに留まらず、AI 固有の課題やデータ資産の保護など、従来の CSPM ではカバーしきれない領域にも取り組む必要があります。AI 技術は急速に進化しており、最近では MCP や A2A などの新しい概念が登場しています。これらの進展に対応したセキュリティ対策を推進していくことも重要です。

今後も新しい技術や課題に追随しながら、AI アプリケーションのセキュリティを強化する取り組みを続けていきます。

さいごに

Security CoE グループでは、一緒に働いてくれる仲間を募集しています。クラウドセキュリティの実務経験がある方も、経験はないけれど興味がある方も大歓迎です。お気軽にお問い合わせください。

詳しくは、 こちらをご確認ください。