Best Practices for Deploying Amazon WorkSpaces

Transcription

1 Amazon WorkSpaces をデプロイ するためのベストプラクティス ネットワークアクセス ディレクトリサービス セキュリティ

2 2016, Amazon Web Services, Inc. or its affiliates. All rights reserved. 注意 本書は情報提供のみを目的としています 本書の発行時点における AWS の現行製品と慣行を表したものであり それらは予告なく変更されることがあります お客様は本書の情報 および AWS 製品またはサービスの利用について 独自の評価に基づき判断する責任を負います いずれの AWS 製品またはサービスも 明示または黙示を問わずいかなる保証も伴うことなく 現状のまま 提供されます 本書のいかなる内容も AWS その関係者 サプライヤ またはライセンサーからの保証 表明 契約的責任 条件や確約を意味するものではありません お客様に対する AWS の責任は AWS 契約により規定されます 本書は AWS とお客様の間で行われるいかなる契約の一部でもなく そのような契約の内容を変更するものでもありません 2/55 ページ

3 目次 要約 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 3/55 ページ

4 要約 このホワイトペーパーでは Amazon WorkSpaces のデプロイに関するベストプ ラクティスの概要を示し ネットワークの考慮事項 ディレクトリサービス ユーザー認証 セキュリティ モニタリング ログ記録について説明します ドキュメントの内容は 必要な情報に早くアクセスできるように 4 つのカテゴ リに分かれています 読者として ネットワークエンジニア ディレクトリエン ジニア セキュリティエンジニアを対象としています はじめに Amazon WorkSpaces は クラウドで提供されるマネージド型のデスクトップコンピューティングサービスです Amazon WorkSpaces を使用すると ハードウェアの購入やデプロイ 複雑なソフトウェアのインストールなどの負担を軽減し AWS マネジメントコンソールでの数クリックの操作 AWS コマンドラインインターフェイス (CLI) または API によってデスクトップエクスペリエンスを提供することができます Amazon WorkSpaces では デスクトップを数分で起動して オンプレミスまたは外部ネットワークのデスクトップソフトウェアに すばやく安全かつ確実に接続およびアクセスできます 次のことを行うことができます AWS Directory Service: AD Connector を使用して オンプレミスの既存 Microsoft Active Directory (AD) を活用する ディレクトリを AWS Cloud に拡張する 4/55 ページ

5 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 の詳細を示し サービスの仕組 みとサービスの開始方法を説明します また 使用できるオプションと機能につ いても説明します 5/55 ページ

6 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 つ以上必要になります 6/55 ページ

7 ネットワークに関する考慮事項 各 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 に適用するセキュリティグ 7/55 ページ

8 ループを使用して 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 間で分割して使用することができます 8/55 ページ

9 サブネットのサイズ 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 に移行している方法 を参照してください 9/55 ページ

10 ネットワークインターフェイス 各 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 制限の値を引き上げる必要があります 10/55 ページ

11 トラフィックフロー 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 暗号化が利用されます 詳細については このドキュメントの セキュリティ セクションを参照してください 11/55 ページ

12 PCoIP ストリーミングゲートウェイとネットワークヘルスチェックのエンドポイントについては リージョンごとの IP 範囲が公開されています ポート 4172 でのアウトバウンドトラフィックは 社内ネットワークから AWS ストリーミングネットワークゲートウェイとネットワークヘルスチェックのエンドポイントに限定できます これには Amazon WorkSpaces を使用している特定の AWS リージョンに対するポート 4172 のアウトバウンドトラフィックのみを許可します IP 範囲とネットワークヘルスチェックのエンドポイントについては Amazon WorkSpaces の PCoIP ゲートウェイ IP 範囲を参照してください Amazon WorkSpaces クライアントには ネットワークステータスチェックの機能が組み込まれています このユーティリティでは アプリケーションの右下にあるステータスインジケータによって ユーザーのネットワークで接続がサポートされているかどうかが示されます ネットワークステータスに関するさらに詳しいビューにアクセスするには クライアントの右下で [Network] を選択します その結果を図 1 に示します 図 1: WorkSpaces クライアント ネットワークチェック 12/55 ページ

13 ユーザーは 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 13/55 ページ

