この記事を書く理由

この記事を書こうと思ったのは、TeamViewerが関係するセキュリティインシデントが起こるたびに、TeamViewerという製品自体のセキュリティレベルが疑われたり、TeamViewerについて間違ったアドバイスが記事になったりする状況が、いつまでたっても改善されないからです。

この記事を書いているつい先日も「ハッキングであわや大量毒殺発生の危機だった水道処理施設のずさんなセキュリティー体制とは？」(2021/02/12 GIGAZINE) といったインシデントがありました。

このインシデントについて米CISAが 'Alert (AA21-042A) Compromise of U.S. Water Treatment Facility' という警告文書の最後で、TeamViewerの正しい使い方を推奨していますが、企業でTeamViewerを正しく使う方法の推奨になっていません。

そこで企業でセキュアにTeamViewerを使うときのベストプラクティス的なものを書いてみます。

ここに書いた内容よりさらにセキュアで簡潔な設定方法があればぜひご教示ください。また、TeamViewerの仕様について間違っている点があればご指摘下さい。

あくまでセキュリティの考え方を書く目的ですので、具体的な操作手順までは書きません。公式マニュアルを参照してください。

なお筆者はTeamViewer社との利害関係はありません。

企業向けTeamViewerベストプラクティス的な何か

有償版を購入する

無償版を商用に使うのはライセンス違反で論外ですが、無償版の致命的な欠点は「企業プロファイル」を使えないことです。企業プロファイルの機能をフルに使って初めてTeamViewerのセキュリティ機能を最大限まで活用できます。

企業プロファイルを使うと、組織のクローズドなTeamViewerインスタンスのようなものを作成でき、組織内のTeamViewerインストール済み端末や、TeamViewerユーザー、セキュリティポリシー、カスタムモジュール、アクセスログなどをManagement Console(以下管理コンソール)で統合管理できるようになります。

これを知らない人が意外に多いのではないかと思います。以下、有償版を購入して組織管理者で初めてサインインしたところからを記述してみます。

組織管理者はライセンス購入時に申請したメールアドレスで、そのメールアドレスで公式サイトにリンクのあるManagement Console(管理コンソール)にサインインすると、有償版の企業プロファイルが使える状態になっています。以下のURLです。

https://login.teamviewer.com/

この管理コンソールのURLは実は無償版ユーザーでもサインインできますが、当然ながら企業プロファイルの機能は使えません。

組織管理者に二要素認証設定する

企業プロファイル全体を保護するために、組織管理者だけでなく下記で登録する組織内の全ユーザーに二要素認証を設定します。二要素認証はGoogle AuthenticatorやAuthyなどのTOTPアプリを使う方式です。

組織管理者だけは自分で自分の二要素認証を自由に解除できますが、組織管理者は他の組織内ユーザーのユーザープロファイルをロックして自分で二要素認証を解除させないようにします。

組織管理者は組織内の別のユーザーに組織管理者の権限を付与することができます。1人で管理しきれなくなったらそうするのがいいでしょう。

ユーザーを登録してプロファイルをロックする

組織内でTeamViewerを使うユーザーのメールアドレスを管理コンソールから登録します。

ユーザー登録が必要なのは、ユーザサポート担当者や遠隔マシンに接続する必要がある要員だけです。つまり遠隔接続する側のユーザーだけです。サポートで接続を受ける側のエンドユーザーは登録しません。

登録時にはユーザープロファイルを編集可能の状態にし、各ユーザーに初期パスワードの変更と二要素認証の設定をしてもらいます。ユーザー側で設定が終わったら、組織管理者はユーザープロファイルをロックし、本人が編集できないようにします。

「二要素認証を設定したよ」と言いつつ実は設定していないユーザーがいるかもしれませんが、管理コンソールでユーザー別に二要素認証設定済みマークが表示されるためすぐ分かります。マークがないユーザーには設定を催促します。

ちなみに、二要素認証設定時の復元コードとTOTPトークンとして使っていたスマホの両方を紛失し、TOTPアプリのバックアップ端末もないとなると、サインイン不能になるため、二要素認証をいったん解除する必要が出てきます。

