Cloud KMS によるシークレット管理

アプリケーションではしばしば、ビルド時や実行時に小さい機密データへのアクセスを必要とします。このようなデータは一般に、シークレットと呼ばれます。シークレットは、概念としては構成ファイルと似ていますが、ユーザーデータなどの追加データへのアクセス権を付与できるため、一般により機密性が高くなります。

このトピックでは、シークレット管理の主なコンセプトの一部について説明します。また、Cloud Key Management Service を使用してシークレットを管理するためのガイダンスも示します。

シークレット管理の概要

シークレットの管理には、いくつかのオプションがあります。シークレットを格納するための一般的な方法には、以下を使用する方法があります。

  • コードまたはバイナリ
  • Deployment Manager
  • コンテナ内のシークレット ボリューム
  • VM のメタデータ
  • ストレージ システム

これらのオプションから選択する際に通常、セキュリティと機能性のバランスをとる必要があります。一般的なセキュリティ上の懸念事項には、次のようなものがあります。

  • 承認: 厳密な承認スコープを含む、シークレットやシークレットの格納場所に対するアクセス管理。
  • 使用状況の検証: 細かい粒度(シークレット単位など)で、シークレットへのアクセスと使用状況を監査する機能。
  • 保存時の暗号化: データの盗難や紛失に備えたシークレットの暗号化。
  • ローテーション: 定期的に、またはインシデントに対応するために必要に応じて、シークレットをローテーションまたは更新する機能。
  • 分離: シークレットを管理する場所と使用する場所の分離。分離は、シークレットを管理できるユーザーとシークレットを使用できるユーザーの間での職掌分散にも適用されます。

一般的な機能上の懸念事項には、次のようなものがあります。

  • 一貫性: 複数のロケーションや複数のアプリケーションに渡るシークレットの同期。
  • バージョン管理: シークレットのローテーションをサポートするための、鍵の更新時期と更新方法の理解。

シークレット管理ソリューションの選択

最適なシークレット管理ソリューションの選択は、ご使用の環境、シークレット、セキュリティのニーズによって異なります。一般的な方法には、次のようなものがあります。

  1. Cloud KMS の鍵を使用して暗号化したシークレットをコードに格納する。このソリューションは通常、アプリケーション レイヤでシークレットを暗号化することによって実装されます。このソリューションを使用して、シークレットへのアクセスのスコープを限定することで、内部の脅威に対する保護を強化できます。シークレットへのアクセスを制限する場合、コードへのアクセス権を持つすべてのデベロッパーにアクセスを許可することも、コードと対応する鍵の両方へのアクセス権を持つデベロッパーのみにアクセスを制限することもできます。すべての開発者がコードと鍵の両方にアクセスできる場合でも、このオプションを実装することで、シークレットへのアクセスの監査が可能になるという利点があります。コード リポジトリでは、このような監査を常に行えるとは限りません。

  2. 保存時に暗号化したシークレットを Cloud Storage のストレージ バケットに格納する。このソリューションには、前述のソリューションと似た利点があります。つまり、少数の開発者にシークレットへのアクセスを限定して、そのアクセスを監査できるようにします。さらに、シークレットを別の場所に格納することで、セキュリティ侵害が検出された場合など、必要な場合にシークレットをより簡単にローテーションできます。また、このソリューションではシステムの分離も可能になります。シークレットを使用しているコード リポジトリが侵害された場合でも、シークレットそのものは保護できます。

  3. サードパーティのシークレット管理ソリューションを使用する。専用のシークレット管理ツールが、このリストで挙げた最初の 2 つのオプションを基に作成されています。さらに、これらのツールを使用すると、シークレットのローテーションが容易になるだけでなく、場合によっては、ユーザーの代わりにローテーションを実行できます。また、定期ローテーションを簡単にすることもできます。

シークレットの変更

シークレット管理ソリューションを検討する際に考慮するもう 1 つの重要な点は、シークレットの変更の容易さです。たとえば、シークレットをハードコーディングするのは、多くの場合魅力的なソリューションですが、このシークレットを後から変更するのは時間がかかる、困難な作業となります。

