Cloud Identity and Access Management

サンプルに移動

ここでは、Cloud Identity and Access Management(Cloud IAM)の概要と、Cloud IAM を使用して Cloud Storage 内のバケットとオブジェクトへのアクセスを制御する仕組みについて説明します。バケットとオブジェクトへのアクセスを制御するその他の方法については、アクセス制御の概要をご覧ください。

このページでは、特に Cloud Storage に関連する Cloud IAM の側面について説明します。Cloud IAM とその機能の詳細については、Cloud Identity and Access Management をご覧ください。特に、Cloud IAM ポリシーの管理に関するセクションをご覧ください。

概要

Cloud Identity and Access Management(Cloud IAM)を使用して、Google Cloud プロジェクトのリソースにアクセスできるユーザーを制御します。リソースには、Cloud Storage のバケットやバケット内に保存されているオブジェクトのほか、Compute Engine インスタンスなどの Google Cloud エンティティが含まれます。

リソースに適用される一連のアクセスルールは、「Cloud IAM ポリシー」と呼ばれます。プロジェクトに適用される Cloud IAM ポリシーは、ユーザーがプロジェクト内のすべてのオブジェクトまたはバケットに対して行うことができる操作を定義します。特定のバケットに適用される Cloud IAM ポリシーは、ユーザーがその特定のバケットとその中のオブジェクトに対して行うことができる操作を定義します。

たとえば、いずれか 1 つのバケットに対する Cloud IAM ポリシーを作成して、ある特定のユーザーにそのバケットの管理権限を付与できます。その一方で、別のユーザーをプロジェクト全体の Cloud IAM ポリシーに追加し、そのユーザーにプロジェクトのすべてのバケット内にあるオブジェクトの表示権限を付与できます。

Cloud IAM でのメンバーとは「誰」であるかを指します。メンバーは個々のユーザー、グループ、ドメイン、さらには一般大衆であることもあります。メンバーにはロールが割り当てられ、そのロールによってメンバーに Cloud Storage、および Google Cloud 全般での操作を実行する権限が付与されます。各ロールは、1 つ以上の権限をまとめたものです。権限は Cloud IAM の基本単位であり、各権限により、特定の操作の実行が許可されます。

たとえば、storage.objects.create 権限ではオブジェクトを作成できます。この権限は、Storage オブジェクト作成者(権限はこれのみ)やStorage オブジェクト管理者(多数の権限がまとめられている)などのロールに含まれています。特定のバケットのメンバーに Storage オブジェクト作成者のロールを付与した場合、メンバーはそのバケットのみでオブジェクトを作成できます。そのバケットの別のメンバーにStorage オブジェクト管理者のロールを付与した場合、そのメンバーはオブジェクトの削除などの追加タスクを行うことができますが、そのバケット内に限られます。この 2 名のユーザーに割り当てたロールが上記のみであれば、彼らはプロジェクト内の他のバケットについて知ることはできません。3 番目のメンバーに、1 つのバケットだけでなくプロジェクトに対するStorage オブジェクト管理者のロールを割り当てると、このメンバーはプロジェクト内のどのバケットにもアクセスできるようになります。

Cloud Storage で Cloud IAM を使用すると、バケットやオブジェクトに対する権限を個別に変更することなく、メンバーの権限を簡単に制限できます。

権限

権限は、Cloud Storage のバケットやオブジェクトに特定の操作を行うことをメンバーに許可します。たとえば、storage.buckets.list 権限を持つメンバーはプロジェクト内のバケットを一覧表示できます。メンバーには権限を直接付与するのではなく、ロールを割り当てます。ロールには、1 つ以上の権限が割り当てられます。

Cloud Storage に適用される Cloud IAM 権限の参照リストについては、Cloud Storage に適用される Cloud IAM 権限をご覧ください。

ロール

ロールは、1 つ以上の権限をまとめたものです。たとえば、Storage オブジェクト閲覧者のロールには、権限 storage.objects.getstorage.objects.list が含まれています。ロールをメンバーに割り当てることで、プロジェクト内のバケットとオブジェクトに対する操作を実行できるようになります。

