サービス アカウント キーから移行する

サービス アカウント キーは、Google Cloud サービスの認証によく使用されます。ただし、適切に管理されていない場合、認証情報の漏洩、権限昇格、情報開示、否認防止などの脅威に対する脆弱性が高まる可能性もあります。

多くの場合、サービス アカウント キーの代わりに、より安全な方法で認証を行うことができます。このガイドは、サービス アカウント キーが本当に必要な場合を除き、サービス アカウント キーをメインの認証メカニズムとする方法からより安全な認証手段に移行する方法について説明します。

このドキュメントは、より安全な認証メカニズムを優先してサービス アカウント キーの使用を減らし、セキュリティ ポスチャーを強化したいと考えているセキュリティ管理者を対象としています。既存の本番環境ワークロード、デベロッパーのワークフロー、サービス アカウント キーを使用する内部プロセスのセキュリティを担当している管理者が対象となる場合もあります。

概要

既存のワークロードからサービス アカウント キーを削除する場合は、偶発的な中断を防ぐため、慎重に計画を立てる必要があります。次の移行計画は、デベロッパーの混乱を最小限に抑えながら集中的に管理できるように設計されています。

この移行計画には、次の 3 つのフェーズがあります。

  • 評価: このフェーズでは、既存の環境を評価して、サービス アカウント キーが存在する場所と、キーが使用中かどうかを確認します。
  • 計画: このフェーズでは、最終的にデプロイするコントロールを決定し、関係者に移行計画を伝えます。
  • デプロイ: このフェーズでは、サービス アカウント キーに代わるより安全な方法で認証を行うため、ワークロードのリファクタリングを開始します。また、環境を継続的にモニタリングして、将来のリスクを軽減する追加機能を構築します。

サービス アカウント キーの使用状況を評価する

このフェーズでは、既存の環境を評価して、サービス アカウント キーが存在する場所と、キーが使用中かどうかを確認します。

以降のセクションでは、組織でのサービス アカウント キーの使用方法を把握するために収集するデータについて説明します。

キーの使用状況に関するデータを収集する

まず、サービス アカウント キーが存在する場所と使用状況を確認します。

Google Cloud には、サービス アカウントの使用状況を把握するためのツールが用意されています。これらのツールは、認証に最近使用されたサービス アカウントとキー、過去 90 日間使用されていないサービス アカウント、過剰な権限を含むロールが付与されたサービス アカウントを特定するのに役立ちます。

これらのツールの情報を組み合わせることで、組織全体でサービス アカウントとキーがどのように使用されているかをより正確に把握できます。こうしたソースからの情報を組織全体で統合する方法の例については、GitHub のデプロイ可能なリファレンス アーキテクチャをご覧ください。このリファレンス アーキテクチャは、さまざまなツールから収集したデータを集約し、分析のために定期的に BigQuery テーブルにエクスポートします。

このリファレンス アーキテクチャでは、Cloud Asset Inventory にクエリを実行して組織内のサービス アカウント キーを特定するデータ パイプラインをデプロイします。次に、そのデータを、関連するアカウントのキーの使用状況と権限の使用状況に関するデータと統合します。結果のテーブル（sa_key_usage）から、次のようなことを確認することができます。

  • 作成された永続キーの数。この数値は、キーからの移行の進行状況を追跡するための大まかな指標として役立ちます。
  • キーを使用するプロジェクトとサービス アカウント。この情報は、サービス アカウント キーを使用するワークロードのオーナーを識別するのに役立ちます。
  • アクティブでないキー。これらのキーは、ワークロード オーナーからの評価を待たずに削除できます。
  • 過剰な権限に関する推奨事項があるサービス アカウントのキー。サービス アカウント キーが、過剰な権限を持つサービス アカウント（特にオーナー、編集者、閲覧者のロールを持つアカウント）に関連付けられている場合、そのキーのリスクは特に高くなる可能性があります。ロールの推奨事項があるサービス アカウントを探すと、過剰な権限を持つサービス アカウントを特定できます。これらのサービス アカウントを特定した後、ワークロードの移行に優先順位を付けることができます。ロールの推奨事項を適用して、過剰な権限を事前に減らすこともできます。

