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

サービスアカウントキーは、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 制約を適用できます。

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

組織レベルでタグ管理者ロール（roles/resourcemanager.tagAdmin）と組織ポリシー管理者ロール（roles/orgpolicy.policyAdmin）があることを確認します。組織レベルでロールを付与する方法については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
組織レベルで、リソースを組織のポリシーから除外するかどうかを定義するために、タグキーとタグ値を作成します。キー disableServiceAccountKeyCreation と値 enforced、not_enforced を使用してタグを作成することをおすすめします。

タグキーとタグ値の作成方法については、新しいタグの作成と定義をご覧ください。
disableServiceAccountKeyCreation タグを組織に適用し、その値を enforced に設定します。組織内のすべてのリソースは、別のタグ値で上書きされない限り、このタグ値を継承します。

リソースにタグを適用する方法については、リソースへのタグの適用をご覧ください。
組織のポリシーから除外するプロジェクトまたはフォルダごとに disableServiceAccountKeyCreation タグを付けて、その値を not_enforced に設定します。この方法でプロジェクトまたはフォルダにタグ値を設定すると、組織から継承されたタグ値がオーバーライドされます。
除外リソースを除くすべてのリソースのサービスアカウントキーを作成できないようにする組織のポリシーを作成します。このポリシーには、次のルールが必要です。
- disableServiceAccountKeyCreation: not_enforced タグの付いたリソースに適用されないように iam.disableServiceAccountKeyCreation 制約を構成します。このルールの条件は次のようになります。
```
"resource.matchTag('ORGANIZATION_ID/disableServiceAccountKeyCreation', 'not_enforced')"
```
- 他のすべてのリソースに適用されるように iam.disableServiceAccountKeyCreation 制約を構成します。

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

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

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

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

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

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

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

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

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

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

不要なキーを削除する

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

最近使用されていないキー、または未使用のリソースに関連付けられているキー（このページの短期間で得られる成果を特定するを参照）。
他の認証方法に移行したワークロードのキー。

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

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

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

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

サービスアカウントキーの漏洩対応の制約により、 Google Cloud が検出する公開鍵を自動的に無効にできます。

不正使用された認証情報を管理するための他のベストプラクティスについては、不正使用された Google Cloud認証情報への対応をご覧ください。

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

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