[Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう

SCPの継承は許可を通すフィルターです
2020.09.01

はじめに

大阪オフィスの川原です。

AWS Organizations の SCP(サービスコントロールポリシー)の継承 について、 仕組みを学びましょう。

前提知識

Organizations

AWS Organizationsは マルチアカウントを統率するためのサービス です。 組織単位(OU) による アカウントのグループ化や、 サービスコントロールポリシー(SCP) によるグループ単位のサービス制限が可能です。

img

– 画像: 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 だけ アタッチされていたとします。

img

このOUのポリシーでは 何も出来ません 。暗黙のDenyがあるためです。

img

Lambda 以外のアクションを出来るようにするためには、 FullAWSAccess を追加でアタッチする必要があります。

img

「暗黙のDeny < 明示的なAllow(FullAWSAccess)」 の関係により、基本的には全アクションを許可されますが、 「明示的なAllow(FullAWSAccess) < 明示的なDeny(Deny Lambda)」 の関係により、Lambdaは禁止されます。

★SCP継承は「フィルター」である

SCPの継承は 許可を通すフィルター です。 「フィルター」がポイントです。 フィルター は 許可を通しますが、許可は与えません

例えば 以下のような OUーアカウントの構成を考えてみます。(ルートや他OUのポリシーは簡略化のため考慮しません)

img

OUに Lambdaを禁止するポリシー Deny Lambda と 何かしらのサービス・リソースに対する操作を許可するポリシー Allow XXX をアタッチします。 そして、OUに所属するアカウントには FullAWSAccess をアタッチします。 ※Organizationsのベストプラクティスとして、アカウントには基本的に FullAWSAccess のみアタッチします (OU単位で権限制御を行うため)。

このとき、 OUのポリシーはアカウントに「継承」 されます。 継承されたSCPは 許可を通すフィルター でしたね。 それを踏まえた上で、アカウントが実際にアクセスできるサービスの領域は以下のカッコ部分になります。

img

イメージ図、伝わりましたでしょうか。 改めて言うと、継承されたSCPは 許可を通すフィルター です。

SCP継承の例

拒否リストの例

Organizations で SCPを使った制御を行うとき、多くは拒否リスト形式の構成になります。 以下が拒否リスト形式の例です。

img

基本的にすべての要素(ルート/OU/アカウント)には FullAWSAccess を付与します。 各OUに 許可されないアクセス を明示的に記したポリシーを付与していきます。

この例で「アカウント(子)が実際にアクセスできる領域」を表した図が以下になります。

img

今回の例ではアカウント(子)には FullAWSAccess をアタッチしていますが、 子OU、親OUの継承によって IAM/VPCのアクションが禁止されています。

許可リストの例

許可されるサービスを列挙 して SCPとして記述していく構成が 許可リスト形式です。
以下が許可リスト形式の例です。

img

許可されるアクセスを明示的に記したSCPを作成して、各OUに適用します。 この例で「アカウント(子)が実際にアクセスできる領域」を表した図が以下になります。

img

暗黙のDenyを把握しておくことが重要です。 「明示的に許可したサービス以外は拒否する」フィルターになります。

ダメな例#1

ここま来れば容易に想像できる、ダメな例を紹介します。

img

一見拒否リスト形式に見えますが、アカウント(子)は 何もできません 。 以下図を見れば一目瞭然ですね。

img

「暗黙のDenyが存在すること」「継承は許可フィルターであること」 を失念したことにより起きた過ちです。

ダメな例#2

img

同じくアカウント(子)は 何もできません 。 以下図を見れば一目瞭然ですね。

img

「なにもできないもの」にフィルターを通しても「なにもできないもの」です。

おわりに

SCPの継承について理解するときのポイントを述べてみました。

改めて、SCPの継承は 許可を通すフィルター です。ただのフィルターです。許可を通しますが、与えません。 フィルターであることを把握すれば、スムーズにSCP設計ができると思います。

この記事が少しでもどなたかのお役に立てば幸いです。

参考