セキュリティ - デプロイのベストプラクティス WorkSpaces
転送中の暗号化ネットワークインターフェイスWorkSpaces セキュリティグループネットワークアクセスコントロールリスト (ACL)AWS Network Firewall暗号化済み WorkSpacesアクセスコントロールオプションと信頼できるデバイスIP アクセスコントロールグループAmazon を使用したモニタリングまたはログ記録 CloudWatch

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

セキュリティ

このセクションでは、Amazon WorkSpaces のサービスを使用する際に暗号化を使用してデータを保護する方法について説明します。転送時と保管時の暗号化、および へのネットワークアクセスを保護するためのセキュリティグループの使用について説明します WorkSpaces。このセクションでは、信頼できるデバイスと IP アクセスコントロールグループ WorkSpaces を使用して、 へのエンドデバイスアクセスを制御する方法についても説明します。

AWS Directory Service での認証 (MFA サポートを含む) に関する追加情報は、このセクションに記載されています。

送信中の暗号化

Amazon WorkSpaces は、暗号化を使用して、通信のさまざまな段階 (転送中) の機密性を保護し、保管中のデータ (暗号化された ) も保護します WorkSpaces。Amazon が転送 WorkSpaces 中に使用する暗号化の各段階のプロセスについては、以下のセクションで説明します。

保管時の暗号化の詳細については、このドキュメントの「暗号化 WorkSpaces」セクションを参照してください。

登録と更新

デスクトップクライアントアプリケーションは、HTTPS を使用した更新と登録について Amazon と通信します。

認証ステージ

デスクトップクライアントは、認証ゲートウェイに認証情報を送信することで認証を開始します。デスクトップクライアントと認証ゲートウェイ間の通信には HTTPS が使用されます。この段階の最後に、認証が成功すると、認証ゲートウェイは同じ HTTPS 接続を介して OAuth 2.0 トークンをデスクトップクライアントに返します。

注記

デスクトップクライアントアプリケーションは、ポート 443 (HTTPS) トラフィック、更新、登録、認証用のプロキシサーバーの使用をサポートします。

クライアントから認証情報を受け取ると、認証ゲートウェイは認証リクエストを AWS Directory Service に送信します。認証ゲートウェイから AWS Directory Service への通信は HTTPS 経由で行われるため、ユーザー認証情報はプレーンテキストで送信されません。

認証 — Active Directory Connector (TAK)

AD Connector は Kerberos を使用してオンプレミス AD との認証済み通信を確立するため、LDAP にバインドして後続の LDAP クエリを実行できます。TAK でのクライアント側の LDAPS サポートは、Microsoft AD と AWS アプリケーション間のクエリを暗号化するためにも利用できます。クライアント側 LDAPS 機能を実装する前に、クライアント側 LDAPS の前提条件を確認してください。

AWS Directory Service は、TLS を使用した LDAP もサポートしています。ユーザーの認証情報は、プレーンテキストで送信されることはありません。セキュリティを強化するために、VPN 接続を使用して WorkSpaces VPC をオンプレミスネットワーク (AD が存在する場所) に接続できます。 AWS ハードウェア VPN 接続を使用する場合、お客様は AES-128 または AES-256 対称暗号化キー SAs 、整合性ハッシュ用の SHA-1 または SHA-256 対称暗号化キー、フェーズ 1 用の SHA-14-18、22、23、24、フェーズ 1、25、14-18、22、23、24 を使用して、転送中の暗号化を設定できます (PFS)。 AES-256

ブローカーステージ

OAuth 2.0 トークンを (認証ゲートウェイから、認証が成功した場合) 受信した後、デスクトップクライアントは HTTPS を使用して Amazon WorkSpaces サービス (Broker Connection Manager) にクエリを実行します。デスクトップクライアントは OAuth 2.0 トークンを送信することで自身を認証し、その結果、クライアントは WorkSpaces ストリーミングゲートウェイのエンドポイント情報を受け取ります。

ストリーミングステージ

