便利だけど気をつけないと危ないChrome Remote Desktop

Windowsデスクトップに遠隔でアクセスしたくなる事がありますが、皆さんどうされてますか？

昔から定番はVNCを使うことでした。個人的にも昔はRealVNCやUltraVNCを使っていましたが、VNCは画質もイマイチですし音声も転送できないのでもう少しマシな方法が欲しいところです。

Windowsの場合、純正のプロトコルであるRDPを用いた「リモートデスクトップ接続」なら音声も転送できますし画質も綺麗です。ですが、これを利用しようとすると、遠隔操作される側が(Homeやwith Bingでなく)Professionalなど上位のエディションである必要がありました。ところが最近、HomeエディションのWindowsでもRDPによるリモートデスクトップ接続を可能にするRDPWrapなんてものが現れました。個人的にも最近は専らこれに頼っています。Windows 8.1 with BingやWindows 10 Homeあたりでも問題なく遠隔操作できるので大変便利です。さらに最近はMicrosoft純正のAndroidで動作するクライアントやiPad/iPhoneなどのiOSで動作するクライアントもあるので、時々iPadから接続したりして快適に利用してます。

そんなわけで個人的にはRDPWrapですっかり満足しているのですが、他の選択として、最近GoogleがChrome Remote Desktopなるものを出していることに気づいてはいました。

support.google.com

ChromeはChromecastに向かってタブだけじゃなくデスクトップを送信（キャスト）する機能があるので、Chrome Remote Desktopもこの技術の延長で実装されてるのかなと思っていたのですが、先日ちょっと調べる機会があって動作を見てみたらこれがとんでもない勘違いであることに気づきました。確かに便利ではあるのですが、なかなか怖いということもわかったのでまとめておきます。

Chrome Remote Desktopのインストールの方法&使い方

インストール手順や基本的使用法そのものはここに詳しいので譲ってしまいます。

www.atmarkit.co.jp

この手順を見ればわかりますが、サーバPCには、chromeremotedesktophost.msiのインストールを通じて「Chromeリモートデスクトップサービス」なるサービスが登録されます。

この結果、対象となるサーバPCはChromeの起動の有無やログオン状態とは関係なく、電源onであればいつでも遠隔操作可能となります。Chrome Remote DesktopというからにはChrome起動中だけ遠隔操作可能なのかと思ってしまいそうになりますが（私だけ？）実はChromeとは無関係であるというのがミソ。ログオン前でも遠隔で接続してログオン操作から行うことが出来るので、確かに大変便利です（例えば再起動が必要になる状況になっても気軽に遠隔から再起動できます）が、一方で他人が利用中のPCのデスクトップも（許可さえされていれば）いつでも共有できてしまう＝操作可能になってしまいます。なお遠隔操作時には、画面中央下に「デスクトップは現在<googleアカウント名>と共有されています」と表示されますので、遠隔操作されていることに気づくことはできます。この機能はどうも、PC操作の遠隔サポートなどを想定しているのでこのような動作になっているようです。

遠隔操作できる条件

調べた範囲では、サーバ側PCのデスクトップが共有可能になる＝遠隔操作可能になる条件は以下の場合のようです（間違っていたらご指摘下さい）。

1. サーバ側PCの管理者権限を持っており（＝ローカル管理者権限のあるアカウントを持っている）あらかじめ対象PCを遠隔操作可能なGoogleアカウントを指定してあること。管理者権限はChromeリモートデスクトップサービスのインストール時と、遠隔操作可能なGoogleアカウントの指定時（PIN指定時）の2回必要になります。遠隔操作可能とするためには、対象となるPCのデスクトップでの直接操作が必要になります。また、1台のPCに対して遠隔操作可能なGoogleアカウントは1つしか指定できません。
2. サーバ側PC、クライアント側PCともにGoogleの特定のサーバへの443/5222TCP接続と、UDPの対外接続が可能であること。NAT配下で構わないようですが、NATルータのUDP Hole punchingについてどんな制限があるかはまだ調べていません。重要なのは、サーバ側PCに外からTCP接続を必要としない、つまり、Port forwardingやUPnPを必要としないことです。UDPが必要なのでProxy配下の端末は操作できませんが、VNCやRDPと違ってTCP接続の穴を外から開ける必要がありません。

ネットワーク的な動作

実際のネットワークトラフィックがどのようになるかは、この辺を読むと推測できます。

(1) サーバ側

Chromeリモートデスクトップサービスを担っているremoting_host.exeから、chromoting-host.talkgadget.google.comのport 5222にTCP接続されています（プロトコルはXMPPの模様）。また、実際のリモートデスクトップ接続後はランダム（だいたいは60000番台）なポート番号のUDPトラフィックをクライアントとの間で直接やりとりしますが、ここに書いてある設定によってポート番号の範囲を12400～12409に制限できるようです。

(2) クライアント側

ドキュメント読む限りはchrome.exeからchromoting-oauth.talkgadget.google.comのport 443とchromoting-client.talkgadget.google.comのport 5222にTCP接続するようです。ただ、私が試した範囲ではChrome.exeから5222への接続は確認できませんでした。代わりにport 5228へのそれらしい接続は見つかりました（バージョン47.0.2526.28の場合）。一度接続するとUDPトラフィックをサーバ側PCとの間で直接投げ合います（ポート番号はやはり基本ランダムで、設定により制限可能）。

なお実際にはGoogleのサーバは（現在のところ）3種とも全てwildcard-talkgadget.l.google.comへのaliasになっているようです。

問題となりうる状況

すぐに思いつく問題では、「UDPが通ればFirewall配下でも遠隔操作可能になるので、組織内のPCがセキュリティポリシーなどに反して遠隔操作可能にされているかもしれない（その結果組織のセキュリティに影響する）」という話です。ただ、PCの管理者権限が必要ですし、NAT接続などUDPが通らないとダメという制限がありますので、小企業のように企業内PCの管理者権限がエンドユーザに渡されているようなところでない限りあまり問題にならないかも知れません。

一般利用者にとっては「いつのまにか画面が他の人に覗かれているかも知れない」という問題があります。これはChrome Remote Desktopが現在使用中の画面状態（セッション）のまま他者に共有させるからです。この挙動はVNCと同じですが、純正リモートデスクトップ接続であるRDPとは違います（RDPの場合使用中のセッションを遠隔で奪うには使用者のログオンパスワードが必要）。共有状態になっているかどうかは画面に「共有されています」という表示が出ているかどうかで解りますが、気づかない可能性はあります。例えばログオンした画面をロックせずに離席してたら、覗かれても気づきませんね。

あと細かいことですが、通信プロトコルが全体としてXMPPをベースとしたものだと思われるのですが詳細は分からないので、リモートデスクトップ接続利用に伴ってGoogleにどのような情報が渡っているのかよく判らないのも気になります。これについてはヘルプ中の「Chrome リモート デスクトップの安全とセキュリティ」という節に「ネットワークの待ち時間やセッションの継続時間に関して、データを完全に匿名で収集、保存」とあり、不要な情報は保存していないと宣言されているので、これを信じる限りはそれほど心配要らないと思うのですが。

Google Chrome Desktopの使用を禁止する方法

端末に管理者権限がない利用者が勝手にChrome Remote Desktopの利用を有効にすることはできないので、この点は安心なのですが、ネットワーク管理側で一網打尽にしようとすると少し面倒です。TCP Port 5222による対外接続を塞いでしまうとできますが、他のXMPP使用アプリケーションも（どれくらいあるかわかりませんが）塞がれてしまいます。きちんと管理する方法については、Google自身が下記のような情報を提供してくれています。

リモートでデスクトップを管理する - Chrome for Work ヘルプ

上記URLにはいくつかのGoogleのホストをDNSでブロックせよと書いてあるのですが、これは管理者にとってはちょっと面倒な上、ちゃんと考えておかないと抜け穴が残っちゃいますよね（例えばDNSサーバを管理外のものに変更されてしまうと抜けられてしまう）。まぁ結局ちゃんと端末管理したければNATなんかせずにProxy設置しなさいということなんでしょう。

 

ということで、何かのご参考になれば。