GCP、AWS、Azure 別に見るクラウド VM への攻撃経路まとめ

概要

本稿は、クラウド内の仮想マシン (VM) サービスに対する潜在的な攻撃ベクトルを特定・緩和するための戦略について解説します。組織はこの情報を使って、VM サービスに関連する潜在的リスクを理解し、防御メカニズムを強化できます。この調査では、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP) という 3 つの主要クラウド サービス プロバイダー (CSP) が提供する VM サービスを中心に取り上げます。

VM はあらゆるクラウド環境で最も利用数の多いリソースの 1 つで、その多さがゆえに、攻撃者らの主要な標的にされています。私たちの研究からは、インターネットに公開されているクラウドホストの 11% には、深刻度が「緊急 (Critical)」または「重要 (High)」と評価される脆弱性があることがわかっています。

VM が侵害されると、同インスタンス内のデータへのアクセスだけでなく、そのインスタンスに割り当てられている権限へのアクセスも、攻撃者に提供してしまうおそれがあります。VM などのコンピュート ワークロードは概してエフェメラル (短命) かつイミュータブル (不変) なので、侵害された ID のもたらすリスクは、VM 内にある侵害されたデータのもたらすリスクより、大きいと言ってもよいでしょう。

本稿で説明する攻撃経路はいずれも脆弱性ではありません。そうでなく、ハイブリッド環境ないしマルチクラウド環境全体で、VM の構成や更新、監視の合理化など、正当なユースケースを持つ意図された機能であることに留意する必要があります。ただし、セキュリティ ベスト プラクティスを遵守せず、アカウントが保護されておらず、アーキテクチャ設計に十分な注意が払われていなければ、悪意のあるユーザーにそれらのサービスや機能を悪用されてしまうおそれはあります。これらの攻撃経路の保護や緩和の責任は、クラウド ユーザーと管理者にあります。

パロアルトネットワークスのお客さまは、以下の製品を通じて、上記の脅威からより強力に保護されています。

• Prisma Cloud をご利用のお客さまは、潜在的な攻撃経路を継続的に監視し、警告してくれる Attack Path ポリシーよって、より強力に保護されています。
• Cortex XDR は、エクスプロイトに加えて検出しづらいクラウドベースの攻撃も検出・ブロックします。
• Cortex Xpanse を使うと、パブリック クラウド プロバイダーで実行されているシャドー IT を検出し、それらのリソースを管理下に置くことができます。
• Unit 42 インシデント レスポンス チームも、侵害を受けた場合の支援や、お客さまのリスク低減のための事前サイバーセキュリティ準備状況評価を行っています。

VM の攻撃経路の概要

私たちは、実行中の VM インスタンスに対する各攻撃経路の条件や権限を調査することで、組織の皆さんが検出や緩和のメカニズムを細かく調整するお手伝いをしています。表 1 は、本稿で解説する全攻撃経路の概要を示したものです。

表 1. VM の攻撃経路の概要

クラウド内の VM を理解する

どのクラウド サービス プロバイダーにおいても最も古くからあり、最も広く使われているインフラストラクチャ・アズ・ア・サービス (IaaS) 製品の 1 つが VM です。これらの製品は、オンプレミス アプリケーションをクラウドに「リフト アンド シフト」するための迅速で明快な方法を提供してくれ、オペレーティング システムとそれより上のレベルについて、同じユーザー エクスペリエンスを維持してくれます。最新の VM サービスは、Linux から Windows、macOS までの幅広いオペレーティング システムをサポートしていて、事実上あらゆるアプリケーションをクラウドにデプロイできます。

VM は今日最新のクラウド テクノロジーではないかもしれませんが、今も変わらず多くの重要なクラウド ワークロードをホストしています。その VM が侵害されれば、攻撃者に機微データを窃取されてコンピュート リソースを乗っ取られるだけでなく、その VM に付与されたすべてのクラウドの権限にアクセスされてしまいます。

