Google Cloud で認証情報の盗難リスクを最小化する 5 つの方法

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

クラウド環境を標的とする脅威アクターが、セキュリティ侵害が起きているクラウド ID の悪用を試みる傾向が強まっています。人間以外のものを含め、ID のセキュリティ侵害が起こると、クラウド リソースの乱用や機密データの引き出しなどのリスクが増大します。これらのリスクは、ほとんどの組織に膨大な数の ID が存在する事実により、さらに大きくなります。ID の数が増えるほど、攻撃対象領域も拡大するためです。

最新版の Google Cloud の Threat Horizons レポートに記載されているように、組織は ID 保護の強化を優先的に行うべきです。

「自動化を進め意識を高めるための戦略を組織に組み入れることをおすすめします。たとえば、安全なパスワードのポリシー、多要素認証の必須化、ユーザー アクセスと Cloud Storage バケット セキュリティの定期的な見直し、ダークウェブでの漏洩した認証情報のモニタリング、アカウント ロックアウトのメカニズムなどが挙げられます。」と、セキュリティ エンジニアリング担当シニア ディレクターを務める Iain Mulholland は、先週の「Cloud CISO の視点」ニュースレターで述べています。

本日は、Google Cloud のセキュリティの専門家が、すぐに実行できる重要なリスク軽減策について詳しく解説します。あらゆる組織に当てはまる内容ですので、クラウド デプロイメントの保護策の候補としてご検討ください。

Google Cloud に組み込まれている保護機能

Google Cloud には、認証情報の盗難リスク軽減に役立つ、常時作動のアカウント保護機能があります。その多くは、ヒューリスティックス（論理ではなく試行錯誤に基づく問題解決法）を活用して認証情報の盗難の可能性が高い行為を検出し、攻撃者のセッションを終了します。また、盗まれた疑いがある Cookie の使用を、通常の数時間から変更して数分間に制限するものもあります。

また、Google Cloud では認証情報の有効性を確認するために、Google Cloud コンソールでの操作前にユーザーに再認証を求めることがあり、多数の機密性の高い操作がその対象となっています。この再認証は決定的に行われることも、リスクスコアに基づいて行われることもあります。

さらに Google Cloud は、サービス認証情報の盗難や不正なリソース共有といった一般的なリスクから組織を保護するために、新たに作成された組織にデフォルトの組織のポリシーを設定します。

しかし、攻撃手法の進化に伴い、多要素認証（MFA）、セッションの保護、サービス認証情報の保護、ID およびアクセス制御、セキュリティ モニタリングの全体にわたる、保護レイヤの追加が重要となっています。

Google Cloud のお客様には、認証情報の盗難に対する保護を強化するために、次の対策を採用することをおすすめします。

1. 多要素認証（MFA）: Google がお客様を支援するために設定した運命共有アプローチの一環として、すべての Google Cloud ユーザーに対して今年中に MFA を必須にする計画について最近解説しました。MFA をまだ有効にしていない場合、必須になる前に次の手順で有効化することをご検討ください。

1. プライマリ ID プロバイダ（IdP）で MFA を有効にします。プライマリ IdP として Google Cloud Identity を使用している Google Cloud のお客様は、こちらの手順に沿って操作してください。

2. 再認証を行うための MFA 手段を Google Cloud Identity アカウントに追加します。Google Cloud Identity がプライマリ IdP でない場合、これを機密性の高い操作を許可する前の独立した確認手段として使用できます。こちらの手順に沿って操作してください。

3. ユーザーが Google にアクセスするとき、常に認証を要求するように IdP を構成します（MFA が望ましい）。Google Cloud のお客様が SAML または OIDC を介して独自の IdP で Cloud Identity を利用している場合、セッションがタイムアウトするとき、または Google Cloud が再認証を必要とするとき、Cloud Identity は IdP に対して証明情報を求めます。デフォルトの構成では、ユーザーの負担を減らすために IdP はこれらの証明情報をすべて自動的に承認します。しかし、ほとんどの IdP では、認証情報の再入力を必須にする構成や、さらには Google Cloud から証明情報が要求されたときに MFA を必須にする構成が可能です。この構成は、ユーザーと管理者のエクスペリエンスが円滑になるよう、IdP が連携するすべてのアプリではなく、Google Cloud に含まれるアプリにのみ適用されるよう設定可能です。

2. セッションの保護: セッションの保護の強化に役立つ以下の 4 つのコントロールの使用をおすすめします。

1. セッションの長さを制限すると、盗まれた Cookie の有用性を下げることができます。デフォルトのセッション時間は 16 時間で、ユーザーが構成可能です。セッション継続時間を設定する手順をご確認ください。また、ご関心のある方はセッション継続時間の管理についてのブログもお読みください。

2. Google Cloud コンソールと API にコンテキストアウェア アクセス（CAA）でアクセスできる IP を制限すると、盗まれた認証情報は役に立たなくなります（ただし、企業ネットワークや VPN など、許可リストに登録済みの IP に攻撃者がアクセスできる場合は例外）。

3. 証明書ベースのアクセスを使用すると、ユーザーが Google Cloud コンソールや Google Cloud API にアクセスするとき、mTLS 証明書を要求できます。mTLS はユーザーに対して、Cookie など既存の認証情報に加えて mTLS 証明書の提示を要求することで、Cookie の盗難を効果的に防止できます。mTLS 証明書は一般にユーザーのデバイスのトラステッド プラットフォーム モジュール（TPM）に保存されるため、攻撃者が盗むのは非常に困難です。多くの企業は、すでにユーザーに対して mTLS 証明書をデプロイしています。Google Cloud では、お客様は既存の mTLS 証明書を再利用するか、Google Cloud 専用の新しい証明書を使用するかを選択できます。

