アクセス制御リスト（ACL） (original) (raw)

使用方法

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

アクセス制御リストを使用すべきか

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

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

アクセス制御リストとは

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

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

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
ユーザー アカウントのメールアドレス ユーザー jeffersonloveshiking@gmail.com
サービス アカウントのメールアドレス ユーザー my-service-account@my-project.iam.gserviceaccount.com
Google グループのメールアドレス グループ work-group@googlegroups.com
プロジェクトのコンビニエンス値 プロジェクト owners-123456789012
Google Workspace ドメイン ドメイン dana@example.com
Cloud Identity ドメイン ドメイン dana@example.com

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

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 と IAM

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

IAM 拒否での動作

拒否ポリシーと ACL が同じ権限をターゲットとしている場合、IAM 拒否ポリシーは、設定した ACL によって付与されるアクセス権をオーバーライドします。

たとえば、バケットにユーザーが storage.objects.get 権限を取得できない拒否ポリシーがあり、バケット内のオブジェクトに対する READER ロールをユーザーに付与する ACL を作成した場合、ユーザーはバケット内のオブジェクトを表示できません。ただし、拒否ポリシーで storage.buckets.get 権限が指定され、ACL でバケットに対する WRITER ロールが付与されている場合、ユーザーはバケットのメタデータを取得できませんが、バケットでオブジェクトの一覧取得、作成、削除を行うことができます。

定義済み ACL

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

以下の表に、定義済み ACL と、各定義済み ACL エントリに適用される 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 の動作

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

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

次のステップ