前回までのあらすじ
第1回から第4回までは、SAMEKORO LABを公開し、どこまで見せるかを整理するところまで進めました。第4回では、目的に合わなかったWAFを外しています。
外からサイトへ入る経路を考えたあと、今度は自分がAWSへ入る経路も気になりました。今回はAWS Organizationsの構成そのものには踏み込まず、普段の入口をルートユーザーからIAM Identity Centerへ変えた過程だけを振り返ります。
最初は「ルートユーザーでいいじゃん」と思っていた
AWSを使い始めた頃、自分が知っている入口はルートユーザーだけでした。ルートユーザー（＝AWSアカウント作成時に用意され、アカウント全体を扱える特別なユーザー）なら何でもできます。
自分で作ったAWSアカウントなのだから、その持ち主であるルートユーザーで作業すればよい。最初はかなり素直にそう思っていました。個人環境なので、ほかの人と権限を分ける場面もありません。
「ルートユーザーは普段使わない」と知識としては分かっていても、代わりの入口を自分で作っていない状態では、結局そこから入るしかありませんでした。
だんだん「これ、本当に毎日使っていいのかな？」と思い始めた
サイトの確認や小さな設定変更をするたび、同じ入口を使います。ルートユーザーでなければできない作業ではないのに、いつも一番特別な入口から入っている。その状態が、だんだん気になるようになりました。
何か問題が起きたわけではありません。ただ、普段の確認と、ルート認証情報が必要な操作が同じ入口に並んでいることへ違和感が残りました。「できるから使う」だけでは、運用として少し雑なのではないかと思い始めたのです。
AWS公式のルートユーザーのベストプラクティスを確認すると、日常作業には管理用の別ユーザーを使い、ルートユーザーはルート認証情報が必要な作業へ限定する考え方が示されています。そこで、まずは普段の入口を分けてみることにしました。
普段使いの入口を分けたくて、IAM Identity Centerを試した
使ったのはIAM Identity Center（＝複数のAWSアカウントへ入るユーザーと権限をまとめて管理するサービス）です。今回の環境では、管理アカウントの samekoro-management で設定しました。
目指したのは、機能をたくさん試すことではありません。通常作業ではAWS Access Portalから入り、ルートユーザーでのサインインはルート専用作業だけに残すことです。
この時点で考えていたのは、権限を弱くすることよりも、入口を分けることでした。普段使う扉を先に作らなければ、ルートユーザーから離れられないと思ったからです。
ユーザー、グループ、許可セット。名前が増えて少し混乱した
設定を始めると、samekoro-admin、Samekoro-Administrators、AdministratorAccess という似た雰囲気の名前が一度に出てきました。どれも管理者に見えて、最初は何をどこへ結び付けているのか少し混乱しました。
実際に作ったものへ戻って眺めると、役割は別でした。
samekoro-adminは、自分がAWS Access PortalへサインインするユーザーSamekoro-Administratorsは、そのユーザーが所属するグループAdministratorAccessは、対象アカウントで使う権限をまとめた許可セット
名前だけを覚えようとすると似ています。でも、「誰が」「どのまとまりに所属し」「どの権限で入るか」と順番に置くと、ようやくつながりました。
「AdministratorAccessがあるなら、ルートユーザーはいらないのでは？」と思った
ここで別の疑問が出ました。AdministratorAccess で管理作業ができるなら、もうルートユーザーはいらないのではないか、という疑問です。
名前にもAdministratorとあり、実際に多くの設定を変更できます。普段の作業だけを見れば、同じように何でもできる入口が二つあるように感じました。
調べながら設定を進めると、同じではないと分かりました。IAM Identity Centerの許可セットは、対象アカウントに用意されるIAMロール（＝必要なときに引き受けて権限を使う仕組み）を通して権限を使います。一方、ルートユーザーはAWSアカウントそのものに結び付いた特別なユーザーで、ルート認証情報が必要な操作は残ります。
つまり、AdministratorAccess があることは、ルートユーザーが不要になったことを意味しません。日常の管理作業を別の入口から行えるようになったということでした。「普段使わない」と「もう使わない」は別だと、ここで腑に落ちました。
図にすると、変えたのは権限より入口だった
今回の運用を図にすると、通常作業とルート専用作業は次のように分かれます。
AWS Access Portal普段の入口普段はAWS Access Portalから samekoro-admin で入り、所属グループと許可セットを通して3つのアカウントへ進みます。ルートユーザーは、その流れの上位にいるのではなく、ルート認証情報が必要な操作だけに使う別経路として残します。
図へ分けてみると、今回変えたものが単純な権限の強さではなく、AWSへ普段入るための入口だったことがよく分かりました。
AWS Access Portalから3つのアカウントへ入ってみた
設定後、AWS Access Portalへ samekoro-admin でサインインしました。今回の環境では、samekoro-management、samekoro-prod、samekoro-lab の3つが表示され、それぞれへ実際にログインできました。
設定画面でユーザーや許可セットが並んでいるだけでは、まだ入口を作った実感がありませんでした。ポータルからアカウントを選び、いつものAWSコンソールが開いたところで、ようやく普段使いの経路がつながったと感じました。
3つのアカウントがなぜ分かれているのか、どのように管理しているのかは、ここでは扱いません。今回は「同じ入口から必要なアカウントを選べる」と確認できたところまでです。
個人環境では、まずこの運用から始めることにした
通常作業はIAM Identity Center経由、ルートユーザーはルート認証情報が必要な操作だけ。この二つを、今の基本運用にしました。
AdministratorAccess は広い権限です。企業で複数人が扱うなら、担当に合わせた許可セット、最小権限、緊急時のルート利用手順まで決める必要があります。個人環境の今回は、いきなり細かく分け切るより、まず日常の入口をルートユーザーから切り離すことを優先しました。
入口を分けたから完成ではありません。普段の作業に本当に必要な権限は、これから見直せます。それでも、何でもできる入口を毎回使う状態から一歩進めたことには意味がありました。
ルートユーザーからサインアウトした
3つのアカウントへ入れることを確認したあと、最後にルートユーザーからサインアウトしました。
AWSを始めた頃は、ルートユーザーしか入口を知りませんでした。そこから、自分で普段の入口を作り、特別な入口を必要なときだけ使う形へ変えられました。サインアウトした瞬間に大きく画面が変わるわけではありませんが、少しだけAWSを「使う側」から「運用する側」へ進めたように感じました。
ルートユーザーを完全に使わなくしたわけではありません。必要な場面に備えて残しつつ、日常からは離す。その距離感を自分の環境で作れたことが、今回一番の変化でした。
まとめ
今回変えたのは、単純な権限の強さではなく、AWSへ普段入るための入口です。通常作業はAWS Access Portalから samekoro-admin で入り、ルートユーザーはルート認証情報が必要な作業だけに残しました。
「ルートユーザーは普段使わない」と知識として分かっていても、自分で別の入口を作り、実際にサインアウトするまでは、運用として実感できていませんでした。AdministratorAccess とルートユーザーが同じではないことも、二つの経路を自分で分けたことで理解できました。
次回は、今回ログインを確認した3つのアカウントがどう分かれているのかを見ていきます。「AWS Organizationsで管理アカウントとLabを分けた話」へ続きます。