この記事は KINTOテクノロジーズ Advent Calendar 2025 の7日目の記事です🎅🎄

はじめに

こんにちは、KINTO テクノロジーズ Cloud Security グループの多田です。普段は大阪 (Osaka Tech Lab) で勤務しています。

我々が開発する多くのサービスは、Amazon Web Services 上で開発していますが、昨今は生成 AI の活用も盛んで、OpenAI の利用に伴い、Microsoft Azure での開発も増えてきました。

本記事では、Azure Container Apps におけるワークロード保護の必要性から、Microsoft Defender for Cloud の限界、そして Sysdig Serverless Agent を用いた実践的な保護手法について、解説します。

Azure Container Apps とは？

Azure Container Apps（以下、ACA）は、Microsoft が提供するサーバーレス型のコンテナ実行環境です。ACA の詳細については、Microsoft のドキュメントを参照してください。

セキュリティ上の特徴としては、Kubernetes ベースのマネージドサービスであり、基盤レイヤー（ノード、ネットワーク、OS）のセキュリティは Microsoft の責任範囲となることです。一方で、アプリケーション層（コンテナワークロード）のセキュリティはユーザー側の責任となります。

この「共有責任モデル」においてアプリケーション層のワークロード保護をどう実現するかが、本記事の内容となります。

なぜワークロード保護が必要なのか？

サーバレスな環境であっても、以下のようなセキュリティリスクは依然として存在します。

• コンテナイメージの脆弱性
• ランタイムの脅威
• 設定ミスや過剰な権限

特に、ランタイムの脅威については、以下のような脅威を検知し対処する必要があります。

• 暗号通貨マイニングの検知・防止
• コンテナドリフト（不正な変更）の防止
• 不正なネットワーク通信の検知・防止
• リバースシェル実行のブロック
• ファイルレス実行の検知

これらの脅威に対処するため、ランタイムでの継続的な監視と脅威検知が不可欠となります。

ちなみに、ACA のセキュリティ機能については、こちらを参照してください。

Microsoft Defender for Cloud ではワークロード保護ができるのか？

結論から言うと、2025年11月時点では、Defender for Containers は ACA をサポートしていません。

Microsoft Defender for Containers は、Azure Kubernetes Service や Azure Container Registry、AWS EKS、Google GKE などに対応しています。詳細なサポート範囲については、こちらを参照してください。

つまり、アプリケーション層のワークロード保護を実現するには、サードパーティ製品の導入が推奨される ということになります。

Sysdig Serverless Agent によるワークロード保護

KINTO テクノロジーズでは、発見的ガードレール（CSPM）など、クラウドセキュリティの運用に Sysdig Secure を利用しています。
Sysdig Secure をどのように活用しているかは、過去にいくつかブログを投稿していますので、よろしければ検索してみてください。一番新しいものだと、「LLM アプリケーションのセキュリティを保護する AI-SPM の取組み」を投稿しています。

ACA のワークロード保護についても、Sysdig Secure が提供する Serverless Agent を利用して保護する取組みを進めています。

Sysdig Serverless Agent とは？

Sysdig Serverless Agent は、サーバレス環境向けに設計されたランタイムセキュリティエージェントです。コンテナワークロードの監視、脅威検知等を実施することができます。

ACA への Serverless Agent のインストールや設定については、SCSK 株式会社さんのブログで丁寧に解説されていますので、そちらを参照してください。Serverless Agent についてイメージがつくと思います。

Serverless Agent は、ホストのカーネルにアクセスできないサーバレス環境において、ユーザスペースレベルの監視を行います。

詳細なアーキテクチャについては、Sysdig のドキュメントを参照してください。

この仕組みの重要なポイントは、コンテナの ENTRYPOINT で起動されたプロセスツリーのみが監視対象となる点です。そのため、docker exec 経由で生成されたシェルや子プロセスはこの監視対象ツリーの外部で生成されるため、システムコールレベルの挙動として検知されません。

Serverless Agent の検知の盲点

前述の通り、Serverless Agent は ENTRYPOINT で起動されたプロセスツリーを監視対象としています。攻撃者が何らかの方法（脆弱性悪用、認証情報搾取等）で、Azure コンソールや CLI へのアクセス権を取得した場合、以下のコマンドでコンテナ内部にアクセスできます。

az containerapp exec --name hogehoge-containerapp --resource-group hogehoge-resourcegroup --exec-command "/bin/bash"

このように、コンテナ内部にアクセスできれば、Serverless Agent に検知されることなく、不正なアクティビティが可能となります。

では、exec 経由の攻撃をどう検知するか？

exec 経由の攻撃は、Serverless Agent では検知できないため、Azure Activity Log（監査ログ）に記録される exec 操作そのものを検知することで、攻撃の予兆を検知します。

Sysdig Secure には、Cloud Detection and Response と呼ばれる機能があり、監査ログをリアルタイムに監視することができます。

Sysdig の Cloud Detection and Response は、Falco による脅威検知を実施しています。az containerapp exec コマンドの実行や、Azure コンソール経由での exec を実施すると、Azure Activity Log には、以下のイベントが記録されます。

Microsoft.App/containerApps/getAuthToken/action

このイベントを Falco ルールで検知することで、exec 操作をリアルタイムに検知できます。Falco ルールは以下となり、Azure コンソール及び CLI 経由での exec を検知できるので、無許可の exec 操作があれば確認するなどの運用を実施することで対応が可能となります。

rules:
  - rule: Detect Azure ContainerApp AuthToken Succeeded
    desc: Detect when Azure Activity Log shows Microsoft.App/containerApps/getAuthToken/action with status Succeeded
    condition: >
      evt.type = "open" and
      json.value["operationName.value"] = "Microsoft.App/containerApps/getAuthToken/action" and
      json.value["status.value"] = "Succeeded"
    output: >
      Azure ContainerApp AuthToken request succeeded
      (operation=%json.value["operationName.value"], status=%json.value["status.value"], caller=%json.value["caller"])
    priority: WARNING
    source: json
    tags: [azure, containerapp, auth, security]

まとめ

本記事では、Azure Container Apps におけるワークロード保護の実践的なアプローチを解説しました。

• Defender for Cloud は、Azure Container Apps に未対応
• Sysdig Serverless Agent のようなサードパーティ製品でのワークロード保護が有効
• Serverless Agent には、仕組み上、検知の盲点が存在する場合があるため、その理解が重要
• 盲点については、多層防御で脅威を検知し、カバレッジを高めることが大切

今回は、Azure Container Apps　におけるワークロード保護について記載しました。

我々、Cloud Security グループは、マルチクラウド環境におけるセキュリティについて、日々実践しています。今後も当グループの取り組みをご紹介していきたいと思います。

最後までお読みいただきありがとうございました。