Object Storage Service:RAM ポリシー

ステップ 1：カスタムポリシーの作成

1. ポリシーページに移動し、ポリシーの作成 をクリックします。

2. スクリプトの編集 を選択し、JSON 形式の権限ポリシーをエディターに入力します。RAM Policy Editor を使用すると、権限ポリシーを素早く生成できます。

   認可ポリシーの例: example-bucket およびそのバケット内のすべてのリソースに対するすべての操作を許可します。

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "oss:*",
         "Resource": [
           "acs:oss:*:*:example-bucket",
           "acs:oss:*:*:example-bucket/*"
         ]
       }
     ]
   }

   完全な権限ポリシーは、 バージョン (バージョン番号) と ステートメント (権限付与ステートメント) で構成されます。

   • バージョン: ポリシーのバージョンであり、1 に固定されていて変更できません。

   • ステートメント：ポリシーの本体であり、1 つ以上の具体的な許可/拒否ルールが含まれます。各権限付与ステートメントは、 エフェクト、 アクション、 リソース、および 条件 で構成されます。

     ポリシー要素	説明
     エフェクト	ポリシーの効果。有効な値: Allow (許可) または Deny (拒否)。
     アクション	リソースに対して実行する特定の操作。ワイルドカード * を使用できます。
     リソース	ポリシーが適用されるリソースの範囲です。
     条件	ポリシーが有効になる条件です。 複数の条件が設定されている場合、ポリシーが有効になるには、すべての条件を同時に満たす (AND 関係) 必要があります。

     権限付与要素の完全なリストについては、OSS 権限付与の構文と要素をご参照ください。

3. OK をクリックし、 [ポリシー名] を入力してから、 OK をクリックしてカスタムポリシーの作成を完了します。

ステップ 2：ユーザーアイデンティティへの権限付与

カスタムポリシーを作成した後、対象のユーザーアイデンティティに付与する必要があります。以下では、RAM ユーザーを例として権限付与の手順を説明します。

1. RAM ユーザーページに移動し、対象ユーザーの 権限の追加 列で 権限の追加 をクリックします。

2. 検索ボックスにカスタムポリシーの名前を入力し、対象のポリシーを選択します。

3. [OK] をクリックして、権限の付与を完了します。

シナリオ 1：RAM ユーザーへのバケットに対する完全な制御権限の付与

次の例では、RAM ユーザーに mybucket という名前のバケットに対する完全なコントロール権限を付与します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:mybucket",
        "acs:oss:*:*:mybucket/*"
      ]
    }
  ]
}

シナリオ 2：RAM ユーザーによるバケット内の一致する特定のパターンのファイルの削除の拒否

以下の例では、mybucket という名前のバケット内で、プレフィックスが abc で拡張子が .txt のすべてのファイルを、RAM ユーザーが削除することを拒否します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/abc*.txt"
      ]
    }
  ]
}

シナリオ 3：RAM ユーザーへのバケット内のすべてのリソースを一覧表示および読み取る権限の付与

• 次の例では、RAM ユーザーに、OSS SDK または OSS コマンドラインツールを介して mybucket という名前のバケット内のすべてのリソースを一覧表示および読み取る権限を付与します。

  説明

  ListObjects アクションは、リソースとしてバケット全体を使用する必要があります。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "oss:ListObjects",
        "Resource": "acs:oss:*:*:mybucket"
      },
      {
        "Effect": "Allow",
        "Action": "oss:GetObject",
        "Resource": "acs:oss:*:*:mybucket/*"
      }
    ]
  }

• 次の例では、RAM ユーザーに対し、OSS コンソールで mybucket という名前のバケット内のすべてのリソースを一覧表示し、読み取る権限を付与します。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListBuckets",
          "oss:GetBucketStat",
          "oss:GetBucketInfo",
          "oss:GetBucketTagging",
          "oss:GetBucketLifecycle",
          "oss:GetBucketWorm",
          "oss:GetBucketVersioning",
          "oss:GetBucketAcl"
        ],
        "Resource": "acs:oss:*:*:*"
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListObjects",
          "oss:GetBucketAcl"
        ],
        "Resource": "acs:oss:*:*:mybucket"
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:GetObject",
          "oss:GetObjectAcl"
        ],
        "Resource": "acs:oss:*:*:mybucket/*"
      }
    ]
  }

