前置き
前回の「インフラ歴2ヶ月がつまづいたアカウント運用管理入門」に引き続き、アカウント運用管理発展です。
案件を通じて学んだIAM OrganizationsとIAM Identity Centerについて、どのような仕組みのサービスなのかを説明していきます。
前回と同様、具体的な実装手段の説明はせず、用語の説明、概念的理解の補助に努める記事となっていますので、その点ご了承ください。
前提知識
アカウント運用の基礎知識
前回記事でも紹介した、AWS IAMとスイッチロールの知識を確認して欲しいです。
インフラ初心者がつまづいたアカウント運用管理入門
マルチアカウント戦略
複数のAWSアカウントを利用して、異なるプロジェクト、部門、または環境（開発、テスト、本番など）を管理する方法のことを指します。
前回の記事でも、環境が3つあることを仮定して話を進めたところがありました。それをイメージしていただくといいと思います。
マルチアカウント戦略を行うメリットとして以下の3点が挙げられます。
-
セキュリティの強化
アカウント間でアクセスを分離することにより、特定のアカウントで発生したセキュリティインシデントが他のアカウントに波及しないようにできるため、セキュリティリスクを大幅に軽減できます。 -
コスト管理の強化
アカウントごとにコストを明確に追跡できるため、コスト配分タグを使わずに各アカウントの消費を直接把握することができます。
これにより、プロジェクトや部門ごとの予算管理やコスト削減が容易になります。 -
サービスの耐障害性の強化
障害が発生した際に、アカウントごとにリソースが分離されているため、影響範囲をそのアカウント内に限定することができます。
これにより、他のアカウントに影響を与えず、サービスの耐障害性が強化されます。
シングルサインオン（SSO）
シングルサインオン（SSO）は、複数のサービスに対して一つの認証を行うことでアクセスできる仕組みです。
ユーザーは一度のログインで複数のAWSアカウントやサービスにアクセスすることができます。
ユーザーは一度のログインで複数のサービスにアクセスできるようになるのです。
SNSアカウントと連携させてログインする方式も、一種のSSOと考えて良いでしょう。
AWS Organizations
AWS Organizations 概要
AWS Organizationsは、複数のAWSアカウントを組織のように一元管理できるようにするサービスです。
Organizations特有のアカウント作成、管理、ポリシー適用など、様々なことができます。
アカウントの違い
このOrganizationsを有効にしたアカウントは「管理アカウント」と呼ばれます。
また、Organizationsで作成したAWSアカウント（またはOrganizationsへ招待し、参加したアカウント）は「メンバーアカウント」と呼ばれます。
各メンバーアカウントの利用料金は、管理アカウントでまとめて管理、または請求を受けることができます。
アカウント管理の基本単位はOU（Organizational Unit / 組織単位）となっています。このOUを利用して、メンバーアカウントを階層構造で整理することができます。
IAM グループの対象がユーザーからアカウントになり、ただグルーピングできるだけでなく、上下関係を持った、というイメージでしょうか。
サービスコントロールポリシー / SCP
サービスコントロールポリシー（SCP）は、AWS Organizationsで使用されるポリシーで、メンバーアカウントやOUに対して適用されるアクセス制御のルールを定義することができます。SCPは、IAMポリシーとは異なり、AWSサービスに対する「許可の上限」を設定するもので、SCPで許可されないアクションは、そのアカウント内で実行することができません。
上図をもとに例を挙げましょう。
例えば、Project OUに「S3の削除操作を禁止する」SCPを適用します。
そうすると、このProject OU内のアカウント（今回はありあせんが）と、その配下のOU（prod OU、Stg OU、Dev OU）にも「S3の削除操作を禁止する」SCPが適用されます。
これらOUに所属しているアカウント内のユーザーは、IAMポリシーで「S3FullAccess」の許可がされていたとしても、「許可の上限」として設けられた「S3の削除操作」以上の操作ができません。
この特性を利用し、より上位のOUに対して許可の上限を設けることで、個別のアカウントやアプリケーションごとに制約を設定する手間を省くことができます。
IAM Identity Center / IdC（旧AWS SSO）
IAM Identity Centerの概要
IAM Identity Center（旧AWS SSO）は、AWS上でのSSO機能を提供するサービスで、複数のAWSアカウントやビジネスアプリケーションに対して、統一されたアクセス管理を実現します。
これにより、ユーザーが一つの認証情報で複数のアカウントやアプリケーションにアクセスできるようになります。
このIAM Identiry Centerは、AWS Organizationsを有効化し、組織の管理アカウントとして指定されたアカウントで利用することが推奨されています。
IAM Identity Centerは、この管理アカウントを通じて設定・運用され、各メンバーアカウントへのアクセスを統一的に管理します。
IAM Identity Centerの主な機能
主な機能は以下の通りとなっています。
-
SSOの提供
ユーザーが一度のログインで複数のAWSアカウントやサードパーティのクラウドアプリケーションにアクセスできる機能を提供し、認証プロセスを簡単にします。
このSSOの実現のためにも、IAM Identity Center特有のユーザー、またグループを作成する必要があります。 -
ユーザーとアクセス権限の一元管理
ユーザーとグループを一元的に管理し、細かなアクセス権限の設定を行うことで、セキュリティと運用効率を向上させます。
例えば、全ユーザーに対して多要素認証（MFA）を適用するなど、一貫したセキュリティ対策を実施することが可能です。 -
監査とガバナンスの強化
ユーザーアクティビティの監査やポリシーの一元管理を通じて、組織全体のセキュリティガバナンスを強化できます。
これにより、コンプライアンス要件の遵守が容易になり、潜在的なセキュリティリスクを早期に検出して対処できるようになります。
組織インスタンスとアカウントインスタンス
IAM Identity Centerを有効にする際に、インスタンスタイプを選択する必要があります。
Organizationsの管理アカウントでIAM Identity Centerを有効にした場合は、アカウントインスタンスを利用してIAM Identity Centerを開始することはできません。
代わりに、自動的に組織インスタンスが作成され、その上でIAM Identity Centerの利用が開始されます。
そしてOrganizationsの管理アカウント以外、つまりOrganizationsのメンバーアカウントかOrganizationsに属していないアカウントではアカウントインスタンスを利用することが可能です。
それらアカウントでIAM Identity Centerの利用を開始しようとしたとき、「AWS Organizations で有効にする（組織インスタンスを作成するということ）」、「このアカウントのみで有効にする（アカウントインスタンスを作成するということ）」の選択を行えます。
スクショ1
ここで「AWS Organizations で有効にする（組織インスタンスを作成するということ）」を選択した場合は、Organizationsの作成とIAM Identity Centerの有効化が同時に行われます。
組織インスタンスとアカウントインスタンスの作成時の違いは以上の通りです。どちらのインスタンスでも、最低限SSO機能は利用できますが、一部機能は利用の可否が異なります。
組織インスタンスでできて、アカウントインスタンスでできないことは以下の項目通りになります。
-
マルチアカウント権限
組織インスタンスでは、AWS Organizationsを使用して複数のアカウントを一元管理し、統一されたポリシーや権限を適用できます。
一方、アカウントインスタンスでは、個別のアカウントごとに権限管理を行う必要があります。 -
AWSへのSSOアクセス用のアクセスポータルAWSアカウント
組織インスタンスでは、IAM Identity Centerを利用して、ユーザーが一度のログインで複数のAWSアカウントやクラウドアプリケーションにアクセスできるポータルを提供します。
アカウントインスタンスでは、各アカウントに対して個別にログインが必要です。 -
SAML2.0 カスタマーマネージドアプリケーション
組織インスタンスでは、SAML 2.0に準拠したカスタムアプリケーションとの統合を通じて、シングルサインオンを実現できます。
アカウントインスタンスでは、このような統合ができず、アプリケーションごとに別々のログインが必要です。 -
委任管理者がインスタンスを管理可能
組織インスタンスでは、特定のアカウントを委任管理者として設定し、管理タスクを分散できます。
アカウントインスタンスでは、管理機能の委任ができず、各アカウントで個別に管理を行います。
許可セット
IAMポリシーのように、IAM Identity Centerにも「許可セット（Permission Sets）」という機能があります。
許可セットは、特定のIAMポリシーやカスタムポリシーを含む一連のアクセス権限を定義し、それをIAM Identity Center特有のユーザーやグループにアサインすることができます。
これにより、組織内の各アカウントに対するアクセス管理を一元的に行うことができます。
許可セットは、例えば「EC2のフルアクセス」や「S3のリードオンリーアクセス」といったアクセス権限を、各アカウントやアプリケーションに対して統一的に適用することが可能です。
これにより、管理者は複数のアカウントにまたがるアクセス権限を一括で管理し、個別のアカウントやアプリケーションごとに設定を繰り返す手間を省くことができます。
実際のログインの流れ
IAM Identity Centerでは、ユーザーやグループに対して、どのアカウントにアクセスできるか、どのアプリケーションにアクセスできるかを細かく制御しつつSSOの実現が可能となっています。
この章では、そんなIAM Identity Centerを利用したログインの流れについて確認をしていきます。
まず前提として、下図のようなユーザー、グループ、許可セット、AWSアカウント、外部アプリケーションがあるとします。
ここで私は混乱してしまったのですが、ここで指している「ユーザー・グループ」はIAM Identity Center特有のユーザー・グループのことです。
IAMユーザー・IAMグループは今回の例では登場しないため、その点は気をつけましょう。
まずはユーザー（またはグループ）に対して、それぞれ許可セット、AWSアカウント、外部アプリケーションを紐付けます。
すると「許可セット」の章にある図のような状態になります。
そうすればSSO機能を利用するための準備は完了です。
まず利用者はアクセスポータルへアクセスし、IAM Identity Center特有のユーザーへログインします。
ログインが成功すると、そのユーザー（または所属しているグループ）に紐づけられたAWSアカウントorアプリケーションを選択できる画面へと遷移します。
あとは目的に応じて、利用したいアカウントorアプリケーションを選択するだけ、となります。
まとめ
以上がAWS、アカウント管理発展となります。
前回の始まり、「AWSアカウントとは？」に比べると少し複雑な内容ですが、図解を通じてイメージがつかめていれば幸いです。
いくつかのシステムを運用する際には、今回紹介したサービスだけでなく、Control Centerといったサービスも活用してアカウント運用管理を行う可能性もあるでしょう。そのため、アカウント運用管理の奥深さを実感しています。
配属後、最初に深く関わったサービスがこれらのアカウント運用管理系のサービスだったのは、AWSを学んでいくうえで良いスタートを切ることのできる経験になったと思います。以上、2本の記事を通しての振り返りでした。
今回登場した用語
- マルチアカウント戦略
- シングルサインオン / SSO
- SAML 2.0
- AWS Organizations
- 管理アカウント
- メンバーアカウント
- サービスコントロールポリシー / SCP
- IAM Identity Center / IdC
- マルチアカウント権限
- 組織インスタンス
- アカウントインスタンス
- 許可セット
- アクセスポータル