Amazon WorkSpaces をデプロイ するためのベスト …...AWS - Amazon WorkSpaces...
Transcript of Amazon WorkSpaces をデプロイ するためのベスト …...AWS - Amazon WorkSpaces...
Amazon WorkSpaces をデプロイ
するためのベストプラクティス
ネットワークアクセス、ディレクトリサービス、セキュリティ
2016 年 7 月
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
2/55 ページ
© 2016, Amazon Web Services, Inc. or its affiliates. All rights reserved.
注意
本書は情報提供のみを目的としています。本書の発行時点における AWS の現行
製品と慣行を表したものであり、それらは予告なく変更されることがあります。
お客様は本書の情報、および AWS 製品またはサービスの利用について、独自の
評価に基づき判断する責任を負います。いずれの AWS 製品またはサービスも、
明示または黙示を問わずいかなる保証も伴うことなく、「現状のまま」提供され
ます。本書のいかなる内容も、AWS、その関係者、サプライヤ、またはライセ
ンサーからの保証、表明、契約的責任、条件や確約を意味するものではありませ
ん。お客様に対する AWS の責任は、AWS 契約により規定されます。本書は、
AWS とお客様の間で行われるいかなる契約の一部でもなく、そのような契約の
内容を変更するものでもありません。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
3/55 ページ
目次
要約 4
はじめに 4
WorkSpaces の要件 6
ネットワークに関する考慮事項 7
VPC の設計 8
トラフィックフロー 11
一般的な設定の例 15
AWS Directory Service 21
AD DS デプロイメントのシナリオ 22
設計上の考慮事項 33
Multi-Factor Authentication (MFA) 39
セキュリティ 41
伝送中の暗号化 41
ネットワークインターフェイス 44
WorkSpace セキュリティグループ 45
暗号化された WorkSpace 46
Amazon CloudWatch の使用によるモニタリングまたはログ記録 49
WorkSpace に関する Amazon CloudWatch メトリックス 49
トラブルシューティング 52
AD Connector が Active Directory に接続できない 52
最も近い AWS リージョンに対するレイテンシーの確認方法 53
まとめ 54
寄稿者 54
その他の資料 55
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
4/55 ページ
要約
このホワイトペーパーでは、Amazon WorkSpaces のデプロイに関するベストプ
ラクティスの概要を示し、ネットワークの考慮事項、ディレクトリサービス、
ユーザー認証、セキュリティ、モニタリング、ログ記録について説明します。
ドキュメントの内容は、必要な情報に早くアクセスできるように、4 つのカテゴ
リに分かれています。読者として、ネットワークエンジニア、ディレクトリエン
ジニア、セキュリティエンジニアを対象としています。
はじめに
Amazon WorkSpaces は、クラウドで提供されるマネージド型のデスクトップコ
ンピューティングサービスです。Amazon WorkSpaces を使用すると、ハード
ウェアの購入やデプロイ、複雑なソフトウェアのインストールなどの負担を軽減
し、AWS マネジメントコンソールでの数クリックの操作、AWS コマンドライン
インターフェイス (CLI)、または API によってデスクトップエクスペリエンスを
提供することができます。Amazon WorkSpaces では、デスクトップを数分で起
動して、オンプレミスまたは外部ネットワークのデスクトップソフトウェアに、
すばやく安全かつ確実に接続およびアクセスできます。次のことを行うことがで
きます。
AWS Directory Service: AD Connector を使用して、オンプレミスの既存
Microsoft Active Directory (AD) を活用する。
ディレクトリを AWS Cloud に拡張する。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
5/55 ページ
AWS Directory Service: Microsoft AD または Simple AD を使用してマネー
ジド型ディレクトリを構築し、ユーザーと WorkSpace を管理する。
これに加え、AD Connector を使用してオンプレミスまたはクラウドホスト型
RADIUS サーバーを活用し、Multi-Factor Authentication (MFA) を WorkSpace
に提供できます。
Amazon WorkSpaces のプロビジョニングは、CLI または API を使用して自動化
できます。その場合は、Amazon WorkSpaces を既存のプロビジョニングワーク
フローに組み込むことが可能になります。
セキュリティについては、WorkSpaces サービスによって提供される統合された
ネットワーク暗号化に加えて、WorkSpace 用に保管時の暗号化を有効にするこ
ともできます (「セキュリティ」セクションの「暗号化された WorkSpace」を参
照してください)。
WorkSpace には、Microsoft System Center Configuration Manager (SCCM) など
既存のオンプレミスツールを使用するか、Amazon WorkSpaces Application
Manager (Amazon WAM) を活用して、アプリケーションをデプロイできます。
以下の各セクションでは、Amazon WorkSpaces の詳細を示し、サービスの仕組
みとサービスの開始方法を説明します。また、使用できるオプションと機能につ
いても説明します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
6/55 ページ
WorkSpaces の要件
Amazon WorkSpaces サービスを正常にデプロイするには、次の 3 つのコンポー
ネントが必要です。
WorkSpaces クライアントアプリケーション。Amazon WorkSpaces でサ
ポートされているクライアントデバイス。完全なリストについては、
「サポートされるプラットフォームとデバイス」を参照してください。
WorkSpaces には、PCoIP (Personal Computer over Internet Protocol) ゼロ
クライアントを使用して接続することもできます。使用可能なデバイスの
一覧については、「PCoIP Zero Clients for Amazon WorkSpaces」を参照し
てください。
ユーザーを認証し、WorkSpace へのアクセスを提供するディレクトリサー
ビス。Amazon WorkSpaces は現在、AWS Directory Service および Active
Directory と組み合わせて使用できます。オンプレミスの Active Directory
サーバーを AWS Directory Service と共に使用すると、WorkSpaces で既存の
エンタープライズユーザー認証情報をサポートできます。
Amazon WorkSpaces を実行するための Amazon Virtual Private
Cloud (Amazon VPC)。マルチ AZ 配置では、AWS Directory Service 構
造ごとに 2 つのサブネットが必要であるため、1 つの WorkSpaces デプロ
イメントにはサブネットが 2 つ以上必要になります。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
7/55 ページ
ネットワークに関する考慮事項
各 WorkSpace は、作成に使用した特定の Amazon VPC と AWS Directory Service
構造に関連付けられています。すべての AWS Directory Service 構造 (Simple AD
、AD Connector、Microsoft AD) には、別々のアベイラビリティーゾーンに 1 つ
ずつ、合計 2 つのサブネットが必要になります。サブネットは Directory Service
構造に永続的に関連付けられており、AWS Directory Service の作成後に変更す
ることはできません。このため、Directory Services 構造を作成する前に適切な
サブネットサイズを決定することが不可欠です。サブネットを作成する前に、以
下の点を慎重に考慮してください。
長期的に必要になる WorkSpace の数は? 予測される増加の程度は?
ユーザーのタイプは?
接続する Active Directory ドメインの数は?
エンタープライズユーザーアカウントの場所は?
Amazon では、計画プロセスの一部として必要なアクセスとユーザー認証の種類
に基づいてグループ (ペルソナ) を定義することをお勧めしています。これらの
情報は、特定のアプリケーションまたはリソースへのアクセスを制限する必要が
ある場合に役立ちます。ユーザーペルソナを定義すると、AWS Directory Service、
ネットワークアクセスコントロールリスト、ルーティングテーブル、VPC セ
キュリティグループを使用して、アクセスを分割および制限することができます。
各 AWS Directory Service 構造では、2 つのサブネットが使用され、その構造か
ら起動されるすべての WorkSpace に同じ設定が適用されます。たとえば、ある
AD Connector にアタッチされたすべての WorkSpace に適用するセキュリティグ
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
8/55 ページ
ループを使用して、MFA 認証が必要かどうか、エンドユーザーが自分の
WorkSpace に対してローカル管理者としてアクセスできるかどうかなどを指定
できます。
注意: 各 AD Connector は、1つの Microsoft Active Directory 組織単位
(OU) に接続されます。この機能を利用できるように、自身のユーザ
ーペルソナを考慮して Directory Service を構築する必要があります。
このセクションでは、VPC およびサブネットのサイズ決定、トラフィックフロー、
ディレクトリサービス設計関連のベストプラクティスについて説明します。
VPC の設計
スケーラビリティ、セキュリティ、管理の容易さに優れた WorkSpaces 環境を構
築するために、Amazon WorkSpaces 用の VPC、サブネット、セキュリティグ
ループ、ルーティングポリシー、ネットワーク ACL を設計する際に考慮すべき
点を以下に示します。
VPC。WorkSpaces デプロイメント用に、専用の VPC を使用することをお
勧めします。専用の VPC を使用すると、必要とされるガバナンスと
WorkSpaces にトラフィック分離を設定することによるセキュリティ上の
ガードレールを指定できます。
ディレクトリサービス。各 AWS Directory Service 構造には、サブネットの
ペアが必要です。これにより、可用性の高いディレクトリサービスを各
Amazon AZ 間で分割して使用することができます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
9/55 ページ
サブネットのサイズ。WorkSpaces デプロイメントは、ディレクトリ構造
に関連付けられ、指定した AWS Directory Service と同じ VPC サブネット
内に配置されます。次の点を考慮する必要があります。
サブネットサイズは永続的であり変更できません。将来的に拡張が必要に
なった場合のために十分な余裕を残しておく必要があります。
選択した AWS Directory Service に対するデフォルトのセキュリティグ
ループを指定できます。このセキュリティグループは、特定の AWS
Directory Service 構造に関連付けられているすべての WorkSpaces に適用
されます。
複数の AWS Directory Services で同じサブネットを使用することもでき
ます。
VPC を設計する際は将来の計画についても考慮します。たとえば、ウイルス対
策サーバー、パッチ管理サーバー、Active Directory サーバー、RADIUS MFA
サーバーなどの管理コンポーネントを追加することも考えられます。このような
要件に対応できるように、VPC 設計内で使用可能な IP アドレスの追加も計画し
ておくことをお勧めします。
VPC の設計およびサブネットのサイズ決定に関する詳細なガイダンスと考慮事
項については、re:Invent のプレゼンテーション「Amazon.com が Amazon
WorkSpaces に移行している方法」を参照してください。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
10/55 ページ
ネットワークインターフェイス
各 WorkSpace には、2 つの Elastic Network Interface (ENI)、1 つの管理ネット
ワークインターフェイス (eth0)、1 つのプライマリネットワークインターフェイ
ス (eth1) があります。管理ネットワークインターフェイスは、クライアント接続
の終端となるインターフェイスであり、AWS で WorkSpace を管理するために使
用されます。AWS では、このインターフェイスのためにプライベート IP アドレ
スが利用されます。ネットワークルーティングを正しく動作させるためには、
WorkSpaces VPC と通信する可能性のあるネットワークで、このプライベートア
ドレス空間を使用しないでください。
リージョンごとに使用されるプライベート IP 範囲のリストについては、
「Amazon WorkSpaces の詳細」を参照してください。
注意: Amazon WorkSpaces およびこれらに関連付けられている管
理ネットワークインターフェイスは、VPC 内に存在しないため、
管理ネットワークインターフェイスまたは Amazon Elastic
Compute Cloud (Amazon EC2) のインスタンス ID を AWS マネジメ
ントコンソールで確認することはできません (図 4、図 5、および
図 6 を参照してください)。ただし、プライマリネットワークイン
ターフェイス (eth1) のセキュリティグループ設定は、AWS マネジ
メントコンソールで確認し、変更することができます。また、各
WorkSpace のプライマリネットワークインターフェイスは、ENI
Amazon EC2 リソースとしてカウントされ、制限の対象になりま
す。WorkSpaces の大規模デプロイについては、AWS マネジメン
トコンソールを通じてサポートチケットを開き、ENI 制限の値を引
き上げる必要があります。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
11/55 ページ
トラフィックフロー
Amazon WorkSpaces のトラフィックは、次の 2 つのメインコンポーネントに分
けることができます。
クライアントデバイスと Amazon WorkSpaces サービスの間のトラフィック
Amazon WorkSpaces サービスとお客様のネットワークの間のトラフィック
次のセクションでは、これらのコンポーネントについて説明します。
クライアントデバイスから WorkSpace へのトラフィック
場所 (オンプレミスまたはリモート) に関係なく、Amazon WorkSpaces クライア
ントを実行するデバイスでは、WorkSpaces サービスに接続するために、同じ 2
つのポートが使用されます。クライアントでは、すべての認証およびセッション
関連情報についてポート 443 で https が使用され、指定の WorkSpace に対する
ピクセルストリーミングとネットワークヘルスチェック用に、TCP および UDP
の両方でポート 4172 (PCoIP ポート) が使用されます。いずれのポートでも、ト
ラフィックは暗号化されます。ポート 443 のトラフィックは認証とセッション
の情報に使用され、トラフィックの暗号化には TLS が利用されます。ピクセル
ストリーミングのトラフィックでは、ストリーミングゲートウェイを通じた
WorkSpace のクライアントと eth0 との間の通信に、AES-256-bit 暗号化が利用
されます。詳細については、このドキュメントの「セキュリティ」セクションを
参照してください。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
12/55 ページ
PCoIP ストリーミングゲートウェイとネットワークヘルスチェックのエンドポイ
ントについては、リージョンごとの IP 範囲が公開されています。ポート 4172 で
のアウトバウンドトラフィックは、社内ネットワークから AWS ストリーミング
ネットワークゲートウェイとネットワークヘルスチェックのエンドポイントに限
定できます。これには、Amazon WorkSpaces を使用している特定の AWS リー
ジョンに対するポート 4172 のアウトバウンドトラフィックのみを許可します。
IP 範囲とネットワークヘルスチェックのエンドポイントについては、Amazon
WorkSpaces の PCoIP ゲートウェイ IP 範囲を参照してください。
Amazon WorkSpaces クライアントには、ネットワークステータスチェックの機
能が組み込まれています。このユーティリティでは、アプリケーションの右下に
あるステータスインジケータによって、ユーザーのネットワークで接続がサポー
トされているかどうかが示されます。ネットワークステータスに関するさらに詳
しいビューにアクセスするには、クライアントの右下で [Network] を選択しま
す。その結果を図 1 に示します。
図 1: WorkSpaces クライアント – ネットワークチェック
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
13/55 ページ
ユーザーは、Directory Service 構造で使用されるディレクトリ (通常は社内ディレ
クトリ) へのログイン情報を指定して、クライアントから WorkSpaces サービスへ
の接続を開始します。ログイン情報は、https を通じて、Amazon WorkSpaces
サービスの認証ゲートウェイ (WorkSpace があるリージョン内) に送信されます。
すると Amazon WorkSpaces サービスの認証ゲートウェイは、WorkSpace に関連
付けられている特定の AWS Directory Service サービス構造にトラフィックを転送
します。たとえば、AD Connector を使用している場合、AD Connector は、オンプ
レミスまたは AWS VPC にある Active Directory サービスに、認証リクエストを直
接転送します (「AD DS デプロイメントのシナリオ」を参照してください)。AD
Connector は、認証情報を保存せず、ステートレスプロキシとして動作します。
結果として、AD Connector から Active Directory サーバーへの接続性が不可欠に
なります。AD Connector は、AD Connector の作成時に定義した DNS サーバーを
使用して、接続先の Active Directory サーバーを決定します。
AD Connector を使用している場合、ディレクトリで MFA が有効になっていれ
ば、ディレクトリサービスの認証前に MFA トークンの確認が行われます。MFA
検証に失敗した場合、ユーザーのログイン情報は AWS Directory Service に転送
されません。
ユーザーが認証されると、ポート 4172 (PCoIP ポート) を利用して、AWS スト
リーミングゲートウェイから WorkSpace へのストリーミングトラフィックが開
始されます。この場合も、セッション関連の情報は、セッション全体で https を
通じてやり取りされます。ストリーミングトラフィックでは、VPC に接続され
ていない WorkSpace の最初の ENI (WorkSpace の eth0) が使用されます。スト
リーミングゲートウェイから ENI へのネットワーク接続は、AWS によって管理
されます。ストリーミングゲートウェイから WorkSpaces のストリーミング ENI
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
14/55 ページ
への接続に失敗した場合は、CloudWatch イベントが生成されます (このホワイ
トペーパーの「Amazon CloudWatch の使用によるモニタリングまたはログ記録」
セクションを参照してください)。
Amazon WorkSpaces サービスとクライアントとの間で送信されるデータの量は、
ピクセルアクティビティのレベルによって異なります。ユーザーエクスペリエン
スを最適化するには、WorkSpace のある AWS リージョンと WorkSpaces クライ
アントとの間のラウンドトリップ時間 (RTT) を 100 ms 未満に抑えることをお勧
めします。これは通常、WorkSpace がホストされているリージョンから約
3000km 以内の場所に WorkSpaces クライアントがあることを意味します。
Amazon WorkSpaces サービスへの接続用に最適な AWS リージョンを決定する
際に参照できる、接続状態の確認 Web ページが用意されています。
Amazon WorkSpaces Service から VPC へのトラフィック
クライアントから WorkSpace への接続が認証され、ストリーミングトラフィッ
クが開始すると、VPC に接続されている Windows デスクトップ (WorkSpace) が
WorkSpaces クライアントに表示されます。ネットワークステータスには、接続
が確立したことが示されます。WorkSpace のプライマリ ENI (eth1 として識別さ
れます) には、VPC によって提供される DHCP (Dynamic Host Configuration
Protocol) サービスから IP アドレス (通常は、AWS Directory Service と同じサブ
ネットのアドレス) が割り当てられます。WorkSpace の存続中、WorkSpace には
この IP アドレスが維持されます。VPC の ENI は、VPC 内のすべてのリソース
と、(VPC ピア接続、AWS Direct Connect 接続、または VPN 接続を経由して)
VPC に接続したすべてのネットワークにアクセスできます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
15/55 ページ
ネットワークリソースへの ENI アクセスは、AWS Directory Service によって各
WorkSpace に設定されるデフォルトのセキュリティグループと、ENI に割り当
てられている追加のセキュリティグループで決定されます (セキュリティグルー
プの詳細については、こちらを参照してください)。セキュリティグループは、
AWS マネジメントコンソールまたは CLI を利用して、VPC 側の ENI に自由に追
加できます。セキュリティグループに加えて、ホストベースの任意のファイア
ウォールを WorkSpace に使用して、VPC 内のリソースに対するネットワークア
クセスを制限することができます。
ここで説明したトラフィックフローについては、このホワイトペーパーの「AD
DS デプロイメントのシナリオ」の図 4 に示されています。
一般的な設定の例
2 種類のユーザーが存在し、AWS Directory Service のユーザー認証に中央の
Active Directory が使用されるシナリオについて考えてみましょう。
すべての場所へのフルアクセスを必要とするワーカー (正社員など)。これ
らのユーザーは、インターネットおよび内部ネットワークへのフルアクセ
スが許可され、VPC からオンプレミスネットワークへのファイアウォー
ルを通過できます。
社内ネットワーク内の限定的なアクセスのみが許可されるワーカー (請負
業者やコンサルタントなど)。これらのユーザーには、VPC 内でのプロキ
シサーバーを経由した限定的な (特定 Web サイトに対する) インターネッ
トアクセスが許可され、VPC 内およびオンプレミスネットワークに対す
る制限付きネットワークアクセスが許可されます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
16/55 ページ
正社員には、ソフトウェアをインストールできるように WorkSpace のローカル
管理者アクセスを付与し、MFA による多要素認証を適用することをお勧めしま
す。また、正社員には、自分の WorkSpace からインターネットへのアクセスも
制限せずに許可することをお勧めします。
請負業者については、特定のプレインストール済みアプリケーションのみを使用
できるように、ローカル管理者アクセスをブロックすることをお勧めします。こ
れらの WorkSpace には、セキュリティグループを通じて非常に限定的なネット
ワークアクセスコントロールを適用します。特定の内部 Web サイトに対しての
みポート 80 および 443 を開き、インターネットへのアクセスをブロックする必
要があります。
このシナリオでは、ネットワークおよびデスクトップアクセスの要件が異なる、
まったく別の 2 種類のユーザーペルソナを使用しています。ベストプラクティス
では、これらのユーザーペルソナの WorkSpace は、別々に管理および設定する
ようにします。これには、ユーザーペルソナごとに 1 つずつ、合計 2 つの AD
Connector を作成する必要があります。各 AD Connector には、WorkSpace 利用
の増加予測に応じて、十分な IP アドレスを提供するためのサブネットが 2 つ必
要です。
注意: 各 AWS VPC サブネットでは、管理目的に 5 個の IP アドレス
を使用し (先頭 4 個と最後の IP アドレス)、各 AD Connector には、
対応するサブネットごとに 1 つの IP アドレスを使用します。
このシナリオでは、さらに次の点についても考慮が必要です。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
17/55 ページ
AWS VPC サブネットは、プライベートサブネットである必要があります。
これにより、インターネットアクセスなどのトラフィックを NAT Gateway
またはクラウド内の Proxy-NAT サーバーを通じて制御するか、オンプレミ
スのトラフィック管理システムを通じてルートバックすることができます。
オンプレミスネットワークに対するすべての VPC トラフィックバウンドに
対応するファイアウォールが用意されています。
Microsoft Active Directory サーバーと MFA RADIUS サーバーは、オンプ
レミス配置 (「シナリオ 1: AD Connector の使用によるオンプレミス AD DS
への認証のプロキシ」を参照) の場合と AWS Cloud 実装 (「AD DS デプロ
イメントのシナリオ」のシナリオ 2 および 3 を参照) の一部である場合が
あります。
すべての WorkSpace がプライベートサブネットでホストされていて、なんらか
の形のインターネットアクセスが許可されている場合は、インターネットゲート
ウェイを通じてインターネットにアクセスできるパブリックサブネットも作成す
る必要があります。正社員用には、インターネットにアクセスするための NAT
ゲートウェイが必要であり、コンサルタントや請負業者には、アクセスを特定の
内部 Web サイトに限定するための Proxy-NAT サーバーが必要です。マルチ AZ
配置で障害に備え、高可用性を考慮した設計を行い、クロス AZ のトラフィック
料金を制限するには、2 つの異なるサブネットに 2 つの NAT ゲートウェイおよ
び NAT またはプロキシサーバーを配置する必要があります。パブリックサブ
ネットとして選択する 2 つの AZ は、3 つ以上の AZ が含まれるリージョンで
WorkSpace サブネットとして使用する 2 つの AZ に一致します。クロス AZ トラ
フィックの料金を制限し、管理を容易にするために、各 WorkSpace AZ からのす
べてのトラフィックを対応するパブリックサブネットにルーティングすることも
できます。図 2に、VPC の設定を示します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
18/55 ページ
図 2: VPC 設計の概要
前に示した 2 つの異なる種類の WorkSpace を設定する方法を次に示します。
正社員用: Amazon WorkSpaces マネジメントコンソールで、メニューバー
の [Directories] オプションを選択し、正社員をホストするディレクトリ
を選択して、[Local Administrator Setting] を選択します。このオプ
ションを有効にすることにより、新しく作成したすべての WorkSpace
に、ローカル管理者権限が付与されます。インターネットアクセスを許可
するには、VPC からのアウトバウンドインターネットアクセス用に NAT
(Network Address Translation) を設定する必要があります。MFA を有効に
するには、RADIUS サーバー、サーバー IP、ポート、および事前共有キー
を指定する必要があります。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
19/55 ページ
正社員の WorkSpace については、AD Connector 設定を通じてデフォルト
のセキュリティグループを適用することにより、WorkSpace へのインバウ
ンドトラフィックは、ヘルプデスクサブネットからの Remote Desktop
Protocol (RDP) に限定されます。
請負業者およびコンサルタント用: Amazon WorkSpaces マネジメントコン
ソールで、[Internet Access] および [Local Administrator Setting] を
無効にします。次に、そのディレクトリ内で作成するすべての新しい
WorkSpace にセキュリティグループを適用できるように、 [Security
Group] 設定セクションでセキュリティグループを追加します。
コンサルタント用 WorkSpace の場合は、AD Connector 設定で AD
Connector に関連付けられているすべての WorkSpace にデフォルトのセ
キュリティグループを適用することにより、WorkSpace に対するアウトバ
ウンドとインバウンドのトラフィックを制限します。セキュリティグルー
プにより、WorkSpace から HTTP トラフィックおよび HTTPS トラフィッ
ク以外へのアウトバウンドアクセスと、オンプレミスネットワークのヘル
プデスクサブネットから RDP へのインバウンドトラフィックを防ぎます。
注意: セキュリティグループは VPC 内の ENI (WorkSpace の eth1) に
のみ適用され、セキュリティグループを適用しても、WorkSpaces ク
ライアントから WorkSpace へのアクセスは制限されません。図 3
は、前に説明した最終的な WorkSpaces VPC 設計を示します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
20/55 ページ
図 3: WorkSpace の設計とユーザーペルソナ
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
21/55 ページ
AWS Directory Service
「はじめに」に記述したとおり、Amazon WorkSpaces は AWS Directory Service
をベースとしています。AWS Directory Service では、3 種類のディレクトリを作
成できます。最初の 2 つは AWS Cloud 内に維持されます。
Microsoft Active Directory (Enterprise Edition) (Microsoft AD とも呼ばれ
ます) 用の AWS Directory Service には、Windows Server 2012 R2 を使用し
ます。
Simple AD は、Samba 4 を使用するマネージド型ディレクトリサービス
です。
3 番目の AD Connector は、認証リクエストとユーザー/グループルックアップ
を既存のオンプレミス Microsoft Active Directory にプロキシするためのディレク
トリゲートウェイです。
次のセクションは、Amazon WorkSpaces ブローカーサービスと AWS Directory
Service との間の認証時の通信フロー、AWS Directory Service で WorkSpaces を
実装するためのベストプラクティス、MFA などの高度な概念について説明しま
す。大規模な Amazon WorkSpaces のインフラストラクチャアーキテクチャの概
念、Amazon VPC の要件のほか、AWS Directory Service (オンプレミスの
Microsoft Active Directory Domain Services (AD DS) との統合を含む) について説
明します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
22/55 ページ
AD DS デプロイメントのシナリオ
Amazon WorkSpaces は AWS Directory Service を基盤としており、ディレクトリ
サービスの適切な設計とデプロイメントが重要です。次の 3 つのシナリオの基に
なっている Microsoft Active Directory Domain Services のクイックスタートガイ
ドでは、WorkSpaces との統合など、AD DS のベストプラクティスのデプロイメ
ントオプションが詳細に示されています。この章の「設計上の考慮事項」セク
ションでは、WorkSpaces の全体的な設計の概念に不可欠な部分である、AD
Connector を WorkSpaces に使用する場合の具体的な要件およびベストプラク
ティスを説明します。
シナリオ 1: AD Connector の使用によるオンプレミス AD DS への認証
のプロキシ。このシナリオでは、お客様へのネットワーク接続
(VPN/Direct Connect (DX)) が用意されており、AWS Directory Service (AD
Connector) を通じてすべての認証がお客様のオンプレミス AD DS にプロ
キシされます。
シナリオ 2: オンプレミス AD DS の AWS への拡張 (レプリカ)。このシナ
リオは、シナリオ 1 と似ていますが、こちらでは、AD Connector と共にお
客様の AD DS のレプリカが AWS にデプロイされます。これにより、AD
DS および AD DS グローバルカタログへの認証/クエリリクエストのレイテ
ンシーが短縮されます。
シナリオ 3: AWS Cloud で AWS Directory Service を使用する分離型のス
タンドアロンデプロイメント。これは分離型のシナリオであり、お客様へ
の認証用接続は含まれていません。このアプローチでは、AWS Directory
Service (Microsoft AD) と AD Connector を使用します。このシナリオで、
認証はお客様への接続に依存しませんが、VPN または DX を通じて必要な
箇所にアプリケーショントラフィックのプロビジョニングを行います。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
23/55 ページ
シナリオ 1: AD Connector の使用によるオンプレミス AD DS への認
証のプロキシ
このシナリオは、オンプレミスの AD DS を AWS に拡張したくないお客様や、
AD DS の新しいデプロイメントという選択肢がない場合を対象としています。
図 4: オンプレミスの Active Directory に対する AD Connector は、各コンポーネ
ントの概要とユーザー認証フローを示しています。
図 4: オンプレミスの Active Directory に対する AD Connector
このシナリオでは、AD Connector を通じてお客様のオンプレミス AD DS にプロ
キシされたすべてのユーザーまたは MFA 認証に、AWS Directory Service (AD
Connector) が使用されています (図 5)。認証プロセスに使用されるプロトコルま
たは暗号化の詳細については、このホワイトペーパーの「セキュリティ」セク
ションを参照してください。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
24/55 ページ
図 5: 認証ゲートウェイによるユーザー認証
シナリオ 1 は、お客様のリソースが既に AWS にあり、WorkSpaces からアクセ
スできるオンプレミスのデータセンターにもリソースがあることが考えられるハ
イブリッドアーキテクチャを示しています。お客様はユーザーおよび MFA 認証
に、既存のオンプレミス AD DS および RADIUS サーバーを利用できます。
このアーキテクチャでは、次のコンポーネントまたは構造が使用されます。
アマゾン ウェブ サービス:
Amazon VPC: 2 つのアベイラビリティーゾーンに 2 つ以上のプライベー
トサブネットを持つ Amazon VPC を作成します。
DHCP オプションセット: Amazon VPC DHCP オプションセットを作成し
ます。これにより、お客様指定のドメイン名とドメインネームサーバー
(DNS) (オンプレミスサービス) の定義が可能になります (詳細について
は、「DHCP オプションセット」を参照してください)。
Amazon 仮想プライベートゲートウェイ: IPsec VPN トンネルまたは AWS
Direct Connect 接続を通じて、独自のネットワークとの通信を可能にしま
す。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
25/55 ページ
AWS Directory Service: AD Connector は、Amazon VPC プライベート
サブネットのペアにデプロイされます。
Amazon WorkSpaces: WorkSpaces は、AD Connector と同じプライベ
ートサブネットにデプロイされます (「設計上の考慮事項」で AD
Connector に関する記述を参照してください)。
お客様:
ネットワーク接続: 会社の VPN または Direct Connect エンドポイント。
AD DS: 会社の AD DS。
MFA (オプション): 会社の RADIUS サーバー。
エンドユーザーデバイス: Amazon WorkSpaces サービスへのアクセスに使用
される、会社または BYOL のエンドユーザーデバイス (Windows、Mac、
iPad または Android タブレット、ゼロクライアント、Chromebook など)
(「サポートされるプラットフォームとデバイス」を参照してください)。
このソリューションは AD DS をクラウドにデプロイしたくないお客様に最適で
すが、落とし穴もあります。
接続への依存: データセンターへの接続が失われると、ユーザーはそれぞ
れの WorkSpace にログインできなくなります。Kerberos/TGT の有効期間
中、既存の接続についてはアクティブな状態が維持されます。
レイテンシー: 接続を介したレイテンシーが存在する場合 (これは DX より
VPN の場合に該当します)、WorkSpaces 認証や AD DS 関連のアクティビ
ティ (グループポリシー (GPO) の適用など) の所要時間が長くなります。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
26/55 ページ
トラフィックコスト: すべての認証は、VPN または DX リンクを経由する
ため、接続タイプに依存します。これは、Amazon EC2 からインターネッ
トへのデータ送信か、データ送信 (DX) です。
注意: AD Connector はプロキシサービスです。ユーザー認証情報の
保存またはキャッシュは行われません。代わりに、すべての認証、
ルックアップ、管理リクエストは、Active Directory によって処理
されます。ディレクトリサービスでは、委任権限のあるアカウント
が必要です。このアカウントに、すべてのユーザー情報に対する読
み取り権限とコンピューターをドメインに参加させる権限を付与す
る必要があります。
AD Connector 用のディレクトリ内でユーザーを設定する方法の詳細について
は、「接続権限の委任」を参照してください。
一般的に、WorkSpaces のエクスペリエンスは、図 4 に示されている項目
5 に大きく左右されます。
シナリオ 2: オンプレミス AD DS の AWS への拡張 (レプリカ)
このシナリオは、シナリオ 1 と似ていますが、シナリオ 2 では、AD Connector
と共にお客様の AD DS のレプリカが AWS にデプロイされます。これにより、
AD DS への認証/クエリリクエストのレイテンシーが短縮されます。図 6 は、各
コンポーネントの概要とユーザー認証フローを示しています。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
27/55 ページ
図 6: お客様の Active Directory ドメインをクラウドに拡張する
シナリオ 1 と同様、すべてのユーザーまたは MFA 認証 (お客様の AD DS にプロ
キシされる) に AD Connector が使用されます (図 5)。シナリオ 2 では、Amazon
EC2 インスタンスのアベイラビリティーゾーンにユーザー AD DS がデプロイさ
れます。これらは、AWS Cloud で実行されるお客様のオンプレミス Active
Directory フォレスト内のドメインコントローラーに昇格されます。AWS Cloud
で AD DS の可用性を高めるために、各ドメインコントローラーは VPC のプライ
ベートサブネットにデプロイされます。AWS Cloud で AD DS をデプロイする際
のベストプラクティスについては、このホワイトペーパーの「設計上の考慮事
項」を参照してください。
デプロイされた WorkSpaces インスタンスは、安全で低レイテンシーのディレク
トリサービスと DNS のためにクラウドベースのドメインコントローラーにアク
セスできます。AD DS の通信、認証リクエスト、および Active Directory レプリ
ケーションを含むすべてのネットワークトラフィックは、プライベートサブネッ
ト内、お客様の VPN トンネル、DX でセキュリティ保護されます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
28/55 ページ
このアーキテクチャでは、次のコンポーネントまたは構造が使用されます。
アマゾン ウェブ サービス:
Amazon VPC: 2 つのアベイラビリティーゾーンに 4 つ以上のプライベー
トサブネット (お客様の AD DS 用に 2 つ、AD Connector または
WorkSpaces 用に 2 つ) を持つ Amazon VPC を作成します。
DHCP オプションセット: Amazon VPC DHCP オプションセットを作成し
ます。これにより、お客様指定のドメイン名と DNS (AD DS ローカル) の
定義が可能になります 詳細については、「DHCP オプションセット」を参
照してください。
Amazon 仮想プライベートゲートウェイ: IPsec VPN トンネルまたは AWS
Direct Connect 接続を通じて、独自のネットワークとの通信を可能にしま
す。
Amazon EC2:
専用のプライベート VPC サブネットで Amazon EC2 インスタンスにデプ
ロイされた、お客様の会社の AD DS ドメインコントローラー。
お客様の "オプションの" RADIUS サーバー (MFA 用)。
AWS Directory Service: AD Connector は、Amazon VPC プライベート
サブネットのペアにデプロイされます。
Amazon WorkSpaces: WorkSpaces は、AD Connector と同じプライベー
トサブネットにデプロイされます (「設計上の考慮事項」で AD Connector
に関する記述を参照してください)。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
29/55 ページ
お客様:
ネットワーク接続: 会社の VPN または AWS Direct Connect エンドポイント。
AD DS: 会社の AD DS (レプリケーション用に必要)。
MFA (オプション): 会社の RADIUS サーバー。
エンドユーザーデバイス: Amazon WorkSpaces サービスへのアクセスに使
用される、会社または BYOL のエンドユーザーデバイス (Windows、Mac、
iPad または Android タブレット、ゼロクライアント、Chromebook など)
(「サポートされるプラットフォームとデバイス」を参照してください)。
このソリューションには、シナリオ 1 の場合と同じ落とし穴はありません。この
ため、WorkSpaces と AWS Directory Service は、接続に依存性しません。
接続への依存: お客様のデータセンターへの接続が失われても、認証と "オ
プションの" MFA はローカルで処理するため、エンドユーザーは作業を続
行できます。
レイテンシー: レプリケーショントラフィックを例外として (「設計上の考
慮事項」の「Active Directory: サイトとサービス」を参照してください)、
すべての認証は低レイテンシーであり、ローカルで処理されます。
トラフィックコスト: このシナリオでは認証がローカルで処理され、VPN
または DX リンクを経由する必要があるのは AD DS レプリケーションのみ
であるため、データ転送が少なくなります。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
30/55 ページ
一般的に、WorkSpaces のエクスペリエンスは拡張され、図 6 に示されている項
目 5 に大きく左右されることはありません。これは、特に、AD DS グローバル
カタログクエリとの関連で何千ものデスクトップ用に WorkSpaces を拡大するよ
うな場合に該当します (このトラフィックは WorkSpaces 環境に対してローカル
のままであるため)。
シナリオ 3: AWS Cloud で AWS Directory Service を使用する分離
型のスタンドアロンデプロイメント
図 7 に示されている、このシナリオでは、分離型のスタンドアロン環境で、
AWS Cloud に AD DS がデプロイされています。このシナリオでは、AWS
Directory Service だけが使用されます。AD DS を自分でフルに管理する代わりに、
可用性の高いディレクトリトポロジの構築、ドメインコントローラーのモニタリ
ング、バックアップとスナップショットの設定などのタスクに AWS Directory
Service を使用できます。
図 7: クラウドのみ - AWS Directory Services (Microsoft AD)
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
31/55 ページ
シナリオ 2 と同様、2 つのアベイラビリティーゾーンにまたがる専用サブネット
に AD DS (Microsoft AD) をデプロイし、AWS Cloud での AD DS の可用性を高め
ます。Microsoft AD に加えて、WorkSpaces 認証または MFA 用に AD Connector
がデプロイされます (3 つのシナリオすべてに共通)。これにより、Amazon VPC
内でロールや機能を分離することができます。これは、標準的なベストプラク
ティスです (「設計上の考慮事項」でネットワークの分離に関する記述を参照し
てください)。
シナリオ 3 は、すべてが含まれた標準的な設定であり、AWS Directory Service
のデプロイ、パッチ、高可用性、モニタリングを AWS で管理したいお客様に適
しています。このシナリオは分離型であるため、本稼働に加えて、PoC (実証支
援) やラボ環境にも適しています。
図 7 では、AWS Directory Service の配置に加えて、ユーザーからワークスペー
スへのトラフィックフローや、ワークスペースと AD サーバーおよび MFA サー
バーとのやり取りについても示しています。
このアーキテクチャでは、次のコンポーネントまたは構造が使用されます。
アマゾン ウェブ サービス:
Amazon VPC: 2 つのアベイラビリティーゾーンに 4 つ以上のプライベー
トサブネット (AD DS (Microsoft AD) 用に 2 つ、AD Connector または
WorkSpaces 用に 2 つ) を持つ Amazon VPC を作成します (ロールの分離)。
DHCP オプションセット: Amazon VPC DHCP オプションセットを作成し
ます。これにより、お客様指定のドメイン名と DNS (Microsoft AD) の定義
が可能になります。詳細については、「DHCP オプションセット」を参照
してください。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
32/55 ページ
オプション: Amazon 仮想プライベートゲートウェイ: IPsec VPN トンネ
ル (VPN) または AWS Direct Connect 接続を通じて、独自のネットワーク
との通信を可能にします。オンプレミスのバックエンドシステム用に使用
します。
AWS Directory Service: Microsoft AD は、専用の VPC サブネットのペ
アにデプロイされます (AD DS マネージドサービス)。
Amazon EC2: お客様の "オプションの" RADIUS サーバー (MFA 用)。
AWS Directory Service: AD Connector は、Amazon VPC プライベート
サブネットのペアにデプロイされます。
Amazon WorkSpaces: WorkSpaces は、AD Connector と同じプライベー
トサブネットにデプロイされます (「設計上の考慮事項」で AD Connector
に関する記述を参照してください)。
お客様:
オプション: ネットワーク接続: 会社の VPN または AWS Direct Connect エ
ンドポイント。
エンドユーザーデバイス: Amazon WorkSpaces サービスへのアクセスに使
用される、会社または BYOL のエンドユーザーデバイス (Windows、Mac、
iPad または Android タブレット、ゼロクライアント、Chromebook など)
(「サポートされるプラットフォームとデバイス」を参照してください)。
シナリオ 2 と同様、このソリューションには、お客様のオンプレミスデータセン
ターへの接続に対する依存、レイテンシー、データ送信コストの問題がありませ
ん (VPC 内で WorkSpaces に対するインターネットアクセスが有効になっている
場合を除く)。このシナリオは、分離型またはクラウドのみのシナリオとして設
計されているためです。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
33/55 ページ
設計上の考慮事項
十分に機能する AD DS を AWS Cloud にデプロイするには、Active Directory の
概念と特定の AWS サービスについてよく理解しておく必要があります。このセ
クションでは、WorkSpaces 用に AD DS をデプロイする場合の設計上の重要な考
慮事項について説明します。また、AWS Directory Service を使用する場合の
VPC のベストプラクティス、DHCP および DNS の要件、AD Connector の仕様、
Active Directory のサイトとサービスについても説明します。
VPC の設計
このドキュメントの「ネットワークに関する考慮事項」セクションに記載されて
いるとおり、また、シナリオ 2 および 3 について説明したとおり、AWS Cloud
の AD DS は、2 つのアベイラビリティーゾーンにまたがるプライベートサブ
ネットの専用ペアにデプロイし、AD Connector または WorkSpaces のサブネッ
トから分離する必要があります。このような構造にすることで、Amazon VPC 内
でロールや機能の分離に関する標準的なベストプラクティスを維持しつつ、
WorkSpaces への AD DS サービスに対して、可用性が高くレイテンシーを抑えた
アクセスを提供できます。
図 8 では、専用のプライベートサブネットへの AD DS と AD Connector の分離
(シナリオ 3) を示しています。この例では、すべてのサーバーが同じ Amazon
VPC にあるものと想定しています。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
34/55 ページ
図 8: AD DS ネットワーク分離
図 9 は、シナリオ 1 と似た設計を示していますが、このシナリオでは、オンプレ
ミス部分が専用の Amazon VPC に配置されています。
図 9: 専用の WorkSpaces VPC
注意: 既存の AWS デプロイメントで AD DS を使用している場合
は、WorkSpaces を専用の VPC に配置し、AD DS の通信用に VPC
ピア接続を使用することをお勧めします。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
35/55 ページ
AD DS 用の専用プライベートサブネットの作成に加えて、ドメインコントロー
ラーとメンバーサーバーには、AD DS レプリケーション、ユーザー認証、
Windows Time サービス、分散ファイル システム (DFS) などのサービスにトラ
フィックを許可するために、複数のセキュリティグループルールが必要になり
ます。
注意: ベストプラクティスでは、必要なセキュリティグループの
ルールを WorkSpaces のプライベートサブネットに制限し、シナリ
オ 2 の場合は、次の表に示すように、オンプレミスと AWS Cloud
との間で双方向の AD DS 通信を有効にします。
プロトコル ポート 用途 送信先
tcp 53, 88, 135, 139, 389, 445, 464, 636
認証
(プライマリ)
Active Directory (プライベート
データセンターまたは EC2)*
tcp 49152 – 65535 RPC
ハイポート Active Directory (プライベート
データセンターまたは EC2)**
tcp 3268-3269 信頼 Active Directory (プライベート
データセンターまたは EC2)*
tcp 9389 リモートの
Microsoft Windows PowerShell (
オプション)
Active Directory (プライベート
データセンターまたは EC2)*
udp 53, 88, 123, 137, 138, 389, 445, 464
認証
(プライマリ)
Active Directory (プライベート
データセンターまたは EC2)*
udp 1812 認証 (MFA)
(オプション)
RADIUS (プライベートデータ
センターまたは EC2)*
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
36/55 ページ
* 「Active Directory and Active Directory Domain Services Port Requirements」
を参照してください。
**「Windows のサービス概要およびネットワーク ポート要件」を参照してくだ
さい。
ルールを実装する詳しい手順については、Amazon Elastic Compute Cloud ユー
ザーガイドの「セキュリティグループへのルールの追加」を参照してください。
VPC の設計: DHCP と DNS
Amazon VPC では、デフォルトで、インスタンスに DHCP サービスが提供され
ます。デフォルトでは、すべての VPC は、内部 DNS サーバーを提供します。こ
の DNS サーバーは、Classless Inter-Domain Routing (CIDR) +2 のアドレス空間
を通じてアクセスでき、デフォルトの DHCP オプションセットを通じてすべて
のインスタンスに割り当てられます。
DHCP オプションセットは、ドメイン名などの範囲オプションや、DHCP を介し
てインスタンスに渡すべきネームサーバーを定義するために、Amazon VPC 内で
使用されます。VPC 内で Windows サービスが正しく動作するかどうかは、この
DHCP の範囲オプションによって左右されるため、正しく設定する必要がありま
す。前に示した各シナリオでは、ドメイン名とネームサーバーを定義する独自の
範囲を作成し、割り当てます。これにより、ドメインに参加した Windows イン
スタンスまたは WorkSpaces が、Active Directory DNS を使用するように設定さ
れます。次の表は、WorkSpaces と AWS Directory Services が正しく動作するた
めに作成する必要のある DHCP 範囲オプションのカスタムセット例を示してい
ます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
37/55 ページ
パラメーター 値
名前タグ
キーに name、value に特定の文字列を指定し
て、タグを作成します。
例: exampleco.com
ドメイン名 exampleco.com
ドメインネームサーバー
カンマで区切った、DNS サーバーの IP アドレ
ス。
例: 10.0.0.10、10.0.1.10
NTP サーバー このフィールドは空白にしておきます。
NetBIOS ネームサーバー
ドメインネームサーバーと同様に、コンマで区
切った IP を入力します。
例: 10.0.0.10、10.0.1.10
NetBIOS ノードの種類 2
カスタム DHCP オプション設定を作成し、Amazon VPC と関連付ける方法の詳
細については、Amazon Virtual Private Cloud ユーザーガイドの「DHCP オプ
ションセットを使用する」を参照してください。
シナリオ 1 では、DHCP 範囲はオンプレミスの DNS または AD DS になります。
これは、シナリオ 2 または 3 では、ローカルにデプロイされたディレクトリサー
ビスになります (Amazon EC2 の AD DS か、AWS Directory Services: Microsoft
AD)。AWS Cloud に配置する各ドメインコントローラーを、グローバルカタログ
とディレクトリが統合された DNS にすることをお勧めします。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
38/55 ページ
Active Directory: サイトとサービス
シナリオ 2 では、サイトとサービスは AD DS の正しい機能の重要なコンポーネ
ントです。サイトトポロジは、同じサイト内のドメインコントローラーや、サイ
トの境界を超えたドメインコントローラーの間で Active Directory レプリケー
ションを制御します。シナリオ 2 では、2 つ以上のサイトが存在します (オンプ
レミスとクラウド内の AWS WorkSpaces)。正しいサイトトポロジを定義するこ
とにより、クライアントアフィニティを確保できます。つまり、クライアント
(この場合は WorkSpaces) に、クライアント側で指定されたローカルドメインコ
ントローラーが使用されます。
図 10: Active Directory サイトとサービス: クライアントアフィニティ
ベストプラクティス: オンプレミスの AD DS と AWS Cloud との間
のサイトリンクについて、最大コストを定義しておきます。図 10
は、サイトに依存しないクライアントアフィニティを確保するため
にサイトリンクに割り当てるコストの例です (コスト 100)。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
39/55 ページ
このような関連付けにより、AD DS レプリケーション、クライアント認証など
のトラフィックで、ドメインコントローラーへの最も効率的なパスが使用される
ようになります。シナリオ 2 および 3 の場合は、レイテンシーの短縮とクロスリ
ンクトラフィックの削減につながります。
Multi-Factor Authentication (MFA) MFA を実装するには、WorkSpaces インフラストラクチャで AWS Directory
Service として AD Connector を使用し、RADIUS サーバーを指定する必要があり
ます。このドキュメントでは RADIUS サーバーのデプロイメントについては説
明しませんが、前の「AD DS デプロイメントのシナリオ」セクションには、各
シナリオでの RADIUS の配置について記載されています。
MFA – 2 要素認証
Amazon WorkSpaces では、AWS Directory Service である AD Connector と、お
客様所有の RADIUS サーバーを通じて MFA がサポートされます。有効になる
と、ユーザーは各自の WorkSpace デスクトップへの認証用に、WorkSpaces ク
ライアントに [Username]、[Password]、および [MFA Code] を指定するよ
う求められます。
図 11: MFA が有効になった場合の WorkSpaces クライアント
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
40/55 ページ
ハードルール: MFA 認証の実装には、AD Connector の使用が求め
られます。AD Connector は AD Connector 設定によってグローバル
であるため、"ユーザーごとの" 選択的な MFA はサポートされませ
ん。"ユーザーごとの" 選択的な MFA が必要な場合は、ユーザーを
AD Connector で分離する必要があります。
WorkSpace の MFA には、1 台以上の RADIUS サーバーが必要です。これらは
RSA などの既存ソリューションであることが一般的ですが、サーバーを VPC 内
にデプロイすることもできます (AD DS デプロイメントのシナリオ を参照してく
ださい)。新しい RADIUS ソリューションをデプロイする場合、現在使用可能な
実装として FreeRADIUS などがあり、クラウドサービスとして Duo Security な
どがあります。
Amazon WorkSpaces に MFA を実装するための前提条件のリストについては、
Amazon WorkSpaces 管理者ガイドの「ネットワークでの AD Connector ディレ
クトリの準備」を参照してください。MFA 用に AD Connector を設定するプロセ
スについては、Amazon WorkSpaces 管理者ガイドの「AD Connector ディレク
トリの管理」の「多要素認証」を参照してください。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
41/55 ページ
セキュリティ
ここでは、Amazon WorkSpaces サービスの使用時に暗号化でデータを保護する
方法について説明します。伝送中と保管時の暗号化のほか、セキュリティグルー
プを利用して WorkSpaces へのネットワークアクセスを保護する方法を示しま
す。認証に関する追加情報 (MFA サポートに関する情報を含む) については、
「AWS Directory Service」セクションを参照してください。
伝送中の暗号化
Amazon WorkSpaces では暗号を使用することにより、通信の各ステージ (伝送
中) における機密性を保護し、保管時のデータも保護します (暗号化された
WorkSpace)。伝送中に Amazon WorkSpaces で使用される暗号化の各ステージ
のプロセスについては、以下の各セクションで説明します。保管時の暗号化の詳
細については、このホワイトペーパーの「暗号化された WorkSpace」を参照し
てください。
登録と更新
デスクトップクライアントアプリケーションは、登録と更新のために、https を
使用して Amazon と通信します。
認証ステージ
デスクトップクライアントは、認証情報を認証ゲートウェイに送信することで認
証を開始します。デスクトップクライアントと認証ゲートウェイの間の通信に
は、https が使用されます。このステージの終了時に認証に成功していれば、認
証ゲートウェイは同じ https 接続を使用してデスクトップクライアントに OAuth
2.0 トークンを返します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
42/55 ページ
注意: デスクトップクライアントアプリケーションでは、更新、登
録、認証用のポート 443 (HTTPS) トラフィックにプロキシサー
バーの使用がサポートされます。
クライアントから認証情報を受信すると、認証ゲートウェイは AWS Directory
Service に認証リクエストを送信します。認証ゲートウェイから AWS Directory
Service への通信には HTTPS が使用されるため、ユーザー認証情報がクリアテキ
ストで送信されることはありません。
認証 - AD Connector
AD Connector では、LDAP にバインドして後続の LDAP クエリを実行できるよ
うに、オンプレミス AD との認証済み通信を確立する際に Kerberos が使用され
ます。現時点では、AWS Directory Service では LDAP with TLS (LDAPs) がサ
ポートされていません。ただし、どのような場合もユーザー認証情報がクリアテ
キストで送信されることはありません。セキュリティの向上のために、VPN 接
続を使用して WorkSpaces VPC を (AD が存在する) オンプレミスネットワークに
接続することができます。AWS ハードウェアの VPN 接続を使用する場合は、伝
送中の暗号化をセットアップします。これには、標準の IPSEC (IKE および
IPSEC SA) に、AES-128 または AES-256 対称暗号化キー、整合性ハッシュ用の
SHA-1 または SHA-256、DH グループ (フェーズ 1 用に 2、14-18、22、23、24、
フェーズ 2 用に 1、2、5、14-18、22、23、24)、PFS を使用します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
43/55 ページ
ブローカーステージ
(認証に成功した場合に認証ゲートウェイから) OAuth 2.0 トークンを受信した
後、デスクトップクライアントは HTTPS を使用して Amazon WorkSpaces サー
ビス (ブローカー接続マネージャー) を照会します。デスクトップクライアント
は OAuth 2.0 トークンを送信することで自身の認証を行い、その結果、
WorkSpaces ストリーミングゲートウェイのエンドポイント情報を受信します。
ストリーミングステージ
デスクトップクライアントはストリーミングゲートウェイに、PCoIP セッション
を開くようリクエストします (OAuth 2.0 トークンを使用)。このセッションは
aes256 暗号化され、通信制御用に PCoIP ポート (4172/tcp) が使用されます。
ストリーミングゲートウェイは OAuth2.0 トークンを使用して、https 経由で
WorkSpaces サービスにユーザー固有の WorkSpace 情報をリクエストします。
ストリーミングゲートウェイは、クライアントから TGT (クライアントユーザー
のパスワードを使用して暗号化済み) も受信し、取得したユーザーの Kerberos
TGT パススルーを使用して、WorkSpace への Windows ログインを開始します。
次に、WorkSpace は標準の Kerberos 認証を使用して、設定された AWS
Directory Service への認証リクエストを開始します。
WorkSpace へのログインが成功すると、PCoIP ストリーミングが開始します。
接続は、ポート tcp 4172 でクライアントによって開始されます (リターントラ
フィックはポート udp 4172)。さらに、管理インターフェイスを使用したスト
リーミングゲートウェイと WorkSpace デスクトップの初期接続には、UDP
55002 が使用されます (Amazon Workspaces に関するドキュメント「Amazon
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
44/55 ページ
WorkSpaces の詳細」を参照してください。初期アウトバウンド UDP ポートは
55002 です)。ポート 4172 (tcp と udp) を使用するストリーミング接続は、AES
128 ビットおよび 256 ビット暗号化方式を使用して暗号化されますが、デフォル
トは 128 ビットです。この設定は、PCoIP 固有の Active Directory GPO
(pcoip.adm) を使用して 256 ビットへ明示的に変更することができます。
ネットワークインターフェイス
各 Amazon WorkSpace には、プライマリネットワークインターフェイスおよび
管理ネットワークインターフェイスという 2 つのネットワークインターフェイス
があります。
プライマリネットワークインターフェイスは、AWS Directory Service、インター
ネット、社内ネットワークへのアクセスなど、VPC 内のリソースへの接続を提
供します。このプライマリネットワークインターフェイスには、セキュリティグ
ループをアタッチすることもできます (ENI へのアタッチと同様)。概念上、この
ENI にアタッチされるセキュリティグループは、デプロイメントの範囲に基づい
て区別されます (WorkSpace セキュリティグループと ENI セキュリティグルー
プ)。
管理ネットワークインターフェイス
管理ネットワークインターフェイスをセキュリティグループで制御することはで
きませんが、WorkSpace でホストベースのファイアウォールを利用して、ポー
トのブロックやアクセスの制御を行うことができます。管理ネットワークイン
ターフェイスに制限を適用することはお勧めしません。ホストベースのファイア
ウォールルールを追加してこのインターフェイスを管理する場合は、
WorkSpaces サービスで WorkSpace へのアクセスと状態を管理できるように、
Amazon WorkSpaces 管理者ガイドの説明に従って、いくつかのポートを開けて
おく必要があります。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
45/55 ページ
WorkSpace セキュリティグループ
デフォルトのセキュリティグループは、AWS Directory Service によって作成さ
れ、特定のディレクトリに含まれるすべての WorkSpace に自動的にアタッチさ
れます。
他のセキュリティグループと同様、WorkSpace セキュリティグループの場合も
ルールを変更することができます。変更を適用すると、結果は直ちに有効になり
ます。
WorkSpace とセキュリティグループの関連付けを変更することで、AWS
Directory Service にアタッチされたデフォルトの WorkSpace セキュリティグ
ループを変更することもできます。
注意: 新しく関連付けたセキュリティグループは、変更後に作成ま
たは再構築された WorkSpace にのみアタッチされます。
ENI セキュリティグループ
プライマリネットワークインターフェイスは通常の ENI であるため、さまざま
な AWS 管理ツールを使用して設定を管理できます (「Elastic Network Interfaces
(ENI)」を参照してください )。特に、 (Amazon WorkSpaces コンソールの
WorkSpace ページで) WorkSpace IP を探し、その IP アドレスをフィルタとして
使用して、(Amazon EC2 コンソールのネットワークインターフェイスセクショ
ンで) 対応する ENI を検索できます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
46/55 ページ
ENI が見つかったら、そこから直接、セキュリティグループを管理できます。プ
ライマリネットワークインターフェイスにセキュリティグループを手動で割り当
てる場合は、「Amazon WorkSpaces の詳細」に説明されているように、
Amazon WorkSpaces のポート要件を考慮してください。
図 12: セキュリティグループの関連付けの管理
暗号化された WorkSpace
各 WorkSpace には、ルートボリューム (C: ドライブ) とユーザーボリューム (D:
ドライブ) が用意されています。暗号化された WorkSpace の機能を使用すると、
いずれかのボリュームまたは両方のボリュームを暗号化できます。
暗号化の対象
保管時のデータ、ボリュームへのディスク I/O、暗号化されたボリュームから作
成されたスナップショットは、すべて暗号化されます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
47/55 ページ
暗号化のタイミング
WorkSpace の暗号化は、WorkSpace の起動時 (作成時) に指定する必要がありま
す。WorkSpace ボリュームを暗号化できるのは、起動時のみです。起動後は、
ボリュームの暗号化ステータスを変更できません。図 13 は、新しい WorkSpace
の起動時に暗号化を選択するための Amazon WorkSpaces コンソールページを示
しています。
図 13: WorkSpace ボリュームの暗号化
新しい WorkSpace の暗号化の仕組み
暗号化された WorkSpace のオプションは、Amazon WorkSpaces コンソールまた
は AWS CLI から選択することも、新しい WorkSpace の起動時に Amazon
WorkSpaces API を使用して選択することもできます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
48/55 ページ
ボリュームを暗号化するために、 Amazon WorkSpaces では AWS Key
Management Service (KMS) から取得したカスタマーマスターキー (CMK) が使用
されます。リージョン内で WorkSpace が初めて起動されると、デフォルトの
AWS KMS CMK が作成されます (CMK にはリージョン範囲が設定されます)。お
客様が管理する CMK を作成して、暗号化された WorkSpace に使用することもで
きます。CMK はデータキーの暗号化に使用され、これらのデータキーは Amazon
WorkSpaces サービスによるボリュームの暗号化に使用されます (厳密には、ボ
リュームを暗号化するのは Amazon Elastic Block Store (Amazon EBS) サービスで
す)。各 CMK は、最大 30 個 の WorkSpace の暗号化に使用できます。
注意: 暗号化された WorkSpace からのカスタムイメージの作成
は、現在サポートされていません。また、ルートボリュームの暗号
化を有効にした状態で起動された WorkSpace では、プロビジョニ
ングに最大 1 時間かかる場合があります。
WorkSpace の暗号化プロセスの詳細については、「AWS KMS を使用した
Amazon WorkSpaces 暗号化の概要」を参照してください。AWS KMS カスタ
マーマスターキーおよびデータキーの追加情報については、「AWS Key
Management Service の概念」を参照してください。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
49/55 ページ
Amazon CloudWatch の使用によるモニタ
リングまたはログ記録
モニタリングは、ネットワーク、サーバー、ログなど、どのようなインフラスト
ラクチャにおいても不可欠な部分です。Amazon WorkSpaces をデプロイするお
客様は、全体的な状態や、個々の WorkSpace の接続ステータスなどについて、
デプロイメントをモニタリングする必要があります。
WorkSpace に関する Amazon CloudWatch メトリッ
クス
WorkSpace に関する Amazon CloudWatch メトリックスは、全体的な状態や個々
の WorkSpace の接続ステータスなどの情報を管理者が詳しく確認できるように
設計されています。メトリックスは WorkSpace 単位で利用でき、組織のすべて
の WorkSpace について、指定のディレクトリ内で集計されます (AD Connector
の ID を参照してください)。
メトリックス (すべての CloudWatch メトリックスなど) は、AWS マネジメント
コンソール (図 13) で確認し、CloudWatch API でアクセスして、CloudWatch ア
ラームやサードパーティー製ツールでモニタリングできます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
50/55 ページ
図 14: CloudWatch メトリックス – ConnectionAttempt/ConnectionFailure
デフォルトでは、次のメトリックスが無料で有効になり、使用可能です。
Available: ステータスチェックに応答した WorkSpace は、このメトリッ
クスにカウントされます。
Unhealthy: 同じステータスチェックに応答しない WorkSpace は、このメ
トリックスにカウントされます。
ConnectionAttempt: WorkSpace に対する接続の試行数。
ConnectionSuccess: 接続に成功した試行数。
ConnectionFailure: 接続に成功しなかった試行数。
SessionLaunchTime: セッションの開始にかかった時間 (WorkSpaces
クライアントが計測)。
InSessionLatency: WorkSpaces クライアントと WorkSpace 間のラウン
ドトリップ時間 (クライアントが計測および報告)。
SessionDisconnect: ユーザーが開始して自動的に閉じられたセッション
の数。
これに加え、図 15 に示されているようにアラームを作成することもできます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
51/55 ページ
図 15: WorkSpace 接続エラー用の CloudWatch アラームを作成する
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
52/55 ページ
トラブルシューティング
"Your device is not able to connect to the WorkSpaces Registration service" などの
エラーメッセージが表示されたり、インタラクティブなログオンバナーで
WorkSpace に接続できないなど、管理またはクライアントに関する一般的な問
題については、Amazon WorkSpaces 管理者ガイドのクライアントおよび管理の
問題に関するトラブルシューティングのページを参照してください。
AD Connector が Active Directory に接続できない
AD Connector でオンプレミスディレクトリに接続するには、オンプレミスネッ
トワークのファイアウォールで VPC の両方のサブネットの CIDR に対して特定
のポートが開かれている必要があります (「AD Connector」を参照してくださ
い)。これらの要件が満たされているかどうかをテストするには、以下の手順を
実行します。
接続を確認するには
1. VPC で Windows インスタンスを起動し、RDP 経由でインスタンスに接続
します。残りの手順は、VPC インスタンスで実行します。
2. DirectoryServicePortTest というテストアプリケーションをダウンロード
して解凍します。ソースコードと Visual Studio プロジェクトファイルが含
まれており、必要であればテストアプリケーションを変更できます。
3. Windows のコマンドプロンプトで、次のオプションを指定して
DirectoryServicePortTest テストアプリケーションを実行します。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
53/55 ページ
DirectoryServicePortTest.exe -d <domain_name> -ip <server_IP_address> -tcp
"53,88,135,139,389,445,464,636,49152" -udp "53,88,123,137,138,389,445,464"
<domain_name>
<domain_name>
フォレストとドメインの機能レベルをテストするために使用される、完全修飾ド
メイン名。ドメイン名を除外した場合、機能レベルはテストされません。
<server_IP_address>
オンプレミスドメインのドメインコントローラーの IP アドレス。ポートはこの
IP アドレスに対してテストされます。IP アドレスを除外した場合、ポートはテ
ストされません。
これによって、必要なポートが VPC からドメインに開かれているかどうかを特
定します。テストアプリケーションでは、最小限のフォレストとドメインの機能
レベルの確認も行われます。
最も近い AWS リージョンに対するレイテンシーの確
認方法
2015 年 10 月、Amazon WorkSpaces では接続状態の確認 Web サイトが開始され
ました。この Web サイトでは、WorkSpaces を使用するために必要なすべての
サービスにアクセスできるかどうかをすばやく確認できます。また、WorkSpace
が実行されている各 AWS リージョンのパフォーマンスチェックも行われ、ユー
ザーにとってどのリージョンが速度面で最も優れているかが示されます。
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
54/55 ページ
まとめ
各組織がアジャイル性を促進し、データの保護を強化してワーカーの生産性を高
めようと努力する中で、エンドユーザーコンピューティングにおける戦略が変わ
ろうとしています。クラウドコンピューティングで既に実現している利点の多く
が、エンドユーザーコンピューティングにも当てはまります。Amazon
WorkSpaces でエンドユーザーのデスクトップを AWS Cloud に移動すること
で、組織ではワーカーの増加に伴う拡張を迅速に行うことができるようになりま
す。また、オフデバイスでデータを保管することによってセキュリティ体制を強
化し、好みのデバイスを使用してどこからでもアクセスが可能なポータブルデス
クトップをワーカーに提供できます。
Amazon WorkSpaces は、既存の IT システムおよびプロセスに統合できるように
設計されており、このホワイトペーパーではそのためのベストプラクティスにつ
いて説明しています。このホワイトペーパーに記載されているガイドラインに従
うことで、費用効率に優れたクラウドデスクトップのデプロイが可能になり、
AWS のグローバルなインフラストラクチャでビジネスに合わせて拡張すること
ができます。
寄稿者
本書の執筆に当たり、次の方々に寄稿していただきました。
Justin Bradley、ソリューションアーキテクト、アマゾンウェブサービス
Mahdi Sajjadpour、シニアコンサルタント、AWS プロフェッショナルサー
ビス
Mauricio Munoz、ソリューションアーキテクト、アマゾンウェブサービス
AWS - Amazon WorkSpaces をデプロイするためのベストプラクティス 2016 年 7 月
55/55 ページ
その他の資料
追加情報については、次の資料を参照してください。
AWS Directory Service の管理の問題のトラブルシューティング
Amazon WorkSpaces の管理の問題のトラブルシューティング
Amazon WorkSpaces クライアントの問題のトラブルシューティング
Amazon WorkSpaces 管理者ガイド
Amazon WorkSpaces 開発者ガイド
サポートされるプラットフォームとデバイス
Amazon WorkSpaces で AWS KMS を使用する方法
AWS CLI コマンドリファレンス – workspaces
Amazon WorkSpaces メトリックスのモニタリング