Cloud Storage に適用される Cloud IAM ロールの参照リストについては、Cloud Storage に適用される Cloud IAM ロールをご覧ください。

プロジェクト レベルのロールとバケットレベルのロール

バケットレベルでロールを付与しても、プロジェクト レベルで付与した既存のロールに影響はありません。また、その逆も同様です。この 2 つのレベルを使用して、権限をきめ細かくカスタマイズできます。たとえば、オブジェクトの読み取りはすべてのバケットで許可し、オブジェクトの作成は特定のバケットでのみ許可するような設定ができます。これを行うには、プロジェクト レベルで Storage オブジェクト閲覧者のロールを付与して、そのユーザーにプロジェクトのすべてのバケットに保存されているすべてのオブジェクトの読み取りを許可し、さらにこのユーザーに特定のバケットについてバケットレベルで Storage オブジェクト作成者のロールを付与します。これにより、ユーザーはそのバケットにのみオブジェクトを作成できます。

一部のロールはプロジェクト レベルとバケットレベルの両方で使用できます。プロジェクト レベルで使用する場合、ロールに含まれる権限はプロジェクト内のすべてのバケットとオブジェクトに適用されます。バケットレベルで使用する場合、権限は特定のバケットとその中のオブジェクトにのみ適用されます。このようなロールとしては、Storage 管理者Storage オブジェクト閲覧者Storage オブジェクト作成者などがあります。

一部のロールは 1 つのレベルでのみ適用できます。たとえば、閲覧者のロールはプロジェクト レベルでのみ適用でき、Storage レガシー オブジェクト オーナーのロールはバケットレベルでのみ適用できます。

ACL との関係

レガシー バケットの Cloud IAM ロールはバケットの ACL と連動して機能します。レガシー バケットのロールを追加、削除すると、バケットに関連する ACL にも変更が反映されます。同様に、バケット固有の ACL を変更すると、バケットに対応するレガシー バケットのロールも更新されます。

レガシー バケットのロール 同等の ACL
Storage レガシー バケット読み取り バケット読み取り
Storage レガシー バケット書き込み バケット書き込み
Storage レガシー バケット オーナー バケット オーナー

これ以外のバケットレベルの Cloud IAM ロールとすべてのプロジェクト レベルの Cloud IAM ロールは、ACL からは独立して機能します。たとえば、ユーザーにStorage オブジェクト閲覧者のロールを設定しても、ACL は変更されません。つまり、バケットレベルの Cloud IAM ロールを使用してバケット内のすべてのオブジェクトに対するアクセスを許可したうえで、きめ細かいオブジェクト ACL を使用してバケット内の特定のオブジェクトに対するアクセスをカスタマイズできます。

ACL を変更するための Cloud IAM 権限

Cloud IAM を使用して、オブジェクトの ACL を変更するために必要な権限をメンバーに付与できます。.get.getIamPolicy.setIamPolicy.update の各 storage.buckets 権限を合わせて付与することで、ユーザーはバケット ACL とデフォルトのオブジェクト ACL を操作できます。

同様に、.get.getIamPolicy.setIamPolicy.update の各 storage.objects 権限を合わせて付与することで、ユーザーはオブジェクト ACL を操作できます。

カスタムロール

Cloud IAM には一般的なユースケースをカバーする数多くのロールが事前定義されていますが、場合によっては、自分で指定した一連の権限が含まれた、独自のロールを定義することが必要になります。これをサポートするために、Cloud IAM にはカスタムロールが用意されています。

メンバーのタイプ

メンバーにはいくつかのタイプがあります。たとえば、Google アカウントと Google グループの 2 つは一般的なタイプであり、allAuthenticatedUsersallUsers の 2 つは特別なタイプです。Cloud IAM の一般的なメンバータイプのリストについては、ID に関するコンセプトをご覧ください。そのリストに記載されているタイプに加え、Cloud IAM では次のメンバータイプをサポートしています。これらのメンバータイプは、Cloud Storage バケットの Cloud IAM ポリシーにのみ適用できます。

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