クラウド内で攻撃者が使用する戦術・技術・手順 (TTP) は、彼らが取得した権限に大きく依存しています。このため、より多くの権限を取得する一般的な方法の 1 つが、VM などのコンピュート リソースを侵害し、そのワークロード ID を乗っ取る方法です。結果として各 VM インスタンスが攻撃者の目標達成の踏み台にされかねないことから、それらの綿密なアタック サーフェス (攻撃対象領域) 管理が重要になります。

ここでは「VM の攻撃経路」を「攻撃者による VM インスタンスのログインやコマンド実行を許しうる一連の手順や条件」と定義しています。また私たちは、攻撃者が標的の VM に関する一意な識別子 (UID)、IP アドレス、仮想プライベート クラウド (VPC)、リージョンなどの基本情報を有しているものと想定しています。

こうした情報は、通常は機密情報とは見なされません。これらはログやコード、または特権レベルの低い読み取り権限から取得される可能性があります。ただし攻撃者は VM のログイン クレデンシャルは持っていません。本稿で解説する攻撃経路の大部分は、VM にアクセスするためのコントロール プレーン アプリケーション プログラミング インターフェイス (API) に依存しています。

以降のセクションでは、それぞれに特有の手法を取り上げ、その手法に関連する各 CSP での攻撃経路を説明します。各攻撃経路について前提条件を概説しますが、これらの条件は必要条件ではあるものの十分条件ではない場合があることに注意してください。たとえば私たちは、攻撃者がまずクレデンシャルの漏えいやフィッシングなどの手段を通じて必要な権限を得たのち、これらの攻撃経路を悪用することを想定しています。

私たちは、これらの攻撃経路につながる、最も関連性の高い権限や構成を中心に取り上げます。本稿に解説する技術のほとんどは特定の VM オペレーティング システムに固有のものではありませんが、話を簡潔にするため、リファレンスとサンプルは Linux システム ベースのものを中心に提供します。

脆弱性の悪用

私たちの研究からは、インターネットに公開されているクラウドホストの 11% には、深刻度が「緊急 (Critical)」または「重要 (High)」と評価される脆弱性があることがわかっています。こうした脆弱性の悪用は、クラウド環境への初期アクセスを取得するさいに攻撃者が最もよく使う手の 1 つです。

最近のアプリケーションには何百もの依存パッケージがバンドルされているので、新たな脆弱性の出現がかつてなく加速しています。インスタンスやクラウドの種類が何であれ、VM が晒している脆弱性がリモートから悪用可能でそれを攻撃者が特定できるなら、その VM は侵害・制御されるおそれがあります。

条件:

• ターゲットの VM にリモートから悪用しうるネットワークに公開された脆弱性があること。
• その脆弱性によって、リモート コードの実行、ファイル アクセス、またはファイルの上書きが可能であること。

緩和策:

• 脆弱性スキャン サービスを有効にする。例えば Prisma Cloud Vulnerability Management、Amazon Inspector、Microsoft Defender for Cloud、Google Security Command Center など。

スタートアップ スクリプトの操作

スタートアップ スクリプトは、VM インスタンスの初期化プロセス中にタスクを実行するファイルです。これらのスクリプトは通常、環境の設定、依存関係のダウンロード、サービスの初期化、更新の取得に使われます。攻撃者が VM のスタートアップ スクリプトの変更権限を取得した場合、この機能が悪用され、VM に悪意のあるコードが挿入される可能性があります。

AWS: ユーザーデータ内のスタートアップ スクリプトを変更する

新しい EC2 インスタンスを起動するときは、オプションでユーザーデータ内にパラメーターやスクリプトを渡せます。ユーザー データ内のスクリプトはすべて、インスタンスの起動時に実行されます。デフォルトでは、スクリプトはインスタンスの初回起動時にのみ実行されます。ただし、cloud-init ディレクティブを設定すれば、再起動のたびにスクリプトを強制的に実行することができます。

条件:

• EC2 の VM 作成に使った Amazon Machine Images (AMI) が、ユーザーデータと cloud-init の機能をサポートしていること。
• プリンシパルが VM のユーザー データを変更し、VM を再起動するための次の権限を持っていること。
  • ec2:StopInstances
  • ec2:ModifyInstanceAttribute
  • ec2:StartInstances