シークレット管理のためのソリューションを探す際には、以下の設計要件とそれらがご使用のアプリケーションにどの程度該当するかを検討してください。

  • シークレットのローテーション。特にセキュリティ上の理由で、シークレットは定期的にローテーションすることをおすすめします。シークレットごとに複数のバージョンを格納し、コードで一度に 1 つずつそれらを使用するようにするのが理想的です。多数のバージョンのシークレットを格納し、必要に応じて新しいシークレットにローテーションすることで、そのシークレットを必要とする可能性がある外部システムとの一貫性をより確実に保持できます。また、こうすることで必要に応じて以前のシークレットにロールバックすることもできます。このソリューションは実装が非常に複雑ですが、このようなニーズを事前に検討しておくことで、後日のシークレット管理が容易になります。
  • シークレットをローカルでキャッシュに保存する。アプリケーションに関するシークレットの格納場所によっては、シークレットをローカルでキャッシュに保存する必要がある場合があります。このようなシークレットは、1 時間に数回など、頻繁に更新できます。 このソリューションの利点は、更新頻度が高まるほど、停止に対してより迅速に対応できるようになることです。一方短所は、シークレットが誤って構成された場合、頻繁な更新によってそのエラーが組織内により速く拡散されることです。
  • 別のソリューションまたはプラットフォームを使用する。シークレット管理では、プラットフォームに依存しないシークレット管理ソリューションを利用することで、ロックインを避けることもできます。こうすることで、より柔軟なソリューションが利用可能になった場合の選択肢を確保できます。

Google Cloud Platform を使用したシークレット管理

GCP には、必要なシークレット管理ソリューションの実装方法に対応するのに役立ついくつかの方法が備わっています。このセクションでは、シークレットの格納に Cloud Storage を、暗号鍵に Cloud KMS を、アクセス制御に Cloud Identity and Access Management を、監査に Cloud Audit Logging を使用する方法について説明します。

ここでは、GCP でのシークレット管理を使用して実装する方法の 1 つを示しています。詳細については、Cloud KMS により暗号化されたシークレットの格納方法をご覧ください。

  • プロジェクトを 2 つ作成します。最初のプロジェクトでは、Cloud Storage を使用してシークレットを格納します。2 つ目のプロジェクトでは、Cloud KMS を使用して暗号鍵を管理します。
  • シークレットへのアクセスが必要なすべてのユーザーに storage.objectAdmincloudkms.cryptoKeyEncrypterDecrypter の役割を割り当てます。または、ユーザーの代わりに Cloud Storage にアクセスするサービス アカウントを使用することもできます。シークレットへのアクセスが不要なユーザーには、管理権限のみを付与し、アクセス権限は付与しないようにしてください。
  • Cloud Storage で、各シークレットを暗号化されたオブジェクトとして格納し、必要に応じてバケットにシークレットをグループ化します。一般に、使用方法、アクセス、保護のニーズが同じシークレットをグループ化できます。
  • Cloud KMS のアプリケーション レイヤで、一意の鍵を使用して各バケットを保護します。または、Google のデフォルトの暗号化を利用することもできます。
  • 可能な限り定期的にシークレットをローテーションします。
  • Cloud Audit Logging を使用してアクティビティをモニタリングします。鍵のローテーションや Cloud IAM 権限の変更といった管理アクティビティ ログはデフォルトで記録されます。検討すべきもう 1 つのオプションは、Cloud Storage オブジェクトに対するデータアクセス ログの記録を有効にすることです。これらのデータアクセス ログは、特に重要なシークレットをモニタリングする際に役立ちます。

このソリューションは、シークレット管理ソリューションの選択で説明したシークレット管理要件のほとんどに対応しています。 対応していないのはバージョン管理のみです。これは、バージョン管理への対応はアプリケーションによって異なるためです。

このようなソリューションを実装する場合は、ニーズに最適な暗号化オプションとシークレットへのユーザー アクセスの管理方法も検討してください。

暗号化オプション

GCP には、シークレットを暗号化するための次の 2 つのオプションがあります。

  • Cloud KMS の鍵を使用したアプリケーション レイヤ暗号化を使用する。このオプションでは、Cloud KMS に格納されている鍵を使用して、既存の Google の暗号化に加えて、Cloud Storage 内のオブジェクトまたはバケットに対する暗号化を実装します。これが推奨のオプションです。

  • Cloud Storage バケットに組み込まれているデフォルトの暗号化を使用する。 GCP では、1 つ以上の暗号化メカニズムを使用して、格納されるお客様のコンテンツを保存時に暗号化します。名前からわかるように、この暗号化はデフォルトで使用でき、ユーザーが行う必要がある操作はありません。

前述およびその他の暗号化オプションの詳細については、保存時の暗号化をご覧ください。

Cloud KMS の鍵を使用したアプリケーション レイヤ暗号化

推奨されるシークレットの格納方法は、Cloud KMS の鍵を使用するアプリケーション レイヤ暗号化を使用することです。この方法は、管理を強化する必要がある場合や、独自の鍵を管理するためのコンプライアンス要件がある場合に特に役立ちます。

このタイプの暗号化を実装するには、Encrypt リクエストを使用して、暗号化するシークレットを Cloud KMS に送信します。Cloud KMS からは暗号化されたシークレットが返され、これをストレージに書き込むことができます。

