tencent cloud

COSバケットおよびバケット内のリソースにアクセスする際は権限承認を経てからアクセスする必要があります。Tencent Cloudの権限システムでは、リソースが所属するルートアカウントはデフォルトでバケットおよびバケット内のリソースに対しすべての管理権限を有します。CAMユーザー（その他のルートアカウント、コラボレーター、サブアカウント）および匿名ユーザーなどのその他のタイプのユーザーは、ルートアカウントによる権限承認を経てからでなければアクセスできません。

アカウントのアクセスポリシーには、ユーザーグループポリシー、ユーザーポリシー、バケットアクセス制御リスト（ACL）、バケットポリシー（Policy）などの異なるポリシータイプがあります。アクセスポリシーの評価においては、次のいくつかの重要な要素があります。

1. ユーザーのID認証：ユーザーがCOS上のリソースにアクセスする場合、次の2つの状況があります。
   • リクエスト署名がある場合、COSはリクエスト署名からユーザーのアカウント情報を解析した後、リクエストをCAMに転送してID認証を行います。
   • 署名のないリクエストの場合は、匿名ユーザーと認識され、認証の次の段階に進みます。
2. アクセスポリシーの種類：アクセスポリシーにはユーザーグループ、ユーザー、バケットなどの複数のタイプが含まれます。アクセスポリシーの順序はアクセスポリシーの種類によって決定されます。
3. ポリシーのコンテキスト情報：ユーザーのリソースアクセスリクエストを処理する際は、ユーザーグループポリシー、ユーザーポリシー、バケットポリシーなどの複数のポリシーに記録された権限の詳細に基づいて総合的に判断し、リクエストを許可するかどうかを最終的に決定します。

アクセスポリシーの評価フロー

Tencent Cloud COSがリクエストを受信すると、最初にリクエスト送信者のIDを確認し、リクエスト送信者が関連の権限を有しているかどうかを検証します。検証のプロセスには、ユーザーポリシー、バケットアクセスポリシー、リソースベースのアクセス制御リストのチェックが含まれ、リクエストに対する認証を行います。

Tencent Cloud COSはリクエストを受信した際、最初にID認証を行い、ID認証の結果に基づいてリクエスト送信者のIDを分類します。IDのカテゴリーに応じて異なるアクションがとられる可能性があります。

1. 検証済みのTencent Cloudルートアカウント：ルートアカウントはその所属リソースに対しすべての操作権限を有します。一方、アカウントに属さないリソースについては、リソース権限の評価が必要であり、認証に合格するとリソースへのアクセスが許可されます。
2. 検証済みのCAMユーザー（サブアカウントまたはコラボレーター）：ユーザーポリシーの評価 —— CAMユーザーは必ず親アカウントにあたるルートアカウントの権限承認を受けていなければ、関連のアクセスが許可されません。CAMユーザーが他のルートアカウントに属するリソースにアクセスしたい場合は、CAMユーザーが属するルートアカウントのリソース権限の評価が必要であり、認証に合格するとリソースへのアクセスが許可されます。
3. ID特性を持たない匿名ユーザー：リソース権限の評価 —— バケットアクセスポリシーまたはバケット、オブジェクトのアクセス制御リストの権限を評価し、認証に合格するとリソースへのアクセスが許可されます。
4. 上記のユーザーカテゴリー以外のリクエスト送信者：アクセスが拒否されます。

アクセスポリシーの評価根拠

Tencent Cloudの権限システムでは、アクセスポリシーの評価フローにおいて、全プロセスでポリシーのコンテキスト情報に基づいて権限の評価を行います。また同時に次のいくつかの基本原則があります。

1. デフォルトでは、すべてのリクエストが暗黙的に拒否（deny）されます。ルートアカウントはデフォルトでアカウント下のすべてのリソースのアクセス権限を有します。
2. ユーザーグループポリシー、ユーザーポリシー、バケットポリシーまたはバケット/オブジェクトのアクセス制御リストに明示的な許可が存在する場合は、このデフォルト値を上書きします。
3. いずれかのポリシーの中に明示的な拒否がある場合は、あらゆる許可を上書きします。
4. 有効な権限の範囲はIDベースのポリシー（ユーザーグループポリシー、ユーザーポリシー）とリソースベースのポリシー（バケットポリシーまたはバケット/オブジェクトのアクセス制御リスト）を合わせたものとなります。

説明：

