ストレージとデータ転送

Cloud Storage でデータのプライバシーとセキュリティを確保するための 4 つのベストプラクティス

2021年1月22日

https://storage.googleapis.com/gweb-cloudblog-publish/images/GCP_Cloud_Storage.max-2600x2600.jpg

Google Cloud Japan Team

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

Cloud Storage を使用すると、組織は費用面や運用面での負担の軽減、迅速なスケーリングをはじめとした、クラウドコンピューティングがもたらすメリットを享受できます。同時に、アクセスを制限して機密情報を保護するために、プライバシーとセキュリティの要件も確実に満たさなくてはなりません。

セキュリティは、企業がデータをクラウドに移行する際に聞かれる共通の懸念事項であると同時に、Google Cloud のすべてのプロダクトにとっての最優先事項でもあります。Cloud Storage はシンプルで信頼性が高いだけでなく、優れた費用対効果であらゆるデータ量の保存と取得をいつでも行うことができます。また、転送中と保存中のデータの暗号化や、さまざまな暗号鍵管理オプション（Google 管理、顧客指定、顧客管理、ハードウェアセキュリティモジュールなど）といったセキュリティ機能が組み込まれています。Google は世界最大級のプライベートネットワークを有しており、Cloud Storage を使用する際に公共のインターネットにデータが公開されるリスクを最小限に抑えます。

Cloud Storage でデータを保護するためのベストプラクティス

エンタープライズストレージデータを保護するには、将来の脅威や新たな課題からデータを保護するための計画を事前に立てておく必要があります。Cloud Storage には、基本的な機能に加え、均一なバケットレベルのアクセス、サービスアカウントの HMAC キー、IAM Conditions、委任トークン、V4 署名などの複数のセキュリティ機能が備わっています。

これらの機能を使用して、データを大規模に保護するためのセキュリティのベストプラクティスをいくつか共有いたします。

1: 組織のポリシーを使用して制御を一元管理し、コンプライアンスの境界を定義する

Google Cloud と同様に、Cloud Storage もリソース階層に従っています。バケットには、プロジェクトに関連付けられたオブジェクトが保持され、プロジェクトは組織に関連付けられます。フォルダを使用して、プロジェクトのリソースをさらに分離することもできます。組織のポリシーは、サービス固有の動作を適用するために、組織、フォルダ、プロジェクトのレベルで設定できます。

組織のポリシーで有効化をおすすめしているのは、次の 2 つです。

ドメインで制限された共有 - このポリシーは、コンテンツが組織外のユーザーと共有されるのを防ぎます。たとえば、バケットの内容を公共のインターネットで公開しようとした場合、このポリシーはそのオペレーションをブロックします。
均一なバケットレベルのアクセス - このポリシーは、アクセス許可を簡素化し、アクセス制御を大規模に管理するのに役立ちます。このポリシーでは、新しく作成されたすべてのバケットにバケットレベルで設定された均一のアクセス制御があり、バケット内のすべてのオブジェクトに対するアクセスを管理します。

2: アクセス制御を簡素化するために Cloud IAM の使用を検討する

Cloud Storage には、バケットとオブジェクトにアクセス権を付与するための 2 つのシステムが用意されています。1 つは Cloud IAM で、もう 1 つはアクセス制御リスト（ACL）です。ユーザーにリソースへのアクセスを許可するには、どちらか一方の方法でアクセス許可を付与するだけでかまいません。

ACL はオブジェクトレベルであり、個々のオブジェクトへのアクセス権を付与します。バケット内のオブジェクトの数が増えると、個々の ACL を管理するために必要なオーバーヘッドも増加します。これにより、1 つのバケット内にあるすべてのオブジェクトの安全性がどの程度であるかを評価することが難しくなります。1 人のユーザーが適切なアクセス権を持っているかどうかを確認するために、何百万個ものオブジェクトを反復処理することを想像してみてください。

リソースへのアクセスの制御には、Cloud IAM を使用することをおすすめします。Cloud IAM は、Google Cloud 全体にわたるプラットフォーム中心の統一されたメカニズムを有効にして、Cloud Storage データのアクセス制御を管理します。バケットレベルの均一なアクセス制御を有効にすると、オブジェクト ACL は使用できなくなり、バケットレベルの Cloud IAM ポリシーがアクセス管理に使用されます。そのため、バケットレベルで付与されたアクセス許可は、バケット内のすべてのオブジェクトに自動的に適用されます。

3: IAM ポリシーが使用できない場合は、ACL に代わる別の方法を検討する

私たちは、お客様がマルチクラウドアーキテクチャであれ個別ユーザーとのオブジェクトの共有であれ、さまざまな理由で ACL を使用し続ける場合があることを認識しています。ただし、エンドユーザーをオブジェクト ACL に含めることはおすすめしません。

代わりに、以下の選択肢をご検討ください。

署名付き URL - 署名付き URL を使用すると、Cloud Storage リソースへの時間制限付きアクセスを委任できます。署名付き URL を生成すると、そのクエリ文字列には、アクセス権を持つアカウント（サービスアカウントなど）に関連付けられた認証情報が含められます。たとえば、ユーザーに URL を送信してドキュメントへのアクセスと読み取りを許可し、その 1 週間後にアクセス権を取り消すことができます。
個別のバケットの使用 - バケットを監査し、アクセスパターンを確認します。オブジェクトのグループがすべて同じオブジェクト ACL セットを共有していることに気付いた場合は、それらを別個のバケットに移動して、バケットレベルでアクセスを制御できるようにすることを検討してください。
IAM Conditions - アプリがオブジェクトの命名で共有プレフィックスを使っている場合、IAM Conditions を使用して、これらのプレフィックスに基づいてアクセスをシャーディングすることもできます。
委任トークン - STS トークンを使用して、Cloud Storage バケットや共有プレフィックスへの時間制限付きアクセス権を付与できます。

4: HMAC キーを、ユーザーアカウントではなくサービスアカウントに使用する

ハッシュベースのメッセージ認証キー（HMAC キー）は、Cloud Storage に対するリクエストに含まれる署名を作成するために使用される認証情報の一種です。一般的に、HMAC キーを、ユーザーアカウントではなくサービスアカウントに使用することをおすすめします。これにより、個々のユーザーが保持するアカウントに依存することで発生するセキュリティとプライバシーへの影響を排除できます。ユーザーアカウントはユーザーがプロジェクトから抜けたり退社したりした際に無効になる可能性があるため、サービスへのアクセスが停止するリスクも軽減できます。

セキュリティのさらなる強化に向けて、以下の作業も実施されることをおすすめします。