Active Directory の移行 - AWS 規範ガイダンス

Active Directory の移行

Active Directory は、多くの企業環境における一般的な ID およびアクセス管理ソリューションです。DNS、ユーザー、マシン管理を組み合わせた Active Directory は、Microsoft と Linux の両方のワークロードでユーザー認証を一元的に行う理想的な選択肢となっています。クラウドまたは AWS への移行を計画している場合、Active Directory を AWS に拡張するか、マネージドサービスを使用してディレクトリサービスインフラストラクチャの管理をオフロードするかを選択することになります。組織にとって適切なアプローチを決定する際には、各オプションのリスクと利点を理解しておくことをお勧めします。

Active Directory 移行の適切な戦略とは、組織のニーズに合い、AWS クラウドを活用できるようにすることです。これには、ディレクトリサービス自体だけでなく、それが他の AWS のサービスとどのように相互作用するかも考慮する必要があります。さらに、Active Directory を管理するチームの長期的な目標も考慮する必要があります。

Active Directory の移行に加えて、Active Directory を配置する場所のアカウント構造、AWS アカウントのネットワークトポロジを決定する必要があり、Active Directory を必要とする DNS 統合やその他の使用予定の AWS のサービスも決定する必要があります。アカウントトポロジの設計やその他の移行戦略上の考慮事項については、本ガイドの「基本的なベストプラクティス」セクションを参照してください。

評価

移行を成功させるには、既存のインフラストラクチャを評価し、その環境に必要な主な機能を理解することが重要です。移行方法を選択する前に、次の項目をお読みになることをお勧めします。

  • 既存の AWS インフラストラクチャ設計の確認 — フットプリントとインフラストラクチャ要件をまだ把握していない場合は、このガイドの「Windows 環境の検出」セクションのガイダンスに従い、評価方法を使用して既存の Active Directory インフラストラクチャを確認してください。AWS の Active Directory 用インフラストラクチャには、Microsoft が規定するサイズを使用することをお勧めします。Active Directory インフラストラクチャを AWS に拡張する場合、AWS の Active Directory 認証フットプリントの一部が必要になる場合があります。このため、Active Directory のフットプリントを AWS に完全に移行する場合を除いて、環境を大きくすることは避けてください。詳細については、Microsoft ドキュメントの「Active Directory ドメイン サービスのキャパシティ プランニング」を参照してください。

  • 既存のオンプレミスの Active Directory 設計の確認 — オンプレミス (自己管理型) Active Directory の現在の使用状況を確認します。Active Directory 環境を AWS に拡張する場合は、オンプレミス環境の拡張としても、AWS の複数のドメインコントローラーで Active Directory を実行することをお勧めします。これは、複数のアベイラビリティーゾーンにインスタンスをデプロイすることで潜在的な障害に備えて設計する AWS Well-Architected フレームワークに準拠しています。

  • アプリケーションとネットワークの依存関係の特定 — 最適な移行戦略を選択する前に、組織が機能するために必要な Active Directory の機能をすべて理解しておく必要があります。マネージドサービスとセルフホスティングのどちらかを選択する際には、それぞれのオプションを理解することが重要であることを意味します。どの移行が適切かを判断するときは、以下の項目について検討します。

    • アクセス要件 — Active Directory を制御するためのアクセス要件により、適切な移行方法が決まります。コンプライアンス規制に対してあらゆる種類のエージェントをインストールするために Active Directory ドメインコントローラーへのフルアクセスが必要な場合、AWS Managed Microsoft AD は適切なソリューションではない可能性があります。代わりに、ドメインコントローラーから AWS アカウント内の Amazon Elastic Compute Cloud (Amazon EC2) へ Active Directory を拡張することを検討してください。

    • 移行のタイムライン — 移行のスケジュールが延長され、完了期限が明確でない場合は、クラウド環境とオンプレミス環境のインスタンスを管理するための不測の事態が発生しているかどうかを確認してください。認証は、管理上の問題を回避するために Microsoft のワークロードに導入すべき重要なコンポーネントです。Active Directory の移行は、移行の早い段階で計画することをお勧めします。

  • バックアップ戦略 — Active Directory ドメインコントローラーのシステム状態をキャプチャするために既存の Windows バックアップを使用する場合、AWS の既存のバックアップ戦略を引き続き使用できます。さらに、AWS ではインスタンスのバックアップに役立つテクノロジーオプションを提供しています。例えば、Amazon Data Lifecycle ManagerAWS BackupAWS Elastic Disaster Recovery は、Active Directory ドメインコントローラーをバックアップするためのサポートされているテクノロジーです。問題を回避するには、Active Directory の復元に頼らないことが最善です。推奨されるベストプラクティスは耐障害性のあるアーキテクチャを構築することですが、復旧が必要な場合はバックアップ方法を用意しておくことが重要です。

  • ディザスタリカバリ (DR) のニーズ — Active Directory を AWS に移行する場合は、災害発生時の耐障害性を考慮して設計する必要があります。既存の Active Directory を AWS に移動する場合は、セカンダリ AWS リージョンを使用し、AWS Transit Gateway を使用して 2 つのリージョンを接続してレプリケーションを行うことができます。通常はこの方法が推奨されます。信頼性をテストするためにプライマリサイトとセカンダリサイト間の接続を何日も切断するような隔離された環境でのフェイルオーバーテストについて、さまざまな要件を課している組織もあります。これが組織の要件である場合は、Active Directory からスプリットブレインの問題をクリーンアップするのに時間がかかる可能性があります。AWS Elastic Disaster Recovery をアクティブ/パッシブの実装として使用できる場合があります。この場合、DR サイトをフェイルオーバー環境として残し、DR 戦略を個別に定期的にテストする必要があります。AWS への移行を評価する際には、組織の目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を計画することが重要な要素になります。実装を検証するためのテストとフェイルオーバーの計画とともに、要件が定義されていることを確認してください。