TeamViewerでこうなった場合、何とサポートに申請して解除してもらうしか方法がありません。最初これを知ったときはびっくりしました。

ライセンス購入時のインボイスを証憑として添付し、サポートに申請すると、おおむね翌日まで二要素認証を解除してくれます。この手続きの面倒さはセキュリティとのトレードオフということで(汗)。

ユーザー登録のその他の意義としては、どのユーザーが、どの端末へ、いつ、どれだけの時間接続したか、管理コンソールからすべての接続ログを確認できることがあります。勤務時間外の遠隔接続や、同一端末への長時間の接続など、セキュリティのみならず様々な観点のチェックに使えます。

2021/02/18 追記:

ちなみにTeamViewerに登録するメールアドレスは全世界のTeamViewerでユニークです。つまり同じメールアドレスをA社のライセンス(企業プロファイル)とB社のライセンス(企業プロファイル)に同時に登録することはできません。

これによって生じる不都合はサポートベンダーの場合です。サポートベンダーの担当者がTeamViewerを使って複数企業をサポートする必要があるとき、各社用のメールアドレスを使い分けて、各社の企業プロファイルにサインインすることになります。

TeamViewerに登録するメールアドレスはGmailアドレスなどではなく自社ドメインのアドレスにするべきでしょう。

3種類のモジュールのユースケースをちゃんと考える

TeamViewerにはWeb会議機能を無視すると3種類のモジュールがあります。

Fullモジュール
Quick Supportモジュール
Hostモジュール

Fullモジュールとは検索エンジンでTeamViewerと検索すると画像でUIが出てくるアレで、管理者権限でインストールする必要があるアプリケーションです。

Quick Supportはユーザーサポート用、Hostモジュールは遠隔ホストへの無人アクセス用途です。

TeamViewerで端末を遠隔操作するとき、操作する側もされる側もFullモジュールを使うのでは、と考えがちですが、FullモジュールからFullモジュールへの遠隔接続をやらないのがベストプラクティスです。

ユーザーサポート用途なら、ユーザーからサポート担当のPCへ逆接続する必要はないはずですので、ユーザーPC側はFullモジュールではなくQuick Supportモジュールを使います。Fullモジュールを使う必要がないエンドユーザーは、企業プロファイルへのユーザー登録も不要です。

遠隔ホスト(PCやサーバー)への無人アクセスなら、サーバー上のTeamViewerを使って別の端末へ遠隔接続するなどということはないはずですので、接続を受けるサーバーにはFullモジュールではなくHostモジュールを使います。

Hostモジュールは管理者権限でインストールする受信専用モジュールで、Windowsのサービスとして常駐します。TeamViewerをサービスとしてインストールするなど危険そうに思えますが、そうではないということは後述します。

このように考えるとFullモジュールからFullモジュールへ遠隔接続するケースは極めて限られるはずです。Fullモジュールどうしの遠隔接続は可能な限りやめましょう。

どうしてもという場合の方法として、FullモジュールをインストールしているPCに、QSモジュールもダウンロードしておく手があります。

両者を同時に起動することはできませんが、接続を受ける間だけFullモジュールをいったん終了させてQSモジュールを起動、接続の受信が終わったらQSモジュールを終了させ、Fullモジュールを起動するという方法です。

2021/02/19 追記:

もう一つFullモジュールのインストール端末を最小限にする理由は、社外のTeamViewerへ遠隔接続できてしまうことで、さまざまなセキュリティリスクが考えられるためです。

また、エンドユーザーが勝手に自分のPCにFullモジュールをインストールしたり、ポータブル版のFullモジュールをダウンロードしたりするのを防ぐ方法ですが、TeamViewerは外向きの443番ポートが空いていれば利用可能なため、通常の企業のファイアウォール設定ではネットワーク的に防ぐ方法はありません。

Fullモジュールを許可した端末以外では、いわゆるIT資産管理ソフトでTeamViewer.exeをファイル名で起動抑止するか、ハッシュ値が登録できるウイルス対策ソフトやEDRでマルウェア扱いして検疫してしまう等の方法が考えられるかと思います。

(エンドユーザーに管理者権限を渡して自由にソフトウェアをインストールできるようにすると、セキュリティ的にはTeamViewer以前の問題になりますが…)

こうした管理を容易にするためにも、Fullモジュールのインストールを許可する端末は最小限にすべきです。

Fullモジュールをインストールする

管理コンソールに登録した各ユーザの端末にFullモジュールをインストールするときは、通常のFullモジュールをTeamViewer公式サイトからダウンロードした後、上記でTeamViewerユーザーとして登録済みのメールアドレスとパスワード、二要素認証のワンタイムパスワードでサインインします。

Fullモジュールを組織管理者に「割り当てる」

インストール後、Fullモジュールを組織管理者アカウントに「割り当てる」作業をします。

Fullモジュールのオプションでアカウント割り当てボタンをクリックし、組織管理者のメールアドレスとパスワード、二要素認証のワンタイムパスワードを入力すると、そのFullモジュールは組織内のものと認識されます。

組織内のモジュールと認識されると、オプションの「ブロックリストと許可リスト」の許可リストで組織名を選択できるようになります。

Fullモジュールを堅牢化する

Fullモジュールをオプションの各種設定項目で堅牢化します。Fullモジュールは接続を受信することがないはずというのがポイントです。

TeamViewerオプションの変更は管理者権限が必要とする
端末に管理者権限があるユーザしかTeamViewerの設定を変更できないようにし、インストール端末に物理的にアクセスされた場合のリスクを最小限にします。
このコンピュータとの詳細接続設定は「拒否」
上述のようにFullモジュールからFullモジュールへ接続することを想定していないため、「受信のリモートコントロールセッションの拒否」を選択します。これですべての受信を拒否するため、この設定だけで堅牢化は事実上終了です。なおこの設定をすると遠隔操作を受信するためのランダムパスワードは意味がなくなるため、Fullモジュール上に表示されなくなります。
ブロックリストと許可リスト
どうしてもFullモジュールからFullモジュールへの接続要件が残る場合、許可リストに必要最小限のユーザーだけを追加します。
ランダムパスワードはできるだけ複雑に
どうしてもFullモジュールからFullモジュールへの接続要件が残る場合、許可リストに入れたユーザーからはTeamViewer IDとランダムパスワードで接続を受信することになります。そのため、第三者からの不正アクセスリスクを低減すべく、パスワードはできるだけ複雑にします。TeamViewerで最も複雑な設定、英数字記号10文字、起動ごとにランダム生成にすると、口頭で伝えるのは運用上不可能と思われるため、やはりFullモジュールからFullモジュールへの遠隔接続はやるべきではありません。
自動的な新しいバージョンへのインストールは有効に。

Fullモジュールを管理コンソールから組織端末として登録する

インストールが終わったら、そのFullモジュールのTeamViewer ID(9～10ケタの数字)を管理コンソールからとして登録します。

セキュリティ上の意味はとくにありません。管理コンソール上でFullモジュールがインストールされている端末としてフォルダ別に管理できたり、起動中のFullモジュールは緑色で表示されるため、在席確認的に使えます。

カスタムQuick Supportモジュールを作成する

ユーザーサポート用途がなく、遠隔ホストへの無人アクセス用途のみの場合は、このセクションは読み飛ばしてください。

Quick Supportモジュール(以下QSモジュール)はサポートを受けるエンドユーザーのPCで使うモジュールです。インストールが不要で、単独で動作するEXEファイルです。起動している間だけ遠隔接続を受け入れ、常駐はできません。

かつ、QSモジュール側でサポートを受けるエンドユーザーが手動承認しない限り遠隔接続は成立しません。

ここで重要なのは、QSモジュールは公式サイトからダウンロードしたものを使ってはいけないということです。

TeamViewer公式サイトからダウンロードできる通常のQSモジュールと、企業プロファイル内で作成するカスタムQSモジュールは全く別物という点です。

通常のQSモジュールを起動するとTeamViewer IDとランダムパスワードが表示され、この2つが分かれば不特定多数のFullモジュールから遠隔接続できてしまいます。

他方、企業内のカスタムのQSモジュールを起動すると、セッションIDというものしか表示されず、同じ組織内のFullモジュールからしか接続できません。

~~(セッションIDはその名に反して、接続してセッションを張るたびに発行されるのではなく、その端末固定です)~~

逆に言えば、セッションIDさえ分り、相手が承諾しさえすれば、組織内では誰のQSモジュールへも接続できるため、組織内でアクセス制御したくなります。

2021/02/18 訂正:
(セッションIDはユーザーサポートを終えた後、サポート担当者が自分のFullモジュール上でクローズ処理をすると無効になり、使い捨てられます。つぎに同じエンドユーザーに対してサポートをするとき、エンドユーザーがQSモジュールを起動すると、新たなセッションIDがランダムに生成されます。そのためいったんクローズした古いセッションIDで、同じ端末に接続することはできません。いずれにせよ、接続を受ける側が承諾しない限り、接続は成立しないわけですが)

QSモジュールを拠点別にアクセス制御する

組織内でカスタムQSモジュールへの接続を制御したい場合、例えば以下のように拠点別にQSモジュールを作成します。

本社用QSモジュール
ニューヨーク支社用QSモジュール
シンガポール支社用QSモジュール

そして各QSモジュールに対応するフォルダを「本社QS」フォルダ、「ニューヨークQS」フォルダ、などと管理コンソールから作成し、各QSモジュールの属性にフォルダ名を指定して一対一で対応付けます。(Active DirectoryでOUの下にコンピュータオブジェクトがぶら下がっているイメージ)

これら「本社QS」や「ニューヨークQS」といったフォルダは、企業内のFullモジュールに自動的に一覧表示されます。

例えば、本社のエンドユーザーがサポートを受けたくて本社用QSモジュールを起動すると、サポート担当者のFullモジュールに表示されている「本社QS」フォルダ内に、そのQSモジュールのセッションID(またはそのPCにサインインしているユーザー名)がポコッと現れます。(組織内がWindowsドメイン構成ならユーザーの表示名が現れるはずです)

サポート担当者はそれをクリックし、相手が接続を受け入れれば遠隔サポートが始まります。サポートが終わってエンドユーザー側がQSモジュールを終了させると、「本社QS」フォルダからセッションIDが消えます。

これでどうやってアクセス制御をするのかというと、これらフォルダのアクセス権をFullモジュールのユーザーごとに設定してやります。

例えば、本社のユーザーサポート要員には「本社QS」「ニューヨークQS」など、全社のQSモジュールフォルダを見せる。一方、ニューヨーク支社のユーザーサポート要員には「ニューヨークQS」フォルダしか見せないなど、FullモジュールのそれぞれのユーザーにどのQSフォルダを見せるかによって、一定のアクセス制御ができます。

カスタムHostモジュールを作成する

次は無人アクセス用途のHostモジュールについてです。

Hostモジュールも企業プロファイル内でカスタムモジュールを作成しますが、QSモジュール同様、拠点別、サーバー群別など、アクセス制御したい単位で複数のカスタムモジュールを作成できます。

QSモジュールと違って、Hostモジュールに特有なのはポリシーによるセキュリティ設定です。

ポリシーを作成する

ポリシーとはFullモジュールにあるオプションの設定一式です。HostモジュールにもFullモジュールのオプションメニューから設定できるのとほぼ同じ設定項目があります。

サーバーに管理者権限でHostモジュールをインストールした後、オプションメニューから手動で一つひとつ設定することもできますが、それを自動設定し、変更できないようにロックするのがポリシーの利用法です。

本社Hostモジュール用ポリシー、ニューヨーク拠点Hostモジュール用ポリシーなどという具合にポリシーを作成し、各Hostモジュールのポリシー属性にそれぞれのポリシー名を指定します。