緩和策:

• ec2:ModifyInstanceAttribute の権限の使用を制限・監視する。

Azure: カスタム データ内のスタートアップ スクリプトを変更する

スタートアップスクリプトは Azure VM にカスタム データ経由で保存されて渡されます。単一 VM の場合、カスタム データはブート時に 1 回だけ設定でき、その後は更新できません。ただし、VM Scale Set (VM のグループ) のカスタムデータは更新することができます。

新しく開始された VM は、更新されたカスタム データを受け取ります。一方、既存の VM が新しいカスタムデータを受け取るには再イメージ化が必要です。

条件:

• プリンシパルが、VM Scale Set の状態を更新し、VM を再イメージ化するための以下の権限を持っていること。
  • Microsoft.Compute/virtualMachineScaleSets/write

緩和策:

• Microsoft.Compute/virtualMachineScaleSets/write 権限の使用を制限・監視する。

GCP: メタデータ内のスタートアップ スクリプトを変更する

Compute Engine のメタデータ サービスは、メタデータを Key-Value ペアとして保存および取得するメカニズムを提供しています。これには、スタートアップ/シャットダウン スクリプトや SSH キーのほか、数々の機能フラグも含まれています。メタデータは、個々の VM のインスタンスのレベルで設定することも、プロジェクト内のすべての VM のプロジェクト全体のレベルで設定することもできます。その後、各 VM がそれぞれのメタデータに従って構成されます。

スタートアップ スクリプトのメタデータ キーには、VM インスタンスのブート時に実行されるコマンドが含まれています。

条件:

• ゲスト エージェントがインストールされ、アクティブになっていること。
• プリンシパルが VM のメタデータを更新する次の権限を持っていること。
  • compute.instances.setMetadata (VM の インスタンス メタデータ経由)
  • compute.projects.setCommonInstanceMetadata (プロジェクト レベルの メタデータ経由)
• プリンシパルが VM を再起動する以下の権限を持っていること。
  • compute.instances.stop
  • compute.instances.start
  • compute.instances.reset

緩和策:

• compute.instances.setMetadata と compute.projects.setCommonInstanceMetadata 権限の使用を制限・監視する。
• 推奨される方法は、メタデータに直接ではなくクラウドストレージにスタートアップ スクリプトを保存し、startup-script-url メタデータキーを使ってその場所を指定することです。こうしておけば、スタートアップ スクリプト内に存在しうる機微情報を、変更管理や追加のアクセス制御などを使ってより適切に保護できますし、256 KB を超えるサイズのスクリプトも使えるようになります。

SSH キーのプッシュ

各組織は通常、クラウド環境内の数百 (場合によっては数千) の VM インスタンス上でさまざまなアプリケーションをホストしています。ですから、これらすべての VM の SSH キー管理作業は煩雑になりがちです。そこで、クレデンシャル管理やアクセス制御のプロセスを合理化すべく、ほとんどの CSP は実行中の VM に SSH 公開鍵を挿入しやすくする機能を提供しています。

通常、こうしたプロセスでは VM 内でエージェントが実行されていて、これがクラウドの API エンドポイントから公開鍵を取得し、SSH デーモン (sshd) の設定ファイルを変更し、VM 上の authorized_keys ファイルを上書きします。つまり、攻撃者に SSH キーをプッシュする権限を奪われた場合、この機能が悪用されて、VM に不正にアクセスされるおそれがあります。

AWS: EC2 Instance Connect を使って SSH キーをプッシュする

EC2 Instance Connect は ID およびアクセス管理 (IAM) を使って Linux VM への SSH アクセスを管理する、シンプルで安全な方法を提供しています。ユーザーが VM に SSH 接続する必要がある場合、Instance Connect は一時的な公開鍵を VM にプッシュし、そのユーザーが SSH デーモンで認証できるようにします。

条件:

• EC2 Instance Connect エージェント がインストールされ、アクティブになっていること。VM 自体に権限は不要。
• プリンシパルが SSH キーをプッシュするために以下の権限を持っていること。
  • ec2-instance-connect:SendSSHPublicKey

緩和策:

