AWS OrganizationsのSCPの継承について調べてみた ～AWS100本ノック～ 28/100

# はじめに

今回はAWS Organizationsの一機能である**SCP**の継承についてご紹介します。
AWS Organizatoinsってなんだ？SCPってなんだ？と思った方は以前書いた[こちらの記事](https://qiita.com/namasa/items/5e2d14b97911b0afded8)をご確認ください。

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/ecd732b3-049d-434e-a500-81d8750b3930.png)

継承については上図の通りなのですが、結局どの操作が許可/拒否されているのかよくわからないですね...
これを理解するために、以下について説明します。
- ポリシーには`暗黙のDeny、明示的なDeny、明示的なAllowがある`
- SCPは`許可を与えるものではない`
- SCPの継承は`許可を通すフィルター`である

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

例えば、以下のような`SCP：SCPAllowLambdaDenyEc2`がアタッチされているとします。
```json: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の操作は全て許可するが、それ以外の操作は全て拒否となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/3b91a84b-95ea-4a06-83de-fad48003856d.png)

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

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

```json:FullAwsAccess
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}
```
**暗黙のDeny < 明示的なAllow < 明示的なDeny**の関係により、EC2操作は拒否されますが、それ以外の操作は全て許可されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/a4de957d-1ca1-44e0-8b2b-e763a7862f0b.png)

# SCPは許可を与えるものではない
これが良く勘違いしやすいポイントです！


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

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

※IAMの[アクセス許可の境界(Permission Boundary)](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html)のAWS Oranigazationsバージョンと思ってもらえればいいかと思います。

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


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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/3df98a1d-167d-4039-83f3-8d3773415390.png)

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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/8abaf35c-538e-4766-bae2-df6e76737cc0.png)


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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/18f459dd-00a0-4dd2-a297-20cccc31c17e.png)


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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/954aeae8-954f-461b-8ae5-efb69dd890dd.png)


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