AWS Organizationsのサービスコントロールポリシー(SCP)の話

はじめに

AWS Organizationsは大きく分けて、Payerをまとめる機能とSCPにより認可設定する機能があります。今回は、SCP機能で何ができるかを整理したいと思います。

SCPを理解するためのポイント

SCPを付与する対象(エンティティ)

SCPを付与する対象(エンティティ)は、組織のツリー構造のルートにあたるRootとOUとAWSアカウントになります。
マスターのAWSアカウントにもSCPを付与できますが、実際は権限制限できません。

サービスコントロールポリシーは、マスターアカウントがどの root または OU に属していても、マスターアカウントに適用されません。
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies.html

Root、OU、AWSアカウント、SCPの関係は以下の様なイメージになります。

権限管理が可能な対象(プリンシパル)

SCPの付与した場合の、権限管理が可能な対象(プリンシパル)は以下になります。

 Rootユーザ
 IAMユーザ
 IAMロール

以下のプリンシパルは適用外になります。

 組織のマスターアカウントに存在する全てのプリンシパル
 メンバーアカウントのサービスにリンクされたロール(Service-linked Role)
 リソースベースのポリシーで権限を付与された外部ユーザ
   例) S3のバケットポリシーで許可した外部アカウントのIAMユーザなど

ブラックリストとホワイトリスト

SCPの記載方法ですが、利用を禁止するブラックリスト方式と利用を許可するホワイトリスト方式があります。

ブラックリストの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1549502804000",
            "Effect": "Deny",
            "Action": [
                "dynamodb:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

ホワイトリストの例

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

IAMと同じで基本、暗黙的Deny＜明示的Allow＜明示的Denyの順で右に行くほど優先度が高くなります。
ただし、暗黙的なDenyの実際のケースとして、例えばOUでFullAWSAccessをアタッチしている場合で、AWSアカウントにホワイトリストをアタッチすると、ホワイトリストで明示的に許可したサービス以外利用できなくなります。
以下の例だと、Account1はOUの暗黙的なDenyが優先されるため、EC2のみ使用できる形になります。

OUとAWSアカウントで入れ子に設定できるため、想定されるパターンをテストしてみます。
前提となる構成は以下になります。Rootには、「FullAWSAccess」がアタッチされていて、IAMポリシーは、FullAccess権限がある前提です。

ホワイトリストのパターン

ホワイトリストの注意点としては、AWSアカウントにデフォルトで「FullAWSAccess」が付与されているためデタッチする必要があります。ただ、ルート、OU、AWSアカウントには最低1つのSCPがアタッチされている必要があるため、新規にSCPを作成して、アタッチしたあとに「FullAWSAccess」をデタッチします。

ホワイトリストの内容は、EC2の操作(ec2:*)を許可する。
AWSアカウントを任意のOUに移動することで権限管理できる方がシンプルなため、AWSアカウントはFullAWSAccessでOU単位でホワイトリストをアタッチするパターンが管理しやすいと思います。。(青線で囲ったところ)

ブラックリストのパターン

ブラックリストの内容は、DynamoDBの操作(dynamodb:*)を拒否する。
OU,AWSアカウントの両方でFullAWSAccess権限を持ちつつ不要な操作をOU側のブラックリストで拒否するパターンが管理しやすいと思います。(青線で囲ったところ)

ブラックリストとホワイトリストの併用

OUでの管理を基本とするのであれば、AWSアカウントはFullAWSAccssをアタッチして、OUでブラックリストとホワイトリストのSCPをアタッチするパターンがパターンが管理しやすいと思います。

ホワイトリストで入れ子状態になったパターン

EC2のみ操作可能で、EC2以外は暗黙的なDenyが有効になり操作できません。

ブラックリストで入れ子状態になったパターン1

親OUでブラックしかアタッチされていないため、すべての操作が拒否されます。

ブラックリストで入れ子状態になったパターン2

DynamoDBに操作不可。DynamoDB以外の操作は可能です。

実際の組織構造を想定したOU構成

ブラックリストでガバナンスを効かせる

想定されるユースケース※マニュアルより抜粋
例 1: ユーザーによる AWS CloudTrail の無効化を禁止する例
2: ユーザーによる Amazon CloudWatch の無効化または設定の変更を禁止する
例 3: ユーザーによる Amazon VPC フローログの削除を禁止する
例 4: ユーザーによる AWS Config の無効化またはルールの変更を禁止する
例 5: インターネットアクセスに接続されていない VPC を使用した取得を禁止する

ホワイトリストで使用するサービスを明示的に許可したい場合

Service用のOUは、EC2やRDSなどエンドユーザ向けのサービスで使用するAWSサービスをホワイトリストで許可する。
Operation用のOU(ログ集約用のアカウント)は、ログ保管を目的としているため、S3などデータをアーカイブするために必要となるAWSサービスのみの使用を許可する。

折衷案

ホワイトリストとブラックリストの併用。
使用するAWSサービスを明示的に許可しつつ、明示的に禁止したい監査系のサービス停止を拒否するような構成です。

お約束

投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。