Google Compute Engine 内でのラテラル ムーブメントを防ぐ

※この投稿は米国時間 2020 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud に移行する組織のセキュリティ運用チームから次のような質問を受けることがよくあります。「デプロイメントへの不正な侵入を防ぎ、ラテラル ムーブメントに対する防御力を高めるにはどうすればよいですか？」ラテラル ムーブメントでは、攻撃者がシステムに侵入した後にシステム内部を動き回り、機密性の高いデータへのアクセス権を奪います。

ラテラル ムーブメントを防ぎ、組織のセキュリティを維持するには、「多層防御」のアプローチをとることをおすすめします。そうすれば、互いに補強し合うように構築された複数のセキュリティ レイヤによってユーザーやデータを保護できます。あるレイヤが回避または突破された場合でも、他に多くのセキュリティ レイヤが控えており、攻撃者の目的遂行を阻止します。

Compute Engine に多層防御アプローチを導入するには、以下のことを実施する必要があります。

• 本番環境リソースをインターネットから切り離す
• デフォルト サービス アカウントを無効にする
  
• サービス アカウントの認証情報へのアクセスを制限する
  
• OS Login を使用して VM へのアクセスを管理する
  
• 最小権限の原則を適用する
  
• ログを収集してシステムをモニタリングする
  

これらの推奨される対策について 1 つずつ詳しく見ていきましょう。

本番環境リソースをインターネットから切り離す

Compute Engine インスタンスへの不正侵入を許さない最も効果的な方法は、公共インターネットへの露出を最小限に抑えることです。Compute Engine VM は、内部または外部 IP アドレスを持つことができます。攻撃可能面を最小化するには、Cloud NAT を使用して VM に内部 IP アドレスのみを割り当て、Identity-Aware Proxy（IAP）を使用してインターネットからのキュレートされたアクセスを許可します。

VM を外部 IP アドレスで直接公開しなければならない場合は、ファイアウォール ルールによってネットワーク アクセスをアプリケーションに必要なポートと IP アドレスのみに制限します。

禁止事項

• VM に外部 IP アドレスを割り当てる。
• インターネット上の誰でも VM に接続できる寛容なファイアウォール ルールを構成する。
  

推奨事項

• VM にプライベート IP アドレスを割り当て、パブリック IP アドレスは一切割り当てない。管理者として VM に接続する際は IAP の TCP 転送を使用し、Cloud NAT によって VM からインターネットへのアクセスを許可します。IAP は、ユーザーの ID とリクエストのコンテキストに基づいてユーザーにアプリケーションや VM へのアクセスを許可すべきかどうかを判断します。Compute Engine に対して IAP を設定するには、このページの手順に沿って操作してください。
• 組織のポリシーを使用して、VM インスタンスに対して許可される外部 IP を定義し、外部 IP アドレスを持つ新しい VM インスタンスが作成または構成されないようにする。
• セキュリティ状況の分析を使用して、外部 IP アドレスを持つ VM と制約が緩すぎるファイアウォール ルールを検出する（注: セキュリティ状況の分析機能の一部は、Security Command Center のプレミアム エディションでのみ使用できます）。以下のセキュリティ結果を確認し、解決します。
• 　 - PUBLIC_IP_ADDRESS: Compute Engine インスタンスに外部 IP アドレスが割り当てられていることを示します。
•      - OPEN_FIREWALL: 任意の IP アドレスまたは任意のポートからのアクセスを許可するファイアウォール ルールが構成されていることを示します。
  
• VPC Service Controls を使用して Google Cloud リソースを分離するセキュリティ境界を構成し、たとえ正規のクライアントによるものであっても、機密データの漏洩を防止する。
• Compute Engine インスタンスの古いメタデータ API を無効にし、アプリケーションを v1 メタデータ API に移行してサーバーサイド リクエスト フォージェリ（SSRF）攻撃を防ぐ。