ここで、[PROJECT_ID] は特定のプロジェクトの ID です。

上記のメンバータイプのいずれかにロールを付与すると、指定したプロジェクトに対して指定された権限を持つすべてのメンバーが、選択されたロールを取得します。たとえば、プロジェクト my-example-project閲覧者のロールを持つすべてのメンバーに、いずれかのバケットの Storage オブジェクト作成者のロールを付与するとします。そのためには、メンバー projectViewer:my-example-project にそのバケットの Storage オブジェクト作成者のロールを付与します。

Conditions

Cloud IAM Conditions では、メンバーへの権限の付与方法を制御する条件を設定できます。Cloud Storage では、次のタイプの条件属性がサポートされています。

  • resource.name: 指定された接頭辞を持つバケットやオブジェクトへのアクセス権を付与します。また、resource.type を使用してバケットまたはオブジェクトへのアクセス権を付与することもできますが、resource.name を使用すればほとんどの場合、これは不要です。
    resource.name.startsWith('projects/_/buckets/[BUCKET_NAME]/objects/[OBJECT_PREFIX]')
  • 日時: 権限の有効期限を設定します。
    request.time < timestamp('2019-01-01T00:00:00Z')

これらの条件式は、Common Expression Language(CEL)のサブセットを使用する論理ステートメントです。バケットの Cloud IAM ポリシーのロール バインディングで条件を指定します。

次の制限事項にご注意ください。

  • バケットレベルで条件を追加する前に、バケットに対して均一なバケットレベルのアクセスを有効にする必要があります。プロジェクト レベルでの条件は許可されますが、Cloud Storage ACL によってプロジェクト レベルの Cloud IAM 条件がオーバーライドされないように、プロジェクト内のすべてのバケットを均一なバケットレベルのアクセスに移行する必要があります。均一なバケットレベルのアクセスの制約を適用して、プロジェクト内のすべての新しいバケットに対して均一なバケットレベルのアクセスを有効にできます。
  • gsutil iam ch コマンドは、条件を含むポリシーでは機能しません。条件を含むポリシーを変更するには、gsutil iam get を使用して関連バケットのポリシーを取得し、ローカルで編集してから、gsutil iam set を使用してバケットに再度適用します。
  • 条件を使用するには、gsutil のバージョンを 4.38 以降にする必要があります。
  • JSON API を使用して、条件付きバケットに対して getIamPolicysetIamPolicy を呼び出す場合は、Cloud IAM ポリシーのバージョンを 3 に設定する必要があります。
  • 期限切れの条件は、削除するまで Cloud IAM ポリシーに残ります。

Cloud Storage ツールでの使用

Cloud IAM の権限を XML API によって設定することはできませんが、Cloud IAM の権限を付与されたユーザーは XML API を使用でき、Cloud Storage へのアクセスのために他のあらゆるツールを使用することもできます。

さまざまな Cloud Storage ツールを使用した操作をユーザーに許可する Cloud IAM 権限については、Cloud Console での Cloud IAMgsutil での Cloud IAMJSON での Cloud IAMXML での Cloud IAM をご覧ください。

ベスト プラクティス

