コンテンツに移動
セキュリティ & アイデンティティ

新しい Secret Manager の機能と統合でセキュリティを強化

2021年8月18日
Google Cloud Japan Team

※この投稿は米国時間 2021 年 8 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

Secret Manager は、API キー、パスワード、証明書などの機密データを安全かつ手軽に保存できるようにする Google Cloud のサービスであり、Google Cloud で使用されるすべてのシークレットを一元的に管理、アクセス、監査することが可能な、信頼できる唯一の情報源として機能します。そのリリース以降、数百万単位のワークロードの保護に貢献してきており、レプリケーション ポリシーVPC 境界のサポートなど、新しい機能を業界に先駆けて提供し続けています。このブログ投稿では、Secret Manager の新機能と、シークレットの安全性を保つのに有効な統合について解説します。

新しい無料枠

架空の話ではなく、現実に Secret Manager で無料枠が利用できるようになりました。この無料枠では以下を使用できます(請求先アカウントごと、1 か月あたり)。

  • 最大 6 つのシークレット バージョン

  • 最大 3 つのローテーション イベント

  • 最大 10,000 回の API 呼び出し

これにより、Secret Manager の価値を最小限の財政的リスクで体験できるようになります。また、Cloud Run や Cloud Functions など、無料枠を提供する既存のサービスとうまく組み合わせることもできます。すでに Secret Manager を利用している場合、この変更は次の請求期間から有効になります。Secret Manager の無料枠について詳しく確認するには、ドキュメントをご覧ください。

SLA の引き上げ

お客様の増大する可用性と信頼性の要件を満たすために、Secret Manager の SLA を 99.95% まで引き上げました。このアップデートはつまり、すべての有効なリクエストが 99.95% の確率で成功することが保証されるということです。そのため、重要度が最も高い部類のワークロードにも Secret Manager を活用できるようになります。詳しくは、最新の Secret Manager SLA をご覧ください。

地域拡大

無料枠の導入、SLA の引き上げに加え、Secret Manager がすべての一般公開 Google Cloud リージョンで利用できるようになりました。Secret Manager のレプリケーション ポリシーを使用して、シークレットの複製先にする特定のリージョンを選択することで、ワークロードやユーザーから地理的に近い場所にシークレットのペイロードを配置してレイテンシを削減できます。この手法は、特定の地域に適用される、データ保存に関する法的および規制上の要件がある場合にも非常に効果的です。詳しくは、ドキュメントの Secret Manager のロケーションの一覧をご覧ください。

コンプライアンスに関する認定

規制対象のデータの保存と処理に使用できるよう、Secret Manager は、次のコンプライアンス要件への準拠が実証されています。ISO 27001ISO 27017ISO 27018SOC 1SOC 2SOC 3PCI DSSHIPAA。SLA の引き上げ、利用可能な地域の拡大、そしてこの認定により、Secret Manager は規制対象となるワークロードでの使用に適したものとなっています。

顧客管理の暗号鍵(CMEK)

Secret Manager では、転送中のペイロードを TLS で、保存中のペイロードを AES-256 で常に保護しています。シークレットのペイロードの暗号化に使用される鍵をより細かく制御したいお客様のために、Secret Manager で顧客管理の暗号鍵(CMEK)がサポートされるようになりました。Secret Manager の CMEK では、Cloud KMS を介するソフトウェア格納型鍵、Cloud HSM を介するハードウェア格納型鍵、Cloud EKM を介する外部管理の鍵がサポートされます。チュートリアルで、Secret Manager の CMEK サポートを有効にする方法をご覧ください。

有効期限と TTL

これまでも、IAM 条件を使用してシークレットへのアクセス権を期限切れにすることは可能でしたが、おおもとのシークレットは残ったままになっていました。今回、Secret Manager でシークレットの自動期限切れ機能がサポートされるようになり、指定したタイムスタンプまたは TTL を基準にシークレットを永久に削除できるようになりました。また、シークレットの TTL は更新することもできるため、シークレットの「貸し出し」を行い、この貸し出しを定期的に更新することも可能になりました。TTL が更新されず、貸し出しの延長が行われなかった場合、シークレットは自動的に削除されます。

シークレットの期限切れ機能は IAM 条件と組み合わせて使用することも可能であり、シークレットをより安全に期限切れにすることができます。シークレットの期限切れ機能や安全対策に関する詳細については、有効期限付きのシークレットの作成と管理のガイドをご覧ください。

ETag とサーバーサイド フィルタリング

