Google Cloud でアプリケーションを安全に認証するためのベスト プラクティス

Google Cloud のドキュメントは、ジョブのさまざまな部分において有用です。新しいサービスについて情報を収集することや、動作中の機能を確認することが必要な場合があります。本番環境で使用するアプリケーションを開発する必要があることから、ドキュメントにアクセスする場合も考えられます。

多くの場合、Google のドキュメントはサービスまたは機能の開発と運用を支援することを目的として作成されています。本番環境や開発環境では、組織で検討すべきセキュリティに関するくつかのベスト プラクティスが存在することが考えられます。ドキュメントに示された方法とは異なる方法でアプリケーションを認証することが必要な場合があります。

アプリケーションに適した認証方法を選択するには、次のディシジョン ツリーを使用します。この記事の残りの部分では、アプリケーションを認証するための安全な方法について説明します。

アプリケーションの認証方法の選択を支援するためのディシジョン ツリーの図。それぞれの方法について、この記事の各セクションで詳しく説明します。

アプリケーションのデフォルト認証情報の概要

ほとんどの場合、コードから API リクエストを行います。アプリケーションのデフォルト認証情報(ADC)を使用すると、必要な認証情報を自動的に検出し、アプリケーションの認証を行うことができます。ADC は、すべての Google Cloud クライアント ライブラリでサポートされています。

ADC では、1 つの認証方法を使用してローカルで開発し、テスト環境または本番環境にデプロイする際に別の方法で認証できます。異なるデプロイ環境とサポートされている認証方法間を移動する際に、コードを変更する必要はありません。

クライアント ライブラリにより、使用可能な認証方法が決まります。ADC では、ローカルで開発を行っているか、本番環境で実行しているかに関係なく、アプリケーションに適した API リクエストが選択されます。可能な限り、アプリケーションには ADC を使用してください。

詳細については、アプリケーションのデフォルト認証情報(ADC)の概要ADC が認証情報を自動的に検出する仕組みをご覧ください。

ローカル開発と gcloud コマンドライン ツールを使用したテスト

このシナリオでは、gcloud コマンドライン ツールで、Cloud APIs を使用してプロジェクトの構成を変更するか、API との新しい統合をテストするコードを作成します。このようなインタラクティブな使用方法は主に、ローカルマシンでの開発とテストを目的としています。gcloud コマンドライン ツールのログイン時に使用する独自の認証情報を入力します。この方法では、API リクエストを行った ID を追跡し、セキュリティ上の理由による監査証跡を提供できます。

gcloud コマンドライン ツールを使用してインタラクティブに認証を行い、独自のコマンドを発行し構成を変更するには、gcloud auth login コマンドを使用して --billing-project フラグを使用し、ユーザー所有の請求先プロジェクトを指定します。Cloud Translation API や Cloud Vision API など、ユーザー所有の請求先プロジェクトが設定されていない場合、一部の Cloud APIs の呼び出しに失敗します。

コードがローカル開発環境から Cloud API を呼び出すように設定するには、Google クライアント ライブラリと ADC を使用します。これを行うには、gcloud auth application-default login コマンドを使用し、--billing-project フラグを使用して、ユーザーが所有している請求先プロジェクトを指定します。ここでも、Cloud Translation API や Cloud Vision API など、一部の Cloud APIs の呼び出しは、ユーザー所有の請求先プロジェクトが設定されていない場合に失敗します。

アプリケーションで Cloud API リクエストを行うために必要な権限を付与するロールをアカウントに割り当てないでください。Identity and Access Management(IAM)Recommender で、過去 90 日間で必要とされなかった権限を確認し、削除できます。

Google Cloud 環境内

このシナリオでは、アプリケーション コードは Google Cloud で実行され、Compute Engine VM、Cloud Run、App Engine、Google Kubernetes Engine(GKE)、Cloud Functions などのサーバーレス プロダクトまたはコンピューティング プロダクト ファミリーを使用します。アプリケーションは Google Cloud 環境で実行されるため、デフォルトの認証情報を使用します。

デフォルトの認証情報を使用して、アプリケーションはコードを実行する仮想インスタンスに関連付けられている ID トークンを取得します。ID トークンは、仮想インスタンスで実行されるメタデータ サーバーから取得されます。その後、このトークンを使用して認証を行い、ADC を使用して Cloud API リクエストを送信できます。

デフォルトの認証情報は ADC の一部であるため、使用するために別の操作を行う必要はありません。コードを変更する、またはサービス アカウントとキーのローテーションを作成して管理する必要はありません。

オンプレミスのデータセンターまたは他のクラウド プロバイダ

このシナリオでは、アプリケーション コードは独自のデータセンター インフラストラクチャか、AWS や Azure などの他のクラウド プロバイダで実行されます。OpenID Connect(OIDC)がサポートされている場合は、外部ワークロードの ID 連携を使用し、各環境に対応する Workload Identity プールを作成して、アプリケーションの認証に使用します。

