翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 AWS のサービス を必要とする DNS 統合やその他の使用の可能性を決定する必要があります。アカウントトポロジの設計やその他の移行戦略上の考慮事項については、本ガイドの「基本的なベストプラクティス」セクションを参照してください。
評価
移行を成功させるには、既存のインフラストラクチャを評価し、その環境に必要な主な機能を理解することが重要です。移行方法を選択する前に、次の項目をお読みになることをお勧めします。
-
既存の AWS インフラストラクチャ設計の確認 – このガイドのWindows 環境の検出「」セクションのガイダンスに従い、既存の Active Directory インフラストラクチャのフットプリントとインフラストラクチャ要件をまだ把握していない場合は、評価方法を使用して既存の Active Directory インフラストラクチャを確認します。Microsoft for Active Directory インフラストラクチャの所定のサイズを使用することをお勧めします AWS。Active Directory インフラストラクチャを に拡張する場合 AWS、 で必要な Active Directory 認証フットプリントは一部のみです AWS。このため、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 Manager、AWS Backup
、AWS Elastic Disaster Recovery は、Active Directory ドメインコントローラーをバックアップするためのサポートされているテクノロジーです。問題を回避するには、Active Directory の復元に頼らないことが最善です。推奨されるベストプラクティスは耐障害性のあるアーキテクチャを構築することですが、復旧が必要な場合はバックアップ方法を用意しておくことが重要です。 -
ディザスタリカバリ (DR) のニーズ – Active Directory を に移行する場合は AWS 、災害発生時の耐障害性を設計する必要があります。既存のアクティブディレクトリを に移動する場合は AWS、セカンダリ を使用し AWS リージョン 、 を使用して 2 つのリージョンを接続し AWS Transit Gateway てレプリケーションを実行できます。通常はこの方法が推奨されます。信頼性をテストするためにプライマリサイトとセカンダリサイト間の接続を何日も切断するような隔離された環境でのフェイルオーバーテストについて、さまざまな要件を課している組織もあります。これが組織の要件である場合は、Active Directory からスプリットブレインの問題をクリーンアップするのに時間がかかる可能性があります。AWS Elastic Disaster Recovery
をアクティブ/パッシブの実装として使用できる場合があります。この場合、DR サイトをフェイルオーバー環境として残し、DR 戦略を個別に定期的にテストする必要があります。組織の目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を計画することは、移行を評価する際の重要な要素です AWS。実装を検証するためのテストとフェイルオーバーの計画とともに、要件が定義されていることを確認してください。
準備
Active Directory を AWSに移行または拡張する際には、組織上および運用上のニーズを満たす適切な戦略が重要な要素となります。の採用には、 との統合方法の選択 AWS のサービス が不可欠です AWS。 AWS Managed Microsoft AD ビジネス要件を満たす Active Directory または のメソッド拡張を必ず選択してください。の使用に依存する Amazon Relational Database Service (Amazon RDS) などのサービスには、いくつかの機能があります AWS Managed Microsoft AD。Amazon EC2 および の Active Directory に互換性の制約があるかどうかを判断するには、必ず制限を評価し AWS のサービス てください AWS Managed Microsoft AD。計画プロセスの一環として、次の統合ポイントを検討することをお勧めします。
で Active Directory を使用する次の理由を考慮してください AWS。
-
AWS アプリケーションが Active Directory と連携できるようにする
-
Active Directory を使用して にログインする AWS マネジメントコンソール
AWS アプリケーションが Active Directory と連携できるようにする
AWS Managed Microsoft AD ディレクトリを使用するには、AWS Client VPN
ユーザーは Active Directory の認証情報でインスタンスにサインインできます。これにより、個々のインスタンスの認証情報を使用したり、プライベートキー (PEM) ファイルを配布する必要がなくなります。こうすることで、使い慣れた Active Directory のユーザー管理ツールを使用して、ユーザーに対してアクセスをすばやく許可または取り消すことができます。
Active Directory を使用して AWS マネジメントコンソールにログインする
AWS Managed Microsoft AD では、 ディレクトリのメンバーに へのアクセスを許可できます AWS マネジメントコンソール。デフォルトでは、ディレクトリのメンバーが AWS リソースにアクセスすることはできません。ディレクトリメンバーに AWS Identity and Access Management (IAM) ロールを割り当てて、さまざまな AWS のサービス および リソースへのアクセスを許可します。IAM ロールでは、ディレクトリメンバーに付与するをサービス、リソース、およびアクセス権限のレベルを定義します。
たとえば、ユーザーが Active Directory 認証情報
ディレクトリメンバーにコンソールへのアクセス権限を付与する際には、ディレクトリにアクセス するための URL を設定しておく必要があります。ディレクトリの詳細を表示してアクセス URL を取得する方法の詳細については、 AWS Directory Service ドキュメントの「ディレクトリ情報を表示する」を参照してください。アクセス URL の作成方法の詳細については、 Directory Service ドキュメントの「アクセス URL の作成」を参照してください。ディレクトリメンバーに IAM ロールを作成して割り当てる方法の詳細については、 ドキュメントの「ユーザーとグループに AWS リソースへのアクセス権を付与する」を参照してください。 Directory Service
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 します。信頼を使用して、既存の Active Directory AWS Managed Microsoft AD に接続できます。つまり、ユーザーは、ユーザー、グループ、またはパスワードを同期することなく、オンプレミスの Active Directory 認証情報を使用して Active Directory 対応アプリケーションと AWS アプリケーションにアクセスできます。たとえば、ユーザーは既存の Active Directory ユーザー名とパスワードを使用して AWS マネジメントコンソール と WorkSpaces にサインインできます。また、 で SharePoint などの Active Directory 対応アプリケーションを使用すると AWS Managed Microsoft AD、ログインした Windows ユーザーは認証情報を再度入力することなく、これらのアプリケーションにアクセスできます。
信頼を使用するだけでなく、Active Directory をデプロイして AWSの EC2 インスタンス上で実行することで Active Directory を拡張できます。これは自分で行うか、 AWS を使用してプロセスに役立てることができます。Active Directory を AWSに拡張する場合は、少なくとも 2 つのドメインコントローラーを異なるアベイラビリティーゾーンにデプロイすることをお勧めします。使用しているユーザーとコンピュータの数に基づいて 3 つ以上のドメインコントローラーをデプロイする必要がある場合がありますが AWS、障害耐性の理由から推奨される最小数は 2 つです。Active Directory Migration Toolkit (ADMT) と Password Export Server (PES)
への移行 AWS Managed Microsoft AD
AWSで Active Directory を使用するには、2 つのメカニズムを適用できます。1 つの方法は、Active Directory オブジェクトを に移行 AWS Managed Microsoft AD するために を採用することです AWS。これには、ユーザー、コンピュータ、グループポリシーなどが含まれます。2 つ目のメカニズムは、すべてのユーザーとオブジェクトを手動でエクスポートし、次に Active Directory 移行ツール
AWS Managed Microsoft ADに移行する理由は他にもあります。
-
AWS Managed Microsoft AD は、Microsoft Remote Desktop Licensing Manager、Microsoft SharePoint
SharePoint 、Microsoft SQL Server Always On などの従来の Active Directory 対応ワークロードを で実行できる実際の Microsoft Active Directory ドメインです AWS クラウド 。 -
AWS Managed Microsoft AD は、グループマネージドサービスアカウント (gMSAs) と Kerberos 制約付き委任 (KCD) を使用して、Active Directory 統合 .NET アプリケーションのセキュリティを簡素化および改善するのに役立ちます。詳細については、 AWS ドキュメントの「 を使用した Active Directory 統合 .NET アプリケーションの移行の簡素化とセキュリティの向上 AWS Managed Microsoft AD
」を参照してください。
複数の AWS Managed Microsoft AD 間で共有できます AWS アカウント。これにより AWS のサービス、各アカウントと各 Amazon EC2
各アカウントや 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、 を使用して (DNS 名を使用して) サーバーへのアクセス Amazon Route 53 Resolver を許可することで、DNS を環境に統合できます。これを行うには、DHCP オプションセットを変更するのではなく、Route 53 リゾルバーエンドポイントを使用することをお勧めします。こうすることで、DHCP オプションセットを変更するよりも DNS 設定を一元的に管理できます。さらに、さまざまなリゾルバルールを活用できます。詳細については、「Networking & Content Delivery Blog」の「Integrating your Directory Service's DNS resolution with Amazon Route 53 Resolvers
移行
への移行を開始する際には 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 「 の Amazon CloudWatch Logs の有効化 AWS Managed Microsoft AD」および 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 を使用することを検討してください。 -
パスワードエクスポートサーバー (PES) – PES を使用してパスワードを に移行できますが、 外に移行することはできません AWS Managed Microsoft AD。ディレクトリからユーザーとパスワードを移行する方法については、Microsoft ドキュメントの AWS 「セキュリティブログとパスワードエクスポートサーバーバージョン 3.1 (x64)
」の「ADMT AWS Managed Microsoft AD を使用してオンプレミスドメインを に移行する方法 」を参照してください。 -
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「」を参照してください。
その他のリソース
-
との信頼について知っておくべきこと AWS Managed Microsoft AD
(AWS セキュリティブログ) -
ADMT AWS Managed Microsoft AD を使用してオンプレミスドメインを に移行する方法
(AWS セキュリティブログ) -
ステップ 2: アクティブディレクトリのデプロイ
(AWS Windows ワークショップ)
