アクセス制御リスト（ACL）

用途

このページでは、アクセス制御リスト（ACL）の概要について説明します。バケットとオブジェクトへのアクセスを制御するための他の方法については、アクセス制御の概要をお読みください。

アクセス制御リストを使用する場合

ほとんどの場合、ACL の使用は避け、バケットに均一なバケットレベルのアクセスを有効にする必要があります。これにより、ACL の使用を防ぐことができます。

  • プロジェクト全体または Cloud Storage 外のリソースには ACL を設定できないため、ACL だけで Google Cloud リソースへのアクセスを制御することはできません。
  • 均一なバケットレベルのアクセスを有効にすると、アクセス制御サーフェスが簡素化され、追加の Google Cloud 機能を使用できるようになります。詳細については、均一なバケットレベルのアクセスを使用する必要がある場合をご覧ください。
  • ドメインで制限された共有の組織のポリシーとカスタム組織のポリシーは、ACL によって付与されたアクセスを防止しないため、意図しないアクセスにつながる可能性があります。
  • プロジェクト レベル以上で IAM 条件が設定されているプロジェクトで ACL を使用すると、予期しない動作やアクセスが発生する可能性があります。

ACL は次のような状況で使用します。

  • バケット内の個々のオブジェクトへのアクセスをカスタマイズする必要がある場合。たとえば、オブジェクトをアップロードしたユーザーに、そのオブジェクトに対しては完全に制御できるアクセス権を与える一方で、バケット内の他のオブジェクトに対してはアクセス権のレベルを低くしたい場合などです。
  • XML API のみを使用している場合、または Amazon S3 との相互運用が必要な場合。

Identity and Access Management（IAM）と ACL は、バケットとオブジェクトへのアクセスを許可するために連動して機能します。つまり、このいずれかのシステムに関連する権限があれば、バケットまたはオブジェクトにアクセスできます。一般に、IAM ポリシーによって付与される権限は ACL に現れず、ACL によって付与される権限は IAM ポリシーに現れません。詳しくは、IAM と ACL の関係をご覧ください。

アクセス制御リストとは

アクセス制御リスト（ACL）とは、バケットとオブジェクトへのアクセス権を持つユーザーと各ユーザーのアクセスのレベルを定義するために使用できるメカニズムです。Cloud Storage では、ACL を個別のバケットやオブジェクトに適用します。各 ACL は、1 つ以上のエントリからなります。どのエントリも、特定のユーザー（またはグループ）が特定の操作を行うことができるようにします。各エントリは、次の 2 つの情報からなります。

  • 権限は、どの操作を行うことができるかを定義します（たとえば、読み取りや書き込み）。

  • スコープ（利用者と呼ばれることもあります）は、指定した操作を誰が行うことができるかを定義します（たとえば、特定のユーザーやユーザー グループ）。

たとえば、あるバケットを、誰でも中にあるオブジェクトにアクセスできる一方、コラボレーターはバケットへのオブジェクト追加とバケットからのオブジェクト削除ができるようにするとします。この場合、ACL は次の 2 つのエントリからなります。

  • 1 つのエントリで、READER 権限をスコープ allUsers に付与します。

  • 別のエントリで、WRITER 権限をコラボレーターのスコープに付与します（この人を指定するには、メールなど、いくつかの方法があります）。

1 つのバケットまたはオブジェクトについて作成できる ACL エントリの最大数は 100 です。エントリのスコープがグループかドメインの場合、そのグループやドメインにどれだけ多くのユーザーが含まれていても、1 つの ACL エントリとしてカウントされます。

ユーザーがバケットまたはオブジェクトへのアクセスを要求すると、Cloud Storage システムはバケットまたはオブジェクトの ACL を読み取り、アクセス リクエストを許可するか拒否するかを決定します。要求されたオペレーションに対するユーザー権限が ACL で付与されている場合、リクエストは許可されます。要求されたオペレーションに対するユーザー権限が ACL で付与されていない場合、リクエストは失敗し、403 Forbidden エラーが返されます。

