とっておきのセキュリティの秘密: Secret Manager で機密情報を守る方法
Google Cloud Japan Team
※この投稿は米国時間 2023 年 7 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。
秘密を守るのは得意ですか？秘密を守るのに苦労している人はたくさんいます。企業についても同じです。企業のデジタル認証情報には、パスワード、API キー、トークン、ソフトウェアのコードに組み込まれた暗号鍵などがあります。これらは保護されたリソースやサービスへのアクセスを認証するために使用する重要な機密情報（シークレット）です。
こうしたシークレットのセキュリティは、アプリケーションのインフラストラクチャと環境を保護するうえで企業が管理しなければならない最大のリスクの一つです。そこで、お客様によるシークレットの適切な管理を可能にする重要なツール、Google Cloud Secret Manager をご紹介します。
Secret Manager は、組織内のシークレットを一元的に保存し、アクセス、管理、監査できるセキュアで効率的なツールです。2023 年 4 月版 Threat Horizons レポートで述べたとおり、認証情報や鍵の管理が十分でないことは、クラウドのお客様が現在直面している重要なセキュリティ問題の一つです。特にサービス アカウント キーは、内部の脅威からクロスクラウドの侵害や知的財産スパイに至るまで、あらゆる場面で使用されていることが確認されています。
DevOps が普及するにつれて、シークレットは開発のあらゆる局面で使用されるようになっています。場合によっては、構成ファイルや関数内に直接平文でシークレットをコーディングすることもあり、コード リポジトリで露出することになります。シークレットが不正使用されると、企業データに不正アクセスするための特権アクセス権の取得、重要なシステムへの侵入、攻撃の実行が発生する可能性が出てきます。
Secret Manager により、セキュリティ侵害の可能性が高まる中でも、企業はシークレットをさらに効果的に管理できます。シークレット管理のリスク分析をする際は、次の 4 点について考慮が必要です。
シークレット スプロール: ワークロードをさらにクラウドに移動するのに伴い、管理すべきシークレットの数は指数的に増加します。これは、さまざまな場所にシークレットが保存されるシークレット スプロールを招き、その追跡と管理が困難になります。
ヒューマン エラー: 人間はどうしてもミスを起こすものです。シークレットの管理においては特にその傾向が強くなります。シークレットを誤って共有してしまうことや、シークレット管理ツールの構成ミスなどの間違いは、深刻な結果を招く可能性があります。
コンプライアンス違反: センシティブ データを扱う組織はさまざまなコンプライアンス規制の対象となり、その中には PCI-DSS、SOC 2、HIPAA、GDPR などがあります。シークレットの管理が適正でなければ、コンプライアンス違反につながる可能性があります。
ダウンタイム: シークレットの適切な管理やローテーションができていなければ、それに依存しているアプリケーションやサービスのダウンタイムを招く可能性があります。
Secret Manager を使用すれば、IT チームは、シークレットを保存し管理する一元的な場所を設けることにより、シークレットを追跡できます。シークレットには、直接 Secret Manager のコンソールからも、Secret Manager の API や SDK を介してもアクセスできます。さらに Secret Manager はアプリケーションに合わせてスケールできるように設計されています。パフォーマンスの問題を引き起こすことなく必要な数のシークレットを保存できて、API ファーストの設計によって他の既存システムにも拡張や統合が可能です。
Google Cloud への Secret Manager のインテグレーション
多くの場合、開発者は使いやすさからシークレット構成の詳細を平文でコードに保存します。この方法に関連して、次の 2 つの大きなリスクが存在します。
シークレットにアクセス可能であれば閲覧やコピーが可能。監査やアクセス制御を適用する手段がない。
開発環境、テスト環境、本番環境の間でコードを移動するのが困難。
ソフトウェア サプライ チェーンにおける、Secret Manager でサポートされているクラウド主導の Google Cloud サービスとのインテグレーションにより、機密情報の保存とアクセスがより簡単かつ安全になります。
このツールの主眼は、ビルド時も実行時も機密情報がセキュアに利用できるようにすることです。
Secret Manager のインテグレーションもまた、以下に示すようにソフトウェア サプライ チェーン中での機密情報のセキュリティに役立つ可能性があります。
1. ソフトウェアの構築とデプロイに使用する CI / CD システムとのインテグレーション
Cloud Code とのインテグレーションにより、パスワードや認証情報、トークンなどの機密構成データをコードベースにハードコードするのを避けることで、よりセキュアなアプリケーションをビルドできます。必要に応じてプログラムで取得できるシークレットに置き換えます。お使いの IDE の中で、そこから移動する必要なく直接的にシークレットを作成、アクセス、変更できます。インテグレーションは、VS Code、IntelliJ、Cloud Shell Editor について可能です。
Cloud Functions とのインテグレーションにより、環境変数として、またはファイル システムを介したボリュームとして、シークレットのアクセスや提示が可能です。
Cloud Build: ビルドでセンシティブ データを扱うためには、それを Secret Manager に保存し、その情報に直接アクセスするようにビルドの手順を設定します。ビルド手順の中では、シークレットの値を環境に関連付けて、スクリプトやプロセスからは環境変数を介してその値にアクセスできます。機密の依存関係をビルド時に取得することは以下の 2 つの場合によく使用されます。
Docker ハブへのイメージの pull / push のために Docker 認証情報を保存する。
ビルドに対して GitHub の pull リクエストを作成する。
2. ランタイム エンジンとのインテグレーション
Cloud Run: ネイティブなインテグレーションにより Cloud Run サービスでシークレットを容易にマウントできます。このインテグレーションを使用すれば、ボリュームのマウントもしくは環境変数としてシークレットをコンテナで使用可能になります。平文の環境変数として保存するのではなく、Secret Manager に保存されたシークレットの名前で参照することにより、機密の依存関係を環境変数に保存できます。このシークレット アクセス操作は、ソースコードを 1 行も変更することなく Cloud Run コンソールから直接行うことができます。
環境変数からではなくファイルからシークレットをコードが読み取る場合は、「ボリュームとしてマウント」のオプションを使用すると、シークレットが環境変数に対するファイルのように使用できます。サービスのデプロイ中は、コンテナの実行に使用するサービス アカウントを検証して必要な権限があるかどうかを確認し、望ましくないアクセスを防止します。
Kubernetes と GKE: CSI ドライバ - プロバイダ ソリューションは Kubernetes とのインテグレーションが可能なオープンソース ソフトウェアです。ドライバによってシークレットを Google Secret Manager に一元的に保存し、Kubernetes の Pod として Kubernetes ネイティブな方法で使用できます。このソリューションには追加の同期機能も付属しています。シークレットを使用するメソッドでは SM の機能、たとえばバージョニング、ローテーション管理、デフォルト / CMEK 暗号化、他の Google Cloud サービスとのクラウド フォーカス インテグレーションなどが利用できます。ドライバ ソリューションを GKE コンポーネントとして公式にサポートするための作業が進行中です。
Secret Manager の組織への適性について
開発者は作業するために預かったセンシティブ データを保護し、シークレットをコードから排除するという大きな責任を負っています。しかし組織も、期待されたことをチームが果たすためのツールやソリューションを提供する責任を負っています。Secret Manager によって、開発者は容易にシークレットの保存と管理を行いつつ、セキュリティを改善できます。
Secret Manager についての詳細は、以下のリソースをご確認ください。
これまでの「とっておきのセキュリティの秘密」ブログは、こちらでお読みください。
- Google Cloud、CISO オフィス セキュリティ アドバイザー Anton Chuvakin
- プロダクト マネージャー Aswin Viswanathan