14 への接続に失敗した場合は 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 に接続したすべてのネットワークにアクセスできます 14/55 ページ

15 ネットワークリソースへの 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 内およびオンプレミスネットワークに対する制限付きネットワークアクセスが許可されます 15/55 ページ

16 正社員には ソフトウェアをインストールできるように 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 アドレスを使用します このシナリオでは さらに次の点についても考慮が必要です 16/55 ページ

17 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 の設定を示します 17/55 ページ

18 図 2: VPC 設計の概要 前に示した 2 つの異なる種類の WorkSpace を設定する方法を次に示します 正社員用 : Amazon WorkSpaces マネジメントコンソールで メニューバーの [Directories] オプションを選択し 正社員をホストするディレクトリを選択して [Local Administrator Setting] を選択します このオプションを有効にすることにより 新しく作成したすべての WorkSpace に ローカル管理者権限が付与されます インターネットアクセスを許可するには VPC からのアウトバウンドインターネットアクセス用に NAT (Network Address Translation) を設定する必要があります MFA を有効にするには RADIUS サーバー サーバー IP ポート および事前共有キーを指定する必要があります 18/55 ページ

19 正社員の 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 設計を示します 19/55 ページ

20 図 3: WorkSpace の設計とユーザーペルソナ 20/55 ページ

21 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) との統合を含む ) について説明します 21/55 ページ

22 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 を通じて必要な箇所にアプリケーショントラフィックのプロビジョニングを行います 22/55 ページ

23 シナリオ 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) 認証プロセスに使用されるプロトコルまたは暗号化の詳細については このホワイトペーパーの セキュリティ セクションを参照してください 23/55 ページ

24 図 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 接続を通じて 独自のネットワークとの通信を可能にしま す 24/55 ページ

25 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) の適用など ) の所要時間が長くなります 25/55 ページ

26 トラフィックコスト : すべての認証は 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 は 各コンポーネントの概要とユーザー認証フローを示しています 26/55 ページ

27 図 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 でセキュリティ保護されます 27/55 ページ

28 このアーキテクチャでは 次のコンポーネントまたは構造が使用されます アマゾンウェブサービス : 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 に関する記述を参照してください ) 28/55 ページ

29 お客様 : ネットワーク接続 : 会社の 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 レプリケーションのみ であるため データ転送が少なくなります 29/55 ページ

30 一般的に 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) 30/55 ページ

31 シナリオ 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 オプションセット を参照 してください 31/55 ページ

32 オプション : 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 に対するインターネットアクセスが有効になっている場合を除く ) このシナリオは 分離型またはクラウドのみのシナリオとして設計されているためです 32/55 ページ

33 設計上の考慮事項 十分に機能する 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 にあるものと想定しています 33/55 ページ

34 図 8: AD DS ネットワーク分離 図 9 は シナリオ 1 と似た設計を示していますが このシナリオでは オンプレ ミス部分が専用の Amazon VPC に配置されています 図 9: 専用の WorkSpaces VPC 注意 : 既存の AWS デプロイメントで AD DS を使用している場合 は WorkSpaces を専用の VPC に配置し AD DS の通信用に VPC ピア接続を使用することをお勧めします 34/55 ページ

35 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 RPC ハイポート Active Directory ( プライベート データセンターまたは EC2)** tcp 信頼 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)* 35/55 ページ

36 * 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 範囲オプションのカスタムセット例を示しています 36/55 ページ

37 パラメーター 値 キーに name value に特定の文字列を指定し 名前タグ て タグを作成します 例 : exampleco.com ドメイン名 exampleco.com カンマで区切った DNS サーバーの IP アドレ ドメインネームサーバー ス 例 : NTP サーバー このフィールドは空白にしておきます ドメインネームサーバーと同様に コンマで区 NetBIOS ネームサーバー 切った IP を入力します 例 : 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 にすることをお勧めします 37/55 ページ