• ec2-instance-connect:SendSSHPublicKey 権限の使用を制限・監視する。
• 不要なら EC2 Instance Connect をアンインストールする。

Azure: VMAccess 拡張機能を使って SSH キーをプッシュする

VM 拡張機能は、VM インスタンス上でデプロイ後の構成や自動化をしやすくするための小さいアプリケーション群です。これらの拡張機能は、システム構成、システム監視、システム バックアップなどの機能を提供します。

VMAccess 拡張機能を使用すると、たとえばユーザーのパスワード設定や SSH 公開鍵のプッシュ、新規の sudo ユーザー作成などのタスクを実行する Linux VM 上の Admin ユーザーを管理できるようになります。az vm user コマンドは、VMAccess 拡張機能を利用して VM 内のユーザー アカウントを管理しています。

条件:

• Azure の VM エージェントがインストールされ、アクティブになっていること。
• プリンシパルが拡張機能をインストールしてユーザー アカウントを更新する次の権限を持っていること。
  • Microsoft.Compute/virtualMachines/extensions/write
  • Microsoft.Compute/virtualMachines/write

緩和策:

• Microsoft.Compute/virtualMachines/extensions/write と Microsoft.Compute/virtualMachines/write 権限の使用を制限・監視する。
• VM にインストールできる拡張機能の種類を制限する。
• 不要なら VMAccess 拡張機能を削除する。

GCP: メタデータを更新して SSH キーをプッシュする

Compute Engine のメタデータ サービスは 、メタデータを Key-Value ペアとして保存・取得するメカニズムを提供しています。SSH キーのメタデータ キーを更新すれば、VM インスタンスに SSH 公開鍵を追加できます。

条件:

• ゲスト エージェントがインストールされ、アクティブになっていること。
• プリンシパルが VM のメタデータを更新する次の権限を持っていること。
  • compute.instances.setMetadata (VM の インスタンス メタデータ経由)
  • compute.projects.setCommonInstanceMetadata (プロジェクト レベルの メタデータ経由)
  • iam.serviceAccounts.actAs (プロジェクトレベル)

緩和策:

• compute.instances.setMetadata と compute.projects.setCommonInstanceMetadata 権限の使用を制限・監視する。
• プロジェクト レベルでのメタデータ ベースの SSH キーをブロックする。

GCP: OS Login を使って SSH キーをプッシュする

OS Login は、Google Cloud Identity (IAM) ポリシーを使って、メタデータ内の SSH キーと VM インスタンス内のユーザー アカウントを自動的に管理します。これは、VM 内の SSH キー管理において推奨される方法です。

OS Login はメタデータ サービスの enable-oslogin というメタデータ キーを更新することで有効化できます。なお、メタデータベースの SSH キーと OS Login は相互排他的な機能なので、いずれか片方のみが有効となる点にはご注意ください。

条件:

• OS Login エージェントがアクティブになっていること。
• プリンシパルが VM のメタデータを更新する次の権限を持っていること。
  • compute.instances.setMetadata (VM の インスタンス メタデータ経由)
  • compute.projects.setCommonInstanceMetadata (プロジェクト レベルの メタデータ経由)
  • iam.serviceAccounts.actAs (プロジェクトレベル)
• プリンシパルが OS Login を使って VM に接続するために compute.osLogin ロールと関連付けられていること。
• 組織外のプリンシパルの場合は次の権限を持っていること。
  • compute.oslogin.updateExternalUser

緩和策:

• compute.instances.osLogin と compute.oslogin.updateExternalUser 権限の使用を制限・監視する。
• プロジェクト レベルで 2 要素認証 (2FA) による OS Login を強制する。
• プロジェクト レベルで OS Login に物理的なセキュリティ キーを強制する。

直接のコード実行

VM インスタンス フリートの管理や構成を効率化するため、ほとんどの CSP は VM セット全体についてコマンドやスクリプトを実行できる機能を提供しています。これにより、VM には公開された管理ポートや踏み台ホスト (Bastion host)、実行状態の sshd などが必要なくなるので、セキュリティとコスト効率が向上します。

