AWS Organizations の SCP の継承について

記事タイトルとURLをコピーする

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

はじめに

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

  • ポリシーを組織ルートにアタッチすると、組織内のすべての OU およびアカウントがそのポリシーを継承します。
  • 特定の OU にポリシーをアタッチすると、その OU または子 OU の直下にあるアカウントがポリシーを継承します。
    AWS Organizations

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

用語説明

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

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

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

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

エンティティ

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

Root

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

OU(organization 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

f:id:swx-satake:20200818175202p:plain

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

調査2

f:id:swx-satake:20200818175451p:plain

次に上図の構成を考えてみます。「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)としてマネジメントコンソール上で以下のように表示されます。

f:id:swx-satake:20200818180643p:plain:w350 ※この画像の Core は親OUと読み替えてください
この画像は「POLICIES INHERITED」で以下の3つが継承されていることがわかります。

  1. Root から FullAWSAccess を継承
  2. Core OU (親 OU) から DenyIAMEdit を継承
  3. Logs OU (子 OU) から FullAWSAccess を継承

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

  1. Logging Account 自体に FullAWSAccess 付与

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

調査3

f:id:swx-satake:20200818181229p:plain

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

調査結果を受けて

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

docs.aws.amazon.com

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

f:id:swx-satake:20200818181501p:plain

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

f:id:swx-satake:20200818193425p:plain

今回の「調査2」は表の「シナリオ3」に適合しており、結果自由な操作はできない状況に陥ってしまいました。

まとめ

f:id:swx-satake:20200818185726p:plain:w200

今回の記事では AWS Organizations のSCP の継承という言葉について掘り下げてみました。調査結果として、継承という言葉からイメージする動作とは少し違い「各階層がそれぞれ独立した権限で動作しており、そこを跨ぐことはない」という動作となっていることがわかりました。

ただ、SCPの設計では「明示的な拒否」を利用するシーンが多く、「明示的な許可」と「暗黙的な拒否」の関係を考えることは少ないため今回のようなシーンに出くわすことは稀かもしれません。 ですが、この記事が何かの参考になれば幸いです。

追記:後日、本ブログの続編として、以下の記事を記載しました。

blog.serverworks.co.jp

佐竹 陽一 (Yoichi Satake) 記事一覧はコチラ

SRE2課所属。AWS資格12冠。2010年1月からAWSを利用してきました。
AWSのコスト削減、最適化を得意としています。