AWS OrganizationsのSCP（サービスコントロールポリシー）を理解する

#AWS Organizations

#AWS

中山順博

2018.05.29

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

はじめに

中山（順）です

Organizations使ってますか？

大規模な組織や何らかの理由でAWSアカウントを大量に利用するケースにおいて、請求や権限制御は悩みの種だと思います。請求についてはConsolidated Billingや弊社をはじめとするAWSのパートナーが提供する請求代行サービスで事務処理などの負担は軽減できていたかと思います。しかし、権限制御については各AWSアカウントのIAMを設定する必要がありました（CloudFormationのStackSetでIAM関連リソースの展開自体は容易に可能だと思います）。

AWS OrganizationsのSCP(Service Control Policy)を利用することで、複数のAWSアカウントに対する権限の制御が可能になっています。

この記事では、SCPの概要 / SCPでできること・できないことを述べ、具体的にどのようなケースで利用すべきか考えていきます。銀の弾丸ではない、ということは先に申し上げておきます。

SCP(Service Control Policy)とは

すでに述べたように、SCPは組織に含まれる複数のAWSアカウントに対してざっくりとした権限制御を行うための仕組みです。

まずはSCPの構成要素とその概要を説明します。

前提条件

Organizationsの初期設定（機能セットの選択）時に"All Feature"（すべての機能）を選択する必要があります。

組織内のすべての機能の有効化

なお、機能セットは後から変更することも可能です。その場合、参加しているメンバーアカウントに対して承認リクエストが送信され、全てのリクエストが承認されることですべての機能を利用できるようになります。正直めんどくさいので、将来的にSCPを利用する可能性があるようであれば最初から全ての機能を有効化していいのではないかと思います。

OU（組織単位）

OUはAWSアカウントをグループ化するための概念です。これによって、ポリシーの適用などの管理作業を大幅に簡素化できます。

OUはデフォルトで存在するルートOUを頂点に階層構造で管理されており、下位のOUは上位のOUに適用されたポリシーを継承します。

組織単位 (OU) の管理

ポリシー

OUもしくはアカウントに割り当てるポリシーを独立したリソースとして定義できます。 OUにポリシーを割り当てるとそのOUに所属するアカウントにポリシーが適用されます。また、すでに述べたとおり下位のOUにポリシーが継承されます。

Organizationsにおいて、現時点では1つだけですがAWSによって定義済みのポリシーが存在します。それ以外のポリシーはユーザー自身で定義する必要があります。

AWS 管理ポリシーを AWS Organizations 組織で使用可能

ポリシーの影響範囲

ポリシーの影響範囲については少し注意する必要があります。

まずは、影響する範囲は以下の通りです。

メンバーアカウントの以下のプリンシパル
Root User
IAM User
IAM Role

逆に、以下のプリンシパルには影響しません。

組織のマスターアカウントに存在する全てのプリンシパル
メンバーアカウントの以下のプリンシパル
Service-linked Role
リソースベースのポリシーで権限を付与された外部ユーザ

ここで注目すべきなのは、「Root Userの権限を制限できる」および「マスターアカウントの権限は制限できない」の2点です。

「Root Userの権限を制限できる」という仕様によって、Root Userの不正利用が発生した場合のリスクをかなり軽減できると一瞬思いました（過去形）。ただし、以下のアクションはSCPで制限されません。

ルート認証情報の管理。アタッチされている SCP に関係なく、アカウントの root ユーザーはいつでも次の操作を実行できます。
ルートユーザーのパスワードの変更
ルートアクセスキーの作成、更新、削除
ルートユーザーの多要素認証の有効化または無効化
ルートユーザーの x.509 キーの作成、更新、または削除
ルートユーザーとしての Enterprise サポートプランへの登録
ルートユーザーとしてのアカウントの解約 (AWS サポートにチケットを送信する代わりにアカウント内から)
ルートユーザーとしての AWS サポートレベルの変更
CloudFront キーの管理
CloudFront プライベートコンテンツの信頼された署名者の機能
AWS アカウントメールの上限/rDNS の変更

ということで、Root Userの位置づけが特別なのはあまり変わりませんし、普段使いしてはいけないこともこれまでと同様です。逆に何らかの事情でRoot Userを普段使いしていてSCPを利用する場合にはRoot Userも影響を受けるということを認識しておきましょう（そもそも、セキュリティベストプラクティスに基づいてIAMへ移行しましょう）。

これらの正確な仕様については以下のドキュメントを確認してください。

サービスコントロールポリシー