これらの機能は通常は VM で実行されているエージェントに依存していて、それらのエージェントがクラウド API のエンドポイントからコマンドを取得・実行しています。攻撃者がこうした行為の実行に必要な権限を得た場合、それらの機能が悪用され、 VM 内で悪意のあるコードが実行されるおそれがあります。

AWS: SSM Run Command を使ってコードを実行する

SSM の Run Command を使うと、System Manager がインストールされているノード上でユーザーがコマンドを実行できるようになります。この機能を使えば、単一クラウド、マルチクラウド、あるいはハイブリッド クラウド環境のノード間で、1 回限りの構成やステータス チェックを簡単に実行できるようになります。

条件:

• SSM Agent がインストールされ、アクティブになっていること。
• その VM が AmazonSSMManagedInstanceCore ポリシー内に指定された権限を持っていること。
• プリンシパルが次の権限をもっていること。
  • ssm:SendCommand

緩和策:

• ssm:SendCommand 権限の使用を制限・監視する。
• Run Command を実行できる SSM ドキュメントを制限する。
• SSM に管理されていない VM からの SSM 権限を取り消す。
• 不要ならデフォルトのホスト管理設定は無効にする。この機能を使うと AWS System Manager がすべての正規 EC2 インスタンスを管理できるようになる。

Azure: 仮想マシンの実行コマンド (RunCommand) を使ってコードを実行する

Azure の実行コマンド (Run Command) 機能は、VM 内の VM エージェントを使ってスクリプトを実行します。この機能は、RDP や SSH サービスが利用できない場合のアプリケーション管理やシステム診断、トラブルシューティングに使えます。

条件:

• Azure の VM エージェントがインストールされ、アクティブになっていること。
• プリンシパルが Run Command を実行するための次の権限を持っていること。
  • Microsoft.Compute/virtualMachines/runCommands/write

緩和策:

• Microsoft.Compute/virtualMachines/runCommands/write 権限の使用を制限・監視する。

Azure: カスタム スクリプト拡張機能を使ってスクリプトを実行する

VM 拡張機能は、VM インスタンス上でデプロイ後の構成や自動化を実行できるようにする小さいアプリケーション群です。カスタム スクリプト拡張機能を使うと VM 内でのスクリプトのダウンロードと実行が可能になります。

条件:

• Azure の VM エージェントがインストールされ、アクティブになっていること。
• プリンシパルが拡張機能をインストールし、カスタム スクリプト拡張機能を実行するための次の権限を持っていること。
  • Microsoft.Compute/virtualMachines/extensions/write
  • Microsoft.Compute/virtualMachines/write

緩和策:

• Microsoft.Compute/virtualMachines/extensions/write と Microsoft.Compute/virtualMachines/write 権限の使用を制限・監視する。
• インストールできる拡張機能の種類を制限する。

GCP: VM Manager を使ってコードを実行する

VM Manager は VM グループの管理に役立つツール スイートで、主にはパッチの適用や OS 情報の収集、ソフトウェア パッケージのインストールやアンインストールに使われています。

パッチ適用前またはパッチ適用後のスクリプトを実行する

Patch の機能を使うと apt (Advanced Packaging Tool) や yum (Yellowdog Updater、Modified) などの OS パッケージ マネージャーを使って VM インスタンスのセット全体に OS パッチを適用できます。パッチ ジョブの作成中に、パッチ適用前またはパッチ適用後のスクリプトをオプションで実行して、パッチの準備やテストを行えます。

OS ポリシーでスクリプトを実行する

OS ポリシーの機能を使うと、ユーザーは複数の VM にわたって OS を一貫した構成にしておくことができます。各ポリシー ファイルには、パッケージ、リポジトリー、ファイルなどのリソースの宣言型構成が含まれています。OS のリソースを構成する方法の 1 つはスクリプトを実行することです。

条件:

• ゲスト エージェントがインストールされ、アクティブになっていること。
• メタデータ内で OS Config が有効になっていること。
• OS Config エージェントがインストールされ、アクティブになっていること。
• その VM に接続されたサービス アカウントがあること。ただし、そのサービス アカウントには権限は必要ない。
• プリンシパルがパッチ ジョブを実行するための次の権限を持っていること。
  • osconfig.patchJobs.exec
  • osconfig.patchJobs.get
  • osconfig.patchJobs.list
