[アップデート]待望!管理アカウントでメンバーアカウントのルートユーザ操作禁止などが設定できるRoot access managementがリリースされました!
はじめに
ContorlTower/Organizations使用者にとって今年1番熱いアップデートが来ました!!Organizationsを使用している際に、管理アカウントから各メンバーアカウントのルートユーザを使用禁止や、ルートユーザ特有の操作の実行が可能になりました!
具体的には管理アカウントから以下の操作が可能になります。
- ルートユーザに対して以下を実施
- 認証情報、パスワード、署名証明書、MFA設定、セッション情報の削除
- パスワードリセットの禁止
- ルートユーザ特有の操作の実行
- S3のバケットポリシーを削除
- SQSのキューポリシーを削除
公式ブログ
この機能の何が嬉しいのか
今までは管理アカウントを管理していた方は、管理アカウントから払い出すメンバーアカウントの管理が必要でした。その中で厳しく制限を行う場合は、SecurityHubのコントロールに準拠しようとするとIAM.6でルートユーザにハードウェアMFAの設定を行う必要がありました。
もしハードウェアMFAを適用するとなった場合、アカウント単位でハードウェアMFAを用意するのか、全メンバーアカウントに同じハードウェアMFAを使うのか、ハードウェアMFAを設定しないか判断が必要でした。設定すると判断した場合は、定期的に手動でのハードウェアMFA設定が必要です。この作業は自動化できないためいくら他の作業を自動化しても大量にアカウントを発行する場合負担になっていました。
またメンバーアカウントのルートユーザは強い権限であるため、ハードウェアMFAを設定できても権限分離で課題ができ、なかなか決定版となるような管理方法がありませんでした。
今回のRoot access management機能によってルートユーザのパスワード/MFAを削除しパスワードリセットを禁止することで、ルートユーザの使用を禁止することができます。管理アカウントからこの設定は有効化できるので、管理範囲が管理アカウントに限定でき、作業の省力化が期待できます。
またこの機能にはS3バケットポリシーとSQSキューポリシーの削除が含まれています!コレがでかい!
SCPでルートユーザの操作を一切禁止するとした場合でも、誤って誰も操作できないバケットポリシーを付与してしまうとルートユーザでの操作が必要でした。
以前のアップデートでメンバーアカウントの削除やメールアドレス変更は可能になり、このS3バケットポリシー削除が最後に起きやすい問題でした。このためだけにルートユーザが必要だったところ、今回のアップデートで管理アカウントに権限さえあればポリシー削除が可能なので、ほぼ完全にメンバーアカウントのルートユーザは不要になります!
ここからは実際に機能を有効化します。その後に既存のアカウントの場合と新規アカウント発行した場合で、挙動に違いがあるか確認します。
機能の有効化
まずはコンソールから機能を有効化してみます。IAMの画面に入ると、サイドバーにRoot access managementメニューが追加されています。
こちらを開いて有効化をクリックします。
Root credential managementとPrivileged root action in member accountsの2つの機能を有効化するか確認されます。前者はルートユーザの資格情報削除、パスワード回復の許可を設定するもので、後者はメンバーアカウントのS3/SQSのリソースポリシー削除を許可する機能です。今回は両方とも有効化します。
画面下部で委任管理も可能であることが確認できます。今回は特に設定せず管理アカウントのままで進めます。有効化を押下します。
押下すると画面が戻り、上記のようにRoot credential managementとPrivileged root action in member accountsが有効になっていることが確認できます。次章からは既存のアカウントに上記の機能を使用してみます。
既存のアカウントの場合
再びサイドバーからRoot access managementを開くと、既存のOrganizationsの構成が表示されます。
OU単位では選択できず、アカウント単位で選択できます。アカウントを選択すると、「特権的なアクションを実行する」がアクティブになるので押下します。※ちなみに管理アカウントは選択しても「特権的なアクションを実行する」はアクティブにならないので実行できません。
3つのメニューDelete S3 Bucket Policy
Delete SQS queue policy
Delete root user credentials
が表示されます。
Delete root user credentials
ここではDelete root user credentialsを選択します。
ルートユーザのアクセスキーやパスワード、署名証明書、MFAが削除され、パスワードリセットも禁止されることが記載されています。内容を確認して、Delete root user credentials
を押下します。
再度適用してよいか確認が入るので、確認
を入力して削除
を押下します。すると画面が戻って削除が完了します。事前にルートユーザでログインしているとこのタイミングでセッションが削除されました。
ここからはルートユーザでログインを試してみます。ルートユーザで再度ログインしようとすると以下のように認証情報が無効になっていることが確認できます。
パスワードリセットを試すと、パスワードリセット用のメール送信まではできます。
ただ、メール受信、パスワードリセット用のURLのリンクに飛ぶまでは出来ますが、以下のようにパスワードリセットが禁止されていることが確認できます。
ここからは管理アカウントに戻ります。もしパスワードを回復させたくなった場合はRoot access management
で以下のように表示され、パスワードリセットでの回復が可能になります。
Delete S3 Bucket Policy
Delete S3 Bucket Policy
を選択すると以下のようにS3 URIを指定する画面が出て、バケットポリシーの削除が実行できます。またS3参照からアカウント内のバケットを確認し選択することも出来ました。
Delete SQS queue policy
Delete S3 Bucket Policy
を選択すると以下のようにSQSのキューのARNを指定することで、キューポリシーを削除できます。
新規のアカウントの場合
次は新規のアカウントがどんな挙動になるのか確認してみます。新規でCTからアカウントを作成し、8のアカウントIDから始まるアカウントを作成しました。このアカウントをRoot access management
で確認してみると以下のように最初からAllowする選択になっているため、すでにルートユーザでのログインを禁止できていることが確認できます。
既存アカウントと同じようにパスワードリセットを試してみると、以下のように禁止されていることが確認できます。
上記から、Root access managementを有効化した組織では新規で作成したアカウントはルートユーザを禁止した状態で展開できることが分かります。
所感
ごく一部の方にとっては念願の機能がリリースされました。既存のユーザもリセット可能であったり、S3バケットポリシーが削除可能であるなど欲しいものがほぼ揃っているような素晴らしい機能でした。あとは最後に1アカウントずつ適用すると大変なので、OU単位でまとめて権限削除が可能になると嬉しいですね。
個人的に熱いアップデートだったので、心当たりある方は是非試してみてください!