GCP サービス アカウントの利用状況の調査
Google Cloud Japan Team
※この投稿は米国時間 2021 年 12 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud のサービス アカウントは、ワークロードがエンドユーザーの関与なしにリソースにアクセスしたり、アクションを実行したりする必要がある場合に使われます。 サービス アカウントを使った認証の方法はいくつかあります。例えばサービス アカウントを Google Compute Engine の一部として使う方法、サービス アカウントになりすます方法、キーファイルと一緒に使う方法などがありますが、キーファイルと一緒に使う方法については、特に慎重になる必要があります。
共通の目的は、Google Cloud 上でキーなしのサービス アカウント アーキテクチャを実現することですが、これを組織全体で行うのは難しい場合があります。 サービス アカウント キーの生成を選択する理由は、デベロッパーの検証からサードパーティのソフトウェア統合の要件まで、さまざまです。
このブログ記事では、サービス アカウント キーを使わざるを得ない場合に、リスクを最小限にする方法を見ていきます。Google Cloud 内のサービス アカウントの使用状況を把握することで、サービス アカウント キーのローテーション時の意図しないアプリケーション障害のリスクを低減する方法を中心に説明します。では、さっそく始めましょう。
CIS ベンチマークからのガイダンス
Center for Information Security（CIS）ベンチマークは、推奨されるセキュリティ強化のガイドラインを提供しています。 Google Cloud Platform に関して、CIS は先日、CIS Google Cloud Platform 基礎ベンチマーク バージョン 1.2.0 を公開しました。この中で CIS は、基本的な GCP サービス全体のセキュリティ体制を改善するための一連のコントロール、概要、説明、影響、監査手順、および修復を提供しています。
例として、CIS Google Cloud Platform 基礎ベンチマーク バージョン 1.2.0 のセクション 1.7 を見てみましょう。ベンチマークにはこうあります。
サービス アカウントのユーザー管理 / 外部キーが 90 日以内のサイクルでローテーションされることを確認する（自動化）
このセクションには、説明、影響、CLI コマンドなどがあり、このベンチマークを満たすための内容、理由、および方法に関する貴重なインサイトを知ることができます。 CIS は、サービス アカウント キーのローテーションにより、不正使用される恐れのあるアカウントへのアクセスの機会を減らすことができるとしています。 解決策は、以下の方法でサービス アカウント キーをローテーションすることです。
90 日以上ローテーションしていないキーを監査し、特定する
対象となるキーを削除する
新しいキーを作成する（必要に応じて）
上記の 3 つのステップは一見簡単そうに見えます。ただし、微妙に異なるユースケースもあるので、注意が必要です。
サービス アカウント キーを削除すると、関連した秘密鍵への現在および将来のすべてのアクセスが事実上削除されます。 その結果、キーファイルに依存していたアプリケーション、パイプライン、サードパーティ統合ができなくなるなどの、不測の結果を招くおそれがあります。 これを防ぐにはどうすればよいでしょうか。
サービス アカウントのアクセス権と使用量の調査
1 つの方法としては、GCP サービス アカウントおよびサービス アカウント キーへの、アクセスおよび使用状況の調査を行うことです。 3 つの GCP サービスを導入してみましょう。Policy Analyzer、Policy Intelligence、そして Cloud Logging です。このツールを使うと、サービス アカウント キーを削除した場合の影響を特定できます。
調査にあたっては、以下の点を考慮する必要があります。
1. このサービス アカウントで何ができるか（Policy Analyzer）
GCP の IAM ロールを見れば、そのサービス アカウントができることがわかります。 ロールは組織のノードからフォルダ、プロジェクトへと、階層的に継承されていきます。 IAM ロールは、GCS バケット、KMS キーリング、サービス アカウントなど、GCP プロジェクト内の多くのリソースにも定義できます。
サービス アカウントが持つすべての IAM バインディングを決定するスクリプトを作成するのは、非常に面倒です。 疑似コードは以下のようになります。
もし、ご自身の組織がお持ちのリソースが少なくない場合、このような処理は非常に面倒であり、有意な処理も難しくなります。 では、どうしたらよいでしょう。 ここで、Policy Analyzer の出番です！Policy Analyzer は、監査関連タスクのアクセスを可視化し、組織全体でクエリを可能にします。次のスクリーンショットは、Policy Analyzer のクエリの主要コンポーネント、クエリのスコープ、プリンシパル（またはサービス アカウント）、および一連の詳細オプションを示しています。 クエリの結果は、組織全体でサービス アカウントに付与されたリソース全部におけるすべてのロールのセットです。
簡単に再利用できるように、以下のようなテンプレートのリンクをご用意しています。https://console.cloud.google.com/iam-admin/analyzer/query;identity=serviceAccount:[YOUR_SA]@[YOUR_PROJECT_ID].iam.gserviceaccount.com;expand=groups;scopeResource=[YOUR_ORG_ID];scopeResourceType=2/report?organizationId=[YOUR_ORG_ID]&supportedpurview=project
このクエリは、サービス アカウントのアクセス範囲を決定するうえで、大いに役立ちます。 サービス アカウントは、単一の GCP プロジェクトにおけるアクセス、組織レベルでのアクセス、または任意のリソースにまたがったアクセスを持つことができます。 Policy Analyzer を使えば、サービス アカウントがどこで使われたかを完全に把握できます。
2. このサービス アカウントが最後に使われたのはいつか（Policy Intelligence）
サービス アカウントが最後にいつ使用されたかを知ることは非常に重要です。 たとえば、あるサービス アカウントが 1 年以上使用されていないとすれば、削除しても問題はないでしょう。 Policy Intelligence のサービスを使えば、サービス アカウントのアクティビティをクエリできます。 以下のコマンドは、指定された GCP プロジェクトのサービス アカウントまたはサービス アカウント キーの最終認証のためのアクティビティをサポートします。たとえば次のようになります。
指定した観察期間中にサービス アカウントが認証されたことがわかれば、そのサービス アカウントが使用されているかどうかを把握できます。 サービス アカウントが最近使用されていた場合（いつまでを最近とするかの定義は、ご自身もしくはご所属の組織に委ねます）、サービス アカウント キーを削除するのはより慎重になった方がよいでしょう。
さらに、複数のサービス アカウント キーがある場合は、Policy Intelligence を使用してキーの最後の認証を識別することで、さらに詳細な情報を知ることもできます（非推奨です）。 一方、クエリされたサービス アカウントに最近のアクティビティが見られない場合、そのサービス アカウントを削除しても不測の結果を引き起こさないだろうという確信が持てるはずです。
Policy Intelligence はプロジェクト単位なので、サービス アカウントに複数のプロジェクトにまたがるロールがある場合、各プロジェクト内でこのクエリを実行する必要があります。 また、Policy Intelligence は指定した観察期間内における結果を返します。 観察期間には、直近のアクティビティ（数分前のアクティビティなど）は含まれないこともあるので、Cloud Logging を参照することもできます。
3. サービス アカウントの最近のアクティビティ（Cloud Logging）
サービス アカウントの最近のアクティビティを知るには、Cloud Logging を活用すると便利です。 特定の期間に行われたアクティビティのリストをクエリすることができます。以下のクエリを行います。
さらに一歩進んで、以下のロギングクエリも実行できます。
この Cloud Logging をベースにした調査を行う場合、いくつか注意点があります。 第一に、GCP のすべてのログタイプ（たとえば、データアクセス ログや VPC フローログなど）がデフォルトで有効になっているわけではありません。こういったレベルのログタイプの粒度を知りたい場合、ログが対応したリソースで有効になっているか確認する必要があります。 第二に、複数のプロジェクトにまたがってクエリを実行するのは大変です。そこで、キー ローテーションを中心にリスクベースで判断をするか、またはログのシンクを使ってログを一元的にエクスポートし、BigQuery や類似のツールなどで総合的に分析するのがよいかもしれません。
結論
サービス アカウント キーを使用することのリスクおよび移行についての戦略は、よくおわかりになられたことと思います。何よりも、できる限りサービス アカウント キーの作成は避けてください。 Workload Identity、仮想マシン サービス アカウント、サービス アカウントの権限借用などの GCP が管理するオプションを使用すれば、サービス アカウント キーを作成しなければならない場面を回避することができます。
次に、ユーザーが管理するサービス アカウント キーがある場合は、キーのローテーションを必ず行ってください。 90 日間が妥当な基準の期間ですが、最終的にはキーのローテーションはそれより頻繁に行うのが理想です。
最後に、使用目的が不明なサービス アカウント キーを持つプロジェクトがある場合（たとえば、多数のユーザーで共有される単一のプロジェクトに多いです）、ログクエリ、Policy Analyzer、Policy Intelligence の 3 つの推奨される GCP ツールを活用して、キー削除時に不測のアプリケーション障害が発生する可能性をできる限り低減してください。
こうした推奨事項は、サービス アカウントの使用状況を完全に実証するわけではありませんが、サービス アカウント キーを安全にローテーションしてリスクを軽減できるのだという自信と信頼を与えてくれるでしょう。
- 戦略的クラウド エンジニア Garrett Wong