シナリオ 4：RAM ユーザーによるバケットの削除の拒否

次の例では、RAM ユーザーが mybucket という名前のバケットを削除することを拒否します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:*",
      "Resource": [
        "acs:oss:*:*:mybucket",
        "acs:oss:*:*:mybucket/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucket"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket"
      ]
    }
  ]
}

シナリオ 5：RAM ユーザーへのファイルアップロード・削除権限の付与とバケット削除の拒否

次の例では、RAM ユーザーに mybucket という名前のバケット内のファイルをアップロードおよび削除する権限 (オブジェクトバージョンの削除を含む) のみを付与しますが、バケット自体の削除権限は拒否します。 oss:* を使用して広範な権限を付与するシナリオ 4 とは異なり、このシナリオでは最小権限の原則に従い、許可される操作を正確に指定します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:PutObject",
        "oss:DeleteObject",
        "oss:DeleteObjectVersion"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/*"
      ]
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucket"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket"
      ]
    }
  ]
}

シナリオ 6：RAM ユーザーへのバケット内の複数のディレクトリへのアクセス権限の付与

写真を保存するバケットが mybucket であるとします。このバケットには、撮影場所を表すディレクトリがいくつかあり、各場所のディレクトリには年ごとのサブディレクトリが含まれています。

mybucket[Bucket]
  ├── beijing
  │   ├── 2014
  │   └── 2015
  └── hangzhou
      ├── 2014
      └── 2015 

RAM ユーザーに mybucket/hangzhou/2014/ および mybucket/hangzhou/2015/ ディレクトリへの読み取り専用権限を付与する必要があります。 ディレクトリレベルの承認は高度な承認機能です。 承認ポリシーの複雑さは使用シナリオによって異なり、参考として以下のシナリオが提供されています。

• RAM ユーザーに mybucket/hangzhou/2014/ および mybucket/hangzhou/2015/ ディレクトリ内のファイルの内容を読み取る権限のみを付与します。

  RAM ユーザーはファイルのフルパスを知っているため、ディレクトリ内のファイル内容を読み取るには、完全なファイルパスを使用することを推奨します。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:GetObject"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket/hangzhou/2014/*",
          "acs:oss:*:*:mybucket/hangzhou/2015/*"
        ]
      }
    ]
  }

• RAM ユーザーに、OSS コマンドラインツールを使用して mybucket/hangzhou/2014/ および mybucket/hangzhou/2015/ ディレクトリにアクセスし、これらのディレクトリ内のファイルを一覧表示する権限を付与します。

  RAM ユーザーがディレクトリ内にどのファイルがあるか分からない場合、OSS コマンドラインツールまたは API を使用して、ディレクトリ情報を直接取得できます。このシナリオでは、ListObjects 権限を追加する必要があります。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:GetObject"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket/hangzhou/2014/*",
          "acs:oss:*:*:mybucket/hangzhou/2015/*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListObjects"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket"
        ],
        "Condition":{
          "StringLike":{
            "oss:Prefix": [
              "hangzhou/2014/*",
              "hangzhou/2015/*"
            ]
          }
        }
      }
    ]
  }

• OSS コンソールを使用してディレクトリにアクセスする権限を RAM ユーザーに付与します。

  OSS コンソールで mybucket/hangzhou/2014/ と mybucket/hangzhou/2015/ ディレクトリにアクセスする場合、RAM ユーザーはルートディレクトリから階層を 1 つずつたどり、ターゲットディレクトリに移動できます。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListBuckets",
          "oss:GetBucketStat",
          "oss:GetBucketInfo",
          "oss:GetBucketTagging",
          "oss:GetBucketLifecycle",
          "oss:GetBucketWorm",
          "oss:GetBucketVersioning",
          "oss:GetBucketAcl"
        ],
        "Resource": [
          "acs:oss:*:*:*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:GetObject",
          "oss:GetObjectAcl"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket/hangzhou/2014/*",
          "acs:oss:*:*:mybucket/hangzhou/2015/*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListObjects"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket"
        ],
        "Condition": {
          "StringLike": {
            "oss:Delimiter": "/",
            "oss:Prefix": [
              "",
              "hangzhou/",
              "hangzhou/2014/*",
              "hangzhou/2015/*"
            ]
          }
        }
      }
    ]
  }

シナリオ 7：RAM ユーザーによるバケット内の任意のファイルの削除の拒否

次の例では、RAM ユーザーが mybucket バケット内のいずれかのファイルを削除することを拒否します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:*:mybucket/*"
      ]
    }
  ]
}

シナリオ 8：RAM ユーザーによる指定されたタグを持つオブジェクトへのアクセスの拒否

次の Deny ポリシーは、RAM ユーザーが examplebucket という名前のバケット内で、タグ status:ok および key1:value1 が付いたオブジェクトにアクセスすることを拒否します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:174649585760xxxx:examplebucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "oss:ExistingObjectTag/status":"ok",
          "oss:ExistingObjectTag/key1":"value1"
        }
      }
    }
  ]
}

シナリオ 9：RAM ユーザーへの特定のIPアドレスからのOSSへのアクセス権限の付与

• Allow 認可に IP アドレス制限を追加します。

  次の例では、Allow 認可に IP アドレス制限を追加し、RAM ユーザーに対し、IP アドレス範囲 192.168.0.0/16 および 198.51.100.0/24 からのみ mybucket という名前のバケット内のすべてのリソースを読み取る権限を付与します。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListBuckets",
          "oss:GetBucketStat",
          "oss:GetBucketInfo",
          "oss:GetBucketTagging",
          "oss:GetBucketAcl"
        ],
        "Resource": [
          "acs:oss:*:*:*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListObjects",
          "oss:GetObject"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket",
          "acs:oss:*:*:mybucket/*"
        ],
        "Condition":{
          "IpAddress": {
            "acs:SourceIp": ["192.168.0.0/16", "198.51.100.0/24"]
          },
          "StringNotLike": {
            "acs:SourceVpc": [
              "vpc-*"
            ]
          }
        }
      }
    ]
  }

• 拒否認可に IP アドレス制限を追加します。

  次の例では、Deny 承認に IP アドレス制限を追加することで、送信元 IP アドレスが 192.168.0.0/16 範囲内にない RAM ユーザーによる OSS でのあらゆる操作を拒否します。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListBuckets",
          "oss:GetBucketStat",
          "oss:GetBucketInfo",
          "oss:GetBucketTagging",
          "oss:GetBucketAcl"
        ],
        "Resource": [
          "acs:oss:*:*:*"
        ]
      },
      {
        "Effect": "Allow",
        "Action": [
          "oss:ListObjects",
          "oss:GetObject"
        ],
        "Resource": [
          "acs:oss:*:*:mybucket",
          "acs:oss:*:*:mybucket/*"
        ]
      },
      {
        "Effect": "Deny",
        "Action": "oss:*",
        "Resource": [
          "acs:oss:*:*:*"
        ],
        "Condition":{
          "NotIpAddress": {
            "acs:SourceIp": ["192.168.0.0/16"]
          },
          "StringLike": {
            "acs:SourceVpc": [
              "*"
            ]
          }
        }
      }
    ]
  }

  説明

  権限ポリシーの認可ルールは拒否優先であるため、訪問者が 192.168.0.0/16 以外の IP アドレスから mybucket 内のコンテンツにアクセスすると、OSS はアクセス拒否エラーを返します。

シナリオ 10：RAM または STS サービスによる他のユーザーへの権限付与

RAM または STS サービスを使用して、IP アドレスが 192.168.0.1 のユーザーに、Java SDK クライアントで以下の操作を実行する権限を付与します。

• mybucket 内の、プレフィックスが foo のオブジェクトを一覧表示します。

• mybucket 内の file で始まるオブジェクトのアップロード、ダウンロード、削除を許可します。

{
  "Version": "1",
  "Statement": [{
    "Action": [
      "oss:GetBucketAcl",
      "oss:ListObjects"
    ],
    "Resource": [
      "acs:oss:*:177530505652xxxx:mybucket"
    ],
    "Effect": "Allow",
    "Condition": {
      "StringLike": {
        "acs:UserAgent": "*java-sdk*",
        "oss:Prefix": "foo"
      },
      "IpAddress": {
        "acs:SourceIp": "192.168.0.1"
      },
      "StringNotLike": {
        "acs:SourceVpc": [
          "vpc-*"
        ]
      }
    }
  },
    {
      "Action": [
        "oss:PutObject",
        "oss:GetObject",
        "oss:DeleteObject"
      ],
      "Resource": [
        "acs:oss:*:177530505652xxxx:mybucket/file*"
      ],
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "acs:UserAgent": "java-sdk"
        },
        "IpAddress": {
          "acs:SourceIp": "192.168.0.1"
        },
        "StringNotLike": {
          "acs:SourceVpc": [
            "vpc-*"
          ]
        }
      }
    }
  ]
}

シナリオ 11：バケットとオブジェクトの ACL をパブリックアクセスに設定することの拒否

次の例では、バケットとオブジェクトの ACL をパブリックアクセスに設定することを拒否し、OSS データのセキュリティを確保します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:PutBucket",
        "oss:PutBucketAcl"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "oss:x-oss-acl": "private"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:PutObject",
        "oss:PutObjectAcl"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "oss:x-oss-object-acl": [
            "private",
            "default"
          ]
        }
      }
    }
  ]
}

シナリオ 12：RAM ユーザーへの IMM 関連機能を使用する権限の付与

次の RAM ポリシーでは、IMM のドキュメント処理を使用する権限を RAM ユーザーに付与します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "oss:GetObject",
        "oss:PutObject",
        "oss:PostProcessTask",
        "oss:ProcessImm"
      ],
      "Resource": "*"
    },
    {
      "Action": [
        "imm:CreateOfficeConversionTask",
        "imm:GetWebofficeURL"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Effect": "Allow",
      "Action": "ram:PassRole",
      "Resource": "acs:ram:*:*:role/aliyunimmdefaultrole"
    }
  ]
}

シナリオ 13：RAM ユーザーへのストレージ冗長タイプを変更する権限の付与

• 特定のバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。

  次の例では、RAM ユーザーに mybucket のストレージの冗長タイプを変更する権限を付与します。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:CreateBucketDataRedundancyTransition",
          "oss:GetBucketDataRedundancyTransition",
          "oss:ListBucketDataRedundancyTransition",
          "oss:DeleteBucketDataRedundancyTransition"
        ],
        "Resource": "acs:oss:*:*:mybucket"
      }
    ]
  }

• すべてのバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。

  重要

  次の例では、Alibaba Cloud アカウント配下のすべてのバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。慎重に設定してください。

  {
    "Version": "1",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "oss:CreateBucketDataRedundancyTransition",
          "oss:GetBucketDataRedundancyTransition",
          "oss:ListBucketDataRedundancyTransition",
          "oss:DeleteBucketDataRedundancyTransition"
        ],
        "Resource": "acs:oss:*:*:*"
      }
    ]
  }

シナリオ 14：RAM ユーザーへの OSS リソースプランの注文を作成する権限の付与

次の RAM ポリシーでは、OSS リソースプランの注文を作成する権限を RAM ユーザーに付与します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:CreateOrder",
      "Resource": "acs:oss:*:*:*"
    }
  ]
}

シナリオ 15：RAM ユーザーへの OSS をアクティベートする権限の付与

次の RAM ポリシーでは、OSS をアクティベートする権限を RAM ユーザーに付与します。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:ActivateProduct",
      "Resource": "acs:oss:*:*:*"
    }
  ]
}

シナリオ 16：RAM ユーザーへの指定されたタグを持つバケット内のデータを読み書きする権限の付与

次の RAM ポリシーでは、指定されたタグを持つバケット内のデータを読み書きする権限を RAM ユーザーに付与します。ここで、タグキーは key1、タグ値は value1 です。

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "oss:ListBuckets",
        "oss:GetBucketStat",
        "oss:GetBucketInfo",
        "oss:GetBucketAcl",
        "oss:ListObjects",
        "oss:PutObject",
        "oss:GetObject"
      ],
      "Resource": [
        "acs:oss:*:*:*"
      ],
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "oss:BucketTag/key1": "value1"
        }
      }
    }
  ]
}

シナリオ 17：RAM ユーザーへの書き込み専用権限 (oss:PutObject) の付与

次の RAM ポリシーでは、OSS にファイルをアップロードする権限を RAM ユーザーに付与しますが、バケットやオブジェクトを読み取ったり一覧表示したりする権限は付与しません。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "oss:PutObject",
      "Resource": "acs:oss:*:*:*"
    }
  ]
}

このポリシーが RAM ユーザーに付与されると、RAM ユーザーは ossutil または SDK 経由でファイルをアップロードできますが、ls を使用してバケットを一覧表示したり、cp を使用してファイルをダウンロードしたりすることはできません。これら 2 種類のリクエストは 403 AccessDenied エラーを返しますが、これはポリシーが有効になった場合の期待される動作です。書き込み専用権限を特定のバケットにのみ付与する必要がある場合は、Resource スコープを acs:oss:*:*:{bucket-name}/* に絞り込むことができます。acs:oss:*:*:/* は有効な Resource 形式ではなく、認可検証をパスできないため、使用しないでください。

このポリシーは、RAM ユーザーまたは RAM ロールのいずれか一方に付与できます。両方に同時に付与する必要はありません。STS の一時的な認証情報で OSS にアクセスする場合、RAM ユーザーの最終的な権限は、RAM ロールの権限と STS セッションポリシーの積集合になります。この場合、この書き込み専用権限ポリシーを直接 RAM ロールに付与できます。

明示的な Deny ルールによる Allow の上書き

症状：RAM ポリシーに Allow ステートメントを設定しているにもかかわらず、リクエストが AccessDenied エラーを返します。

トラブルシューティング手順：

1. [RAM ユーザー] ページに移動し、対象のユーザーをクリックして、[権限] タブでこのアイデンティティにバインドされているすべてのポリシー (システムポリシーとカスタムポリシーを含む) を表示します。

2. 各ポリシーを 1 つずつ確認し、Effect: Deny を含むステートメントがないかを確認します。特に、Action にワイルドカード (例：oss:*) が含まれるルール、または対象のアクションが含まれるルールに注目してください。

3. アカウントレベルでサービスコントロールポリシー (SCP) が有効になっている場合は、SCP にリクエストと一致する Deny ルールがないかを確認します。

解決策：不要な Deny ステートメントを削除するか、Deny ルールの Resource と Condition のスコープを絞り込み、Allow されている正当なリクエストを誤って遮断しないようにしてください。RAM ポリシーは明示的な拒否の優先原則に従います。つまり、同一ポリシーまたは他のポリシーに Allow ルールが存在していても、いずれかの Deny ルールがリクエストに一致するとアクセスは拒否されます。

リソース ARN 形式の誤り

症状：GetObject や PutObject などのオブジェクトレベルのアクションで権限不足が返されたり、ListObjects などのバケットレベルのアクションが失敗したりします。これら 2 種類のアクションでは、Resource を個別に設定する必要があります。

トラブルシューティング手順：

1. ポリシーの Resource フィールドを確認し、バケットレベルのリソース (acs:oss:*:*:bucketname) とオブジェクトレベルのリソース (acs:oss:*:*:bucketname/*) の両方が含まれているかを確認します。

2. アカウント ID が正しく入力されていることを確認します。すべてのアカウントに一致させるために * を使用している場合は、想定する権限のスコープと一致していることを確認します。

3. ディレクトリレベルの認可では、正しいプレフィックスのワイルドカード (例：acs:oss:*:*:mybucket/dir/*) を使用していることを確認します。Resource にディレクトリパスを記述しているにもかかわらず、ListObjects に必要なバケットレベルのリソースを省略していないかにも注意してください。

解決策：バケットレベルとオブジェクトレベルの両方のアクションを認可する必要がある場合は、同一ポリシー内で 2 種類の Resource を設定します。

{
  "Effect": "Allow",
  "Action": ["oss:ListObjects", "oss:GetBucketInfo"],
  "Resource": "acs:oss:*:*:mybucket"
},
{
  "Effect": "Allow",
  "Action": ["oss:GetObject", "oss:PutObject"],
  "Resource": "acs:oss:*:*:mybucket/*"
}

ポリシーが正しい RAM アイデンティティにアタッチされていない

症状：ポリシーを作成または変更した後も権限が有効にならず、RAM ユーザーまたは RAM ロールの実際のアクセス動作が変わりません。

トラブルシューティング手順：

1. ポリシー ページに移動し、対象のポリシーを見つけ、[ユーザーのバインド] をクリックして現在バインドされている ID のリストを表示します。対象のユーザーまたはロールがリストに含まれていることを確認します。

2. ユーザーグループを介して権限が付与される場合、RAM ユーザーグループ ページに移動し、RAM ユーザーが対応するユーザーグループに追加されていること、およびそのユーザーグループに対象のポリシーがアタッチされていることを確認します。

3. RAM ロールを使用している場合は、アプリケーションまたはユーザーが、別のロールではなく、対象のポリシーがアタッチされている正しいロールを引き受けていることを確認します。

解決策：対象ユーザーの [権限] タブで [権限を付与] をクリックし、対象のポリシーをこの RAM アイデンティティにアタッチしてから、再度テストします。

Condition の不一致

症状：ポリシーに Condition (IP 制限、VPC 制限、時間帯制限など) が含まれており、特定のソースからのリクエスト、または特定の時間帯のリクエストが想定外に拒否されます。

トラブルシューティング手順：

1. ポリシーの Condition 設定を確認し、使用している条件キー (例：acs:SourceIp、acs:SourceVpc、oss:Prefix) と、それぞれの一致値を検証します。

2. リクエスト元のクライアントの実際の IP アドレス、VPC ID などの属性が、Condition の要件を満たしているかを確認します。

3. acs:SourceIp と acs:SourceVpc は、通常はセキュリティ上の死角を避けるために併用する必要があります。パブリック IP アドレスのみを制限している場合、VPC 内のリクエストが一致する IP アドレスのパブリックインターネット出口を経由してルーティングされ、制限を回避する可能性があります。詳細については、「本番環境への適用」のセキュリティ推奨事項をご参照ください。

解決策：実際のネットワークアクセスアーキテクチャに基づいて Condition フィールドを調整します。問題を特定するために、まず Condition を一時的に削除してポリシーの基本的な Allow が機能することを確認し、その後、条件制約を段階的に追加して検証してください。

Action 名のスペルミスまたは不足

症状：該当アクションの Allow を設定しているにもかかわらず、リクエストが AccessDenied を返します。または、OSS コンソール経由のアクセスは正常ですが、SDK または API 呼び出しが失敗します (またはその逆)。

トラブルシューティング手順：

1. ポリシー内の各 Action 名を検証します。OSS の Action はケースセンシティブ (大文字と小文字を区別します) です。正しい形式は、例：oss:GetObject であり、oss:getobject ではありません。

2. OSS コンソール経由の操作では、通常、複数の Action を同時に認可する必要があります (例：oss:ListBuckets、oss:GetBucketStat、oss:GetBucketInfo、oss:GetBucketAcl)。不足がないか確認します。

3. OSS がサポートする RAM 認可要素を参照し、必要なアクションの正式名称と適用シナリオを確認します。

解決策：スペルミスしている Action 名を修正し、実際の利用シナリオ (コンソール、SDK、API) に基づいて必要な Action をすべて追加します。

バケットポリシーと RAM ポリシーの相互影響

症状：RAM ポリシーで対象アクションを認可しているにもかかわらず、特定のバケットへのアクセスが拒否されます。または、RAM ポリシーを削除した後もアクセス動作が変わりません。

トラブルシューティング手順：

1. OSS コンソールに移動し、対象バケットを開いて、[アクセス制御] > [バケットポリシー] を選択します。現在のアイデンティティに適用される Deny ルールがないかを確認します。

2. 明示的な拒否の優先原則に従い、バケットポリシーの Deny ルールと RAM ポリシーの Allow ルールは拒否優先で評価されます。つまり、RAM ポリシーでアクションを認可していても、バケットポリシーに一致する Deny ルールがある限り、リクエストは拒否されます。

3. バケットのアクセス制御リスト (ACL) 設定を確認します。ACL が private のバケットでは、すべてのアクセスを RAM ポリシーまたはバケットポリシーで明示的に認可する必要があります。バケットレベルの ACL が public-read または public-read-write に設定されている場合、匿名ユーザーでもデータにアクセスできるため、データセキュリティ上のリスクになります。

解決策：RAM ポリシーとバケットポリシーを総合的に確認し、両者が競合していないことを確認します。RAM ポリシーの Allow ルールを有効にする必要がある場合は、バケットポリシー内の該当する Deny ルールを調整または削除するか、関連する認可を RAM ポリシーに集約してください。