AWS コンソールへのログイン管理を整理した(している)ので、覚え書き。
書いているのは以下の範囲。
- AWS コンソールへのログイン管理
- 複数の AWS アカウント(マルチアカウント)を集約
要件はこんな感じ。
(アカウント数は少ないけど、今後増えたときに展開しやすいようにしたい)
- 踏台アカウント方式を利用
- AWS コンソールへのログインは MFA 認証を有効化
- 設定を Terraform でコード化
記事が長くなるので、方針検討編と実装編を分けることにしました。
ロール切替方式の権限設定一式を作成する
https://qiita.com/batatch/items/08aa3f705336a0fea89e
ロール切替用にユーザを作成し、MFA 認証を有効にする
https://qiita.com/batatch/items/9bebb1710e26960075b6
方式検討
マルチアカウントなユーザ管理にはいくつか方式があって、次の記事で分かりやすく整理されています。
AWSのマルチアカウント管理ことはじめ ログインの一元化の設計
https://blog.takuros.net/entry/2020/12/01/094417
- 外部 ID プロバイダ連携
- AWS Organizations + AWS SSO
- 踏台アカウント ★採用
今回は AWS Organizations が利用できないケースなので、踏台形式で構成することにします。
アカウント数が少なかったり、請求代行会社を使ってる場合で AWS Organizations の利用が適切でないことがあります。
踏台形式では、代表となる AWS アカウント(以下、マスターアカウント) にユーザ、グループ登録を集約し、対象の AWS アカウント(以下、ターゲットアカウント) にはロールを登録して、AWS アカウントをまたがってロールを切り替える(スイッチロール) という仕組みを利用するようです。
次の記事の説明が分かりやすいです。
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる
https://iselegant.hatenablog.com/entry/2020/05/24/215808
この辺を読んで概要はつかめます。
。。が、実際に適用するとなると、何をどう設定するか分からずモヤモヤしたので、自分なりに実施したことをまとめてみます。
構成
ロール切替について、図を描いてみます。
登場人物はこんな感じ。
マスターアカウント
- 類語: 踏台アカウント、代表アカウント、JUMP アカウントなど
- IAM ユーザ、グループを登録し、どのアカウントのどのロールへ切替可能かを設定する
ターゲットアカウント
- 類語: 作業アカウント、メンバーアカウントなど
- IAM ロールで権限を設定する。マスターアカウントからのロール切替の許可設定をする
IAM のどの設定をどこに～というのが分かりにくかったので、その辺を表現してみます。
他、以下のような用語もよく出てきます。
文脈によって同じことを指していたり、微妙に違ったりで混乱します。。
スイッチロール(Switch Role)
ロールを切り替える「行為」のこと
アシュームロール(Assume Role)
ロール切替を実現する AWS の仕組み、機能のこと
ちなみに、ロール切替では IAM 設定のユーザ、グループ、ロール、ポリシーという要素が複雑に絡んで実現されるので、各要素についてきちんと整理した方がいいかもしれません。
それぞれの要素の関連は以下のように描けると思います。
権限そのものを定義するのがポリシーで、ポリシーの紐づけ対象としてユーザ(、グループ)、もしくはロールがあります。
- 人(ログインユーザ) に権限持たせる → ユーザ(、グループ)
- プログラムや AWS リソースに持たせる → ロール
ロール切替では、通常はユーザに割り当てられないロールを一時的に割り当てて権限を取得する形になります。
仕組み的にはユーザに直接ロールを紐づけるのではなく、ロールが割り当てられた仮想的なユーザ(AssumedRoleUser) が作られて成り代わる形のようです。
アバターとか着ぐるみ、擬人化のようなものでしょうか。
アイコンがヘルメットの絵なのは、役目の被り物を表しているってことですかね。
この形であれば、権限の持たせ方はロール定義だけに集約されるので、ユーザ(、グループ) にはどのロールへ切替可能かだけの設定になって、見通しよくなりますね。
なお、ロールが割り当てられるのはなく擬人化する形なので、複数のロールへ切替可能にしても、権限の合成にはなりません。
ロール切替構成になると、操作上は以下のようになります。
ログイン先が１個所になるので操作がシンプルになります。
AWS アカウントを行き来するのもメニューから選ぶだけ(初回、登録手続きが必要) なので楽になります。
ただ、残念なことに同時に複数アカウントの画面を開きたい場合は、ブラウザのセッションが共有なのでタブでは同時に開きっぱなしにはできないようです。
自分は Chrome のユーザを AWS アカウント毎に作ってセッションを分けています。
ユーザのログイン設定
ロール切替によってユーザ登録をマスターアカウントに集約できることになったので、次はユーザ登録について。
マスターアカウントに IAM ユーザを登録し、MFA 認証を有効にするとして、他にもやっておきたい設定があります。
- ユーザ自身に自分でパスワードを変更できるようにする
- ユーザ自身に MFA 仮想デバイスを自分で登録できるようにする
これらについては、公式ドキュメントで説明がありました。
AWS: IAM ユーザーがセキュリティ認証情報ページで自分のコンソールのパスワードを管理できるようにする
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage-password-only.html
AWS: MFA で認証された IAM ユーザーがセキュリティ認証情報ページで自分の MFA デバイスを管理できるようにする
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.html
これらのポリシーを付与した共通グループを用意し、全 IAM ユーザを所属させる形が分かりやすいですね。
ロール計画
各ターゲットアカウントにロールを用意することになります。
マスターアカウントにはロール x ターゲットアカウント分の切替グループが必要になるので、あまり細分化したり、個々のアカウントに特化したものになると管理が煩雑になります。
上にあげた参考文献などを見ていると、全アカウントで共通のロールに統一するのがよさそうです。
- Administrator (管理者)
- Maintainer (作業者)
- Developer (開発者)
- etc..
| role \ account | アカウント1 | アカウント2 | アカウント3 | ... |
|---|---|---|---|---|
| Administrator | a1_Admin | a2_Admin | a3_Admin | ... |
| Maintainer | a1_Maintain | a2_Maintain | a3_Maintain | ... |
| Developer | a1_Develop | a2_Develop | a3_Develop | ... |
| : | : | : | : | ... |
AWS では、あらかじめ職務機能毎のポリシー定義が用意されているので、これらをベースにしながら設定するのがいいかもしれません。
Administrator ロールには AdministratorAccess ポリシーを設定するなど。
AWS: 職務機能の AWS 管理ポリシー
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_job-functions.html
例)
- 管理者 AdministratorAccess
- Billing(料金) Billing
- データベース管理者 DatabaseAdministrator
- 開発者パワーユーザー PowerUserAccess
- ネットワーク管理者 NetworkAdministrator
- セキュリティ監査人 SecurityAudit
- サポートユーザー SupportUser
インフラのコード化
インフラの設定は、できればコード化しておきたいです。
画面操作で設定してしまうと忘れちゃうし、手順書など何らかの情報共有が必要になります。
どうせ作るなら実行できるコードがいいですよね。
方法はいろいろありますが、HashiCorp 社の Terraform が定番のようです。
Terraform
https://www.terraform.io/
今回のユーザ設定も Terraform でコード化していきます。
ユーザ設定は AWS アカウント自体の初期設定となるので、Terraform のコードを「どこで実行するか？」で悩みました。
- 初期設定なので、EC2 インスタンスなどの OS 環境がまだない
- 自分のパソコンなどから API キーによるアクセスは禁止したい
これを解決するいいサービスがありました。
AWS Cloud Shell
https://aws.amazon.com/jp/blogs/news/aws-cloudshell-command-line-access-to-aws-resources/
ブラウザ上でさくっとシェルコマンドが使えて、AWS API なども叩けます。
最初の作業用に管理者用の捨て IAM ユーザを作成して、Cloud Shell で terraform を実行してユーザを設定します。
ユーザを設定した後、捨てユーザを削除すれば、すべてコード管理された IAM ユーザで利用開始できます。
今回はここまで。
長くなってきたので実装編は別記事にします。
// EOF