ACL を使うとバケットとオブジェクトに関係するほとんどの操作を管理できますが、バケットを作成する機能は、適切なプロジェクト権限の有無によって決まります。

権限

権限は、特定のオブジェクトやバケットに対して何を実行できるかを表します。

Cloud Storage では、次の表に示すように、バケットやオブジェクトに対して同心円状の権限を割り当てることができます。

バケット オブジェクト
READER バケットの内容を一覧表示することをユーザーに許可します。また、ACL を除くバケットのメタデータを読み取ることをユーザーに許可します。 オブジェクトのデータをダウンロードすることをユーザーに許可します。
WRITER READER 権限によって付与されたすべてのアクセス権をユーザーに付与します。また、マルチパート アップロードを使用したオブジェクトの作成を含め、バケット内でのオブジェクトの作成、置換、削除をユーザーに許可します。 該当なし。この権限はオブジェクトに適用できません。
OWNER WRITER 権限によって付与されたすべてのアクセス権をユーザーに付与します。また、ACL を含むバケットのメタデータの読み書きや、バケットのタグの操作をユーザーに許可します。 READER 権限によって付与されたすべてのアクセス権をユーザーに付与します。また、ACL を含むオブジェクトのメタデータの読み書きをユーザーに許可します。
デフォルト バケットが作成されるときに、定義済みの project-private ACL が適用されます。バケットは、常に project-owners グループによって所有されます。 オブジェクトがアップロードされるときに、定義済みの project-private ACL が適用されます。オブジェクトは、オブジェクトをアップロードしたリクエスト元によって常に所有されます。

このページでは、一般に権限を READER、WRITER、OWNER と呼びます。JSON API と Google Cloud コンソールで、権限はこのように指定されています。XML API を使用している場合、これらに相当する権限はそれぞれ READ、WRITE、FULL_CONTROL です。

スコープ

スコープは、特定の権限を誰に付与するのかを指定します。

ACL は 1 つまたは複数のエントリで構成されており、それぞれのエントリは特定のスコープに権限を付与します。次のいずれかのエンティティを使って ACL のスコープを指定できます。