Cloud IAM を使用するには、他の管理設定と同様、アクティブ管理を有効にする必要があります。バケットやオブジェクトに他のユーザーがアクセスできるようにする前に、バケットやオブジェクトを誰と共有するか確認してください。また、誰にどのようなロールを与えるかも確認する必要があります。プロジェクト管理、使用パターン、組織の所有権が次第に変動し、バケットやプロジェクトの Cloud IAM 設定の変更が必要になる場合があります。特に、大規模な組織や大人数のグループで Cloud Storage を管理している場合はその可能性が高くなります。アクセス制御設定の評価や計画を行う際には、次のおすすめの方法を念頭に置いてください。

  • アクセス権を付与する際は、最小権限を与えることを原則にします。

    最小権限の原則は、リソースへのアクセス権を付与するためのセキュリティ ガイドラインです。最小権限の原則に基づいてアクセス権を付与する場合、割り当てられたタスクを実行するために必要なアクセス権のみをユーザーに付与します。たとえば、他のユーザーとファイルを共有する場合は、storage.admin ロールではなく storage.objectReader ロールを付与する必要があります。

  • 自分が知らないユーザーに setIamPolicy の権限を付与しないようにしてください。

    setIamPolicy 権限が付与されたユーザーは、権限を変更してデータを制御できます。setIamPolicy 権限があるロールは、オブジェクトに対する管理権限を委任する場合のみ使用します。

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

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

  • Cloud Storage での閲覧者 / 編集者 / オーナーの基本ロールについて

    閲覧者 / 編集者 / オーナーの各基本ロールを付与すると、Cloud Storage 内で、その名前が表すアクセス権が実質的に付与されます。ただし、この処理は、Cloud Storage に固有のメンバータイプを使用して、バケットレベルとオブジェクト レベルで提供される追加アクセス権を介して間接的に行われます。アクセス権はデフォルトで追加されますが、取り消すこともできます。

    たとえば、閲覧者のロールでは、メンバーはバケットを一覧表示できますが、バケットやオブジェクトを閲覧することはできません。ただし、

    • 閲覧者のロールを持つメンバーは通常、プロジェクト内の各バケットに対する Storage レガシー バケット読み取りのロールとその権限を取得します。新しいバケットを作成する場合、Cloud Storage に対するデフォルトの動作は、新しいバケットに対する Storage レガシー バケット読み取りのロールを閲覧者基本ロールに付与することであるためです。したがって、プロジェクトの閲覧者基本ロールを持つすべてのメンバーに、新しいバケットに対する Storage レガシー バケット読み取りも付与されます。この動作により、閲覧者のロールを持つメンバーがバケットを閲覧できます。

    • バケットには projectPrivate のデフォルト オブジェクト ACL があります。つまり、バケットに追加されたオブジェクトはデフォルトで projectPrivate ACL を取得します。この ACL により、閲覧者のロールを持つメンバーがオブジェクトを閲覧できます。

    同様に、編集者オーナーの基本ロールは、Cloud Storage へのアクセスが制限されていますが、これらのロールが割り当てられたメンバーは、新しいバケットに対するStorage レガシー バケット オーナーと、projectPrivate ACL を介したオブジェクトの所有権を取得します。

    バケットとオブジェクトへのアクセス権の一部は閲覧者 / 編集者 / オーナーの基本ロールに固有ではないため、メンバー自身はあると予想していたアクセス権を取り消すことができるのでご注意ください。

  • オブジェクトやバケットにアクセスできなくなるような権限の設定を避けます。

    バケットやオブジェクトは、それを読み取る権限を持つユーザーがいない場合、アクセス不能になります。バケットの場合、バケットのすべての Cloud IAM 権限を削除すると、このような状況が発生する可能性があります。オブジェクトの場合、オブジェクトのオーナーがプロジェクトを離れ、オブジェクトへのアクセスを許可するバケットレベルまたはプロジェクト レベルの Cloud IAM ポリシーが存在しないと、このような状況が発生します。どちらの場合も、Storage 管理者などの適切なロールを自分や他のメンバーにプロジェクトレベルで割り当てることで、アクセスを回復できます。 この操作を行うと、プロジェクト内のすべてのバケットやオブジェクトへのアクセスが許可されます。このため、対象のバケットやオブジェクトへのアクセス権をリセットした後で、ロールの取り消しが必要になる場合があります。

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

    デフォルトでは、プロジェクト レベルのオーナーのロールを持つメンバーが、新しく作成されたバケットに対するStorage レガシー バケット オーナーのロールを持つ唯一のエンティティです。チームメンバーがグループを離れても他のメンバーがバケットを管理できるように、オーナーのロールを持つメンバーが常に 2 人以上いるようにする必要があります。

次のステップ