Amazon WorkSpaces検証 Part2：管理基盤となる"ディレクトリ"を理解する

皆様、こんにちは。

ネットワールド SEの目木です。

前回の投稿ではAmazon Workspacesの概要を調べるとともに、以下のような環境を検証用に準備しました。

VPCおよびサブネットが存在し、その中のコンポーネントはNAT GatewayおよびInternet Gatewayを通して外部のインターネットへと出ていくことができるようになっている、といった構成です。今回からはこの環境にAmazon Workspacesを構成していきたいと思います。

実際のAmazon Workspacesのコンソールメニューは以下のように表示されます。

画面左側にメニューが確認できますが、初期構築で設定を行うのは”ディレクトリ”と”Workspaces”の2か所です。それぞれの項目の役割について簡単に整理します。

ディレクトリ：
Workspaceを管理するための論理グループ
AWSのドキュメントでは”Workspaceとユーザを管理する“とされており、そのために連携するディレクトリサービスを定義する
Workspaces：
ユーザが利用するVDIの管理メニュー
ディレクトリ内のユーザに紐づける形でWorkspaceの作成を行う

Amazon Workspaces では、このディレクトリにて定義されたアカウントの管理基盤を利用してWorkspaceと利用者を紐づけて管理しつつ、適切に利用ユーザへ提供するための認証機能と併せる形でVDIを提供します。

それでは、実際の画面を見ながら、ディレクトリの詳細について確認していきましょう。

ディレクトリの作成

Amazon Workspacesの環境は原則ドメインサービスを基に管理を行いますが、その基盤となるサービスには選択肢があります。

以下は、"ディレクトリの作成"を実行後に最初に表示される画面です。

ここではディレクトリタイプということで、以下の3つのディレクトリから管理基盤として利用するサービスを選択します。

AWS Managed Microsoft AD
Simple AD（Sambda）
AD Connector

上から順にAWS Managed Microsoft ADとSimple ADに関してはフルマネージド型のディレクトリサービス、AD Connectorはユーザマネージドのディレクトリサービス（Microsoft AD）とAmazon Workspacesを連携するためのコネクタサービスになります。

今回は検証用にEC2インスタンスとしてMicrosoft ADサーバを構成していますので、一番下のAD Connectorを選択しています。
ここから先の項目は選択したディレクトリサービスによっても異なりますので、検証される際はご注意ください。

なお、AWS Managed Microsoft ADによる構成については弊社別記事でも紹介しておりますので、興味がございましたらそちらもよろしくお願いいたします。

参考：Microsoft Managed AD構成のAmazon WorkSpacesを展開してみた！

blogs.networld.co.jp

AD Connectorを選択した場合は、次の画面でモデルを選択します。

モデル選定ということで、スモールとラージのサイジングについて情報を確認したのですが、残念ながら明確な線引きが記述されたものは確認できませんでした。

正直、どちらを選択すべきか迷うところなのですが、興味深い点としてAmazon Workspacesのディレクトリとして登録したAD Connectorについては利用料金が無料となる閾値が設定されており、スモールの場合は月に最低1ユーザ、ラージの場合は月に最低100ユーザと定められています。

各サイズのパフォーマンスについて詳細な情報がない以上、この月当たり100ユーザを超えるかどうかというところでサイジングを決めてしまうというのが、妥当な選定理由となりそうです。
以上をふまえて、今回は私が1人で検証するだけの環境ですので、ここではスモールモデルを選択しました。

ディレクトリタイプの選択後は、ADサーバが存在するVPCおよびサブネットを指定します。

AD ConnectorはマネージドサービスとしてAWSが管理していますので、そこからADサーバと疎通ができるようにするために情報を入力していきます。

続けて、ADへの接続情報を設定します。
入力内容は以下の通りです。

組織名：管理上の表示名（任意で入力）
ディレクトリのDNS名：ドメイン名
ディレクトリのNetBIOS名：ドメインのNetBIOS情報
DNS IPアドレス：上記ディレクトリの名前解決が可能なDNSサーバのIPアドレス
サービスアカウント情報：ADサーバに問い合わせる際のアカウント情報＋パスワード

ADサーバへの問い合わせ用途としてサービスアカウントを必要となりますが、一般的には権限の最小原則に従って、最低限の権限を持たせたサービスアカウントを作成することになるかと思います。

この権限の委任については管理ガイドの中で以下のように記述されています。

[Active Directory User and Computers](Active Directory ユーザーとコンピュータ) ナビゲーションツリーで、ドメインルートを選択します。メニューで [Action] (アクション) を選択し、[Delegate Control] (制御を委任する) を選択します。AD AWS ConnectorがManaged Microsoft ADに接続されている場合、ドメインルートレベルで制御を委任することはできません。この場合、制御を委任するには、コンピュータオブジェクトが作成されるディレクトリ OU で OU を選択します。
[Delegation of Control Wizard](制御の委任ウィザード) ページで [Next] (次へ) をクリックし、[Add] (追加) をクリックします。
[Select Users, Computers, or Groups](ユーザー、コンピュータ、またはグループの選択) ダイアログボックスで「Connectors」と入力し、[OK] をクリックします。複数のオブジェクトがある場合は、上記で作成した Connectors グループを選択します。[Next] (次へ) をクリックします。
[Tasks to Delegate](委任するためのタスク) ページで、[Create a custom task to delegate] (委任するためのカスタムタスクを作成) を選択し、[Next] (次へ) をクリックします。
[Only the following objects in the folder](フォルダ内の次のオブジェクトのみ) を選択してから、[Computer objects] (コンピュータオブジェクト) と [User objects] (ユーザーオブジェクト) を選択します。
[Create selected objects in this folder](選択したオブジェクトをこのフォルダに作成) を選択し、[Delete selected objects in this folder] (このフォルダ内の選択したオブジェクトを削除) を選択します。続いて、[Next] (次へ) をクリックします。

参考（抜粋）：

docs.aws.amazon.com

実際にWorkspaceを展開してドメイン参加させたり、ユーザアカウント情報との紐づけを行ったりするためには、ユーザアカウントの読み込み、コンピュータアカウントの書き込み（削除）権限が必要となることが想像できます。ここまでは理解できるのですが、この権限委任の対象がドメインルートとなっており、こちらは少々過剰なようにも感じます。
このあたりは、別途調整可否を確認してみたいと思いますが、今回は素直にドメインルートに対する権限としてサービスアカウントに委任して進めました。

なお、このサービスアカウントを作成する際は、パスワード要件についても注意が必要です。こちらはAWSのルールに準拠させる必要があるため、以下の条件を含む形で設定しなければなりません。（AD側のパスワード要件と異なる場合があり、その際に見落としがちです）