ID 連携を使用すると、Identity and Access Management(IAM)を使用し、外部 ID に対して、サービス アカウントの権限借用機能を含む IAM ロールを付与できます。このアプローチでは、有効期間が短いアクセス トークンを使用してリソースに直接アクセスできます。

ID プロバイダの例:

  • AWS
  • Azure Active Directory
  • オンプレミスの Active Directory
  • Okta
  • Kubernetes クラスタ

詳細については、外部ワークロードの ID 連携を使用する方法と Workload Identity プールの作成をご覧ください。

OIDC のサポートがない場合や、ID 連携を使用しない場合は、ユーザー管理のサービス アカウントを作成できます。これらのサービス アカウントについては、次のセクションで説明します。これらの認証情報は、プロバイダが提供する AWS Secret Manager や Azure Key Vault などのデジタル Vault に安全に保存してください。これらの認証情報は、暗号化された形式以外のディスクには書き込まないでください。

ユーザー管理サービス アカウント

このシナリオでは、コードは Google Cloud 内、または OpenID Connect と ID 連携をサポートする環境内で実行されません。その環境が信頼できると見なされ、使用を妨げる組織のポリシー サービスの制約はありません。サービス アカウントを使用して、アプリケーションの認証を行うことができます。ADC はサービス アカウントと連携するため、異なるデプロイ環境では、アプリケーションで別の認証方法を自動的に使用できます。

サービス アカウントは、個人ではなく、アプリケーションが使用する特別なタイプのアカウントです。各サービス アカウントは、認証に使用される公開 / 秘密 RSA 鍵ペアに関連付けられています。環境の不正使用や、サービス アカウント キーの漏洩によるリスクがほぼないことを確認してください。エクスポートする鍵を保護し、潜在的なセキュリティ リスクを最小限に抑えるには、サービス アカウント キーのベスト プラクティスをご覧ください。

トークンを取得する際に、サービス アカウントで自己署名 JWT(JSON ウェブトークン)または OIDC トークンを使用して、必要以上のラウンド トリップを回避できます。詳細については、JWT を使用して Cloud Endpoints API に対して認証済みリクエストを行う方法をご覧ください。

サービス アカウントはユーザーの代わりにアクションを実行しますが、過剰な権限を割り当てられている可能性があり、また、不要になった場合に削除されないケースも頻繁に見られます。Identity and Access Management Recommender で、過去 90 日間に必要とされなかった権限を確認し、削除する必要がある未使用のサービス アカウントを特定できます。

半信頼環境または制限付き環境

このシナリオでは、アプリケーション コードは半信頼環境で実行されているか、実行できる操作を制限するポリシーの制約が適用されています。これらの環境でサービス アカウントを使用して認証を行い、Cloud APIs リクエストを送信しないでください。

組織のポリシー サービスを使用してプロジェクトに制約を適用することで、他のプロジェクト(特に本番環境のデプロイにおけるプロジェクト)内で実行されるリソースとの通信を制限できます。

環境はそれぞれ異なり、さまざまなセキュリティ要件が適用される可能性があるため、ご自身に影響する可能性があるサービス固有のガイダンスを確認してください。オペレーション チームやセキュリティ チームと協力して、ニーズに合ったソリューションを設計します。

簡単に言うと、有効期間が短いアクセス トークンを安全に取得できるシステムを設計する必要があります。設計について、次のことに注意してください。

  • トークンの有効期間は、アプリを実行するのに十分な長さに設定するか、更新可能なものにする必要があります。
  • トークンの範囲を必要なロールに限定します。
  • トークンをディスクに書き込まないでください。

サンプル ソリューションの中には、オンプレミスのデジタル鍵管理(HashiCorp Vault など)にアクセスするものや、Cloud Run に限定的にアクセスし、Secret Manager から認証情報を自動的に取得するもの、あるいは Cloud Key Management Service から暗号化認証情報を取得するものが存在します。

また、Google Cloud コンサルティングを利用して、安全なソリューションを設計およびビルドするためのサポートを利用することもできます。

セキュリティ上の考慮事項

アプリケーションの認証プロセスで JWT または OIDC トークンを使用する場合は、有効期限が切れるまでトークンは有効です。漏洩のリスクを軽減するため、トークンの存続期間をジョブの予想実行時間よりも若干長くなるように構成します。たとえば、トークンがジョブの実行中に 15 分間必要になる場合は、トークンの有効期間を 20 分に構成します。

これらのトークンは、親サービス アカウントの削除以外で取り消すことはできません。ここでも、トークンの存続期間の割り当てポリシーを考慮して、侵害される可能性のあるトークンを使用可能な期間を短く設定します。

サービス アカウント キーが盗まれ、次の鍵のローテーションまで、または永久にトレースできない方法で認証情報が生成される可能性があります。エクスポートする鍵を保護し、潜在的なセキュリティ リスクを最小限に抑えるには、鍵のローテーションや監査など、サービス アカウント キーのベスト プラクティスをご確認ください。

必要に応じてサービス アカウント キーを削除して、今後使用できないようにすることも可能です。

次のステップ

アプリケーションでの認証情報の使用については、認証情報を管理するためのベスト プラクティスをご覧ください。