はじめに
今回は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
がアタッチされているとします。
{
"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がアタッチされている場合は、どうなるでしょうか?
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "lambda:*",
"Resource": "*"
}
]
}
{
"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をアタッチしていると、結局何が許可されて、何が拒否されるのかよくわからなくなったりするので、この記事を見てイメージ掴んでいただけると幸いです。