38 Active Directory: サイトとサービス シナリオ 2 では サイトとサービスは AD DS の正しい機能の重要なコンポーネントです サイトトポロジは 同じサイト内のドメインコントローラーや サイトの境界を超えたドメインコントローラーの間で Active Directory レプリケーションを制御します シナリオ 2 では 2 つ以上のサイトが存在します ( オンプレミスとクラウド内の AWS WorkSpaces) 正しいサイトトポロジを定義することにより クライアントアフィニティを確保できます つまり クライアント ( この場合は WorkSpaces) に クライアント側で指定されたローカルドメインコントローラーが使用されます 図 10: Active Directory サイトとサービス : クライアントアフィニティ ベストプラクティス : オンプレミスの AD DS と AWS Cloud との間のサイトリンクについて 最大コストを定義しておきます 図 10 は サイトに依存しないクライアントアフィニティを確保するためにサイトリンクに割り当てるコストの例です ( コスト 100) 38/55 ページ

39 このような関連付けにより 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 クライアント 39/55 ページ

40 ハードルール : 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 ディレクトリの管理 の 多要素認証 を参照してください 40/55 ページ

41 セキュリティ ここでは Amazon WorkSpaces サービスの使用時に暗号化でデータを保護する方法について説明します 伝送中と保管時の暗号化のほか セキュリティグループを利用して WorkSpaces へのネットワークアクセスを保護する方法を示します 認証に関する追加情報 (MFA サポートに関する情報を含む ) については AWS Directory Service セクションを参照してください 伝送中の暗号化 Amazon WorkSpaces では暗号を使用することにより 通信の各ステージ ( 伝送中 ) における機密性を保護し 保管時のデータも保護します ( 暗号化された WorkSpace) 伝送中に Amazon WorkSpaces で使用される暗号化の各ステージのプロセスについては 以下の各セクションで説明します 保管時の暗号化の詳細については このホワイトペーパーの 暗号化された WorkSpace を参照してください 登録と更新 デスクトップクライアントアプリケーションは 登録と更新のために https を 使用して Amazon と通信します 認証ステージ デスクトップクライアントは 認証情報を認証ゲートウェイに送信することで認証を開始します デスクトップクライアントと認証ゲートウェイの間の通信には https が使用されます このステージの終了時に認証に成功していれば 認証ゲートウェイは同じ https 接続を使用してデスクトップクライアントに OAuth 2.0 トークンを返します 41/55 ページ

42 注意 : デスクトップクライアントアプリケーションでは 更新 登 録 認証用のポート 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 用に ) PFS を使用します 42/55 ページ

43 ブローカーステージ ( 認証に成功した場合に認証ゲートウェイから ) 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 が使用されます (Amazon Workspaces に関するドキュメント Amazon 43/55 ページ

44 WorkSpaces の詳細 を参照してください 初期アウトバウンド UDP ポートは です ) ポート 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 管理者ガイドの説明に従って いくつかのポートを開けておく必要があります 44/55 ページ

45 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 を検索できます 45/55 ページ

46 ENI が見つかったら そこから直接 セキュリティグループを管理できます プライマリネットワークインターフェイスにセキュリティグループを手動で割り当てる場合は Amazon WorkSpaces の詳細 に説明されているように Amazon WorkSpaces のポート要件を考慮してください 図 12: セキュリティグループの関連付けの管理 暗号化された WorkSpace 各 WorkSpace には ルートボリューム (C: ドライブ ) とユーザーボリューム (D: ドライブ ) が用意されています 暗号化された WorkSpace の機能を使用すると いずれかのボリュームまたは両方のボリュームを暗号化できます 暗号化の対象 保管時のデータ ボリュームへのディスク I/O 暗号化されたボリュームから作 成されたスナップショットは すべて暗号化されます 46/55 ページ

47 暗号化のタイミング WorkSpace の暗号化は WorkSpace の起動時 ( 作成時 ) に指定する必要があります WorkSpace ボリュームを暗号化できるのは 起動時のみです 起動後は ボリュームの暗号化ステータスを変更できません 図 13 は 新しい WorkSpace の起動時に暗号化を選択するための Amazon WorkSpaces コンソールページを示しています 図 13: WorkSpace ボリュームの暗号化 新しい WorkSpace の暗号化の仕組み 暗号化された WorkSpace のオプションは Amazon WorkSpaces コンソールまたは AWS CLI から選択することも 新しい WorkSpace の起動時に Amazon WorkSpaces API を使用して選択することもできます 47/55 ページ

48 ボリュームを暗号化するために 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 の概念 を参照してください 48/55 ページ