このデータ パイプラインは毎日実行され、日付分割の BigQuery テーブルに書き込まれます。このテーブルを使用して、特定のサービス アカウントまたはキーを調査できます。また、Looker Studio などのダッシュボード ツールで修復状況を追跡することもできます。

コンテキストを追加してキーの使用状況データを拡充する

キーの使用状況のデータセットを作成した後、必要に応じてデータソースを追加し、データセットを拡張できます。リソースのガバナンスと来歴を追跡するために使用しているデータソースを追加することをおすすめします。既存のガバナンスに応じて、次のようなデータを追加できます。

  • 構成管理データベース（CMDB）または同様のシステムから収集する所有権情報。
  • プロジェクト ラベルで構成されたガバナンス情報（プロジェクトを担当するチームやコストセンターなど）。
  • Google Cloud の外部環境のワークロードに使用されるキーに関する環境情報。

サービス アカウント キーの使用量を減らすための計画を作成する

サービス アカウント キーの使用量を減らすために変更をデプロイする前に、影響を受けるワークロードと環境、それらの変更の適用方法を決定する必要があります。また、この計画をビジネス全体で共有し、ワークロード オーナーが計画をサポートするようにする必要があります。

以下のセクションでは、計画で対処すべき主なトピックについて説明します。具体的な計画は、組織の規模やワークロード固有の要件によって異なります。

現在のワークロード オーナーの責任を決定する

中央のセキュリティ チームは存在するキーを評価できますが、移行を成功させるにはワークロード オーナーのサポートが欠かせません。移行対象のキーの場合、ワークロード オーナーは、利用可能な認証方法の中からユースケースに適したものを判断し、その移行を実行する必要があります。

既存のセキュリティ ポスチャーの改善と、ワークロード オーナーの労力とのバランスを取る方法を検討する必要があります。以下のセクションでは、2 つのサンプル アプローチについて説明します。1 つはセキュリティ対策の改善に重点を置くアプローチで、もう 1 つはワークロード オーナーの労力を最小限に抑えることを優先するアプローチです。実際のアプローチは、これとは異なる場合があります。たとえば、対象となるワークロードを個別に選択する場合もあります。

例: 現在のすべてのワークロードが移行対象として評価される

考えられるアプローチの一つは、現在と将来のすべてのワークロードにサービス アカウント キーの制御を適用することです。この場合、次のようなステップが考えられます。

  • ワークロード オーナーと協力して、既存のワークロードのキーの使用状況を評価します。
  • 例外が認められていない限り、ワークロード オーナーは、キーを使用する既存のワークロードをすべて移行する必要があります。
  • 例外が認められていない限り、今後のすべてのワークロードでサービス アカウント キーを使用できないようにする必要があります。

このアプローチは既存のセキュリティ ポスチャーの改善を優先していますが、短期的にはデベロッパーとワークロード オーナーの負担が増加します。このような計画を成功させるには、ワークロード オーナーがワークロードのレビューとリファクタリングに参加する必要があります。

例: 現在のワークロードは移行対象として評価されていない

もう 1 つのアプローチは、既存のワークロードではサービス アカウント キーの継続使用を許可し、今後のワークロードにのみ新しいコントロールを適用する方法です。

このアプローチでは、将来のワークロードのセキュリティ ポスチャーが向上し、現在のワークロード オーナーの負担は最小限に抑えられます。ただし、既存のワークロードのセキュリティ ポスチャーは向上しません。

短期間で得られる成果を特定する

