amazon workspaces をデプロイするためのベストプラクティス · aws - amazon...

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 とお客様の間で行われるいかなる契約の一部でもなく、そのような契約の

内容を変更するものでもありません。


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


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 に拡張する。

https://aws.amazon.com/directoryservice/details/


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 の詳細を示し、サービスの仕組

みとサービスの開始方法を説明します。また、使用できるオプションと機能につ

いても説明します。

https://aws.amazon.com/workspaces/applicationmanager/

https://aws.amazon.com/workspaces/applicationmanager/


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 つ以上必要になります。

http://docs.aws.amazon.com/workspaces/latest/adminguide/client_help.html#client_list

http://www.teradici.com/product-finder/aws/zero-clients


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 に適用するセキュリティグ


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 間で分割して使用することができます。


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 に移行している方法」を参照してください。

https://www.youtube.com/watch?v=kawZBGCLBJU

https://www.youtube.com/watch?v=kawZBGCLBJU


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 制限の値を引

き上げる必要があります。

http://docs.aws.amazon.com/workspaces/latest/adminguide/admin_details.html


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 暗号化が利用

されます。詳細については、このドキュメントの「セキュリティ」セクションを

参照してください。


12/55 ページ

PCoIP ストリーミングゲートウェイとネットワークヘルスチェックのエンドポイ

ントについては、リージョンごとの IP 範囲が公開されています。ポート 4172 で

のアウトバウンドトラフィックは、社内ネットワークから AWS ストリーミング

ネットワークゲートウェイとネットワークヘルスチェックのエンドポイントに限

定できます。これには、Amazon WorkSpaces を使用している特定の AWS リー

ジョンに対するポート 4172 のアウトバウンドトラフィックのみを許可します。

IP 範囲とネットワークヘルスチェックのエンドポイントについては、Amazon

WorkSpaces の PCoIP ゲートウェイ IP 範囲を参照してください。

Amazon WorkSpaces クライアントには、ネットワークステータスチェックの機

能が組み込まれています。このユーティリティでは、アプリケーションの右下に

あるステータスインジケータによって、ユーザーのネットワークで接続がサポー

トされているかどうかが示されます。ネットワークステータスに関するさらに詳

しいビューにアクセスするには、クライアントの右下で [Network] を選択しま

す。その結果を図 1 に示します。

図 1: WorkSpaces クライアント – ネットワークチェック

https://aws.amazon.com/about-aws/whats-new/2015/09/amazon-workspaces-pcoip-gateway-ip-ranges/

https://aws.amazon.com/about-aws/whats-new/2015/09/amazon-workspaces-pcoip-gateway-ip-ranges/


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


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 に接続したすべてのネットワークにアクセスできます。

https://clients.amazonworkspaces.com/Health.html


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 内およびオンプレミスネットワークに対す

る制限付きネットワークアクセスが許可されます。

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/admin_details.html#member_security_group


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 アドレスを使用します。

このシナリオでは、さらに次の点についても考慮が必要です。


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 の設定を示します。


18/55 ページ

図 2: VPC 設計の概要

前に示した 2 つの異なる種類の WorkSpace を設定する方法を次に示します。

正社員用: Amazon WorkSpaces マネジメントコンソールで、メニューバー

の [Directories] オプションを選択し、正社員をホストするディレクトリ

を選択して、[Local Administrator Setting] を選択します。このオプ

ションを有効にすることにより、新しく作成したすべての WorkSpace

に、ローカル管理者権限が付与されます。インターネットアクセスを許可

するには、VPC からのアウトバウンドインターネットアクセス用に NAT

(Network Address Translation) を設定する必要があります。MFA を有効に

するには、RADIUS サーバー、サーバー IP、ポート、および事前共有キー

を指定する必要があります。


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 設計を示します。


20/55 ページ

図 3: WorkSpace の設計とユーザーペルソナ


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) との統合を含む) について説

明します。


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 を通じて必要な

箇所にアプリケーショントラフィックのプロビジョニングを行います。

https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html

https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html


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)。認証プロセスに使用されるプロトコルま

たは暗号化の詳細については、このホワイトペーパーの「セキュリティ」セク

ションを参照してください。


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 接続を通じて、独自のネットワークとの通信を可能にしま

す。

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html


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) の適用など) の所要時間が長くなります。



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 は、各

コンポーネントの概要とユーザー認証フローを示しています。

http://docs.aws.amazon.com/workspaces/latest/adminguide/connect_delegate_privileges.html


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 でセキュリティ保護されます。


28/55 ページ




トサブネット (お客様の AD DS 用に 2 つ、AD Connector または

WorkSpaces 用に 2 つ) を持つ Amazon VPC を作成します。