また、「マスターアカウントの権限は制限できない」という仕様を踏まえるとマスターアカウントでは管理用途での利用に限定するのが適切ではないかと思います。具体的なユースケースとしてはAWS Answersの以下のソリューションが参考になるかと思います。

AWS Multiple Account Security Strategy

ポリシー構文

ポリシーの構文は公式ドキュメントを参照してください。 SCPでは以下の点に留意する必要があります。

Action要素のワイルドカード (*) 文字は、ポリシー自体、または文字列の末尾にのみ使用可能（先頭もしくは中間には利用できない）
NotAction要素は利用できない
Resource要素は"*"しか指定できない
Principal要素は利用できない
Condition要素は利用できない

サービス管理ポリシー構文

通常のIAMポリシーと比べるとできることが非常に少ないです。しかし、SCPではこのくらい十分な気もします。 Conditionは使えるとありがたいのですが。

IAMとの関係

アクセス権の管理はOrganizationsの登場以前にはIAMによって管理されていました。 SCPを利用する場合、リクエストを実行できるかはどのように決まるのでしょうか？

ざっくり書くと、SCPとIAMの両方で許可されている場合に実行可能です。もう少し具体的に書くと、「双方で明示的に許可され」なおかつ「いずれでも明示的に拒否されていない」場合に権限を有していると評価されます。

詳細はドキュメントを確認してください。

サービスコントロールポリシーについて

実際のSCPの適用アプローチですが、ポリシー構文でも説明したとおりSCPの表現力には制限があります。

そのため、「ざっくりとした」制限をSCPで実施し、細かい制御をIAMで実施する、というアプローチが適切かと思います。

また、SCPでのアクセス制御のアプローチとしては、ブラックリスト方式とホワイトリスト方式が考えられると思います。どちらが適切かは要件次第です。

SCP を使用した戦略

やってみた

組織の作成とメンバーアカウントの作成が完了していることを前提に、SCPの有効化とポリシーの定義・割り当てを行い、最後に動作確認を行ってみます。

SCPを有効化

組織の作成時に機能セットで"All Feature"を選択した場合であっても、SCPの利用前に機能の有効化が必要です。有効化は「アカウントの整理」の画面から実行できます。「有効化」をクリックしてください。

これでSCPを利用できるようになります。有効化直後にRoot OUに割り当てられたポリシーを確認してみると、マネージドポリシーである"FullAWSAccess"というポリシーが割り当てられています。「IAMとの関係」の項で説明したとおり、SCPとIAMの両方で許可されたアクションのみ実行できますので、組織の作成直後にSCPを有効化しただけであれば既存のIAMユーザーなどに影響を与えることはありません。

この後、OUの作成やOU間でのアカウントの移動、OUに対するポリシーの割り当てなどを行っていますが、これらの作業を行うことで既存のIAMユーザーなどに影響が出ます。 本番環境への適用時には十分に事前評価を行い、万が一の際にはロールバックできるように手順を整備して作業に臨んでください。

OUを作成

Rootの配下にOUを作成します。ツリービューでRootが表示されていることを確認したうえで、「+ 新規組織単位」をクリックします。

OU名を入力し、「組織単位の作成」をクリックします。

すると、ツリービューからRoot配下にOUが作成されたことが確認できます。

作成したOUを選択すると、そのOUにはアカウントが所属していないことを確認できます。

割り当てられているポリシーを確認すると、Root OUから"FullAWSAccess"が継承されていることを確認できます。ちなみに、継承されたポリシーは手動でデタッチすることが可能です。ただし、OUには1つ以上のポリシーを割り当てておく必要があるため、デタッチ前に他のポリシーを割り当てる必要があります。

アカウントを作成したOUに移動

Root OUに含まれるメンバーアカウントを作成したOUへ移動させてみたいと思います。移動させたいアカウントを選択し、「移動」をクリックします。

ダイアログが表示されるため、移動先のOUを選択し、「移動」をクリックします。

すると、以下のようにアカウントが移動されます。

ポリシーを定義

次にポリシーの定義を行います。

今回はホワイトリスト方式のポリシー割り当てを行います。そのため、ここで定義するポリシーを割り当てつつ、Root OUから継承された"FullAWSAccess"をデタッチします。これによって作成したポリシーで許可したアクションしか実行できないアカウントになるはずです。

今回は以下のようなポリシーを作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*"
            ],
            "Resource": "*"
        }
    ]
}

「ポリシー」のタブを選択すると、ポリシーの一覧が表示されます。ここで「ポリシーの作成」をクリックします。