Secret Manager のベスト プラクティス

このガイドでは、Secret Manager を使用する際のベスト プラクティスについて説明します。このガイドは、すべての推奨事項を説明するものではありません。このガイドを読む前に、プラットフォームの概要を確認して、Google Cloud の全体像と Secret Manager のコンセプトの概要を理解することをおすすめします。

アクセス制御

Secret Manager API へのアクセスは IAM で保護されます。シークレット権限を付与する際は、最小権限の原則に沿う必要があります。

Secret Manager API への認証には認証情報が必要です。クライアント ライブラリは、すべて同様の方法で「アプリケーションのデフォルト認証情報」と呼ばれる認証情報を検索します。

  • ローカルで開発する場合は、gcloud auth application-default login を使用します。これにより、クライアント ライブラリによって自動的に取得される認証情報を持つファイルが作成されます。
  • Compute Engine や Cloud Functions など、他の Google Cloud コンピューティング プラットフォームでは、クライアント ライブラリはインスタンス メタデータ サーバーを介して認証情報を取得します。
  • GKE では、Workload Identity はメタデータ サービスを介して認証情報も提供します。
  • Amazon Web Services や Microsoft Azure など、他のプラットフォームでは、既存の ID メカニズムを使用して Google Cloud APIs に対する認証を行う Workload Identity 連携を設定することを検討してください。

Secret Manager API の外部に追加のシークレットを安全に保存し、アクセスする必要がないため、これらの方法はすべて、サービス アカウントの認証情報をエクスポートする方法よりも好ましい方法です。

コーディング手法

ファイル システムまたは環境変数を介してアプリケーションにシークレットを渡すのが一般的ですが、可能な限り避けてください。

  • ファイル システムでシークレットにアクセスできると、攻撃者がシークレット マテリアルを読み取ることができるため、ディレクトリ トラバーサル攻撃などのアプリケーションの脆弱性が深刻化する可能性があります。
  • 環境変数を介してシークレットが使用されると、デバッグ エンドポイントの有効化やプロセス環境の詳細をログに記録する依存関係などの構成ミスにより、シークレットが漏洩する可能性があります。
  • シークレット マテリアルを別のデータストア(Kubernetes Secret など)に同期する場合は、そのデータストアのアクセス制御を検討してください。次に例を示します。
    • データストアによりシークレットへのアクセスは拡張されていますか?
    • シークレットへのアクセスを監査できますか?
    • データストアは、保存データの暗号化とリージョン指定の要件に準拠していますか?

こうした理由から、可能であれば、Secret Manager API を直接使用することをおすすめします(提供されているクライアント ライブラリのいずれかを使用するか、REST または GRPC のドキュメントに沿ってください)。

管理

ワークロードに特定のロケーション要件(constraints/gcp.resourceLocations 制約を使用して適用可能)がない限り、シークレットを作成する際に、自動レプリケーション ポリシーを選択します。

シークレットを最新のエイリアスを使用するのではなくバージョン番号で参照します。既存のリリース プロセスを使用して、バージョン番号に更新をデプロイします。これは通常、起動時に読み込まれる特定のシークレット バージョンを使用してアプリケーションを構成することを意味します。最新のエイリアスを使用することは便利ですが、シークレットの新しいバージョンに問題がある場合は、ワークロードでシークレット バージョンを使用できないままになる可能性があります。バージョン番号に固定すると、既存のリリース プロセスを使用して構成の検証とロールバックを行うことができます。

シークレット バージョンを破棄する前、またはシークレットを削除する前に、シークレット バージョンを無効にします。これによって、シークレットを破棄したように見えますが、元に戻せる状態にすることで、停止を防ぐことができます。つまり、データを完全に削除する前に、依存関係が残らないようにするために、無効にして 1 週間待機します。

不可逆で削除する必要がある場合を除き、本番環境のシークレットには有効期限を設定しないでください。有効期限機能は、一時的な環境の自動クリーンアップに最適です。シークレットを期限切れにする代わりに、時間ベースの IAM Conditions を検討してください。

以下の目的のために、定期的にシークレットをローテーションします。

  • シークレットの漏洩が発生した場合の影響を制限する。
  • シークレットへのアクセスが不要になった個人に対して、以前にアクセスしたシークレットの使用を継続できないようにする。
  • ローテーション フローを継続的に実施して、停止の可能性を減らす。

以下の目的のために、Cloud Asset Inventory を使用して組織全体のシークレットをモニタリングします。

  • 組織全体のシークレットの識別に役立てる。
  • ローテーション、暗号化構成、ロケーションなどの組織要件に対する不遵守を特定する。

データアクセス ログを有効にして、AccessSecretVersion リクエスト情報を取得し、分析します。フォルダレベルまたは組織レベルでこれを有効にすると、シークレットまたはプロジェクトごとにロギングを構成しなくてもロギングを適用できます。

IAM による制御に加えて、ネットワーク ベースの制御で Secret Manager API へのアクセスを制限するには、組織に VPC Service Controls の境界を設定します。

constraints/iam.allowedPolicyMemberDomains 組織のポリシーを使用すると、シークレットの IAM ポリシーに追加できる ID を制限できます。

ピーク時のシークレット使用量(アプリケーションの同時デプロイやサービスの自動スケーリングによる「thundering herd」を考慮)を推定し、そのようなイベントに対処できるように、プロジェクトに十分な割り当てを行ってください。さらに割り当てが必要な場合は、割り当ての引き上げをリクエストします。