Cloud KMS では、最大 64 KiB のサイズのシークレットを扱うことができます。これより大きなシークレットを暗号化する必要がある場合は、鍵の階層を使用する、すなわち、ローカルで生成されたデータ暗号鍵(DEK)を使用してシークレットを暗号化してから、Cloud KMS の鍵暗号鍵(KEK)を使用して DEK を暗号化することをおすすめします。DEK の詳細については、エンベロープ暗号化をご覧ください。

デフォルトの暗号化

ご使用のアプリケーションにアプリケーション レイヤ暗号化が適していない場合、別の一般的なソリューションは Cloud Storage のデフォルトの暗号化を使用することです。このオプションは通常、ストレージでシークレットを保護するためのクラウド ソリューションを主に探している場合に使用されます。

この暗号化は自動的に有効になり、ユーザー側で実装に関して行う必要がある追加の操作はありません。

シークレットへのアクセスの管理

アクセスを制限および適用するには、次の 2 つの主なオプションがあります。

  • シークレットが格納されているバケットに対するアクセス制御。このオプションでは、バケットごとに複数のシークレット(オブジェクト)をサポートすることも、バケットごとにシークレットを 1 つのみサポートすることもできます。これが推奨のオプションです。
  • シークレットが格納されているバケットを暗号化する鍵に対するアクセス制御。このオプションでは、鍵ごとに複数のシークレットをサポートすることも、鍵ごとに 1 つのシークレットのみをサポートすることもできます。

シークレットを分離するのは、それによってセキュリティと利便性が向上する場合のみにしてください。一般的におすすめする設定は、暗号分離のために 1 つの暗号鍵が保護するデータ量を制限するか、1 つのアクセス制御リストが保護するデータ量を制限することです。この設定により、シークレットへのアクセスに対するより細かな制御が可能になり、誤って権限を付与することを防ぎ、より詳細な監査を行えるようになります。論理的に妥当である場合は、シークレットをグループ化します。たとえば、単一のアプリケーションが実行時に、特定のシークレットのコレクションにアクセスする必要があるような場合は、制御を容易にするためにシークレットをグループ化します。

シークレットの格納方法を決定する際には、以下のガイドラインを使用することをおすすめします。

  • 各シークレットはそれぞれ固有のオブジェクトです。
  • 複数の特徴を共有するシークレットが、単一のバケットにグループ化されます。
  • 論理的にグループ化されたこれらのシークレットを含む各バケットの暗号化には、単一の暗号鍵を使用します。

シークレットのグループ化が適しているシナリオには、次のようなものがあります。

  • 同じアプリケーションがシークレットへのアクセスを必要としている場合
  • 同じ人間の管理者がシークレットのバージョンとアクセスを管理している場合
  • 本番、開発、テストなどの環境が同じ場合
  • ビルド時やデプロイ時など、同じ時点で使用される場合
  • 必要な保護レベルが同じ場合

鍵のローテーション

シークレットを暗号化する鍵は、定期的にローテーションすることをおすすめします。鍵をローテーションすることで、単一の鍵で暗号化されるデータの量を制限し、不正使用された場合に備えて鍵のライフサイクルを制限することができます。鍵の自動ローテーションに加えて、手動で鍵をローテーションすることもできます。たとえば、シークレットの新しいバージョンが更新されたときに、鍵を手動でローテーションできます。詳細については、鍵のローテーションをご覧ください。

シークレットのローテーション

鍵のローテーションに加えて、シークレットをローテーションすることもできます。シークレットは通常、新しいバージョンが作成されたときにローテーション(更新)されます。たとえば、データベース認証情報の新しいパスワードが生成された場合です。シークレットのライフサイクルを制限するために、鍵を定期的にローテーションすることもおすすめします。

シークレットをローテーションすると、シークレットに管理が必要な複数のバージョンが生成されます。一度に有効なシークレットのバージョンは 1 つのみであることも、複数のシークレットのバージョンが有効であることもあります。アプリケーションが以前のバージョンにロールバックされた際に古いバージョンのシークレットが必要になることがあるため、古いバージョンのシークレットを一定期間保持することをおすすめします。

シークレットの複数のバージョンを管理する方法の 1 つは、バージョンごとにオブジェクトを作成し、それらのオブジェクトをその特定のシークレットに関連付けられている同じバケットに格納することです。さらに、命名規則を利用して使用中のバージョンをトラッキングできます。また、中心となる変数のセットを使用して、特定の時点でどのシークレットを使用するかを決定することもできます。

Cloud IAM を使用した権限管理

GCP でのシークレット管理の一環として、Cloud IAM を使用することをおすすめします。Cloud IAM を使用すると、GCP リソースに対する権限を作成、管理できます。また、GCP サービスに関するアクセス制御が 1 つのシステムに統合され、整合性のあるオペレーションのセットが提供されます。Cloud IAM の詳細については、Cloud IAM のドキュメントをご覧ください。

