この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
AWS Organizations はマルチアカウントを統率するためのサービスで、 組織単位(OU) によるAWSアカウントのグループ化など可能です。
サービスコントロールポリシー(SCP) は、OUに対して指定するものです。 SCPによって OU配下のアカウントで実行できるサービス・アクションを まとめて制限 することができます。
※SCPの簡単な説明、および継承については以下ブログにまとめています。
さて、SCPによる制限は強いです。 ルートユーザーでさえ 、SCPで禁止されたAWS操作は行うことができません。 この強さはメリットですが、AWS環境を運用する上で不便になることがあります。 運用管理者(Administrator)が日々の運用業務を行う際に、 SCPで禁止されていて実施できない、といったことがあるためです。
そこで本記事では 「運用管理者は SCPで縛られないようにしたい」 要望があることを想定して、それを実現するためのSCP記述例を紹介します。
特定メンバーは例外とするSCP
早速ですが SCP記述例を載せます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCreateVPC",
"Effect": "Deny",
"Action": [
"ec2:CreateVpc"
],
"Resource": "*",
"Condition": {
"StringNotLike":{
"aws:PrincipalARN":[
"arn:aws:iam::*:root",
"arn:aws:iam::*:role/operator"
]
}
}
}
]
}
- VPC新規作成する操作を禁止する
- ただし
ルートユーザー
およびIAMロール "operator"
は例外
となる SCPです。
ハイライトしている部分、 Condition
を利用して例外を指定しています。
IAMユーザーやIAMグループを例外としたい場合は、 以下の表を参考に書き換えて下さい。
例外登録したいもの | ARN 例 |
---|---|
ルート | arn:aws:iam::*:root |
IAMロール | arn:aws:iam::*:role/operator |
IAMユーザー | arn:aws:iam::*:user/special-user |
IAMグループ | arn:aws:iam::*:group/operators |
また、ワイルドカードを使って
arn:aws:iam::*:role/admin-*
( "admin-" で始まるIAMロール )
といった書き方、登録方法も可能です。
試してみる
先の SCPが継承されたアカウントで操作してみます。 ※実施するIAMロールには AdministratorAccess が付与されています。
arn:aws:iam::*:role/operator
で実施
> aws ec2 create-vpc --cidr-block 10.10.20.0/24
{
"Vpc": {
"CidrBlock": "10.10.20.0/24",
"DhcpOptionsId": "dopt-xxx",
"State": "pending",
"VpcId": "vpc-xxx",
"OwnerId": "73xxx",
"InstanceTenancy": "default",
"Ipv6CidrBlockAssociationSet": [],
"CidrBlockAssociationSet": [
{
"AssociationId": "vpc-cidr-assoc-xxx",
"CidrBlock": "10.10.20.0/24",
"CidrBlockState": {
"State": "associated"
}
}
],
"IsDefault": false
}
}
VPC作成ができました。
arn:aws:iam::*:role/cm-kawahara.masahiro
で実施
> aws ec2 create-vpc --cidr-block 10.10.10.0/24
An error occurred (UnauthorizedOperation) when calling the CreateVpc operation:
You are not authorized to perform this operation. Encoded authorization failure message: a9nCbMRmeNX7kKfdP_WzrWOO(略)
失敗しました。どのアクションで失敗したか確認してみます。
> message="a9nCbMRmeNX7kKfdP_WzrWOO(略)"
> aws sts decode-authorization-message --encoded-message $message | jq -r '.DecodedMessage' | jq -c '.context.action'
"ec2:CreateVpc"
VPCの作成で失敗しています。 operator
を除いて、SCPの制御が効いていることが分かります。
(追記) 許可リスト形式 SCPの場合
許可リスト形式 SCPで制限を行っている場合は少し工夫が必要です。 Allow ステートメントでは Conditionを利用できない ためです。
例えば以下のような許可リスト形式のSCPを OUにアタッチして、運用していたとします。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowList",
"Effect": "Allow",
"Resource": "*",
"Action": [
"ec2:*",
"vpc:*",
"iam:*"
]
}
]
}
ステートメントは "Effect:Allow" なので、先程説明した Condition
は付けることが出来ません。
このような場合は、 Allow × Action の組み合わせではなく Deny × NotAction の組み合わせで対応しましょう。
具体的には、以下のようなSCPとなります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNotActionList",
"Effect": "Deny",
"Resource": "*",
"NotAction": [
"ec2:*",
"vpc:*",
"iam:*"
],
"Condition": {
"StringNotLike":{
"aws:PrincipalARN":[
"arn:aws:iam::*:root",
"arn:aws:iam::*:role/operator"
]
}
}
}
]
}
【注意】FullAWSAccessも付与すること + 影響範囲を調査すること
上記ポリシーだけでは 明示的な Denyのみ なので、何も出来ません(以下イメージ)
なので、 FullAWSAccessを忘れずに付けましょう 。
また、この対応を行う際の 影響範囲 を事前に精査しましょう。
- (対応前) 許可リスト(
Allow × Action
) 形式。 許可されない操作は 暗黙のDeny で拒否されている - (対応後) 許可リスト(
Deny × NotAction + FullAWSAccess
) 形式。 許可されない操作は 明示的なDeny で拒否されている
明示的なDenyは一番強い です。
仮に「実は管轄外で 何か SCPがアタッチされていて、特定操作を許可していた」
としても Deny × NotAction
の部分で Deny されていると、特定操作は実行できません。
NotActionの部分に漏れなく、許可するアクションのリストを埋め込むことが大事です。
おわりに
- 運用管理者は権限を絞りたくない
- でも、それ以外 普段のAWS利用者にはガードレールを敷くためにもガッツリSCP運用していきたい
そういったケースに、今回紹介した SCP記述が活用できると思います。 少しでもどなたかのお役に立てば幸いです。