共有と共同作業

このドキュメントでは、一般的なデータ共有および共同作業のさまざまなシナリオについて説明します。シナリオを実装するために、プロジェクトとバケットの Identity and Access Management（IAM）ポリシーとオブジェクトのアクセス制御リスト（ACL）を構成する方法についても説明します。

機密データの保存とメンテナンス

このシナリオでは、ある企業のマーケティング アナリストが、Cloud Storage を使って、機密の収益予測や販売予測データをバックアップしたいと考えています。このデータにアクセスできるユーザーを、マーケティング アナリストのみにする必要があります。この企業の Cloud Storage アカウントを統括し、管理しているのは IT 部署です。主な管理業務には、社内のさまざまな部署が Cloud Storage にアクセスできるようにバケットを作成して共有することが含まれます。

マーケティング アナリストの守秘義務とプライバシーのニーズを満たすには、バケットとオブジェクトの権限によって、スプレッドシートの保存先のバケットを IT スタッフが保守できるようにすると同時に、バケットに保存されているデータを IT スタッフが表示 / ダウンロードできないようにすることが必要です。これを行うには、finance-marketing という名前のバケットを作成し、リストされているリソースに対する次のロールを、指定されたプリンシパルに付与します。

ロール	リソース	プリンシパル	説明
ストレージのレガシー バケット オーナー	バケット finance-marketing	IT スタッフ	IT スタッフにバケットのストレージのレガシー バケット オーナーのロールを追加すると、オブジェクトの削除やバケットの IAM ポリシーの変更など、一般的なバケット管理タスクを実行できるようになります。また、IT スタッフは finance-marketing バケットの内容を一覧表示することもできるようになりますが、内容の表示やダウンロードを行うことはできません。
ストレージのオブジェクト作成者	バケット finance-marketing	マーケティング アナリスト	マーケティング アナリストにバケットについてのストレージ オブジェクト作成者のロールを与えると、バケットにオブジェクトをアップロードできるようになります。アナリストはアップロードしたオブジェクトの所有者になり、そのオブジェクトを表示、更新、削除できます。

これらのロールにより、マーケティング アナリストがバケットに追加したオブジェクトは、アナリスト自身以外のだれも表示 / ダウンロードすることができません。ただし、アナリストは、オブジェクトの ACL を変更することにより、他のユーザーにアクセスを許可できます。このようにしても IT スタッフは、必要に応じて finance-marketing バケットの内容の一覧表示や、バケットに保存されているファイルの削除、置き換えを行えます。

注意: IT スタッフにはバケットを管理する権限が付与されているため、バケット内のオブジェクトを表示する権限を自分や他のユーザーに付与できます。その対策として、監査ログを表示し、バケットおよびプロジェクトのアクセス許可に対する変更を追跡できます。

このシナリオを実装する

実行内容

シナリオ実装のためには、次のアクションを実行する必要があります。

1. finance-marketing という名前のバケットを作成します。手順については、バケットの作成をご覧ください。

2. 各 IT スタッフ メンバーに、バケットに対するストレージのレガシー バケット オーナーのロールを与えます。手順については、バケットレベルのポリシーにプリンシパルを追加するをご覧ください。

IT スタッフの実行内容

シナリオ実装のため、IT スタッフは次のアクションを実行する必要があります。

1. マーケティング アナリストに、バケットに対するストレージのオブジェクト作成者のロールを付与します。手順については、バケットレベルのポリシーにプリンシパルを追加するをご覧ください。

ベンダー向けドロップ ボックス

このシナリオでは、ある建設会社がさまざまなプロジェクトの建築計画を提供している複数の建築設計会社（ベンダー）と連携しています。建設会社は、ベンダー会社がプロジェクトのさまざまなマイルストーンで建築計画をアップロードできるようにベンダー向けドロップ ボックスを設定する必要があります。ドロップ ボックスでは、建設会社のクライアントのプライバシーを守る必要があります。つまり、このドロップ ボックスでは、ベンダーが他のベンダーの仕事を見られないようにしなければなりません。そのようにするには、建設会社ごとに別々のバケットを作成して、リストされたリソースに対する次のロールを、指定されたプリンシパルに付与します。

ロール	リソース	プリンシパル	説明
オーナー	プロジェクト全体	建設会社のマネージャー	建設会社のマネージャーにプロジェクト レベルでオーナーのロールを付与すると、ベンダーごとにバケットを作成できるようになります。
ストレージ オブジェクト閲覧者	プロジェクト全体	建設会社のマネージャー	ストレージ オブジェクト閲覧者を付与された建設会社のマネージャーは、ベンダーがアップロードするオブジェクトをダウンロードできます。
ストレージのレガシー バケット オーナー	各ベンダーのバケット	建設会社のマネージャー	ストレージのレガシー バケット オーナーのロールを付与された建設会社のマネージャーは、バケットごとの内容を一覧表示し、各プロジェクト マイルストーンの終了時にオブジェクトを削除できます。
ストレージのオブジェクト管理者	各ベンダーのバケット	バケットに関連するベンダー	各ベンダーに、それぞれのバケットについてのストレージのオブジェクト管理者を付与すると、オブジェクトのアップロード、バケット内のオブジェクトの一覧表示、各オブジェクトにアクセスできるユーザーの制御など、ベンダーは、バケット内のオブジェクトを完全に制御できるようになります。メタデータ（バケットに対するロールなど）の変更や表示はできません。プロジェクト内の他のバケットの一覧を取得して表示することもできないため、ベンダー間のプライバシーが保護されます。