デスクトップクライアントは、ストリーミングゲートウェイで PCoIP セッションを開くように (OAuth 2.0 トークンを使用) 要求します。このセッションは AES-256 で暗号化されており、通信制御 (4172/TCP) に PCoIP ポートを使用します。

OAuth2.0 トークンを使用して、ストリーミングゲートウェイは HTTPS 経由で Amazon WorkSpaces サービスにユーザー固有の WorkSpaces 情報をリクエストします。

ストリーミングゲートウェイは、クライアントから TGT (クライアントユーザーのパスワードを使用して暗号化されます) を受け取り、Kerberos TGT パススルーを使用して、ゲートウェイは、ユーザーが取得した Kerberos TGT を使用して WorkSpaceで Windows ログインを開始します。

WorkSpace 次に、 は、標準の Kerberos 認証を使用して、設定された AWS Directory Service への認証リクエストを開始します。

WorkSpace が正常にログインすると、PCoIP ストリーミングが開始されます。接続は、ポート UDP 4172 のリターントラフィックを使用して、ポート TCP 4172 でクライアントによって開始されます。さらに、管理インターフェイスを介したストリーミングゲートウェイと WorkSpaces デスクトップ間の初期接続は UDP 55002 経由です。（Amazon の IP アドレスとポートの要件 WorkSpacesに関するドキュメントを参照してください。 最初のアウトバウンド UDP ポートは 55002 です）。ポート 4172 (TCP および UDP) を使用するストリーミング接続は、AES 128 および 256 ビット暗号を使用して暗号化されますが、デフォルトは 128 ビットです。お客様は、Windows 用の PCoIP 固有の AD グループポリシー設定を使用するか、Amazon Linux 用の pcoip-agent.conf ファイルを使用して WorkSpaces、これを 256 ビットにアクティブに変更できます WorkSpaces。Amazon のグループポリシー管理の詳細については WorkSpaces、「」のドキュメントを参照してください。

ネットワークインターフェイス

各 Amazon WorkSpace には、プライマリネットワークインターフェイス と管理ネットワークインターフェイス と呼ばれる 2 つのネットワークインターフェイスがあります。

プライマリネットワークインターフェイスは、 AWS Directory Service、インターネット、カスタマー企業ネットワークへのアクセスなど、カスタマー VPC 内のリソースへの接続を提供します。このプライマリネットワークインターフェイスにセキュリティグループをアタッチできます。概念的には、セキュリティグループは、deployment: WorkSpaces security group と ENI security groups の範囲に基づいて、この ENI にアタッチされます。

管理ネットワークインターフェイス

管理ネットワークインターフェイスは、セキュリティグループでは制御できません。ただし、 でホストベースのファイアウォールを使用して、ポート WorkSpaces をブロックしたり、アクセスを制御できます。管理ネットワークインターフェイスに制限を適用することはお勧めしません。お客様がホストベースのファイアウォールルールを追加してこのインターフェイスを管理する場合は、Amazon WorkSpaces サービスが のヘルスとアクセシビリティを管理できるように、いくつかのポートを開く必要があります WorkSpace。詳細については、「Amazon Workspaces 管理ガイド」の「ネットワークインターフェイス」を参照してください。

WorkSpaces セキュリティグループ

デフォルトのセキュリティグループは AWS Directory Service ごとに作成され、その特定のディレクトリ WorkSpaces に属するすべての に自動的にアタッチされます。

Amazon は WorkSpaces、他の多くの AWS サービスと同様に、セキュリティグループを利用します。Amazon WorkSpaces は、ディレクトリを WorkSpaces サービスに登録するときに 2 つの AWS セキュリティグループを作成します。ディレクトリコントローラー directoryId _controllers 用の 1 つと、 directory directoryId _workspacesMembers WorkSpaces 内の 用の 1 つです。 directoryId workspacesMembers これらのセキュリティグループを削除しないでください。削除すると、 に障害 WorkSpaces が発生します。デフォルトでは、 WorkSpaces メンバーセキュリティグループの出力は 0.0.0.0/0 に開かれています。デフォルトの WorkSpacesセキュリティグループをディレクトリに追加できます。新しいセキュリティグループを WorkSpaces ディレクトリに関連付けると、起動 WorkSpaces した新しい または再構築 WorkSpaces した既存の に新しいセキュリティグループが追加されます。この新しいデフォルトのセキュリティグループを再構築 WorkSpaces せずに既存の に追加することもできます。複数のセキュリティグループを WorkSpaces ディレクトリに関連付ける場合は、 WorkSpaces各セキュリティグループのルールを 1 つのルールセットに集約します。セキュリティグループルールをできるだけ凝縮することをお勧めします。セキュリティグループの詳細については、「Amazon VPC ユーザーガイド」の「VPC のセキュリティグループ」を参照してください。

