管理者権限を持たせても、ルートユーザーとは別物だった

AdministratorAccessまであれば十分だと思った

第9回では、AWS Access Portalから三つのAWSアカウントへログインできることを確認しました。samekoro-adminが所属するSamekoro-Administratorsへ、AdministratorAccess許可セットを割り当てています。

ここまで設定すると、普段の確認や変更はほとんど同じ入口から行えます。そこで一度、「AdministratorAccessがあるなら、ルートユーザーはいらないのでは」と考えました。

名前にもAdministratorとあり、コンソールで多くの操作ができるため、違いはログイン方法だけにも見えました。しかし調べながら実際の入口を整理すると、二つは権限の強さだけで比べるものではありませんでした。

ルートユーザーとIAM Identity Centerユーザーではサインインの経路が異なります。ルートユーザーはAWSアカウントそのものの所有者として作られる認証情報です。一方、今回のAdministratorAccessは、IAM Identity Centerの許可セットを通して対象アカウントのロールへ付与される権限です。

普段のサービス操作だけを見ていると、どちらでも同じ画面を開ける場面が多くあります。そのため、自分の中では「強い権限」という一つの箱に入っていました。

違いが見えたのは、AWSにはルートユーザーの認証情報が必要な操作が残ると確認した時です。管理者用ポリシーで広い権限を持っていても、ルートユーザーとして認証されたことにはなりません。

今回の通常作業では、AWS Access Portalからsamekoro-adminで入り、許可セットを選びます。この入口では、IAM Identity Centerが管理するロールを使って各アカウントへアクセスします。

ルートユーザーはその経路の最上位版ではなく、別の認証情報を使う別経路です。

この二つに分けると、「AdministratorAccessよりさらに強い権限がルート」という理解だけでは足りないことが分かります。誰としてAWSへ入っているのかが違います。

第5回で普段の入口をIAM Identity Centerへ変えましたが、ルートユーザーを完全に使わなくしたわけではありません。ルート認証情報が必要な作業のために、別の入口として残します。

変えたのは、確認や設定変更のたびにルートユーザーで入る習慣です。通常作業はAWS Access Portalから始め、必要なアカウントを選びます。ルートユーザーは、該当する操作だと確認できた時だけ使います。

「ルートユーザーは普段使わない」と知識として分かっていても、自分で別の入口を作り、実際にサインアウトするまでは、運用として実感できていませんでした。

ルートユーザーと別物だと分かったからといって、AdministratorAccessを毎回使う状態が完成形になるわけではありません。AWS公式資料でも、日常作業ではより制限した許可セットを選べるようにする考え方が示されています。

今回確認できたのは、三つのアカウントへ入る管理者経路です。ここから先は、読むだけの作業、構築する作業、組織を管理する作業を同じ許可セットで行うのかを見直せます。

企業なら担当者や職務ごとに権限を分け、承認や緊急時の経路も含めて管理します。個人環境ではまず、ルートと通常作業の入口を分離し、その次に通常作業の中を細かくする順番にしました。

AWS Access Portalから管理・本番・検証へ入れることを確認し、最後にルートユーザーからサインアウトしました。ルートユーザーしか知らなかった頃と比べると、普段の入口と特別な入口を分けて選べる状態です。

管理者権限を持たせたことよりも、用途に応じて入口を変える運用を作れたことのほうが大きな変化でした。少しだけ、AWSを作る側から運用する側へ進めたように感じました。

AdministratorAccessとルートユーザーは同じではありません。前者は許可セットを通じて使う管理者権限、後者はAWSアカウント固有の認証情報です。

通常作業はAWS Access Portal、ルート認証情報が必要な操作だけはルートユーザー。この区別を残したことで、強い権限を一つ用意して終わりではなく、入口と用途を分けて考えられるようになりました。

次回からは、操作した記録をあとから追えるようにする準備へ進みます。第11回ではCloudTrailを取り上げ、実際に検証した内容で本文を更新します。