Cloud Identity and Access Management

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

このページでは、特に Cloud Storage に関連する Cloud IAM の側面について説明します。Cloud IAM の詳細と全般的な機能については、Google Cloud Identity and Access Management のデベロッパー ガイドをご覧ください。特に、Cloud IAM ポリシーの管理に関するセクションをご覧ください。

概要

Cloud Identity and Access Management(Cloud IAM)を使用すると、Google Cloud Platform プロジェクト内のリソースへのアクセスを許可するユーザーを制御できます。リソースには、Cloud Storage バケットとバケット内に格納されているオブジェクト、Compute Engine インスタンスなどの他の GCP エンティティなどがあります。

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

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

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

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

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

権限

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

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

役割

役割は、1 つ以上の権限をまとめたものです。たとえば、roles/storage.objectViewer には storage.objects.get および storage.objects.list 権限が含まれています。役割をメンバーに割り当てると、そのメンバーはプロジェクト内のバケットとオブジェクトに対する操作を実行できるようになります。

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

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

バケットレベルで役割を付与しても、プロジェクト レベルで付与した既存の役割に影響はありません。また、その逆も同様です。この 2 つのレベルを使用して、権限をきめ細かくカスタマイズできます。たとえば、あるユーザーに対して、オブジェクトの読み取りをすべてのバケットで許可し、オブジェクトの作成は特定のバケットでのみ許可できます。これを実現するには、ユーザーにプロジェクト レベルで roles/storage.objectViewer の役割を付与して、そのユーザーにプロジェクトのすべてのバケットに保存されているすべてのオブジェクトの読み取りを許可し、さらにこのユーザーに特定のバケットについてバケットレベルで roles/storage.objectCreator の役割を付与して、そのバケットでのみオブジェクトの作成を許可します。

一部の役割はプロジェクト レベルとバケットレベルの両方で使用できます。プロジェクト レベルで使用する場合、役割に含まれる権限はプロジェクト内のすべてのバケットとオブジェクトに適用されます。バケットレベルで使用する場合、権限は特定のバケットとその中のオブジェクトにのみ適用されます。このような役割としては、roles/storage.adminroles/storage.objectViewerroles/storage.objectCreator などがあります。

一部の役割は 1 つのレベルでのみ適用できます。たとえば、Viewer の役割はプロジェクト レベルでのみ適用でき、roles/storage.legacyObjectOwner の役割はバケットレベルでのみ適用できます。

ACL との関係

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

レガシー バケットの役割 同等の ACL
roles/storage.legacyBucketReader バケット読み取り
roles/storage.legacyBucketWriter バケット書き込み
roles/storage.legacyBucketOwner バケット オーナー

これ以外のバケットレベルの Cloud IAM 役割とすべてのプロジェクト レベルの Cloud IAM 役割は、ACL からは独立して機能します。たとえば、ユーザーにストレージ オブジェクト閲覧者の役割を設定しても、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 について Viewer の役割を持つすべてのメンバーに、バケットのいずれかについて roles/storage.objectCreator の役割を付与するとします。そのためには、メンバー projectViewer:my-example-project にそのバケットの roles/storage.objectCreator の役割を渡します。

Cloud Storage ツールでの使用

XML API を使用して Cloud IAM 権限を設定することはできませんが、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 での ViewerEditorOwner のプロジェクトの役割について

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

    たとえば、Viewer の役割自体は、メンバーに storage.buckets.list 権限を付与するだけですが、新しいバケットはデフォルトで roles/storage.legacyBucketReader の役割を、プロジェクトについて の役割を持つすべてのメンバーに付与します。このバケットの役割は、Viewer がバケットを表示できるようにするものです。また、バケットには projectPrivate のデフォルト オブジェクト ACL があります。つまり、バケットに追加されたオブジェクトはデフォルトで projectPrivate ACL を取得します。この ACL によって、Viewer はオブジェクトを表示できます。

    同様に、プロジェクト役割 EditorOwner は、Cloud Storage へのアクセスが制限されていますが、これらの役割が割り当てられたメンバーは、新しいバケットの roles/storage.legacyBucketOwner と、projectPrivate ACL を介したオブジェクトの所有権を取得します。

    バケットとオブジェクトへのアクセス権の一部は ViewerEditorOwner のプロジェクト役割に固有ではないため、メンバーに必要のないアクセス権は取り消すことができます。

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

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

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

    デフォルトでは、プロジェクト レベルの Owner の役割を持つメンバーだけが、新規作成されるバケットで roles/legacyBucketOwner の役割を持つエンティティとなります。チームメンバーがグループを離れても他のメンバーがバケットを管理できるように、Owner の役割を持つメンバーが常に 2 人以上いるようにする必要があります。

次のステップ

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

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

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