WorkSpaces ディレクトリまたは既存の にセキュリティグループを追加する方法の詳細については WorkSpace、WorkSpaces 「管理者ガイド」を参照してください。

一部のお客様は、 WorkSpaces トラフィックが出力できるポートと送信先を制限したいと考えています。からの出力トラフィックを制限するには WorkSpaces、サービス通信に必要な特定のポートを残す必要があります。そうしないと、ユーザーは にログインできません WorkSpaces。

WorkSpaces は、 WorkSpace ログイン中にドメインコントローラーとの通信のために、カスタマー VPC の Elastic Network Interface (ENI) を利用します。ユーザーが に WorkSpaces 正常にログインできるようにするには、ドメインコントローラーまたは _workspacesMembers セキュリティグループにドメインコントローラーを含む CIDR 範囲へのアクセスを次のポートに許可する必要があります。

  • TCP/UDP 53 - DNS

  • TCP/UDP 88 - Kerberos 認証

  • TCP/UDP 389 – LDAP

  • TCP/UDP 445 – SMB

  • TCP 3268-3269 – グローバルカタログ

  • TCP/UDP 464 - Kerberos パスワードの変更

  • TCP 139 - Netlogon

  • UDP 137-138 - Netlogon

  • UDP 123 – NTP

  • RPC の TCP/UDP 49152-65535 一時ポート

他のアプリケーション、インターネット、またはその他の場所にアクセス WorkSpaces する必要がある場合は、_workspacesMembers セキュリティグループ内の CIDR 表記でそれらのポートと宛先を許可する必要があります。これらのポートと送信先を追加しない場合、 WorkSpaces は上記のポート以外には到達しません。最後の考慮事項の 1 つは、デフォルトでは、新しいセキュリティグループにはインバウンドルールがありません。したがって、インバウンドルールをセキュリティグループに追加するまで、別のホストからインスタンスに送信されるインバウンドトラフィックは許可されません。上記の手順は、 からの WorkSpaces出力を制限する場合、またはそれらにアクセスする必要があるリソースまたは CIDR 範囲のみに進入ルールをロックする場合にのみ必要です。

注記

新しく関連付けられたセキュリティグループは、変更後に WorkSpaces 作成または再構築された場合にのみアタッチされます。

ENI セキュリティグループ

プライマリネットワークインターフェイスは通常の ENI であるため、さまざまな AWS 管理ツールを使用して管理できます。詳細については、「Elastic Network Interface」を参照してください。 WorkSpace IP アドレス (Amazon WorkSpaces コンソールの WorkSpaces ページ内) に移動し、その IP アドレスをフィルターとして使用して、対応する ENI (Amazon EC2 コンソールのネットワークインターフェイスセクション内) を見つけます。

ENI が見つかったら、セキュリティグループによって直接管理できます。セキュリティグループをプライマリネットワークインターフェイスに手動で割り当てる場合は、Amazon のポート要件を考慮してください WorkSpaces。詳細については、「Amazon Workspaces 管理ガイド」の「ネットワークインターフェイス」を参照してください。

MFA が有効になっている WorkSpaces クライアントを示すスクリーンショット

図 21: MFA が有効になっている WorkSpaces クライアント

ネットワークアクセスコントロールリスト (ACL)