評価では、ワークロード オーナーによる追加の修復作業なしで安全に削除できるキーを特定できる場合があります。たとえば、キーが 90 日間アクティブでない場合や、アクティブでなくなったリソースにキーが関連付けられている場合は、別の認証メカニズムに移行しなくても、キーを安全に削除できます。

この条件を満たすキーのリストを作成します。このリストは、デプロイ フェーズで不要なキーを削除するために使用します。キーをリストに追加する前に、サービス アカウント キーに依存する本番環境への緊急のアクセスなど、サービス アカウント キーを頻繁に必要としないユースケースがあるかどうかを確認します。

組織のポリシーの変更を適用する場所を計画する

サービス アカウント キーからの移行を成功させるには、新しいキーが作成されないようにする必要があります。デプロイ フェーズで、iam.disableServiceAccountKeyCreation 組織のポリシーの制約を適用し、新しいサービス アカウント キーが作成されないようにします。

この制約によって既存のキーの使用が妨げられることはありませんが、キーを定期的にローテーションする既存のワークロードが中断される可能性があります。中断を最小限に抑えるために、デプロイ フェーズを開始する前にリソース階層のどこに制約を適用するか決定します。

最初は組織レベルではなく、プロジェクト レベルまたはフォルダレベルで制約を適用することもできます。たとえば、本番環境用のフォルダにデプロイする前に、開発環境に使用するフォルダに制約を適用します。また、多数のチームが存在する大規模な組織の場合は、最初に 1 つのチームのフォルダに制約を適用し、移行時に追加のフォルダに制約を適用することもできます。

タグを使用した組織のポリシーを使用して、プロジェクト レベルまたはフォルダレベルで組織ポリシーを条件付きで適用できます。

例外プロセスを設計する

この移行の目的は、サービス アカウント キーの使用を削減または排除することですが、サービス アカウント キーを必要とする正当なユースケースもあります。既存のワークロードにサービス アカウント キーが必要ない場合でも、将来のワークロードでサービス アカウント キーが必要になる可能性があります。したがって、サービス アカウント キーを必要とするユースケースを評価しての例外として承認する運用プロセスを定義しておく必要があります。

ワークロード オーナーがワークロードでのサービス アカウント キーの例外使用をリクエストできるプロセスを定義します。例外を担当する意思決定者には、ユースケースを検証するための技術的な知識が必要です。サービス アカウント キーの代わりとなる安全な方法をワークロードのオーナーと検討できる知識も必要です。また、サービス アカウント キーを管理するためのベスト プラクティスについてワークロード オーナーにアドバイスできる能力も求められます。

今後の変更をワークロード オーナーに伝える

計画を策定したら、その計画を組織全体に明確に檀達志、関係者（特に上級幹部）が移行に積極的に関与できるようにする必要があります。

具体的な移行の詳細は組織によって異なりますが、コミュニケーション計画に次のトピックを含めることを検討してください。

  • 安全でないサービス アカウント キーが組織にもたらす悪影響と、サービス アカウント キーから移行する目的。
  • サービス アカウント キーの作成を防ぐ新しいセキュリティ コントロールと、既存のプロセスへの影響。
  • サービス アカウント キーに代わるより安全な方法を特定するためのデベロッパー向けのガイダンス。
  • チームがサービス アカウント キーの例外使用をリクエストするプロセス（この例外が再評価される頻度を含む）。
  • 提案された変更を適用するタイムライン。

ワークロード オーナーと協力して計画を練り、組織全体で機能するようにします。

コントロールのデプロイとワークロードのリファクタリング

計画を作成してワークロード オーナーに伝えたら、サービス アカウント キーからの移行を開始できます。

このフェーズでは、サービス アカウント キーに代わるより安全な方法で認証を行うように、ワークロードをリファクタリングします。また、環境を継続的にモニタリングして、将来のリスクを軽減する追加機能を構築します。

以降のセクションでは、中断を最小限に抑えながらワークロードをリファクタリングし、キーを削除するステップについて説明します。これらのステップは、組織に必要な優先度と作業量に基づいて、任意の順序で行うことができます。

新しいサービス アカウント キーの作成を停止する制御を適用する

新しいサービス アカウント キーの作成を停止するには、iam.disableServiceAccountKeyCreation 組織のポリシーの制約を適用します。

ただし、この制約を適用する前に、ポリシーから除外するプロジェクトまたはフォルダにタグを追加する必要があります。サービス アカウント キーから移行できない既存のワークロードや、サービス アカウント キーのみで認証を行う正当な理由がある新しいワークロードについては、例外を許可できます。

除外対象のプロジェクトとフォルダにタグを追加したら、タグを使用した組織のポリシーを設定して、除外対象外のプロジェクトとフォルダに iam.disableServiceAccountKeyCreation 制約を適用できます。

適用対象外のすべてのプロジェクトとフォルダでサービス アカウント キーが作成されないようにするには、次の操作を行います。

  1. 組織レベルでのタグの管理と組織のポリシーの管理に必要な IAM ロールがあることを確認します。

  2. 組織レベルで、プロジェクトまたはフォルダを組織のポリシーから除外するかどうかを定義するために、タグキーとタグ値を作成します。キー disableServiceAccountKeyCreation と値 enforced と not_enforced を使用してタグを作成することをおすすめします。

    タグキーとタグ値の作成方法については、新しいタグの作成と定義をご覧ください。

  3. disableServiceAccountKeyCreation タグを組織に適用し、その値を enforced に設定します。組織内のすべてのプロジェクトまたはフォルダは、別のタグ値で上書きされない限り、このタグ値を継承します。

    リソースにタグを適用する方法については、リソースへのタグの適用をご覧ください。

  4. 組織のポリシーから除外するプロジェクトまたはフォルダごとに disableServiceAccountKeyCreation タグを付けて、その値を not_enforced に設定します。この方法でプロジェクトまたはフォルダにタグ値を設定すると、組織から継承されたタグ値がオーバーライドされます。

  5. 除外リソースを除くすべてのリソースのサービス アカウント キーを作成できないようにする組織のポリシーを作成します。このポリシーには、次のルールが必要です。

    • disableServiceAccountKeyCreation: not_enforced タグの付いたリソースに適用されないように iam.disableServiceAccountKeyCreation 制約を構成します。このルールの条件は次のようになります。

      resource.matchTag(\"ORGANIZATION_ID/disableServiceAccountKeyCreation\", \"not_enforced\")

    • 他のすべてのリソースに適用されるように iam.disableServiceAccountKeyCreation 制約を構成します。

    タグ条件を使用して組織のポリシーを作成する方法については、タグを使用した組織のポリシーの設定をご覧ください。

既存のワークロードを修正する

サービス アカウント キーを使用するワークロードごとに、ワークロードのオーナーと協力して、別の認証方法を選択して実装します。

Google Cloud CLI、Cloud クライアント ライブラリ、Terraform など、アプリケーションのデフォルト認証情報（ADC）をサポートするツールまたは REST リクエストを介して Google Cloud サービスにアクセスする場合は、次の図を参考にして認証方法を選択してください。

ユースケースに基づいて認証方法を選択するためのディシジョン ツリー

この図には、次の質問が記載されています。

  1. シングル ユーザー開発環境（独自のワークステーション、Cloud Shell、仮想デスクトップ インターフェースなど）でコードを実行していますか？
    1. 「はい」の場合は、質問 4 に進みます。
    2. 「いいえ」の場合は、質問 2 に進みます。
  2. Google Cloud でコードを実行していますか？
    1. 「はい」の場合は、質問 3 に進みます。
    2. 「いいえ」の場合は、質問 5 に進みます。
  3. Google Kubernetes Engine または GKE Enterprise でコンテナを実行していますか？
    1. 「はい」の場合は、GKE 用 Workload Identity 連携を使用して、サービス アカウントを Kubernetes Pod に接続します。
    2. そうでない場合は、リソースにサービス アカウントを接続します。

  4. ユースケースにサービス アカウントが必要ですか？

    たとえば、すべての環境でアプリケーションの認証と認可を一貫して構成したいとします。

    1. 「いいえ」の場合は、ユーザー認証情報で認証を行います。
    2. 「はい」の場合は、ユーザー認証情報を使用してサービス アカウントの権限を借用します。
  5. ワークロードは Workload Identity 連携をサポートする外部 ID プロバイダで認証されますか？
    1. 「はい」の場合は、Workload Identity 連携を構成して、オンプレミスや他のクラウド プロバイダで実行されているアプリケーションがサービス アカウントを使用できるようにします。
    2. 「いいえ」の場合は、サービス アカウント キーを作成します。

場合によっては、サービス アカウント キー以外の認証方法を使用できないことがあります。サービス アカウント キー以外は使用できない例としては、次のような場合があります。

  • 市販の製品（COTS）または Software as a Service（SaaS）アプリケーションを使用して、Google Cloud サービス アカウント キーをユーザー インターフェースに直接入力している。
  • ワークロードが Google Cloud の外部で実行されており、Workload Identity 連携をサポートできる ID プロバイダで認証されていない。

サービス アカウント キーを引き続き使用する必要がある場合は、サービス アカウント キーを管理するためのベスト プラクティスに従います。

また、サービス アカウント キーを継続して使用するリスクと別の認証方法に切り替えるコストを検討した結果、特定のワークロードを修正しないことにする場合もあります。

不要なキーを削除する

サービス アカウント キーが不要であることが確実な場合は、キーを削除する必要があります。不要なキーとしては、次のものがあります。

  • 最近使用されていないキー、または未使用のリソースに関連付けられているキー（このページの短期間で得られる成果を特定するを参照）。

  • 他の認証方法に移行したワークロードのキー。

    プロジェクト内のすべてのサービス アカウント キーを削除したら、そのプロジェクトに iam.disableServiceAccountKeyCreation 制約が適用されていることを確認します。プロジェクトがこの制約から除外されている場合は、除外を許可したタグを削除します。

キーを安全に削除するには、削除する前にキーを無効にすることをおすすめします。削除すると元に戻せませんが、無効にすると、予期しない問題が見つかった場合にキーをすばやく有効にすることができます。キーを無効にした後、キーを完全に削除しても問題がないことを確認してから、キーを削除します。キーを無効にした後に予期しない問題が見つかった場合は、キーを再度有効にして問題を解決します。キーを安全に削除できるようになるまで、このプロセスを繰り返します。

組み込みのコントロールを使用してキーの漏洩に対処する

Google Cloud には、漏洩したサービス アカウント キーの検出と対応に役立つツールとサービスがいくつか用意されています。漏洩したサービス アカウント キーに対応するために、次のメカニズムの使用を検討してください。

  • Security Command Center の異常検出を有効にして、公開リポジトリのキーをスキャンします。キーの漏洩が検出された場合、このスキャンにより account_has_leaked_credentials の検出結果が作成されます。
  • Security Command Center のクリプトマイニング保護プログラムを確認し、資格の技術的な前提条件を満たしていることを確認します。漏洩した認証情報は、暗号通貨マイニングの悪用によく使用されています。
  • セキュリティ チームが Google Cloud からセキュリティ通知（漏洩したキーの不正使用など）を受信できるように、重要な連絡先を構成します。メールアドレスがモニタリングされ、単一障害点として個々のユーザーに依存していないことを確認します。

インシデント管理の詳細については、共同インシデント管理プロセスを構築するをご覧ください。

サービス アカウント管理の継続的な改善

可能な限り、サービス アカウント キーを管理するためのベスト プラクティスを実装してください。キー管理プロセスを改善することで、組織に残っているサービス アカウント キーのリスクを軽減できます。

次のステップ