CCTV 관제 화면에 로그인하면 영상도 보호될까? 접근 권한의 구조

관제 페이지에 로그인 화면이 있으면 CCTV 영상도 자동으로 보호될까요? 확인해야 할 것은 페이지 진입뿐 아니라 실제 영상 요청이 어디에서 허용되는가입니다. 웹 화면과 미디어 서버가 별도로 동작한다면 각각의 접근 경로를 살펴봐야 합니다.

이 글은 CCTV 웹 연결 구조의 후속편입니다. 로그인한 사용자가 어떤 카메라를 실시간으로 보고, 어떤 녹화를 다시 볼 수 있는지 설계하는 방법을 가상 매장 사례로 설명합니다.

1. 로그인과 권한 확인이 답하는 질문

인증은 “누구인가”를 확인하고, 인가는 “이 요청을 허용할 것인가”를 판단합니다. 로그인에 성공한 직원이라도 모든 카메라와 모든 관리 기능을 사용할 이유는 없습니다. 이 구분은 OWASP 접근 권한 안내에서도 설명하는 기본 원칙입니다.

예를 들어 A매장 직원과 B매장 직원이 같은 사이트에 로그인한다고 가정하겠습니다. A매장 직원에게는 A매장 출입구 영상이 필요하지만, B매장 창고 영상까지 보여 줄 필요는 없습니다. 여기서 로그인 성공은 두 사람 모두에게 해당하지만, 카메라별 허용 결과는 달라집니다.

가상 이용자	허용할 범위	별도 승인할 기능
A매장 직원	A매장 실시간 보기	녹화 다시보기·내보내기
B매장 직원	B매장 실시간 보기	녹화 다시보기·내보내기
통합 관리자	담당 매장 실시간·다시보기	계정 관리·카메라 설정 변경

위 표는 권한을 나누는 예시이지 특정 업무의 정답은 아닙니다. 실제 운영에서는 맡은 업무에 필요한 범위를 정하고, 인사 이동이나 담당 매장 변경 시 누구의 권한을 바꿔야 하는지도 함께 정합니다.

직접 제작한 권한 확인 개념도. 외부 인증 서버에 판단을 요청하는 구성을 예로 들었으며, 다른 인증 방식에서는 검증 위치와 통신 흐름이 달라질 수 있습니다.

2. 메뉴를 숨기는 것만으로 충분하지 않은 이유

A매장 직원의 화면에서 B매장 카메라 버튼을 숨겼다고 가정해 보겠습니다. 그런데 미디어 서버가 B매장 영상 요청을 누구에게나 허용한다면 화면의 메뉴 제한과 실제 접근 제한이 서로 맞지 않습니다. 서버 쪽에서 요청한 사용자와 대상 카메라를 함께 확인해야 합니다.

OWASP는 기본 거부와 요청별 권한 검증을 권고합니다. 이를 관제 서비스에 적용하면, 권한 표에 없는 카메라나 허용되지 않은 동작은 서버에서 거부하도록 설계하는 방식이 됩니다. 페이지를 거쳐 왔다는 사실이나 추측하기 어려운 주소만으로 접근을 허용하지 않는 것이 핵심입니다.

실시간 영상, 다시보기, 영상 내보내기, 썸네일이 서로 다른 주소에서 제공된다면 경로를 나눠 적어 보세요. “로그아웃 상태에서 어디까지 접근할 수 있어야 하는가”를 각 경로에 답하면 빠뜨린 범위를 찾기 쉽습니다. 내보내기와 썸네일 권한은 서비스가 따로 구현해야 할 수도 있습니다.

3. MediaMTX에서는 무엇을 구분할 수 있을까?

MediaMTX는 설정 파일의 내부 사용자, 외부 HTTP 인증 서버, 외부 JWT 제공자를 사용하는 방식을 지원합니다. 권한에는 읽기(read), 송출(publish), 녹화 재생(playback) 등의 동작과 스트림 경로를 지정할 수 있습니다. 구체적인 구성은 MediaMTX 인증 공식 문서를 기준으로 확인해야 합니다.

내부 사용자 방식은 정해진 계정과 경로를 설정으로 관리하는 출발점이 될 수 있습니다. 외부 HTTP 방식은 인증 요청을 받은 서비스가 사용자와 경로 등을 보고 허용 여부를 응답하는 구조입니다. JWT 방식은 외부에서 발급한 서명 토큰과 그 안의 권한 정보를 검증하는 구조입니다. 위 그림은 세 방식 중 외부 HTTP 판단 흐름을 단순화했습니다.

선택할 때는 계정 수보다 기존 회원 정보와 카메라 담당 관계가 어디에 저장되어 있는지 먼저 보는 편이 좋습니다. 예를 들어 담당 매장이 자주 바뀐다면 권한 변경이 실제 재생 요청에 언제 반영되는지 설명할 수 있어야 합니다. 어떤 방식이든 브라우저에 전체 카메라의 공용 관리자 비밀번호를 넣는 설계는 피해야 합니다.

4. 토큰 만료와 재생 종료는 따로 확인합니다

토큰에 유효 기간이 있더라도 “그 시간이 되면 이미 재생 중인 영상도 정확히 끊긴다”고 단정하면 안 됩니다. 신규 요청의 검증과 이미 만들어진 연결의 처리 방식은 구분해서 확인해야 합니다. 사용할 미디어 서버의 버전, 재생 방식, 세션 종료 정책에 따라 실제 동작을 검증합니다.

시험 항목은 세 가지로 나눌 수 있습니다. 만료된 토큰으로 새 재생을 시작하는 경우, 재생 중 네트워크가 끊겨 다시 연결하는 경우, 연결을 유지한 채 유효 기간을 넘기는 경우입니다. 로그아웃하거나 담당 매장을 변경했을 때 기존 재생을 즉시 끝내야 한다면, 그 요구도 별도의 종료 정책과 시험 항목으로 적습니다.

WebRTC와 HLS 비교 글에서 설명한 것처럼 두 방식의 전달 흐름이 다릅니다. 따라서 한 방식에서 권한 확인을 통과했다고 다른 방식의 재생 주소까지 검증했다고 보기는 어렵습니다. 실제 제공하는 출력 방식별로 같은 이용자 시나리오를 확인해야 합니다.

5. 가상 계정 두 개로 권한표 확인하기

1. 시험용 A직원과 B직원 계정을 만들고, 각자 허용된 카메라가 정상 재생되는지 확인합니다.
2. 허용되지 않은 카메라를 요청했을 때 서버가 거부하는지 확인합니다.
3. 로그아웃 상태에서 실시간·다시보기 경로가 의도대로 제한되는지 확인합니다.
4. 담당 카메라를 바꾼 뒤 신규 재생과 기존 재생의 동작을 각각 기록합니다.
5. 권한 거부 기록에 사용자 식별자·대상 경로·동작·시간이 남는지 확인하되 비밀번호와 원문 토큰은 기록하지 않습니다.

검증 결과는 “보안 설정 완료”라는 한 줄보다 “A직원은 A매장 실시간 허용, B매장 실시간 거부, A매장 다시보기 거부”처럼 적으면 이해하기 쉽습니다. 먼저 권한표를 만들고 실제 결과를 나란히 놓으면, 화면 구성과 영상 서버 설정이 같은 규칙을 따르는지 확인할 수 있습니다.

자료 확인일: 2026년 9월 7일. 공식 자료를 참고한 설계 설명입니다. 이용자·매장 사례는 가상이며, 특정 서비스에 대한 보안 진단 결과나 완성된 인증 구현을 뜻하지 않습니다.