• プリンシパルが OS ポリシーの割り当てを管理するための次の権限を持っていること。
  • osconfig.osPolicyAssignments.update
  • osconfig.osPolicyAssignments.get
  • osconfig.osPolicyAssignments.list

緩和策:

• osconfig.patchJobs.exec、osconfig.patchJobs.exec、 osconfig.osPolicyAssignments.update の権限の使用を制限・監視する。
• プロジェクト レベルで osconfig-disabled-features メタデータ キーを設定することで、パッチと OS ポリシーの機能を無効化する。
• 不要ならプロジェクト レベルのメタデータの OS Config を無効化する。
• 不要なら OS Config エージェントをアンインストールする。

ミドルウェア経由の SSH

AWS: SSM Session Manager を使って VM にログインする

AWS SSM Session Manager は、IAM を使ってノードにログインするための安全で監査可能な方法を提供します。 Session Manager を使っているノードにはインバウンド ポートを公開しておく必要がなくなり、ノードにログインするユーザーが秘密鍵を管理する必要がなくなります。

Session Manager は、マルチクラウド環境またはハイブリッド クラウド環境のノード上でも構成できます。攻撃者が Session Manager のアクションの実行権限を得た場合、この機能を悪用して Session Manager を実行している VM にログインされるおそれがあります。

条件:

• SSM Agent がインストールされ、アクティブになっていること。
• VM のインスタンス プロファイルに次の権限が含まれていること。
  • ssmmessages:CreateControlChannel
  • ssmmessages:CreateDataChannel
  • ssmmessages:OpenControlChannel
  • ssmmessages:OpenDataChannel
  • ssm:UpdateInstanceInformation
• プリンシパルが VM に接続するための次の権限を持っていること。
  • ssm:StartSession
  • ssm:ResumeSession
  • ssm:TerminateSession

緩和策:

• ssm:StartSession、ssm:ResumeSession の権限の使用を制限・監視する。
• Session Manager に管理されていない VM からの ssmmessages 権限を取り消す。
• 不要ならデフォルトのホスト管理設定は無効にする。
• 不要なら SSM エージェントをアンインストールする。

シリアル コンソール アクセス

ほとんどのクラウド サービス プロバイダーは、VM のブートやネットワーク構成の問題をトラブルシュートする機能として、シリアル コンソール アクセスを提供しています。この機能は、ネットワークやオペレーティング システムの状態に関係なく、VM へのテキストベースのコンソール アクセスを提供します。

ネットワークベースのアクセス制御はシリアル コンソール アクセスには適用されません。したがって攻撃者がシリアル コンソールの権限を得た場合、この機能が悪用され、ネットワークベースのファイアウォール制限が回避されて、VM に不正にアクセスされるおそれがあります。なお、シリアル コンソール アクセスはユーザー認証を回避するわけではない点にはご注意ください。VM にログインするには、やはり有効なパスワードか秘密鍵が必要です。

AWS: シリアル ポート経由でログインする

Amazon EC2 シリアル コンソールは、EC2 インスタンスのシリアル ポートへのアクセスを提供します。

条件:

• シリアル コンソール アクセスがアカウント レベルで有効化されていること。
• プリンシパルがアクセスを有効化できるよう ec2:EnableSerialConsoleAccess 権限を持っていること。
• VM のインスタンス タイプがサポートされているタイプの 1 つであること。Nitro System 上でビルドされるほとんどのインスタンスがサポート対象。
  • プリンシパルに ec2:ModifyInstanceAttribute 権限があれば VM のインスタンス タイプを変更可能。
• プリンシパルがインスタンスに SSH 公開鍵をプッシュするための有効なパスワードか権限を持っていること。
  • プリンシパルに ec2-instance-connect:SendSerialConsoleSSHPublicKey 権限があればシリアル コンソール経由で SSH キーを VM にプッシュ可能。

緩和策:

• アカウント レベルでシリアル コンソール アクセスを無効にする。
• ec2:EnableSerialConsoleAccess、ec2-instance-connect:SendSerialConsoleSSHPublicKey の権限の使用を制限・監視する。

Azure: シリアル ポート経由でログインする

Azure シリアル コンソールは VM インスタンスへのテキストベースのコンソール アクセスを提供します。

条件:

• シリアル コンソールがサブスクリプション レベルで有効化されていること。デフォルトは有効。
• VM のブート診断が有効化されていること。
• Linux では getty、Windows では SAC など、VM のゲスト OS でターミナル管理サービスが有効化されていること。デフォルトは有効。
• VM ゲスト OS にローカル ログイン用にテキストベースのユーザー認証 (有効なユーザー/パスワードなど) が構成されていること。
• プリンシパルがシリアル ポート経由でVMに接続するための次の権限を持っていること。
  • Microsoft.Compute/virtualMachines/start/action
  • Microsoft.Compute/virtualMachines/read
  • Microsoft.Compute/virtualMachines/write
  • Microsoft.Resources/subscriptions/resourceGroups/read
  • Microsoft.Storage/storageAccounts/listKeys/action
  • Microsoft.Storage/storageAccounts/read
  • Microsoft.SerialConsole/serialPorts/connect/action

緩和策:

• Microsoft.SerialConsole/serialPorts/connect/action 権限の使用を制限・監視する。
• サブスクリプション レベルでのシリアル コンソール アクセスを無効化する。
• 個々の VM に対しブート診断を無効化する。
• 個々の VM に対しターミナル管理サービスを無効化する。
• 個々の VM に対するユーザー名/パスワードなど、ローカル ログインのテキストベース認証を無効化する。

GCP: シリアル ポート経由でログインする

GCP では、シリアル ポート経由で VM に接続するのに別の方法を提供しています。Compute Engine のシリアル ポート アクセスは、メタデータ サービス内で serial-port-enable メタデータ キーを更新することによって有効化できます。

条件:

• ゲスト エージェントが VM にインストールされ、アクティブになっていること。
• プリンシパルが VM のメタデータを更新する次の権限を持っていること。
  • compute.instances.setMetadata (VM の インスタンス メタデータ経由)
  • compute.projects.setCommonInstanceMetadata (プロジェクト レベルのメタデータ経由)
  • インスタンスのサービスアカウント上の iam.serviceAccountUser ロール

緩和策:

• compute.instances.setMetadata と compute.projects.setCommonInstanceMetadata 権限の使用を制限・監視する。
• iam.serviceAccountUser ロールの使用を制限・監視する。
• 組織ポリシーを通じてシリアル ポート アクセスを無効化する。
• VM 上の OS Config エージェントを無効化する。

結論

本稿では VM に対して起こりうる攻撃経路の概要を示し、組織がクラウド セキュリティ強化に向けて実装できる緩和戦略を解説しました。クラウド環境における VM のセキュリティ態勢維持はきわめて重要です。

VM は利用数も多いですし、ワークロード ID の権限も備わっているので、攻撃者にとっては垂涎の的です。なお、本稿で解説した攻撃経路はいずれも、正当なユース ケースを持つ意図された機能に基づいています。ただ、そうした機能の保護を適切に講じていないと、攻撃者らに悪質な目的で利用されてしまうおそれがあります。こうした攻撃経路を保護し、潜在的リスクを緩和する責任はクラウド ユーザーにあります。

攻撃経路を有効においても関連リスクの緩和においても重要な役割を果たすのが IAM の構成です。クラウド セキュリティを堅牢化するには、これらの攻撃経路を継続的に特定し、危険な権限の使用を監視することが重要です。

クラウド環境の進化とともに、サイバー攻撃者の使う TTP も進化していきます。組織はクラウド セキュリティの取り組みにおいて常に警戒を怠らず積極的に動くことで進化する脅威への対抗戦略を適応させていく必要があります。

パロアルトネットワークスの保護と緩和策

パロアルトネットワークスのお客さまは、以下の製品を通じて、上記の脅威からより強力に保護されています。

