Table of Contents
小規模チームのリモートアクセス：RDPやVPNより先に役割を決める
小さなチームが必要としているのは、抽象的な「リモートアクセス」ではありません。経理担当者は会計ファイル、運用担当者は社内アプリ、管理者はサーバー保守を必要とします。3人全員に同じリモートデスクトップを渡せば初日は早く進みますが、その後の権限管理、操作確認、退職時の停止が難しくなります。
VPN、gateway、RDP client、セルフホスト製品を比較する前に、役割ごとに一行ずつ書き出します。
| 役割 | 必要なアプリ・データ | 権限 | 接続元 | 離任時に止めるもの |
|---|---|---|---|---|
| 経理 | 会計ファイルとexport | 読み書き可、サーバー管理不可 | 管理対象のPC | account、session、共有link、recovery access |
| 運用 | 社内Webアプリ | 通常のアプリrole | 管理対象のPCまたはphone | アプリaccountと有効なsession |
| 管理者 | update、log、backup | 独立した特権account | 承認済み管理端末 | admin account、key、gateway access |
この表を作ると、製品選びはかなり簡単になります。
必要最小限の入口を渡す
ファイルだけが必要なら、個別accountとfolder permissionを持つファイルサービスを使います。一つの業務アプリだけなら、認証付きWeb境界からそのアプリだけを公開します。Linux管理なら、管理されたVPNやidentity-aware gatewayを通るSSHのほうが、完全なdesktopより範囲を狭くできます。
対象PC上のGUIが本当に必要な場合だけremote desktopを使います。その場合も、独立sessionが必要なのか、現在login中の画面を共有するのかを先に決めます。両者では同意、lock、clipboard、recoveryの動作が異なります。
生のRDP、VNC、SSHをInternet全体に公開しないでください。CISAはremote accessとprivileged accessへのMFAを推奨し、公開状態または保護不足のremote serviceを侵入経路として挙げています。管理されたVPNまたは認証gatewayの後ろに置き、接続できる人と端末を絞り、結果を記録します。
一人につき一つのidentity
共有accountでは、退職時の停止もincident調査も推測になってしまいます。一人ずつ個別identityとMFAを用意し、日常作業と管理作業を分けます。サーバーを変更する特権sessionで、mail、web browsing、通常のoffice workを行うべきではありません。
権限設計は次の問いで確認できます。経理担当者はサーバー管理者にならずに仕事を完了できるか。運用担当者はbackup storeを読まずにアプリを使えるか。管理者は全従業員のアプリpasswordを引き継がずにhostを保守できるか。
一つでも「いいえ」なら、設計はまだ完成していません。
参加テストより先に離任テストをする
account追加は自然に何度も試されますが、完全な権限削除は見落とされがちです。導入前にtest userを作り、無効化した後に次のすべてが止まることを確認します。
- 新しいlogin
- 既存のbrowser、VPN、remote-desktop session
- userに紐づくSSH key、device certificate、recovery method
- 主accountを迂回する共有linkやapplication token
- 紛失・廃棄した端末からのaccess
実際の退職時に、VPN accountは消えたのに古いapplication sessionがまだ使える、と初めて気づく設計では不十分です。
復旧もリモートアクセスの一部
最初の接続成功だけでは、業務用として準備完了とは言えません。gateway停止、certificate期限切れ、account lock、remote machine再起動、唯一の管理者不在を試します。
変更対象と同じ部品に依存しない第二の復旧経路を残します。business-criticalなmachineなら、updateとoutageの担当を決め、外部administratorやMSPへ引き継ぐ条件も決めます。backupは通常userから守り、実際のrestoreを試します。CISAのransomware guidanceも、offlineかつencryptedなbackupと定期的なrecovery testを推奨しています。
一つの実務でpilotする
最初は一人のuserと一つの通常業務だけで確認します。
- 必要なアプリやデータ以外には到達できない。
- 明示的に設計・保護していないserviceがpublic listenしていない。
- MFAと許可端末・networkの条件が実際に適用される。
- 成功と失敗が想定したlogに残る。
- account無効化で新規accessと既存sessionの両方が止まる。
- 同じ故障中のremote pathを使わずに管理者が復旧できる。
通過してから次の役割を追加します。3人の会社にenterprise用語は要りませんが、責任者は必要です。
購入判断は最後にする
access matrixと離任テストを通る、最も小さな仕組みを選びます。共有ファイル、Webアプリ、SSH、remote desktopは交換可能ではなく、「一つのtoolですべて」は多くの場合よい要件ではありません。
すでに到達可能なrelay一台と既存PC三台までがあり、導入前にlistener、identity、permission、rollbackを確認したい場合は、固定 USD 250のLazyRemote Network Fit Review を提供しています。最初はmetadataだけで、password、private key、未編集configは不要です。deploymentとhardwareは別です。