しかし、予防対策を講じたにもかかわらず、それでも攻撃者がどうにかして VM に不正侵入した場合はどうなるでしょうか。次に、不正侵入の影響を抑え、攻撃者が内部を動き回って他のリソースへのアクセス権を取得することを阻止する方法を見ていきます。

デフォルト サービス アカウントを無効にする

ID と API へのアクセス権を構成することは、VM を作成する際に不可欠なステップです。この構成作業には、VM で実行されるアプリケーションによって使用されるサービス アカウントを指定することが含まれます。Google Cloud では、アプリケーションに権限を付与する方法が 2 通り用意されています。Compute Engine のデフォルト サービス アカウントを使用する方法と、ユーザーが作成したサービス アカウントを使用する方法です。

Compute Engine のデフォルト サービス アカウントは Google Cloud Console プロジェクトによって自動的に作成され、自動生成された名前とメールアドレスを持ちます。オンボーディング プロセスを簡単にするため、デフォルト サービス アカウントにはプロジェクト編集者の IAM ロールが自動的に付与されます。つまり、このサービス アカウントには、プロジェクト内のほぼすべてのリソースに対する読み取りおよび書き込みアクセス権があります（他のサービス アカウントに成り代わる権限を含む）。これらの権限は制約が緩いため、組織のポリシーを使用してこのロールの自動付与を無効にすることをおすすめします。その代わりに、Compute Engine のデフォルト サービス アカウントに付与されたすべてのアクセス権を削除し、VM に必要な権限のみが付与された新しいサービス アカウントを作成します。

禁止事項

• 編集者の基本ロールが付与された Compute Engine のデフォルト サービス アカウントを使用する。
• 異なる VM で実行される異なるアプリケーションに対して同じサービス アカウントを使用する。

推奨事項

• Compute Engine のデフォルト サービス アカウントの編集者ロールを取り消し、必要な権限のみを持つ新しいサービス アカウントを VM 用に作成する。
•  Compute Engine のデフォルト サービス アカウントを無効にする。
• 組織のポリシーで [デフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化] をオンに設定し、Compute Engine のデフォルト サービス アカウントに編集者ロールがデフォルトで付与されないようにする。
• セキュリティ状況の分析を使用して以下の構成ミスを検出し、解決する。
•  - FULL_API_ACCESS: VM インスタンスが、すべての Google Cloud API への完全アクセス権を持つデフォルト サービス アカウントを使用するように構成されていることを示します。
  

サービス アカウントの認証情報へのアクセスを制限する

攻撃者によるサービス アカウントへのなりすましを防ぐには、サービス アカウント キーの作成を可能な限り避け、既存のキーへのアクセスを保護する必要があります。サービス アカウント キーは Google Cloud の外部ワークロードがサービス アカウントとして認証できるようにすることを目的としたものですが、Google Cloud 内で運用するとき、サービス アカウント キーを使用する必要はほとんどありません。

禁止事項

• サービス アカウント用の秘密鍵を生成してダウンロードする。Compute Engine インスタンスは自動的に、構成されたサービス アカウントに成り代わることができます。
• サービス アカウント ユーザーまたはサービス アカウント トークン作成者のロールをプロジェクト レベルで付与する。その代わりに、これらのロールを個々のサービス アカウントに必要に応じて付与します。サービス アカウント ユーザーのロールが付与されたユーザーは、サービス アカウントの代わりに長時間実行ジョブを開始できます。サービス アカウント トークン作成者のロールが付与されたユーザーは、そのサービス アカウントに直接成り代わる（そのサービス アカウント自身であると表明する）ことができます。

推奨事項

• 組織のポリシーで以下のことを行う。
•  - [サービス アカウント キーの作成を無効化] をオンに設定して、ユーザーがサービス アカウント用のユーザー管理秘密鍵を作成してダウンロードすることを禁止する。
  
•  - サービス アカウントをホストしないプロジェクトのために [サービス アカウントの作成を無効化] をオンに設定する。
  
• サービス アカウント キーのアップロードを使用して、オンプレミス サービスの Google Cloud に対する認証にハードウェア セキュリティ モジュールの鍵を使用する。これにより、サービス アカウントの秘密鍵が漏洩する可能性が最小限に抑えられます。
  