49 Amazon CloudWatch の使用によるモニタ リングまたはログ記録 モニタリングは ネットワーク サーバー ログなど どのようなインフラストラクチャにおいても不可欠な部分です Amazon WorkSpaces をデプロイするお客様は 全体的な状態や 個々の WorkSpace の接続ステータスなどについて デプロイメントをモニタリングする必要があります WorkSpace に関する Amazon CloudWatch メトリックス WorkSpace に関する Amazon CloudWatch メトリックスは 全体的な状態や個々の WorkSpace の接続ステータスなどの情報を管理者が詳しく確認できるように設計されています メトリックスは WorkSpace 単位で利用でき 組織のすべての WorkSpace について 指定のディレクトリ内で集計されます (AD Connector の ID を参照してください ) メトリックス ( すべての CloudWatch メトリックスなど ) は AWS マネジメント コンソール ( 図 13) で確認し CloudWatch API でアクセスして CloudWatch ア ラームやサードパーティー製ツールでモニタリングできます 49/55 ページ

50 図 14: CloudWatch メトリックス ConnectionAttempt/ConnectionFailure デフォルトでは 次のメトリックスが無料で有効になり 使用可能です Available: ステータスチェックに応答した WorkSpace は このメトリッ クスにカウントされます Unhealthy: 同じステータスチェックに応答しない WorkSpace は このメ トリックスにカウントされます ConnectionAttempt: WorkSpace に対する接続の試行数 ConnectionSuccess: 接続に成功した試行数 ConnectionFailure: 接続に成功しなかった試行数 SessionLaunchTime: セッションの開始にかかった時間 (WorkSpaces クライアントが計測 ) InSessionLatency: WorkSpaces クライアントと WorkSpace 間のラウン ドトリップ時間 ( クライアントが計測および報告 ) SessionDisconnect: ユーザーが開始して自動的に閉じられたセッション の数 これに加え 図 15 に示されているようにアラームを作成することもできます 50/55 ページ

51 図 15: WorkSpace 接続エラー用の CloudWatch アラームを作成する 51/55 ページ

52 トラブルシューティング "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 テストアプリケーションを実行します 52/55 ページ

53 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 リージョンのパフォーマンスチェックも行われ ユーザーにとってどのリージョンが速度面で最も優れているかが示されます 53/55 ページ

54 まとめ 各組織がアジャイル性を促進し データの保護を強化してワーカーの生産性を高めようと努力する中で エンドユーザーコンピューティングにおける戦略が変わろうとしています クラウドコンピューティングで既に実現している利点の多くが エンドユーザーコンピューティングにも当てはまります Amazon WorkSpaces でエンドユーザーのデスクトップを AWS Cloud に移動することで 組織ではワーカーの増加に伴う拡張を迅速に行うことができるようになります また オフデバイスでデータを保管することによってセキュリティ体制を強化し 好みのデバイスを使用してどこからでもアクセスが可能なポータブルデスクトップをワーカーに提供できます Amazon WorkSpaces は 既存の IT システムおよびプロセスに統合できるように設計されており このホワイトペーパーではそのためのベストプラクティスについて説明しています このホワイトペーパーに記載されているガイドラインに従うことで 費用効率に優れたクラウドデスクトップのデプロイが可能になり AWS のグローバルなインフラストラクチャでビジネスに合わせて拡張することができます 寄稿者 本書の執筆に当たり 次の方々に寄稿していただきました Justin Bradley ソリューションアーキテクト アマゾンウェブサービス Mahdi Sajjadpour シニアコンサルタント AWS プロフェッショナルサービス Mauricio Munoz ソリューションアーキテクト アマゾンウェブサービス 54/55 ページ

55 その他の資料 追加情報については 次の資料を参照してください AWS Directory Service の管理の問題のトラブルシューティング Amazon WorkSpaces の管理の問題のトラブルシューティング Amazon WorkSpaces クライアントの問題のトラブルシューティング Amazon WorkSpaces 管理者ガイド Amazon WorkSpaces 開発者ガイドサポートされるプラットフォームとデバイス Amazon WorkSpaces で AWS KMS を使用する方法 AWS CLI コマンドリファレンス workspaces Amazon WorkSpaces メトリックスのモニタリング 55/55 ページ