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マルチアカウント管理を開始するきっかけになれば幸いです。

一瞥即解