ネットワーク ACLs は、さらに別のファイアウォールの管理が複雑になるため、非常に複雑なデプロイでは一般的に使用され、ベストプラクティスとしては通常使用されません。ネットワーク ACLs が VPC 内のサブネットにアタッチされると、OSI モデルのレイヤー 3 (ネットワーク) でその機能に焦点を当てます。Amazon WorkSpaces は Directory Services で設計されているため、2 つのサブネットを定義する必要があります。ネットワーク ACLs は Directory Services とは別に管理され、ネットワーク ACL は が割り当て WorkSpacesたサブネットの 1 つだけに割り当てられる可能性があります。

ステートレスファイアウォールが必要な場合、ネットワーク ACLs はセキュリティのベストプラクティスです。ベストプラクティスとして、デフォルト設定を超えてネットワーク ACLs に加えられた変更は、サブネットごとに検証されていることを確認してください。ネットワーク ACLs が意図したとおりに動作しない場合は、VPC フローログを使用してトラフィックを分析することを検討してください。

AWS Network Firewall

AWS Network Firewall には、ネイティブセキュリティグループとネットワーク ACLs が提供する機能以外にも、コストがかかります。HTTPS ベースのウェブサイトのサーバー名検査 (SNI)、侵入検知と防止、ドメイン名の許可リストと拒否リストなど、ネットワーク接続に関するセキュリティを強化する権限をお客様に求めると、お客様は で代替ファイアウォールを見つけることが許可されていました AWS Marketplace。これらのファイアウォールのデプロイは複雑であるため、標準の EUC 管理者が慣れている範囲を超える課題が発生していました。 AWS Network Firewall は、レイヤー 3 から 7 の保護を有効にしながら、ネイティブな AWS エクスペリエンスを提供します。NAT ゲートウェイと組み合わせて AWS Network Firewall を使用することは、組織がすべての EUC ネットワーク保護をカバーするために、他の手段 (クラウドまたはファイアウォールを除外した別のチームに転送できるサードパーティーのファイアウォールの既存のオンプレミスライセンス) を所有していない場合のベストプラクティスです。NAT ゲートウェイは AWS Network Firewall でも無料です。

AWS Network Firewall のデプロイは、既存の EUC 設計を中心に設計されています。単一の VPC 設計では、ファイアウォールエンドポイント用のサブネットと個別のインターネット出力ルーティングに関する考慮事項を備えた簡素化されたアーキテクチャを実現できますが、マルチ VPC 設計では、ファイアウォールと Transit Gateways エンドポイントを備えた統合インスペクション VPC の利点を享受できます。

設計シナリオ

シナリオ 1: 基本的なインスタンスのロックダウン

セキュリティ WorkSpaces グループはデフォルトで拒否され、ステートフルであるため、デフォルトのセキュリティグループはインバウンドトラフィックを許可しません。つまり、 WorkSpaces インスタンス自体をさらに保護するために設定する必要がある追加の設定はありません。すべてのトラフィックを許可するアウトバウンドルールと、それがユースケースに適合するかどうかを検討します。例えば、ポート 443 へのすべてのアウトバウンドトラフィックを任意のアドレスに拒否するのが最善です。また、LDAP の場合は 389、LDAPS の場合は 636、SMB の場合は 445 など、ポートのユースケースに適合する特定の IP 範囲を拒否することをお勧めします。ただし、環境の複雑さには複数のルールが必要になる場合があるため、ネットワーク ACLs またはファイアウォールアプライアンスを介してより適切に対応できます。

シナリオ 2: インバウンド例外

一定の要件ではありませんが、ネットワークトラフィックが へのインバウンドで開始されることがあります WorkSpaces。例えば、 WorkSpaces クライアントが接続できないときにインスタンスをトリアージするには、代替のリモート接続が必要です。このような場合は、 WorkSpaceのカスタマー ENI のセキュリティグループへのインバウンド TCP 3389 を一時的に有効にするのが最善です。

もう 1 つのシナリオは、一元化されたインスタンスによって開始されるインベントリまたは自動化関数のコマンドを実行する組織スクリプトです。インバウンドの特定の集中型インスタンスからそのポート上のトラフィックを保護することは永続的に設定できますが、 AWS アカウントの複数のデプロイに適用できるため、ディレクトリ設定にアタッチされた追加のセキュリティグループでこれを行うのがベストプラクティスです。