このシナリオを実装する

実行内容

シナリオ実装のためには、次のアクションを実行する必要があります。

1. 建設会社のマネージャーにプロジェクトに対するオーナーのロールと、プロジェクトに対するストレージ オブジェクト閲覧者のロールを付与します。手順については、単一のロールを付与するをご覧ください。

建設会社のマネージャーの実行内容

建設会社のマネージャは、シナリオ実装のために次のアクションを実行する必要があります。

1. ベンダーごとに個別のバケットを作成します。手順については、バケットの作成をご覧ください。

   建設会社のマネージャーにはオーナーのロールが与えられているため、作成するバケットごとにストレージのレガシー バケット オーナーのロールが自動的に付与されます。

2. 各ベンダーに、それぞれのバケットに対するストレージ オブジェクト管理者を付与します。手順については、バケットレベルのポリシーにプリンシパルを追加するをご覧ください。

3. ベンダーが Google Cloud Console を使用する予定の場合は、バケットへのリンクを次の形式で提供します。

   https://console.cloud.google.com/storage/browser/BUCKET_NAME

   ここで、BUCKET_NAME はベンダーのバケットの名前です。

ベンダーの作業

各ベンダーは、シナリオ実装のために次のアクションを実行する必要があります。

1. 割り当てられたバケットにオブジェクトをアップロードします。これを行う最も簡単な方法は Google Cloud コンソールを使用する方法です。Google Cloud CLI などの他の方法では、使用する前に追加の設定が必要です。手順については、オブジェクトのアップロードをご覧ください。

   注: ベンダーは、このシナリオで設定された権限に基づき、自社に割り当てられたバケットに関連するいずれかのメールを使用してログインする必要があります。

認証によるブラウザでのダウンロード

このシナリオでは、クライアントは、ブラウザでの単純なダウンロードにより特定のユーザーにファイルを利用させたいと考えています。これは、Cloud Storage の Cookie ベースの認証を使用して行います。オブジェクトをダウンロードするには、ユーザーが有効なアカウント（Google Workspace、Cloud Identity、Gmail、Workforce Identity 連携など）にログインして認証を受ける必要があります。次の認証済みユーザーがオブジェクトをダウンロードできます。

• オブジェクト自体のアクセス制御リスト（ACL）で、READ または FULL_CONTROL 権限を持つユーザー。

• オブジェクトを含むバケットまたはプロジェクトに適用される Identity and Access Management（IAM）ポリシーで、storage.objects.get 権限を持つユーザー。

その他のすべてのユーザーには、403 Forbidden (access denied) のエラーが返されます。

この機能を使用するには、ユーザーにオブジェクトへのアクセス権限を付与してから、そのユーザーにオブジェクトへの特別な URL を渡してください。ユーザーがこの URL をクリックすると、Cloud Storage によりアカウントにログインするよう求められ（まだログインしていない場合）、オブジェクトがそのユーザーのパソコンにダウンロードされます。

このシナリオを実装する

Cookie ベースの認証は、一般的な次の 4 つの手順で構成されます。

1. バケットを作成します。手順については、バケットの作成をご覧ください。

   所有するプロジェクトの中にバケットを作成する場合、バケットにオブジェクトをアップロードし、バケットにアクセスできるユーザーを変更するためのアクセス許可が自動的に付与されます。

   注: 使用するバケットがすでにある場合、このシナリオでは、保護されているコンテンツをそのバケットから提供することになります。匿名ユーザーには、オブジェクトへのアクセスを許可するバケットレベルまたはプロジェクト レベルのロールを与えないようにすることをおすすめします。

2. 共有するオブジェクトをアップロードします。手順については、オブジェクトのアップロードをご覧ください。

   オブジェクトをアップロードすると、そのオブジェクトの所有者になり、オブジェクトの ACL を変更できます。

3. ユーザーにオブジェクトへのアクセス権を与えます。 これは、次の 2 つのうちのいずれかの方法で実行できます。

   1. バケットの IAM ポリシーを変更して、目的の各ユーザーにバケット内のすべてのオブジェクトに適用されるストレージ オブジェクト閲覧者のロールを付与します。手順については、バケットレベルのポリシーにプリンシパルを追加するをご覧ください。

   2. オブジェクトの ACL を変更して、対象となる各ユーザーに個々のオブジェクトの READ 権限を与えます。手順については、ACL の設定をご覧ください。

