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

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

アクセス制御

Secret Manager API へのアクセスは IAM によって保護されます。シークレットに権限を付与する際は、最小権限の原則に従います。

Secret Manager API への認証には認証情報が必要です。クライアント ライブラリはすべて似たような手段を使用して「アプリケーションのデフォルト認証情報」と呼ばれる認証情報を検索します。

  • ローカルで開発する場合は、 gcloud auth application-default login を使用します。これにより、クライアント ライブラリによって自動的に取得される認証情報を含むファイルが作成されます。

  • Compute Engine や Cloud Run 関数など、他の 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 のドキュメントに従うことをおすすめします。

管理

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

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

本番環境のシークレットは、完全に削除する必要があることが確実でない限り、本番環境のシークレットに有効期限を設定しないでください。有効期限機能は、一時的な環境の自動クリーンアップに最適です。シークレットの有効期限切れの代替として、時間ベースの IAM 条件を検討してください。

シークレットを定期的にローテーションして、次の処理を行います。

  • シークレットの漏洩が発生した場合の影響を制限する。

  • シークレットへのアクセスが不要になった個人が、以前にアクセスしたシークレットを継続して使用できないようにします。

  • サービスの停止の可能性を低減します。

次の理由から、Cloud Asset Inventory を使用して組織全体のシークレットをモニタリングします。

  • 組織全体のシークレットの識別に役立てる。

  • ローテーション、暗号化構成、ロケーションなどの組織要件に対する不遵守を特定する。

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

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

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

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

データ所在地のコンプライアンス

データの所在地と主権に関する厳格な要件がある場合は、リージョン シークレットを選択します。リージョン シークレットを使用すると、特定の地理的位置内に機密データを保存できます。保存時、使用中、転送中の完全な保証が提供されるため、データ所在地に関する法的、規制上の、または組織の要件を遵守できます。