最後に、ステートフルベースではないネットワークトラフィックがあり、受信例外でエフェメラルポートを指定する必要があります。クエリとスクリプトが失敗する場合は、接続障害の根本原因を判断しながら、少なくとも一時的に一時ポートを許可するのがベストプラクティスです。

シナリオ 3: 単一 VPC 検査

のデプロイを簡素化 WorkSpaces する (スケーリングプランのない単一の VPC など) には、検査用に個別の VPC を必要としないため、他の VPCs への接続は VPC ピアリングを使用して簡素化できます。ただし、ファイアウォールエンドポイントの個別のサブネットは、それらのエンドポイントに設定されたルーティングと、Internet Gateway (IGW) のエグレスルーティングを使用して作成する必要があります。そうしないと、設定する必要はありません。すべてのサブネットが VPC CIDR ブロック全体を利用する場合、既存のデプロイには使用可能な IP スペースがない可能性があります。このような場合、デプロイが初期設計を超えてすでにスケールされているため、シナリオ 4 の方が適している可能性があります。

シナリオ 4: 一元化された検査

多くの場合、 AWS リージョンの複数の EUC デプロイで優先され、 AWS Network Firewall のステートフルルールとステートレスルールの管理を簡素化します。この設計では Transit Gateway アタッチメントと、それらのアタッチメントを介してのみ設定できる検査ルーティングを使用する必要があるため、既存の VPC ピアは Transit Gateway に置き換えられます。この設定にもより高度な制御が行われ、デフォルトの WorkSpaces エクスペリエンスを超えるセキュリティが可能になります。

Transit Gateway アタッチメントを使用するサンプルアーキテクチャ。

図 22: Transit Gateway アタッチメントを使用したサンプルアーキテクチャ

暗号化済み WorkSpaces

各 Amazon WorkSpace は、ルートボリューム (Windows 用ドライブ、Amazon Linux 用ルート WorkSpaces) WorkSpacesとユーザーボリューム (Windows 用ドライブ WorkSpaces、Amazon Linux 用ホーム) でプロビジョニングされます WorkSpaces。暗号化 WorkSpaces された機能により、一方または両方のボリュームを暗号化できます。

暗号化されるもの

保管時に保存されるデータ、ボリュームへのディスク入出力 (I/O)、および暗号化されたボリュームから作成されたスナップショットはすべて暗号化されます。

暗号化はいつ行われますか？

の暗号化は、. WorkSpaces volumes を起動時にのみ暗号化できる (作成) ときに指定 WorkSpace する必要があります WorkSpace。起動後にボリュームの暗号化ステータスを変更することはできません。次の図は、新しい の起動中に暗号化を選択するための Amazon WorkSpaces コンソールページを示しています WorkSpace。

WorkSpaces コンソールのスクリーンショットとルートボリュームの暗号化方法

図 23: WorkSpace ルートボリュームの暗号化

新しい はどのように WorkSpace 暗号化されますか？

お客様は、Amazon WorkSpaces コンソールまたは から AWS CLI、またはお客様が新しい を起動するときに Amazon WorkSpaces API を使用して、暗号化 WorkSpaces オプションを選択できます WorkSpace。

