virtual_secure_room_directory_service pattern¶
概要¶
virtual_secure_room_directory_service pattern
モジュールでは、仮想セキュアルームのユーザーを作成・登録するディレクトリサービスを構築します。
想定する適用対象環境¶
virtual_secure_room_directory_service pattern
は、Runtime環境で使用することを想定しています。
依存するpattern¶
virtual_secure_room_directory_service pattern
は、事前に以下のpatternが適用されていることを前提としています。
pattern名 | 利用する情報 |
---|---|
network pattern | パブリックおよびプライベートサブネット |
構築されるリソース¶
このpatternでは、以下のリソースが構築されます。
リソース名 | 説明 |
---|---|
AWS Directory Service | 入力変数で指定された設定で、ディレクトリサービスを構築します。 |
Amazon EC2 | Directory Serviceを管理するAD Managerサーバーを構築します。 |
AWS Systems Manager | マネージャサーバーを自動でドメイン参加させるためのSSMドキュメントを作成します。 |
モジュールの理解に向けて¶
仮想セキュアルームはDirectory Service
とWorkSpaces
で実現します。以下に各サービスの概要を簡単に記載します。
Directory Service :ディレクトリ(AD)サービス。WorkSpacesにログインするユーザーを管理する。
WorkSpaces :VDIサービス。仮想セキュアルームの端末となる。
virtual_secure_room_directory_service pattern
は以下の部分を作成するモジュールになります。
以下のリソースを作成します。
Directory Service¶
- 仮想セキュアルームでは
MicrosoftAD
タイプのディレクトリを構築します- これはユーザーのパスワードのリセットや有効期限を設けたいためです
- また、
MicrosoftAD
の場合はStandard
かEnterprise
のエディションを選択できます - エディションにより管理できるオブジェクト数の上限に違いがあり、
Standard
のオブジェクト上限は50,000となります - 仮想セキュアルームではそこまで多くのオブジェクトを扱わないため
Standard
をデフォルトのエディションとしています
- ドメイン名、短縮名、OUは指定した任意の値で設定します
- ドメイン管理者の
Admin
のパスワードを任意の値で設定します - WorkDocsは使用しないのでSSOは設定しません
AD Manager用 EC2インスタンス¶
- Directory Serviceへユーザー登録などをするためのEC2インスタンスです
- デフォルトでは最新のWindows2019日本語版のAMIで起動します。(任意に指定も可能)
- 管理に必要な
AD LDSツール
、DNSサーバーツール
、グループポリシーの管理
をUSERDATAでインストールします - Directory Serviceへのドメイン参加も自動で行われます。これはSSMでコマンドを実行することで実現しています
SSMのコマンド実行後にサーバー再起動が行われ、それ以後はドメインのユーザーでログインできるようになります - 上記SSM実行のためのインスタンスプロファイルを設定します。(ADManage用EC2インスタンスに付与するIAMロール参照)
- ローカルAdministratorのパスワードを任意の値で設定します
- EIPを付与し、インスタンスのパブリックIPを固定化しています。(ファイアウォール申請用)
AD Manager用 EC2インスタンスに付与するIAMロール¶
- EC2を自動でドメイン参加させるためSSMを実行するための以下ポリシーをアタッチします
AmazonSSMManagedInstanceCore
AmazonSSMDirectoryServiceAccess
AD Manager用 EC2インスタンスに付与するSG¶
- 特定の端末(作業スペースの固定端末など)からのみのアクセスを許可する
AD Manager用 EC2インスタンスへの接続について¶
AD Manager用EC2にはpattern実行後に出力されるadmanager_public_dns
またはadmanager_public_ip
を指定してRDPで接続します。
接続はpattern実行時に許可したCIDRから接続します。
ドメインのAdminでAD Manager用EC2へ接続する際、以下メッセージで接続できず数分待っても改善しないことがあります。
その場合は一度EC2インスタンスを再起動してから再接続してみてください。
Unable connect. We couldn't connect to the remote PC. You might not have permission to sign in remotely. Contact your network Administrator for assistance.
初期マスタパスワードの変更について¶
本パターンを適用後に構築される以下ユーザーのパスワードは、リソース構築用のterraformスクリプトに平文で記述する必要があります。
- Directory ServiceのAdmin
- AD ManagerサーバーのAdministrator
この状況は、コードを参照可能なユーザーによる不正なアクセスや、悪意のある第三者による不正アクセスのリスクを増大させます。
そのため、本パターンを適用した後には必ずパスワードを変更するようにしてください。
変更手順は以下のようになります。
Directory ServiceのAdmin¶
- マネジメントコンソールにアクセスする
- [サービス]-[Directory Service]でDirectory Serviceの画面を表示する
- 本patternで作成したDirectory Serviceを選択し、[アクション]-[ユーザーパスワードのリセット]を選択する
ユーザー名
にAdmin
、新しいパスワード
およびパスワードを確認
に任意のパスワードを入力して[パスワードのリセット]- AD Manager用EC2にRDPでログインする。その際、ユーザーはドメインのAdmin、パスワードは4の手順で設定したパスワードを使いログインする
AD ManagerサーバーのAdministrator¶
-
Runtime環境のAD Manager用EC2のEIPを確認し、許可した端末からRDPで接続する
この時、接続ユーザーはインスタンスのAdministrator
で接続する``` yaml user: Administrator password: P@ssw0rd1234 ```
-
[スタート]-[Windwos PowerShell]を起動する
-
以下コマンドでパスワードを変更する
```powershell $Password = ConvertTo-SecureString "変更後のパスワード" -AsPlainText -Force Get-LocalUser -Name "Administrator" | Set-LocalUser -Password $Password ```
-
[スタート]-[電源]-[切断]で一度ログアウトする
- 変更したパスワードで
Administrator
にログインできることを確認する
ディレクトリユーザーの追加について¶
以下の手順でユーザーを追加します。
-
Runtime環境のAD Manager用EC2のEIPを確認し、許可した端末からRDPで接続する
この時、接続ユーザーはドメインのAdmin
で接続する。サンプルコードで記載した例だと以下でアクセス可能
(ログイン出来ない場合EC2の初期化処理が終わっていない可能性がある。数分おいてからやり直す。)``` yaml user: Admin@TEST or TEST\Admin or TESTをtest.epona.comに変えてもOK password: P@ssw0rd1234 ```
-
[スタート]-[Windows管理ツール]-[Active Directoryユーザーとコンピューター]を起動する
- [ドメイン名]-[OU名]-[Users]を開く(サンプルコードの例だとtest.epona.com->TEST->Users)。Adminが表示さる
ここで画面上部の人間が一人のボタン[現在のコンテナーに新しいユーザーを作成
]をクリック -
姓
、名
、ユーザーログオン名
を入力する。例えば以下の通り。入力したら[次へ]をクリック``` yaml 姓: test 名: a ユーザーログオン名: test.a ```
-
パスワード
とパスワードの確認入力
を入力(!!!作業端末によっては英語キーボードと認識される可能性もあるので記号などは注意!!!)する。入力したら[次へ] - [完了]をクリック
- 作成したユーザーをクリックしてpropertiesを表示する。[全般]タブの
電子メール
に使用可能なメールアドレスを設定する
WorkSpacesを作成するとこのメールアドレスにworkspaceへの招待メールが飛ぶ。入力したら[OK]をクリック
AD Manager用EC2のインバウンド設定について¶
AD Manager用EC2への接続を許可する送信元IPアドレス(CIDR)は、リポジトリにコミットしたくない場合もあります。その場合は、.tfファイルにハードコードするのではなく、入力変数ファイル(.tfvarsファイル)に定義して、terraformコマンドのオプションで指定してください。管理方針については、合わせてこちらもご参照ください。
DNSフォワーダーの設定について¶
仮想セキュアルームから外部へのアクセスはProxy経由で行うことを想定しています。
Proxyはvirtual_secure_room_proxy patternで作成可能です。
当該patternを適用するとECSのコンテナとしてProxyが作成されます。
ここで作成したProxyはVPC内DNSからのみ参照可能なService Discoveryの名前を指定して利用することを想定しています。
ただし、本patternで作成するMicrosoft AD
のDNSサーバーはVPC-provided DNSへ自動的にリクエストをフォワードしません。
このためService Discoveryを利用する際は、Microsoft AD
のDNSサーバーへDNSフォワーダー設定が必要になります。
設定方法は以下の通りです。
-
Runtime環境のAD Manager用EC2のEIPを確認し、許可した端末からRDPで接続する
この時、接続ユーザーはドメインのAdmin
で接続する。サンプルコードで記載した例だと以下でアクセス可能
(ログイン出来ない場合EC2の初期化処理が終わっていない可能性がある。数分おいてからやり直す。)``` yaml user: Admin@TEST or TEST\Admin or TESTをtest.epona.comに変えてもOK password: P@ssw0rd1234 ```
-
ADに設定されているDNSサーバーのIPv4アドレスを確認する
- [スタート]-[Windows PowerShell]を起動する
- PowerShellで
Get-DnsClientServerAddress
コマンドを実行する
優先度順に2つのDNSサーバーのIPアドレスが表示されます
- DNSマネージャーでDNSサーバーへ接続する
- [スタート]-[Windwos管理ツール]-[DNS]を起動する
- [次のコンピューター]を選択し、2-2で確認したDNSサーバーのIPv4アドレスを入力して[OK]をクリックする。
どちらのDNSサーバーへ接続してもよいですが、後述の理由により優先度の高い方に接続することを推奨します
- 条件付フォワーダーを設定する
- 3-2で接続したDNSマネージャーの画面でDNSサーバーのIPアドレスをクリックする
- [条件付フォワーダー]をダブルクリックする
- サイドメニューに表示された[条件付フォワーダー]を右クリックし、[新規条件付フォワーダー]をクリックする
DNSドメイン
にProxyの名前を入力する。
virtual_secure_room_proxy pattern
適用時に出るinternal_container_endpoint
から:3128
を除いた値マスターサーバーのIPアドレス
にVPC内部DNSのIPアドレスを入力する。
VPCのCIDRブロックの第4オクテットを2にしたアドレス(10.71.0.0/16
の場合は10.71.0.2
)となります。
このIPアドレスのサーバーは、必要なゾーンに対して権限がありません。
というエラーが表示されますが、そのまま設定して問題ありません- [このActive Directory条件付きフォワーダーを保存し、次の方法でレプリケートする]にチェックを入れ、[OK]をクリックする。
このオプションを設定することで、もう一方のDNSサーバーにも数分後に条件付フォワーダーの設定が反映されます。
このため、優先度の低いDNSサーバーへ設定した場合は実際に設定が使われるようになるまで数分のタイムラグが発生します
各種共有を制限する設定について¶
仮想セキュアルームからの情報漏えいを防ぐため、仮想セキュアルームとクライアント端末との各種共有を制限できます。 本手順では、クリップボードとファイルのコピー、プリンターによる印刷を制限する手順を説明します。
これらの設定は、ドメインのグループポリシーに設定することでドメイン内のすべてのWorkSpacesに適用できます。
なお、以下手順はAWS公式のこちらの手順をベースにしています。
ドメインに対するグループポリシーの設定手順¶
本手順では、ドメインを管理するAD Mangerに対してグループポリシーを設定する手順を説明します。
設定にはWorkSpacesとAD Manager用EC2を使用します。
WorkSpaces内にあるAWSにより作成されたグループポリシーをテンプレートとしてAD Manager用EC2にコピーします。
コピーしたテンプレートを使いAD Manager用EC2からドメインのグループポリシーとして設定します。
設定方法は以下の通りです。
- PCoIP のグループポリシー管理用テンプレートの準備
- virtual_secure_room_workspaces patternで作成したWorkSpacesに作成したドメインユーザーでログインする
- エクスプローラーから
C:\Program Files (x86)\Teradici\PCoIP Agent\configuration
ディレクトリを開く
Cドライブはデフォルトで非表示となっていますが、エクスプローラーのアドレスバーに直接パスを入力することでアクセス可能です pcoip.adm
をnotepad等で開き、内容をコピーしてクライアント端末のテキスト等に貼り付けておく
- PCoIP のグループポリシー管理用テンプレートのインストール
- AD Manager用EC2にドメインのAdminでログインする
- notepadを開き1-3でクライアント端末に貼り付けておいた
pcoip.adm
の内容を貼り付け任意の場所にpcoip.adm
という名前で保存する
拡張子がtxt
にならないように、保存ダイアログでファイル種別を全てのファイル
に変更して保存してください - [スタート]-[Windows管理ツール]-[グループポリシーの管理]を開く
- 左メニューの[フォレスト]-[ドメイン]-[ドメイン名]以下の
OU名
を右クリック、このこのドメインにGPOを作成し、コンテナーにリンクする
を選択 - 任意の名前で新しいGPO(グループポリシーオブジェクト)を作成する
- 作成したGPOを右クリックし
編集
を選択 - [コンピューターの構成]-[ポリシー]-[管理用テンプレート]を開き、メニューバーの
操作
からテンプレートの追加と削除
を選択する 追加
を選択し5の手順で作成したpcoip.adm
を選択し閉じる
これで、仮想セキュアルームで利用するドメインに対するグループポリシーの設定は完了です。
以降の手順では、作成したグループポリシーに対して各種共有の制限を設定します。
グループポリシーに対して設定することで、ドメイン内の全WorkSpacesに対して一括で適用できます。
グループポリシーの変更内容をWorkSpacesに反映させるには、WorkSpacesの再起動が必要となります。
クリップボードの共有制限について¶
本手順では、仮想セキュアルームとクライアント端末間のクリップボード共有制限の設定手順について説明します。
この手順ではクリップボードリダイレクトの設定を通じて、仮想セキュアルームとクライアント端末間のクリップボードを経由したコピーを制限します。
設定にはドメインに対するグループポリシーの設定手順で利用したEC2とグループポリシーを利用します。
設定方法は以下の通りです。
- PCoIP のクリップボードリダイレクトの設定
- AD Manager用EC2にドメインのAdminでログインする
- [スタート]-[Windows管理ツール]-[グループポリシーの管理]を開く
- 左メニューの[フォレスト]-[ドメイン]-[ドメイン名]-[OU名]以下にある2-5で作成したGPOを右クリックし
編集
を選択 - [コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[従来の管理用テンプレート(ADM)]-[PCoIP Session Variables]-[Overridable Administrator Defaults]を開く
Configure clipboard redirection
を選択してポリシー設定
をクリック- ラジオボタンで
有効
を選択しオプション
からDisabled in both directions(双方で無効)
を選択してOK
- リモートデスクトップセッションによるクリップボードリダイレクトの制限設定
- クリップボードの共有制限についての1.3の手順を参照し、グループポリシーエディターを表示する
- [コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[Windowsコンポーネント]-[リモートデスクトップサービス]-[リモートデスクトップ セッションホスト]-[デバイスとリソースのリダイレクト]を開く
クリップボードのリダイレクトを許可しない
を選択してポリシー設定
をクリック- ラジオボタンで
有効
を選択してOK
これで、仮想セキュアルームとクライアント端末とのクリップボード共有制限の設定は完了です。
ファイルの共有制限について¶
本手順では、仮想セキュアルームとクライアント端末間のファイル共有制限の設定手順について説明します。
この手順ではドライブリダイレクトの設定を通じて、仮想セキュアルームとクライアント端末間のファイルコピーを制限します。
設定にはドメインに対するグループポリシーの設定手順で利用したEC2とグループポリシーを利用します。
設定方法は以下の通りです。
- リモートデスクトップセッションによるドライブリダイレクトとプリンターリダイレクトの設定
- クリップボードの共有制限についての1.3の手順を参照し、グループポリシーエディターを表示する
- [コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[Windowsコンポーネント]-[リモートデスクトップサービス]-[リモートデスクトップ セッションホスト]-[デバイスとリソースのリダイレクト]を開く
ドライブのリダイレクトを許可しない
を選択してポリシー設定
をクリック- ラジオボタンで
有効
を選択してOK
これで、仮想セキュアルームとクライアント端末とのファイル共有制限の設定は完了です。
プリンターサポートの設定について¶
本手順では、仮想セキュアルームとクライアント端末間のプリンターサポートの設定手順について説明します。
この手順ではプリンターリダイレクトの設定を通じて、仮想セキュアルームとクライアント端末間のプリンター利用を制限します。
設定にはドメインに対するグループポリシーの設定手順で利用したEC2とグループポリシーを利用します。
設定方法は以下の通りです。
- PCoIP のプリンターサポートの設定
- クリップボードの共有制限についての1.3の手順を参照し、グループポリシーエディターを表示する
- [コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[従来の管理用テンプレート(ADM)]-[PCoIP Session Variables]-[Overridable Administrator Defaults]を開く
Configure remote printing
を選択してポリシー設定
をクリック- ラジオボタンで
有効
を選択しオプション
からprinting disabled(クライアント端末への印刷機能を無効化)
を選択してOK
- リモートデスクトップセッションによるプリンターリダイレクトの設定
- クリップボードの共有制限についての1.3の手順を参照し、グループポリシーエディターを表示する
- [コンピューターの構成]-[ポリシー]-[管理用テンプレート]-[Windowsコンポーネント]-[リモートデスクトップサービス]-[リモートデスクトップ セッションホスト]-[プリンターのリダイレクト]を開く
クライアントプリンターのリダイレクトを許可しない
を選択してポリシー設定
をクリック- ラジオボタンで
有効
を選択してOK
これで、仮想セキュアルームとクライアント端末とのプリンターサポート設定は完了です。
サンプルコード¶
virtual_secure_room_directory_service pattern
を使用したサンプルコードを、以下に記載します。
module "directory_service" {
source = "git::https://gitlab.com/eponas/epona.git//modules/aws/patterns/virtual_secure_room_directory_service?ref=v0.2.6"
tags = {
Owner = "test"
Environment = "virtual-secure-room"
RuntimeEnvironment = "production"
ManagedBy = "epona"
}
directory_service_domain_name = "test.epona.com"
directory_service_domain_password = "P@ssw0rd1234"
directory_service_short_name = "TEST"
directory_service_ou = "OU=TEST,DC=test,DC=epona,DC=com"
directory_service_vpc_id = data.terraform_remote_state.network.outputs.network.vpc_id
directory_service_subnet_ids = data.terraform_remote_state.network.outputs.network.private_subnets
ad_manager_name = "ad_manager"
ad_manager_administrator_password = "P@ssw0rd1234"
ad_manager_subnet_id = data.terraform_remote_state.network.outputs.network.public_subnets[0]
ad_manager_role_name = "admanagerrole"
ad_manager_instance_profile_name = "admanagerinstanceprofile"
ad_manager_sg_name = "ad_manager_sg"
ad_manager_sg_ingresses = var.ingresses
}
関連するpattern¶
virtual_secure_room_directory_service pattern
に関連するpatternを、以下に記載します。
pattern名 | 説明 |
---|---|
virtual_secure_room_workspaces | WorkSpacesをデプロイするパターン |
virtual_secure_room_proxy | 仮想セキュアルーム用Proxyをデプロイするパターン |
入出力リファレンス¶
Requirements¶
Name | Version |
---|---|
terraform | ~> 0.14.10 |
aws | >= 3.37.0, < 4.0.0 |
Inputs¶
Name | Description | Type | Default | Required |
---|---|---|---|---|
ad_manager_administrator_password | AD管理ツールを導入するEC2インスタンスのAdministratorのパスワード | string |
n/a | yes |
ad_manager_instance_profile_name | AD管理ツールを導入するEC2インスタンスに付与するインスタンスプロファイル名 | string |
n/a | yes |
ad_manager_name | AD管理ツールを導入するEC2インスタンスのNameタグの値 | string |
n/a | yes |
ad_manager_role_name | AD管理ツールを導入するEC2インスタンスに付与するIAMロール名 | string |
n/a | yes |
ad_manager_sg_ingresses | AD管理ツールを導入するEC2インスタンスへのアクセス許可。記述例は以下の通り。rules = [{ |
list(object({ |
n/a | yes |
ad_manager_sg_name | AD管理ツールを導入するEC2インスタンスに付与するSGの名前 | string |
n/a | yes |
ad_manager_subnet_id | AD管理ツールを導入するEC2インスタンスを配置する、サブネットのID | string |
n/a | yes |
directory_service_domain_name | ディレクトリのFQDN。例: corp.example.com | string |
n/a | yes |
directory_service_domain_password | Directory Serviceのadminのパスワード | string |
n/a | yes |
directory_service_ou | ディレクトリ内の組織(OU=<短縮名>,DC=<第2レベルドメイン>,DC=<第1レベルドメイン>) | string |
n/a | yes |
directory_service_short_name | ディレクトリの短縮ドメイン名 | string |
n/a | yes |
directory_service_subnet_ids | ディレクトリをデプロイするサブネットIDのリスト。異なるAZにあるサブネットIDを指定すること。 | list(string) |
n/a | yes |
directory_service_vpc_id | Directory ServiceをデプロイするVPCのID | string |
n/a | yes |
ad_manager_ami | AD管理ツールを導入するEC2インスタンスのAMI。指定なしの場合、最新のWindows2019Base日本語版のAMIを使用 | string |
null |
no |
ad_manager_instance_type | AD管理ツールを導入するEC2インスタンスのインスタンスタイプ | string |
"t2.micro" |
no |
ad_manager_root_block_volume_size | AD管理ツールを導入するEC2インスタンスの、ルートデバイスボリュームのサイズ | string |
"30" |
no |
tags | 仮想セキュアルームに関するリソースに付与するタグ | map(string) |
{} |
no |
Outputs¶
Name | Description |
---|---|
admanager_login_password | ドメインのAdminに設定している初期パスワード |
admanager_login_user | ドメインのAdminでAD Managerへログインする際のユーザー名 |
admanager_public_dns | AD Managerのパブリックホスト名 |
admanager_public_ip | AD ManagerのパブリックIPアドレス |
directory_id | Diretory ServiceのID |
※ このドキュメントはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。
※ このドキュメントに記載されている会社名、製品名は、各社の登録商標または商標です。
© 2021 TIS Inc.