• 明示的な拒否：ユーザーポリシー、ユーザーグループポリシー、バケットPolicyの中で特定のユーザーに対して明確なDenyポリシーが存在する場合。例えば、ルートアカウントがユーザーポリシーの中で、サブユーザーUIN 100000000011がGET Object操作を行うことを明確にDenyと設定している場合、そのサブユーザーはそのルートアカウント下のオブジェクトリソースをダウンロードすることはできません。
• 明示的な許可：ユーザーポリシー、ユーザーグループポリシー、バケットPolicy、バケットACLの中で、grant-\*によって特定のユーザーを明確に指定し、特定のユーザーに対し明確なAllowポリシーを設けます。
• すべての人を拒否：バケットPolicyの中で、Deny anyoneと明確に指定します。すべての人を拒否すると、任意の署名なしリクエストが拒否されます。署名付きリクエストに対してはIDベースのポリシーによる認証が行われます。
• すべての人を許可：バケットPolicyの中で、Allow anyoneと明確に指定するか、またはバケットACLの中でpublic-\*と明確に指定します。
• 有効な権限の範囲はIDベースのポリシーとリソースベースのポリシーを合わせたものとなります。1回の完全な認証において、COSは最初にユーザーのIDを解析し、ユーザーのIDに基づいて、そのユーザーがアクセス権限を持つリソースの権限チェックを行います。同時にリソースベースのポリシーに基づき、ユーザーを匿名ユーザーとみなして権限チェックを行います。2回のチェックのうち1回が成功するとアクセスが許可されます。

アクセスポリシーの評価根拠は次の図のとおりです。最初にリクエストの署名の有無に基づき、ユーザーが匿名ユーザーかどうかを評価します。ユーザーが匿名ユーザーであれば、「すべての人を拒否」または「すべての人を許可」のポリシーがないかどうかを評価し、これに基づいてアクセス許可またはアクセス拒否の判断を行います。ユーザーが正当なCAMユーザーまたはリソースを所有するルートアカウントの場合は、明示的な拒否、明示的な許可または「すべての人を許可」のポリシーがないかどうかを評価し、これに基づいてアクセス許可またはアクセス拒否の判断を行います。

ポリシーのコンテキスト情報

ポリシーのコンテキスト情報とは、ポリシーに記録される権限の詳細を指します。最小権限の原則の下で、ユーザーはポリシーの中で次の情報を明確に指定する必要があります。

• プリンシパル（principal）：どのサブユーザー（ユーザーIDの入力が必要）、コラボレーター（ユーザーIDの入力が必要）、匿名ユーザーまたはユーザーグループに権限を付与したいかを明確に指定する必要があります。一時キーを使用してアクセスする場合、この項の指定は不要です。
• ステートメント（statement）：次のいくつかのパラメータに、対応するパラメータを明確に入力します。
• エフェクト（effect）：このポリシーが「許可」であるか「明示的な拒否」であるかを明確に述べる必要があります。allowとdenyの2種類が含まれます。
• アクション（action）：このポリシーが許可または拒否するアクションを明確に述べる必要があります。アクションは単一のAPIのアクションまたは複数のAPIアクションのセットとすることができます。
• リソース（resource）：このポリシーが権限を承認する具体的なリソースを明確に述べる必要があります。リソースは6セグメント式で記述します。リソース範囲の指定は、exampleobject.jpgなどの指定されたファイル、またはexamplePrefix/*などの指定されたディレクトリとすることができます。業務上の必要がない限り、すべてのリソースにアクセスする権限（ワイルドカード*）をユーザーにみだりに付与しないでください。
• 条件（condition）：ポリシー発効の制約条件を記述します。条件はオペレーター、アクションキーとアクション値から構成されています。条件値には時間、IPアドレスなどの情報を含めることができます。

ポリシーの作成は一定のポリシー構文に従って行う必要があります。アクセスポリシーの言語概要を参照し、業務上の必要性に応じて作成することができます。ユーザーポリシーおよびバケットポリシーの作成例については、ユーザーポリシー構文の構造およびバケットポリシーの例をそれぞれご参照ください。

アクセスポリシーの評価の例

ルートアカウントUIN 100000000001がサブアカウントUIN 100000000011にユーザープリセットポリシーをバインドし、このサブアカウントにルートアカウント下のリソースを読み取り専用として許可したとします。このユーザーポリシーの詳細は次のとおりです。このユーザーポリシーはこのサブアカウントに対し、すべてのList、Get、Head操作およびOptionsObject操作の実行を許可しています。

{
  "version": "2.0",
  "statement": [
      {
          "action": [
              "cos:List*",
              "cos:Get*",
              "cos:Head*",
              "cos:OptionsObject"
          ],
          "resource": "*",
          "effect": "allow"
      }
  ]
}

また、ルートアカウントはあるプライベート読み取り/書き込みバケットexamplebucket-1250000000に次のバケットポリシーを追加しました。

{
"Statement": [
  {
    "Principal": {
      "qcs": [
        "qcs::cam::anyone:anyone"
      ]
    },
    "Effect": "Deny",
    "Action": [
      "name/cos:GetObject"
    ],
    "Resource": [
      "qcs::cos:ap-guangzhou:uid/100000000011:examplebucket-1250000000/*"
    ]
  }
],
"version": "2.0"
}

このバケットポリシーはすべてのユーザーのオブジェクトダウンロード実行（GetObject）の操作を明示的に拒否しています。このため、アクセスポリシー評価のフローにおいては、次が行われます。

1. このサブアカウントが署名パラメータによってGetObjectをリクエストした場合、このリクエストが表すユーザーのIDが対応するユーザーポリシーとマッチした場合、アクセスポリシーの評価検証は合格となります。
2. このサブアカウントが署名のないパラメータによってGetObjectをリクエストした場合、システムによって匿名のリクエストと判断され、バケットポリシーによってアクセスが拒否されます。