準備

Active Directory を AWS に移行または拡張する際には、組織上および運用上のニーズを満たす適切な戦略が重要な要素となります。AWS のサービス のサービスとどのように統合するかを選択することは、AWS を採用する上で重要です。ビジネス要件を満たす Active Directory または AWS Managed Microsoft AD のメソッドエクステンションを必ず選択してください。Amazon Relational Database Service (Amazon RDS) などのサービスには、AWS Managed Microsoft AD の使用に依存する機能がいくつかあります。必ず AWS のサービスの制限を評価して、Amazon EC2 上の Active Directory と AWS Managed Microsoft AD に互換性の制約があるかどうかを判断してください。計画プロセスの一環として、次の統合ポイントを検討することをお勧めします。

AWS で Active Directory を使用する理由には、次のようなものがあります。

  • AWS アプリケーションが Active Directory と連携できるようにする

  • Active Directory を使用して AWS マネジメントコンソールにログインする

AWS アプリケーションが Active Directory と連携できるようにする

AWS Managed Microsoft AD ディレクトリを使用するには、AWS Client VPNAWS マネジメントコンソールAWS IAM Identity CenterAmazon ConnectAmazon FSx for Windows File ServerAmazon Quick SuiteAmazon RDS for SQL Server (Directory Service にのみ適用)、Amazon WorkMailAmazon WorkSpaces などの複数の AWS アプリケーションとサービスを有効にすることができます。ディレクトリで AWS アプリケーションまたはサービスを有効にすると、ユーザーは Active Directory の認証情報でそのアプリケーションまたはサービスにアクセスできます。使い慣れた Active Directory の管理ツールを使用して、インスタンスを AWS Managed Microsoft AD ディレクトリに結合することで、Active Directory のグループポリシーオブジェクト (GPO) を適用して Windows または Linux 用 Amazon EC2 インスタンスを一元管理できます。

ユーザーは Active Directory の認証情報でインスタンスにサインインできます。これにより、個々のインスタンスの認証情報を使用したり、プライベートキー (PEM) ファイルを配布する必要がなくなります。こうすることで、使い慣れた Active Directory のユーザー管理ツールを使用して、ユーザーに対してアクセスをすばやく許可または取り消すことができます。

Active Directory を使用して AWS マネジメントコンソールにログインする

AWS Managed Microsoft AD を使用すると、ディレクトリのメンバーに AWS マネジメントコンソールへのアクセス権限を付与することができます。デフォルトでは、ディレクトリのメンバーが AWS リソースにアクセスすることはできません。ディレクトリのメンバーに AWS Identity and Access Management (IAM) ロールを割り当てることで、さまざまな AWS のサービスやリソースにアクセスできるようにします。IAM ロールでは、ディレクトリメンバーに付与するをサービス、リソース、およびアクセス権限のレベルを定義します。

