Migration時のIdentity Integration

AWSへの移行では、

アプリケーションをAWSへ移す

ことと、

ユーザーIDの管理主体を移す

ことは同じではありません。

例えばアプリケーションをAWSへ移行しても、

Microsoft Entra ID

オンプレミスActive Directory

などを企業のIDソースとして継続利用できます。

したがって移行時には、

ワークロード移行

と、

User Migration

を分けて判断します。

1. 最初にIDソースをどこに残すか決める

最初に、

現在のユーザーは
どこで管理されているか

を確認します。

代表的には、

外部IdP

セルフマネージドActive Directory

AWS Managed Microsoft AD

IAM Identity Centerディレクトリ

などがあります。

そのうえで、

現在のIDソースを維持
↓
AWSから既存IDを利用

するのか、

ID管理主体そのものを
新しいディレクトリへ移す

のかを決めます。

重要なのは、

ワークロードをAWSへ移行
=
User Migrationも同時に必須

ではないことです。

2. 既存の外部IdPを維持する場合

Microsoft Entra IDやOktaなどを今後も企業のIDソースとして利用するなら、

既存外部IdP
↓
IAM Identity Center
↓
AWS

という既存のFederation構成を移行後も利用できます。

この場合、アプリケーションをAWSへ移したという理由だけで、

全ユーザーを
別のAWS側ディレクトリへ移行

する必要はありません。

ここではFederationの仕組み自体を再度扱うのではなく、既存IDソースを維持するなら、ワークロード移行とUser Migrationを別の時期にできることを移行時の判断として押さえます。

3. FederationとUser Migrationを区別する

Federationでは、

既存企業ID
↓
そのまま認証元として利用
↓
AWSへアクセス

します。

一方User Migrationでは、

ユーザーオブジェクト

グループ

認証情報

などについて、ID管理主体を新しい環境へ移すことを検討します。

つまり、

Federation
→ 既存ID管理主体を維持

User Migration
→ ID管理主体を移行

という違いがあります。

4. Active Directoryを維持する場合はAWS Directory Serviceで統合する

既存のセルフマネージドActive Directoryを今後も利用する場合、

AWS側のサービス
↓
AWS Directory Service
↓
既存Active Directory

という統合を利用できます。

移行時に検討する代表的な選択肢には、

AD Connector

AWS Managed Microsoft AD

AWS Managed Microsoft AD
(Hybrid Edition)

があります。

判断の中心は、

既存ADをそのまま認証元として利用したいか

AWS側にも独立したマネージドADが必要か

既存ADをAWSへ拡張したいか

です。

5. AD Connectorは既存Active Directoryをそのまま利用する

AD Connectorは、

AWS
↓
AD Connector
↓
既存Active Directory

という形で、対応するAWSサービスから既存Active Directoryを利用するためのプロキシです。

AD Connectorでは、

既存Active Directoryの
ディレクトリデータ

をAWS側へ複製しません。

認証元は既存Active Directoryのままです。

そのため、

既存ADをIDソースとして維持

ユーザーを別ディレクトリへ移したくない

対応AWSサービスから
既存ADを利用したい

という場合に候補になります。

同時に、

AD Connectorを利用中
↓
既存ドメインコントローラーへの依存あり

という点も移行時の依存関係として把握します。

6. AWS Managed Microsoft ADと既存ADを信頼関係で接続できる

AWS側に、

既存ADとは別の
AWS Managed Microsoft AD

を配置しつつ、移行期間中は既存Active Directoryのユーザーも利用したい場合があります。

Standard EditionまたはEnterprise EditionのAWS Managed Microsoft ADでは、既存のセルフマネージドActive Directoryとの信頼関係を構成できます。

概念的には、

既存Active Directory
       │
       │ 信頼関係
       ▼
AWS Managed Microsoft AD
       │
       ▼
AWS上のディレクトリ対応ワークロード

です。

これにより、

AWS側
→ 別のマネージドADを運用

移行期間
→ 既存ADのユーザーを継続利用

というHybrid Identityを構成できます。

7. Hybrid Editionで既存Active DirectoryをAWSへ拡張できる

現在のAWS Directory Serviceでは、

AWS Managed Microsoft AD
(Hybrid Edition)

も利用できます。

Hybrid Editionは、

既存セルフマネージドActive Directory
↓
AWSへ拡張

するための選択肢です。

既存の企業IDと認証情報を維持しながら、AWS側にマネージドなActive Directory基盤を配置できます。

この方式は、

別のAWS Managed Microsoft ADを作成
↓
既存ADとの信頼関係を構成

する方式とは異なり、既存Active Directoryの拡張として統合します。

したがって、

既存ADを維持
+
AWS側にもマネージドAD機能が必要
+
別ドメインとの信頼関係方式を避けたい

場合はHybrid Editionを評価します。

8. Hybrid Identityでは既存IDとAWS側環境を共存させる

移行を一度に完了できない場合、

一部ワークロード
→ オンプレミス

一部ワークロード
→ AWS

という期間が発生します。

IDも同様に、

