アクセス制御リスト(ACL)

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

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

通常は、Cloud Identity & Access Management(Cloud IAM) を使用してリソースへのアクセスを制御することをおすすめします。Cloud IAM と ACL は、バケットとオブジェクトへのアクセスを許可するために連動して機能します。ユーザーは IAM または ACL のいずれかの権限があれば、バケットまたはオブジェクトにアクセスできます。

バケット内の個々のオブジェクトへのアクセス権をカスタマイズしなければならない場合は、ACL の使用が必要になる可能性が高くなります。Cloud IAM 権限はバケット内のすべてのオブジェクトに適用されるため、このような場合には適していません。ただしその場合でも、バケット内のすべてのオブジェクトに共通するアクセス権については Cloud IAM を使用することをおすすめします。これにより、人手の必要な細かい管理作業の量が軽減されます。

アクセス制御リストとは

アクセス制御リスト(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 バケット内のオブジェクトを一覧表示、作成、上書き、削除することをユーザーに許可します 1 該当なし。この権限はオブジェクトに適用できません。
OWNER バケットに対する READER 権限と WRITER 権限をユーザーに付与します。また、ACL を含むバケットのメタデータを読み書きすることをユーザーに許可します。 ユーザーに READER アクセスを許可します。また、ACL を含むオブジェクトのメタデータを読み書きすることをユーザーに許可します。
デフォルト バケットが作成されるときに、定義済みの project-private ACL が適用されます。バケットは、常に project-owners グループによって所有されます。 オブジェクトがアップロードされるときに、定義済みの project-private ACL が適用されます。オブジェクトは、オブジェクトをアップロードしたリクエスト元によって常に所有されます。

1 バケットのメタデータ プロパティ aclcorsdefaultObjectAcllifecycleloggingversioningwebsite は変更できません。

このページでは、一般に権限を READERWRITEROWNER と呼びます。JSON APIGoogle Cloud Platform Console では、権限はこのように指定されています。XML API を使用している場合、これらに相当する権限はそれぞれ READWRITEFULL_CONTROL です。ユーザーに代わって Google Cloud Storage API にアクセスするために、OAuth 2.0 認証を使用してツールとアプリケーションを認証する(権限を付与する)場合は、OAuth スコープ devstorage.read_onlydevstorage.read_writedevstorage.full_control によってアクセスが制限されます。次の表では、一般的に使われる権限の用語をまとめています。

JSON API XML API OAuth2 スコープ
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

スコープ

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

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

スコープ(「利用者」) エンティティの種類
Google アカウントのメールアドレス ユーザー collaborator@gmail.com
Google グループのメールアドレス グループ work-group@googlegroups.com
プロジェクトのコンビニエンス値 プロジェクト owners-123456789012
G Suite ドメイン ドメイン [USERNAME]@[YOUR_DOMAIN].com
Cloud Identity ドメイン ドメイン [USERNAME]@[YOUR_DOMAIN].com
すべての Google アカウント所有者の特殊 ID ユーザー allAuthenticatedUsers
すべてのユーザーの特殊 ID ユーザー allUsers
  • Google アカウントのメールアドレス

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

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

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

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

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

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

    コンビニエンス値 owners-<project-number>editors-<project-number>viewers-<project-number> は、プロジェクト番号が <project-number> であるプロジェクトのオーナー、編集者、閲覧者を表します。

  • G Suite または Cloud Identity

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

  • すべての Google アカウント所有者の特殊 ID

    この特殊なスコープ ID は、Google アカウントで認証済みのユーザーを表します。すべての Google アカウント所有者の特殊なスコープ ID は allAuthenticatedUsers です。

  • すべてのユーザーの特殊 ID

    この特殊なスコープ ID は、Google アカウントの有無に関係なくインターネット上のすべてのユーザーを表します。すべてのユーザーの特殊なスコープ ID は allUsers です。

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

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

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

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

定義済み ACL

定義済み ACL(ACL テンプレート)は、特殊な ACL エントリのセットに対する別名です。これを使うことで、バケットやオブジェクトに一度に多数の ACL エントリを簡単に適用できます。定義済み ACL は、オーナー権限を除くすべてのアクセス権を取り消す(定義済み ACL private)、オブジェクトを誰でも読み取り可能にする(定義済み ACL publicRead)など、一般的なシナリオ向けに定義されています。

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

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

  • 表中では JSON API での権限の記述 OWNERWRITERREADER が使われています。XML API での同等のスコープは FULL_CONTROLWRITEREAD です。

    JSON API XML API/gsutil 説明
    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 権限を付与し、すべての認証済み Google アカウント所有者に READER 権限を付与します。他のすべての権限は削除されます。
    publicRead public-read バケットまたはオブジェクトのオーナーに OWNER 権限を付与し、すべてのユーザー(認証済みユーザーと匿名ユーザーの両方)に READER 権限を付与します。オブジェクトにこれを適用すると、インターネット上の誰でも認証を行わずにこのオブジェクトを読み取ることができます。バケットにこれを適用すると、インターネット上の誰でも認証を行わずにオブジェクトを一覧表示できます。

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

    publicReadWrite public-read-write バケットのオーナーに OWNER 権限を付与し、すべてのユーザー(認証済みユーザーと匿名ユーザーの両方)に READER 権限と WRITER 権限を付与します。この ACL はバケットにのみ適用できます。バケットにこれを適用すると、インターネット上の誰でも認証を行わずにオブジェクトの一覧表示、作成、上書き、削除を行うことができます。

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

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

デフォルト ACL

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

デフォルト バケット ACL

すべてのバケットはプロジェクト オーナー グループによって所有されます。プロジェクト オーナーには、各自のプロジェクト内のすべてのバケットに対する OWNER 権限が自動的に付与されます。プロジェクトを作成すると、自動的にプロジェクト オーナーとして追加されます。

デフォルト バケット ACL でバケットを作成する場合(つまり、バケット作成時に定義済み ACL を指定しない場合)、そのバケットには定義済みの projectPrivate ACL が適用されます。この projectPrivate ACL は、プロジェクト チームメンバーの役割に基づいてメンバーに追加権限を付与します。これらの追加権限は次のように定義されます。

  • プロジェクト閲覧者

    projectPrivate ACL は、プロジェクト閲覧者に、プロジェクト内のバケットへの READER アクセス権を付与します。すべてのプロジェクト チームメンバーはバケット内のオブジェクトを一覧表示できます。また、すべてのプロジェクト チームメンバーは、バケット ACL と関係なく、プロジェクト内のバケットを一覧表示できます。

  • プロジェクト編集者

    projectPrivate ACL はプロジェクト内のバケットに対する OWNER 権限をプロジェクト編集者に付与します。プロジェクト編集者はバケットの内容を一覧表示し、バケット内のオブジェクトを作成、上書き、削除できます。また、プロジェクト編集者は、バケット ACL と関係なく、バケットの一覧表示、作成、削除を行うことができます。

  • プロジェクト オーナー

    projectPrivate ACL は、プロジェクト オーナーに OWNER 権限を付与します。また、プロジェクト オーナーは、プロジェクト編集者が実行できるすべてのタスクと、複数の管理タスク(チームメンバーの追加と削除、お支払い情報の変更など)を実行できます。

プロジェクト閲覧者、プロジェクト編集者、プロジェクト オーナーは、役割と関連するプロジェクト番号を組み合わせることによって識別されます。たとえば、プロジェクト 867489160491 では、編集者は project-editors-867489160491 として識別されます。プロジェクト番号は Google Cloud Platform Console のトップページで確認できます。

デフォルト オブジェクト 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 は他の管理設定と同様、アクティブ管理を有効にしておく必要があります。バケットやオブジェクトに他のユーザーがアクセスできるようにする前に、バケットやオブジェクトを誰と共有するか確認してください。また、誰にどのような役割を与えるかも確認する必要があります。時間が経過するとともに、プロジェクト管理、使用パターン、組織内のオーナーの変化により、バケットやオブジェクトの ACL 設定を変更しなければならないことがあります。特に、大規模な組織や大人数のグループでバケットやオブジェクトを管理している場合はその可能性が高くなります。アクセス制御設定の評価や計画を行う際には、次のベスト プラクティスを念頭に置いてください。

  • 自分のバケットやオブジェクトにアクセス権限を付与する際は、最小権限を与えることを原則にします。

    最小権限の原則は、権限を付与する際の安全ガイドラインです。最小権限の原則を基にアクセス権を付与すると、ユーザーが割り当てられたタスクを行うために必要な、最小限の権限を付与することができます。たとえば、誰かとファイルを共有したい場合は、OWNER 権限ではなく READER 権限を付与します。

  • 知らない人に OWNER 権限を付与することは避けます。

    OWNER 権限を付与されたユーザーは、ACL を変更しデータの制御権を奪うことができます。OWNER 権限の付与は、オブジェクトやバケットに対する管理権限を委任する場合だけにします。

  • 匿名ユーザーへの権限の付与は慎重に行います。

    allUsersallAuthenticatedUsers のスコープは、インターネット上の誰もがデータの読み取りと分析を行えることを許容できる場合のみ使用します。これらのスコープは一部のアプリケーションとシナリオで有用ですが、すべてのユーザーに OWNER 権限を許可することは、一般におすすめできません。

  • オブジェクトにアクセスできなくなるような ACL の設定を避けます。

    アクセスできないオブジェクトは、ダウンロード(読み取り)できないオブジェクトで、削除することしかできません。これが起きるのは、オブジェクトのオーナーが、他の誰にもオブジェクトに対する OWNER 権限や READER 権限を許可しない状態のままにした場合です。この問題を避けるために、自分または他のユーザーがオブジェクトをバケットにアップロードする際に、定義済み ACL、bucket-owner-read または bucket-owner-full- control を使用することができます。

  • バケットの管理権限を委任してください。

    デフォルトでは、プロジェクト オーナー グループは、バケットの作成時にバケットの OWNER 権限を所有している唯一のエンティティです。チームメンバーがグループを離れても他のプロジェクト オーナーがバケットを管理できるように、プロジェクト オーナー グループにはいつでも 2 人以上のメンバーがいるようにする必要があります。

  • Cloud Storage の相互運用性に注意してください。

    Amazon S3 などの他のストレージ サービスとの相互運用アクセスのための XML API を使用する場合、署名 ID によって ACL 構文が決まります。たとえば、使用しているツールやライブラリが ACL の取得を Cloud Storage にリクエストし、そのリクエストで別のストレージ プロバイダの署名 ID が使用されている場合、Cloud Storage は、対応するストレージ プロバイダの ACL 構文を使用した XML ドキュメントを返します。使用しているツールやライブラリが ACL の適用を Cloud Storage にリクエストし、そのリクエストで別のストレージ プロバイダの署名 ID が使用されている場合、Cloud Storage は、対応するストレージ プロバイダの ACL 構文を使用した XML ドキュメントの受信を期待します。

    Amazon S3 との相互運用アクセスのための XML API の詳細な使用方法については、Amazon S3 から Google Cloud Storage への移行を参照してください。

Cloud Storage は、いくつかの ACL 変更ルールを適用し、データにアクセスできなくなるような ACL の設定を防ぐことで、これらのベスト プラクティスに従うのに役立ちます。

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

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

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

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

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

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。