例えば、ユーザーが AWS マネジメントコンソールActive Directory の認証情報で にサインインできるようにすることが可能です。そのためには、ディレクトリ内のアプリケーションとして AWS マネジメントコンソール を有効にしてから、Active Directory ユーザーとグループを IAM ロールに割り当てます。ユーザーが AWS マネジメントコンソール にサインインすると、AWS リソースを管理するための IAM ロールが引き受けられます。これにより、SAML インフラストラクチャを個別に設定および管理することなく、ユーザーに AWS マネジメントコンソール へのアクセスを簡単に許可できます。詳細については、AWS セキュリティブログの「AWS IAM Identity Center Active Directory 同期により AWS アプリケーションエクスペリエンスを向上させる方法」を参照してください。ディレクトリまたはオンプレミスの Active Directory 内のユーザーアカウントへのアクセスを許可できます。これにより、ユーザーは既存の認証情報とアクセス許可を使用して、AWS マネジメントコンソールまたは AWS Command Line Interface (AWS CLI) にサインインできます。また、既存のユーザーアカウントに IAM ロールを直接割り当てて、AWS リソースを管理できます。

ディレクトリメンバーにコンソールへのアクセス権限を付与する際には、ディレクトリにアクセス するための URL を設定しておく必要があります。ディレクトリの詳細表示およびアクセス URL の取得に関する詳細は、AWS Directory Service ドキュメントの「ディレクトリ情報の表示」を参照してください。アクセス URL の作成方法の詳細については、Directory Service ドキュメントの「アクセス URL の作成」を参照してください。IAM ロールを作成してディレクトリメンバーに割り当てる方法に関する詳細については、Directory Service ドキュメントの「ユーザーとグループに AWS リソースへのアクセスを付与する」を参照してください。

Active Directory の以下の移行オプションを検討してください。

  • Active Directory の拡張

  • AWS Managed Microsoft AD に移行する

  • 信頼を使用した Active Directory の AWS Managed Microsoft AD への接続

  • Active Directory DNS と Amazon Route 53 の統合

Active Directory の拡張

既存の Active Directory インフラストラクチャを使用して Active Directory 対応のワークロードを AWS クラウドに移行するには、AWS Managed Microsoft AD が役立ちます。信頼を使用して、AWS Managed Microsoft AD を既存の Active Directory に接続できます。つまり、ユーザーは Active Directory 対応のアプリケーションと AWS アプリケーションにオンプレミス Active Directory の認証情報を使用してアクセスできます。そのためのユーザー、グループ、またはパスワードの同期は不要です。例えば、ユーザーは既存の Active Directory のユーザーネームとパスワードを使用して、AWS マネジメントコンソールと WorkSpaces にサインインできます。また、AWS Managed Microsoft AD で SharePoint などの Active Directory 対応のアプリケーションを使用すると、ログインした Windows ユーザーは認証情報を再入力しなくても、これらのアプリケーションにアクセスできます。

信頼を使用するだけでなく、Active Directory をデプロイして AWS の EC2 インスタンス上で実行することで Active Directory を拡張できます。自分で行うことも、AWS と協力してプロセスをサポートしてもらうこともできます。Active Directory を AWS に拡張する場合は、少なくとも 2 つのドメインコントローラーを異なるアベイラビリティーゾーンにデプロイすることをお勧めします。AWS 内のユーザーとコンピュータの数によっては、3 つ以上のドメインコントローラーをデプロイする必要がある場合がありますが、復元上の理由から、推奨する最小数は 2 台です。移行の実行に Active Directory Migration Toolkit (ADMT)Password Export Server (PES) を使用することで、Active Directory インフラストラクチャの運用上の負担を軽減し、AWS にオンプレミスの Active Directory ドメインを移行することもできます。Active Directory Launch Wizard を使用して AWS に Active Directory をデプロイすることもできます。

AWS Managed Microsoft AD に移行する