ボリュームを暗号化するために、Amazon は AWS Key Management Service () の CMK WorkSpaces を使用しますAWS KMS。デフォルトの AWS KMS CMK は、 WorkSpace がリージョンで初めて起動されたときに作成されます。(CMKsにはリージョンスコープがあります）。

お客様は、暗号化された で使用するカスタマー管理の CMK を作成することもできます WorkSpaces。CMK は、Amazon WorkSpaces サービスが各 WorkSpace ボリュームの暗号化に使用するデータキーを暗号化するために使用されます。（厳密な意味では、ボリュームを暗号化するのは Amazon EBS です）。現在の CMK の制限については、AWS KMS 「リソースクォータ」を参照してください。

注記

暗号化された からのカスタムイメージの作成 WorkSpace はサポートされていません。また、 WorkSpacesルートボリュームの暗号化を有効にして起動すると、プロビジョニングに最大 1 時間かかる場合があります。

WorkSpaces 暗号化プロセスの詳細については、「Amazon が WorkSpaces を使用する AWS KMS方法」を参照してください。暗号化された のリクエストが正しく処理されていることを確認するために、CMK WorkSpace の使用をモニタリングする方法を検討してください。 AWS KMS キーとデータキーの詳細については、AWS KMS 「」ページを参照してください。

アクセスコントロールオプションと信頼できるデバイス

Amazon WorkSpaces では、どのクライアントデバイスが にアクセスできるかを管理するためのオプションをお客様に提供しています WorkSpaces。お客様は、信頼されたデバイス WorkSpaces へのアクセスのみを制限できます。デジタル証明書を使用して、macOS および Microsoft Windows PCsから へのアクセスを許可 WorkSpaces できます。また、iOS、Android、Chrome OS、Linux、ゼロクライアント、および WorkSpaces Web Access クライアントへのアクセスを許可またはブロックすることもできます。これらの機能により、セキュリティ体制をさらに改善できます。

アクセスコントロールオプションは、ユーザーが Windows、MacOS、iOS、Android、ChromeOS、およびゼロクライアント上のクライアント WorkSpaces から にアクセスするための新しいデプロイで有効になります。Web Access または Linux WorkSpaces クライアントを使用したアクセスは、新しい WorkSpaces デプロイではデフォルトで有効になっていないため、有効にする必要があります。

信頼されたデバイス (マネージドデバイスとも呼ばれます) からの企業データアクセスに制限がある場合は、有効な証明書を持つ信頼されたデバイスへのアクセスを制限 WorkSpaces できます。この機能を有効にすると、Amazon は証明書ベースの認証 WorkSpaces を使用して、デバイスが信頼されているかどうかを判断します。 WorkSpaces クライアントアプリケーションは、デバイスが信頼されていることを確認できない場合、デバイスへのログインまたは再接続をブロックします。

信頼できるデバイスのサポートは、次のクライアントで利用できます。

  • WorkSpaces Windows デバイスで実行されている Amazon Windows クライアントアプリ

にアクセスできるデバイスの制御の詳細については WorkSpaces、「信頼できるデバイス WorkSpaces へのアクセスの制限」を参照してください。

注記

信頼されたデバイスの証明書は、Amazon WorkSpaces Windows、macOS、および Android クライアントにのみ適用されます。この機能は、Teradici PCoIP ソフトウェアおよびモバイルクライアント、Teradici PCoIP ゼロクライアント、RDP クライアント、リモートデスクトップアプリケーションなど、Amazon WorkSpaces Web Access クライアント、またはサードパーティークライアントには適用されません。

IP アクセスコントロールグループ

IP アドレスベースのコントロールグループを使用すると、お客様は信頼できる IP アドレスのグループを定義および管理し、信頼できるネットワークに接続している WorkSpaces 場合にのみユーザーが にアクセスできるようになります。この機能は、お客様がセキュリティ体制をより詳細に制御するのに役立ちます。

IP アクセスコントロールグループは、 WorkSpaces ディレクトリレベルで追加できます。IP アクセスコントロールグループの使用を開始するには、2 つの方法があります。

  • IP アクセスコントロールページ — WorkSpaces マネジメントコンソールから、IP アクセスコントロールページに IP アクセスコントロールグループを作成できます。ルールは、アクセス可能な IP アドレスまたは IP 範囲を入力することで、これらのグループに追加 WorkSpaces できます。これらのグループは、更新の詳細ページでディレクトリに追加できます。

  • Workspace APIs — WorkSpaces APIs を使用して、グループの作成、削除、表示、アクセスルールの作成や削除、ディレクトリからのグループの追加や削除を行うことができます。

Amazon WorkSpaces 暗号化プロセスで IP アクセスコントロールグループを使用する方法の詳細については、「 の IP アクセスコントロールグループ WorkSpaces」を参照してください。

Amazon を使用したモニタリングまたはログ記録 CloudWatch

ネットワーク、サーバー、ログのモニタリングは、インフラストラクチャに不可欠な部分です。Amazon をデプロイするお客様は、デプロイ、特に個々の の全体的なヘルスと接続ステータスをモニタリング WorkSpaces する必要があります WorkSpaces。

の Amazon CloudWatch メトリクス WorkSpaces

CloudWatch の メトリクス WorkSpaces は、個々の の全体的なヘルスと接続ステータスに関する追加のインサイトを管理者に提供するように設計されています WorkSpaces。メトリクスは、 ごと WorkSpace、または特定のディレクトリ内の組織 WorkSpaces 内のすべての に対して集計されます。

これらのメトリクスは、すべての CloudWatch メトリクスと同様に、 AWS Management Console （次の図を参照) で表示でき、 CloudWatch APIs経由でアクセスし、 CloudWatch アラームやサードパーティツールでモニタリングできます。

