AWS Organizations の SCP の継承について

SRE2課佐竹です。
AWS Organizations のサービスコントロールポリシー（SCP）の「継承」を正しく理解できておらず、設計でハマったので調査してみました。

はじめに
用語説明
調査結果
- 調査1
- 調査2
  - DenyIAMEdit
- 調査3
調査結果を受けて
まとめ
- 2024年10月7日追記

はじめに

AWS Organizations には「ポリシーの継承」という言葉が出てきます。この「継承」という言葉ですが、以下のように公式ドキュメントで利用されています。

ポリシーを組織ルートにアタッチすると、組織内のすべての OU およびアカウントがそのポリシーを継承します。

特定の OU にポリシーをアタッチすると、その OU または子 OU の直下にあるアカウントがポリシーを継承します。
AWS Organizations

つまり最下層にあるAWSアカウントは、Root とそれまでに所属している OU の SCP を全て継承するということです。この「継承」という言葉ですが、日本語で想像する「継承」の通りに動作しないことがわかりましたので、その調査記録として記載します。

用語説明

念のために、AWS Organizations に登場する用語を手短に説明いたします。

SCP(サービスコントロールポリシー)

IAM Policy のように動作するポリシーです
SCP は各エンティティにそれぞれ複数個付与が可能になっています
エンティティには最低限1つの SCP がアタッチされていなければならない制限 があります

エンティティから最後の SCP をデタッチすることはできません。すべてのエンティティに常に少なくとも 1 つの SCP がアタッチされていなければなりません。
AWS Organizations

エンティティ

エンティティは、以下の3つ（Root, OU, Account）です。

Root

ルートはその組織内部で 1 つのみ（1つのAWSアカウントのみ）持つことができます
Root は明確には OU を持っていませんが、OU のように動きます。具体的には Root には直接 SCP をアタッチすることが可能です

OU(organizational unit)

AWSアカウントはいずれかのOUに配置されるか、もしくは Root に直接配置されます
OU は他の OU に所属（ぶら下げて配置）することが可能です

アカウント

個別のAWSアカウント1つを指します
エンティティには最低限1つの SCP が付与されている必要があるという制限から、AWSアカウントそれぞれにも1つの SCP が付与されている必要があります

FullAWSAccess

デフォルトで、AWSが SCP に用意している唯一の初期ポリシーです
FullAWSAccess は全てのAWSアカウントに付与されています

JSON

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

調査結果

調査1

上図のような構成を考えてみます。この構成では、各エンティティには全て「FullAWSAccess」のみが付与されています。この状態であれば、最下層にある Logging Account、Audit Account で特に操作は制限されません。

調査2

次に上図の構成を考えてみます。「DenyIAMEdit」という SCP は以下のポリシー JSONが記載されているとします。

DenyIAMEdit

{    
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessWithException",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DeleteRole",
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePermissionsBoundary",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription"
      ],
      "Resource": [
        "arn:aws:iam::*:role/ServerworksControl*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalARN":"arn:aws:iam::*:role/ServerworksControl*"
        }
      }
    }
  ]
}

このJSONは以下の公式ドキュメントから流用しました。

例 8: IAM プリンシパルで管理者を除き、特定の変更ができないようにする
サービスコントロールポリシーの例 - AWS Organizations

この状態では、「Logging Account」には継承されたポリシー（POLICIES INHERITED）としてマネジメントコンソール上で以下のように表示されます。

※この画像の Core は親OUと読み替えてください
この画像は「POLICIES INHERITED」で以下の3つが継承されていることがわかります。

Root から FullAWSAccess を継承
Core OU (親 OU) から DenyIAMEdit を継承
Logs OU (子 OU) から FullAWSAccess を継承

※補足：Root 及び各 OU より継承されたポリシーを最下層のアカウント側から拒否（デタッチ）することはできません
また、

Logging Account 自体に FullAWSAccess 付与

もされていることもわかります。この状態で、Logging Account、 Audit Account で自由な操作、例えば EC2 Instance の構築は可能でしょうか？結論からお伝えすると、構築不可能です。この状態では「DenyIAMEdit」にて許可されたもの以外の操作は不可能になります。

調査3

もし自由な操作を行いたい場合は、上図のような SCP に変更する必要があります。つまり先ほど操作が不可能であったのは「親OU」で権限が不足しているために、その配下のアカウントでも全て操作が不可能になってしまっていたとなります。

調査結果を受けて

AWS の権限許可には「暗黙的な拒否」、「明示的な許可」、「明示的な拒否」の3つがあります。何も記載がない場合は「暗黙的な拒否」になり、これがデフォルトです。明示的なアクセス許可がポリシーで宣言されている場合は「明示的な許可」となり、利用可能です。ただし、「明示的な拒否」には負けます。
強さは「暗黙的な拒否」＜「明示的な許可」＜「明示的な拒否」と強くなって行きます。詳しくは以下のドキュメントをご確認ください。

docs.aws.amazon.com

今回の事象を理解するにあたり、SCP のポリシーと、AWSアカウントにある IAM のポリシーを以下の通り表として並べてみました。また、今回はスペースの都合「拒否」を2種類とも同じ拒否として並列記載しています。

ここで重要なのは、「全ての階層（全 SCP と IAM Policy）で許可されている必要がある」という点です。つまり「シナリオ1」でしか操作可能とならない結果となります。
私が勘違いをしていたのは、「最下層のAWSアカウントは Root と経由してきた OU の SCP を全て継承するため、その SCP の中に明示的な許可が1つでもあれば暗黙的な拒否を打ち消す」と考えていたことです。ですが実際は、その通りになりませんでした。
これはどういうことかというと、各階層の SCP を跨いで権限を考えてくれるわけではないということです。それぞれの階層の SCP ごとで「暗黙的な拒否」、「明示的な許可」、「明示的な拒否」の権限設定は独立しており、暗黙的な拒否（もしくは明示的な拒否）が残っている SCP がどこかの階層に1つでもあれば、最下層のアカウントはその影響を受けるということです。