スコープ（「利用者」） エンティティの種類 例
すべてのエンティティを指す特別な ID ユーザー allUsers
すべての有効なアカウントを指す特別な ID ユーザー allAuthenticatedUsers
ユーザー アカウントのメールアドレス ユーザー collaborator@gmail.com
Google グループのメールアドレス グループ work-group@googlegroups.com
プロジェクトのコンビニエンス値 プロジェクト owners-123456789012
Google Workspace ドメイン ドメイン USERNAME@YOUR_DOMAIN.com
Cloud Identity ドメイン ドメイン USERNAME@YOUR_DOMAIN.com
Workforce Identity プール内の単一の ID プリンシパル //iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com
グループ内のすべての Workforce ID PrincipalSet //iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

  • すべてのエンティティを指す特別な ID:

    特別なスコープ ID allUsers は、インターネット上の任意のエンティティを表します。この ID は User エンティティ タイプですが、Google Cloud コンソールを使用する場合は Public エンティティ タイプとしてラベル付けされます。

  • 有効なすべてのアカウントを指す特別な ID:

    特別なスコープ ID allAuthenticatedUsers は、サービス アカウントを含むほとんどの認証済みアカウントを表します。詳しくは IAM の概要をご覧ください。この ID は User エンティティ タイプですが、Google Cloud コンソールを使用する場合は Public エンティティ タイプとしてラベル付けされます。

  • ユーザー アカウントのメールアドレス:

    ユーザー アカウントを所有しているすべてのユーザーは、そのアカウントに固有のメールアドレスを関連付けているはずです。ユーザー アカウントに関連付けられているメールアドレスを使用して、スコープを指定できます。

    Cloud Storage では、メールアドレスが ACL に追加されたときから、エントリが削除されるか置き換えられるまでの間、メールアドレスを保存します。ユーザーがメールアドレスを変更した場合は、ACL エントリを更新してこれらの変更を反映する必要があります。

  • Google グループのメールアドレス

    各 Google グループには、そのグループに関連付けられた固有のメールアドレスがあります。たとえば、Cloud Storage Announce グループには gs-announce@googlegroups.com というメールアドレスがあります。Google グループに関連付けられているメールアドレスは、各 Google グループのホームページで [情報] をクリックすると確認できます。

    ユーザー アカウントのメールアドレスと同様に、Cloud Storage では、メールアドレスが ACL に追加されたときから、エントリが削除されるまでの間、グループのメールアドレスを保存します。Google グループのメールアドレスは永続的で変更されることがないため、Google グループのメールアドレスの更新については心配する必要はありません。

  • プロジェクトのコンビニエンス値

    コンビニエンス値を使用すると、プロジェクトの閲覧者、編集者、オーナーに一括でアクセス権を付与できます。コンビニエンス値は、プロジェクトのロールと関連するプロジェクト番号を組み合わせたものです。たとえば、プロジェクト 867489160491 では、編集者は editors-867489160491 として識別されます。プロジェクト番号は、Google Cloud Console のトップページで確認できます。

    通常、コンビニエンス値は本番環境で使用しないでください。使用すると、基本ロールを付与する必要が生じ、本番環境では推奨されません。

  • Google Workspace または Cloud Identity:

    Google Workspace と Cloud Identity のユーザーは、メール アカウントをインターネット ドメイン名に関連付けることができます。関連付ける際に、各メール アカウントは USERNAME@YOUR_DOMAIN.com の形式をとります。Google Workspace または Cloud Identity に関連付けられているインターネット ドメイン名を使用してスコープを指定できます。

  • Workforce Identity:

    Workforce Identity 連携では、外部 ID プロバイダ（IdP）を使用して IAM でユーザー グループの認証と認可を行い、ユーザーが Google Cloud サービスにアクセスできるようにします。

同心円状の権限とスコープ

Cloud Storage で ACL を指定するとき、複数の権限を付与するために複数のスコープを指定する必要はありません。Cloud Storage は、同心円状の権限を使用するため、WRITER 権限を付与すると READER 権限も付与することになり、OWNER 権限を付与すると、READER 権限と WRITER 権限も付与することになります。

ほとんどのツールで、ACL を指定する際に同じエントリに複数のスコープを指定できます。最も制限の緩い権限は、スコープに付与されるアクセス権です。たとえば、1 人のユーザーにあるバケットに対する READER 権限と WRITER 権限の 2 つのエントリを指定した場合、ユーザーはバケットに対して WRITER 権限を持つことになります。

XML API では、同じスコープを使用して 2 つの ACL エントリを指定することはできません。たとえば、1 つのバケットに対してユーザーに READ 権限と WRITE 権限を付与するとエラーになります。代わりに、ユーザーに WRITE 権限を付与することで、READ 権限も付与されます。

定義済み ACL

定義済み ACL（規定 ACL）は、多数の ACL エントリをバケットまたはオブジェクトに一度に簡単に適用するのに使用できる、特殊な ACL エントリのセットの別名です。