役割とアクセス管理における重要なコンセプトに、職掌分散があります。データの暗号化と復号の両方、また新しい鍵の管理や作成のすべてを 1 人のユーザーが実行できないようにしてください。詳細については、職掌分散をご覧ください。

権限の管理には、次の 2 つの方法があります。

  • サービス アカウントを使用しない方法。これが推奨のオプションです。
  • サービス アカウントを使用する方法

サービス アカウントを使用しない権限管理

Cloud KMS を使用したシークレット管理における理想的な構成は、不要なアクセスを最小限に抑えて、職掌分散を実施することです。このタイプの構成では、次のような複数のユーザーが必要です。

  • 組織レベルの管理者。これは、resourcemanager.organizationAdmin 役割を持つユーザーです。組織レベルの管理者は通常、アカウントのビジネス オーナーです。代わりに resourcemanager.projectCreator 役割を使用した場合は、そのユーザーにプロジェクトに対する owner アクセス権が付与されるので注意してください。このレベルのアクセスは通常は不要です。シークレット管理にはこの役割を使用しないことをおすすめします。
  • storage.objectAdmin 役割を持つ 2 番目のユーザー。このユーザーはシークレットの管理を担当します。このユーザーは、Cloud Storage バケットを含むプロダクトに対する storage.admin 役割を持つサービス アカウントも使用します。このサービス アカウントは、このユーザーがバケット メタデータの編集やバケットの削除をできないように制限します。
  • cloudkms.admin 役割を持つ 3 番目のユーザー。このユーザーは、シークレットの暗号化に使用される鍵を管理します。
  • storage.objectAdmincloudkms.cryptoKeyEncrypterDecrypter の両方の役割を持つ 4 番目のユーザー。これは、シークレットにアクセスする必要があるエンドユーザーです。

サービス アカウントを使用する権限管理

もう 1 つの実装では、エンドユーザーにはストレージ バケットに対する権限のみを付与し、ストレージ サービスがサービス アカウントを使用してユーザーの代わりに鍵にアクセスするようにする必要があります。この構成はサービス アカウントを使用しない権限管理で説明したものと似ていますが、次の点が異なります。

  • シークレットにアクセスするエンドユーザーに storage.objectAdmin 役割があります。
  • Cloud Storage サービス アカウント用の 5 番目のユーザーに cloudkms.cryptoKeyEncrypterDecrypter 役割があります。

人間のユーザーに鍵を使用しての暗号化と復号を一切許可しないことが望ましいとされる場合が一部にはありますが、この構成によってそれが実現できます。その場合でも、Cloud Storage は独断で鍵を使用して暗号化と復号を実行できます。

Cloud Audit Logging を使用した監査

GCP でシークレットを管理する際の最後の考慮事項は、Cloud Audit Logging を使用することです。このサービスは、GCP サービスによって生成される、管理アクティビティとデータアクセスという 2 つのログストリームで構成されます。これらのストリームは、GCP プロジェクト内で「誰がいつ、どこで、何をしたか」という質問に回答するのに役立ちます

管理アクティビティ ログには、サービスやプロジェクトの構成またはメタデータを変更する API 呼び出しや管理アクションのログエントリが含まれています。このログは常時有効になっており、プロジェクトの全員が見ることができます。

データアクセス ログには、サービスが管理するユーザー提供データ(データベース サービスに格納されているデータなど)の作成、変更、読み込みを行う API 呼び出しのログエントリが含まれています。データアクセス ログは、プロジェクトのオーナーと、プライベート ログ閲覧者役割を持つユーザーだけが見ることができます。

Cloud Storage と Cloud KMS の両方で、管理アクティビティ ログはデフォルトで有効になっています。これには、新しいバケットの作成や鍵のローテーションといった操作が含まれます。管理アクティビティ ログはデフォルトで有効であり、ユーザーが有効にする必要はありません。

データアクセス ログは大量のデータを生成する可能性があるため、Cloud Storage と Cloud KMS のいずれでも、デフォルトでは有効になっていません。このログは、特にここで説明したソリューションの実装時に頻繁に行われる操作をトラッキングします。このような操作の例には、バケットの読み込みや、鍵を使用した暗号化や復号などがあります。また、すべてのシークレットへのアクセスには Cloud Storage と Cloud KMS の両方を使用する必要があるため、シークレットの操作は両方の場所で記録される可能性があります(ただし、両方での記録は冗長になります)。

ロギングを使用する場合は、Cloud KMS の鍵に対してではなく、Cloud Storage のオブジェクトに対してデータアクセス ログを有効にすることをおすすめします。このログによって提供されるデータは、Cloud KMS の鍵に対するデータアクセス ログよりも詳細で監査も容易です。また、特に重要なシークレットについては、Cloud Storage オブジェクトに対してデータアクセス ログを有効にします。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud KMS ドキュメント