MSP를 위한 자체구축 보안 원격지원
헬프데스크·MSP가 고객사의 PC에 원격으로 접속하는 순간부터 신뢰의 문제가 시작됩니다. 사용자가 허락했는가, 무엇을 했는지 남는가, 외부 벤더의 접근은 제한되어 있는가 — 이 세 가지를 갖추지 못하면 아무리 화면이 선명해도 보안 원격지원이라 부르기 어렵습니다. 이 가이드는 MSP가 원격지원 도구를 선택하거나 자체구축할 때 확인해야 할 요건을 정리하고, 넷서브의 동의 기반(consent-based) 원격지원 제품 SupportReach가 이를 어떻게 충족하는지 설명합니다.
MSP 원격지원이 일반 원격 제어와 다른 점
일반 원격 데스크톱은 "내 PC에 내가 접속"하거나 "관리 대상 PC에 상시 접속"하는 시나리오를 가정합니다. 반면 MSP·헬프데스크의 원격지원은 남의 PC, 지금 그 PC를 쓰고 있는 사람에게 접속합니다. 그래서 접속을 여는 조건 자체가 다릅니다 — 관리자의 사전 등록이 아니라, 그 순간 사용자의 동의가 세션을 여는 조건이어야 합니다. 이런 세션을 업계에서는 attended(동의 기반) 세션이라고 부르고, 무인 장치를 상시 관제하는 unattended 세션과 구분합니다.
MSP가 확인해야 할 네 가지 요건
🤝 명시적 동의
기기 앞의 사용자가 허용해야만 세션이 시작되는지. 참여 → 보기 → 제어처럼 단계별 동의가 필요합니다.
⏺️ 전체 세션 녹화
화면과 입력 스트림을 세션 ID로 저장하고 감사용으로 재생할 수 있는지.
🧾 위변조 방지 감사
세션 생명주기(시작·동의·제어·종료)가 독립적으로 검증 가능한 형태로 남는지 — 해시체인처럼 사후에 조작 여부를 확인할 수 있는 구조인지.
🛡️ 범위·시간 제한 벤더 접근(PRA)
외부 벤더에게 공유 크레덴셜 없이, 필요한 범위와 시간만큼만 접근을 주고 종료 시 자동 회수되는지.
이 네 가지를 자체구축하려면 제어 승인 게이트(동의), 세션 녹화·리플레이, 해시체인 감사 로그, 시간 제한 접근 토큰을 각각 설계해야 합니다. SupportReach는 이 네 가지를 ConnectKit· SessionKit·ServerKit· DeviceKit 위에 정책 계층으로 이미 조립해 둔 제품입니다.
자체호스팅과 종단간 암호화
MSP는 여러 고객사의 데이터를 다룹니다. 연결 서버와 녹화 저장소를 조직(또는 MSP)이 자체호스팅하면 화면·입력·녹화·감사 로그가 외부로 나가지 않습니다. 여기에 ConnectKit의 J-PAKE·AES-256-GCM 종단간 암호화가 더해지면, 중계 서버조차 세션 내용을 볼 수 없습니다. 규제 산업(금융·의료·공공)의 MSP 고객이라면 이 두 가지가 사실상 전제 조건입니다.
SupportReach의 구성
| 구성 요소 | 역할 |
|---|---|
| 브라우저 웹 콘솔(ServerKit ViewerGateway) | 상담원이 설치 없이 접속 — 보기·제어·동의. RBAC·단기 토큰·기기별 ACL로 보호 |
| 지원 호스트(SupportReach Host) | 사용자 PC에서 지원 PIN 발급과 동의 절차를 처리 |
| 해시체인 감사 로그(ServerKit) | session.* 생명주기(시작·동의·제어·종료)를 위변조 방지 구조로 기록, 독립 검증·내보내기 가능 |
| 벤더 PRA | 범위·시간 제한·승인 필수·항상 녹화 조건으로 외부 벤더 접근을 부여, 종료 시 회수 |
MSP 플릿까지 확장하기
동의 기반 지원(SupportReach)과 별개로, 무인 자산을 상시 관제해야 하는 MSP라면 DeviceKit.Rmm으로 인벤토리·라이브 지표·원격 명령 실행까지 확장할 수 있습니다. 무인 장치 관제 자체는 무인 장치 원격 관제(RMM) 가이드를 참고하세요.
도입 절차 — 단계별로
SupportReach 같은 동의 기반 원격지원 도구를 MSP 환경에 도입할 때는 보통 아래 순서를 따릅니다.
- 정책 정의 — 어떤 세션에 동의가 필요한지, 녹화·보존 기간, 벤더 접근 승인권자를 먼저 정합니다.
- 콘솔·호스트 배포 — 상담원용 웹 콘솔과 사용자 PC의 지원 호스트를 온프렘 환경에 설치합니다.
- 역할·권한 설정 — RBAC로 상담원·관리자·벤더 역할을 나누고, 벤더에게는 PRA 범위를 세션 단위로 제한합니다.
- 감사 체계 연결 — 해시체인 감사 로그를 SIEM 등 기존 보안 모니터링 체계로 내보내도록 구성합니다.
- 시범 운영 후 확대 — 소규모 팀으로 먼저 운영해 동의 흐름과 녹화 보관을 검증한 뒤 전체 헬프데스크로 확대합니다.
자주 묻는 질문
동의 기반(attended) 원격지원이 왜 MSP에 중요한가요?
MSP는 여러 고객사의 사용자 PC에 접속하므로, 세션이 사용자의 명시적 동의 없이 시작되면 신뢰와 컴플라이언스
문제가 생깁니다. 동의 기반 세션은 참여 → 보기 → 제어 순으로 사용자가 매 단계를 허용해야 열리므로, 무단
접근 우려 없이 지원할 수 있습니다.
세션 녹화와 감사 로그만으로 충분한가요, 아니면 더 필요한가요?
녹화와 감사 로그는 사후 검증을 위한 최소 요건입니다. 여기에 위변조 방지(해시체인) 구조로 로그 자체가
조작되지 않았음을 독립적으로 검증할 수 있어야 하고, 외부 벤더에게는 범위·시간이 제한된 접근(PRA)까지
더해야 컴플라이언스 요건을 온전히 충족합니다.
SupportReach는 상담원이 별도 프로그램을 설치해야 하나요?
아니요. 상담원(운영자)은 브라우저 기반 웹 콘솔(ServerKit ViewerGateway)로 접속합니다. 사용자 쪽에는 지원
호스트가 설치되어 지원 PIN과 동의 절차를 제공합니다.
외부 벤더에게 PRA(특권 원격 접근)를 줄 때 무엇이 보장되나요?
SupportReach의 벤더 PRA는 범위·시간 제한, 승인 필수, 항상 녹화 조건으로 접근을 부여합니다. 공유
크레덴셜이 없고, 세션 종료 시 접근이 자동으로 회수됩니다.
Secure, self-built remote support for MSPs
Trust becomes the question the moment a helpdesk or MSP connects to a customer's PC remotely. Did the user consent? Is there a record of what happened? Is an outside vendor's access scoped? Without all three, no amount of screen clarity makes a tool secure remote support. This guide lays out what an MSP should require when choosing or building a remote-support tool, and how NetServ's consent-based remote-support product, SupportReach, meets it.
How MSP remote support differs from ordinary remote control
An ordinary remote desktop assumes "I'm connecting to my own PC" or "connecting to a device I manage, always-on." MSP and helpdesk remote support instead connects to someone else's PC, in use right now by someone else. That changes what's allowed to open a session: not an administrator's pre-registration, but the user's consent in that moment. The industry calls this an attended (consent-based) session, distinct from the unattended session used for always-on monitoring of unmanned devices.
Four requirements an MSP should check
🤝 Explicit consent
Does a session start only when the person at the machine allows it — step-by-step, like join → view → control?
⏺️ Full session recording
Is the screen and input stream persisted keyed to a session id, and replayable for audit?
🧾 Tamper-evident audit
Is the session lifecycle (start, consent, control, end) recorded so it can be independently verified — like a hash chain that reveals tampering after the fact?
🛡️ Scoped, time-boxed vendor access (PRA)
Can an outside vendor get access with no shared credentials, scoped and time-boxed, revoked automatically on end?
Building all four yourself means designing a control-approval consent gate, session recording and replay, a hash-chained audit log, and time-boxed access tokens. SupportReach already assembles these four as a policy layer on top of ConnectKit, SessionKit, ServerKit, and DeviceKit.
Self-hosting and end-to-end encryption
MSPs handle data for many client organizations. Self-hosting the connection server and recording storage (by the org or the MSP) keeps screen, input, recordings, and audit logs from leaving your boundary. Add ConnectKit's J-PAKE / AES-256-GCM end-to-end encryption on top, and even the relay server can't see session content. For MSPs serving regulated industries (finance, healthcare, public sector), both are effectively table stakes.
How SupportReach is put together
| Component | Role |
|---|---|
| Browser web console (ServerKit ViewerGateway) | Agent attaches with no install — view · control · consent. Gated by RBAC, short-lived tokens, per-device ACL |
| Support host (SupportReach Host) | Runs on the user's PC, issues the support PIN and handles consent |
| Hash-chained audit log (ServerKit) | Records the session.* lifecycle (start, consent, control, end) tamper-evidently, independently verifiable and exportable |
| Vendor PRA | Grants outside vendors scoped, time-boxed, approval-required, always-recorded access, revoked on end |
Scaling to an MSP fleet
Separate from consent-based support (SupportReach), an MSP that also monitors unattended assets can extend to DeviceKit.Rmm for inventory, live metrics, and remote command execution. For unattended device operations itself, see the unattended device RMM guide.
Rollout, step by step
Onboarding a consent-based remote-support tool like SupportReach into an MSP environment usually follows this order.
- Define policy — decide up front which sessions require consent, how long recordings are retained, and who approves vendor access.
- Deploy the console and host — install the agent web console and the support host (for user PCs) on-prem.
- Set roles and permissions — split agent, admin, and vendor roles with RBAC, and scope each vendor's PRA to a single session.
- Wire up audit — export the hash-chained audit log to your existing security monitoring, such as a SIEM.
- Pilot, then expand — run it with a small team first to verify the consent flow and recording retention, then roll out to the full helpdesk.
Frequently asked questions
Why does consent-based (attended) support matter for an MSP?
An MSP connects to user PCs across many client organizations, so a session opening without explicit user
consent creates trust and compliance problems. A consent-based session only opens as the user allows each step
— join, then view, then control — so support happens without any risk of unauthorized access.
Is session recording and an audit log enough, or is more needed?
Recording and an audit log are the minimum for after-the-fact verification. On top of that you need a
tamper-evident (hash-chained) structure so the log itself can be independently verified as unaltered, and
scoped, time-boxed access (PRA) for outside vendors to fully meet compliance requirements.
Does the agent need to install separate software with SupportReach?
No. Agents (operators) connect from a browser-based web console (ServerKit ViewerGateway). On the user's side, a
support host is installed to issue the support PIN and handle consent.
What's guaranteed when granting PRA (privileged remote access) to an outside vendor?
SupportReach's vendor PRA grants access that's scoped, time-boxed, approval-required, and always recorded —
with no shared credentials, and access revoked automatically when the session ends.