Google Cloud Secret Manager のご紹介
Google Cloud Japan Team
※この投稿は米国時間 2020 年 1 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。
アプリケーションの多くは、データベースとの接続時に使用する資格情報や、サービスを呼び出すための API キー、もしくは認証用の証明書を必要とします。こうしたシークレットのアクセス管理やセキュリティ保護は、機密データの氾濫や可視性の低さ、統合機能の欠如などが原因で複雑になることが珍しくありません。
Secret Manager は、API キー、パスワード、証明書、その他の機密データの安全かつ便利な保存方法を提供する Google Cloud の新しいサービスです。Google Cloud 全体にわたってシークレットの管理やアクセス、監査を支援する唯一の信頼できる情報源となります。
Secret Manager は重要な機能を数多く提供します。
グローバル名とレプリケーション : シークレットはプロジェクト内でグローバルなリソースです。自動またはユーザー管理のレプリケーション ポリシーを選べるため、シークレットの保存場所を制御できます。
ファーストクラス バージョニング : シークレット データは書き換え不能で、ほとんどの操作は指定されたシークレット バージョンで行われます。Secret Manager では、
42
といった特定のバージョンを指定することも、latest
といった流動的なエイリアスを使うことも可能です。
最小特権の原則 : シークレットにアクセスできるのはプロジェクト オーナーだけです。ほかの役割のユーザーに対しては、Cloud IAM を介して明示的に権限を付与する必要があります。
監査ロギング : Cloud Audit Logging を有効にすると、Secret Manager での操作ごとに監査ログ エントリが生成されます。この監査ログを異常検知システムに取り込むと、異常なアクセス パターンが特定され、セキュリティ侵害の可能性があるときにはアラートが生成されます。
強力な暗号化の保証 : 転送中のデータは TLS、保存中のデータは AES256 でそれぞれ暗号化されます。近日中に CMEK(顧客管理の暗号化鍵)もサポートされます。
VPC Service Controls : VPC Service Controls により、ハイブリッド環境から Secret Manager へのコンテキストアウェア アクセスが可能になります。
現在、Google Cloud のすべてのお客様が Secret Manager のベータ版をご利用いただけます。まずは Secret Manager クイックスタートをご覧ください。以下では、Secret Manager の機能の一部を詳しく説明します。
グローバル名とレプリケーション
従来のシークレット管理ツールでは、リージョン間で異なることがほとんどない API キーや証明書などの認証情報でもリージョンごとの設定が必要とされており、これがネックになっていることがお客様からの早期フィードバックで明らかになりました。そのため、シークレット名はプロジェクト内でグローバルに扱われます。
ただし、シークレット名はグローバルですが、シークレット データはリージョン固有です。シークレットが保存されるリージョンを完全に制御したいかどうかは企業によって異なるので、Secret Manager は以下のレプリケーション ポリシーを使用して、そうしたお客様の要件と好みの両方に対応します。
自動レプリケーション : 最もシンプルなレプリケーション ポリシーであり、Secret Manager のシークレットをどのリージョンにレプリケートするかを Google に任せます。
ユーザー管理のレプリケーション : ユーザー管理のレプリケーション ポリシーが指定されると、Secret Manager は、ユーザーによって指定されたすべてのロケーションにシークレット データをレプリケートします。ほかのソフトウェアをインストールしたり、サービスを実行したりする必要はありません。指定されたリージョンへのデータのレプリケーションは Google が行います。シークレット データが保存されるリージョンを指定したいお客様は、このレプリケーション方法を選択してください。
ファーストクラス バージョニング
バージョニングは、段階的ロールアウト、緊急ロールバック、および監査をサポートする高信頼システムにとってコアとなる要素です。Secret Manager は、シークレット バージョンを使用してシークレット データのバージョンを自動的に管理します。アクセス、破棄、無効化、有効化などほとんどの操作はシークレット バージョンを指定して行われます。
本番環境のデプロイでは常に特定のシークレット バージョンに固定しなければなりません。シークレットの更新は、新バージョンのアプリケーションをデプロイするときと同じ方法で処理する必要があります。それに対し、開発やステージングといった高速反復型の環境では、常に最新バージョンのシークレットを返す latest
エイリアスを Secret Manager で使用できます。
シークレットの作成
シークレットの作成は、Secret Manager API やクライアント ライブラリのほか、Cloud SDK でも可能です。
シークレット バージョンへのアクセスも同様です。
シークレットのディスカバリ
前述したように、Secret Manager はさまざまなシークレットを保存できます。Cloud DLP を使用すれば、証明書やシークレット用の infoType 検出器でシークレットを見つけやすくなります。次のコマンドは、ソース ディレクトリのすべてのファイルを検索して、Secret Manager に移行できるシークレットのレポートを生成します。
シークレットを Cloud Storage バケットに保存している場合は、バケットをスキャンする DLP ジョブを Cloud Console で設定できます。
ほかの Google Cloud 製品やサービスでも、Secret Manager とのネイティブな統合を順次リリースする予定です。
Berglas との関係
Berglas(Google Cloud でのシークレット管理を目的とするオープンソース プロジェクト)については、そのまま使用し続けることができます。Berglas v0.5.0 以降の場合、sm://
というプレフィックスを指定すれば、Secret Manager から直接シークレットを作成し、アクセスできるようになります。
Berglas が管理しているシークレットを Secret Manager に移したい場合は、berglas migrate
コマンドを使って 1 回限りの自動移行を実行できます。
セキュリティのさらなる強化
現代のソフトウェア開発で中心となるのはセキュリティです。Google Cloud のセキュリティ製品ポートフォリオにシークレット管理サービスを追加し、お客様の環境をよりセキュアなものにできることを私たちはうれしく思います。Secret Manager を使用すれば、Google Cloud 全体にわたって、API キーや認証情報のようなシークレットの管理、監査、アクセスが容易になります。
詳細は Secret Manager のドキュメントや料金ページをご覧ください。
- By Seth Vargo, Developer Advocate and Matt Driscoll, Product Manager