はじめに

今回はAWS Organizationsの一機能であるSCPの継承についてご紹介します。
AWS Organizatoinsってなんだ？SCPってなんだ？と思った方は以前書いたこちらの記事をご確認ください。

SCPの継承とは

SCP(サービスコントロールポリシー)は、管理ルート・OU・メンバーアカウントそれぞれに1つ以上アタッチすることが出来ます。
その際、以下の公式説明の通り、上位にアタッチしたSCPが下位のOU・アカウントに継承されます。

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

継承については上図の通りなのですが、結局どの操作が許可/拒否されているのかよくわからないですね...
これを理解するために、以下について説明します。

ポリシーには暗黙のDeny、明示的なDeny、明示的なAllowがある
SCPは許可を与えるものではない
SCPの継承は許可を通すフィルターである

ポリシーには暗黙的なDeny、明示的なDeny、明示的なAllowがある

ポリシーには、暗黙的なDeny、明示的なDeny、明示的なAllowの3つがあります。

例えば、以下のようなSCP：SCPAllowLambdaDenyEc2がアタッチされているとします。

SCPAllowLambdaDenyEc2

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

この場合、

明示的なDeny：EC2の全てのActionをDeny
明示的なAllow：Lambdaの全てのActionをAllow
暗黙のDeny：それ以外を全てDeny
となります。

また、それぞれの優先順位としては
暗黙のDeny < 明示的なAllow < 明示的なDeny
になります。

つまり、このSCPの場合は
Lambdaの操作は全て許可するが、それ以外の操作は全て拒否となります。

複数のSCPがアタッチされた場合

複数のSCPがアタッチされている場合は、どうなるでしょうか？

SCPAllowLambdaDenyEc2

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

FullAwsAccess

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

暗黙のDeny < 明示的なAllow < 明示的なDenyの関係により、EC2操作は拒否されますが、それ以外の操作は全て許可されます。

SCPは許可を与えるものではない

これが良く勘違いしやすいポイントです！

先ほどSCPで許可する/拒否する、について説明しましたが、SCPで許可されていればアカウント内のIAMユーザやIAMロールは、対象リソースの操作を行うことが出来るのでしょうか？

先ほどの説明だけ見るとそのように思ってしまう(私自身も最近までそう思っていた)のですが、実は違います。
SCP自体は権限を与えるわけではなく、あくまで、組織内の権限の境界を定義するものなので、実際に権限を与えるには、IAMポリシーをアタッチする必要があります。

※IAMのアクセス許可の境界(Permission Boundary)のAWS Oranigazationsバージョンと思ってもらえればいいかと思います。

Identity Centerを利用しているなら権限セットをSSOユーザ/グループにアタッチします。

SCPの継承はフィルターである

SCPの継承は許可を通すフィルターのような扱いになります。

例えば、以下のようなに親OU、子OU、メンバーアカウントの組織構造の場合、管理ルート・OU・メンバーアカウント全てで許可された操作(全てのフィルターを通過した操作)が可能になります。
つまり、この場合だとLambda操作のみ許可されます！

やりがちなダメなパターン

フィルターということを忘れたダメなパターンです。
子OUで明示的なAllowが何もアタッチされていないためフィルターを通りません。

よって、管理ルート・親OU・メンバーアカウントでFullAwsAccessがアタッチされていてもメンバーアカウントではどの操作も許可されません。

拒否リストパターン ※推奨

次は拒否リストパターンになります。これがAWS推奨(というか、一番管理しやすい)のやり方になります。
全てでFullAwsAccessがアタッチされ、必要に応じて拒否するSCPをアタッチしています。

許可リストパターン

次は許可リストパターンになります。必要に応じて許可するSCPをアタッチしています。
この場合全ての管理ルート・OU・アカウントで明示的なAllowをしないと、暗黙のDenyによって拒否されてしまうので、拒否リストパターンと比べて視認性が低いです。

おわりに

今回は、SCPの継承について説明させて頂きました。
複数のOUや・アカウントにSCPをアタッチしていると、結局何が許可されて、何が拒否されるのかよくわからなくなったりするので、この記事を見てイメージ掴んでいただけると幸いです。