AWS Organizations におけるアクセス統制

記事タイトルとURLをコピーする

3月よりIE課(インターナルエデュケーション課) に異動しました山﨑です。

今回はAWS Organizations における「アクセス統制」について整理してみます

AWS Organizations におけるアクセス統制

AWS Organizations のおさらい

AWS Organizations とは要約すると、ユーザーが管理する「組織」と呼ばれる管理単位に1つ以上のAWSアカウントを統合することで、複数のAWSアカウントを効率的に一元管理することができるアカウント管理サービスです。一元管理をする上で、組織の長となるAWSアカウントを「Management Account」と呼び、その他のAWSアカウントを「Member Account」と呼びます。

詳細については以下のブログをご覧ください

blog.serverworks.co.jp

アクセス統制について

単一のAWSアカウントを利用する際は該当のAWSアカウント上でIAMユーザー(認証情報)を作成し、そのIAMユーザーにIAMポリシーを割り当てる(認可)ことでアクセスを管理、統制します。

本ブログではAWS Organizations 配下の各AWSアカウントを利用する際の認証認可を一元管理することをアクセス統制と呼称し、アクセス統制を実現するための2つの手段について整理します。

①IAM方式

IAM方式

IAM方式は専用のAWSアカウント(IAM管理アカウント)を作成し、IAM管理アカウントから各種AWSアカウントへスイッチロールを行う方法です。各AWSアカウントで実施する作業は以下の通りです。

IAM管理アカウント

IAMエンティティ

IAM管理アカウントでは、IAMエンティティとしてIAMユーザー、IAMグループ、IAMポリシーを作成します。

IAMエンティティ 概要
IAMユーザー 各種AWSアカウントへスイッチロールを行うユーザーを作成
IAMグループ ユーザーをグループ管理
IAMポリシー 以下2つのIAMポリシーを作成
①セキュリティを向上させるためにMFAを強制するIAMポリシー
②スイッチロールを許可するIAMポリシー

MFAを強制するポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowViewAccountInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowManageOwnPasswords",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword",
                "iam:GetUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnSigningCertificates",
            "Effect": "Allow",
            "Action": [
                "iam:DeleteSigningCertificate",
                "iam:ListSigningCertificates",
                "iam:UpdateSigningCertificate",
                "iam:UploadSigningCertificate"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnSSHPublicKeys",
            "Effect": "Allow",
            "Action": [
                "iam:DeleteSSHPublicKey",
                "iam:GetSSHPublicKey",
                "iam:ListSSHPublicKeys",
                "iam:UpdateSSHPublicKey",
                "iam:UploadSSHPublicKey"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnGitCredentials",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceSpecificCredential",
                "iam:DeleteServiceSpecificCredential",
                "iam:ListServiceSpecificCredentials",
                "iam:ResetServiceSpecificCredential",
                "iam:UpdateServiceSpecificCredential"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnVirtualMFADevice",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice"
            ],
            "Resource": "arn:aws:iam::*:mfa/*"
        },
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

スイッチロールを許可するポリシー

このIAMポリシーで「スイッチロールを許可するAWSアカウント」と「スイッチロール先のAWSアカウントで引き受ける権限(IAMロール)」を制御します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::<スイッチロール先のAWSアカウントID>:role/<引き受けるIAMロール名>",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

各種AWSアカウント

各AWSアカウントではユーザーに引き受けを許可する権限を定義したIAMロールを作成します。

IAMロールの例

IAMロール 概要
AdminRole AdministratorAccess権限(管理者権限)を付与
ReadOnlyRole ReadOnlyAccess権限(読み込み権限)を付与
MaintenanceRole 各AWSアカウントの運用に必要な権限を付与

各AWSアカウントで共通して作成するIAMロールと権限が決まっているのであれば、CloudFormation StackSets を利用することで一括デプロイすることも可能です。CloudFormation StackSets であれば自動デプロイ設定ができるため、新規AWSアカウントが発行された場合でも自動デプロイが可能です。

blog.serverworks.co.jp

運用イメージ

IAM管理アカウント

IAM管理アカウントでは、「ユーザーにスイッチロールを許可するAWSアカウント」と「スイッチロール先のAWSアカウントでユーザーに引き受けを許可するIAMロール」に応じてIAMポリシーを作成し、必要に応じてアタッチ・デタッチすることでアクセス統制を行う運用が考えられます。

各種AWSアカウントでスイッチロール用のIAMロールが追加/削除されれば、それに応じてIAM管理アカウントでもIAMポリシーを作成/削除する必要が出てきます。

# Policy Name 役割 メモ
1 Switch-HRPrd-AdminPolicy HR System OU 配下の本番アカウントにAdmin権限でスイッチロールをすることを許可 初期構築時以外は基本的に利用しない
2 Switch-HRPrd-ROPolicy HR System OU 配下の本番アカウントにRO権限でスイッチロールをすることを許可 AWS環境の閲覧用途に利用
3 Switch-HRPrd-MUPolicy HR System OU 配下の本番アカウントにMaintenance権限でスイッチロールをすることを許可 環境構築後のメンテナンス時に利用