以下の表に、定義済み ACL と、各定義済み ACL エントリに適用される ACL エントリを示します。以下の表を使用するときには、次の点に注意してください。

  • プロジェクト オーナー グループはプロジェクト内のバケットの所有権を持ち、オブジェクトを作成するユーザーは、そのオブジェクトの所有権を持ちます。オブジェクトが匿名ユーザーによって作成された場合は、プロジェクトのオーナー グループがオブジェクトの所有権を持ちます。

  • 表中では JSON API での権限の記述 OWNER、WRITER、READER が使われています。XML API での同等のスコープは FULL_CONTROL、WRITE、READ です。

    JSON API / gcloud storage XML API 説明
    private private バケットまたはオブジェクトのオーナーに、バケットまたはオブジェクトに対する OWNER 権限を付与します。
    bucketOwnerRead bucket-owner-read オブジェクト オーナーに OWNER 権限を付与し、バケット オーナーに READER 権限を付与します。これはオブジェクトでのみ使用できます。
    bucketOwnerFullControl bucket-owner-full-control オブジェクトとバケットのオーナーに OWNER 権限を付与します。これはオブジェクトでのみ使用できます。
    projectPrivate project-private プロジェクト チームでの役割に基づいてチームメンバーに権限を付与します。すべてのチームメンバーは READER 権限を持ちます。プロジェクト オーナーとプロジェクト編集者は OWNER 権限を持ちます。これは、新しく作成されたバケットのデフォルト ACL です。また、そのバケットのデフォルト オブジェクト ACL が変更されない限り、新しく作成されたオブジェクトのデフォルト ACL でもあります。
    authenticatedRead authenticated-read バケットまたはオブジェクトのオーナーに OWNER 権限を付与し、すべての認証済みのユーザー アカウント所有者に READER 権限を付与します。
    publicRead public-read バケットまたはオブジェクトのオーナーに OWNER 権限を付与し、すべてのユーザー（認証済みユーザーと匿名ユーザーの両方）に READER 権限を付与します。オブジェクトにこれを適用すると、インターネット上の誰でも認証を行わずにこのオブジェクトを読み取ることができます。バケットにこれを適用すると、インターネット上の誰でも認証を行わずにオブジェクトを一覧表示できます。

    * 表の最後にあるキャッシュについての注意をご覧ください。
    publicReadWrite public-read-write バケットのオーナーに OWNER 権限を付与し、すべてのユーザー（認証済みユーザーと匿名ユーザーの両方）に READER 権限と WRITER 権限を付与します。この ACL はバケットにのみ適用できます。バケットにこれを適用すると、インターネット上の誰でも認証を行わずにオブジェクトの一覧表示、作成、置き換え、削除を行うことができます。

    * 表の最後にあるキャッシュについての注意をご覧ください。

* デフォルトでは、一般公開されたオブジェクトは Cache-Control ヘッダー付きで提供され、オブジェクトは 3,600 秒間キャッシュに保存されます。更新がすぐに表示されるようにするには、Cache-Control:private, max-age=0, no-transform にオブジェクトの Cache-Control メタデータを設定する必要があります。

デフォルト ACL

バケットを作成するかオブジェクトをアップロードするときに、ACL を明示的に指定しないと、デフォルト ACL が設定されます。オブジェクトに設定されるデフォルト ACL は変更可能です。その方法については、デフォルト オブジェクト ALC の変更をご覧ください。デフォルトの ACL を変更しても、バケットにすでに存在するオブジェクトの ACL やプロジェクトにすでに存在するバケットの ACL は変更されません。

デフォルト バケット ACL

すべてのバケットはプロジェクト オーナー グループによって所有されます。また、プロジェクト オーナーには、定義済み ACL を使用するプロジェクト内部の任意のバケットに対する OWNER 権限が付与されます。

デフォルト バケット ACL でバケットを作成する場合（つまり、バケット作成時に定義済み ACL を指定しない場合）、そのバケットには定義済みの projectPrivate ACL が適用されます。

デフォルト オブジェクト ACL

デフォルトでは、バケットに対して OWNER 権限または WRITER 権限を持っているすべてのユーザーがそのバケットにオブジェクトをアップロードできます。オブジェクトをアップロードする際に、定義済み ACL を指定するか、ACL をまったく指定しないかを選択できます。ACL を指定しない場合は、バケットのデフォルト オブジェクト ACL が Cloud Storage によってそのオブジェクトに適用されます。すべてのバケットにはデフォルト オブジェクト ACL があります。この ACL は、そのバケットにアップロードされたオブジェクトのうち、定義済み ACL がないか、リクエストで ACL が指定されていないもの（JSON API のみ）すべてに適用されます。すべてのバケットのデフォルト オブジェクト ACL の初期値は projectPrivate です。

