[![Logo](https://www.paloaltonetworks.com/wp-content/uploads/2021/07/PANW_Parent.png)](https://www.paloaltonetworks.jp/) [![Unit42 Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/unit42-logo-white.svg)](https://unit42.paloaltonetworks.com/ja/) Menu * [セキュリティ コンサルティング](https://www.paloaltonetworks.com/unit42) * [**現在、攻撃を受けていますか?**](https://start.paloaltonetworks.com/contact-unit42.html) Japanese * [English](https://unit42.paloaltonetworks.com/container-escape-techniques/) * [Japanese](https://unit42.paloaltonetworks.com/ja/container-escape-techniques/) * [Threat Research Center](https://unit42.paloaltonetworks.com/ja/ "Threat Research") * [脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/ "脅威リサーチ") * [クラウド サイバーセキュリティ リサーチ](https://unit42.paloaltonetworks.com/ja/category/cloud-cybersecurity-research-ja/ "クラウド サイバーセキュリティ リサーチ") [クラウド サイバーセキュリティ リサーチ](https://unit42.paloaltonetworks.com/ja/category/cloud-cybersecurity-research-ja/) # コンテナー エスケープ: クラウド環境でコンテナーから脱出する技術 ![Clock Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-clock.svg) 6 分で読めます Related Products [![Code to Cloud Platform icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/prisma_RGB_logo_Icon_Color.png)Code to Cloud Platform](https://unit42.paloaltonetworks.com/ja/product-category/code-to-cloud-platform-ja/ "Code to Cloud Platform")[![Cortex icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/cortex_RGB_logo_Icon_Color.png)Cortex](https://unit42.paloaltonetworks.com/ja/product-category/cortex-ja/ "Cortex")[![Cortex XSIAM icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/cortex_RGB_logo_Icon_Color.png)Cortex XSIAM](https://unit42.paloaltonetworks.com/ja/product-category/cortex-xsiam-ja/ "Cortex XSIAM")[![Prisma Cloud icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/prisma_RGB_logo_Icon_Color.png)Prisma Cloud](https://unit42.paloaltonetworks.com/ja/product-category/prisma-cloud-ja/ "Prisma Cloud") * ![Profile Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-profile-grey.svg) 著者: * [Bar Ben-Michael](https://unit42.paloaltonetworks.com/ja/author/bar-ben-michael/) * [Yosef Yaakov](https://unit42.paloaltonetworks.com/ja/author/yosef-yaakov/) * ![Published Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-calendar-grey.svg) 公開日:2024年7月18日 * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-category.svg) カテゴリー * [クラウド サイバーセキュリティ リサーチ](https://unit42.paloaltonetworks.com/ja/category/cloud-cybersecurity-research-ja/) * [脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-tags-grey.svg) タグ: * [Cloud infrastructure](https://unit42.paloaltonetworks.com/ja/tag/cloud-infrastructure-ja/) * [Container](https://unit42.paloaltonetworks.com/ja/tag/container-ja/) * [Container escape](https://unit42.paloaltonetworks.com/ja/tag/container-escape-ja/) * [Container security](https://unit42.paloaltonetworks.com/ja/tag/container-security-ja/) * [Docker](https://unit42.paloaltonetworks.com/ja/tag/docker-ja/) * [Kubernetes](https://unit42.paloaltonetworks.com/ja/tag/kubernetes-ja/) * [![Download Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-download.svg)](https://unit42.paloaltonetworks.com/ja/container-escape-techniques/?pdf=download&lg=ja&_wpnonce=5f0cc26d8b "Click here to download") * [![Print Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-print.svg)](https://unit42.paloaltonetworks.com/ja/container-escape-techniques/?pdf=print&lg=ja&_wpnonce=5f0cc26d8b "Click here to print") 共有![Down arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/down-arrow.svg) * ![Link Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-share-link.svg) * [![Link Email](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-sms.svg)](mailto:?subject=コンテナー%20エスケープ:%20クラウド環境でコンテナーから脱出する技術&body=Check%20out%20this%20article%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fja%2Fcontainer-escape-techniques%2F "Share in email") * [![Facebook Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-fb-share.svg)](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Funit42.paloaltonetworks.com%2Fja%2Fcontainer-escape-techniques%2F "Share in Facebook") * [![LinkedIn Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-linkedin-share.svg)](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fja%2Fcontainer-escape-techniques%2F&title=コンテナー%20エスケープ:%20クラウド環境でコンテナーから脱出する技術 "Share in LinkedIn") * [![Twitter Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-twitter-share.svg)](https://twitter.com/intent/tweet?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fja%2Fcontainer-escape-techniques%2F&text=コンテナー%20エスケープ:%20クラウド環境でコンテナーから脱出する技術 "Share in Twitter") * [![Reddit Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-reddit-share.svg)](https://www.paloaltonetworks.com//www.reddit.com/submit?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fja%2Fcontainer-escape-techniques%2F&ts=markdown "Share in Reddit") * [![Mastodon Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-mastodon-share.svg)](https://mastodon.social/share?text=コンテナー%20エスケープ:%20クラウド環境でコンテナーから脱出する技術%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fja%2Fcontainer-escape-techniques%2F "Share in Mastodon") ## 概要 本稿では、コンテナー エスケープ技術を確認し、それらの影響を評価し、エンドポイント検出・対応 (EDR) の観点からエスケープを検出する方法を明らかにします。 クラウド サービスの人気とともに、コンテナー利用数も増加しており、コンテナーはいまやクラウド インフラに組み込まれた部品の 1 つとなりました。多くの利点をもつコンテナーですが、それでも攻撃技術の影響は受けます。そうした攻撃技術の 1 つがコンテナー エスケープ (container escape: コンテナーからの脱出) です。 多くのコンテナーはインターネットに接続されていることから、セキュリティ リスクはいっそう高まります。たとえばコンテナーへの低い権限のアクセスを取得した外部攻撃者は、構成ミスや脆弱性の悪用などさまざまな方法で、そのコンテナーからの脱出を試みることでしょう。 コンテナー エスケープは組織にとって重大なセキュリティ リスクです。なぜならこれが攻撃チェーンにおける要石となって、悪意のある脅威アクターにアクセスを許すことになりかねないからです。私たちは以前、そのような攻撃チェーンを [runC の脆弱性に関する記事](https://unit42.paloaltonetworks.jp/breaking-docker-via-runc-explaining-cve-2019-5736/)のなかで発表しました。その記事では、攻撃者がどのように CVE-2019-5736 を悪用し、root レベルのコード実行を取得し、Docker コンテナーから脱出しうるのか、その技術を論じました。その記事の発表以降もさまざまな組織が同様の脆弱性を多数公表していますし、それらの脆弱性は攻撃者によるコンテナー脱出に利用される可能性があります。 パロアルトネットワークスのお客様は、本稿で紹介するコンテナー エスケープの技術から、[Cortex](https://www.paloaltonetworks.jp/cortex) と [Prisma Cloud](https://www.paloaltonetworks.jp/prisma/cloud) の両ソリューションを通じてさらに適切に保護されています。 侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、[こちら](https://start.paloaltonetworks.jp/contact-unit42.html)の問い合わせフォームからご連絡いただくか、infojapan@paloaltonetworks.com まで電子メールにてお問い合わせください (ご相談は弊社製品のお客さまには限定されません)。 | **関連する Unit 42 のトピック** | [**Container Escape**](https://unit42.paloaltonetworks.jp/tag/container-escape-ja/)**,** [**Containers**](https://unit42.paloaltonetworks.jp/tag/containers-ja/)**,** [**Docker**](https://unit42.paloaltonetworks.jp/tag/docker-ja/)**,** [**Kubernetes**](https://unit42.paloaltonetworks.jp/tag/kubernetes-ja/) | |------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ### **コンテナーとは** 最も単純な形式の場合、コンテナーとは要するにアプリケーションを構成するプロセスのグループです。これらのグループは隔離されたユーザー空間で実行されていますが、同じカーネル空間を共有しています。これは、ホスト全体が仮想化される仮想マシンとは対照的です。コンテナーのしくみを見ていく前に「隔離されたユーザー空間」が何を意味するのかを説明しておきます。 なかには、コンテナーが実際には隔離されたユーザー空間ではなく仮想化を使っているケースがあります。そうしたケースは本稿には当てはまりません。 ### **なぜコンテナーが必要なのか** コンテナーはリソースの効率利用のために使われています。コンテナーを使えば、1 台のサーバー上で複数のシステムを使えるようになります。オペレーティング システムは「名前空間 (namespace)」というメカニズムを提供しています。コンテナーはこの名前空間を使って隔離されたプロセス ツリーやネットワーク スタック、ファイル システム、そのほかさまざまなユーザー空間のコンポーネントを作成します。これによってリソースの効率利用が実現されています。 コンテナー内での隔離とは、各アプリケーションが自分専用にカスタマイズされた環境を持てることを意味します。同時に実行できない複数のアプリケーションがある場合は、同一サーバー上のそれぞれに専用のコンテナー内で動作させればよいことになります。 このアプローチのおかげで、コンテナーはホストから抽象化された独自のユーザー空間のコンポーネント群と対話できます。つまり、コンテナーごとに隔離されたユーザー空間が作られることになります。したがって、あるコンテナー内のアプリケーション群は、それぞれが専用サーバー内で実行されているかのように動作することができます。この特徴が、コンテナーがマイクロサービス ベースのアプリケーションに最適である理由でもあります。 コンテナーには高い移植性もあります。動作に必要なすべての依存関係を保持しているので、サポートされたコンテナー ランタイムを実行している任意のシステム上で、シームレスに実行できます。 とはいえ、こうしたコンテナーの状況は課題ももたらします。コンテナーは同じカーネルを共有しており、ホストのユーザーモードから完全には隔離されていないケースが多くなっています。したがって、コンテナー環境の制約を逃れようとする攻撃者が使う、さまざまな技術からの影響を受けやすくなっているのです。これらの技術は総称して「コンテナー エスケープ」と呼ばれます。 ### **コンテナーはどのように機能するのか** コンテナー内部のしくみを詳しく解説する前に、Linux オペレーティング システムの動作について理解しておく必要があります。Linux では、プロセスが生成されると、そのプロセスは親プロセスから属性 (attribute) を継承します。それには次のものが含まれます。 * 権限 * 環境変数 (明示的に定義されていない場合) * ケイパビリティ * 名前空間 コンテナーはこのメカニズムを利用して隔離されたプロセス ツリーを生成します。 コンテナー オーケストレーションを担当するアプリケーションは、[コンテナー ランタイム](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)と呼ばれます。 コンテナー ランタイムはプロセス開始とその属性の調整という役割を担っていて、対象プロセス自体に加えてその子プロセスすべての制限や隔離を行っています。その後、対象プロセスは「init」に名前が変更され、コンテナー構成ファイルで定義されたコマンドを実行します。 通常はコンテナー ランタイムが直接使われることはなく、コンテナー CLI やコンテナー ランタイムと通信するコンテナー オーケストレーション システムなどのアプリケーションを通じて使われます。 コンテナー CLI の例としては、[Docker Engine](https://docs.docker.com/engine/) があげられます。Docker Engine は [containerd](https://containerd.io/) をコンテナー ランタイムとして使い、[Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#:~:text=What%20is%20a%20Dockerfile%3F,to%20build%20a%20given%20image.) をコンテナー構成ファイルとして使います。ほかによく利用されているコンテナー オーケストレーション システムとしては [Kubernetes](https://kubernetes.io/) があります。こちらもコンテナー ランタイムとして containerd を使えます。 プロセスの隔離あたって[コンテナー ランタイム](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)が変更する属性としては次のものがあげられます。 * クレデンシャル (資格情報) * ケイパビリティ * [Linux Security Modules (LSM)](https://ja.wikipedia.org/wiki/Linux_Security_Modules) * [seccomp (Secure computing)](https://ja.wikipedia.org/wiki/Secure_computing_mode) * 名前空間 * [コントロール グループ (cgroups)](https://ja.wikipedia.org/wiki/Cgroups) すべてのコンテナー エンジンがこれら各属性を活用しているわけではありませんが、多くのエンジンで活用されています。 コンテナーのしくみをもっとよく理解するため、コンテナーの隔離と権限の制限にとくに関連の深い 2 つの属性、ケイパビリティと名前空間の例を調べてみましょう。 #### ケイパビリティ ケイパビリティについて、[Linux の man ページ](https://man7.org/linux/man-pages/man7/capabilities.7.html) は以下のように述べています。 「*Linux では、従来スーパーユーザーに関連付けられていた権限を、独立して有効化・無効化のできる、『ケイパビリティ』と呼ばれる個別の単位に分割しています。*」 本質的に、ケイパビリティ属性というのは、その名前の意味する「プロセスが実行可能 (capable) なアクションの範囲」そのものです。 Linux がケイパビリティ属性を実装した理由は、単純なユーザーやグループだけでなく、もっと多くの手段でプロセスを制限する必要があるためです。ケイパビリティ属性は、とくに root 権限を持つプロセスが実行できる操作を制限します。 以下の図 1 は、Linux のケイパビリティの包括的なリストです。 ![この画像は、ターミナルの黒い背景に白い等幅フォントで示した Linux のケイパビリティ名の一覧です。システム レベルのセキュリティを構成するための「cap\_chown」や、「cap\_kill」、「cap\_setuid」などのさまざまなシステム パーミッション (権限) が表示されています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-574065-135326-1.jpeg) 図 1. 利用可能な Linux のケイパビリティのリスト 図 1 に示したように、chown ([cap\_chown](https://man7.org/linux/man-pages/man7/capabilities.7.html#:~:text=overloaded%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20CAP_SYS_ADMIN%20capability.-,CAP_CHOWN,-Make%20arbitrary%20changes)) や ptrace ([cap\_sys\_ptrace]()) などのよく使われる操作ですら、ケイパビリティ メカニズムで制御可能な root 操作の一覧に含まれています。詳細については[ケイパビリティに関する Linux の man ページ](https://man7.org/linux/man-pages/man7/capabilities.7.html)を参照してください。 このロジックは単純です。ケイパビリティを削除すると、たとえ root 権限があっても対応する操作は実行できなくなります。たとえば、cap\_sys\_ptrace ケイパビリティを削除した場合、プログラムを起動したユーザーの権限レベルに関係なく、プロセスはほかのプロセスに対して ptrace システム コール (syscall) を実行できなくなります。 コンテナー作成にかかわるプロセスから不要な高権限のケイパビリティを戦略的に削除することで、コンテナー エンジンは root 権限でもコンテナーを安全に実行できるようになります。このセキュリティ メカニズムは、Linux の継承可能なケイパビリティ メカニズムによって可能となっています。 ただし残念ながら、コンテナー エンジンを使ってコンテナーを立てるさい、管理者が高権限のケイパビリティを全部は削除していないかもしれません。そうした場合には、コンテナー内からプロセスが利用できる特定のケイパビリティに基づいて、攻撃者らはそれら残されたケイパビリティをさまざまなコンテナー エスケープ手段に活用することができます。 #### 名前空間 [名前空間についての Linux man ページ](https://man7.org/linux/man-pages/man7/namespaces.7.html) は以下のように述べています。 「*名前空間はグローバル システム リソースを抽象化してラップします。これにより、名前空間内のプロセスからは、自分専用の隔離されたグローバル リソースのインスタンスを持っているかのように見えます。グローバル リソースへの変更は、その名前空間のメンバーであるプロセスからは見えますが、それ以外のプロセスからは見えません。名前空間の用途の 1 つはコンテナーの実装です。*」 プロセス管理においてケイパビリティはあるプロセスが「*何* 」を実行できるのかを定義し、名前空間はそれらのアクションを「*どこ*」で実行できるのかを定義します。言ってしまえば名前空間とは、「あるプロセスとその子プロセスがグローバル リソース内に独自の排他的インスタンスを所有しているかのように動作できるようにする抽象化レイヤー」です。 さまざまな種類の名前空間が存在し、それぞれがオペレーティング システム (OS) 内で特定の種類のグローバル リソースを受け持っています。 いちばんわかりやすい名前空間の 1 つは、PID (プロセス識別子) 名前空間です。管理者またはソフトウェアが新しい PID 名前空間を作成すると、OS は名前空間の作成を担当するプロセスに PID 1 を割り当てます。次に OS は次の PID である 2 を最初の子プロセスに割り当て、3 を 2 番目の子プロセスに割り当て、4 を 3 番目の子プロセスに割り当て、というように割り当てていきます。 あるプロセスが root 権限で実行されていて [cap\_kill](https://man7.org/linux/man-pages/man7/capabilities.7.html#:~:text=V%20IPC%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20objects.-,CAP_KILL,-Bypass%20permission%20checks) ケイパビリティをもっている、というシナリオを考えてみましょう。この場合、このプロセスは権限のチェックを回避し、ほぼすべてのプロセスを終了できます。ただし、このプロセスが新しい PID 名前空間内で動作している場合、そのプロセスのプロセス終了能力は同一名前空間内のプロセスに対してに限られます。cap\_kill ケイパビリティを持つこの元のプロセスにとって、自身の PID 名前空間外部にあるプロセスは本質的に存在しないのです。 基本的に名前空間は隔離強制メカニズムとして機能するもので、ケイパビリティや seccomp などの追加機能を備えることにより、意図せずほかの名前空間に干渉したりエスケープしたりしないようにしています。 下の図 2 は、利用可能な Linux の名前空間を示しています。詳しくは[名前空間に関する Linux の man ページ](https://man7.org/linux/man-pages/man7/namespaces.7.html)に記載されています。 ![これは Linux の名前空間の詳細を示した表です。Namespace (名前空間)、Flag (フラグ)、Page (ページ)、Isolates (隔離) の各列が表示されています。行には、IPC、Network (ネットワーク)、Mount (マウント)、PID、Time (時間)、User (ユーザー)、UTS が含まれていて、それぞれ対応するフラグ、参照される man ページ、隔離される対象とペアになっています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-577289-135326-2.jpeg) 図 2. 利用可能な Linux 名前空間のリストとその簡単な説明 ## コンテナー エスケープ コンテナー エスケープというと「ホスト システム上のコンテナー内でプログラムを実行する能力」だけを連想する方がおられるかもしれませんが、コンテナー エスケープ技術がどれもこの枠に収まるわけではありません。コンテナー エスケープのシナリオには、攻撃者がコンテナーを使ってホストからデータを盗んだり、特権昇格を実行したりすることも含まれます。 コンテナー エスケープ技術の例をいくつか見てみましょう。 ### **例 1: ユーザーモード ヘルパー** 最初の例は、ユーザーモード ヘルパーと呼ばれる一連の技術です。この例は [call\_usermodehelper](https://manpages.debian.org/experimental/linux-manual-4.11/call_usermodehelper.9.en.html) カーネル関数を悪用することからその名が付きました。 #### ユーザーモード ヘルパー攻撃技術のしくみ ドライバー向けに用意されている call\_usermodehelper 関数は、カーネルから直接ユーザーモードのアプリケーションを準備して開始することで、カーネルがユーザーモードで稼働する任意のプログラムを昇格された権限で実行できるようにします。 ただし特定の条件下では、ユーザーはドライバーそのほかのカーネル モード コンポーネントに、同じ昇格された権限でユーザーモードのプログラムを実行させることができます。ユーザーモード ヘルパーという用語は、カーネルがこうした特定の条件下でユーザーモード ファイルに定義されたユーザーモード プログラムを実行するさまざまな状況を含意しています。 ここで強調しておきたいのが、攻撃者がユーザーモードで特定のファイルを作成・変更すれば、カーネルを騙してさまざまなプログラムを root 権限で実行できるという点です。これには root アクセスが必要ですが、攻撃者が昇格された権限か悪用可能な脆弱性を突いてコンテナーの制御を奪った場合、その攻撃者が必要なアクションをとるのは容易です。 ##### **ユーザーモード ヘルパー: release\_agent** このユーザーモード ヘルパー技術は、cgroup とその release\_agent ファイルを活用してコンテナー エスケープを実現します。私たちは[過去に cgroup に影響する脆弱性](https://unit42.paloaltonetworks.jp/cve-2022-0492-cgroups/)について報告していますが、今回のコンテナー エスケープ技術は脆弱性に基づくものではありません。root 権限を持つ攻撃者がこのユーザーモード ヘルパー技術を使ってコンテナー エスケープを実現するというものです。[cgroups](https://man7.org/linux/man-pages/man7/cgroups.7.html) はプロセスへのリソース割り当て調整に使われていて、リソースの使用を制限する手段を提供しています。 今回の例では、cgroup の release\_agent のエスケープに、[2019 年の Black Hat USA カンファレンスで、Brandon Edwards 氏と Nick Freeman 氏により最初に発表された \[PDF\]](https://i.blackhat.com/USA-19/Thursday/us-19-Edwards-Compendium-Of-Container-Escapes-up.pdf)技術を用います。特定の cgroup の release\_agent を有効にすれば、対象 cgroup が空になったときに攻撃者はプログラムを実行できます。Linux は cgroups の適切なクリーンアップのためのこの機能を含めていますが、OS は何ら厳密な制約を持っておらず、任意の実行可能ファイルを実行可能です。 この技術の実装には次の手順が含まれます。 1. ディレクトリーを 1 つ作成してそれをマウントし、cgroup を 1 つ割り当てます。 2. その cgroup 内にディレクトリーを作成して新たなグループを作ります。 3. notify\_on\_release ファイルの内容を 1 に設定します。これにより、ユーザーモード ヘルパーのメカニズム (すべての新しい cgroup に存在) が有効になります。 4. release\_agent ファイル内で実行可能ファイルの絶対パスを指定します。このファイルはすべての種類の cgroup のルート ディレクトリーに存在していて、全 cgroups 間で共有されます。ルート ディレクトリーの絶対パスはコンテナー内から /etc/mtab ファイルを照会すれば取得できます (図 3 参照)。 5. cgroup.procs ファイルに 0 を書き込んでグループを空にします。そのグループが初期状態で空でも、release\_agent で指定された実行可能ファイルは実行されます。 以下の図 3 は、簡潔なシェル コマンドのシーケンスを使ってこの技術を実装した例を示しています。 ![白で表示された複数行のコードには、さまざまな Linux ターミナル コマンドと、システム設定の変更およびネットワーク攻撃のシミュレーションを目的としたスクリプトが含まれています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-580232-135326-3.png) 図 3. シェル コマンドで release\_agent エスケープを実装したところ (出典: [A compendium of container escapes - Brandon Edwards and Nick Freeman - Black Hat USA 19 \[PDF\]](https://i.blackhat.com/USA-19/Thursday/us-19-Edwards-Compendium-Of-Container-Escapes-up.pdf)) これは、正当なユーザーモード ヘルパーを使って、いくつかのシェル コマンドを実行するだけでコンテナーをエスケープした例です。 コンテナー エスケープのためのそのほかのユーザーモード ヘルパー技術も、この例と似たパターンにならいます。ここ重要なのは、「コンテナー内から関連ファイルを変更できるならホスト システム上で root 権限で任意のプログラムを実行できる」という点です。 私たちの調査は、ユーザーモード ヘルパー技術が最も大きな影響を与えうることを示しています。その主な理由は、コンテナー エスケープが比較的容易なこと、うまく実装できた場合の影響が大きいことです。 #### ユーザーモード ヘルパー攻撃技術の検出方法 これら一連の技術の検出には体系的アプローチが求められます。 1. **call\_usermodehelper 呼び出しのマッピング:** 最初にカーネルが使う call\_usermodehelper の全呼び出しを網羅した一覧を作成します。 2. **影響を受ける呼び出しの特定:** どの call\_usermodehelper 呼び出しがファイル経由でユーザーモード プログラムから操作されうるかを見定めます。 3. **コンテナーの変更の評価:** これらのファイルをコンテナー内から変更し、指定したプログラムを実行できるか調べます。 4. **ユーザーモード ヘルパー ファイルの監視:** 下準備が整ったら、各ユーザーモード ヘルパーに関連付けられた関連ファイルへの変更を検出戦略が監視することになります。ここではとくに、コンテナーのユーザーモード プログラム内から発生した変更の識別が重要なポイントとなります。 こうした多段階プロセスを踏むことが、コンテナー内のユーザーモード ヘルパー悪用にからむ潜在的セキュリティ リスクの事前的検出・緩和能力向上につながります。 #### 実地でのユーザーモード ヘルパー攻撃技術の検出 下の図 4 は、[DEEPCE](https://github.com/stealthcopter/deepce) リポジトリーから得た deepce.sh という侵入テストツールで release\_agent ファイルを変更し、コンテナーをエスケープしようとしたところを Cortex XDR が特定した様子です。 ![この画像は、あるコンテナー テクノロジー システムに対するサイバーセキュリティ攻撃を示したフローチャートです。この図は、「yosef/Ubuntu-20/root」というラベルの付いたノードで始まり、「deepce.sh」で終わっています。これら 2 つは危険または重要なポイントを表す 2 つの赤いアイコンで示されています。このプロセスは矢印で連結された複数のステップで進みます。「CMD」から始まり、「runC」を経て、最後にスクリプト「bash」と「deepce.sh」を実行しています。各ノードと遷移には、システム内でのアクションの順序とその性質を示すため、明確なラベルが付けられています。図の下には、コマンド ライン命令の「bin/sh ./deepce.sh --no-enumeration --exploit PRIVILEGED --username deepce --password deepce」が表示されています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-584950-135326-4.jpeg) 図 4. ![この画像は、あるコンテナー テクノロジー システムに対するサイバーセキュリティ攻撃を示したフローチャートです。この図は、「yosef/Ubuntu-20/root」というラベルの付いたノードで始まり、「deepce.sh」で終わっています。これら 2 つは危険または重要なポイントを表す 2 つの赤いアイコンで示されています。このプロセスは矢印で連結された複数のステップで進みます。「CMD」から始まり、「runC」を経て、最後にスクリプト「bash」と「deepce.sh」を実行しています。各ノードと遷移には、システム内でのアクションの順序とその性質を示すため、明確なラベルが付けられています。図の下には、コマンド ライン命令の「bin/sh ./deepce.sh --no-enumeration --exploit PRIVILEGED --username deepce --password deepce」が表示されています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-584950-135326-4.jpeg)図 4. DEEPCE を使った release\_agent のコンテナー エスケープ試行でトリガーされた Cortex XDR のアラート 図 4 は Cortex XDR のインシデント レポート内のアラートの因果関係チェーンを示した図で、イベントに関する洞察を提供しています。このアラートは指定されたツールによるプロセス実行ツリーを明示し、どの段階でアクティビティが検出され、その実行が阻止されたかを示しています。図 4 の Cortex XDR アラートはそのツールのコマンド ラインも合わせて表示することでツール実行にまつわる詳細なコンテキストを提供しています。 ### **例 2: SUID を使用した特権昇格** コンテナーのセキュリティは、本稿前半で説明したメカニズム (ケイパビリティ、名前空間、seccomp など) で強化されているので、多くのコンテナーはホスト上で root 権限で動作できます。この技術はそこを突くものです。 #### SUID 攻撃技術のしくみ この技術を使えば、あるホスト上で限定的な権限を持っているユーザーが、そのホスト上に存在する root 権限で動くプログラムを、コンテナーの内部から実行できるようになります。攻撃者がホストへの初期アクセスを持っていることが前提なので、これは完全なコンテナー エスケープではありません。ただし、最初はごく限られた権限しか持っていない攻撃者でも、これを使えばそのホスト上で root レベルの権限でアクションを実行できるようになります。 攻撃者がこのエスカレーションを実現できる理由は、あるコンテナーがホストと同じユーザー名前空間で動作している場合、そのコンテナー内のファイルに設定された SUID/GUID 権限ビットが、コンテナー外でもその権限を保持するからです。これは多くのコンテナー環境でよくある設定です。 この攻撃の実行には以下が必要です。 * ホストと同じユーザー名前空間内で root として実行されているコンテナー * ホストとコンテナーの両方からアクセス可能なディレクトリー * ホスト上のシェル * コンテナー上のシェル この技術を使う攻撃者は以下の手順を踏みます。 1. コンテナーとホストが共有している既存のディレクトリーに、実行可能ファイルを作成します。 攻撃者はコンテナー側、ホスト側のいずれの側からでもこのファイルを作成できます。 2. コンテナー内から SUID 権限ビットを追加します。 3. コンテナー外部から SUID を持つバイナリーを実行します。 これらの手順が完了すると、攻撃者の実行可能ファイルはそのホスト上で root 権限で動作します。 この前提条件が満たされているなら、攻撃者にとってこの攻撃は容易です。ファイルへの SUID 権限ビット設定は簡単な手順で、以下の [chmod](https://man7.org/linux/man-pages/man2/chmod.2.html) コマンドを使うだけですみます。 chmod u+s **\<ファイル名\>** #### SUID 攻撃技術の検出方法 これは非常に特殊な攻撃技術なので、攻撃の重要段階に的を絞った検出アプローチが使えます。 * **ファイル作成:** 実行が目的のファイル作成を監視します。 * **SUID/GUID ビットの変更:** コンテナーとそのホストが共有しているディレクトリーのファイルに SUID/GUID ビットを追加するようなコンテナー内の chmod 操作を検出します。 * **コンテナー外でのファイルの実行:** SUID/GUID ビットが設定されたファイルが、非 root のユーザーによってホスト上で実行されているようなインスタンスを検出します。 #### 実地での SUID 攻撃技術検出 図 5 は、SUID 技術を使ったコンテナー エスケープ試行を検出・ブロックした Cortex XDR からのアラートです。 ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-588290-135326-5.jpeg) 図 5. Cortex XDR のアラート。SUID 技術を使ったコンテナー エスケープの試みを示している Cortex XDR はコンテナー ランタイム環境 (runc) からの bash インターフェイス経由の chmod コマンドにアラートを発報しています (図 5)。この chmod コマンドは、コンテナーとホストが共有しているディレクトリー内のファイルに、SUID 権限ビットを設定しようとしていました。 ### **例 3: ランタイム ソケット** コンテナー インフラはホスト環境内ではクライアント/サーバー モデルで動いています。[Docker などのコンテナー プラットフォームのドキュメントが説明しているように](https://docs.docker.com/get-started/overview/#docker-architecture)、コンテナー CLI がクライアントとして機能する一方、コンテナーのデーモンはサーバーとして機能します。図 6 は Docker アーキテクチャの概要を示したもので、これを見るとコンテナー環境のクライアント/サーバー型の特性がわかりやすいです。 ![クライアント、Docker ホスト、レジストリーなどのコンポーネントを含む Docker アーキテクチャを示した図。クライアント側には、「docker run」、「docker build」、「docker pull」などのコマンド例が表示されています。Docker ホストには、さまざまな構成を示す Docker デーモン、イメージ、およびコンテナーが表示されています。レジストリーには、NGINX とその関連項目 (データベースのアイコン) が示されているほか、「Extensions」、「Plugins」と書かれたフォルダーも表示されています。矢印は、これらのオブジェクト間でのコマンドやデータの流れを示しています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-591058-135326-6.png) 図 6. Docker インフラのアーキテクチャ (出典: [Docker ドキュメント](https://docs.docker.com/get-started/overview/)) このクライアント/サーバー インフラを実装しているランタイム ライブラリーは、[API サーバー](https://www.linkedin.com/pulse/api-server-onkar-kulkarni-tyaof/)を外部に公開していて、この API サーバーがクライアント/サーバー間の通信を処理しています。このさいの通信は[ランタイム ソケット](https://https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/#runtime-socket)と呼ばれる [Unix ソケット](https://www.digitalocean.com/community/tutorials/understanding-sockets)を介して行われます。攻撃者は、対象コンテナー内からそのコンテナーのランタイム ソケットと直接対話することで、このメカニズムを利用できます。 #### ランタイム ソケットの攻撃技術のしくみ この技術を使うと、攻撃者は同一ホスト上に新たな特権つきコンテナーを作成できるようになります。作成後はその新しいコンテナーを使ってホスト側へとエスケープできます。 ランタイム ソケットがコンテナー内にマウントされている場合、API サーバーに直接コマンドを送信することでコンテナー ランタイムを制御できるようになります。このランタイム ソケットを使ってコンテナー ランタイムの制御を確立した攻撃者は、その [Unix ソケット ファイル](https://en.wikipedia.org/wiki/Everything_is_a_file) を使って API コマンドを実行できるようになります。これにより、攻撃者は容易に新たなコンテナーを作成し、そこからエスケープしてホスト側へアクセスできるようになります。 Unix ソケット ファイルを使ったランタイム ソケットとのやりとりは、次のアクティビティにより達成できます。 * ランタイム ソケットをパラメーターに指定してコンテナー ランタイム CLI を介する方法 * curl などの実行ファイルを使って任意のソケットを介して通信する方法 前者のアプローチだと、攻撃者は [REST API](https://www.ibm.com/topics/rest-apis) の呼び出しをしなくても通常のコマンドを実行できるようになります。ただし、コンテナー ランタイムを識別してコンテナー内でそのコンテナー ランタイムの CLI を取得するのはひと仕事でしょう。 逆に、 curl のようなよくある実行可能ファイルを使うことにも利点があります。というのも、ほとんどのコンテナー環境にはそれらのファイルが既に存在しているからです。この方法の場合より複雑な REST API コマンドが必要になりますが、API サーバーと通信するための追加プログラムをインストールする必要がなくなります。 以下は、Docker の REST API を使ってコンテナー ランタイムと対話する curl コマンドの例です。これらの例では、攻撃者が新しいコンテナーを作成して起動しています。 * curl --unix-socket /var/run/docker.sock http://localhost/containers/json * 作成されているすべてのコンテナーの情報を取得 * curl -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d {json\_containing\_container\_configuration} http://localhost/containers/create * 指定された JSON 構成に基づいてコンテナーを作成 * curl --unix-socket /var/run/docker.sock http://localhost/containers/{container\_id}/start * {container\_id} で指定されているコンテナーを起動 このランタイム ソケット技術を使用すると、攻撃者はホストのルート ディレクトリーへのマウント ポイントを持つ特権付きコンテナーを作成できます。攻撃者はこの後、ホストのファイル システムへの特権アクセスを通じて新しく作成されたコンテナーからエスケープできます。 #### ランタイム ソケット攻撃技術の検出方法 この形式の攻撃は複数の方法で検出できます。 * **ランタイム Unix ソケットの監視:** 最も直接的なアプローチはコンテナー ランタイム Unix ソケットへのリクエストを監視し、それらのリクエストがコンテナー内から出されたかどうかを確認することです。コンテナーの作成や操作など、影響のあるリクエストのみをフィルタリングすることで誤検知 (FP) を減らせます。 * **Unix ソケット ファイルのアクセス検出:** 別の方法として、Unix ソケット ファイルへのアクセスを検出する方法があります。ただしこのアプローチには誤検知がつきものです。リクエストに対して完全な可視性がない状態で、関係ないインスタンスを除外するのは難しいためです。 * **CLI または curl コマンドの実行** : コンテナー内部からのコンテナー ランタイム ソケットを使ったコンテナー ランタイム CLI または curl コマンドの実行の識別に重点を置いて検出を行うこともできます。この方法は効果的ですが、すべてのユース ケースを捕捉できるとは限りません。 * **検索試行の検出:** コンテナー内からのコンテナー ランタイム ソケット検索試行を検出するという別のアプローチもあります。ただしこれもほかの方法と同様、すべてのユース ケースを網羅できない可能性があります。 検出能力を強化するにはこれらの方法を組み合わせて使うことです。それによりカバレッジを最適化する多層防御戦略を実現できます。 #### 実地でのランタイム ソケット攻撃技術検出 以下の図 7 は、侵入テスト ツール DEEPCE を使った攻撃を Cortex XDR が検出・防止したさいのアラートです。curl を使ってマウントしたコンテナー ソケットからコンテナーをエスケープしようとしています。 ![この画像は、セキュリティ侵害の試みを示すサイバーセキュリティ ネットワーク フロー図です。この図には、CGO と書かれた四角形、runc というラベルのついた円、XDR エージェント、bash シェルなどのさまざまなコンポーネントが描かれていて、これらのコンポーネントは「deepce.sh」というスクリプトに向かう方向つき矢印で接続されています。これにより、侵害試行の流れが表わされています。深刻度レベルの高いアラート アイコンと、侵入が阻止されたことを示す「Prevented (Blocked)」と書かれた追加の詳細も表示されています。下部のコンソールには、観測された動作の詳細が表示されていて、「Anomaly Detection (異常を検出)」、「Container escaping Protection (コンテナー エスケープの保護)」などのカテゴリーが表示されています。特定の技術データ、パス、識別子は、構造化されたテーブル形式でレイアウトされています。背景には、ディレクトリー パス「/yosef/Ubuntu-20/root」を持つコンピューター インターフェイスが表示されています。タイムスタンプ、ソース タグなどの重要な詳細と、各モジュールのアクティビティの簡潔な説明により、表示されているセキュリティ イベントのコンテキストがわかりやすくなっています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-595259-135326-7.png) 図 7. Cortex XDR のアラート。ランタイム ソケット技術によるコンテナー エスケープ試行を示している ### **例 4: ログ マウント** これは Kubernetes に特有の攻撃で、より正確にはポッド エスケープと呼ばれるものです。というのも、Kubernetes プラットフォームはコンテナーを「[ポッド (pod)](https://kubernetes.io/docs/concepts/workloads/pods/)」と呼んでいますし、この攻撃では Kubernetes 特有の機能を使ってコンテナーからエスケープするからです。本技術については、2019 年に Aqua Security が[洞察に富む記事](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)を公開しています。 #### ログ マウント攻撃技術のしくみ この攻撃はポッド内にいる攻撃者に、root 権限を持つホスト上の任意のディレクトリーないしファイルへの読み取りアクセス権を与える可能性があります。この技術の要件は次のとおりです。 1. ホストの /var/log ディレクトリーへのマウントをもつポッドにアクセスできる 2. Kubernetes インターフェースを使ってログを読み取るケイパビリティがある 1. これはログ アクセスを持つ通常の Kubernetes ユーザーとして実現可能 2. 代わりにログ アクセスを持つポッド サービス アカウントを使ってもよい 最善のシナリオではホストの /var/log へのマウントをもつポッド内からログにアクセスできるようになります。 この脆弱性は Kubernetes がポッド ログにアクセスする方法に依るものです。各ポッドは /var/log 内に対応するログ ファイルを 1 つ持っています。このログ ファイルは、[シンボリック リンク (symlink)](https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%83%AA%E3%83%B3%E3%82%AF) によって、 /var/lib/docker/containers にあるコンテナー ディレクトリ内のログ ファイルにリンクされています。 この問題は [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#:~:text=The%20kubelet%20is%20the%20primary,object%20that%20describes%20a%20pod.) が宛先を検証せずにシンボリック リンクの内容を読み取ってしまう方法に起因しています。たとえば、シンボリック リンクの宛先をログ ファイルから /etc/shadow へに変更することで、攻撃者がホストの /etc/shadow ファイルにアクセスできるようになります。 攻撃はそこでは終わりません。Kubernete の [kubectl コマンドライン ツール](https://kubernetes.io/docs/reference/kubectl/)を介して HTTP POST リクエストを生成する場合、このツールは裏では /var/log ディレクトリーから対象のログ ファイルへの相対パスを指定してログにアクセスしています。つまり、攻撃者が /var/log 内からルート ディレクトリーへのシンボリック リンクを作成した場合、攻撃者は root 権限でファイル システム全体にアクセスできるようになります。 たとえば、/var/log 内にある root\_host という名前のホストのルート ディレクトリーへのシンボリック リンクと、ログ ファイル root\_host/etc/passwd を指定する HTTP POST 要求を組み合わせると、攻撃者はホストの /etc/passwd ファイルを取得できるようになります。 この技術では「/var/log がマウントされたポッド」と「ログの読み取りケイパビリティを持つ Kubernetes アカウント」の両方へのアクセスを得る必要があるのでこれは簡単な作業ではありませんが、可能性は残ります。 #### ログ マウント攻撃技術の検出方法 この形式の攻撃は次の 2 つの方法で検出できます。 * \*\*HTTP リクエストの監視:\*\*ログの読み取りを目的としたすべての HTTP 要求を監視し、不適切なパスをフィルタリングします。ただし、このアプローチでは、正当なログのシンボリック リンクを変更する攻撃を識別できない可能性があります。 * **シンボリック リンクの作成/変更の検出:** ポッド内部から発生した、ホストの /var/log ディレクトリー内で作成・変更されたシンボリック リンクを検出します。これを実装するには、ポッド側でなくホスト側の /var/log ディレクトリーで発生する書き込み操作を確実に検出せねばなりません。 これら 2 つの検出方法を組み合わせることでこうしたログ マウントの検出を改善できます。 #### 実地でのログ マウント攻撃技術検出 図 8 は、この技術を使った Kubernetes ポッドからのコンテナー エスケープ試行を検出・ブロックした Cortex XDR からのアラートです。このアラートは、ホスト ファイル システムにアクセスするため、/var/log にシンボリック リンクの作成が試行されたことを示しています。gこの試みでは、bash シェルを使って ln コマンドを実行し、シンボリック リンクを作成しようとしています。 ![これはサイバーセキュリティ プロセス フロー図で、番号の付いた円いアイコンが線でつながれ、4 つのステップを示しています。各ステップには、「CGO」、「runc」、「bash」、「ln」というラベルが付けられています。これらのラベルは、ソフトウェア セキュリティ チェックのさまざまな段階を表しています。この図は「yosef-Ubuntu-root」というタイトルの GUI に表示されていて、タイムスタンプ、ユーザー パス、セキュリティ署名などの追加の詳細が表示されています。最後のステップでは、ブロックされたアクションの通知が緑色のボックスで表示されています。](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-601156-135326-8.jpeg) 図 8. /var/log を使用したログ マウント エスケープ試行に関する Cortex XDR のアラート データ ### **例 5: センシティブ マウント** この技術はコンテナー内にマウントされている機微な宛先を持つディレクトリー (ホストの /etc ディレクトリーなど) にフォーカスしています。こうした宛先からはホストの /etc/passwd ファイルなどの個人情報を含むファイルへのアクセスが得られることから、攻撃者にとっては魅力的です。この種のマウントは構成ミスであって、こうしたマウント ポイントは「センシティブ マウント」と呼ばれます。 これは構成ミスの悪用にすぎませんが、コンテナー エスケープ技術の範疇に入るものです。 #### センシティブ マウント攻撃技術のしくみ この技術に必要なアクションは、構成ミスのあるコンテナー内からこうしたセンシティブなマウントを検出し、それらにアクセスすることのみです。たとえば攻撃者がホストの /etc ディレクトリーにアクセスする /host\_etc という名前のマウントを使ってコンテナーへのアクセスを得る可能性があります。攻撃者は、構成ミスのあるコンテナーから /host\_etc/password にアクセスすることにより、事実上ホストの /etc/passwd ファイルにアクセスしたことになります。 この技術は最も簡単なコンテナー エスケープ方法ですが検出は困難です。 #### センシティブ マウント攻撃技術の検出方法 機微情報を含むディレクトリーをマウントするコンテナーを監視してアラートを出すことは可能ですが、これは能動的な保護とはいえません。 この技術への効果的な保護には、事前に決められた機微ファイルや場所へのあらゆるアクセス (読み取り、書き込み、作成、削除) を検出する必要があります。ところがこの戦略では誤検知が急増するリスクがあり、重大な懸念が生じます。検出されたファイル アクセスがホスト上の正しいファイルに対応していることを確認する必要があります。 たとえば、/etc/shadow は不正アクセスから守るべき機微ファイルの一例です。コンテナー ランタイムは通常、ホスト ファイル システム内の指定の場所に新しいコンテナーのルート ディレクトリーを設定します。これにあたっては [chroot](https://man7.org/linux/man-pages/man2/chroot.2.html) または [pivot\_root](https://man7.org/linux/man-pages/man2/pivot_root.2.html) が使われて、コンテナーからの適切なアクセス レベルが設定されます。つまりコンテナーの /etc/shadow ファイルはホストの /etc/shadow ファイルと同じファイルではないので、コンテナーの /etc/shadow を直接監視しても、攻撃を検出する上では何の価値もありません。 「shadow」という名前の付いたすべてのファイルへのアクセスを検出するのも別の問題をもたらします。マウントは元のパスを保持していないことや、完全パスの情報が示されないことがあります。 解決策としては、検出された各ファイル アクセスのパスをコンテナー パスから対応するホストのパスへ変換する方法があります。これにより、ホストのパスに基づいた監視が可能になり、コンテナーとホスト間で直接共有すべきでない機微なファイルやディレクトリーへの攻撃を正確に検出できるようになります。このソリューションは概念的には単純ですが、実装は難しいかもしれません。 この種のコンテナー エスケープ手法に対し、私たちはどのように防御すればよいのでしょうか。課題は「コンテナー内でマウントされているファイルのどれがホスト上の機微ファイルと対応しているかを知る」という点です。Cortex XDR は、関連するイベントのパスを変換し、これらのセンシティブ マウントからのファイル アクセスをリアルタイムで検出することで、この課題に対応しています。 #### 実地でのセンシティブ マウント攻撃技術検出 図 9 は、センシティブ マウント技術を使ったコンテナー エスケープ試行を検出・ブロックした Cortex XDR からのアラートです。これは、bash インターフェイスを使い、構成ミスのあるコンテナー上のセンシティブ マウントを介してホスト上の機微ファイルにアクセスしようとした試みを Cortex XDR が検出したところです。 ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/word-image-604173-135326-9.jpeg) 図 9. センシティブ マウント技術を使ったエスケープ試行に関する Cortex XDR のアラート データ ### **検証環境** 私たちは検証環境内で [containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) コンテナー ランタイムを使う Kubernetes クラスターを選択しました。containerd は現在 Docker Engine で使われているコンテナー ランタイムであるという点は注目に値します。 本稿で検討してきた技術と Cortex XDR に組み込んだカバレッジは、特定のコンテナー ランタイムに依存するものではありません。弊社のアプローチにより、検出と保護が多様なコンテナー ランタイムに適用され、さまざまなランタイム環境での柔軟性と有効性が維持されます。 ## 結論 本稿ではさまざまなコンテナー エスケープ技術を検討してきました。本稿の結果はコンテナー技術の人気が高まるなかでの攻撃リスクの高まりを強調するものといえるでしょう。そのなかには攻撃者にコンテナーのホストへの部分的アクセス権を与える技術も、攻撃者にホストへの完全なアクセス権を与える技術もありました。コンテナーを使う組織が増えるにつれて、こうしたエスケープ技術からのリスクは、脅威情勢において注目すべき特性の 1 つでありつづけることでしょう。 潜在的な攻撃の緩和に向け、全コンテナー利用者は、こうした技術のリスクを認識し、推奨されるセキュリティと検出のガイドラインを遵守せねばなりません。 私たちは本稿に解説した検出原理に基づき、Cortex XDR に堅牢な検出ロジックを組み込み済みです。 パロアルトネットワークスのお客様は、[Cortex XDR](https://www.paloaltonetworks.jp/cortex/cortex-xdr)、[XSIAM Linux Agent](https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-Administrator-Guide/Install-the-XDR-Collector-Installation-Package-for-Linux)、[Cortex XDR agent for Cloud](https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-Administrator-Guide/Cortex-XDR-Agent-for-Cloud)、[Prisma Cloud Defender Agent](https://docs.prismacloud.io/en/classic/compute-admin-guide/technology-overviews/defender-architecture) を通じ、「コンテナー エスケープ」モジュールを使ってこれらのコンテナー エスケープ技術からより適切な保護を受けられます。 侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、[infojapan@paloaltonetworks.com](https://start.paloaltonetworks.jp/contact-unit42.html) までメールにてご連絡いただくか、下記の電話番号までお問い合わせください(ご相談は弊社製品のお客さまには限定されません)。 * 北米フリーダイヤル: 866.486.4842 (866.4.UNIT42) * EMEA: +31.20.299.3130 * APAC: +65.6983.8730 * 日本: (+81) 50-1790-0200 パロアルトネットワークスは、これらの調査結果を Cyber Threat Alliance (CTA: サイバー脅威アライアンス) のメンバーと共有しました。CTA のメンバーはこのインテリジェンスを使って、お客さまに保護を迅速に提供し、悪意のあるサイバー攻撃者を体系的に阻害できます。詳細は [Cyber Threat Alliance](https://www.cyberthreatalliance.org) にてご確認ください｡ ## 追加リソース * [Kubernetes](https://kubernetes.io/) * [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) -- Kubernetes Documentation * [Container Runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) -- Kubernetes Documentation * [Container runtime socket](https://https://kubernetes.io/docs/concepts/security/api-server-bypass-risks/#runtime-socket) -- Kubernetes Documentation * [containerd](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) -- Kubernetes Documentation * [Containerd](https://containerd.io/) * [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) -- Kubernetes Documentation * [Command-line tool (kubectl)](https://kubernetes.io/docs/reference/kubectl/) -- Kubernetes Documentation * [Docker architecture](https://docs.docker.com/get-started/overview/#docker-architecture) -- Docker Docs * [Docker Engine overview](https://docs.docker.com/engine/) -- Docker Docs * [Overview of best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) -- Docker Docs * [Understanding Sockets](https://www.digitalocean.com/community/tutorials/understanding-sockets) -- Jamon Camisso, Digital Ocean Tutorial * [Api server](https://www.linkedin.com/pulse/api-server-onkar-kulkarni-tyaof/) -- Onkar Kulkarni, LinkedIn post * [What is a REST API?](https://www.ibm.com/topics/rest-apis) -- IBM * [chroot(2) --- Linux manual page](https://man7.org/linux/man-pages/man2/chroot.2.html) -- Linux/UNIX system programming training * [pivot\_root(2) --- Linux manual page](https://man7.org/linux/man-pages/man2/pivot_root.2.html) -- Linux/UNIX system programming training * [capabilities(7) --- Linux manual page](https://man7.org/linux/man-pages/man7/capabilities.7.html) -- Linux/UNIX system programming training * [namespaces(7) --- Linux manual page](https://man7.org/linux/man-pages/man7/namespaces.7.html) -- Linux/UNIX system programming training * [call\_usermodehelper(9)](https://manpages.debian.org/experimental/linux-manual-4.11/call_usermodehelper.9.en.html) -- Debian Manpages * [Docker Enumeration, Escalation of Privileges and Container Escapes (DEEPCE)](https://github.com/stealthcopter/deepce) -- stealthcopter (Matthew Rollings) on GitHub * [Kubernetes Pod Escape Using Log Mounts](https://www.aquasec.com/blog/kubernetes-security-pod-escape-log-mounts/) -- Aqua Blog, Aqua Security * [A Compendium of Container Escapes \[PDF\]](https://i.blackhat.com/USA-19/Thursday/us-19-Edwards-Compendium-Of-Container-Escapes-up.pdf) -- Brandon Edwards and Nick Freeman, Capsule8 -- Presentation at Black Hat USA, 2019 * [cgroups に影響する Linux の新たな脆弱性 CVE-2022-0492 コンテナー エスケープの条件は](https://unit42.paloaltonetworks.jp/cve-2022-0492-cgroups/) -- パロアルトネットワークス Unit 42 *2024-08-07 09:30 JST 英語版更新日 2024-08-06 09:40 PDT の内容を反映し破損していたリンクを修正* トップに戻る ### タグ * [Cloud infrastructure](https://unit42.paloaltonetworks.com/ja/tag/cloud-infrastructure-ja/ "cloud infrastructure") * [Container](https://unit42.paloaltonetworks.com/ja/tag/container-ja/ "Container") * [Container escape](https://unit42.paloaltonetworks.com/ja/tag/container-escape-ja/ "container escape") * [Container security](https://unit42.paloaltonetworks.com/ja/tag/container-security-ja/ "container security") * [Docker](https://unit42.paloaltonetworks.com/ja/tag/docker-ja/ "Docker") * [Kubernetes](https://unit42.paloaltonetworks.com/ja/tag/kubernetes-ja/ "Kubernetes") [Threat Research Center](https://unit42.paloaltonetworks.com/ja/ "Threat Research") [次ページ:BadPack にご用心: Android アプリの奇妙な分析回避トリック](https://unit42.paloaltonetworks.com/ja/apk-badpack-malware-tampered-headers/ "BadPack にご用心: Android アプリの奇妙な分析回避トリック") ### 目次 * ### 関連記事 * [Copy Fail:ここ数年で最も深刻なLinuxの脅威について必要な知識](https://unit42.paloaltonetworks.com/ja/cve-2026-31431-copy-fail/ "article - table of contents") * [AWS IAM Roles Anywhereの危険性に迫る。](https://unit42.paloaltonetworks.com/ja/aws-roles-anywhere/ "article - table of contents") * [二重特権昇格攻撃チェーン: GKE (Google Kubernetes Engine) で監視やサービス メッシュの構成と権限をエクスプロイトして Kubernetes で不正アクセスを取得する手法](https://unit42.paloaltonetworks.com/ja/google-kubernetes-engine-privilege-escalation-fluentbit-anthos/ "article - table of contents") ## 関連項目 クラウド サイバーセキュリティ リサーチ リソース ![Pictorial representation of autonomous AI attack in cloud environments.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/04/12_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2026年4月23日 [#### AIはクラウドを攻撃できるのか?自律型クラウド攻撃型マルチエージェント システムの構築から得られた教訓](https://unit42.paloaltonetworks.com/ja/autonomous-ai-cloud-attacks/) * [AI](https://unit42.paloaltonetworks.com/ja/tag/ai-ja/ "AI") * [Cloud](https://unit42.paloaltonetworks.com/ja/tag/cloud-ja/ "Cloud") * [Data exfiltration](https://unit42.paloaltonetworks.com/ja/tag/data-exfiltration-ja/ "data exfiltration") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/autonomous-ai-cloud-attacks/ "AIはクラウドを攻撃できるのか?自律型クラウド攻撃型マルチエージェント システムの構築から得られた教訓") ![Close-up of a black woman with glasses examining colorful computer code on a screen. The scene is illuminated by various lights, creating a focused and analytical atmosphere.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/02/13_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2026年2月6日 [#### クラウド脅威アクターの活動を検出する新しい手法](https://unit42.paloaltonetworks.com/ja/tracking-threat-groups-through-cloud-logging/) * [API](https://unit42.paloaltonetworks.com/ja/tag/api-ja/ "API") * [IAM](https://unit42.paloaltonetworks.com/ja/tag/iam-ja/ "IAM") * [MITRE](https://unit42.paloaltonetworks.com/ja/tag/mitre-ja/ "MITRE") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/tracking-threat-groups-through-cloud-logging/ "クラウド脅威アクターの活動を検出する新しい手法") ![Pictorial representation of Azure OpenAI DNS resolution issue. Futuristic cityscape illustration with luminous structures and floating cloud elements, showcasing advanced technology and a dynamic, digitally enhanced environment.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/06/02_DNS_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2026年1月20日 [#### DNS OverDoS: プライベート エンドポイントはプライベートすぎるのか？](https://unit42.paloaltonetworks.com/ja/dos-attacks-and-azure-private-endpoint/) * [Microsoft Azure](https://unit42.paloaltonetworks.com/ja/tag/microsoft-azure-ja/ "Microsoft Azure") * [Networking](https://unit42.paloaltonetworks.com/ja/tag/networking/ "networking") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/dos-attacks-and-azure-private-endpoint/ "DNS OverDoS: プライベート エンドポイントはプライベートすぎるのか？") ![Pictorial representation of cloud discovery with AzureHound. A digital representation of a cloud composed of blue light particles, superimposed over a blurred background of server racks in a data center.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/10/08_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2025年10月24日 [#### AzureHoundを使用したクラウド ディスカバリ](https://unit42.paloaltonetworks.com/ja/threat-actor-misuse-of-azurehound/) * [Control plane](https://unit42.paloaltonetworks.com/ja/tag/control-plane-ja/ "control plane") * [Curious Serpens](https://unit42.paloaltonetworks.com/ja/tag/curious-serpens-ja/ "Curious Serpens") * [Data plane](https://unit42.paloaltonetworks.com/ja/tag/data-plane-ja/ "data plane") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/threat-actor-misuse-of-azurehound/ "AzureHoundを使用したクラウド ディスカバリ") ![Pictorial representation of a gift card fraud campaign. A glowing skull and crossbones on a circuit board.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/10/07_Cybercrime_Category_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2025年10月22日 [#### Jingle Thief: クラウドベースのギフトカード詐欺キャンペーンの実態](https://unit42.paloaltonetworks.com/ja/cloud-based-gift-card-fraud-campaign/) * [CL‑CRI‑1032](https://unit42.paloaltonetworks.com/ja/tag/cl-cri-1032-ja/ "CL‑CRI‑1032") * [Microsoft](https://unit42.paloaltonetworks.com/ja/tag/microsoft-ja/ "Microsoft") * [Phishing](https://unit42.paloaltonetworks.com/ja/tag/phishing-ja/ "phishing") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/cloud-based-gift-card-fraud-campaign/ "Jingle Thief: クラウドベースのギフトカード詐欺キャンペーンの実態") ![Pictorial representation of model namespace reuse. A vibrant digital illustration featuring a glowing cloud icon with a padlock, symbolizing cloud security technology, set against a backdrop of glowing circuit lines in blue and orange.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/08/05_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2025年9月3日 [#### モデル名前空間の再利用テクニック: AIサプライチェーンの基本的側面を誤用する](https://unit42.paloaltonetworks.com/ja/model-namespace-reuse/) * [Azure](https://unit42.paloaltonetworks.com/ja/tag/azure-ja/ "Azure") * [GenAI](https://unit42.paloaltonetworks.com/ja/tag/genai-ja/ "GenAI") * [Google](https://unit42.paloaltonetworks.com/ja/tag/google-ja/ "Google") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/model-namespace-reuse/ "モデル名前空間の再利用テクニック: AIサプライチェーンの基本的側面を誤用する") ![Pictorial representation of serverless tokens in the cloud. East Asian woman examining data on multiple screens in a high-tech environment, surrounded by digital graphics and code.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/06/07_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2025年6月13日 [#### クラウドにおけるサーバーレス トークン: エクスプロイト攻撃と検出](https://unit42.paloaltonetworks.com/ja/serverless-authentication-cloud/) * [AWS](https://unit42.paloaltonetworks.com/ja/tag/aws-ja/ "AWS") * [Google Cloud](https://unit42.paloaltonetworks.com/ja/tag/google-cloud-ja/ "Google Cloud") * [Microsoft Azure](https://unit42.paloaltonetworks.com/ja/tag/microsoft-azure-ja/ "Microsoft Azure") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/serverless-authentication-cloud/ "クラウドにおけるサーバーレス トークン: エクスプロイト攻撃と検出") ![Pictorial representation of ELF-based malware like NoodleRAT, Winnti, SSHdInjector, Pygmy Goat and AcidPour. Vibrant futuristic cityscape with glowing neon lines, clouds, and a dramatic sky at twilight.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/06/02_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2025年6月10日 [#### クラウド運用におけるLinuxバイナリの進化](https://unit42.paloaltonetworks.com/ja/elf-based-malware-targets-cloud/) * [Endpoint](https://unit42.paloaltonetworks.com/ja/tag/endpoint-ja/ "endpoint") * [Linux Malware](https://unit42.paloaltonetworks.com/ja/tag/linux-malware-ja/ "Linux Malware") * [Machine Learning](https://unit42.paloaltonetworks.com/ja/tag/machine-learning-ja/ "Machine Learning") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/elf-based-malware-targets-cloud/ "クラウド運用におけるLinuxバイナリの進化") ![Pictorial representation of AWS Roles Anywhere. Futuristic cityscape with glowing orange and blue structures, elevated clouds, and illuminated, scattered points representing lights or data points.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/06/01_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)脅威リサーチ](https://unit42.paloaltonetworks.com/ja/category/threat-research-ja/) 2025年6月9日 [#### AWS IAM Roles Anywhereの危険性に迫る。](https://unit42.paloaltonetworks.com/ja/aws-roles-anywhere/) * [AWS](https://unit42.paloaltonetworks.com/ja/tag/aws-ja/ "AWS") * [Kubernetes](https://unit42.paloaltonetworks.com/ja/tag/kubernetes-ja/ "Kubernetes") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/aws-roles-anywhere/ "AWS IAM Roles Anywhereの危険性に迫る。") ![Digital illustration of a glowing blue brain floating above a network of interconnected golden lines and points, symbolizing neural connections and artificial intelligence on a dark background with blue highlights.](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/12_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)主なサイバー脅威](https://unit42.paloaltonetworks.com/ja/category/top-cyberthreats-ja/) 2025年5月21日 [#### GitHub Actionsサプライチェーン攻撃: Coinbaseへの標的型攻撃が拡大し、tj-actions/changed-files事件が多発: 脅威評価（4/2更新）](https://unit42.paloaltonetworks.com/ja/github-actions-supply-chain-attack/) * [GitHub](https://unit42.paloaltonetworks.com/ja/tag/github-ja/ "GitHub") * [Supply chain](https://unit42.paloaltonetworks.com/ja/tag/supply-chain-ja/ "supply chain") [今すぐ読む ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ja/github-actions-supply-chain-attack/ "GitHub Actionsサプライチェーン攻撃: Coinbaseへの標的型攻撃が拡大し、tj-actions/changed-files事件が多発: 脅威評価（4/2更新）") * ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg) * ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ![Enlarged Image]() ![Newsletter](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/04/Unit-42_get-updates-banner.png) ![UNIT 42 Small Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/palo-alto-logo-small.svg) Unit 42 からの最新情報を取得 ## 進化する脅威の状況を常に先取り メール アドレス 本フォームを送信することにより、[利用規約](https://www.paloaltonetworks.jp/legal-notices/terms-of-use)に同意し、[プライバシー ポリシー](https://www.paloaltonetworks.jp/legal-notices/privacy)を承認したことになります。 本サイトは reCAPTCHA で保護されており、Googleの[プライバシー ポリシー](https://policies.google.com/privacy) と[サービス利用規約](https://policies.google.com/terms)が適用されます。 Invalid captcha! サブスクライブ ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) ![loader](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-loader.svg) {#footer} 製品とサービス * [AI利用ネットワーク セキュリティ プラットフォーム](https://www.paloaltonetworks.jp/network-security) * [AIのセキュア バイ デザイン](https://www.paloaltonetworks.jp/precision-ai-security/secure-ai-by-design) * [Prisma AIRS](https://www.paloaltonetworks.jp/prisma/prisma-ai-runtime-security) * [AI Access Security](https://www.paloaltonetworks.jp/sase/ai-access-security) * [クラウド提供型セキュリティ サービス](https://www.paloaltonetworks.jp/network-security/security-subscriptions) * [Advanced Threat Prevention](https://www.paloaltonetworks.jp/network-security/advanced-threat-prevention) * [Advanced URL Filtering](https://www.paloaltonetworks.jp/network-security/advanced-url-filtering) * [Advanced WildFire](https://www.paloaltonetworks.jp/network-security/advanced-wildfire) * [Advanced DNS Security](https://www.paloaltonetworks.jp/network-security/advanced-dns-security) * [Enterprise Data Loss Prevention](https://www.paloaltonetworks.jp/sase/enterprise-data-loss-prevention) * [Enterprise IoT Security](https://www.paloaltonetworks.jp/content/pan/ja_JP/network-security/enterprise-iot-security) * [Medical IoT Security](https://www.paloaltonetworks.jp/network-security/medical-device-security) * [Industrial OT Security](https://www.paloaltonetworks.jp/content/pan/ja_JP/network-security/industrial-ot-security) * [SaaS Security](https://www.paloaltonetworks.jp/sase/saas-security) * [次世代ファイアウォール](https://www.paloaltonetworks.jp/network-security/next-generation-firewall) * [ハードウェア ファイアウォール](https://www.paloaltonetworks.jp/network-security/hardware-firewall-innovations) * [ソフトウェア ファイアウォール](https://www.paloaltonetworks.jp/network-security/software-firewalls) * [Strata Cloud Manager](https://www.paloaltonetworks.jp/network-security/strata-cloud-manager) * [SD-WAN for NGFW](https://www.paloaltonetworks.jp/network-security/sd-wan-subscription) * [PAN-OS](https://www.paloaltonetworks.jp/network-security/pan-os) * [Panorama](https://www.paloaltonetworks.jp/network-security/panorama) * [セキュア アクセス サービス エッジ](https://www.paloaltonetworks.jp/sase) * [Prisma SASE](https://www.paloaltonetworks.jp/sase) * [App Acceleration](https://www.paloaltonetworks.jp/sase/app-acceleration) * [自律型デジタルエクスペリエンス管理](https://www.paloaltonetworks.jp/sase/adem) * [Enterprise DLP](https://www.paloaltonetworks.jp/sase/enterprise-data-loss-prevention) * [Prisma Access](https://www.paloaltonetworks.jp/sase/access) * [Prisma Browser](https://www.paloaltonetworks.jp/sase/prisma-browser) * [Prisma SD-WAN](https://www.paloaltonetworks.jp/sase/sd-wan) * [リモート ブラウザ分離](https://www.paloaltonetworks.jp/sase/remote-browser-isolation) * [SaaS Security](https://www.paloaltonetworks.jp/sase/saas-security) * [AI駆動型セキュリティ運用プラットフォーム](https://www.paloaltonetworks.jp/cortex) * [Cloud Security](https://www.paloaltonetworks.jp/cortex/cloud) * [Cortex Cloud](https://www.paloaltonetworks.jp/cortex/cloud) * [Application Security](https://www.paloaltonetworks.jp/cortex/cloud/application-security) * [Cloud Posture Security](https://www.paloaltonetworks.jp/cortex/cloud/cloud-posture-security) * [Cloud Runtime Security](https://www.paloaltonetworks.jp/cortex/cloud/runtime-security) * [Prisma Cloud](https://www.paloaltonetworks.jp/prisma/cloud) * [AI駆動型SOC](https://www.paloaltonetworks.jp/cortex) * [Cortex XSIAM](https://www.paloaltonetworks.jp/cortex/cortex-xsiam) * [Cortex XDR](https://www.paloaltonetworks.jp/cortex/cortex-xdr) * [Cortex XSOAR](https://www.paloaltonetworks.jp/cortex/cortex-xsoar) * [Cortex Xpanse](https://www.paloaltonetworks.jp/cortex/cortex-xpanse) * [Unit 42マネージド ディテクション\&レスポンス](https://www.paloaltonetworks.jp/cortex/managed-detection-and-response) * [マネージドXSIAM](https://www.paloaltonetworks.jp/cortex/managed-xsiam) * [次世代のアイデンティティ セキュリティ](https://www.paloaltonetworks.jp/idira) * [特権アクセス管理](https://www.paloaltonetworks.jp/idira/human/privileged-access-management) * [アイデンティティ管理とアクセス管理](https://www.paloaltonetworks.jp/idira/human/identity-and-access-management) * [Endpoint Privilege Manager](https://www.paloaltonetworks.jp/idira/human/endpoint-privilege-manager) * [アイデンティティ ガバナンス](https://www.paloaltonetworks.jp/idira/human/identity-governance) * [従業員パスワード管理](https://www.paloaltonetworks.jp/idira/human/workforce-password-management) * [エージェンティック アイデンティティ](https://www.paloaltonetworks.jp/idira/agentic) * [シークレット管理](https://www.paloaltonetworks.jp/idira/machine/secrets-management) * [統合型シークレット ガバナンス](https://www.paloaltonetworks.jp/idira/machine/unified-secrets-governance) * [アプリケーションの認証情報配信](https://www.paloaltonetworks.jp/idira/machine/application-credentials-delivery) * [ベンダーの特権アクセス](https://www.paloaltonetworks.jp/idira/human/vendor-privileged-access) * [脅威インテリジェンス\&インシデント レスポンス サービス](https://www.paloaltonetworks.jp/unit42) * [予防評価](https://www.paloaltonetworks.jp/unit42/assess) * [インシデント レスポンス](https://www.paloaltonetworks.jp/unit42/respond) * [セキュリティ戦略を変革](https://www.paloaltonetworks.jp/unit42/transform) * [脅威インテリジェンスについて](https://www.paloaltonetworks.jp/unit42/threat-intelligence-partners) 会社名 * [パロアルトネットワークスについて](https://www.paloaltonetworks.jp/about-us) * [採用情報](https://jobs.paloaltonetworks.com/en/) * [お問合せ](https://www.paloaltonetworks.jp/company/contact-sales) * [企業責任](https://www.paloaltonetworks.com/about-us/corporate-responsibility) * [お客様向け](https://www.paloaltonetworks.jp/customers) * [IR](https://investors.paloaltonetworks.com/) * [拠点](https://www.paloaltonetworks.com/about-us/locations) * [ニュースルーム](https://www.paloaltonetworks.jp/company/newsroom) 人気のあるリンク * [ブログ](https://www.paloaltonetworks.com/blog/?lang=ja) * [コミュニティ](https://www.paloaltonetworks.com/communities) * [コンテンツライブラリ](https://www.paloaltonetworks.jp/resources) * [Cyberpedia](https://www.paloaltonetworks.jp/cyberpedia) * [イベントセンター](https://events.paloaltonetworks.com/) * [電子メール設定の管理](https://start.paloaltonetworks.com/preference-center) * [製品A〜Z](https://www.paloaltonetworks.jp/products/products-a-z) * [製品認証](https://www.paloaltonetworks.com/legal-notices/trust-center/compliance) * [脆弱性の報告](https://www.paloaltonetworks.com/security-disclosure) * [サイトマップ](https://www.paloaltonetworks.jp/sitemap) * [テクニカル ドキュメント](https://docs.paloaltonetworks.com/) * [Unit 42](https://unit42.paloaltonetworks.jp/) * [個人情報の販売および共有禁止](https://panwedd.exterro.net/portal/dsar.htm?target=panwedd) ![Palo Alto Networks Logo](https://www.paloaltonetworks.jp/etc/clientlibs/clean/imgs/pan-logo-dark.svg) * [プライバシー](https://www.paloaltonetworks.jp/legal-notices/privacy) * [トラスト センター](https://www.paloaltonetworks.jp/legal-notices/trust-center) * [利用規約](https://www.paloaltonetworks.jp/legal-notices/terms-of-use) * [ドキュメント](https://www.paloaltonetworks.jp/legal-notices) Copyright © 2026 Palo Alto Networks. All Rights Reserved * [![](https://www.paloaltonetworks.jp/etc/clientlibs/clean/imgs/social/youtube-black.svg)](https://www.youtube.com/user/paloaltonetworks) * [![](https://www.paloaltonetworks.jp/etc/clientlibs/clean/imgs/social/twitter-x-black.svg)](https://twitter.com/PaloAltoNtwks) * [![](https://www.paloaltonetworks.jp/etc/clientlibs/clean/imgs/social/facebook-black.svg)](https://www.facebook.com/PaloAltoNetworks/) * [![](https://www.paloaltonetworks.jp/etc/clientlibs/clean/imgs/social/linkedin-black.svg)](https://www.linkedin.com/company/palo-alto-networks) * [![](https://www.paloaltonetworks.jp/content/dam/pan/en_US/images/icons/podcast.svg)](https://unit42.paloaltonetworks.com/unit-42-threat-vector-podcast/) * JP Select your language ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ### Default Heading Read the article ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) Seekbar ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Volume](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-volume.svg) Volume ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg)