Chrome Remote Desktopは安全か?正直なレビュー

手短に言うと、カジュアルな個人利用であれば、Chrome Remote Desktop(CRD)は十分に安全です。Google提供の無料でシンプルなツールで、セッションを暗号化し、PINとGoogleアカウントによってアクセスを制限します。正直なところ、クローズドソースであり、通信はすべてGoogleのクラウドを介して仲介され、管理者としてのコントロールはほとんどなく、そして——あらゆるリモートツールと同様に——詐欺師に悪用される可能性もあるという注意点があります。以下、根拠を示しながら公平に見ていきましょう。

手短な結論

CRDは、本来の用途——自分のマシンにアクセスする、あるいは家族のサポートをする——には十分に安全です。接続はGoogleが保護してくれます。Google公式のサポートドキュメントによれば、すべてのリモートデスクトップセッションは完全に暗号化されており、無人アクセスにはPINが必要で、単発のサポートセッションでは一度しか使えないシングルユースのアクセスコードが使用されます。個人利用としては妥当な基準と言えるでしょう。

立ち止まって考えるべきなのは、カジュアルな利用の範囲を超える場合です。CRDはGoogleアカウントに紐づけられ、Googleのインフラ上で動作し、管理機能は限定的です。実際の弱点は、推測されやすいPIN、Googleアカウントの侵害、そしてソーシャルエンジニアリングの3つです。だからといってインストールが危険というわけではありません——どこまで信頼して使うべきかを左右する要素だということです。

Chrome Remote Desktopがセッションを保護する仕組み

実際に機能しているのは3つの仕組みで、いずれもGoogleのヘルプページに記載されています。

• 暗号化。 Googleは「すべてのリモートデスクトップセッションは完全に暗号化されている」と述べています。第三者による分析でも、一般的に標準的なウェブ転送のセキュリティ(TLSとAES)を使用していると説明されています。Googleは一般消費者向けページでプロトコルの詳細な内訳を公開していないため、暗号化は十分ではあるものの、独自に監査できるものではないと考えておきましょう。
• 無人アクセス用のPIN。 継続的なリモートアクセス用に設定したコンピューターにアクセスするには、PINの入力が必要です。これにより、あなたのGoogleセッションを持つ無関係な第三者が、気づかれずに接続することを防いでいます。
• サポート用のワンタイムアクセスコード。 リアルタイムで誰かをサポートする際、ホスト側は一度しか使えないコードを生成します(Googleの説明による)。共有を続けるには、定期的な再確認が必要です。

これらに加えて、Googleアカウント自体も二要素認証で保護することができ——リモートアクセスにおいては、それは絶対にそうすべきことです。信頼できるネットワーク上での個人利用であれば、この仕組みは実際のところ十分です。

実際のリスクはどこにあるのか

CRDの弱点は特殊なものではありません。その設計から必然的に生じる、次の3つです。

脆弱なPIN。 PINは無人アクセスを守る鍵であり、Googleが定める最小桁数はわずか6桁です。見知らぬ人が一度だけ推測を試みる分には6桁でも十分ですが、人は誕生日、繰り返し数字、連番といった予測可能な数字を選びがちで、これにより桁数から想定される探索空間の実質的な広さは大幅に狭まります。24時間365日アクセス可能な状態にしているマシンにとって、安易なPINは侵入される最も可能性の高い経路です。分かりにくいものを選びましょう。

Googleアカウントの侵害。 無人アクセスのCRDはGoogleアカウントに紐づけられているため、そのアカウントこそが防御境界なのです。誰かがフィッシングであなたのGoogleパスワードを盗み、二要素認証を有効にしていなければ、あなたのリモートデスクトップも相手の手に渡るものの一部になってしまいます。これはCRD自体の欠陥というより、すべてをGoogleアカウントという一つのかごに入れてしまうことの帰結です——だからこそ、CRDを使うなら、そのアカウントで2FAを有効にすることは譲れません。

詐欺。 あらゆるリモートツールと同様に、現実世界で最も大きな被害をもたらすのは暗号の破られ方ではなく、ソーシャルエンジニアリングです。FBIも警告しているとおり、テクニカルサポート詐欺の犯人は被害者を言葉巧みに誘導してリモートデスクトップソフトをインストールさせ、アクセスを共有させたうえで口座から金銭を奪います。CRDのワンタイムコードは、電話口の「親切な技術者」に読み上げてしまいやすく、それがまさに問題の核心です。公平に言えば、これはCRDの脆弱性ではなく利用上のリスクです——AnyDeskやTeamViewer、RustDeskでも全く同じ手口が通用してしまいます。防御のための習慣についてはリモートデスクトップ詐欺を避ける方法で解説しています。

CRDにないもの

CRDは意図的にミニマルに作られており、多くの人にとってはそこが魅力でもあります。とはいえ、特に個人利用を超えた用途を検討している場合は、そのトレードオフをはっきりさせておく価値があります。

セルフホスティングはできません。すべてのCRD接続はGoogleのクラウドを介して仲介され、Googleアカウントに紐づけられています。ランデブーサービスを自分のサーバー上で動作させるオプションはなく、監査できるソースコードもありません——ホストが説明どおりに動作していることは、Googleを信頼するしかないのです。また、チーム管理、一元化されたポリシー、アクセス制御リスト、セッションログ、デバイスのグループ化といった機能もほとんどありません。これはGoogleを批判しているわけではなく、単にCRDがそうした用途向けに作られていないというだけです。こうした機能が必要になったなら、それはCRDでは物足りなくなったということであり、より高機能な無料リモートデスクトップツールやChrome Remote Desktopの専用代替ツールを検討するのが正直な次のステップです。

ここにこそ、オープンソースでセルフホスト型のモデルが、単なる機能の多さではなく異なる種類の安心をもたらす理由があります。CRDは、検証できる公開プロトコルがないまま、その暗号化を十分なものとして受け入れることを求めます。一方RustDeskはAGPLの下でオープンソース化されているため、クライアントとその暗号処理は信頼に頼るのではなく監査できる形で存在しています。そして、CRDがGoogleアカウントを防御境界にしてしまうのに対し、セルフホスティングではID/ランデブーサーバーとリレーサーバーを自分のマシンやVPS上に置けるため、仲介とアクセスポリシーは単一のクラウドログインの背後ではなく、自分がコントロールするインフラ上にとどまります——これはデータ主権やGDPRに関する懸念に直接関わってくる点です。

念のため言っておくと、このオープン性は両刃の剣でもあります。コードが公開されているということは、RustDesk自体の脆弱性も公開されるということです。最新リリースや脆弱性開示の記録には注意を払っておきましょう。また、セルフホスティングは一種の手間を別の手間に置き換えるだけです——CRDに必要なアカウントとPINの管理が、自分でパッチを当てるサーバーへと変わり、トラフィックは依然としてエンドポイント間を直接移動します。これは異なる安心のモデルであって、より軽いものではありません。

最終評価

Chrome Remote Desktopは安全か?カジュアルな個人利用——自分のPCにアクセスする、親戚をサポートする——であれば、答えはイエスです。十分に安全で、シンプルかつ低コストです。その前提で評価してください。Googleアカウントで二要素認証を有効にし、誕生日ではないPINを選び、自分から連絡してきた相手には決してアクセスコードを読み上げない——これだけで、実際に重要となるリスクには対処できたことになります。

CRDの限界が見えてくるのは、コントロールとスケールの面です。クローズドソースであり、Googleのクラウドを介して仲介され、管理機能も乏しいのです。コードを監査する必要がある、仲介を自分のインフラ上にとどめておきたい、あるいは複数台以上のマシンを管理する必要がある——そうした場合こそ、オープンソースでセルフホスト型の選択肢を検討すべきタイミングです。CRDが安全でないからではなく、そもそもそういう用途のためのツールではなかったからです。