ます。これにより、お客様指定のドメイン名と DNS (AD DS ローカル) の

定義が可能になります詳細については、「DHCP オプションセット」を参

照してください。

Amazon 仮想プライベートゲートウェイ: IPsec VPN トンネルまたは AWS

Direct Connect 接続を通じて、独自のネットワークとの通信を可能にしま

す。

Amazon EC2:

専用のプライベート VPC サブネットで Amazon EC2 インスタンスにデプ

ロイされた、お客様の会社の AD DS ドメインコントローラー。

お客様の "オプションの" RADIUS サーバー (MFA 用)。



Amazon WorkSpaces: WorkSpaces は、AD Connector と同じプライベー

トサブネットにデプロイされます (「設計上の考慮事項」で AD Connector

に関する記述を参照してください)。



29/55 ページ

お客様:

ネットワーク接続: 会社の VPN または AWS Direct Connect エンドポイント。

AD DS: 会社の AD DS (レプリケーション用に必要)。

MFA (オプション): 会社の RADIUS サーバー。

エンドユーザーデバイス: Amazon WorkSpaces サービスへのアクセスに使

用される、会社または BYOL のエンドユーザーデバイス (Windows、Mac、



このソリューションには、シナリオ 1 の場合と同じ落とし穴はありません。この

ため、WorkSpaces と AWS Directory Service は、接続に依存性しません。

接続への依存: お客様のデータセンターへの接続が失われても、認証と "オ

プションの" MFA はローカルで処理するため、エンドユーザーは作業を続

行できます。

レイテンシー: レプリケーショントラフィックを例外として (「設計上の考

慮事項」の「Active Directory: サイトとサービス」を参照してください)、

すべての認証は低レイテンシーであり、ローカルで処理されます。

トラフィックコスト: このシナリオでは認証がローカルで処理され、VPN

または DX リンクを経由する必要があるのは AD DS レプリケーションのみ

であるため、データ転送が少なくなります。



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)


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 サー

バーとのやり取りについても示しています。




トサブネット (AD DS (Microsoft AD) 用に 2 つ、AD Connector または

WorkSpaces 用に 2 つ) を持つ Amazon VPC を作成します (ロールの分離)。


ます。これにより、お客様指定のドメイン名と DNS (Microsoft AD) の定義

が可能になります。詳細については、「DHCP オプションセット」を参照

してください。

https://aws.amazon.com/de/directoryservice/details/



32/55 ページ

オプション: Amazon 仮想プライベートゲートウェイ: IPsec VPN トンネ

ル (VPN) または AWS Direct Connect 接続を通じて、独自のネットワーク

との通信を可能にします。オンプレミスのバックエンドシステム用に使用

します。

AWS Directory Service: Microsoft AD は、専用の VPC サブネットのペ

アにデプロイされます (AD DS マネージドサービス)。

Amazon EC2: お客様の "オプションの" RADIUS サーバー (MFA 用)。



Amazon WorkSpaces: WorkSpaces は、AD Connector と同じプライベー

トサブネットにデプロイされます (「設計上の考慮事項」で AD Connector

に関する記述を参照してください)。

お客様:

オプション: ネットワーク接続: 会社の VPN または AWS Direct Connect エ

ンドポイント。

エンドユーザーデバイス: Amazon WorkSpaces サービスへのアクセスに使

