通常のユーザーとは異なり、サービス アカウントにはパスワードがありません。その代わりに、サービス アカウントは ECDSA 鍵ペアを使用して認証を行います。RSA 鍵ペアの秘密鍵を使用するとサービス アカウントとして認証できるため、秘密鍵にアクセスできることはユーザーのパスワードを知っていることと似ています。この秘密鍵はサービス アカウント キーと呼ばれています。サービス アカウント キーの管理は慎重に行ってください。扱いを誤ると、セキュリティ上のリスクが生じる可能性があります。
サービス アカウント キーに関連する主な脅威は次のとおりです。
認証情報の漏えい: サービス アカウント キーが、本来保管すべきではない場所に誤って保存される可能性があります。漏えいしたサービス アカウント キーが悪用され、ユーザーの環境にアクセスされる可能性があります。
権限昇格: サービス アカウント キーの保護が十分でないと、このような鍵が権限の昇格に利用される可能性があります。
情報開示: サービス アカウント キーにより、機密データが誤って公開される可能性があります。
否認防止: サービス アカウント キーを使用して認証を行い、サービス アカウントでオペレーションを実行すると、攻撃者が身元を隠して操作を実行する可能性があります。
このページでは、サービス アカウント キーを管理、使用、保護するためのベスト プラクティスについて説明します。
認証情報の漏えいを防ぐ
サービス アカウント キーは、ユーザー名やパスワードと同様に認証情報の一つです。有効なサービス アカウント キーにアクセスできるユーザーは、この鍵を使用して認証を行い、サービス アカウントにアクセス権のあるリソースを使用できます。
攻撃者にとっては、漏えいしたパスワードよりもサービス アカウント キーのほうが価値が高い可能性があります。たとえば、漏えいしたパスワードでログインを試みても、ユーザー アカウントに 2 段階認証プロセスとログイン時の本人確認が構成されていれば、ログインに成功する可能性は低くなります。対照的に、サービス アカウントは追加のログイン検証の対象ではないため、漏えいしたサービス アカウント キーを使用した認証は成功する可能性が高くなります。
攻撃者は、次のような方法でサービス アカウント キーを探す可能性があります。
- オープンソース プロジェクトのソースコード リポジトリ。
- 侵害されたサービスについて、一般に公開されているデータダンプ。
攻撃者が情報を探すのは公開されている場所だけではありません。非公開の場所に侵入し、サービス アカウント キーを探す可能性もあります。次に例を示します。
- メール ボックス
- ファイル共有
- バックアップ ストレージ
- 一時ファイル システムのディレクトリ
サービス アカウント キーの漏えいリスクを低減する効果的な方法は、使用されている鍵の数を減らし、新しい鍵が作成されないようにすることです。以降のセクションでは、サービス アカウント キーの数を制限する方法と、サービス アカウントの漏えいリスクを軽減する別の方法について説明します。
サービス アカウント キーを一時的な場所に残さない
サービス アカウント キーを作成したら、すぐにキーを保管場所に移動します。ダウンロード フォルダに鍵のコピーを残してはなりません。また、ごみ箱に誤って移動しないように注意する必要があります。
ユーザー間でサービス アカウント キーの受け渡しを行わない
ユーザーにサービス アカウント キーの作成権限があるとは限りません。サービス アカウント キーを必要とするアプリケーションをデプロイした場合、このようなユーザーが別のユーザーにサービス アカウント キーの作成をリクエストする可能性があります。
サービス アカウント キーをソースコード リポジトリに送信しない
サービス アカウント キーは認証情報であり、不正アクセスから保護しなければなりません。サービス アカウント キーをソースコード リポジトリに送信すると、未承認のユーザーや不正なユーザーが鍵にアクセスするリスクが高くなります。
攻撃者が公開のソース リポジトリにあるソースコードをスキャンし、鍵を盗み出す可能性があります。
現在は非公開のソース リポジトリを使用していても、鍵の漏えいをチェックせずに公開リポジトリに切り替えることがないとは言えません。
別のチームのメンバーが自分のワークステーションにソースコードのコピーを保存している可能性もあります。
サービス アカウント キーを使用するコードを扱う場合は、サービス アカウント キーをソースコードとは別に格納し、鍵がソース リポジトリに誤って送信されるリスクを軽減する必要があります。多くの場合、開発中はサービス アカウント キーを使用せず、サービス アカウント キーの代わりに個人の認証情報を使用することで、このリスクをさらに低減できます。
プログラム バイナリにサービス アカウント キーを埋め込まない
サービス アカウント キーは特定のパターンに一致する文字列です。このため、他のファイルやバイナリに埋め込まれている場合でも識別は可能です。攻撃者にとって、バイナリにアクセスできれば、そこに埋め込まれているサービス アカウント キーの抽出はさほど難しい作業ではありません。
サーバーサイド アプリケーションのプログラム バイナリがアーティファクト リポジトリにホストされている可能性があります。また、デバッグ目的でデベロッパーのワークステーションにコピーされることもあります。サービス アカウント キーをプログラム バイナリから分離すれば、バイナリにアクセス可能なユーザーがサービス アカウントの認証情報に暗黙的にアクセスするのを防ぐことができます。
- ツール、デスクトップ プログラム、モバイルアプリなどのクライアント サイド アプリケーションの場合は、サービス アカウントを使用しないでください。
- サーバーサイド アプリケーションの場合は、サービス アカウント キーをバイナリに埋め込まないでください。鍵をアプリケーション バイナリから分離して保持します。
鍵の漏えいによるセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションする
サービス アカウント キーが誤って漏えいする可能性を減らすことはできますが、そのリスクを完全に排除することはできません。
鍵のローテーションは、既存の鍵を新しい鍵に置き換えてから、置き換えた鍵を無効にするプロセスです。サービス アカウント キーを含む、管理するすべての鍵を定期的にローテーションすることをおすすめします。
サービス アカウント キーをローテーションすると、鍵の漏洩や盗難のリスクを低減できます。鍵が漏えいした場合、数日から数週間で不正な行為者が鍵を特定してしまう可能性があります。サービス アカウント キーを定期的にローテーションすれば、漏えいした鍵が不正な行為者の手に渡るまでに無効化されている可能性が高くなります。
有効期限を設定して鍵を自動的に期限切れにする
デフォルトでは、作成したサービス アカウント キーの有効期限は 1 年間です。削除するまで有効です。独自の有効期限を設定することもできます。サービス アカウント キーに有効期限を設定すると、永続的な認証情報の存続期間を短くし、セキュリティ リスクを抑えることができます。ただし、有効期限の設定にもリスクがあります。たとえば、有効期限を設定すると、鍵の有効期限が切れたときにワークロードが失敗する可能性があります。
サービス アカウント キーを必要とするシステムに一時的にアクセスする必要がある場合は、有効期限を使用します。たとえば、次のような場合に有効期限を使用します。
- サービス アカウント キーでのみ認証できるアプリケーションのコードを非本番環境で開発する。
- サービス アカウント キーでのみ認証できるサードパーティ製ツールを使用する。
以下のシナリオでは、有効期限を使用しないようにします。
- 本番環境ワークロード。本番環境では、サービス アカウント キーが期限切れになると、誤ってサービスが停止する可能性があります。代わりに有効期限のない鍵を使用し、鍵のローテーションでライフサイクルを管理します。
- 継続的インテグレーション（CI）パイプラインなど、永続的にアクセスする必要がある非本番環境ワークロード。
- 指定した時間の経過後に鍵が使用されないようにする鍵のローテーション システム。
サービス アカウント キーの有効期限を設定するには、プロジェクト、フォルダ、組織で新しく作成された鍵に有効期限を構成します。有効期限は、既存の鍵には適用されません。
サービス アカウント キーのローテーション プロセスを確立しておくと、サービス アカウント キーが不正使用された疑いがある場合にも迅速に対応できます。
アプリケーションを実行するマシンごとに専用の鍵を使用する
不審なアクティビティの潜在的な発生源を絞り込むため、アプリケーションのコピーごとに鍵を作成してください。こうすることで、多くのサービスが監査ログレコードに serviceAccountKeyName フィールドを追加し、これによりアクティビティが発生したマシンを識別できます。