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 人目のメンバーに 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.getstorage.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 を変更するために必要な権限をメンバーに付与できます。次の storage.buckets 権限を合わせて付与することで、ユーザーはバケット ACL とデフォルト オブジェクト ACL を操作できます: .get.getIamPolicy.setIamPolicy.update

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

カスタムの役割

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-projectViewer の役割を持つすべてのメンバーに、いずれかのバケットの 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 の Viewer / Editor / Owner プロジェクト役割を理解します。

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

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

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

    バケットとオブジェクトへのアクセス権の一部は Viewer / Editor / Owner のプロジェクト役割に固有ではないため、メンバー自身はあると予想していたアクセス権を取り消すことができるのでご注意ください。

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

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

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

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

次のステップ

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

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

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