各種AWSアカウント

各種AWSアカウントで考えられる運用としては「IAMロールのメンテナンス」「IAMロールの作成/削除」が考えられます。

「IAMロールのメンテナンス」に関しては、例えば新しいAWSサービスの利用を開始し運用保守を行う必要が出た場合、IAMロール(MaintenanceRole)に割り当てているIAMポリシーに対して新しいAWSサービスの操作権限を追加する、といった具合です。

「IAMロールの作成/削除」に関しては、先述した3つのIAMロール以外の用途でIAMロールが必要または不必要になった場合はにIAMロールの作成/削除を行う、といった具合です。

②SSO方式

SSO方式

SSO方式は専用のAWSアカウント(SSOアカウント)を作成し、SSOアカウントのIAM Identity Center で発行されたアクセスポータルサイトからシングルサインオンで各種AWSアカウントへスイッチロールを行う方法です。各AWSアカウントで実施する作業は以下の通りです。

Management Account

Management Accountでは、SSOアカウントに対してIAM Identity Center の統合と委任を有効化します。

aws organizations enable-aws-service-access --service-principal sso.amazonaws.com
aws organizations register-delegated-administrator --account-id <SSOアカウントのアカウントID> --service-principal sso.amazonaws.com

SSOアカウント

IAM Identity Center の概念図

SSOアカウントでは、IAM Identity Center を有効化して各種コンポーネントを作成し、アクセス先のAWSアカウントにそれらを関連付けます。より詳細について知りたい方は以下のブログも合わせてご覧ください

【AWS SSO】アクセス権の仕組みについて - サーバーワークスエンジニアブログ

【AWS SSO】アクセス権の設定方法 - サーバーワークスエンジニアブログ

IAMエンティティ 概要
SSOユーザー SSOにログインするための個々のユーザー
IDソースは「IAM Identity Center Directory」「Active Directory」「外部IDプロバイダー」のいずれかから選択可能
ID ソースを管理する - AWS IAM Identity Center (successor to AWS Single Sign-On)
SSOグループ SSOユーザーをグループ管理
アクセス許可セット AWSのリソースに対するアクセス許可の集合。SSOユーザーまたはSSOグループに割り当てることで権限を定義

関連付けが完了すると、関連付けたAWSアカウント上に「AWSReservedSSO_{関連付けたアクセス許可セット名}_xxxxxxxxxx」というIAMロールが自動作成されます。自動作成されたIAMロールはSSOアカウント以外のAWSアカウント上では操作不可です。

IAM Identity Center によるシングルサインオンの実態は、AWSアカウント上に自動作成されたIAMロールへのスイッチロールです。

IAM方式ではIAMグループにMFAを強制するIAMポリシーをアタッチしてセキュリティを高めていましたが、IAM Identity Center ではアクセスポータルサイトへのアクセスにMFAを設定することができます。

多要素認証を設定

運用イメージ

SSOアカウント

SSO方式の場合、各種AWSアカウントにログインするユーザー/グループ/権限を全てSSOアカウントで管理する必要があります。そのため、基本的にはエンドユーザーからの依頼に基づいてそれらをメンテナンスするという運用が考えられます

運用イメージ

IAM方式とSSO方式のどちらが良いの?

結論から言うと私としてSSO方式をオススメしたいです。以下、理由を列挙しています

  • IAMのサービスクォータでは、AWSアカウントが数十〜数百に拡張した際に耐えきれなくなる可能性が高い
  • IAM方式だとIAM管理アカウント以外での運用作業が発生するが、SSO方式だとSSOアカウント内で完結する
  • ユーザー目線だとSSO方式の方がUIがシンプルで分かりやすい
  • その他、SSO方式だとIDソースとしてActive Directoryや外部IDプロバイダーを指定できるため、既存IDリソースを活用しやすい

参考

IAM のサービスクォータ

リソース デフォルトクウォータ 上限緩和可否
IAMユーザー数 5,000 不可
IAMグループ数 300
最大500
IAMロール数 1,000
最大5,000
IAM ユーザーがメンバーになれるグループ 10 不可
IAM グループにアタッチされた管理ポリシー 10 不可

IAM クォータおよび AWS STS クォータ、名前の要件、および文字の制限 - AWS Identity and Access Management

IAM Identity Center のサービスクォータ

リソース デフォルトクウォータ 上限緩和可否
IAM Identity Centerで許可される許可セット数 2,000
AWSアカウントあたりに許可されるアクセス許可セット数 50
アクセス許可セットごとの管理ポリシーとカスタマー管理ポリシーの数 20 不可
IAM Identity Centerでサポートされるユーザの数 100,000
IAM Identity Centerでサポートされるグループの数 100,000 不可
設定可能なAWSアカウントまたはアプリケーションの総数 3,000

AWS IAM Identity Center (successor to AWS Single Sign-On) のクォータ - AWS IAM Identity Center (successor to AWS Single Sign-On)

まとめ

ということで、今回も超大作になってしまいましたが、AWS Organizations における「アクセス統制」について整理してみました。どなたかのお役に立てば幸いです。

山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ

カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers