AWS再入門ブログリレー2022 AWS Directory Service編

みなさん、こんにちは！
福岡オフィスの青柳です。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の40日目のエントリです。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。40日目のテーマは「AWS Directory Service」です。

AWS Directory Serviceとは

「AWS Directory Service」とは、Microsoft Windowsの「Active Directory」をマネージドサービスとして提供するAWSのサービスです。

一般的に「ディレクトリサービス」と言うと、Active Directoryを始めとするディレクトリサービス全般を指します。
ただ、AWS Directory Serviceが提供するのはディレクトリサービス全般ではなく「Active Directory」の範疇となります。

余談ですが、「Active Directory」というのはマイクロソフト社の認証・ID管理に係る製品に付けられた「ブランド名」のようなもので、Active Directoryのうちディレクトリサービスを提供する製品は「Active Directory Domain Service (AD DS)」と言います。

ですので、AWS Directory Serviceは「Active Directory Domain Service (AD DS) のマネージドサービスである」と言うのが正確かもしれません。

※ 歴史的経緯を説明しますと、まずWindows Server 2000で、それまでの「Windows NTドメイン」の後継かつ「LDAPに準拠したディレクトリサービス」として「Active Directory」がリリースされました。
その後、Windows Server 2008になるとディレクトリサービス以外の機能がActive Directoryに追加され、従来のディレクトリサービスは「Active Directory Domain Service (AD DS)」と呼ばれるようになりました。
この時に追加されたサービスとしては「Active Directory Federation Service (AD FS)」や「Active Directory Certificate Service (AD CS)」などがあります。

AWS Directory Serviceの利用用途

「どのような時にAWS Directory Serviceを使うのか？」という点について整理してみましょう。

AWS Directory Serviceを利用する場面は多岐に渡りますが、主な利用用途としては以下の3つが挙げられます。

• Windows環境のユーザー認証、サーバー/クライアントの管理
• AWSサービス利用時の認証、ユーザー管理
• AWSへのサインイン時のユーザー認証

Windows環境のユーザー認証、サーバー/クライアントの管理

いわゆる「Windowsサーバー/クライアントをドメインに参加させる」「ユーザーをドメインで認証する」という使い方です。

この時、ドメイン参加やユーザー認証はAWS上 (EC2インスタンス等) で行われるパターンもありますし、オンプレミス環境からドメインに参加したりユーザー認証を行うことも可能です。 (もちろん、DirectConnectやサイト間VPNによってオンプレミス環境とAWSが接続されていて、認証を受けるクライアント/サーバーやユーザーがAWS Directory Serviceへ適切にアクセスできることが前提です)

なお、「Windows環境の」と書きましたが、LinuxやmacOSでもユーザー認証やサーバー/クライアント管理の対象となることが可能です。 (その際は、OS組み込みまたは別途インストールしたSambdaクライアントを用いることになります)

AWSサービス利用時のユーザー認証、ユーザー管理

AWS Directory Serviceを用いて、AWSサービスを利用するユーザーの認証や管理を行うことができます。

これはAWSの全てのサービスで可能という訳ではなく、いくつかのAWSサービスで提供されている機能です。

• Amazon Chime
• Amazon Connect
• Amazon FSx for Windows File Server
• Amazon QuickSight
• Amazon RDS/Aurora
• Amazon WorkDocs
• Amazon WorkMail
• Amazon WorkSpaces
• AWS Client VPN
• AWS Transfer Family

AWSサービスの種類によって、AWS Directory Serviceとの関係性が以下のように異なります。

• ユーザー管理の方式として、サービス独自の管理方法 (ユーザー名とパスワードなど) とAWS Directory Serviceが選択できるもの
  • 例： Amazon Connect、Amazon RDSなど
• AWS Directory Serviceによるユーザー管理が前提となっているもの
  • 例： Amazon WorkSpacesなど

また、AWS Directory Serviceと連係したユーザー管理の仕組みや操作方法については、各AWSサービスによって異なりますので、各AWSサービスのドキュメントを確認してください。

なお、後述する「ディレクトリタイプ」によって、これらのAWSサービスに対応しているもの・対応していないものがあります。
詳細は「AWSサービスとの連係」の章で説明します。

AWSへのサインイン時のユーザー認証

AWSのマネジメントコンソールへサインインする際に、IAMユーザーの代わりにAWS Directory Serviceによるユーザー認証でサインインすることができます。

AWS Directory Serviceによるユーザー認証を利用する場合には、予めAWS Directory Service画面でマネジメントコンソールのユーザー認証機能を「有効化」する必要があります。
また、AWS Directory ServiceのユーザーやグループへIAMロールを割り当てることで、サインインを行ったユーザーに応じてマネジメントコンソール上でのAWSリソースへのアクセス権限を設定することができます。

AWS Organizationsを使って複数のAWSアカウントを管理している環境では、AWS Single Sign-On (SSO) をAWS Directory Serviceと連係させることで、AWS Directory Serviceによるユーザー認証でAWSマネジメントコンソールへサインインすることができます。
また、AWS SSOはマネジメントコンソールへのサインインの他にAWSや他社のアプリケーション利用時のSSOにも対応していますので、これらにおいてもAWS Directory Serviceによるユーザー認証を利用することが可能です。

ディレクトリタイプについて

AWS Directory Serviceには、大きく特性が異なる3種類の「ディレクトリタイプ」があります。

• AWS Managed Microsoft AD
• Simple AD
• AD Connector

それぞれのディレクトリタイプの特徴について説明していきます。

AWS Managed Microsoft AD

「AWS Managed Microsoft AD」は、文字通り「Microsoft Active Directory」をマネージドサービスとして提供するものです。
内部では実際に「Windows Server 2012 R2」が動作しており、Windows Server上でActive Directoryサービスが稼働しています。

Active Directoryそのものが動作していますので、互換性の面では3種類のディレクトリタイプの中で最も優れています。
ただし、オンプレミス等のActive Directoryと比較して一部に制限が行われている箇所があります。

オンプレミスADなど既存のActive Directoryとの接続についての制限事項

• オンプレミスADなど既存のドメインに対して、AWS Managed Microsoft ADを「追加のドメインコントローラー」として追加することはできない。
• AWS Managed Microsoft ADで構築したドメインに対して、オンプレミスAD等のドメインコントローラーを追加することはできない。

これらのの制限事項は、つまり「1つのドメインにおいてAWS Managed Microsoft ADとオンプレミスAD等のドメインコントローラーを混在させる」という構成は不可能ということを意味します。

その代わり、「AWS Managed Microsoft ADとオンプレミスAD等で信頼関係を設定する」ことは可能です。

Active Directoryの管理についての制限事項

• ドメイン管理者ユーザー「Administrator」がAWSの管理下となっており、AWS利用者はAdministratorを使うことができない。
  (代わりに「Admin」というユーザーが用意されており、これを管理者ユーザーとして使用する)
• ADディレクトリのデフォルトOU/コンテナ (例「Computers」「Domain Controllers」「Users」など) がAWSの管理下となっており、AWS利用者はこれらのOU/コンテナ内のオブジェクトを移動したりオブジェクトを新規作成することができない。
  (AWS利用者向けのOUが用意されており、そちらに必要なオブジェクトやサブOUを作成していく)

これらの制限事項が致命的となることはあまりないと思いますが、既存のActive Directory環境における運用方針や操作手順がそのままでは流用できない可能性がありますので留意してください。

サポートするユーザー数などの規模

AWS Managed Microsoft ADは以下の2つの「エディション」が選択可能で、それぞれの諸元は以下のようになっています。

※ 利用料金は、記事執筆時点 (2022/03/30) における東京リージョンの価格です。デフォルトの「ドメインコントローラー×2台」構成の料金であり、ドメインコントローラーを追加する場合には別途料金が必要となります。

Simple AD

「Simple AD」は、Microsoft Active Directoryと互換性のある「Sambda」を使ったマネージドサービスです。
ユーザーやコンピューターの管理、ログイン認証などの基本的な機能はActive Directoryと同様に利用できますが、Active Directoryで利用可能な多様な機能に対してSimple ADで使える機能は限定されています。

Simple ADがサポートしない機能

Simple ADは、Active Directoryが持つ機能のうち、以下の機能をサポートしません。

• 他のドメインとの信頼関係
• LDAPスキーマ拡張
• Active Directory「ごみ箱」機能
• グループ管理サービスアカウント (gMSA)
• RADIUSサーバーを使った多要素認証 (MFA)
• 以下のツールを使った管理
  • PowerShell
  • Windows Server 2008 R2以降で提供されている「Active Directory管理センター」
    (※ 従来から使われている「Active Directory管理ツール」は利用可能)

1番目の「他のドメインとの信頼関係」をサポートしないことに加えて、AWS Managed Microsoft ADと同様に「既存ドメインのドメインコントローラーとして追加」や「Simple ADのドメインに既存のドメインコントローラーを追加」といったこともできません。

つまり、実質的にSimple ADは、オンプレミスADなどと連係しない独立したActive Directoryドメインとして導入する構成が唯一となります。

連係可能なAWSリソースの種類が少ない

前章「AWS Directory Serviceの利用用途」で説明した通り、いくつかのAWSサービスではAWS Directory Serviceを用いてユーザーの認証や管理を行うことができます。

「AWS Directory Serviceの利用用途」で挙げた10のAWSサービスは全て、AWS Managed Microsoft ADとの連係に対応しています。
しかし、Simple ADとの連係に対応しているのは「Amazon Connect」「Amazon WorkDocs」「Amazon WorkMail」「Amazon WorkSpaces」「AWS Client VPN」のみです。

また、AWSへのサインインについては、マネジメントコンソールはSimple ADとの連係に対応していますが、AWS SSOはSimple ADとの連係に対応していません。

サポートするユーザー数などの規模

Simple ADは以下の2つの「サイズ」が選択可能で、それぞれの諸元は以下のようになっています。

※ 利用料金は、記事執筆時点 (2022/03/30) における東京リージョンの価格です。

AD Connector

「AD Connector」は、AWS Managed Microsoft ADやSimple ADとは考え方が異なるディレクトリタイプです。

AD Connectorは、自分自身にはディレクトリサービスとしてのデータベースを持たず、オンプレミスADなど既存のActive Directoryへの接続を仲介する機能を提供します。

AD Connectorを使う主な目的として「AWSサービスのユーザー認証・ユーザー管理にオンプレミスADなど既存のActive Directoryを使う」があります。

FSx for Windows File Serverなど一部の例外を除いて、AWSサービスは「AWS Directory Service」のみと連係が可能であり、既存のActive Directoryと直接連係することはできません。
しかし、既存のActive DirectoryとAWSサービスの間に「AWS Directory Service」のコンポーネントである「AD Connector」を挟むことで、AD Connectorを通して既存のActive Directoryと連係することが可能になるという訳です。

なお、「AD Connectorは既存Active Directoryへの『プロキシ』の役割となる」と言われることもありますが、AD ConnectorはActive Directoryのデータのキャッシュは一切行いません。
あくまでも、AWSサービスからActive Directoryへのリクエストとレスポンスを転送するだけの動作を行います。
したがって、AWSとオンプレミス環境の間のネットワークに障害が発生した場合などはユーザー認証が行えなくなる点に留意してください。

サポートするユーザー数などの規模

AD Connectorは以下の2つの「サイズ」が選択可能で、それぞれの諸元は以下のようになっています。

※ 利用料金は、記事執筆時点 (2022/03/30) における東京リージョンの価格です。

AWS Managed Microsoft ADやSimple ADとは異なり、サポートするユーザー数やオブジェクト数などの具体的な数値は提示されていません。

マネジメントコンソールでAD Connectorを作成する画面に、以下のヘルプ情報が記載されています。

AD Connectorでサポートされるユーザー数は、オンプレミスネットワークのネットワークレイテンシー、既存のActive Directoryのパフォーマンス、AD Connectorインスタンスで使用するAWSアプリケーション数と大きな相関があります。さまざまなAD Connectorとリージョンをテストし、特定の設定とニーズに最適なものを選択することをお勧めします。

ここに書かれている通り、AD Connectorのサイズは実際に使用してみて高負荷時の応答速度などを確認した上で選定することになると思います。

AWSサービスとの連係

AWS Directory Serviceと連係可能なAWSサービスについて、各「ディレクトリタイプ」毎の対応可否を整理したものが以下の表です。

(※1) ChimeでAWS Directory Serviceとの連係を行うためには、組織のドメイン検証を行って「エンタープライズアカウント」を有効にする必要があります。
(※2) Chimeが連係可能なAWS Directory Serviceは「バージニア北部 (us-east-1) リージョン」で作成したものに限ります。
(※3) FSx for Windows File Serverで自己管理型ADと連係を行う場合は、AD Connectorを使わずに直接連係する必要があります。
(※4) QuickSightでAWS Directory Serviceとの連係を行うためには、QuickSight Enterprise Editionを使用する必要があります。
(※5) RDS/Auroraのデータベースエンジンの種類やバージョンによっては、AWS Directory Serviceとの連係をサポートしないものもあります。
(※6) WorkMailは「バージニア北部 (us-east-1)」「オレゴン (us-west-2)」「アイルランド (eu-west-1)」の各リージョンのみで利用可能なサービスであり、連係するAWS Directory ServiceはWorkMailと同じリージョンに作成する必要があります。

AWS Managed Microsoft ADは全てのAWSサービスに対応しており、また、AD Connectorもほぼ全てのAWSサービスに対応しています。

「FSx for Windows File Server」はAD Connectorに対応していませんが、備考欄にもある通り「自己管理型AD」(オンプレミスADなど) との連係は直接行えるため問題ないでしょう。

「RDS」あるいは「Aurora」はAD Connectorに対応しておらず、また、オンプレミスADなどと直接連係する方法もありません。
RDS/AuroraでオンプレミスADを使ったユーザー認証を行いたい場合は、AWS Managed Microsoft ADとオンプレミスADの間で「信頼関係」を設定した上で、RDS/AuroraをAWS Managed Microsoft ADと連係させるという手法を検討します。

前章「ディレクトリタイプについて」で説明した通り、Simple ADは他のディレクトリタイプと比較して連係可能なAWSサポートの種類が大幅に少ないです。

AWSにおけるActive Directory環境の構築パターン

ここからは、AWS Directory Serviceを使ってActive Directory環境を構築する場合における、様々なパターンをご紹介します。

ここに挙げるパターンが全てという訳ではありませんが、代表的なパターンと言えるのではないかと思います。
AWS Directory Serviceのどのディレクトリタイプを選択すればよいか、オンプレミスのActive Directoryと連係するにはどのような構成にするのがよいか、といったことを検討する上での参考にしてください。

「Simple AD」を単体で導入する

Simple ADを利用する場合、「ディレクトリタイプについて」の章で説明した通り、以下の制約があります。

• 既存ドメインにSimple ADをドメインコントローラーとして追加したり、Simple ADのドメインに既存のドメインコントローラーを追加したりはできない
• 既存ドメインとSimple ADとの間で「信頼関係」を設定することはできない

したがって、Simple ADを利用する場合は「オンプレミスADなどと連係しない独立したActive Directoryドメインとして導入する」構成が唯一となります。

Simple ADを利用する主なユースケースは「AWSサービス利用時のユーザー認証、ユーザー管理」です。
AWSサービスを利用するユーザーをオンプレミスADとは別々に管理して問題ない場合や、そもそもオンプレミスADを導入していない場合は、Simple ADを利用する構成が最もシンプルで低コストな選択肢となります。

その他にも、以下のようなユースケースでSimple ADを利用することは可能です。

• EC2インスタンスのWindowsサーバーをSimple ADのドメインで管理したい
• オンプレミス環境のユーザーやクライアントをSimple ADのドメインで管理したい
  (オンプレミス環境とAWSがDirectConnectやサイト間VPNで接続されている必要あり)

