0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

Posted at

はじめに

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

SCPの継承とは

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

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

image.png

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

  • ポリシーには暗黙の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の操作は全て許可するが、それ以外の操作は全て拒否となります。

image.png

複数の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操作は拒否されますが、それ以外の操作は全て許可されます。

image.png

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

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

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

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

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

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

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

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

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

image.png

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

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

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

image.png

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

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

image.png

許可リストパターン

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

image.png

おわりに

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?