Object Storage Service:Control Policy

認証メカニズム

Control Policy は権限の境界を定義しますが、直接権限を付与するものではありません。メンバーアカウント内の RAM ユーザーまたは RAM ロールが OSS などのクラウドサービスにアクセスしようとした場合、システムはまず Control Policy に基づいてコンプライアンスチェックを実行します。このチェックを通過した場合にのみ、システムは当該アカウントの RAM 権限ポリシーを評価します。

評価原則

Control Policy の評価は、リクエストされたリソースを所有するアカウントから開始され、Resource Directory の階層を上方向にたどって行われます。各レベルでの評価は、明示的な拒否が優先される 原則に従います。

1. 明示的な拒否が優先される：リクエストに一致する Deny ルールが存在する場合、そのリクエストは即座に拒否されます。Control Policy の評価プロセスはここで終了し、アカウントの RAM 権限ポリシーは評価されません。

2. 明示的な許可の検索：あるレベルで一致する Deny ルールが存在しない場合、システムは一致する Allow ルールを探します。Allow ルールが見つかった場合、そのレベルでの評価は通過し、親ノードに移って階層のルートフォルダまで評価が継続されます。ルートフォルダでも評価が通過した場合、Control Policy 全体のチェックは成功とみなされます。その後、システムはアカウントの RAM 権限ポリシーを評価します。

3. デフォルト拒否：一致する Deny ルールも Allow ルールも見つからない場合、リクエストはデフォルトで拒否されます。評価プロセスはここで終了し、次のレベルへの移行やアカウントの RAM 権限ポリシーの評価は行われません。

Alibaba Cloud は、アクセス対象のアカウントおよびその階層上のすべての祖先ノードにアタッチされたポリシーを評価します。これにより、上位レベルにアタッチされた Control Policy が、その下位にあるすべてのアカウントに強制されることを保証します。詳細については、「Control Policy の概要」をご参照ください。

ポリシーの種類

• システム Control Policy：事前に用意されたポリシーで、閲覧は可能ですが変更はできません。Control Policy 機能を有効化すると、デフォルトで FullAliyunAccess ポリシーがアタッチされ、すべての操作が許可されます。

• カスタム Control Policy：ユーザーが作成・管理するポリシーです。フォルダまたはメンバーにアタッチできます。

適用範囲

Control Policy は、Resource Directory 内のメンバーアカウントに所属するすべての RAM ユーザーおよび RAM ロールに適用されます。サービスにリンクされたロール、メンバーアカウントの root ユーザー、および管理アカウント内のいかなる ID にも適用されません。

手順 1: コントロールポリシー機能を有効化する

この操作は一度だけ実行すれば十分です。すでに機能が有効になっている場合は、このステップをスキップしてください。

1. Resource Directory - Control Policy の有効化ページに移動します。

2. 制御ポリシーの有効化 をクリックし、選択内容を確認します。

3. 更新 をクリックしてステータスを確認します。

ステップ 2：カスタム Control Policy を作成

1. Resource Directory - Control Policy の作成ページに移動します。

2. 必要に応じて構成方法を選択します。

   以下の例は、パブリックアクセスのブロックを強制するポリシーの作成方法を示しています。その他の構成例については、「一般的な権限付与シナリオ」をご参照ください。

   重要

   拒否ポリシーを構成する前に、メンバーアカウント内のすべての既存リソースがポリシーに準拠していることを確認してください。OSS のパブリックアクセスブロックを強制する場合、すべての既存バケットでパブリックアクセスのブロックが有効になっていることを事前に確認する必要があります。

   ビジュアルエディター

   ビジュアルエディター セクションで、以下の設定を行います。

   • 効果：[拒否] を選択します。

   • Service：[OSS] を選択します。

   • 操作：oss:DeleteBucketPublicAccessBlock および oss:PutBucketPublicAccessBlock を選択します。

   ポリシーエディター

   ポリシーエディター セクションで、以下のポリシー構成を入力します。

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Deny",
         "Action": [
           "oss:DeleteBucketPublicAccessBlock",
           "oss:PutBucketPublicAccessBlock"
         ],
         "Resource": "*"
       }
     ]
   }

   説明

   Control Policy は JSON フォーマットを使用し、Version および Statement の 2 つのコアフィールドで構成されます。Statement は、Effect、Action、Resource、Condition の要素で構成されます。Action の構成方法の詳細については、「Action」をご参照ください。

3. OK をクリックします。

4. Control Policy の作成ダイアログボックスで、名前と説明を入力し、OK をクリックします。

ステップ 3：Control Policy をフォルダにアタッチ

1. Resource Directory - ディレクトリ管理ページに移動します。

2. リソースディレクトリツリーで、対象のフォルダをクリックします。

3. [ポリシー] タブで、ポリシーのアタッチ をクリックします。

4. ポリシーのアタッチ パネルで、アタッチする Control Policy を選択し、OK をクリックします。

ステップ 4：ポリシーの検証

ポリシーをアタッチ後、フォルダ内のすべてのメンバーアカウントがその制約の対象となります。パブリックアクセスのブロックを強制するポリシーの効果を検証するには、以下のチェックを実行します。

1. 拒否操作の検証：メンバーアカウント内で、既存のバケットのパブリックアクセスブロックを無効化しようとします。Control Policy により、この操作が拒否されるはずです。

2. 作成制限の検証：パブリックアクセスブロックを有効にせずに新しいバケットを作成しようとします。システムは作成リクエストを拒否するはずです。

3. 階層的適用の検証：階層内の異なるレベルにあるメンバーアカウントで同様の操作を実行し、ポリシーがフォルダ全体で有効であることを確認します。

シナリオ 1：OSS バケットのパブリックアクセスブロックを強制

OSS バケットのパブリックアクセスブロックを強制するための Control Policy を構成し、ユーザーがこの機能を無効化したり、この機能を有効にせずに新しいバケットを作成したりできないようにします。以下の例は、ポリシー構成を示しています。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucketPublicAccessBlock",
        "oss:PutBucketPublicAccessBlock"
      ],
      "Resource": "*"
    }
  ]
}