AWS で Active Directory を使用するには、2 つのメカニズムを適用できます。1 つの方法は、AWS Managed Microsoft AD を採用して Active Directory オブジェクトを AWS に移行することです。これには、ユーザー、コンピュータ、グループポリシーなどが含まれます。2 つ目のメカニズムは、すべてのユーザーとオブジェクトを手動でエクスポートし、次に Active Directory 移行ツールを使用してユーザーとオブジェクトを手動でインポートする方法です。

AWS Managed Microsoft AD に移行する理由は他にもあります。

AWS Managed Microsoft AD は複数の AWS アカウント間で共有できます。これにより、各アカウントおよび各 Amazon Virtual Private Cloud (Amazon VPC) のディレクトリを操作しなくても、Amazon EC2 などの AWS のサービスを管理できます。この操作では、AWS リージョン内の任意の AWS アカウントおよび Amazon VPC からディレクトリを使用できます。この機能により、複数のアカウントと VPC 間で単一のディレクトリを使用して、ディレクトリ対応のワークロードを優れたコスト効果で簡単に管理できます。例えば、単一の AWS Managed Microsoft AD ディレクトリを使用して、EC2 インスタンスにデプロイした Windows ワークロードを複数のアカウントと VPC 間で簡単に管理することができるようになります。AWS Managed Microsoft AD ディレクトリを別の AWS アカウント と共有する場合は、Amazon EC2 コンソールや AWS Systems Manager を使用して、アカウントや AWS リージョン 内の任意の Amazon VPC からインスタンスをシームレスに結合できます。

各アカウントや Amazon VPC でディレクトリをデプロイしたり、手動でドメインにインスタンスを結合したりする必要がなくなるため、EC2 インスタンスにディレクトリ対応のワークロードを迅速にデプロイできます。詳細については、Directory Service ドキュメントの「ディレクトリを共有する」を参照してください。AWS Managed Microsoft AD 環境を共有するにはコストがかかることを覚えておいてください。Amazon VPC ピアまたは Transit Gateway ピアを使用して、他のネットワークまたはアカウントから AWS Managed Microsoft AD 環境と通信できるため、共有が不要な場合があります。このディレクトリを次のサービスで使用する場合は、ドメインを共有する必要があります: Amazon Aurora MySQL、Amazon Aurora PostgreSQL、Amazon FSx、Amazon RDS for MariaDB、Amazon RDS for MySQL、Amazon RDS for Oracle、Amazon RDS for PostgreSQL、Amazon RDS for SQL Server。

AWS Managed Microsoft AD との信頼を利用する

既存のディレクトリのユーザーに AWS リソースへのアクセスを許可するには、AWS Managed Microsoft AD 実装の信頼を使用できます。また、AWS Managed Microsoft AD 環境間で信頼を構築することもできます。詳細については、AWS セキュリティブログの「AWS Managed Microsoft AD との信頼について知っておくべきこと」を参照してください。

Active Directory DNS と Amazon Route 53 の統合

AWS に移行すると、Amazon Route 53 Resolverを使用して (DNS 名を使用して) サーバーへのアクセスを許可することで DNS を環境に統合できます。これを行うには、DHCP オプションセットを変更するのではなく、Route 53 リゾルバーエンドポイントを使用することをお勧めします。こうすることで、DHCP オプションセットを変更するよりも DNS 設定を一元的に管理できます。さらに、さまざまなリゾルバルールを活用できます。詳細については、ネットワークとコンテンツ配信ブログの「Directory Service の DNS 解決策を Amazon Route 53 Resolver と統合する」記事および、AWS 規範ガイダンスドキュメントの「マルチアカウント AWS 環境でハイブリッドネットワークの DNS 解決を設定する」を参照してください。

移行

AWS への移行を開始する際には、移行に役立つ設定とツールのオプションを検討することをお勧めします。環境の長期的なセキュリティと運用面を考慮することも重要です。

次のオプションも検討してください。

  • クラウドネイティブセキュリティ

  • Active Directory を AWS に移行するためのツール

