IAM Identity CenterとAzure ADでシングルサインオン
目次
- 目次
- はじめに
- シングルサインオン構成の流れ
- シングルサインオン対象のユーザー範囲
- 自動プロビジョニング対象とするユーザーの絞り込み
- 自動プロビジョニング対象とするユーザー属性の絞り込み
- SAMLとSCIMの構成完了後の設定
- まとめ
はじめに
※2022/07 AWS SSOがIAM Identity Centerに名称変更されたため、記事を加筆・修正
こちらの記事でIAM Identity Center(旧AWS SSO)を利用して、複数AWSアカウントのマネージメントコンソールへシングルサインオンを行う構成について記述しました。今回は、Azure ADをIDプロバイダーとして利用してIAM Identity CenterとSAML連携し、Azure ADに登録されたユーザーIDでAWSへログインする構成について、詳細な設定に踏み込んで説明します。
なお、本記事ではAzure ADをIDプロバイダーとして利用する構成としていますが、これは世の中のエンタープライズの企業様の多くがActive Directoryでのユーザー管理を従前から実施されており、その流れでAzure ADを利用されているパターンが多く見受けられるためです。IDストアとしてOktaを利用することもあるでしょうし、IAM Identity Center自体にもローカルIDストア(Identity Center ディレクトリ)を無料で作成することが出来ますので、システムの要件に応じてユーザー管理をどこで行うかを選択すると良いでしょう。
機能が豊富だが有償のサードパーティサービスまでは不要なので、AWSだけで認証機能とIDストアを賄いたいという場合は、IAM Identity CenterのIdentity Center ディレクトリは選択肢になります。Identity Center ディレクトリではMFAデバイスによる多要素認証の設定も可能なため、IDストアとして最低限の機能は揃っており、今後も開発が進んでいくものと思われます。
シングルサインオン構成の流れ
SAMLメタデータの交換
IAM Identity CenterとAzure AD間でシングルサインオンを構成するためには、Azure AD側でテナントにエンタープライズアプリケーションを作成する必要があります。エンタープライズアプリケーションを作成する流れは世の中で他に情報があるため省略するとして、シングルサインオンを構成するためにメタデータファイルを交換する流れを説明します。
- Azure ADでエンタープライズアプリケーション作成後に、シングルサインオンのメニューからフェデレーションメタデータXMLをダウンロードする。
- IAM Identity Centerでアイデンティティソースの変更を行い、外部IDプロバイダーを選択して、サービスプロバイダーのメタデータをダウンロードする。
- Azure ADのエンタープライズアプリケーションで、IAM Identity Centerから入手したメタデータファイルをアップロードする。
- IAM Identity CenterでもAzure ADから入手したアイデンティティプロバイダーのメタデータファイルをアップロードする。
SAMLメタデータには、お互いの真正性を確認するための証明書やユーザーアクセス時のリダイレクト先URLが含まれます。
この作業を行うことで、SAMLプロトコルによって最低限の認証時リダイレクトの構成が完了します。
なお、IAM Identity CenterのIdentity Center ディレクトリを利用する場合はクラウド間のSAMLの構成は不要となり、ローカルIDストアに登録されたユーザー・グループ情報を利用して、すぐにログインしたいAWSアカウントとアクセス権限セットの紐づけを行うことが出来ます。
SCIMでユーザー・グループ情報の自動プロビジョニングを構成する
SAMLでの認証を行うには、IAM Identity CenterにもAzure ADに登録されたユーザーと同等のユーザー情報が存在している必要があります。
ユーザーの二重管理をしたくないからシングルサインオンを構成しているのに結局ユーザーの作成が必要なのかという感覚を受けますが、ユーザー認証の順番として、まずユーザーがIAM Identity Centerポータルにログインする際にAzure ADの認証画面に飛ばされ、そちらで認証が成功すると、認証が成功したユーザーに対応するユーザーがIAM Identity Center側にも存在する場合ログインが完了するという流れになるため、対応するユーザーの作成は必須です。
しかし、少数のユーザーID情報を手動作成=手動プロビジョニングするならまだしも、数万人登録されているようなIDストアのユーザー情報を全てIAM Identity Center側にも手動で作成するのは現実的ではありません。そのような場合にSCIMによるユーザー・グループ情報の自動プロビジョニングが有効な手段になります。
IAM Identity Centerで自動プロビジョニングを有効化する操作を行うと、SCIMエンドポイントとアクセストークンが入手できます。この情報をAzure ADのエンタープライズアプリケーション側のプロビジョニングメニューでテナントのURLとシークレットトークン欄にペーストし、プロビジョニングモードを自動にして保存すれば自動プロビジョニングが有効になります。自動プロビジョニングが有効の場合、40分の固定間隔でAzure ADからIAM Identity CenterのIDストアにユーザー情報が同期され、ユーザーの作成・更新・削除の変更が反映されます。なお、40分間隔の自動同期のみでなく、手動で変更されたユーザー情報の同期を行うことも可能です。
シングルサインオン対象のユーザー範囲
これまでの手順で、Azure ADのユーザーIDでIAM Identity Centerにシングルサインオンするための構成が整いました。しかし、シングルサインオン対象のユーザーの指定はどのように行うのでしょうか。
Azure ADでは二つの設定箇所でシングルサインオンを行える対象ユーザーの範囲を指定できます。一つ目はエンタープライズアプリケーションのプロパティメニューで[割り当てが必要ですか？]の設定値を[いいえ]にすると Azure ADテナント配下に登録されたユーザー全員がSSO対象となります。[割り当てが必要ですか？]の設定値を[はい]にするとエンタープライズアプリケーションの中の[ユーザーとグループ]内で指定したユーザー・グループのみがSSO対象となります。ただし、いずれのケースもIAM Identity Center側でも対応するユーザーを作成しないと、SAML認証だけ出来てその後はエラーが表示されます。
[割り当てが必要ですか？]の設定値を[はい]にした場合、[ユーザーとグループ]の項目で、SSO対象と自動プロビジョニングのユーザー・グループを絞り込むことが出来ます。
ただし、SAML連携自体はAzure AD Freeでも可能ですが、Azure Active Directory Premium P1以上あるいは同等(Microsoft 365 E3等)のライセンスがグループに追加されるユーザーに付与されていないと、SSO対象にグループ単位での割り当ては出来ません。
IAM Identity Centerでシングルサインオン構成を行う際にやりたくなるのは、ユーザー情報だけ外部IDプロバイダーから取得して、ユーザーのグループ管理はIAM Identity Center側で独自に行うという形です。しかし、これはIAM Identity Centerの仕様として出来ず、グループ構成から外部IDプロバイダー側で作成し、それをSCIMで同期してくる必要があります。アイデンティティソースを外部IDプロバイダーに変更してしまうと、IAM Identity Centerではユーザー・グループ共に自身では作成できないのが仕様となります。
また、ユーザーをSSO対象に追加しない状態でSSOを行おうとしても管理者がユーザーを割り当てていないため、サインイン中に問題が発生しました、とエラーとなります。
自動プロビジョニング対象とするユーザーの絞り込み
SAMLでのSSO対象とするユーザーの絞り込み方については先述の通りですが、記載した通りSAML認証の対象にしただけではSSOは成功しません。IAM Identity Center側にも対応するユーザーを作成しないといけませんが、自動プロビジョニングの場合、どのように同期対象のユーザーを指定するのでしょうか。
先ほどSCIMのシークレットトークンを張り付けたのと同じページに[プロビジョニングの編集]ボタンで移動し、[範囲]を[すべてのユーザーとグループを同期する]にすると、Azure ADテナント配下に登録されたユーザー全員分の情報がIAM Identity Centerに同期されます(数万人登録されているテナントでこれを誤って選ぶと意図せず全員分の情報同期が始まるので恐ろしいことになります)。[割り当てられたユーザーとグループのみを同期する]にすると、[ユーザーとグループ]で指定したユーザーとグループのみが自動同期されるため、こちらを選択しましょう。
なお、自動プロビジョニング対象とするユーザーの絞り込みには上記以外でもう一つ方法があり、それはスコープフィルターを使用してAzure ADのグループ名に特定の単語が入っていたら同期対象とする、といったような条件式での指定になります。
[プロビジョニングの編集]画面で、[マッピング]セクションを展開し、[Provision Azure Active Directory Groups]と[Provision Azure Active Directory Users]のそれぞれのリンクの中に[ソース オブジェクト スコープ]-[スコープフィルターの追加]メニューがあります。この画面で、特定グループだけを同期対象にするといった条件指定が出来るため、上手く指定をすれば、Azure Active Directory Premium P1のライセンスがなくても、特定グループや特定ユーザーのみの自動同期を行うことが可能です。
自動プロビジョニング対象とするユーザー属性の絞り込み
Azure ADからIAM Identity Centerに同期するユーザー情報には、名前以外にも所属部署や電話番号といった情報も含めることが出来ます。企業によっては認証に不要な情報をIDストアの外部に共有せず、最低限必須の情報だけを同期したいという要望もあるでしょう。
自動プロビジョニングの際、IAM Identity Centerにどのユーザー属性を同期するかは、[プロビジョニングの編集]画面で、[属性マッピング]を編集します。
IAM Identity Centerでは、[givenName], [surname], [userPrincipalName(=userName)], [displayName]が必須属性で、Azure AD側でユーザー名やその他の属性が変更された場合でもユーザーを識別できるように、[objectId(=externalId)]も必要とされます。
Automatic provisioning - AWS IAM Identity Center (successor to AWS Single Sign-On)
For SCIM synchronization to work, every user must have a First name, Last name, Username and Display name value specified. If any of these values are missing from a user, that user will not be provisioned.
Verify that the externalId SCIM mapping at your IdP corresponds to a value that is unique, always present, and least likely to change for your users. For example, your IdP might provide a guaranteed objectId or other identifier that’s not affected by changes to user attributes like name and email. If so, you can map that value to the SCIM externalId field. This ensures that your users won’t lose AWS entitlements, assignments, or permissions if you need to change their name or email.
Azure ADの推奨として、[IsSoftDeleted]も残すよう記載があるため、最低限6属性を残せば、Azure ADとIAM Identity Center間で自動プロビジョニングは機能することになります。裏を返すと、必須属性である[givenName], [surname], [userPrincipalName(=userName)], [displayName]が空(null)のユーザーがいると、そのユーザー情報は同期に失敗します。
IsSoftDeleted 属性を属性マッピングから削除することはお勧めしません。
全ての属性を削除する必要はない、デフォルトのマッピングから機能するのに必要な変更だけ行いたいという場合には、AWSのブログ記事にあるように[facsimileTelephoneNumber]と[mobile]属性を削除してください。なぜこの属性を削除するかというと、デフォルトでは、[telephoneNumber][facsimileTelephoneNumber][mobilephoneNumber]は全てIAM Identity Center側の[phoneNumber]にマッピングされるようになっており、複数の属性を一つの属性にマップすることが出来ないためエラーになるからです。
また、既に記載していますが、[externalId]属性には一意の値である[objectId]属性をマッピングする方が良いため、デフォルトのマッピングである[mailNickname]属性を変更して[objectId]属性にするのが良いでしょう。
AWS Single Sign-On の次の進化 | Amazon Web Services ブログ
属性マッピングを管理するページに移動します。そのセクションでは、facsimileTelephoneNumber および mobile 属性を使用しないため削除し、mailNickname 属性をクリックして編集し、Source 属性を objectId に変更します。
Remove the duplicate attributes. For example, having two different attributes being mapped from Azure AD both mapped to "phoneNumber_" on the AWS side would result in the error if both attributes have values in Azure AD. Only having one attribute mapped to a "phoneNumber__ " attribute would resolve the error.
SAMLとSCIMの構成完了後の設定
SAMLとSCIMの構成が完了したら、それ以降の設定は外部IDプロバイダーの場合もIdentity Center ディレクトリを利用する場合も変わりません。シングルサインオンをしたいログイン先のAWSアカウントと、対象ユーザー・グループ、AWSアカウントでそのユーザーに許可する権限を持ったアクセス権限セットの三者を紐づけることで、ユーザーは必要な権限でAWSアカウントにログインできるようになります。
まとめ
本記事では、Azure ADとIAM Identity CenterでSAMLによるシングルサインオンを構成する流れについて、世の中で既に説明がされているものに加えて、SAML認証対象ユーザーの絞り込み方や属性マッピングの取捨選択の理由など、なぜその操作が必要なのかという理由に深入りして説明しました。
企業のユーザー管理は歴史的にActive Directoryが強く、企業の既存資産を活用しようとすると、必然的にIAM Identity CenterとAzure ADを連携させる構成が多くなります。複数のクラウドに設定が分かれることでどちらのサポートに問い合わせても一貫した回答を得られないというお客様の事例を見たことがありますが、そうしたベンダー間の課題を埋めるためにIAM Identity CenterとAzure ADのSAML, SCIMの仕様に踏み込んでご説明しました。
より特殊な条件下での構成についても引き続き説明する予定ですが、本記事は長くなったため、より深い話は別記事でご説明します。
AWSマルチアカウント管理のすすめ(2/2)
目次
はじめに
前編の記事にて、企業がAWSの活用を行う上で、マルチアカウント管理の構成を行うことが重要だと説明しました。
AWSマルチアカウント管理の構成を行うためにどういった検討要素があるのか、私が考える構成観点は以下の通りですが、後編ではID管理の構成とNW管理の構成について説明します。
- マルチアカウント管理の運用方針の策定
- セキュリティ管理の構成
- ログ管理の構成
- ID管理の構成
- NW管理の構成
ID管理の構成
マネージメントコンソールへのシングルサインオン
複数アカウント管理を行う上で、各アカウントのマネージメントコンソールへログインするには一般的にはIAMで信頼関係を作成し、アカウント間でIAMユーザーをスイッチロールします。
しかし、管理される対象のアカウントの数が増えれば増えるだけ作成されるIAMロールの数も増え、これを個別に構成管理するのは運用負担も大きくなります。また、企業によっては既に別のIDプロバイダーで従業員のユーザー情報を登録して管理しているかもしれません。出来ることなら普段使用しているユーザー情報に認証を一本化し、AWSにログインするためにIAMユーザーを別途作成するというIDの二重管理は避けたいものです。
こうした要望に応える形で登場したのがIAM Identity Center(旧称AWS SSO)ですが、IAM Identity Centerを利用することで自分でスイッチロールの仕組みを構成するよりずっと簡単に複数アカウントへのログインの仕組みを整えることができます。
詳細は別途記事を作成しようと思いますが、IAM Identity Centerと既存の外部IDプロバイダーをSAML連携することで、ユーザー認証を統合することができます。また、アクセス権限セット/許可セットと呼ばれるIAMロールに相当するものと、ユーザー/グループ、ログインしたい対象AWSアカウントの三者を紐づけることで、必要なユーザーが必要な権限で必要なAWSアカウントにログインできるようになります。
また、ここで指す外部IDプロバイダーとは、Azure ADやOktaのようなSAMLプロトコルに対応したIDストアのことですが、IAM Identity Center自体にもあまり知られていませんがIdentity CenterディレクトリというローカルIDストアが存在します。外部IDストアは持っていないがマルチアカウントでシングルサインオンしたい、という要望がある場合も、Identity CenterディレクトリにユーザーIDを登録すれば、AWSサービス単独でシングルサインオンを実現することが可能です。
アプリケーションへのシングルサインオン
AWSマネージメントコンソールへのシングルサインオンが構成出来たら、その他のAWSサービスへのシングルサインオンも検討しましょう。 いくつか例を挙げると、QuickSight, SageMaker Studio, OpenSearch Service, Client VPN等のAWSサービスがユーザー認証のためにSAMLに対応しています。マネージメントコンソールへのログインだけではなく、利用者が使用する側のサービスに対してもシングルサインオンを行うようポリシーを定めることで、プラットフォーム全体としてユーザーIDの乱立を抑制して運用効率を向上することに繋がります。
NW管理の構成
AWSマルチアカウント管理を行う上で、ネットワークの構成は大きな部分を占める作業になります。NWのルーティング設計やアドレス割り当ては最初に作業しておく必要があり、利用者がプラットフォームを使いだしてからの追加作業では本番サービスに影響を与える変更が必要になるためです。
Transit GatewayとDirect Connectを使用したAWSアカウント/オンプレミス間の通信集約
Transit Gatewayの利用はかなり一般化したため、あえてここで説明する必要はないでしょうが、複数AWSアカウントのVPC間で通信をする場合にVPCピアリングを行うと、複数接続するためにネットワーク構成がフルメッシュになります。
AWS運用の規模が大きくなるとシステム間での接続が増えるため、ルートの管理が煩雑なフルメッシュ構成ではなく、Transit Gatewayを利用したハブアンドスポークのNW構成を行うことで通信経路の設計を効率化します。
オンプレミス環境とAWS環境をDirect Connectで接続する場合、VGWからVPCに直結ではなく、Transit Gatewayで終端することでDirect Connectを経由したオンプレミス環境からのルーティングを効率的に行うことが出来ます。この際、Direct Connect接続からはTransit VIFを作成してDirect Connect Gatewayに接続し、DXGWがTransit Gatewayに接続する流れとなります。
Direct Connectを準備するためにNWパートナーやキャリアの回線契約を利用することはままありますが、パートナーが提供する共有型のDirect ConnectだとTransit VIFを使用できないことがあるため、要注意です。(専有型の場合は、Direct Connect接続を自分で所有してVIFの作成が可能)
P34, P50 https://d1.awsstatic.com/webinars/jp/pdf/services/20210209-AWS-Blackbelt-DirectConnect.pdf
より大規模なAWSのNW構成
Transit Gatewayを使用して複数アカウントの通信をルーティングする際に、注意すべきなのはTransit Gatewayがリージョナルサービスであることです。 利用者が本格的にAWSを利用してマルチリージョンのシステム構成を行った際に、リージョン間のVPCで通信が必要となった場合を想定すると、理想としてはTransit Gatewayを一つデプロイすればリージョン間の通信も一つのTransit Gatewayでルーティング出来ることを期待しますが、残念ながらそういったことは出来ません。
複数のリージョン間でルーティングを行うには、リージョンごとにTransit Gatewayをデプロイし、Inter-Region Peeringを行う必要があります。
また、更にシステム構成が高度化して、何個ものリージョン間で通信が必要になる場合は、Transit GatewayのInter-Region Peering自体がメッシュ構造になってしまうため、AWS Cloud WANでNW構成を整備することも検討します。
AWS Network Firewallの集中型IPS
数ある利用者のAWSアカウントが外部ネットワークと不正な通信を行っていないかを運用者が一元的に検査することも一つの手法です。
AWS Network Firewallを使用すると通信の検査が出来ますが、外部通信は通信の方向によって出口/入口を別々に設け、それぞれの経路上にFirewall Endpointをデプロイして通信を検査します。
アウトバウンド通信(AWS->インターネット)については、各AWSアカウントのVPCからではなく、Transit Gateway経由でNW機能を集約したNWコントロールアカウントのVPCから出るようにします。NWコントロールアカウントの中で集中型のFirewall Endpointをデプロイすることで、通信を一元的に検査します。
インバウンド通信(インターネット->AWS)については、WebサービスをAWSから外部公開する場合の想定になりますが、全てのインバウンド通信をNWコントロールアカウントで受信すると、アクセスが一点に集中してNWのスケーラビリティが落ちるため、インバウンド通信は各システム用に作成する個別のAWSアカウントで外部公開用のVPCを作成し、そこで検査します。
AWS Firewall ManagerによるNetwork Firewallルールの管理
AWS Network Firewallルールについては、Suricata互換のIPSルール「AWS Managed Threat Signatures」を使用してマルウェアやボットネットのシグニチャを検知・ブロックしたり、外部への特定の通信をホワイトリスト / ブラックリストでフィルタできます。
AWS Firewall Managerを使用すると、Network Firewallルール(ステートレス/ステートフル)をNWコントロールアカウントで一元管理し、AWS Organizationsのサービス統合とResource Access Managerでの共有を行うことで、複数アカウントへのルールのデプロイを運用者が行うことが出来ます。AWS Firewall ManagerでWAFのルールを管理する情報は良くあるのですが、他アカウントのNetwork Firewallルールについても、FIrewall Managerでデプロイすることが可能です。アウトバウンド通信とインバウンド通信の両方のルールについて、Firewall Managerは集約型デプロイモデルと分散型デプロイモデルの両方を用いて管理可能です。
AWS Firewall Manager が AWS Network Firewall の集約型デプロイモデルのサポートを開始
AWS Network Firewallのデプロイモデル | Amazon Web Services ブログ
Route 53プライベートホストゾーンの共有・Route 53 Resolverによるフォワーダーの中央管理
AWS上にプラットフォーム共通の専用DNSゾーンを用意することで、全AWSアカウントで統一したドメイン名で運用できます。AWS上で専用のDNSゾーンを用意する場合は、共通アカウントであるNWコントロールアカウントにRoute 53のプライベートホストゾーンを作成し、Resource Access Managerで各システムのAWSアカウントVPCに共有して紐づけることで、システムごとに複数のドメインが乱立する事態を避けられます。
また、オンプレミスのシステムとAWS上のシステムで相互に名前解決が必要な場合は、Route 53 ResolverをNWコントロールアカウントのVPCにデプロイして、条件付きフォワードをインバウンド/アウトバウンドで設定することが可能です。
なお、 Route 53プライベートホストゾーンは上位ゾーンからの委任や下位ゾーン(サブドメイン)の委任に対応していないため、オンプレミスから条件付きフォワードを行う場合、前提としてAWS上で作成するプライベートホストゾーンはオンプレミスで管理するゾーンのサブドメインにはなれないことに注意が必要です。
AWS上でRoute 53のプライベートホストゾーンを作成する際に質問をされるのが、既にオンプレミスで利用しているゾーンがあるので、Direct ConnectでAWSとオンプレミス環境が繋がったら、EC2はオンプレのゾーンに登録したら良いではないか、というものです。
私は、既にオンプレミス環境で既存のゾーンを運用していたとしても、クラウド環境では専用のプライベートホストゾーンを作成すべきだと考えています。
まず第一に、システム間は疎結合であるべきなので、仮にDXに障害が発生したら、AWS上のEC2はオンプレに名前解決に行けなくなるため、AWS単体での稼働も継続できなくなります。 また、Route 53は様々なルーティングポリシーや機能を用意しているため、せっかく用意された機能は活用してシステム開発の柔軟性をあげることも必要だと考えています。
もちろん、やや古い考えにはなりますが、会社のセキュリティポリシー等でインターネットに向けての名前解決を禁止するといった考え方がある場合は、EC2の名前解決をオンプレミスのゾーンで管理することも選択肢にはなり得ます。
VPCエンドポイントの中央管理
システムごとにAWSアカウントが作成され、AWSアカウントごとにインターフェース型のVPCエンドポイント(PrivateLink)が複数デプロイされると、エンドポイントの数だけ時間課金が発生します。
AWS運用が大規模になると、システムごとに重複したVPCエンドポイントの数だけコストがかかるため、NWコントロールアカウントにあらかじめVPCエンドポイントをデプロイするための専用サブネットを用意し、各システムがTransit Gateway経由で共用のVPCエンドポイントを使用するとコスト削減が可能です。
まとめ
前編と今回の記事で、企業がAWSを大規模に活用するために構成できるAWSマルチアカウント管理の考え方を構成観点ごとに説明しました。まだ他にもコスト管理の統合であったり実施できることはありますが、まずはスタートの考え方として皆さまがAWSマルチアカウント管理を開始するきっかけになれば幸いです。
AWSマルチアカウント管理のすすめ(1/2)
目次
はじめに
2023/03 AWSマルチアカウント管理の構成がAWS Well-Architected Frameworkのセキュリティの柱でも推奨されていることを追記
企業でAWSの活用が進むと、AWSアカウントが個別案件ごとに乱立したり、社内のクラウド利用の承認プロセスをバイパスして野良クラウドが利用されたり、といったセキュリティ統制や運用効率の問題が発生することがままあります。
そうしたクラウドガバナンスの問題に対して、AWSから提供されているのがAWSマルチアカウント管理の手法です。AWSを大規模に、効率良く、組織横断でセキュリティ統制を効かせながら活用するためには、どういったサービスを利用することができるのか本記事では前後編に分割してご紹介します。
AWSマルチアカウント管理のコンセプト
AWSを比較的早くから利用されている企業等でありがちな構成が、オンプレミス環境の延長で、同じAWSアカウント内で環境面ごとにVPCを大きく取って分割し、NWの境界を単位としてワークロードを区分しているケースです。
オーナーが異なるワークロードが同じAWSアカウントの中に混在するとどのような問題が発生するでしょうか。以下のような課題が挙げられます。
- 1つのAWSアカウント内で複数システムが稼働するため、利用者ごとにお互いのワークロードに干渉しないようIAMの権限管理が煩雑になる(あるいは、誤操作やオペミスのリスクを負いながら緩い権限管理で運用する)
- システムごとにAWSリソースのコストを按分するために、コスト配分タグを使用するが、タグ付けに対応していないリソース等、システムごとにきれいにコスト管理が出来ない
- 上記のような共通環境での制約を嫌って、システム独自で個別にAWSアカウントを持ってしまい、結果的に必要なセキュリティ統制から漏れてしまう
こうした問題点を解決してクラウドガバナンスを向上させる方法が、以下に挙げる構成です。
- 利用者用の環境は、1システム1環境1アカウントとして個別に管理する(権限・コスト分離)
- 利用者用アカウントとは別に、セキュリティ・ログ・NWといった共通機能を機能ごとに分割した管理用AWSアカウント群を作成する(運用効率化・重複機能の共通化)
- 利用者用AWSアカウントに対して、必要なセキュリティをガードレールのように展開するが、ガードレールに抵触しない範囲では最大限の自由と操作権限を利用者に渡す(セキュリティ統制と自由の両立)
AWSアカウントレベルでワークロードを分離することは、AWS Well-Architected Frameworkのセキュリティの柱でも強く推奨されているため、これからAWSを使い始める方はマルチアカウント管理の考え方を基に、AWS OrganizationsやAWS Control Towerを利用する前提で構成検討を行うと良いでしょう。
AWSマルチアカウント管理の構成を行うためにどういった検討要素があるのか、私が考える構成観点は以下の通りです。
- マルチアカウント管理の運用方針の策定
- セキュリティ管理の構成
- ログ管理の構成
- ID管理の構成
- NW管理の構成
前編では、マルチアカウント管理の運用方針の策定、セキュリティ管理の構成、ログ管理の構成についてご紹介します。
1. マルチアカウント管理の運用方針の策定
役責と責任分界点の整理
AWSマルチアカウント管理を行う上で、AWSを組織全体のプラットフォームとして運用するための運用者とそれを利用する利用者が発生することになりますが、事前にそれぞれがどの機能までの運用をカバーするかをまず決定します。
例えば、運用者は事前にプラットフォームの初期整備を行うことになりますが、その後の運用の中では、利用者の申請に応じてAWSアカウントの払い出し作業をするとか、各アカウントの中でセキュリティ違反が発生した時に監視と連絡を行うといった役割を負います。 利用者については、運用者が一部の運用作業を担当していることを理解しつつ、それ以外のシステムに必要なアプリケーション開発等の自由と責任を負う、といった定義を事前に行うことで、プラットフォームの円滑な運用を行うことが可能です。
マルチアカウント管理に必要な範囲の標準化
運用者が申請に応じてアカウントの払い出し作業を行うとき、アカウントの作成に合わせて標準的な構成でベースVPCを作成し必要なNWルーティングの設定も行った上で払い出す、ということをすると、全ての個別アカウントの構成を必要な要件を満たす形である程度統一することが出来ます。
その際にあらかじめ決めておくべきなのは、利用者がどのリージョンを使用可能とするのか、AZ構成は何を基本とするか、ログの保管期間はどの程度を基準とするか、タグは何を付与するか、等の全員が守るべき標準です。あらかじめあらゆる規約を作成するというのは難しいでしょうが、マルチアカウント管理を行う上で運用を円滑に行うための標準は最初に抑えておくべきでしょう。
運用ガイドラインの策定
プラットフォームの運用を行う上で、利用者と運用者へのガイドラインを策定しておくことも重要です。運用者向けには定型作業の定義としてアカウント払い出し作業、セキュリティ違反検知時の対応フロー、障害発生時の対応方針といった事項を文書化しておくべきですし、利用者向けには、プラットフォームが何を提供してくれるのか、プラットフォームをどのように利用すべきなのかが分かるようなガイダンスを行うことで、プラットフォームの正しい形での活用を促進することが出来ます。
2. セキュリティ管理の構成
ガードレールの構成
AWSマルチアカウント管理の肝となるのが、AWSが提供しているAWS OrganizationsとAWS Control Towerの機能になります。両者の機能説明は世の中で広くされていますので、ここでは割愛しますが、Control Towerが標準で提供する予防的/検出的ガードレールを使用することで、プラットフォームのセキュリティを一定程度担保できます。
このガードレールはいわゆる境界型セキュリティの考えを元に作成されたものが多く、例えばS3バケットのパブリック公開を禁止するであるとか、RDS/Redshiftがパブリックサブネットに配置されたらアラートを発するという考え方になります。S3バケットの暗号化設定を変更させない、ルートユーザーの操作を禁止するといったセキュリティポリシーとして利用者に守らせたい規則を敷くこともできます。
Security Hub/GuardDuty/Inspector等のセキュリティ機能
Security Hub/GuardDuty/Inspector等のAWSの有用なセキュリティ系サービスについて、AWS Organizationsの機能でサービス統合を行うとマルチアカウントの管理を効率的に行うことが可能です。
サービス統合を行うと、各アカウントの情報が管理アカウントのコンソールに集約されるため、運用者は今どのアカウントがどのような状況になっているかを俯瞰して確認することができます。セキュリティ違反が発生した時は、すぐにコンソールで該当アカウントの状況を確認できるでしょう。
最小権限の原則に従って、セキュリティ系サービスについては管理者の委任設定を行うことでAuditアカウントに委譲し、強い権限が集中している管理アカウントではなく、Auditアカウント側で運用作業を行えるようにすることが推奨されます。
AWS Service Catalogの作成
AWS Service Catalogとは、CloudFormationテンプレートをラップしたような機能になり、今回のケースでの活用例としては、運用者があらかじめ必要なセキュリティ設定やセキュリティエージェントを導入したEC2を作成するテンプレートを用意し、それをService Catalogでポートフォリオ化して利用者のアカウントに共有することが出来ます。利用者にてそれを使用してEC2のデプロイを実施してもらえば、必要なセキュリティ設定が行われたEC2を負荷なくデプロイすることができ、セキュリティ管理から漏れたEC2の発生を抑制できます。
3. ログ管理の構成
監査ログの収集
Control Towerを有効化すると、利用者用の各AWSアカウントからCloudTrailログとConfigログをLog ArchiveアカウントのS3バケットに集約して保存するよう設定が行われます。 監査ログやセキュリティ系のログが中央集約されれば、運用者が監査対応しやすくなりますので運用上望ましいことと思います。
アプリケーションログの集約
Control Towerが収集設定をしてくれるのは監査ログのみですが、その他のログ、例えばVPCフローログやGuardDuty等のセキュリティサービスのログも手動で収集するよう設定を追加することも検討できます。また、利用者アカウントのCloudFront、ELB、WAFといったインターネットと接しているサービスのログ集約も有用でしょう。SIEM製品をLog Archiveアカウントに展開すればそうして収集したログ監視が出来ますし、Log Archiveアカウントにログ分析基盤を展開すれば、更にあらゆるアプリケーションログを収集して、ログの横串分析を行い、ビジネスに寄与する洞察を得るといった展開も考えられます。
AWS JapanからSIEM on Amazon Opensearch Serviceというサービスが提供されていますが、あらかじめ代表的なAWSサービスログの取り込みに対応しており、サードパーティのSIEM製品やログ分析サービスを検討するまでの議論にならない場合は、AWSネイティブの機能で完結するため、Log Archiveアカウントにログ分析基盤を作るための有力な候補となります。
留意事項
ここまで、AWS OrganizationsとAWS Control Towerの機能を活用してマルチアカウント管理を構成する方法を記載しましたが、実際にシステムに導入を行う際、留意すべき事項が2点あります。
AWS再販環境の制約
世の中では多くのAWSパートナーがAWS再販ベンダーとしてAWS資源の提供を行っていますが、AWS再販には、エンドカスタマーアカウントモデル(ECAM)とソリューションプロバイダーアカウントモデル(SPAM)の二通りが存在します。
SPAMの場合、再販ベンダーが全てのAWSアカウントのrootユーザーを所有することになり、ECAMでは顧客がアカウントのrootユーザーの所有権を持ちます。一般的には、SPAMの方が再販ベンダーが他のアカウントと合算してボリュームディスカウントを効かせることが出来るので、値引き率は高めになりますが、管理アカウントを再販ベンダーが全顧客共通で管理しているため、顧客専用のAWS Organizationsを組めません。一方で、ECAM方式であれば、アカウントの所有権は顧客にありますので、顧客がAWS Organizationsを組むことが可能です。ただし、ボリュームディスカウントが効かない分、値引き率が下がることがあります。
どちらも一長一短になりますが、中間のような再販の形態もあり、再販の仕方はSPAM方式だが、特定の顧客専用のAWS Organizationsを作成することで、再販ベンダーが顧客にAWS組織を間貸しするような形でAWS OrganizationsやAWS Control Towerの機能を使用させることもあります。
いずれのケースにしても、AWSマルチアカウント管理を行うにはAWS OrganizationsやControl Towerの機能が不可欠ですので、再販を利用する場合は自組織専用のAWS Organizationsを組めて、かつControl Towerも利用できる再販ベンダーを選定すべきです。
AWS ソリューションプロバイダー向け AWS Control Tower のベストプラクティス | AWS JAPAN APN ブログ
Control Towerの必要有無
私自身もそうだったのですが、Control Towerが一見複雑そうに見えて、マルチアカウント管理を行う上で本当に導入した方が良いのか疑問を持つ方がいます。私の結論としては、Control TowerはAWS Organizationsの機能を便利に利用するために各サービス機能をラップしたようなサービスになり、AWSも開発を推進しているため、使用するべきと思います。
本記事で触れたAuditアカウントやLog Archiveアカウントも、Control Tower有効化時に自動で作成されますし、ガードレールもControl Towerを利用しないで作りこむのは手間がかかります。また、再販環境だと出来ないことが大半ですが、アカウントファクトリー機能を使用すると自分で新規AWSアカウントの作成を簡単に行うことができるのも利点です。
まとめ
本記事では、AWSを大規模に活用する際に、AWSマルチアカウント管理を行うことがなぜ推奨されるのか概要を説明し、マルチアカウント管理を構成するために必要なマルチアカウント管理の運用方針の策定、セキュリティ管理の構成、ログ管理の構成について説明しました。後編では、ID管理の構成とNW管理の構成について説明をします。