すると、サーバーにHostモジュールをインストール後、組織管理者アカウントに「割り当て」をした瞬間、ポリシーの内容に沿ってすべてのオプションが自動的に設定され、かつ、ロックされます。

(もちろんTeamViewer以外の方法でサーバーに管理者権限で接続できれば、Hostモジュールの設定変更どころか再インストールもできるため、TeamViewerでしかサーバーにアクセスできない場面が前提)

ポリシーの内容を設定する

Hostモジュールの堅牢化の考え方はFullモジュールとはかなり異なります。

上述のようにFullモジュールは原則として接続を受信することはありませんが、Hostモジュールは接続を受信しないと意味がありません。

またWindows環境の場合、Hostモジュールへの接続にはWindowsアカウントとそのパスワードを利用し、TeamViewer IDとTeamViewerパスワードは使わないのが基本です。TeamViewerのアクセス制御機能を使わず、Windows認証でHostモジュールに遠隔接続するということです。

するとポリシーの内容は以下のような設定になるはずです。

個人的なパスワードと簡易アクセスは利用しない
Hostモジュールは無人アクセス用途ですが、Windows認証を使う前提のため個人的なパスワードによる簡易アクセスはセキュリティレベルが低いため利用しません。
ブロックリストと許可リスト
そのマシンに接続する最低限のユーザーだけを許可リストに設定します。本社Hostモジュール用ポリシーなら本社要員、ニューヨーク拠点Hostモジュール用ポリシーなら現地要員などの使い方ができます。
ランダムパスワードは「非常に安全」
Hostモジュールへの接続はTeamViewer IDとランダムパスワードは使わずWindows認証を使いますが、HostモジュールはFullモジュールのような受信完全拒否の設定ができないため、ランダムパスワードが有効化されてしまいます。したがって最高の複雑性、つまり英数字記号10文字にしておきます。このパスワードはHostモジュールを起動するたびにランダムに生成されます。

第三者が不正アクセスをする場合、許可リストにあるTeamViewerアカウントに二要素認証を突破して不正アクセスでなりすまし、かつ、HostモジュールのTeamViewer ID (9～10桁の数字)と英数字記号10文字のパスワードの両方にブルートフォースを成功させる必要があります。事実上不可能と考えてよいと思います。

Hostモジュールの利用方法

セキュリティの話とは無関係ですが、TeamViewerのHostモジュールを利用したことがある方は少ないと思われるため、Fullモジュールからどうやって遠隔のマシンのHostモジュールへ接続するのかを説明します。

まずFullモジュールを開くと、QSモジュール同様、各フォルダの中にぶら下がった形で各サーバーが見えます。管理コンソールで各サーバー(Hostモジュール)を、例えば拠点別フォルダにきれいに整理していることが前提ですが。

接続したいサーバーをダブルクリックすると認証ダイアログが表示され、TeamViewerパスワードの入力を求められます。ですがTeamViewerの認証は使いません。ここで認証方式をWindows認証に切りかえます。

するとWindowsドメイン名修飾のWindowsアカウント名と、Windowsパスワードの入力欄に切り替わり、リモートデスクトップでWindowsサーバーに接続するのと同じように、Windowsアカウントで接続できます。

TeamViewerで接続先サーバーの画面が開くと、接続先サーバーのWindowsサインイン画面が表示され、そこから改めてWindowsアカウントでサーバーにサインインすることになります。ここで別のWindowsアカウントを使ってサインインすることもできます。

TeamViewerでの接続はサーバーのコンソールの前に座るのと同じイメージで、実際にサーバーにサインインするのはそれから、ということです。

あとがき

ここで力尽きました。

まだ見落としがたくさんある気がしますが、とにかくTeamViewerは企業プロファイルの機能をフルに使わないかぎり、まともなセキュリティ設定はできません。

言いたかったのは、ほぼそれだけです。

(見落としに気づけば随時加筆すると思います。ご容赦ください)