[AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう
はじめに
大阪オフィスの川原です。
AWS Organizations の SCP(サービスコントロールポリシー)の継承 について、 仕組みを学びましょう。
前提知識
Organizations
AWS Organizationsは マルチアカウントを統率するためのサービス です。 組織単位(OU) による アカウントのグループ化や、 サービスコントロールポリシー(SCP) によるグループ単位のサービス制限が可能です。
– 画像: AWS Organizations の用語と概念 | AWSドキュメント
OUとは
組織単位(Organizational Unit: OU) は AWSアカウントのグループ化 を実現する要素です。 OU 配下に他OUをぶらさげる、ツリー構造を構築できます。
SCPとは
サービスコントロールポリシー(SCP)は OUまたはアカウントに指定するポリシー です。 OU/アカウントで実行できるサービス・アクションを制限できます。 IAMポリシーと同じような記述で作成できます。
デフォルトではすべてのルート、OU、アカウントに FullAWSAccess という ポリシーがアタッチされています。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }
継承について
「継承」について、AWSのドキュメントには以下のように記載されています。
- ポリシーを組織ルートにアタッチすると、 組織内のすべての OU およびアカウントがそのポリシーを 継承 します。
- 特定の OU にポリシーをアタッチすると、 その OU または子 OU の直下にあるアカウントがポリシーを 継承 します。
- 特定のアカウントにポリシーをアタッチすると、そのアカウントにのみ影響します。
組織内の複数のレベルにポリシーをアタッチできるため、 アカウントは複数のポリシーを 継承 できます。
– 引用: ポリシーの継承について | AWSドキュメント
要は「ルート/OUに割り当てたポリシーは、そのルート/OU配下すべての要素に 継承 される」 ということです。
次章で SCP継承を考える際に抑えておきたいのポイントを書いていきます。
SCP継承を考える際のポイント
★「暗黙のDeny」を把握する
よく IAMのポリシー設計の際に聞く言葉ですが、同じように SCP設計でも考慮する必要があります。 以下 優先順位を抑えましょう。
- 暗黙のDeny < 明示的なAllow < 明示的なDeny
例えばOUに Deny Lambda(Lambdaアクションを禁止)
のSCP だけ アタッチされていたとします。
このOUのポリシーでは 何も出来ません 。暗黙のDenyがあるためです。
Lambda 以外のアクションを出来るようにするためには、 FullAWSAccess を追加でアタッチする必要があります。
「暗黙のDeny < 明示的なAllow(FullAWSAccess)」 の関係により、基本的には全アクションを許可されますが、 「明示的なAllow(FullAWSAccess) < 明示的なDeny(Deny Lambda)」 の関係により、Lambdaは禁止されます。
★SCP継承は「フィルター」である
SCPの継承は 許可を通すフィルター です。 「フィルター」がポイントです。 フィルター は 許可を通しますが、許可は与えません 。
例えば 以下のような OUーアカウントの構成を考えてみます。(ルートや他OUのポリシーは簡略化のため考慮しません)
OUに Lambdaを禁止するポリシー Deny Lambda
と
何かしらのサービス・リソースに対する操作を許可するポリシー Allow XXX
をアタッチします。
そして、OUに所属するアカウントには FullAWSAccess
をアタッチします。
※Organizationsのベストプラクティスとして、アカウントには基本的に FullAWSAccess
のみアタッチします
(OU単位で権限制御を行うため)。
このとき、 OUのポリシーはアカウントに「継承」 されます。 継承されたSCPは 許可を通すフィルター でしたね。 それを踏まえた上で、アカウントが実際にアクセスできるサービスの領域は以下のカッコ部分になります。
イメージ図、伝わりましたでしょうか。 改めて言うと、継承されたSCPは 許可を通すフィルター です。
SCP継承の例
拒否リストの例
Organizations で SCPを使った制御を行うとき、多くは拒否リスト形式の構成になります。 以下が拒否リスト形式の例です。
基本的にすべての要素(ルート/OU/アカウント)には FullAWSAccess
を付与します。
各OUに 許可されないアクセス を明示的に記したポリシーを付与していきます。
この例で「アカウント(子)が実際にアクセスできる領域」を表した図が以下になります。
今回の例ではアカウント(子)には FullAWSAccess
をアタッチしていますが、
子OU、親OUの継承によって IAM/VPCのアクションが禁止されています。
許可リストの例
許可されるサービスを列挙 して SCPとして記述していく構成が 許可リスト形式です。
以下が許可リスト形式の例です。
許可されるアクセスを明示的に記したSCPを作成して、各OUに適用します。 この例で「アカウント(子)が実際にアクセスできる領域」を表した図が以下になります。
暗黙のDenyを把握しておくことが重要です。 「明示的に許可したサービス以外は拒否する」フィルターになります。
ダメな例#1
ここま来れば容易に想像できる、ダメな例を紹介します。
一見拒否リスト形式に見えますが、アカウント(子)は 何もできません 。 以下図を見れば一目瞭然ですね。
「暗黙のDenyが存在すること」「継承は許可フィルターであること」 を失念したことにより起きた過ちです。
ダメな例#2
同じくアカウント(子)は 何もできません 。 以下図を見れば一目瞭然ですね。
「なにもできないもの」にフィルターを通しても「なにもできないもの」です。
おわりに
SCPの継承について理解するときのポイントを述べてみました。
改めて、SCPの継承は 許可を通すフィルター です。ただのフィルターです。許可を通しますが、与えません。 フィルターであることを把握すれば、スムーズにSCP設計ができると思います。
この記事が少しでもどなたかのお役に立てば幸いです。