コンソールのメトリクスのスクリーンショット

図 24: CloudWatch metrics: ConnectionAttempt / ConnectionFailure

デフォルトでは、以下のメトリクスが有効になっており、追加料金なしで利用できます。

  • 利用可能 — WorkSpacesステータスチェックに応答する は、このメトリクスでカウントされます。

  • 異常 — 同じステータスチェックに応答しない は、このメトリクスにカウントされます。 WorkSpaces

  • ConnectionAttempt — に対して行われた接続試行回数 WorkSpace。

  • ConnectionSuccess — 成功した接続試行回数。

  • ConnectionFailure — 失敗した接続試行の数。

  • SessionLaunchTime — WorkSpaces クライアントによって測定される、セッションの開始にかかる時間。

  • InSessionLatency — WorkSpaces クライアントによって測定および報告された WorkSpaces、クライアントと の間のラウンドトリップ時間。

  • SessionDisconnect — ユーザーによって開始され、自動的に閉じられたセッションの数。

さらに、次の図に示すように、アラームを作成できます。

接続エラーの CloudWatch アラームを示すスクリーンショット

図 25: WorkSpaces 接続エラーの CloudWatch アラームを作成する

の Amazon CloudWatch イベント WorkSpaces

Amazon CloudWatch Events からのイベントを使用して、 への正常なログインを表示、検索、ダウンロード、アーカイブ、分析し、応答できます WorkSpaces。このサービスは、 へのユーザーのログインについて、クライアント WAN IP アドレス、オペレーティングシステム、 WorkSpaces ID、およびディレクトリ ID 情報をモニタリングできます WorkSpaces。例えば、次の目的でイベントを使用できます。

  • WorkSpaces ログインイベントを将来の参照用にログとして保存またはアーカイブし、ログを分析してパターンを探し、それらのパターンに基づいてアクションを実行します。

  • WAN IP アドレスを使用してユーザーのログイン元を特定し、ポリシーを使用して、WorkSpaces アクセスの CloudWatch イベントタイプで見つかった WorkSpaces アクセス基準を満たす からのファイルまたはデータにのみアクセスすることをユーザーに許可します。

  • ポリシー制御を使用して、権限のない IP アドレスからのファイルやアプリケーションへのアクセスをブロックします。

CloudWatch イベントの使用方法の詳細については、「Amazon CloudWatch Events ユーザーガイド」を参照してください。の CloudWatch イベントの詳細については WorkSpaces、「Cloudwatch Events WorkSpaces を使用して をモニタリングする」を参照してください。

YubiKey Amazon の サポート WorkSpaces

追加のセキュリティレイヤーを追加するために、お客様は多要素認証を使用してツールやサイトを保護することを選択することがあります。一部のお客様は、Yubico でこれを行うことを選択しています YubiKey。Amazon は、 によるワンタイムパスコード (OTP) 認証プロトコルと FIDO U2F 認証プロトコルの両方 WorkSpaces をサポートしています YubiKeys。

