3月よりIE課（インターナルエデュケーション課） に異動しました山﨑です。
サウナブームが到来しているせいか、毎週通っているサウナの人が徐々に増えてきて困っております
さて、今回はAWS Organizations におけるSCP設計のポイントを整理してみようと思います。
おさらい
SCPとは
SCPとは「Service Control Polices」というAWS Organizations の機能を示しています。AWS公式ドキュメントでは「SCPs」と称していますが、複数形の「s」を省略して「SCP」と呼ばれることが多いです。SCPは、OUまたはAWSアカウントに関連付けることで各種AWSサービスへのアクセス制御を実現します。
SCPで初めに押さえておくべき5つのポイント
①SCPは最初に評価されるアクセスポリシー
SCPはAWSが提供するアクセスポリシーの中で最初に評価されるアクセスポリシーです。そのため、IAMポリシーで「AdministratorAccess」権限を付与していたとしても、SCPで「Deny」しているアクションは実行することができません。詳細は以下のブログをご覧ください。
②SCPの有効範囲はIAMユーザーとIAMロールのみ
先程紹介したブログにも記載されていますが、SCPではS3バケットポリシーやKMSキーポリシーといった「リソースベースのポリシー」は適用範囲外であるためSCPによる制御はできません。
③Management Account はSCPを用いたアクセス制御は不可
SCPは Member Account にのみ適用されるため、Management Account に対して同様のアクセス制御をする場合は「アイデンティティベースのポリシー（IAM）」で個別に制御する必要があります。
④1つのOUまたはAWSアカウントには5つまでアタッチ可能
SCPは1つのOUまたはAWSアカウントに対して5つまでしか適用することはできません。これは上限緩和申請をしてもリミットを上げることができないためご注意ください。その他、SCPに関連する制限については以下のブログをご覧ください。
⑤SCPは下位のOU階層に継承可能
SCPは1つのOUまたはAWSアカウントに5つまでアタッチ可能ですが、「継承」と呼ばれる仕組みを利用することで、最大35個のSCPをアタッチすることができます。「継承」とは上位のOU階層にアタッチされているSCPが、下位のOUおよびAWSアカウントにも同様に適用される仕組みを示しています。
「継承」に関する詳細は内容については以下のブログをご覧ください。
SCP設計のポイント
①拒否リストとしてSCPを利用する
AWSではSCPの利用方法として「許可リスト」「拒否リスト」のいずれかを採用することができますが、設計難易度と運用負荷を考慮して「拒否リスト」として利用し、細かなアクセス制御は各AWSアカウントのIAMを利用することを推奨します。
| 利用方法 | メリット | デメリット |
|---|---|---|
| 許可リスト | ・AWSのIAMのベストプラクティス （最小権限の許可）に従って細かなアクセス制御を行うことができる。 ・新しいAWSサービスが一般公開された場合、デフォルトでそのサービスへのアクセスはブロックされるため意図しないサービス利用を予防できる。 |
・アクセスを明示的に許可するアクションを漏れなくリストアップして定義する必要があるため、設計難易度が高い。 ・新たにAWSサービスを利用したり、新たなアクションを利用したい場合、サービス利用に際して明示的に許可するアクションを漏れなくリストアップする必要があるため運用負荷が高い。 |
| 拒否リスト | ・明示的に拒否したいアクションのみを定義するため、設計難易度と運用負荷が低い ・拒否リストという特性上、AWS Organizations 組織におけるガードレールとして機能させることができる |
・拒否リストにない全てのAWSサービスへのアクセスは許可されるため、細かなアクセス制御は各AWSアカウントのIAMを利用して設定する必要がある。 ・新しいAWSサービスが一般公開された場合、意図しないサービス利用を予防するために都度、拒否リストを修正する必要がある。 |
②上位のOU階層にアタッチするSCPから順番に設計する
SCPを設計する際は上位のOU階層にアタッチするSCPから順番に設計することを推奨します。それはSCPの「継承」という仕組みを利用する場合、OUの上位階層に行けば行くほど汎用性が高い制御内容にする必要があるからです。
- ForceMFA：MFA設定をしていない場合、MFA設定以外の操作を禁止する（汎用性: 高）
- DenyCreateEC2Instance：EC2インスタンスの作成を禁止する（特殊性: 高）
会社組織で策定されているルール（規則）と並べてみるとイメージしやすいのではないかと思います。会社には様々なルールがありますが、社員は定められた「全社ルール」「部内ルール」「課内ルール」を遵守しながら業務を遂行する必要があります。部内ルールは全社ルールを遵守することを前提に策定し、課内ルールは部内ルールを遵守することを前提に策定されます。このような手順を踏むことにより、会社で定められた規則（ルール）を社員が漏れなく遵守することが期待できます。
AWS Organizations 組織においても同様に上位のOU階層にアタッチするSCPから順番に設計することで、遵守すべきルールの漏れを最小限に抑えた設計が期待できるのではないかと考えています。
③5W1HでSCPの要件を整理する
SCPでポリシーを設計する前に「5W1H」の形式で、制御内容を整理します。
| Who(何が) | Where(何に対して) | When(どんな条件下で) | What(どんな操作を) | Want(どうしたい) |
|---|---|---|---|---|
| ・指定したAWSアカウント ・指定したOU内の全アカウント ・指定したOUの下位の階層に含まれる全アカウント（継承） |
要整理 | 要整理 | 要整理 | Deny |
SCP の要件を整理する上ではWant（どうしたい）は決まっているので、残りは以下を整理します。
- Who(何が)
- どのメンバーアカウント、どのOUに適用するのか
- Where(何に対して)
- Resource要素
- When(どんな条件下で)
- Condition要素
- What(どんな操作を)
- Action要素
④ポリシーの記述方法を押さえる
SCPにおけるポリシー記述方法は基本的にIAMポリシーの記述方法と変わりません。まずは以下の5つの要素を押さえておけば基本的なSCPの記述方法を理解することができます。
| 要素 | 説明 |
|---|---|
| Sid | 記述するポリシーの説明を記述し、他のポリシーとの区別する。 |
| Effect | 操作を許可(Allow)するか、拒否(Deny)するかを記述する。 |
| Action | 具体的な操作内容を記述する。 |
| Resource | ポリシーの適用範囲(どのAWSリソースに適用するか)を記述する。 |
| Condition | どういった条件下でポリシーを適用するのかを記述する。 |
※参考ドキュメント：IAM JSON ポリシー要素のリファレンス - AWS Identity and Access Management
ポリシー例
{ "Version": "2012-10-17", "Statement": [ { "Sid": "EC2FullAccess", "Effect": "Allow", "Action": "ec2:*", "Resource": "\*", "Condition": { "StringEquals": { "aws:PrincipalArn": "arn:aws:iam::123456789123:user/yamasaki-user" } } ] }
SCPのサンプルポリシー
汎用性が高いSCPと、特殊性が高いSCPについてそれぞれ1つずつサンプルポリシーをご紹介します。その他のSCPについては以下ブログまたはAWS公式ドキュメント化をご覧ください。
汎用性が高いSCP
ForceEncryptionPolices
- EBS構築時にストレージ暗号化を強制
- RDS構築時にストレージ暗号化を強制
- EFS構築時にストレージ暗号化を強制
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ForceRDSStorageEncryption", "Effect": "Deny", "Action": [ "rds:CreateDBInstance", "rds:CreateDBCluster" ], "Resource": [ "*" ], "Condition": { "Bool": { "rds:StorageEncrypted": "false" } } }, { "Sid": "ForceEBSStorageEncryption", "Effect": "Deny", "Action": [ "ec2:RunInstances", "ec2:CreateVolume" ], "Resource": [ "*" ], "Condition": { "Bool": { "ec2:Encrypted": "false" } } }, { "Sid": "ForceEFSStorageEncryption", "Effect": "Deny", "Action": [ "elasticfilesystem:CreateFileSystem" ], "Resource": [ "*" ], "Condition": { "Bool": { "elasticfilesystem:Encrypted": "false" } } } ] }
特殊性が高いSCP
DenyNetworkComponents
Transit Gatewayの削除 Direct Connect Gatewayの削除 Direct Connect の接続の削除 VIFの削除 VPCの削除 Route53 Resolver Endpoint の削除 NetworkFirewall の削除
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNWComponentsOperations", "Effect": "Deny", "Action": [ "ec2:DeleteTransitGateway", "directconnect:DeleteDirectConnectGateway", "directconnect:DeleteConnection", "directconnect:DeleteVirtualInterface", "ec2:DeleteVpc", "route53resolver:DeleteResolverEndpoint", "network-firewall:DeleteFirewall" ], "Resource": [ "*" ] } ] }
まとめ
SCP設計のポイントは以下の4点
- ①拒否リストとしてSCPを利用する
- ②上位のOU階層にアタッチするSCPから順番に設計する
- ③5W1HでSCPの要件を整理する
- ④ポリシーの記述方法を押さえる
どなたかのお役に立てれば幸いです
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers
