【クローズド・閉域】インターネット接続不可の Amazon WorkSpaces

記事タイトルとURLをコピーする

こんにちは、クラウドインテグレーション部 技術1課 宮形 です。

私が好きなAWSのサービスとして、 Amazon WorkSpaces があります。 VDI を短時間で簡単に作れるところが気に入っています。

そんな Amazon WorkSpaces (以下 WorkSpaces と記) ですが、WorkSpaces の中の OS をインターネット接続不可のクローズド(閉域)にしても問題なく使えるのでしょうか?という疑問がありました。 ネットの記事を探してみましたが、意外と情報がなく、個人的に検証してみることにしました。

f:id:swx-miyagata:20220204190733p:plain

例えば「高いセキュリティが求められる業務を WorkSpaces 上で行いたい」というニーズに対応できると思いました。

前提条件

  • WorkSpaces の OS は Windows10 (Windows Server 2019 ベース) Office バンドル
  • Directory Service として AD Connector を利用し、EC2上の Active Directory をディレクトリ参照

構成図

下記の構成図のような環境を作成して検証しました。Microsoft Active Directory サーバーが Public Subnet に配置されてしまっていますが、後の設定でインターネット接続はできません。

f:id:swx-miyagata:20220204190814p:plain

クローズド(閉域)環境の構築

WorkSpaces が接続するサブネットのルートテーブルは、下記のように VPC内の CIDR への経路のみとします。 インターネット向け 0.0.0.0/0 の経路は未定義です。これだけで、インターネットには接続できなくなる筈です。

f:id:swx-miyagata:20220204180931p:plain

加えて、ネットワークACL(NACL)で VPC内のCIDR以外は通信をブロックします。

f:id:swx-miyagata:20220204181024p:plain

WorkSpaces 自体の構築手順は、本BLOGでは説明割愛とさせていただきます。弊社過去BLOGに多く情報がありますので、必要な方はご参照ください。

Amazon WorkSpaces カテゴリーの記事一覧 - サーバーワークスエンジニアブログ

WorkSpaces へ接続して動作確認

この状態でインターネット接続できるクライアントから WorkSpaces へ接続してみます。 特に問題なく接続できました。

f:id:swx-miyagata:20220204181136p:plain

WorkSpaces 内から実行する ping も nslookup 名前解決もインターネットへは届いていません。

f:id:swx-miyagata:20220204182912p:plain f:id:swx-miyagata:20220204181238p:plain

WorkSpaces 内からWebブラウザを起動してみますが、どのWebサイトへも接続できません。

f:id:swx-miyagata:20220204181318p:plain

インターネット接続が不可となると、Windows 愛好家(?)として気になるところを調べていきます。

Windows と Office のライセンス認証

確認してみましたが、しっかりライセンス認証されていました。 f:id:swx-miyagata:20220204181354p:plain

f:id:swx-miyagata:20220204181433p:plain

slmgr.vbs -dli コマンドで確認すると、KMSクライアントでOSライセンス認証が行われていました。 KMSホストのIPアドレスは 169.254.169.250 となっています。

f:id:swx-miyagata:20220204181451p:plain

Officeのライセンス認証は別のコマンドで確認します。

cscript “C:\Program Files\Microsoft Office\Office16\ospp.vbs” /dstatus

こちらもKMSクライアントで認証されています。KMSホストのIPアドレスは 198.19.64.250 でした。OSとは別のようです。

f:id:swx-miyagata:20220204181518p:plain

ややこしいのですが、KMS というキーワードは AWS にも存在しており「キー管理サービス」として暗号化のための鍵をクラウドで管理してくれます。 本BLOGの KMS はMicrosoftが提供するものです。Windows や Office などのアクティベーションを行うサーバーをイントラネット上に構築できる仕組みです。

Windows Server でキー管理サービス (KMS) ライセンス認証ホストを作成する方法 | Microsoft Docs

KMSホストはイントラネット内に自分で構築することが可能です。その場合、クライアントがKMSホストを見つけるために DNSサーバーにSRVレコードを登録するのが一般的です。_vlmcs._tcp という固定で決まったSRVレコードを登録します。

WorkSpaces でKMSのSRVレコードを nslookup してみましたが、レコード無しとなります。 KMSホストや SRVレコードを私自身が構築・登録していないので当然です。

f:id:swx-miyagata:20220204181651p:plain

では、WorkSpacesはどのようにしてKMSホストを見つけているのか?答えはレジストリでした。IPアドレス直書きでハードコードされています。

f:id:swx-miyagata:20220204181741p:plain f:id:swx-miyagata:20220204181726p:plain

この点は、AWSのマニュアルに記載がありました。

WorkSpaces の IP アドレスとポートの要件 - Amazon WorkSpaces

・パブリックバンドルに基づく WorkSpaces の Windows アクティベーション用の Microsoft KMS へのアクセスを許可する、ポート 1688 での IP アドレス 169.254.169.250 および 169.254.169.251 への送信 TCP。ライセンス持ち込み (BYOL) Windows WorkSpaces を使用している場合は、Windows アクティベーションのために独自の KMS サーバーへのアクセスを許可する必要があります。

・ポート 1688 での IP アドレス 54.239.236.220 への送信 TCP を使用して、BYOL WorkSpaces の Office 用 Microsoft KMS のアクティベーションのためのアクセスを許可します。

WorkSpaces パブリックバンドルの 1 つを通じて Office を使用している場合は、Office アクティベーション用の Microsoft KMS の IP アドレスは異なります。その IP アドレスを特定するには、WorkSpace の管理インターフェイスの IP アドレスを検索し、最後の 2 つのオクテットを 64.250 に置き換えます。例えば、管理インターフェイスの IP アドレスが 192.168.3.5 の場合、Microsoft KMS Office アクティベーションの IP アドレスは 192.168.64.250 です。

WorkSpaces のOSには、イーサーネットポートが2つあります。

f:id:swx-miyagata:20220204182055p:plain

ひとつは「プライマリインターフェイスポート」です。本来インターネットへアクセスするときはこちらから通信がおこなれますが、今回はクローズド(閉域)としています。

もう一つの「管理インターフェイスポート」です。AWS側が管理するマネージドVPCに繋がっており、利用者クライアントとの画像や操作の伝搬などにも利用されています。この「管理インターフェイスポート」の先にKMSホストが配置されているようです。

WorkSpacesのルートテーブルを確認すると、やはり必要な分の静的ルートが「管理インターフェイスポート」向けで設定されていました。 f:id:swx-miyagata:20220204185131p:plain

Windows と Office のライセンス認証は WorkSpacesがインターネット接続不可でも問題無いことがわかりました。

Windows Defender の定義パターン更新

これはインターネット接続不可クローズド(閉域)だとパターン更新することはできませんでした。確認しましたが、2019年7月ころの Windows Defender 定義で止まったままです。

f:id:swx-miyagata:20220204182219p:plain

WSUS、SCCM、サードパーティのオフライン対応のウイルス対策ソフトウェアetc。。。を用意する必要がありそうです。

NTP 時刻同期

WorkSpaces のOSで w32tm コマンドで確認すると、下記3つのNTPサーバーを参照となっています。

(1) 169.254.169.123

(2) ActiveDirectoryサーバー(PDC)

(3) time.windows.com

f:id:swx-miyagata:20220204185035p:plain

(1) は AWS側が提供しているNTPサーバーのようです。このNTPサーバーについてはAWSより解説されています。

Amazon Time Sync Service で時間を維持する | Amazon Web Services ブログ

(2) はWindows の仕様で、ActiveDirectory ドメイン参加すると PDCをNTPサーバーとして参照するようになります。自動的に登録されたものと思われます。

(3) はWindows デフォルトの設定ですが、インターネット上に存在するので到達できません。

(1) のAWS提供NTPサーバーは、先ほどの「管理インターフェイスポート」の先に存在しているので、WorkSpacesがインターネット接続不可でも問題無く時刻同期が行えます。 なお、(1) と (2) が モード3 クライアントなので、どちらとも時刻同期する可能性があります。 ActiveDirectory においては、ドメインコントローラーとメンバーの時刻が一致している必要があります。もし、(2) の 時刻が意図あってズレている場合は注意が必要です。グループポリシー等を使って (1) AWS提供NTPサーバー を参照しない設定をした方がよいです。

まとめ

結果、インターネット接続不可クローズド(閉域)の WorkSpaces を構築して利用することは出来ました。 AWS下記マニュアルの通信要件を守ることに注意が必要です。 WorkSpaces の IP アドレスとポートの要件 - Amazon WorkSpaces

また、インターネット接続不可の場合、使用できない機能が存在します。例えば、下記マニュアルには WorkSpaces の機能 Application Manager を利用するためにはインターネット接続が必要という記載があります。今後新機能が登場した場合も、都度インターネット接続の必要性を確認する必要があります。

WorkSpaces 用に VPC を設定する - Amazon WorkSpaces

WorkSpaces は、仮想プライベートクラウド (VPC) で WorkSpaces を起動します。オペレーティングシステムに更新をインストールし、Amazon WorkSpaces Application Manager (Amazon WAM) を使用してアプリケーションをデプロイできるように、WorkSpaces はインターネットにアクセスできる必要があります。

WorkSpaces をどのような業務・用途でご利用されるかはユーザー様それぞれだと思います。 本BLOGが WorkSpaces をご検討されている方の参考になれば幸いです。

宮形純平(執筆記事の一覧)

クラウドインテグレーション部 技術1課

好きなお酒は缶チューハイと本格焼酎