用される、会社または BYOL のエンドユーザーデバイス (Windows、Mac、



シナリオ 2 と同様、このソリューションには、お客様のオンプレミスデータセン

ターへの接続に対する依存、レイテンシー、データ送信コストの問題がありませ

ん (VPC 内で WorkSpaces に対するインターネットアクセスが有効になっている

場合を除く)。このシナリオは、分離型またはクラウドのみのシナリオとして設

計されているためです。



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 にあるものと想定しています。


34/55 ページ

図 8: AD DS ネットワーク分離

図 9 は、シナリオ 1 と似た設計を示していますが、このシナリオでは、オンプレ

ミス部分が専用の Amazon VPC に配置されています。

図 9: 専用の WorkSpaces VPC

注意: 既存の AWS デプロイメントで AD DS を使用している場合

は、WorkSpaces を専用の VPC に配置し、AD DS の通信用に VPC

ピア接続を使用することをお勧めします。


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 (プライベート


tcp 9389 リモートの

Microsoft Windows PowerShell (

オプション)



udp 53, 88, 123, 137, 138, 389, 445, 464

認証

(プライマリ)



udp 1812 認証 (MFA)

(オプション)

RADIUS (プライベートデータ

センターまたは EC2)*


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 範囲オプションのカスタムセット例を示してい

ます。

https://technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx

https://support.microsoft.com/en-us/kb/832017

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule


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 にすることをお勧めします。

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html#DHCPOptionSet

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html#DHCPOptionSet


38/55 ページ

Active Directory: サイトとサービス

シナリオ 2 では、サイトとサービスは AD DS の正しい機能の重要なコンポーネ

ントです。サイトトポロジは、同じサイト内のドメインコントローラーや、サイ

トの境界を超えたドメインコントローラーの間で Active Directory レプリケー

ションを制御します。シナリオ 2 では、2 つ以上のサイトが存在します (オンプ

レミスとクラウド内の AWS WorkSpaces)。正しいサイトトポロジを定義するこ

とにより、クライアントアフィニティを確保できます。つまり、クライアント

(この場合は WorkSpaces) に、クライアント側で指定されたローカルドメインコ

ントローラーが使用されます。

図 10: Active Directory サイトとサービス: クライアントアフィニティ

ベストプラクティス: オンプレミスの AD DS と AWS Cloud との間

のサイトリンクについて、最大コストを定義しておきます。図 10

は、サイトに依存しないクライアントアフィニティを確保するため

にサイトリンクに割り当てるコストの例です (コスト 100)。


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 クライアント


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 ディレク

トリの管理」の「多要素認証」を参照してください。

http://freeradius.org/

https://www.duosecurity.com/docs/awsworkspaces

http://docs.aws.amazon.com/workspaces/latest/adminguide/prep_connect.html


http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/using_connect_directory.html#connect_mfa


41/55 ページ

セキュリティ

ここでは、Amazon WorkSpaces サービスの使用時に暗号化でデータを保護する

方法について説明します。伝送中と保管時の暗号化のほか、セキュリティグルー

プを利用して WorkSpaces へのネットワークアクセスを保護する方法を示しま

す。認証に関する追加情報 (MFA サポートに関する情報を含む) については、

「AWS Directory Service」セクションを参照してください。

伝送中の暗号化

Amazon WorkSpaces では暗号を使用することにより、通信の各ステージ (伝送

中) における機密性を保護し、保管時のデータも保護します (暗号化された

WorkSpace)。伝送中に Amazon WorkSpaces で使用される暗号化の各ステージ

のプロセスについては、以下の各セクションで説明します。保管時の暗号化の詳

細については、このホワイトペーパーの「暗号化された WorkSpace」を参照し

てください。

登録と更新

デスクトップクライアントアプリケーションは、登録と更新のために、https を

使用して Amazon と通信します。

認証ステージ

デスクトップクライアントは、認証情報を認証ゲートウェイに送信することで認

証を開始します。デスクトップクライアントと認証ゲートウェイの間の通信に

は、https が使用されます。このステージの終了時に認証に成功していれば、認

証ゲートウェイは同じ https 接続を使用してデスクトップクライアントに OAuth

2.0 トークンを返します。


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 を使用します。


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

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/admin_details.html#admin_eni


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 管理者ガイドの説明に従って、いくつかのポートを開けて

おく必要があります。

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/admin_details.html#admin_eni

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/group_policy.html





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 を検索できます。

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/admin_details.html#member_security_group

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html


46/55 ページ

ENI が見つかったら、そこから直接、セキュリティグループを管理できます。プ

ライマリネットワークインターフェイスにセキュリティグループを手動で割り当

てる場合は、「Amazon WorkSpaces の詳細」に説明されているように、

Amazon WorkSpaces のポート要件を考慮してください。

図 12: セキュリティグループの関連付けの管理

暗号化された WorkSpace

各 WorkSpace には、ルートボリューム (C: ドライブ) とユーザーボリューム (D:

ドライブ) が用意されています。暗号化された WorkSpace の機能を使用すると、

いずれかのボリュームまたは両方のボリュームを暗号化できます。

暗号化の対象

保管時のデータ、ボリュームへのディスク I/O、暗号化されたボリュームから作

成されたスナップショットは、すべて暗号化されます。



47/55 ページ

暗号化のタイミング

WorkSpace の暗号化は、WorkSpace の起動時 (作成時) に指定する必要がありま

す。WorkSpace ボリュームを暗号化できるのは、起動時のみです。起動後は、

ボリュームの暗号化ステータスを変更できません。図 13 は、新しい WorkSpace

の起動時に暗号化を選択するための Amazon WorkSpaces コンソールページを示

しています。

図 13: WorkSpace ボリュームの暗号化

新しい WorkSpace の暗号化の仕組み

暗号化された WorkSpace のオプションは、Amazon WorkSpaces コンソールまた

は AWS CLI から選択することも、新しい WorkSpace の起動時に Amazon

WorkSpaces API を使用して選択することもできます。


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 の概念」を参照してください。

http://docs.aws.amazon.com/kms/latest/developerguide/services-workspaces.html#services-workspaces-overview

http://docs.aws.amazon.com/kms/latest/developerguide/services-workspaces.html#services-workspaces-overview

http://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys

http://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys


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 ア

ラームやサードパーティー製ツールでモニタリングできます。


50/55 ページ

図 14: CloudWatch メトリックス – ConnectionAttempt/ConnectionFailure

デフォルトでは、次のメトリックスが無料で有効になり、使用可能です。

Available: ステータスチェックに応答した WorkSpace は、このメトリッ

クスにカウントされます。

Unhealthy: 同じステータスチェックに応答しない WorkSpace は、このメ

トリックスにカウントされます。

ConnectionAttempt: WorkSpace に対する接続の試行数。

ConnectionSuccess: 接続に成功した試行数。

ConnectionFailure: 接続に成功しなかった試行数。

SessionLaunchTime: セッションの開始にかかった時間 (WorkSpaces

クライアントが計測)。

InSessionLatency: WorkSpaces クライアントと WorkSpace 間のラウン

ドトリップ時間 (クライアントが計測および報告)。

SessionDisconnect: ユーザーが開始して自動的に閉じられたセッション

の数。

これに加え、図 15 に示されているようにアラームを作成することもできます。


51/55 ページ

図 15: WorkSpace 接続エラー用の CloudWatch アラームを作成する


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 テストアプリケーションを実行します。

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/client_troubleshooting.html

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/admin_troubleshooting.html


http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/connect_verification.html


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 リージョンのパフォーマンスチェックも行われ、ユー

ザーにとってどのリージョンが速度面で最も優れているかが示されます。

https://clients.amazonworkspaces.com/Health.html


54/55 ページ

まとめ

各組織がアジャイル性を促進し、データの保護を強化してワーカーの生産性を高

めようと努力する中で、エンドユーザーコンピューティングにおける戦略が変わ

ろうとしています。クラウドコンピューティングで既に実現している利点の多く

が、エンドユーザーコンピューティングにも当てはまります。Amazon

WorkSpaces でエンドユーザーのデスクトップを AWS Cloud に移動すること

で、組織ではワーカーの増加に伴う拡張を迅速に行うことができるようになりま

す。また、オフデバイスでデータを保管することによってセキュリティ体制を強

化し、好みのデバイスを使用してどこからでもアクセスが可能なポータブルデス

クトップをワーカーに提供できます。

Amazon WorkSpaces は、既存の IT システムおよびプロセスに統合できるように

設計されており、このホワイトペーパーではそのためのベストプラクティスにつ

いて説明しています。このホワイトペーパーに記載されているガイドラインに従

うことで、費用効率に優れたクラウドデスクトップのデプロイが可能になり、

AWS のグローバルなインフラストラクチャでビジネスに合わせて拡張すること

ができます。

寄稿者

本書の執筆に当たり、次の方々に寄稿していただきました。

Justin Bradley、ソリューションアーキテクト、アマゾンウェブサービス

Mahdi Sajjadpour、シニアコンサルタント、AWS プロフェッショナルサー

ビス

Mauricio Munoz、ソリューションアーキテクト、アマゾンウェブサービス


55/55 ページ

その他の資料

追加情報については、次の資料を参照してください。

AWS Directory Service の管理の問題のトラブルシューティング

Amazon WorkSpaces の管理の問題のトラブルシューティング

Amazon WorkSpaces クライアントの問題のトラブルシューティング

Amazon WorkSpaces 管理者ガイド

Amazon WorkSpaces 開発者ガイド

サポートされるプラットフォームとデバイス

Amazon WorkSpaces で AWS KMS を使用する方法

AWS CLI コマンドリファレンス – workspaces

Amazon WorkSpaces メトリックスのモニタリング

http://docs.aws.amazon.com/directoryservice/latest/admin-guide/admin_troubleshooting.html

http://docs.aws.amazon.com/workspaces/latest/adminguide/admin_troubleshooting.html

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/client_troubleshooting.html


http://docs.aws.amazon.com/workspaces/latest/devguide/

http://docs.aws.amazon.com/de_de/workspaces/latest/adminguide/client_help.html#client_list

http://docs.aws.amazon.com/kms/latest/developerguide/services-workspaces.html

http://docs.aws.amazon.com/cli/latest/reference/workspaces/index.html

http://docs.aws.amazon.com/workspaces/latest/adminguide/monitoring.html

amazon workspaces をデプロイ するためのベストプラクティス · aws - amazon...

Documents

amazon workspaces をデプロイするためのベストプラクティス · aws - amazon...