yuj1osm's tech blog

クラウドやセキュリティなど

マルチアカウント構成とIAM設計

AWSアカウントを複数運用している組織は多いと思います。
今回はクロスアカウントアクセスを利用した、Jumpアカウント方式を紹介します。

各アカウントにIAMユーザを作成する問題点

AWSアカウントは用途ごとに分けた方が管理がしやすいです。
マルチアカウントの考え方については、以下が分かりやすいです。

https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf

例えば以下のように、開発/ステージング/本番と3つのアカウントがあったとします。
それぞれのアカウントにIAMユーザを作成すると、アカウントごとにログインが必要になります。
また、IAMユーザが増えていくことでユーザやポリシーの管理が煩雑になり、セキュリティ上のリスクも高まります。

クロスアカウントアクセスによるJumpアカウント方式

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

IAMの設計例

権限設計の切り口は様々ですが、チームリーダーはある程度の権限を持たせたいけどチームメンバーは権限を絞りたい、というのも一つの方法です。

以下のような設計にすると運用しやすくなると思います。

前提

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

設計ポイント解説

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

人員変更があれば、JumpアカウントでIAMユーザを作成/削除し、グループへの追加/削除をするだけです。
さらに、これらのグループやロールをCloudFormationで構成すると、自動化や管理がしやすくなります。

まとめ

マルチアカウントのIAM設計のうちJumpアカウント戦略について紹介しました。
マルチアカウントとIAMの設計はなかなか難しく、社内体制や事業拡大とともに変わっていくものです。
ユーザからの要望や組織の変化に合わせて、適宜見直していく運用が大事だと思います。