既存Active Directoryを維持

+

AWS側から既存IDを利用

というHybrid Identityが必要になる場合があります。

Hybrid Identityの目的は、

移行期間だから
ユーザーを二重管理する

ことではありません。

可能な場合は、

同じ企業ID
↓
オンプレミス
+
AWS

で利用できるようにします。

9. User MigrationはID管理主体を移したい場合に行う

企業が最終的に、

セルフマネージドActive Directory
↓
廃止

AWS Managed Microsoft AD
↓
新しいID管理主体

とする場合は、Hybrid Identityを維持するだけでは目的を達成できません。

この場合はUser Migrationを計画します。

AWS Directory Serviceでは、セルフマネージドActive DirectoryからAWS Managed Microsoft ADへ、

Active Directory Migration Tool
ADMT

+

Password Export Service
PES

を利用して、ユーザーや暗号化されたパスワードを移行する方法があります。

整理すると、

既存ADを維持
→ Hybrid Identity

既存ADをAWSへ拡張
→ Hybrid Editionを評価

ID管理主体を別の
AWS Managed Microsoft ADへ移す
→ User Migration

です。

10. User Migrationとワークロード移行の順序は依存関係で決める

User Migrationとワークロード移行を、

必ず同時に行う

必要はありません。

例えば既存IdPや既存Active Directoryを移行期間中も利用できるなら、

先にワークロードをAWSへ移行
↓
後からID管理主体を移行

という順序が成立する場合があります。

反対に、移行先ワークロードが新しいディレクトリを前提とするなら、

新しいディレクトリを準備
↓
ID統合を構成
↓
ワークロードを移行

という順序が必要です。

したがって、

サーバー移行順序
=
User Migration順序

とは固定せず、依存関係から判断します。

11. IAM Identity CenterでActive DirectoryをIDソースとして利用できる

IAM Identity CenterではAWS Directory Serviceを介してActive DirectoryをIDソースとして利用できます。

構成は、

Active Directory
↓
AWS Directory Service
↓
IAM Identity Center
↓
AWSアカウント / アプリケーション

です。

この場合IAM Identity Centerには、

ユーザー

グループ

グループメンバーシップ

などの情報を同期できます。

一方、

Active Directoryユーザーの
パスワード

をIAM Identity Centerへ同期して認証するわけではありません。

認証はソースActive Directoryで行われます。

12. ユーザー情報の同期と認証を混同しない

Active DirectoryをIAM Identity CenterのIDソースとして利用している場合、

ユーザー / グループ情報
Active Directory
↓
IAM Identity Center

と、

ユーザー認証
↓
Active Directory

は別です。

したがって、

ユーザー情報が
IAM Identity Centerに存在
=
認証元もAWSへ移行済み

ではありません。

これは移行中に既存Active Directoryへの依存を判断するうえでも重要です。

13. IAM Identity CenterのIDソース変更は移行作業として計画する

IAM Identity CenterのIDソースを、

外部IdP
↓
Active Directory

または、

Active Directory
↓
外部IdP

へ変更する場合、

単純な設定変更

とは考えません。

現在のIAM Identity Centerでは、この変更によって、

IAM Identity Center内のユーザー

グループ

割り当て

が削除されます。

そのため、

新しいIDソースから
ユーザー / グループを準備

AWSアカウント /
アプリケーション割り当てを再構成

する移行作業として計画します。

14. 旧ID基盤を廃止するタイミング

移行の最後に旧環境を廃止するときは、

ワークロードがAWSへ移動した

だけを基準にしません。

確認するのは、

旧Active Directoryを利用する
ワークロードが残っていない

AD Connector依存が残っていない

信頼関係経由の認証が残っていない

旧IdPへのFederation依存が残っていない

新しいIDソースで
全対象ユーザーが利用可能

ことです。

これらの旧ID基盤への依存がなくなった後に、旧環境の廃止を判断します。

15. 移行時のID判断フロー

現在のIDソースを確認
↓

移行後も
現在のIDソースを使うか
├─ YES
│
│  外部IdP
│  → 既存Federationを維持
│
│  Active Directory
│  ↓
│  既存ADをそのまま認証元として利用
│  → AD Connector等を評価
│
│  既存ADをAWSへ拡張
│  → AWS Managed Microsoft AD
│     (Hybrid Edition)を評価
│
│  AWS側に別のマネージドADが必要
│  → AWS Managed Microsoft AD
│     + 必要に応じて信頼関係
│
└─ NO
   ↓
   ID管理主体を移す
   ↓
   User Migrationを計画

↓

Hybrid Identity期間の
依存関係を確認

↓

ワークロード移行

↓

ID切り替え

↓

旧ID基盤への依存が
なくなったことを確認

↓

旧ID基盤を廃止

SAP-C02では、ワークロード移行とUser Migrationを分離し、既存IDをFederationやAWS Directory Serviceで継続利用するのか、Hybrid Identityを維持するのか、既存ADをAWSへ拡張するのか、ID管理主体そのものを移すのかを要件から判断することが重要です。