4. Access Context Manager でコンテキストに応じたアクセス制限を構成できます。これによって Google Cloud 組織管理者は、プロジェクトとリソースに対してきめ細かな属性ベースのアクセス制御を定義できます。アクセスレベルは、デバイスとユーザーの属性に関する追加の条件が満たされたときにのみリソース リクエストが許可されるように構成できます。たとえば、リソースへのアクセスと構成を行う際は、組織で管理されているデバイスを使用するよう要求できます。

3. サービス認証情報の保護: 組織は、人間以外の ID についても多層的な保護を構築すべきです。Google Cloud は、サービス アカウント キーと API キーの管理、使用、セキュリティ保護を行うための詳細なベスト プラクティスを提供しています。検討すべき 3 つの重要なコントロールを以下に示します。

1. サービス アカウント キーの作成を無効化する: この組織のポリシー設定により、ユーザーはサービス アカウント用の永続的なキーを作成できなくなります。サービス アカウント キーの使用を制限なく許可する代わりに、ユースケースに適した認証方法を選択し、より安全な代替手段がない場合にのみ例外としてサービス アカウント キーの使用を許可します。

2. 漏洩したサービス アカウント キーを自動的に無効化する: Google Cloud は、漏洩したサービス アカウント キーがないか公開リポジトリ（GitHub や Gitlab を含む）を定期的にスキャンし、漏洩したキーを検出すると、自動的にそのキーを無効化します。また、Cloud Audit Logs イベントを作成し、漏洩したキーについての通知をプロジェクト オーナーとセキュリティ担当者に送信します。DISABLE_KEY オプションは変更しないことを強くおすすめします（デフォルトでオンです）。

3. サービス アカウント キーを信頼できるネットワークにバインドする: サービス アカウント用のコンテキストアウェア アクセスにより、お客様はサービス アカウントを一定範囲の IP または特定の VPC ネットワークにバインドし、それらの信頼できるネットワークからのみ Google Cloud サービスや API にアクセス可能となるように設定できます。お客様は、こちらのフォームを使用してこのコントロールの早期アクセス版をリクエストできます。

4. ID とアクセス制御: 最小権限の原則を守ることで、認証情報の侵害が起きたときの影響を軽減できます。これらのコントロールを使用して、ユーザーが職務を遂行するために必要なアクセスや権限のみを付与します。

1. Google Cloud の Identity and Access Management（IAM）では、特定の Google Cloud リソースへのきめ細かなアクセスを付与し、他のリソースへのアクセスを防止できます。権限はロールとしてグループ化し、認証されたプリンシパルに付与します。IAM Recommender などのツールを使用して、アクセス許可を定期的にレビューし、適正な範囲に調整してください。Google Cloud アーキテクチャ フレームワークでは、ID とアクセスを管理するための追加のベスト プラクティスを提示しています。

2. VPC Service Controls では、強固でコンテキストアウェアな手法でクラウド リソースへのアクセスをコントロールできます。ユーザーの ID や IP アドレスなどの属性に基づいて、きめ細かなアクセス制御ポリシーを作成できます。これらのポリシーは、クラウド リソースへのアクセス権を信頼されていないネットワークに付与する前に、特定のセキュリティ コントロールが設定されていることを確認します。承認済みネットワークからのみアクセスを許可することで、VPC Service Controls は、盗まれた OAuth やサービス アカウント認証情報を使用しているクライアントによるデータの引き出しリスクを低減します。

3. プリンシパル アクセス境界により、プリンシパルがアクセスできるリソースを明確に定義できます。プリンシパルがリソースにアクセスできないポリシー設定となっている場合、付与されたロールに関係なく、そのリソースへのアクセスが制限されます。

4. ドメインで制限された共有（共有先のドメインの制限）を使用してドメインごとに ID を制限し、特定のドメインまたは組織に属するユーザーのみにロールの付与対象を限定します。ドメインで制限された共有が有効な場合、許可されているドメインまたは組織に属するプリンシパルのみが、Google Cloud 組織の IAM ロールの付与対象となります。

5. セキュリティ モニタリング: 予防的なコントロールの実装に加えて、クラウド環境に侵害の兆候がないか積極的にモニタリングします。早期に検出できれば、侵害によるビジネスへの影響を抑えることができます。

1. Security Command Center（SCC）は、Google Cloud に組み込まれたセキュリティおよびリスク管理プラットフォームです。包括的なセキュリティ ポスチャー管理、脅威の検出、コンプライアンスのモニタリングが可能です。SCC のCloud Infrastructure Entitlement Management（CIEM）機能により、どの ID がデプロイメントのどのリソースにアクセス可能かを管理し、構成ミスによる脆弱性の発生を抑えて、最小権限の原則を適用できます。SCC 内の Sensitive Actions Service は、クラウド組織、フォルダ、プロジェクトで発生する、損害を引き起こす恐れがあるアクションを自動的に検出し、アラートを発します。SCC のVirtual Red Teaming 機能は、価値の高いリソースが危険にさらされていないかどうかを常時検出し、侵害につながる可能性のある ID とアクセスパスを明らかにします。

次のステップ

強固なセキュリティ ポスチャーを維持するには、組織が直面するリスクとその対策としてのコントロールを継続的に評価していく必要があります。この記事で紹介した推奨事項は、クラウド資産を強化し、認証情報の侵害に関連するリスクの高まりに対抗するうえで役立ちます。

Google Cloud デプロイメントを保護するためのその他の方法については、Google のセキュリティ ベスト プラクティス センターをご覧ください。

-Google Cloud Security、エンジニアリング担当シニア ディレクター、Panos Mavrommatis
-Google Cloud Security、エンジニアリング担当シニア ディレクター、Vikram Makhija