Amazon WorkSpaces は現在 OTP モードをサポートしており、OTP YubiKey で を利用するために管理者またはエンドユーザーから追加の手順は必要ありません。ユーザーは をコンピュータ YubiKey にアタッチし、キーボードが WorkSpace （特に OTP の入力が必要なフィールド) 内でフォーカスしていることを確認し、 のゴールデンコンタクトをタッチできますYubiKey。 YubiKey は、選択したフィールドに OTP を自動的に入力します。

YubiKey と で FIDO U2F モードを使用するには WorkSpaces、追加の手順が必要です。で U2F リダイレクトを利用するには、サポートされている YubiKey モデルのいずれかがユーザーに発行されていることを確認してください WorkSpaces。

  • YubiKey 4

  • YubiKey 5 NFC

  • YubiKey 5 Nano

  • YubiKey 5C

  • YubiKey 5C Nano

  • YubiKey 5 NFC

YubiKey U2F の USB リダイレクトを有効にするには

デフォルトでは、USB リダイレクトは PCoIP WorkSpaces に対して無効になっています。 で U2F モードを利用するには YubiKeys、有効にする必要があります。

  1. インストールしたPCoIP (32 ビット) 用の WorkSpaces グループポリシー管理用テンプレート、または PCoIP (64 ビット) 用の WorkSpaces グループポリシー管理用テンプレートが最新であることを確認します。

  2. ディレクトリ管理 WorkSpace または WorkSpaces ディレクトリに参加している Amazon EC2 インスタンスで、グループポリシー管理ツール (gpmc.msc) を開き、PCoIP セッション変数 に移動します。

  3. ユーザーによる設定の上書きを許可する場合には、[Overridable Administrator Defaults] (上書き可能な管理者のデフォルト) を選択します。それ以外の場合は、[Not Overridable Administrator Defaults] (上書き不可の管理者のデフォルト) を選択します。

  4. [Enable/disable USB in the PCOIP session] (PCoIP セッションでの USB を有効/無効にする) 設定を開きます。

  5. [Enabled] (有効)、[OK] の順に選択します。

  6. [Configure PCoIP USB allowed and unallowed device rules] (PCoIP USB の許可および許可されないデバイスのルール設定) を開きます。

  7. [有効] を選択し、[USB 認証テーブルを入力 (最大 10 個のルール)] で、USB デバイスの許可リストルールを設定します。

    1. 承認ルール - 110500407。この値は、ベンダー ID (VID) と製品 ID (PID) の組み合わせです。VID/PID の組み合わせの形式は です。ここで1xxxxyyyy、 xxxxは 16 進形式の VID、 yyyyは 16 進形式の PID です。この例では、1050 が VID で、0407 が PID です。USB 値の詳細については、 YubiKey YubiKey「USB ID 値」を参照してください。

  8. [Enter the USB authorization table (maximum ten rules)] (USB 認証テーブルを入力 (最大 10 個のルール)) で、USB デバイスのブロックリストルールを設定します。

    1. [Unauthorization Rule] (非承認ルール) に、空の文字列を設定します。これは、承認リスト内の USB デバイスだけが許可されることを意味します。

      注記

      USB 承認ルールと USB 非承認ルールをそれぞれ最大 10 個定義することができます。複数のルールを区切るには、縦棒 (|) 文字を使用します。承認/承認解除ルールの詳細については、「Windows 用 Teradici PCoIP 標準エージェント」を参照してください。

  9. [OK] をクリックします。

  10. グループポリシー設定の変更は、 の次回のグループポリシーの更新後 WorkSpace 、および WorkSpace セッションの再開後に有効になります。グループポリシーの変更を適用するには、次のいずれかを実行します。

    1. を再起動します WorkSpace (Amazon WorkSpaces コンソールで を選択し WorkSpace、アクション 、再起動 WorkSpaces を選択します）。

    2. 管理コマンドプロンプトで、gpupdate/force と入力します。

  11. 設定が有効になると、USB デバイスルール設定で制限が設定され WorkSpaces ていない限り、サポートされているすべての USB デバイスを にリダイレクトできます。

YubiKey U2F の USB リダイレクトを有効にする YubiKey と、FTAK U2F モードで を利用できます。