APISDK を介して Secret Manager のシークレットを作成、管理するお客様にとって、同時実行の制御とパフォーマンスは極めて重要になります。Google はこれを踏まえ、ETag とサーバーサイド フィルタリングを Secret Manager で使用できるようにしました。ETag で使用されるオプティミスティック同時実行制御により、同じシークレットに対して複数の変更が同時に実行されることが防止されます。また、サーバーサイド フィルタリングでは、ペイロード サイズとクライアントサイドの計算オーバーヘッドを大幅に軽減できます。これらを組み合わせることで、強整合性が保証され、アプリケーションのパフォーマンスが向上します。詳細については、ドキュメントの Secret Manager の ETagSecret Manager のサーバーサイド フィルタリングをご覧ください。

コーディング、ビルド、実行、デプロイ、モニタリング、オーケストレーション

API キー、パスワード、証明書などのシークレットは、最新のソフトウェア アプリケーションのほとんどで不可欠な要素です。開発者、オペレーター、セキュリティ チームがソフトウェアを安全にビルド、運用、監視できる体制が整っていなければなりません。そこで Google は、アプリケーション開発ライフサイクル全体で使用される一般的なツールとテクノロジーに、Secret Manager を統合しました。

  • コーディング - ソフトウェア エンジニアは、Cloud Code を使用して、使い慣れた IDE から直接シークレットの作成や、シークレットへのアクセスができます。VS Code、IntelliJ、Cloud Shell エディタなら、シークレットの参照や、シークレットにアクセスするためのコード スニペットの挿入も、すべて使い慣れたローカル IDE から行うことが可能です。

  • ビルド - リリース エンジニアは、Cloud Build と Secret Manager の統合を活用した CI ビルドの一環としてシークレットにアクセスできます。これは、Docker レジストリへの認証や、GitHub API との通信などに使用できます。他の CI システムを使用する場合には、Secret Manager のシークレットにアクセスするための GitHub アクションも利用できます。

  • 実行(サーバーレス) - Cloud Run と Secret Manager のネイティブ統合を活用することで、環境変数として、またはファイルシステムを介して利用できるシークレットのマウントが可能です。シークレットは Cloud Run のコントロール プレーンで解決されるため、この統合を使用して、アプリケーションと Secret Manager との間の密結合を回避し、ハイブリッド クラウド デプロイや優れたローカル開発エクスペリエンスを実現できます。

  • 実行(Kubernetes 上) - Secret Manager CSI ドライバを使用して、GKE、Anthos、または任意の Kubernetes クラスタからシークレットをマウントできます。ベンダーに依存しないこのドライバにより、環境変数またはファイルシステムを介してシークレットが公開され、他のパブリック クラウド プロバイダや HashiCorp Vault と同じインターフェースを使用したハイブリッド クラウド デプロイが可能になります。

  • デプロイ - 既存の Secret Manager と Terraform の統合を補完するために、Kubernetes Config Connector(KCC)で Secret Manager を管理できるようになりました。オペレーターは KCC を使用して、Kubernetes と使い慣れた Kubernetes API で Google Cloud リソースを管理できます。

  • モニタリング - セキュリティ チームは、Secret Manager と Cloud Asset Inventory(CAIS)の統合を活用して、特定のプロジェクトやフォルダ、または組織全体のシークレットの使用状況を把握できます。

  • オーケストレーション - DevOps チームやセキュリティ チームは Secret Manager Event Notifications を使用することで、Pub/Sub トピックをサブスクライブし、シークレットやシークレット バージョンの変更に関する通知を受け取れます。これにより、新しいシークレット バージョンが追加されたときに ServiceNow チケットを作成するといった、高度に統合されたワークフローの作成が可能になります。また、DevOps チームは Secret Manager Rotation Scheduling を使用して、ローテーション ガイドで説明されているような自動ローテーション フローを構築することもできます。

ベスト プラクティス

Secret Manager のベスト プラクティス ガイドには、どうすれば Secret Manager からセキュリティ面の利点を最大限引き出せるかが解説されています。セキュリティは総合的に考慮すべき分野なので、このガイドは、アクセス制御、コーディング方法、シークレット管理など、きめ細かいトピックを扱っています。Secret Manager のベスト プラクティス ガイドはすべてを完全に網羅しているわけではありませんが、本番環境デプロイでの Secret Manager の使用に関するよくある疑問や懸念事項の答えが載せられています。

シームレスなセキュリティに向けて

シークレットの管理は、あらゆる組織のセキュリティ ツールキットにおける重要な要素です。Secret Manager を利用すれば、Google Cloud、Ahthos、オンプレミスで使用する API キーや認証情報などのシークレットに対する管理、監査、アクセスが容易になります。趣味でサイド プロジェクトに取り組んでいる個人ユーザーであれ、数千人規模の従業員を抱える大企業であれ、これらの新しい機能と統合を活用することで簡単に Secret Manager を導入できます。

使用を開始するには、Secret Manager のドキュメントをご覧ください。

-デベロッパー アドボケイト兼プロダクト マネージャー Seth Vargo

-エンジニアリング&プロダクト マネージャー Phillip Tischler

投稿先