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

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

川原征大

2020.09.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

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

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設計ができると思います。

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

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

はじめに