[AWS Organizations]特定メンバーの行動は制限しない SCP記述

2020.11.16

この記事は公開されてから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ロール ) といった書き方、登録方法も可能です。

試してみる

img

先の 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のみ なので、何も出来ません(以下イメージ)

img

なので、 FullAWSAccessを忘れずに付けましょう

img

また、この対応を行う際の 影響範囲 を事前に精査しましょう。

  • (対応前) 許可リスト( Allow × Action ) 形式。 許可されない操作は 暗黙のDeny で拒否されている
  • (対応後) 許可リスト( Deny × NotAction + FullAWSAccess ) 形式。 許可されない操作は 明示的なDeny で拒否されている

明示的なDenyは一番強い です。 仮に「実は管轄外で 何か SCPがアタッチされていて、特定操作を許可していた」 としても Deny × NotAction の部分で Deny されていると、特定操作は実行できません。

NotActionの部分に漏れなく、許可するアクションのリストを埋め込むことが大事です。

おわりに

  • 運用管理者は権限を絞りたくない
  • でも、それ以外 普段のAWS利用者にはガードレールを敷くためにもガッツリSCP運用していきたい

そういったケースに、今回紹介した SCP記述が活用できると思います。 少しでもどなたかのお役に立てば幸いです。

参考