• Prisma Cloud をご利用のお客さまは、潜在的な攻撃経路を継続的に監視し、警告してくれるAttack Path ポリシーよって、より強力に保護されています。
• Cortex XDR は、エクスプロイトに加えて検出しづらいクラウドベースの攻撃も検出・ブロックします。
• Cortex Xpanse を使うと、パブリック クラウド プロバイダーで実行されているシャドー IT を検出し、それらのリソースを管理下に置くことができます。

侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、infojapan@paloaltonetworks.com までメールにてご連絡いただくか、下記の電話番号までお問い合わせください(ご相談は弊社製品のお客さまには限定されません)。

• 北米フリーダイヤル: 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 にてご確認ください｡

追加リソース

パロアルトネットワークス

• Prisma Cloud
• Prisma Cloudによる脆弱性管理
• Prisma Cloud attack path policies
• Cortex XDR
• Unit 42 インシデント レスポンス チームの連絡先
• Unit 42 クラウド脅威レポート
• クラウドを渡る技術: クラウド環境のラテラルムーブ術
• ゼロデイとアクセス キーがクラウドで出会うとき: SugarCRM のゼロデイ脆弱性への対応
• オペレーション CloudKeys: 露出した AWS の IAM キーを悪用するクリプトマイニング オペレーションの追跡

AWS

• Amazon Inspector
• インスタンス ユーザー データの使用
• EC2 インスタンス再起動ごとのスクリプト実行
• EC2 Instance Connect
• EC2 Instance Connect エージェント
• EC2 Instance Connect の権限
• EC2 Instance Connect のアンインストール
• SSM Run Command
• SSM エージェントのインストール
• SSM エージェントのアンインストール
• AmazonSSMManagedInstanceCore ポリシー
• SSM エージェントが実行できるドキュメントの制限
• デフォルトのホスト管理設定
• SSM Session Manager
• Session Manager の権限
• Amazon EC2 シリアル コンソール
• シリアル コンソールへのアカウントア クセスの権限
• シリアル コンソール アクセスをサポートするインスタンス タイプ

Azure

• Microsoft Defender for Cloud
• 仮想マシンのカスタム データ
• 仮想マシンのスケール セット プロパティの変更
• VMSS の状態更新コマンド
• Azure 仮想マシンの再イメージ化
• 仮想マシンの拡張機能
• VMAccess 拡張機能
• Linux VM エージェント
• VM 拡張機能のインストール権限
• VM のユーザー アカウント管理コマンド
• Microsoft.Compute/virtualMachines/extensions
• Run Command
• Run Command へのアクセスを制限する
• カスタム スクリプトの拡張機能
• Azure シリアル コンソール
• サブスクリプション レベルでの Azure シリアル コンソール有効化/無効化
• Linux 用 Azure シリアル コンソール
• Windows 用 Azure シリアル コンソール
• ブート診断
• シリアル コンソールへのアクセス権限
• シリアル コンソールの有効化・無効化
• コントロール プレーンとデータ プレーン

GCP

• Google Security Command Center
• VM メタデータ
• 事前定義されたメタデータキー
• Linux スタートアップ スクリプトのメタデータキー
• メタデータでの OS Config の有効化
• ゲスト エージェントのインストール
• VM の再起動またはリブート
• メタデータ ベースの SSH 認証鍵を使用する VM への SSH 認証鍵の追加
• VM からの SSH 認証鍵の制限
• OS Login の概要
• OS Login の有効化
• Compute OS Login role
• Compute OS Login External User role
• 2 要素認証 (2FA) を使う OS Login の設定
• OS Login でのセキュリティ キー有効化
• VM Manager
• Compute Engine Patch
• パッチ ジョブの作成
• パッチ ジョブの作成権限
• Compute Engine の OS ポリシー
• OS ポリシーでのスクリプト実行
• OS ポリシーの割り当て作成権限
• メタデータでのパッチまたは OS ポリシーの無効化
• シリアル コンソールの有効化
• 組織ポリシーによるシリアル コンソール アクセスの無効化

そのほか

• 踏み台インスタンス
• sshd configuration file
• ssh authorized_keys
• Cyber Threat Alliance