4. ユーザーにオブジェクトへの特殊な URL を提供します。

   認証によるブラウザでのダウンロードでは、特定の URL エンドポイント経由で Cloud Storage にアクセスします。次の URL を使用します。

   https://storage.cloud.google.com/BUCKET_NAME/OBJECT_NAME

   ここで

   • BUCKET_NAME は、目的のオブジェクトを含むバケットの名前です。例: my-bucket
   • OBJECT_NAME は、目的のオブジェクトの名前です。例: pets/dog.png

   それを表示できるのは適切な ACL または IAM 権限を与えられたユーザーのみであるため、この URL をどのように使用可能にするかは重要ではありません。URL をユーザーに直接送ったり、ウェブページに投稿できます。

グループを使用したアクセスの制御

このシナリオでは、新しいソフトウェアを試すように招待したユーザーなど、特定のユーザーだけがオブジェクトを利用できるようにしたいと考えています。また、多くのユーザーを招待しますが、ユーザーごとに権限を個別に設定することは考えていません。同時に、オブジェクトを公開して招待したお客様にオブジェクトにアクセスするためのリンクを送信するという方法は使用しません。招待されていないユーザーにリンクが送信される危険があるからです。

このシナリオを扱う 1 つの方法は、Google グループを使用することです。グループを作成し、招待したユーザーのみをグループに追加できます。次に、そのグループ全体にオブジェクトへのアクセス権を与えることができます。

ロール	リソース	プリンシパル	説明
ストレージ オブジェクト閲覧者	使用中のバケット	Google グループ	Google グループにバケットに対するストレージ オブジェクト閲覧者のロールを付与すると、Google グループに属するすべての顧客がバケット内のオブジェクトを表示できるようになります。グループ外のユーザーはだれもオブジェクトにアクセスできません。

注: グループを使用してリソースへのアクセスを管理する場合、グループに属することができるメンバーの数を決定するグループのポリシーと制限を把握しておく必要があります。1 つのグループに追加できるユーザー数よりも多くのユーザーを招待する必要がある場合は、ユーザーを認証するサービスを作成し、サービス アカウントによって署名された URL にリダイレクトできます。詳細については、署名付き URL（クエリ文字列認証）をご覧ください。

このシナリオを実装する

1. Google グループを作成し、ユーザーを追加します。手順については、グループの作成をご覧ください。

2. バケットを作成します。手順については、バケットの作成をご覧ください。

3. オブジェクトをバケットにアップロードします。手順については、オブジェクトのアップロードをご覧ください。

4. Google グループにオブジェクトへのアクセス権を与えます。

   • IAM ロール storage.objectViewer を使用すると、バケット内のすべてのオブジェクトへの表示アクセス権限を付与できます。手順については、バケットレベルのポリシーにプリンシパルを追加するをご覧ください。

   • バケットのうち一部のオブジェクトにのみアクセスを許可する場合は、これらの個々のオブジェクトに読み取り ACL を設定します。手順については、ACL の設定をご覧ください。

5. 適切なリクエスト エンドポイントをグループと共有して、オブジェクトへのアクセス先を把握します。

   たとえば、Google Cloud コンソールを使用する場合、URL https://console.cloud.google.com/storage/browser/BUCKET_NAME ではバケット BUCKET_NAME のオブジェクトのリストに移動します。

マネージド フォルダを使用してアクセスを制御する

このシナリオでは、カスタム画像を含む固有のウェブサイトを所有する複数のお客様が存在します。お客様がウェブサイトにのみ画像をアップロードし、他のウェブサイトにはアップロードできないようにする必要があります。お客様がアカウントをキャンセルしたときに、ウェブサイト上の画像への公開アクセスを無効にする必要がありますが、お客様がアカウントを再度有効にした場合に備えて、イメージが削除されることを回避する必要があります。

このシナリオに対処する方法の一つが、マネージド フォルダを使用することによるものです。バケット内に複数のマネージド フォルダを作成し、IAM を使用して、お客様とエンドユーザーの両方による個別のマネージド フォルダへのアクセスを制御できます。

このシナリオを実装する

1. バケットを作成します。

2. 各お客様のウェブサイトのバケットにマネージド フォルダを作成します。

3. マネージド フォルダごとに、お客様にストレージ オブジェクト ユーザー（roles/storage.objectUser）のロールを付与する IAM ポリシーを設定します。これにより、お客様は、マネージド フォルダにオブジェクトをアップロードして、対象のマネージド フォルダからオブジェクトを削除できるようになります。

4. すべてのマネージド フォルダに対して、プリンシパル allUsers にストレージ オブジェクト閲覧者（roles/storage.objectViewer）のロールを付与する IAM ポリシーを設定します。これにより、マネージド フォルダ内のイメージ オブジェクトがすべてのユーザーにとって視認可能になります。

   または、allUsers に storage.objects.get IAM 権限を付与するカスタムロールを付与することもできます。

5. お客様がアカウントをキャンセルしたら、関連するマネージド フォルダに対するストレージ オブジェクト ユーザー（roles/storage.objectUser）のロールをユーザーに付与している IAM ポリシーを削除します。対象のマネージド フォルダ内に存在するオブジェクトへの公開アクセスを無効にするには、ストレージ オブジェクト閲覧者（roles/storage.objectViewer）のロールを allUsers に付与する IAM ポリシーを削除します。