• エクスポートされたサービス アカウント キーを使用する代わりに、--impersonate-service-account フラグを使用して gcloud コマンドをサービス アカウントとして実行する。これはリクエストごとに構成できるほか、gcloud config set auth/impersonate_service_account {service_account_email} を実行することですべての gcloud コマンドに対して構成することもできます。
  
• セキュリティ状況の分析を使用して、サービス アカウントのユーザーロールと既存のサービス アカウント キーの寛容な使用を検出する。以下の検出結果について確認します。
  
•  - SERVICE_ACCOUNT_KEY_USER_MANAGED: サービス アカウント用のユーザー管理秘密鍵が存在することを示します。
  
•  - SERVICE_ACCOUNT_KEY_NOT_ROTATED: サービス アカウント用のユーザー管理秘密鍵が 90 日間ローテーションされていないことを示します。
  
•  - OVER_PRIVILEGED_SERVICE_ACCOUNT_USER: ある IAM メンバーが、特定のサービス アカウントのためではなくプロジェクト レベルでサービス アカウントのユーザーロールを持っていることを示します。
  

OS Login を使用して VM へのアクセスを管理する

攻撃者が権限を昇格して他の VM へのアクセス権を取得する方法の一つに、プロジェクトのメタデータに格納されている SSH 認証鍵を探すという方法があります。VM へのアクセスに使用される SSH 認証鍵を手動で管理すると、余計な時間がかかり、リスクも高くなります。SSH 認証鍵を手動で管理する代わりに OS Login を使用し、IAM の ID に基づいて VM へのアクセス権を付与することをおすすめします。OS Login が有効になっている場合、SSH 認証鍵は無視されるため、攻撃者が SSH 認証鍵をインスタンス メタデータにアップロードすることによって新しい VM へのアクセス権を取得することはできません。固有のユーザーと SSH 認証鍵の構成に依存しているワークフローの下位互換性を維持するため、OS Login はデフォルトでは無効になっています。VM インスタンスへのアクセスの管理の詳細については、こちらをご覧ください。

禁止事項

• SSH 認証鍵を VM インスタンス メタデータに格納して手動で管理する。
• プロジェクト内のすべての VM への接続に使用できるプロジェクト全体の SSH 認証鍵を許可する。

推奨事項

• OS Login を使用して、VM へのアクセスを IAM の ID に基づいて管理する。
• 組織のポリシーで OS Login を必須にする。これにより、新しいプロジェクトで作成されたすべての VM インスタンスで OS Login が有効になります。この制約は、新規および既存のプロジェクトにおいて、OS Login がプロジェクト レベルまたはインスタンス レベルで無効になるようなメタデータの更新を防ぎます。
• セキュリティ状況の分析を使用して、OS Login が有効であること、およびプロジェクト全体の SSH 認証鍵が使用されていないことを確認する。以下のタイプの構成ミスがないか確認します。
•  - OS_LOGIN_DISABLED: OS Login が VM インスタンスで無効になっていることを示します。
  
•  - COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED: あるプロジェクト内のすべての Compute Engine インスタンスへのログインを許可するプロジェクト全体の SSH 認証鍵が使用されていることを示します。
  
•  - ADMIN_SERVICE_ACCOUNT: あるサービス アカウントに、所有者のアクセス権、または roles/compute.osAdminLogin などの管理者ロールが付与されていることを示します。これらの権限があると、OS Login の設定を変更できるか、sudo を実行できます。
  

最小権限の原則を適用する

すべての VM インスタンス、サービス アカウント、ユーザーが、正当なビジネス オペレーションに必要な情報とリソースのみにアクセスできるようにすることは、特に VM の数が多い場合には難題です。Google Cloud の IAM Recommender は、組織内での適正サイズの権限管理を支援するため、機械学習を活用してプロジェクトの実際の権限使用状況をモニタリングし、過度に寛容なロールの代わりとなるより限定的で制約の大きいロールを提案します。この機能は、削除しても問題ない権限を提案するほか、今後のアクセス権のニーズの予測も示します。

IAM Recommender からの提案を検討してそれを適用する方法の詳細については、推奨事項を使用して最小権限を適用するのページをご覧ください。最小権限の原則の適用に関するヒントについては、このブログ投稿をお読みください。

禁止事項

• IAM の基本ロールである所有者、編集者、閲覧者を使用する。

推奨事項

• Policy Intelligence を有効にし、IAM Recommender を使用して過剰な権限を検出、修正する。
• 組織のポリシーで [ドメインで制限された共有] をオンに設定し、構成された組織の外部のメンバーに IAM ポリシーによる権限の付与が行われないようにする。
• 事前定義された IAM ロールで付与される権限が必要な範囲を超えている場合は、カスタムロールを作成して使用することを検討する。

ログを収集してシステムをモニタリングする

強力な予防対策は、悪意あるアクティビティの効果的な検出によって補完する必要があります。適切なログを収集することは、セキュリティの調査やフォレンジックの基本です。データアクセス ログは必ず有効にしてください。これは Cloud Audit Logs の一部であり、Google Cloud リソース内で「誰がいつどこで何をしたか」を明らかにします。

推奨事項

• データアクセス ログを有効にする。データアクセス監査ログには、リソースの構成やメタデータを読み取る API 呼び出しや、ユーザー提供のリソースデータの作成、変更、読み取りを行うユーザー主導の API 呼び出しが記録されます。データアクセス監査ログは大量のログデータを生成する可能性があるため、デフォルトでは無効になっています。
• VPC Service Controls をドライラン モードで有効にする。組織内でまだサービス境界を適用できない場合でも、ドライラン モードを有効にしてそのようなリクエストをログに記録できます。これにより、組織またはプロジェクトを越えたデータの移動に関する情報が得られます。
• 以下のような Security Command Center のプレミアム機能を使用する。
•  - セキュリティ状況の分析で次の検出結果を見て、組織全体でロギングが適切に有効になっていることを確認します。AUDIT_LOGGING_DISABLED: データアクセス ログが有効になっていない、または特定のユーザーが除外されていることを示します。FLOW_LOGS_DISABLED: フローログが無効になっている VPC サブネットワークが存在することを示します。
  
•  - セキュリティ状況の分析を使用して、組織外部のユーザー（Gmail アドレスを使用しているユーザーなど）にプロジェクトへのアクセス権が付与されているかどうかを検出します。NON_ORG_IAM_MEMBER: 組織の認証情報を使用していない IAM メンバー ユーザーが存在することを示します。
  
•  - Event Threat Detection を使用してログを自動的にスキャンし、IAM によって組織外部のユーザーに過度に寛容な権限が付与されている、クリプトマイニング、既知の有害な IP アドレスまたはドメインへの接続、発信 DDoS 攻撃などの不審なアクティビティについて警告を受けます。
  

参考情報

これらの提案が、皆様のクラウド環境におけるラテラル ムーブメントの防御や検出に役立つと幸いです。Google Cloud でのセキュリティのベスト プラクティスについて詳しく知るには、Center for Internet Security が発行している CIS Google Cloud Platform 基礎ベンチマークをご覧になり、セキュリティ状況の分析機能によって提供される詳細な推奨事項を確認してください。Kubernetes ワークロードを保護する方法の詳細については、CIS Google Kubernetes Engine（GKE）ベンチマークをご覧ください。Terraform を使用してデプロイメントを管理している場合は、Config Validator を設定することで、セキュリティの構成ミスをデプロイ前に検出できます。

最後に、Google のインフラストラクチャがどのように保護されているかをより深く理解し、Google のセキュリティ ソリューションの詳細を知るには、Google Cloud のセキュリティに関するページをご覧ください。 

-Google Cloud ソフトウェア エンジニア Iulia Ion

-Google Cloud ソフトウェア エンジニア Josh Strom