「障害が起きたとき、保守会社が遠隔で対応してくれる」
「毎月の更新作業は、IT事業者に任せている」
「パソコンへ保守用ソフトを入れているが、製品名までは分からない」
このような会社は少なくありません。
遠隔保守は、担当者が現地へ移動しなくても、パソコンやサーバーの状態確認、設定変更、ソフトウェア更新、障害対応を行える便利な仕組みです。特に、専任の情報システム担当者がいない中小企業では、遠隔保守を使わずに日常のIT運用を維持することが難しい場合もあります。
一方で、遠隔保守のためのアカウントやツールが攻撃者に悪用されると、「本来は保守会社が会社を助けるための入口」が、「攻撃者が会社の端末へ入るための入口」に変わります。
問題は、遠隔保守を使うこと自体ではありません。
会社が、次の質問に答えられない状態で使い続けることです。
- どの遠隔保守ツールが入っているのか
- 誰がそのツールを管理しているのか
- どの端末へ接続できるのか
- どの保守担当者が接続できるのか
- いつ接続したのか
- 接続中に何を行ったのか
- 契約終了後にアクセス権を削除したのか
- 異常時に自社側で接続を止められるのか
本記事では、遠隔保守・RMMツールを継続して利用しながら、委託先の接続時間、利用者、権限、操作、ログを管理するための実務手順を解説します。
遠隔保守とRMMは同じものではない
遠隔保守に使われる仕組みには、複数の種類があります。
| 種類 | 主な使い方 | 主な特徴 |
|---|---|---|
| オンデマンド型リモートサポート | 利用者が画面に表示された番号等を保守担当者へ伝える | その都度、利用者が接続を開始する |
| 承認型の遠隔操作 | 保守担当者からの接続要求を利用者が許可する | 利用者が目の前にいることを前提としやすい |
| 無人接続型の遠隔操作 | 端末へ常駐ソフトを入れ、利用者が不在でも接続する | サーバーや夜間保守で使われることがある |
| RMM | 端末の監視、ソフトウェア配布、スクリプト実行、遠隔操作等を一元管理する | 多数の端末を継続的に管理できる |
| VPN・リモートアクセス装置 | 外部から社内ネットワークへ接続する経路を作る | 接続後に何ができるかは別の権限設定による |
RMMは、Remote Monitoring and Managementの略です。
CISAはRMMについて、端末へ導入して状態を継続的に監視するとともに、無人での遠隔管理機能を提供するソフトウェアと説明しています。RMMの管理基盤が侵害された場合、管理対象となっている複数の顧客や端末へ影響が広がる危険があります。なりますが、製品によっては次の操作が可能です。
- 画面の閲覧・遠隔操作
- ファイルの送受信
- クリップボードの共有
- コマンドやスクリプトの実行
- ソフトウェアの導入・削除
- サービスや端末の再起動
- 端末の状態監視
- 更新プログラムの配布
- 複数端末への一括処理
例えばSimpleHelpは、遠隔操作、無人接続、端末監視、スクリプト、自動保守、ファイル転送などの機能を提供しています。同時に、時間制限、権限設定、操作履歴、多要素認証、接続元制限などの管理機能も用意しています。面を見るソフト」ではありません。
製品や設定によっては、管理者に近い操作を多数の端末へ実行できる仕組みです。
VPNの記事と今回の記事は何が違うのか
ライトハウスコンサルタントでは、これまで医療機関を対象として、保守用VPNやリモート接続の点検項目、都度接続、多要素認証、ベンダー契約について解説してきました。トワークへ入るための「経路」です。
RMMは、端末を監視し、遠隔操作や設定変更を行うための「管理機能」です。
VPNを停止していても、クラウド型RMMのエージェントが外部の管理基盤へ接続していれば、保守担当者が遠隔操作できる構成があります。反対に、VPNへ接続できても、対象システムへの権限がなければ操作できない構成もあります。
したがって、今回確認するのは、VPN装置の設定だけではありません。
- 端末に入っているRMMエージェント
- RMMの管理者アカウント
- 委託先の技術者アカウント
- RMM管理基盤の契約者
- 遠隔操作で使える機能
- 操作履歴と保管場所
- 契約終了時の削除方法
これらを一つの仕組みとして管理します。
2026年夏に確認されたRMMの重大な脆弱性
SimpleHelpでは技術者権限を取得される脆弱性が悪用された
2026年6月、RMM製品SimpleHelpの認証処理に関する脆弱性、CVE-2026-48558が公表されました。
対象はSimpleHelp 5.5.15以前、および6.0のRC2より前のプレリリース版です。ただし、影響を受けるのは、対象バージョンでOpenID Connectを使用するなど、一定の構成条件を満たす環境です。
脆弱な環境では、外部の未認証者が偽造した認証情報を送信し、正規の技術者として認証される可能性があります。構成によっては、多要素認証も回避される可能性があると説明されています。版として、5.5系には5.5.16、6.0系にはRC2を公開し、利用者へ更新を求めました。年6月29日、この脆弱性を「実際の攻撃で悪用されたことが確認された脆弱性」として、Known Exploited Vulnerabilities Catalogへ追加しました。てのSimpleHelp利用者が侵害されたわけではないことです。
対象バージョン、認証方式、外部公開状況などを確認しなければ、個別環境が影響を受けたかは判断できません。
一方で、自社が使っている遠隔保守製品名やバージョンを把握していなければ、脆弱性情報が公表されても、自社が対象かどうか確認できません。
BeyondTrustでも認証前の脆弱性が公表された
2026年7月6日には、BeyondTrust Remote SupportおよびPrivileged Remote Accessに関するCVE-2026-40139が公開されました。
NVDの説明では、特定の認証構成が有効な場合、未認証の外部者がアクセス制御を回避し、高い権限を持つアカウントを含む装置上のアカウントへ不正にアクセスできる可能性があるとされています。treは、Remote SupportおよびPrivileged Remote Accessの25.3.2以前を対象として、利用者へ公式情報の確認と更新を推奨しました。者がすべて侵害されたことを意味しません。
重要なのは、遠隔保守製品自体もソフトウェアであり、通常のOSやサーバーと同様に、バージョン管理と脆弱性対応が必要だということです。
「正規のツールだから安全」とは限らない
RMMには、次の二つの異なる危険があります。
一つ目は、RMM製品や管理サーバーの脆弱性、管理アカウントの侵害などによって、正規の仕組みそのものが乗っ取られる危険です。
二つ目は、攻撃者が正規のRMM製品を、会社へ無断で導入する危険です。
Kasperskyは2026年7月2日、正規ソフトウェアを装った偽サイトから、ScreenConnectを使う遠隔操作機能が導入される攻撃キャンペーンを報告しました。調査では、著名ソフトウェアの公式サイトを模倣する90以上のドメインが確認され、検索結果を悪用して偽サイトへ誘導する手法が使われていました。2026年3月、会議招待や請求書、業務通知などを装ったメールから偽のTeams、Zoom、Adobe Reader等をダウンロードさせ、ScreenConnect、Tactical RMM、Mesh Agentなどを導入する攻撃を報告しています。ファイルが電子署名されていた事例も確認されました。般に使われている製品である」「ウイルス対策ソフトが直ちに警告しなかった」という理由だけで、会社が許可したソフトウェアとは判断できません。
会社が承認したRMMと、攻撃者が導入したRMMを区別できるようにする必要があります。
RMMに関係する四つの侵入経路
| 侵入経路 | 例 | 主な対策 |
|---|---|---|
| 製品の脆弱性 | RMMサーバーや認証機能の脆弱性を悪用される | バージョン管理、迅速な更新、外部公開制限 |
| 保守会社のアカウント侵害 | 技術者IDや管理者IDを盗まれる | 個人別ID、MFA、端末・接続元制限 |
| 無許可RMMの導入 | 偽ソフトやフィッシングから正規RMMを導入される | 許可リスト、ソフトウェア台帳、実行制御 |
| 過剰な正規権限 | 保守会社が必要以上の端末や機能へアクセスできる | 最小権限、対象限定、接続時間制限 |
CISA、NSA、MS-ISACは、正規のRMMソフトウェアが攻撃に悪用されると、一般的なウイルス対策を回避しながら遠隔操作へ使われる可能性があるとして、導入済み遠隔操作ツールの監査、無許可RMMの実行制御、承認済みの接続経路の使用などを推奨しています。品名ではなく「管理の全体像」
遠隔保守製品の比較表を見る前に、現在の運用を把握します。
保守会社へ、少なくとも次の事項を質問してください。
- 使用している遠隔保守・RMM製品の正式名称
- 現在使用しているバージョン
- 端末へ導入されるサービス名、プロセス名、エージェント名
- 管理サーバーを運用している組織
- RMMの契約者・テナント所有者
- 接続できる保守担当者の人数
- 自社専用の技術者アカウントか、他社と共通のアカウントか
- 接続可能な端末・サーバーの範囲
- 遠隔操作で使用できる機能
- 多要素認証の有無
- 接続元の端末や場所を制限しているか
- 操作ログを誰が保管しているか
- 異常時に自社側で接続を止められるか
- 契約終了時にエージェントを誰が削除するか
- 再委託先の技術者も接続できるか
「セキュリティ上の理由により詳細は回答できません」という回答だけでは、自社の委託先管理として十分とはいえません。
攻撃方法や内部構成のすべてを開示してもらう必要はありませんが、自社へ誰が、どの仕組みで、どの範囲まで接続できるのかは確認する必要があります。
遠隔保守ツール台帳を作る
確認した結果は、遠隔保守ツール台帳へ記録します。
遠隔保守ツール台帳の記載例
| 項目 | 記録する内容 |
|---|---|
| ツール名 | 製品・サービスの正式名称 |
| 用途 | 障害対応、更新、監視、問い合わせ対応など |
| 管理事業者 | 保守会社、クラウド事業者、自社 |
| テナント所有者 | RMM環境を契約・管理している組織 |
| 対象端末 | パソコン、サーバー、ネットワーク機器等 |
| エージェント名 | サービス名、プロセス名、表示名 |
| 接続方式 | 都度接続、利用者承認、常時接続 |
| 保守担当者 | 氏名または個人別ID |
| 認証 | パスワード、MFA、端末認証等 |
| 接続元制限 | IPアドレス、会社端末、国・地域等 |
| 権限 | 一般利用者、ローカル管理者、システム管理者 |
| 許可機能 | 画面操作、ファイル転送、スクリプト等 |
| 利用可能時間 | 営業時間、保守時間帯、緊急時のみ等 |
| ログ | 取得項目、保存先、保存期間 |
| バージョン | 管理サーバー、エージェントのバージョン |
| 更新責任者 | 自社または委託先の担当者 |
| 契約終了日 | 保守契約の終了予定日 |
| 停止方法 | 緊急時に外部接続を止める方法 |
| 最終確認日 | 設定・アカウント・ログを確認した日 |
すべてを自社で技術的に確認できない場合は、保守会社から回答書や設定画面の写し、管理レポートを提出してもらいます。
重要なのは、自社でツールを操作できることではなく、自社へつながる仕組みを説明できることです。
接続方式を三段階に分ける
すべての端末へ、常時無人接続を許可する必要はありません。
業務の必要性に応じて、次の三段階に分けます。
| 接続方式 | 主な対象 | 運用例 |
|---|---|---|
| 利用者承認型 | 一般従業員のパソコン | 利用者が接続要求を確認して許可する |
| 計画作業型 | 業務サーバー、ネットワーク機器 | 作業票で時間と対象を指定し、一時的に接続を有効化する |
| 常時無人接続型 | 24時間監視が必要なサーバー等 | 対象、担当者、機能、ログを厳格に限定する |
「いつ障害が起きるか分からないから、すべて常時接続にする」という説明だけでは不十分です。
緊急時に接続を有効化する担当者を決める方法や、監視機能だけを常時有効にして遠隔操作は都度承認にする方法もあります。
ただし、利用できる方式は製品や保守契約によって異なります。現在のツールが、接続時間制限、承認、対象限定に対応しているかを確認してください。
手順1 保守担当者は個人別アカウントにする
保守会社用の共通IDを複数人で使っていると、操作ログにIDが残っても、実際に誰が接続したのか分かりません。
原則として、保守担当者ごとに個人別アカウントを発行します。
アカウント管理で確認する項目
- 保守担当者ごとに個人別IDがある
- 共通パスワードを複数人で使っていない
- 管理者権限を持つ人を限定している
- 多要素認証を有効にしている
- 担当変更や退職時に直ちに停止する
- 一定期間使っていないIDを停止する
- 再委託先の担当者を区別できる
- 自社ごとにアクセス範囲を分離している
- 緊急用IDの利用を記録している
- アカウントの最終確認日を記録している
多要素認証を有効にしていても、それだけですべてのリスクがなくなるわけではありません。
SimpleHelpの事例では、脆弱な認証構成において、偽造した認証情報から技術者セッションを取得し、構成によっては多要素認証も回避される可能性がありました。製品の更新、接続元制限、アカウント監査、ログ確認を組み合わせます。
手順2 通常作業と管理者作業を分ける
日常的な状態確認に、常に最高権限を使用する必要はありません。
次のように権限を分けます。
| 作業 | 権限の例 |
|---|---|
| 端末の稼働状態確認 | 閲覧・監視のみ |
| 利用者への操作案内 | 画面共有・遠隔操作 |
| ログの収集 | 指定フォルダ・指定機能のみ |
| ソフトウェア更新 | 対象端末への更新権限 |
| OSやサービスの設定変更 | 一時的な管理者権限 |
| アカウント・認証基盤の変更 | 別途承認した高権限ID |
| バックアップ削除・初期化 | 二重確認を伴う限定権限 |
RMM上の技術者権限と、接続先端末の管理者権限も分けて考えます。
RMMへログインできることと、接続先ですべての管理操作ができることを同じ権限にすると、一つのアカウント侵害による影響が大きくなります。
本稿では、通常作業では標準権限を使用し、管理者権限が必要な作業だけ、対象と時間を限定して昇格させる運用を推奨します。
手順3 使用できる機能を限定する
遠隔操作が必要だからといって、すべての機能を許可する必要はありません。
| 機能 | 主な危険 | 運用例 |
|---|---|---|
| 画面の遠隔操作 | 利用者になり代わって操作される | 対象端末と時間を限定 |
| ファイル転送 | 情報の持ち出し、マルウェア搬入 | 原則停止し、必要時だけ許可 |
| クリップボード共有 | パスワードや機密文書のコピー | 業務上不要なら無効化 |
| コマンド実行 | 設定変更、ツール導入 | 管理者作業として承認 |
| スクリプト一括実行 | 多数端末への影響 | 検証済みスクリプトだけ使用 |
| ソフトウェア配布 | 無許可ソフトの導入 | 配布物とハッシュ等を記録 |
| 再起動・停止 | 業務中断 | 実施時間と連絡先を指定 |
| アカウント作成 | 不正な永続アクセス | 原則として別途承認 |
| ログ削除 | 調査不能になる | 保守担当者による削除を制限 |
ファイル転送やスクリプト実行は、保守業務に必要な場合があります。
その場合でも、「必要だから常時許可」ではなく、「どの作業で、誰が、何を扱ったか」を記録します。
手順4 接続時間と対象を作業票で指定する
保守作業を始める前に、作業票またはチケットを作成します。
遠隔保守作業票の項目
- 受付番号
- 依頼部署
- 対象端末・システム
- 障害または作業の内容
- 保守会社名
- 実際に接続する技術者
- 接続開始予定時刻
- 接続終了予定時刻
- 使用するRMMツール
- 使用するアカウント
- 必要な権限
- 使用する機能
- ファイル転送の有無
- 再起動・停止の有無
- 作業前バックアップの要否
- 自社側の立会者・連絡先
- 承認者
- 作業結果
- 実際の終了時刻
- ログ確認者
すべての問い合わせで、複雑な申請書を作る必要はありません。
一般従業員のパソコンに対する軽微なサポートでは、チケット番号、対象端末、技術者、開始・終了時刻、利用者承認だけでもよいでしょう。
一方、次のシステムでは、より厳格な承認が必要です。
- 会計・給与システム
- 顧客情報を大量に保存するシステム
- 認証基盤・ドメイン管理
- バックアップ管理
- ネットワーク機器
- セキュリティ製品
- 製造・制御システム
- Webサイトやクラウドの管理者画面
重要度に応じて、手続きを分けます。
手順5 接続元の端末と場所を制限する
保守会社の担当者が、どの端末からでもRMMへログインできる状態は避けるべきです。
製品が対応している場合は、次の制限を検討します。
- 保守会社が管理する業務端末だけに限定する
- 個人所有端末からの接続を禁止する
- 端末証明書や端末登録を使用する
- 接続元IPアドレスを制限する
- 許可した国・地域以外からの接続を拒否する
- 承認済みVPNやVDIを経由させる
- 管理者画面をインターネットへ直接公開しない
- 技術者用画面と一般利用者用画面を分離する
NSA、CISA、MS-ISACは、承認されたRMMだけを、VPNやVDIなどの承認済み遠隔接続経路から使用することや、無許可RMMの通信を制限することを推奨しています。は固定IP制限に対応していない場合や、エージェントが外部へHTTPS通信を行う構成もあります。
一つの方法だけを必須とせず、端末認証、MFA、時間制限、ログ監視など、利用可能な対策を組み合わせます。
手順6 ログは「保守会社が持っている」で終わらせない
遠隔保守のログには、少なくとも次の情報が必要です。
| ログ項目 | 確認する内容 |
|---|---|
| 認証 | 誰が、いつ、どの認証方法でログインしたか |
| 接続元 | IPアドレス、端末、場所等 |
| 接続先 | どの端末・サーバーへ接続したか |
| 開始・終了 | セッションの開始時刻と終了時刻 |
| 権限 | 使用した役割、権限変更 |
| ファイル転送 | ファイル名、方向、実施者 |
| スクリプト・コマンド | 実行内容、対象、結果 |
| ソフトウェア配布 | 配布物、対象端末、結果 |
| 再起動・停止 | 実行者、対象、時刻 |
| アカウント変更 | 技術者IDの追加・削除、権限変更 |
| 設定変更 | ログ、MFA、接続制限等の変更 |
| 一括操作 | 複数端末を対象とした作業 |
ログの保存期間に、すべての会社へ共通する一律の期間があるわけではありません。
契約、業界ガイドライン、取引先要求、事故の発見までに想定される期間、ログ容量を踏まえて決めます。
重要なのは、次の点です。
- 自社が必要なときにログを取得できる
- 保守会社だけがログを削除できる状態にしない
- 契約終了後も必要なログを受け取れる
- タイムゾーンや端末名を識別できる
- 作業票と実際のログを照合できる
- 異常を見つけたときに原本を保全できる
CISAのランサムウェア対策ガイドは、ネットワーク上の遠隔操作ツールを監査し、RMMの実行ログや通常とは異なる利用、インストールされずに実行される可搬型RMMなどを確認するよう推奨しています。グ
次の操作は、必ずしも攻撃とは限りません。
しかし、通常の保守作業と異なる場合は、確認が必要です。
- 深夜・休日の接続
- 承認された時間外の接続
- 見覚えのない技術者IDの追加
- 技術者IDの管理者昇格
- MFA設定の変更・無効化
- 新しい接続元端末からのログイン
- 海外等、通常とは異なる接続元
- 多数端末への一括スクリプト実行
- セキュリティソフトの停止
- バックアップ関連サービスの停止
- 大量のファイル転送
- 新しいRMMエージェントの配布
- ログ設定や保存期間の変更
- 通常使わないコマンドシェルの実行
- 作業票が存在しないセッション
すべてのログを毎日、人が一件ずつ確認する必要はありません。
自社にとって重要な異常条件を決め、該当した場合に通知する方法や、月次で例外だけ確認する方法があります。
手順7 RMM製品自体の更新責任を決める
「保守会社が使う道具だから、更新も保守会社が行うはず」と考えてはいけません。
契約前に、次の責任を決めます。
| 確認事項 | 決める内容 |
|---|---|
| 脆弱性情報の収集 | 誰が製品情報や注意喚起を確認するか |
| 対象判定 | 自社環境が対象か誰が調べるか |
| 緊急連絡 | 重大な脆弱性を誰へ知らせるか |
| 更新作業 | 管理サーバーとエージェントを誰が更新するか |
| 事前検証 | 更新による業務影響をどこで確認するか |
| 適用期限 | 緊急度に応じていつまでに対応するか |
| 代替策 | 更新できない場合に何を停止・制限するか |
| 侵害確認 | 更新前に悪用されていないか誰が調査するか |
| 完了報告 | バージョンと適用結果を誰へ報告するか |
SimpleHelpの脆弱性では、製品提供者が対象バージョンと修正版を案内し、利用者へ更新を求めました。利用企業側で製品名とバージョンを把握していなければ、その案内を自社の対応へ結び付けられません。更新される製品でも、「自動だから確認不要」ではありません。
サービス事業者からのセキュリティ通知を誰が受け取り、影響確認やログ調査が必要かを判断する担当者を決めます。
委託先確認票へ入れたい15項目
「適切なセキュリティ対策を行うこと」という一文だけでは、実際の運用は決まりません。
契約書、仕様書、委託先確認票、作業手順書などへ、少なくとも次の内容を反映します。
| 項目 | 確認・合意する内容 |
|---|---|
| 1. 使用ツール | 正式名称、提供方式、バージョン |
| 2. 利用目的 | 障害対応、監視、更新など |
| 3. 接続対象 | 対象端末、システム、ネットワーク |
| 4. 接続方式 | 都度承認、計画接続、常時無人接続 |
| 5. 利用者 | 個人別技術者ID、再委託先 |
| 6. 認証 | MFA、端末認証、パスワード方針 |
| 7. 接続元 | 会社端末、場所、IPアドレス等 |
| 8. 接続時間 | 通常時間、計画作業、緊急時 |
| 9. 権限 | 閲覧、操作、管理者権限 |
| 10. 許可機能 | ファイル転送、スクリプト、再起動等 |
| 11. ログ | 取得項目、保存先、保存期間、提供方法 |
| 12. 更新 | 脆弱性情報、更新責任、緊急対応 |
| 13. 事故連絡 | 連絡先、第一報の条件、提供情報 |
| 14. 契約終了 | ID停止、エージェント削除、ログ引渡し |
| 15. 緊急停止 | 自社から接続を遮断する手順 |
IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」は、中小企業が取引先や外部情報サービスを含めて対策を進めることを想定し、規程、資産台帳、インシデント対応手引きなどの付録を提供しています。ではなく、RMMの特性を踏まえた本稿の実務提案です。
自社の業種、扱う情報、契約、取引先要求に応じて調整してください。
遠隔保守の開始前・作業中・終了後を分ける
接続前
- 障害・作業内容を記録する
- 対象端末を特定する
- 実際に接続する技術者を確認する
- 接続時間を決める
- 使用する権限と機能を決める
- ファイル転送や再起動の有無を確認する
- 必要に応じてバックアップや復旧方法を確認する
- 自社側の連絡担当者を決める
- 承認番号またはチケット番号を発行する
作業中
- 接続開始を自社担当者へ通知する
- 計画した端末以外へ接続しない
- 計画にない操作が必要になった場合は再確認する
- 機密情報を不要に閲覧・取得しない
- ファイル転送やコマンド実行を記録する
- 重要システムでは自社担当者が進行を確認する
- 異常が見つかった場合は作業を中断し、連絡する
作業後
- 遠隔セッションを終了する
- 一時的な管理者権限を解除する
- 一時アカウントを停止する
- 作業内容と変更点を報告する
- 再起動・動作確認の結果を記録する
- 作業票とRMMログを照合する
- 次回作業や残課題を記録する
- 必要に応じて資産台帳や構成図を更新する
「作業完了しました」というメールだけでは、何を変更したのか分からない場合があります。
作業報告には、対象、作業者、開始・終了時刻、実施内容、変更内容、転送ファイル、再起動、確認結果を含めます。
緊急時の例外ルールを先に決める
障害時に、通常の申請手続をすべて完了するまで待てない場合があります。
そのため、緊急時の例外ルールを平時に決めます。
緊急接続ルールの例
- 緊急接続を認める事象を定義する
- 承認できる責任者を複数名決める
- 電話等による口頭承認を認める条件を決める
- 口頭承認でも、対象、技術者、時刻を記録する
- 緊急用アカウントは使用後に停止または認証情報を変更する
- 接続可能な端末と機能を必要最小限にする
- 作業終了後にログを保全する
- 事後確認を行う期限を決める
- 例外が繰り返される場合は通常手順を見直す
例えば、「翌営業日までに作業票を完成させ、ログと照合する」というルールが考えられます。
これは法令上の一律期限ではなく、事後確認を放置しないための運用例です。
契約終了時はアカウント削除だけでは足りない
保守会社を変更したとき、前の会社の担当者アカウントを停止しても、端末にRMMエージェントが残っていることがあります。
契約終了時には、次の項目を確認します。
- 保守担当者アカウントの停止
- RMM管理者アカウントの停止
- APIキーやアクセストークンの失効
- 端末証明書の失効
- RMMエージェントの削除
- 自動起動サービスの削除
- タスクスケジューラ等の設定削除
- VPNアカウントの削除
- ファイアウォールの許可設定削除
- 接続元IPアドレスの許可解除
- クラウドのゲストアカウント削除
- 共有フォルダ権限の削除
- 保守用ローカルアカウントの削除
- ログと作業記録の引渡し
- 自社情報の返却・消去
- 再委託先を含むアクセス停止確認
「アンインストールしました」という回答だけでなく、台帳上の対象台数と削除済み台数が一致しているかを確認します。
一部端末について、サービス名、プロセス、インストール済みソフトウェア、通信先を自社または新しい保守会社が確認すると、削除漏れを見つけやすくなります。
見覚えのないRMMを発見した場合
知らない遠隔操作ツールが見つかった場合、直ちにすべて削除すると、調査に必要な情報まで失う可能性があります。
一方で、実際に不正操作が進行している場合は、証拠保存より被害拡大の停止を優先しなければならないこともあります。
最初に記録する情報
- 製品名・表示名
- バージョン
- サービス名・プロセス名
- インストール日時
- インストールした利用者
- 接続先ドメイン・IPアドレス
- 端末識別番号
- RMM上の組織名・テナント名
- 最終接続日時
- ログや設定画面
- ファイルの保存場所
- デジタル署名
- 対象端末
- 表示された警告や異常
初動の例
- 不正操作が進行中なら対象端末をネットワークから隔離する
- RMMセッションを停止する
- 管理サーバーやテナントを特定する
- 不明な技術者アカウントを停止する
- 既存セッションやトークンを失効させる
- 同じRMMが他の端末にもないか調べる
- ファイル転送、コマンド、スクリプトの履歴を確認する
- 管理者パスワードや認証情報の利用状況を確認する
- 必要な認証情報を変更する
- 保守会社へ、従来から確認済みの連絡先を使って確認する
- 情報へのアクセスや持ち出しの可能性を調べる
- 対応の時系列を記録する
攻撃者がRMMを使っている場合、RMMのチャットや画面上に表示された連絡先を信用してはいけません。
契約書、過去のメール、取引先台帳など、事前に確認済みの連絡先を使用します。
CISAのランサムウェア対策ガイドも、予期しないRMMの利用を侵害の兆候として確認し、関連するシステムやアカウントを特定・封じ込めるよう案内しています。た場合の連絡内容
保守会社から「当社で不正アクセスが発生しました」と連絡を受けた場合、次の内容を確認します。
| 確認項目 | 内容 |
|---|---|
| 発覚日時 | 保守会社が異常を把握した日時 |
| 発生期間 | 不正アクセスが継続した可能性のある期間 |
| 対象 | 自社用テナント、技術者ID、管理サーバー等 |
| 侵害アカウント | どの担当者・管理者アカウントか |
| 接続履歴 | 自社端末へ接続した履歴があるか |
| 操作内容 | ファイル転送、コマンド、スクリプト等 |
| 対象端末 | 接続された可能性のある端末一覧 |
| 認証情報 | パスワード、トークン、証明書等への影響 |
| 現在の措置 | アカウント停止、更新、隔離等 |
| 証拠 | ログ、時系列、調査報告書 |
| 継続対応 | 次回報告日、問い合わせ窓口 |
「現在調査中」という段階でも、第一報は必要です。
すべての事実が確定するまで連絡しない契約では、自社側の封じ込めやログ保全が遅れます。
契約では、少なくとも次のどちらかが発生した場合に、速やかに第一報を行うよう定めます。
- 自社へ影響することが確認された
- 自社へ影響する可能性を否定できない
具体的な報告時間は、業種、契約、情報の重要度、24時間連絡体制の有無に応じて決めてください。
月1回確認したいRMM管理の数字
以下は、本稿で提案する月次確認の例です。
| 指標 | 確認する意味 | 目指す状態 |
|---|---|---|
| 承認済みRMM製品数 | 使用ツールを把握できているか | 台帳と実態が一致 |
| RMM導入端末数 | 対象端末を把握できているか | 管理対象と一致 |
| 所有者不明のRMM数 | 誰が入れたか分からないツールがないか | 0 |
| 利用目的不明のエージェント数 | 不要な常駐接続がないか | 0 |
| 共有技術者ID数 | 操作者を特定できるか | 原則0 |
| MFA未設定ID数 | 認証対策が不足していないか | 0 |
| 不要な管理者ID数 | 過剰権限が残っていないか | 0 |
| 時間外接続数 | 作業票と異なる接続がないか | すべて理由を確認 |
| 作業票なし接続数 | 無断接続がないか | 0 |
| ログ取得失敗数 | 調査できない期間がないか | 0 |
| 更新期限超過数 | 脆弱な版が残っていないか | 0 |
| 契約終了後の残存エージェント数 | 古い保守経路が残っていないか | 0 |
| 未確認の緊急接続数 | 例外対応が放置されていないか | 0 |
月1回という頻度は、すべての会社に一律に求められる法的義務ではありません。
重要システムでは、接続の都度確認した方がよい場合があります。反対に、利用頻度の低い一般端末では、四半期単位の全体棚卸しと月次の差分確認を組み合わせる方法もあります。
30日で遠隔保守の管理を整える
| 期間 | 実施すること | 完成させるもの |
|---|---|---|
| 第1週 | 保守会社と社内端末を調査し、使用中のRMMを洗い出す | 遠隔保守ツール台帳の初版 |
| 第1週 | RMM管理者、テナント所有者、緊急停止方法を確認する | 管理責任者一覧 |
| 第2週 | 技術者ID、MFA、権限、接続対象を確認する | 技術者アカウント一覧 |
| 第2週 | 不要なエージェント、ID、権限を停止する | 削除・停止記録 |
| 第3週 | 作業票、承認、接続開始・終了の流れを試す | 遠隔保守作業票 |
| 第3週 | ファイル転送、スクリプト、管理者権限を限定する | 権限・機能一覧 |
| 第4週 | ログを取得し、作業票と照合する | ログ確認記録 |
| 第4週 | 保守会社の侵害を想定した机上確認を行う | 緊急停止・連絡手順 |
最初から新しいRMM製品へ入れ替える必要はありません。
まず、現在使っている仕組みについて、次の状態を作ります。
- 製品名と管理者が分かる
- 対象端末が分かる
- 接続する技術者を特定できる
- 多要素認証が設定されている
- 必要以上の権限がない
- 接続日時と操作を確認できる
- 契約終了時に削除できる
- 異常時に自社側で停止できる
そのうえで、現在の製品では必要な管理ができない場合に、設定変更や製品変更を検討します。
経営者が確認したい五つの質問
経営者がRMMの技術的な設定画面を見る必要はありません。
担当者や保守会社へ、次の五つを質問してください。
- 自社へ遠隔接続できるツールをすべて一覧にできるか
- 保守会社の誰が、どの端末へ接続できるか説明できるか
- 最後に技術者アカウントと権限を確認したのはいつか
- 接続日時、操作内容、ファイル転送の記録を自社で取得できるか
- 保守会社で事故が起きたとき、自社側だけで接続を止められるか
この五つに答えられないからといって、直ちに不正アクセスが発生しているとは限りません。
しかし、会社として遠隔保守経路を管理できていない可能性があります。
まとめ
遠隔保守・RMMツールは、中小企業のIT運用を支える有効な仕組みです。
問題は、ツールを導入したことではなく、次の状態で放置することです。
- 製品名が分からない
- 管理者が分からない
- 誰が接続できるか分からない
- すべての端末へ常時接続できる
- 共有IDを複数人で使っている
- 管理者権限を常時付与している
- ファイル転送やスクリプト実行を制限していない
- ログを自社で取得できない
- 製品のバージョンを把握していない
- 契約終了後もエージェントが残っている
遠隔保守を安全に使うために必要なのは、「信頼できる保守会社だから任せる」という判断だけではありません。
次の六つを、会社として管理することです。
- 使用ツール
- 接続する人
- 接続できる時間
- 接続できる端末
- 使用できる権限・機能
- 接続後に残る記録
最初の一歩として、保守会社へ「当社に使用している遠隔保守ツールの正式名称、対象端末、技術者アカウント、MFA、ログ、緊急停止方法を教えてください」と質問してください。
ライトハウスコンサルタントの「中小企業セキュリティ現状診断」では、既存のITベンダーや保守会社に任せている業務についても、使用ツール、アカウント、権限、ログ、契約終了時の処理など、自社が確認すべき事項を整理します。か分からない」「契約書には保守としか書かれていない」「遠隔接続を止める方法が分からない」という場合は、製品を買い替える前に、現在の接続経路と責任分担を見える化することが重要です。
