おすすめのアクセス制御方法

このページでは、Identity and Access Management(IAM)アクセス制御リスト(ACL)を使用して、データへのアクセスを管理するためのベスト プラクティスについて説明します。

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

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

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

  • IAM ロールに setIamPolicy 権限を与えたり、知らないユーザーに ACL OWNER 権限を付与しないでください。

    setIamPolicy IAM 権限または OWNER ACL 権限を付与されたユーザーは、権限を変更してデータを制御できます。これらの権限を持つロールは、オブジェクトとバケットに対する管理権限を委任する場合にのみ使用します。

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

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

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

    管理者権限を持つユーザーがグループから離れても、他のチームメンバーがリソースを引き続き管理できるようにする必要があります。

    リソースにアクセスできないようにするには、次のいずれかを行います。

    • プロジェクトに対するストレージ管理者 IAM ロールを個人ではなく、グループに付与します。

    • プロジェクトに対するストレージ管理者 IAM ロールを少なくとも 2 人に付与します。

    • バケットの OWNER ACL 権限を少なくとも 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 から Cloud Storage への単純な移行をご覧ください。

次のステップ