クラウドネイティブセキュリティ

  • Active Directory コントローラーのセキュリティグループ設定 AWS Managed Microsoft AD を使用している場合、ドメインコントローラーには、ドメインコントローラーへのアクセスを制限するための VPC セキュリティ設定が付属しています。ユースケースによっては、セキュリティグループのルールを変更してアクセスを許可する必要がある場合があります。セキュリティグループ設定の詳細については、Directory Service ドキュメントの「AWS Managed Microsoft AD ネットワークセキュリティ設定を強化する」を参照してください。ユーザーがこれらのグループを変更したり、他の AWS のサービスに使用したりすることを許可しないことをお勧めします。他のユーザーにこれらの機能の使用を許可すると、ユーザーが必要な通信をブロックするように変更を行った場合、Active Directory 環境のサービスが中断される可能性があります。

  • Active Directory イベントログ用の Amazon CloudWatch Logs との統合 AWS Managed Microsoft AD を実行している場合、または自己管理型の Active Directory を使用している場合は、Amazon CloudWatch Logs を利用して Active Directory のロギングを一元化できます。CloudWatch ログを使用して、認証、セキュリティ、およびその他のログを CloudWatch にコピーできます。これにより、1 か所でログを簡単に検索できるようになり、コンプライアンス要件を満たすのに役立ちます。CloudWatch Logs との統合をお勧めします。これにより、環境内の将来のインシデントにより適切に対応できるようになります。詳細については、Directory Service ドキュメントの「AWS Managed Microsoft AD での Amazon CloudWatch Logs の有効化」および AWS ナレッジセンターの「Windows イベントログ用の Amazon CloudWatch Logs」を参照してください。

Active Directory を AWS に移行するためのツール

Active Directory 移行ツール (ADMT) とパスワードエクスポートサーバー (PES) を使用して移行を行うことをお勧めします。これにより、あるドメインから別のドメインにユーザーとコンピューターを簡単に移動できます。PES を使用する場合や、管理対象の Active Directory ドメインから別のマネージドドメインに移行する場合は、次の点に注意してください。

  • ユーザー、グループ、およびコンピュータ用のアクティブディレクトリ移行ツール (ADMT)ADMT を使用して、自己管理型の Active Directory から AWS Managed Microsoft AD にユーザーを移行できます。重要な考慮事項は、移行スケジュールとセキュリティ識別子 (SID) 履歴の重要性です。SID 履歴は移行中には転送されません。SID 履歴をサポートすることが不可欠な場合は、SID 履歴を維持できるように、ADMT ではなく、Amazon EC2 上の自己管理型の Active Directory を使用することを検討してください。

  • Password Export Server (PES) — PES を使用して AWS Managed Microsoft AD にパスワードを移行できますが、ここからパスワードを移行することはできません。ディレクトリからユーザーとパスワードを移行する方法については、AWS セキュリティブログの「ADMT を使用してオンプレミスドメインを AWS Managed Microsoft AD に移行する方法」および Microsoft ドキュメントの「Password Export Server バージョン 3.1 (x64)」を参照してください。

  • LDIF — LDAP データ交換フォーマット (LDIF) は、AWS Managed Microsoft AD ディレクトリのスキーマを拡張するために使用されるファイル形式です。LDIF ファイルには、ディレクトリに新しいオブジェクトや属性を追加するために必要な情報が含まれています。ファイルは LDAP の構文規格を満たしている必要があり、追加するオブジェクトごとに有効なオブジェクト定義が含まれている必要があります。LDIF ファイルを作成したら、ファイルをディレクトリにアップロードしてスキーマを拡張する必要があります。LDIF ファイルを使用して AWS Managed Microsoft AD ディレクトリのスキーマを拡張する方法の詳細については、Directory Service ドキュメントの「AWS Managed Microsoft AD のスキーマの拡張」を参照してください。

  • CSVDE — 場合によっては、信頼を作成したり ADMT を使用したりせずに、ユーザーをディレクトリにエクスポートおよびインポートする必要がある場合があります。理想的ではありませんが、Csvde (コマンドラインツール) を使用すると Active Directory ユーザーをあるドメインから別のドメインに移行できます。Csvde を使用するには、ユーザー名、パスワード、グループメンバーシップなどのユーザー情報を含む CSV ファイルを作成する必要があります。その後、csvde コマンドを使用してユーザーを新しいドメインにインポートできます。このコマンドを使用して、ソースドメインから既存のユーザーをエクスポートすることもできます。これは、SAMBA ドメインサービスなどの別のディレクトリソースから Microsoft Active Directory に移行する場合に役立つ場合があります。詳細については、AWS セキュリティブログの「Microsoft Active Directory ユーザーを Simple AD または AWS Managed Microsoft AD に移行する方法」を参照してください。

その他のリソース