Identity and Access Management

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

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

概要

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

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

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

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

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

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

権限

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

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

役割

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

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

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

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

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

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

ACL との関係

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

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

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

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

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

同様に、storage.objects 権限(.get.getIamPolicy.setIamPolicy.update)では、ユーザーはオブジェクト ACL を操作できます。

カスタムの役割

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

メンバーのタイプ

メンバーにはいくつかのタイプがあります。たとえば、Google アカウントと Google グループの 2 つは一般的なタイプであり、allAuthenticatedUsersallUsers の 2 つは特別なタイプです。IAM の一般的なメンバータイプのリストについては、ID に関する概念をご覧ください。そこにリストされているタイプに加えて、IAM は次のメンバータイプをサポートしています。これらは、Cloud Storage バケットの 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 ツールでの使用

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

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

おすすめの方法

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

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

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

  • 知らない人に setIamPolicy 権限を含む役割を付与することは避けます。

    setIamPolicy 権限が付与されたユーザーは、権限を変更してデータを制御できます。setIamPolicy 権限を含む役割は、オブジェクトとバケットに対する管理権限を委任する場合にのみ使用してください。

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

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

  • Cloud Storage の Viewer / Editor / Owner プロジェクト役割を理解します。

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

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

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

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

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

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

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

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

次のステップ

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

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

Cloud Storage ドキュメント