Chrome リモートデスクトップの安全性について
本記事は、corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#1 Advent Calendar 2021のアドベントカレンダー3日目の記事となります。Chrome リモートデスクトップ(というかWebRTC)のことについて書いてます。
前書き
緊急事態宣言等の影響によりリモートワークが余儀なくなり、とりあえずで作った環境そのまま運用している会社も少なくはないのかなと思っています。そんな中で、ブラウザがあれば遠隔地のPCにリモートでアクセスすることができる、Chrome リモートデスクトップというブラウザ拡張機能の利用を検討された方もいらっしゃるのではないでしょうか。
弊社でも、「無料で使えるからこれええやんけ。使ったろ」と思ったものの、あまりに簡単に使えるものだから本当に安全なのか？ と疑問点がいくつか沸いてきました。提案することになった際に「天下のGoogleが提供してるから大丈夫です！ 多分！」と言うだけではなくてちゃんと説き伏せられる程度には知識を仕入れておこうかなと思い、整理もかねての投稿となります。
Chrome リモートデスクトップ
Chrome リモートデスクトップとは、利用しているPCの画面を他のPCと共有し、共有先PCのキーボードとマウスを操作できるようになるChromeの拡張機能の一つです。
基本的には拡張機能をインストールするだけなので、従来のように会社のPCにVPNのソフトウェアをインストールして、端末の設定を入れて、FW側で設定をして…といった作業をすることなく、共有のためのコードを生成し、それを入力するだけでサクっとアクセスすることが可能となります。
共有先の画面を見るためにはChromeさえあればOKです。RDP接続のようにProfessional以上のライセンスじゃないといけない、といった制約も今のところ無さそうなので、割といろんな環境でコストをかけずに使えることができる機能となってます。
で、これってどうやって実装してるのかなというと、WebRTC(Web Real-Time Communication)って技術が使われています。
WebRTCとは、WEBベース(ブラウザ)で動画や音声をやり取りするために開発された技術であり、今回のようにPCの画面などの映像や、ブラウザベースでのTV会議などを実装する際に利用されています。
WebRTCの実装方式
WebRTCを実装するための主な通信方式やプロトコルは以下となります。
・P2P
WebRTCでは、相手と通信をする際の主な通信方式としてP2P(Peer to Peer)が用いられます。読んでそのまま、サーバを介することなく相手先の端末と自端末で直接通信を行う通信方式となります。とはいえ、通信を始める際に一切の手がかりなく相手先を知ることは困難なので、WebRTCではその他以下のサーバを用いて通信先を判別します。
・STUNサーバー
プライベート環境間での通信でもない限り、インターネットを介した通信にはNATによってアドレス変換が行われます。STUNサーバでは、NATした際のIPアドレスとポート番号を保管しあうことで、通信先のアドレス情報を知ることができるようになります。これによって、相手へ通信するためにNATを超える必要があるのか否かを判断することができます。
・TURNサーバー
STUNによってNAT越えが必要となった場合で、ファイアウォールの制限などでP2P通信ができない際に代理で通信を行う際に利用されるサーバです。一般的に、企業のLANから通信する場合はNATが必須になるかと思うので、ほぼこのサーバーを利用して通信することになるかと思います。
・シグナリングサーバー
通信相手の情報を得るためのサーバです。通信に必要な各ブラウザの情報(SDP)などの情報が登録され、相手を識別するために用いられます。
WebRTCを使った通信概要図
は、ざっくり以下のようになるかと思います。
WebRTCの安全性
WebRTCにおいては、基本的に以下のような要件にて安全性が担保されています。
・TURNを経由した通信は必ず以下の方式で暗号化されるため、秘密鍵を持つユーザ間以外は通信を復号化、判別することはできない。(TURNも同様)
データストリームの暗号化方式 ：DTLS
メディアストリームの暗号化方式：SRTP
・ブラウザ(Webベース)のツールのため、通常利用時はソフトウェアをインストールする必要がなく、一般的なソフトウェアに比べて利用時におけるマルウェア混入のリスクが少ない。
・システムはブラウザの機能に依存しているため、脆弱性が発見された際の対応がブラウザ開発元によって行われるため比較的迅速に行われる。
・カメラや画面キャプチャ等、リソースへのアクセス時は必ず許可を促すため、利用者がアクセスを許可しない限りは接続先のリソースからの情報流出はない
ということで、なるほどWebRTCを使った場合の通信は安全だということが担保されました。ただそれでも、「とは言ってもなんかまだ不安なんだよなあ…」と言われた場合によくありそうな理由を4点ほど考えてみました。
①Chrome拡張機能の危険性
こちらの記事などで過去に見たことがあったのですが、Chromeの拡張機能には一部プライバシーポリシーが非掲載であったり、脆弱性のあるライブラリが含まれているといった安全性の確認が成されていないアプリケーションが展開されていることがあるとの情報があります。
これらは、拡張機能を配信するプラットフォームが抱える問題であり、WebRTCやChromeリモートデスクトップに対する問題では無いため、本アプリを提供元がはっきりしているところから(Googleから)インストールすることを徹底することで懸念を解消できるかなと思います。
②データ流出の危険性
WindowsのRDPと同じように、Chromeリモートデスクトップにおいてもリモート接続先からリモート接続元へクリップボードの共有(同期)を行うことができます。これは、やりようによっては私用のPCから社用のPCへリモート接続し、PC内の秘密情報を抜き取ることも可能となります。
これはWebRTCの脆弱性というわけではなく、Chromeリモートデスクトップの仕様に関する問題となります。これに関しては、こちらの記事にもある通りブラウザの設定によってリモート元→先へのコピペを制限するといった設定で制御をかける必要があるかと思います。ただ、本設定を実際に試したところリモート先→元へのコピペは可能なようでした。そのため、この辺りの記事を参考に、リモートアクセスを許可するネットワーク等を制御することで、想定外の環境からのアクセスを行わせないようにする必要があるかと思います。
③アカウント漏洩の危険性
そうは言ってもGoogleアカウントがIDもパスワードも漏洩したら意味ないんじゃないの？ と言われることもあるかと思います。ただ、これに関してはChrome リモートデスクトップに限った話ではなくなってしまうので、2要素認証を利用してアクセスを制御したりすることで万が一漏洩した場合でも不正アクセスされづらくする仕組みづくりが必要になるかなと思います。
④P2Pの危険性
P2Pはその通信方式から、サーバを介さないため通信元の安全性を確認することが難しいと言われています。とはいえ、前述したように今ではTURNサーバなどを介して通信することが多い状況ですし、前述した接続元ネットワーク設定などを用いて統制をかけることで、使う用途や使う人、接続先の端末などを十分に制御できていれば問題はないのかなと思います。
また、P2PというとどうしてもWinny等のファイル共有ソフト(と、それを介して拡散したウイルスやワームの被害)を思い出してしまうのでそれも印象が良くない原因の一つかな、と思いました。悪いのは技術ではなくそれを悪用する人なので、それらに直接の罪は無いんですけどね。。。
上記、パッと思いつく印象でとりあえず4つほど挙げてみました。どういう仕組みで動いているのかを分かっていれば怖いものではなくなるのかなと思います。それだけではなく、システム上でもこういった設定を行うことでデータ流出を防ぐことが可能です、まで言えると導入への心理的ハードルがグッと下がるのではないかなと思いますので、一度どこまで制御できるのかをお試しいただくのも良いかなと思います。
参考資料
【初心者向け】P2Pを知らない１ヶ月前の自分にWebRTCを説明してみる
WebRTC で利用されいる TURN プロトコルの解説
この記事が気に入ったらサポートをしてみませんか？