https://yuj1osm.hatenablog.com/entry/20221205/1670215444

7編にわたって、「Change Managerによる変更管理と本番アクセス統制」について紹介しています。

前回の「①動機づけ編」では、変更管理と本番アクセス統制の必要性を紹介しました。
今回の「②マルチアカウント&IAM設計編」では、本番アクセス統制の前提となるマルチアカウント設計とIAM設計について紹介します。

AWSアカウントとは

AWSアカウントは、AWSリソースに対するセキュリティ、アクセス、課金の境界を提供してくれる単位です。

AWSアカウントに登録されているIAMユーザは、AWSアカウント内のリソースにアクセスできますが、外部のユーザはアクセスできません。
課金もアカウント単位で請求されます。

個人で簡単な検証をする分には単一アカウントでも十分ですが、企業で扱うワークロードの規模が大きく複雑になると、アカウントを分離したマルチアカウント構成の方が様々な恩恵を受けることができます。

マルチアカウント構成のメリット

マルチアカウント構成の嬉しいところを以下にあげます。

セキュリティやガバナンス

オンプレミスで、1つのワークロードに対してサーバを分離するという考えがありますが、クラウドにも同様の考えが適用できます。

代表的な切り口として、開発環境/ステージング環境/本番環境という分離方法があります。
こうすることで、本番環境にログインできるメンバーを最小限にしたり、各環境に適したセキュリティ対策を行うことができます。

課金

単一アカウントの運用だと、どのワークロードがどれほど課金されているかが分かりづらくなります。
アカウントを分離することで、各アカウントに対する課金が明確になり、責任範囲やコスト削減のコントロールがしやすくなります。

運用

変更作業を実施した際の影響範囲を局所化することができます。まずは開発環境やステージング環境で変更作業やパッチ適用などを試したのち、本番環境へ適用することが容易になるため、サービス障害の可能性を低減できます。.

Jumpアカウント方式

マルチアカウント構成にした際に、どのようにユーザにログインしてもらうかを考えます。
前述のような、開発環境/ステージング環境/本番環境の3面構成を例にします。

それぞれのアカウントにIAMユーザを作成すると、アカウントごとにログインが必要になってしまいます。
さらに、IAMユーザが増えるにつれてポリシーの管理が複雑になり、セキュリティリスクが高まる要因になります。

このような場合、ユーザを1つのアカウントに集約するという方法があります。
Jumpアカウント方式やSSO方式がありますが、ここではJumpアカウント方式を紹介します。

Jumpアカウントを用意し、そこにIAMユーザを集約します。
そして、各アカウントにスイッチするロールを用意します。

利用者は、まずJumpアカウントにログインし、各アカウントへスイッチロールすることでログインすることができます。
各アカウントでどのような操作を許可するかは、スイッチ先のロールに対して必要な権限を付与すればよいです。

IAM設計のコツ

権限設計の切り口は様々ですが、チームリーダーはある程度の権限を持たせたいけどチームメンバーは権限を絞りたい、というのも一つの方法です。そのような場合、以下のような設計にすると運用しやすくなると思います。

前提

前述の開発環境/ステージング環境/本番環境の3面構成
admin01/admin02：Jumpアカウントの管理者
leader01：チームリーダー
member01：チームメンバー

設計ポイント解説

Jumpアカウントで、管理者グループ「JumpAdminGroup」、リーダーグループ「LeaderGroup」、メンバーグループ「MemberGroup」を作成し、IAMユーザを所属させる。
Jumpアカウントで、管理者ロール「Jump_AdminRole」を作成し、管理者グループ「JumpAdminGroup」からのみスイッチロールを許可する。
※管理者同士のクロスチェックや緊急時に対応できるようにするため、管理者権限を持つユーザは複数人いるとよいでしょう。
管理者ロール「Jump_AdminRole」は、JumpアカウントのIAMユーザやグループの管理に使用する。
開発環境/ステージング環境/本番環境で、リーダーロール「LeaderRole」、メンバーロール「MenberRole」、読み取り専用ロール「_ReadOnlyRole」を作成する。
読み取り専用ロール「_ReadOnlyRole」は、リーダーとメンバーの両方がスイッチでき、設定確認のみの場合はこのロールを使うルールにする。
※設定確認するだけのために高い権限を与えていると、操作ミスで設定を変更してしまう可能性があるため、読み取り専用ロールは作成しておくとよいです。例えば、Linuxでずっとrootのまま作業しませんよね？
リーダーロール「_LeaderRole」は、リーダーグループ「LeaderGroup」からのみスイッチロールを許可し、サポート問い合わせや課金情報閲覧などある程度の権限を与えておく。
メンバーロール「_MemberRole」は、メンバーグループ「MemberGroup」からのみスイッチロールを許可し、開発運用に必要な権限のみ与えておく。