オブジェクト ACL は、オブジェクトのアップロード方法に応じて適用されます。

  • 認証済みアップロード

    オブジェクトをアップロードするための認証済みリクエストを送信し、アップロード時にオブジェクト ACL を指定しない場合は、オブジェクトの所有者としてリストに追加され、定義済み projectPrivate ACL がデフォルトでオブジェクトに適用されます。これは次のことを意味します。

    • オブジェクトをアップロードしたユーザーはオブジェクト オーナーとしてリストに追加されます。オブジェクトの所有権は ACL を変更しても変わることはありません。オブジェクトの所有権を変えられるのは、オブジェクトを置き換えたときだけです。

    • オブジェクト オーナーには、オブジェクトに対する OWNER 権限が付与されます。オーナーに対して OWNER 権限より下の権限を付与しようとした場合でも、Cloud Storage によって自動的に OWNER にエスカレーションされます。

    • プロジェクト オーナーとプロジェクト編集者グループには、オブジェクトに対する OWNER 権限が付与されます。

    • プロジェクト チームメンバー グループには、オブジェクトに対する READER 権限が付与されます。

  • 匿名アップロード

    認証されていない（匿名の）ユーザーがオブジェクトをアップロードした場合（これは、バケットが allUsers グループに WRITER 権限か OWNER 権限を付与している場合に起こる可能性があります）、前述のようにデフォルト バケット ACL がオブジェクトに適用されます。

    匿名ユーザーはオブジェクトのアップロード中に定義済み ACL を指定できません。

ACL の動作

Cloud Storage は、データにアクセスできなくなるような ACL の設定を防ぐ ACL 変更ルールをいくつか実施することで、ベスト プラクティスに沿った運用を支援します。

  • バケットまたはオブジェクトのオーナーを変更する ACL は適用できません。

    バケットやオブジェクトのオーナーは、ACL を変更して更新することはできません。バケットまたはオブジェクトに新しい ACL を適用する場合、バケットまたはオブジェクトのオーナーが新しい ACL でも同じであることを確認してください。

  • バケットまたはオブジェクトのオーナーは、バケットまたはオブジェクトの OWNER 権限を常に持ちます。

    バケットのオーナーはプロジェクト オーナー グループであり、オブジェクトのオーナーはオブジェクトをアップロードしたユーザーか、オブジェクトが匿名ユーザーによってアップロードされた場合はプロジェクト オーナー グループです。

    バケットまたはオブジェクトに新しい ACL を適用すると、権限付与を省略した場合、Cloud Storage によって、バケットまたはオブジェクトに対する OWNER 権限がそれぞれ追加されます。プロジェクト オーナー グループにオブジェクトに対する OWNER 権限は付与されないため（オブジェクトが匿名ユーザーによって作成された場合を除く）、明示的に権限を含める必要があります。

バケットまたはオブジェクトの所有権を変更する ACL は適用できません（OWNER 権限と混同しないでください）。Cloud Storage で作成されたバケットとオブジェクトの所有権は永続的です。しかし、オブジェクト（バケットではありません）を置き換えることで、所有権を事実上変更できます。置き換えは、基本的に、削除オペレーションを行い、その直後にアップロード オペレーションを行うことです。アップロード中、アップロードを行ったユーザーがオブジェクトのオーナーになります。オブジェクトを置き換えるには、置き換えを行う人（また、そうすることでオブジェクトの所有権を得る人）は、オブジェクトをアップロードするバケットに対する WRITER 権限か OWNER 権限を持っている必要があるのでご注意ください。

次のステップ