ただし、Simple ADで利用できるActive Directoryの互換機能には制限がある点と、オンプレミス環境のドメイン管理を目的とする場合はネットワーク帯域やネットワーク障害の問題を考慮する必要があります。

「AWS Managed Microsoft AD」を単体で導入する

AWS Managed Microsoft ADを利用する場合の、最もシンプルな構成パターンです。

この構成パターンは、Simple ADの構成パターンにおける「Simple AD」を「AWS Managed Microsoft AD」に置き換えただけの構成です。

ユースケースとしてもSimple ADの構成パターンとほぼ同じですが、Simple ADではなくAWS Managed Microsoft ADを選択する理由としては以下のようなものが挙げられます。

• Simple ADとの連係には対応していないAWSサービスを利用したい
  (例えば「Amazon Chime」「Amazon QuickSight」など)
• Simple ADでは利用できないActive Direcotyの機能を利用したい
  (例えば「Active Directory『ごみ箱』機能」など)
• ユーザー数やオブジェクト数の面からSimple ADではスペックが不足する

また、別のユースケースとしては、EC2インスタンスが「RDS/Aurora」へアクセスする際にAWS Managed Microsoft ADのユーザー認証を利用するパターンがあります。

RDS/Auroraの標準の認証方式である「ユーザー名/パスワード認証」を使う場合に比べて、Active Directoryのユーザー認証はサーバー上でパスワードを管理しなくてよいため、よりセキュアになります。

オンプレミスのADへ「AD Connector」で接続する

ここからは、オンプレミス環境のActive Directoryと連係するパターンです。

オンプレミスADと連係を行うパターンのうち、最もシンプルなのがこの構成です。

「ディレクトリタイプについて」の章で説明した通り、AWSサービスはオンプレミスADなど既存のActive Directoryと直接連係することはできません。
このような時に、AD Connectorを使うことで、AWSサービスが既存ADと連係することができるようになります。

なお、AD Connectorは、AWSサービスが既存ADと連係するために使われる他に、EC2インスタンスを既存ADと連係させる場合にも使うことができます。 (既存ADへ接続したAD Connectorに対して、ドメイン参加やログオン認証を行うことができる)

ただ、EC2インスタンスはAD Connectorを使わずとも既存ADと直接連係することができるため、そのような目的でAD Connectorを利用することはあまりないかもしれません。

オンプレミスのADと「AWS Managed Microsoft AD」で信頼関係を設定する

この構成パターンでは、まず、AWS側に「オンプレミスADとは別のドメイン」のAWS Managed Microsoft ADを構築します。 (AWS Managed Microsoft ADは既存ADと同一ドメインを構成することができないため、必ず別ドメインとなります)

そして、オンプレミスADとAWS Managed Microsoft ADとの間で「信頼関係」を設定します。

「信頼関係」とは、別々のドメインの間で片方のドメインが他方のドメインを「信頼」することにより、一方のドメインで認証を受けたユーザーがもう一方のドメインの資産へアクセスすることができるようになる仕組みです。

信頼関係には「方向」が存在し、ドメイン同士が相互に信頼し合う「双方向の信頼関係」と、片方のドメインから他方のドメインに対してのみ信頼する「一方向の信頼関係」があります。
AWSサービスの種類により、「双方向」の信頼関係が必要なものと「一方向」の信頼関係で構わないものに分かれます。

• 双方向の信頼関係が必要
  • Amazon Chime
  • Amazon Connect
  • Amazon QuickSight
  • Amazon WorkDocs
  • Amazon WorkMail
  • Amazon WorkSpaces
  • AWS Client VPN
  • AWS マネジメントコンソール
  • AWS Single Sign-On (SSO)
  • AWS Transfer Family
• 双方向または一方向 (AWS→オンプレミス) のいずれかの信頼関係が必要
  • Amazon EC2 (ドメイン参加・ログオン認証)
  • Amazon FSx for Windows File Server
  • Amazon RDS/Aurora

なお、ドメインの信頼関係によってドメインを跨いだアクセスを実現することができますが、あくまでドメインは別々であり、ユーザーやオブジェクトなどの情報はそれぞれのドメインで管理されることに留意する必要があります。

オンプレミスのADと「AD on EC2」でActive Directoryドメインを構成する

オンプレミス側とAWS側で別々のドメインを構築するのではなく、両者で共通のドメインを利用する構成です。

ただし、この構成ではAWS Directory Serviceを利用することができませんので、EC2インスタンスのWindows ServerへActive Directoryをインストールしてドメインコントローラーを構築する必要があります。

マネージドサービスであるAWS Directory Serviceを利用しない構成であるため、ドメインコントローラーのEC2インスタンスを管理する手間やコストが発生します。

この構成を選択するメリットとしては、一つのドメインのドメインコントローラーをオンプレミス側とAWS側へ配置することにより、オンプレミス側のADで障害が発生した場合にAWS側のADを使って処理を継続できるという点があります。
更に、オンプレミス側のADが障害により復旧不能となった場合でも、AWS側のドメインコントローラーに複製された情報を使ってADの復旧が行えるという点もあります。

つまり、オンプレミスADと連係してAWSからドメイン認証などの機能を利用するという目的に加えて、オンプレミスADのバックアップやDRという観点も含んだものとなります。

なお、EC2インスタンスでドメインコントローラーを構築した場合、AWSサービスがADと直接連係することができません。
もしAWSサービスをADと連係したい場合は、AD Connectorを導入してADと接続することで、連係が行えるようになります。

～～～

最後に、オンプレミスADと連係する3つの構成パターンを比較して、各構成のメリット・デメリットを整理します。

• オンプレミスのADへ「AD Connector」で接続
  • 〇 構成がシンプル
  • × オンプレミスADで障害が発生したり、オンプレミスとAWSの間が通信不可になった場合、何もできなくなる
• オンプレミスのADと「AWS Managed Microsoft AD」で信頼関係を設定
  • 〇 オンプレミスADで障害が発生したり、オンプレミスとAWSの間が通信不可になっても、オンプレミス側・AWS側それぞれで閉じた処理は継続できる
    (例えば、AWS Managed Microsoft ADのドメインに参加したEC2インスタンスからAWSリソースへのアクセスは行える)
  • 〇 オンプレミスADとAWS側ADをある程度独立して管理することができる (オンプレミスとAWSの間に境界を引きたい場合は有効)
  • × オンプレミスADをAWS側へ複製・分散配置している訳ではないため、バックアップやDRを目的とした構成にはならない
• オンプレミスのADと「AD on EC2」でActive Directoryドメインを構成
  • 〇 オンプレミスADで障害が発生したり、オンプレミスとAWSの間が通信不可になっても、オンプレミス側・AWS側それぞれで閉じた処理は継続できる
    (例えば、ドメインに参加したEC2インスタンスからAWSリソースへのアクセスは行える)
  • 〇 Active Directoryドメインが全体で一つであるため、シームレスかつシンプルに管理が行える
  • 〇 オンプレミスADをAWSへ複製・分散配置した冗長構成となるため、バックアップやDRが実現できる
    (オンプレミス側のドメインコントローラーが障害で復旧不能となった場合でも、AWS側に複製された情報を使って処理が継続でき、オンプレミスADの復旧も可能である)
  • × マネージドサービスではないため、ドメインコントローラーのEC2インスタンスを管理する必要がある (OSパッチ更新など)

オンプレミスADとAWSを連係するには、このようにいくつかの構成パターンが考えられ、それぞれの構成パターンでメリット・デメリットが異なることがお分かり頂けたかと思います。

全ての条件において優れている構成パターンというものはありませんので、「オンプレミスADと連係したい目的は何か」「コスト、信頼性、運用性、etc. のどれを優先するのか」といった点を勘案して、構成パターンを選定して頂ければと思います。

おわりに

以上、『AWS 再入門ブログリレー 2022』の40日目のエントリ『AWS Directory Service』編でした。

明日 (3/31) は西野による『AWS CLI』の予定です。お楽しみに！！