Home Assistant IP 카메라 보안 체크리스트

Home Assistant IP 카메라 조합은 생각보다 빨리 복잡해집니다. 화면만 뜨면 끝이라고 보기 쉬운데, 실제 운영에서 발목을 잡는 건 대개 영상 품질보다 권한, 네트워크 경계, 로그 품질이거든요. 저도 홈랩에서 몇 번 다시 깔아보니, ONVIF로 장치가 잡히고 스트림이 재생되는 순간보다 그다음 몇 주가 더 중요하더라고요.

지금은 기준을 하나로 잡습니다. 카메라는 신뢰하는 장비가 아니라, 필요한 범위 안에서만 일하게 만드는 장비로 보는 겁니다. 이 관점으로 보면 설계가 훨씬 단순해집니다. 카메라는 영상을 보내고, Home Assistant는 상태와 자동화를 묶고, 외부 접근은 VPN이나 엄격한 리버스 프록시로만 받습니다. 이번 글은 그 기준으로 정리한 Home Assistant IP 카메라 보안 실전 체크리스트입니다.

Home Assistant 서버, 카메라 전용 네트워크, 관리용 단말, VPN 경로를 한눈에 보여주는 개요 이미지입니다.

1. 왜 Home Assistant IP 카메라 연동이 보안 이슈로 이어질까

IP 카메라는 단순한 영상 소스가 아닙니다. 스트림 서버이자 웹 관리 장비이고, 경우에 따라 이벤트 발행자이기도 합니다. Home Assistant는 그 위에 자동화를 얹는 오케스트레이션 레이어에 가깝고요. 여기서 자주 놓치는 건, Home Assistant에 붙였다고 해서 카메라 자체의 공격면이 자동으로 줄어드는 건 아니라는 점입니다.

제가 현장에서 제일 자주 본 실패는 세 가지였습니다.

• 노출 실패: RTSP, 웹 관리 포트, ONVIF 포트가 의도치 않게 다른 VLAN이나 인터넷 쪽에서 보입니다.
• 권한 실패: Home Assistant 연동 계정이 관리자 권한이라 PTZ, 사용자 관리, 설정 변경까지 다 열려 있습니다.
• 가시성 실패: 프록시, 카메라, Home Assistant 시간이 어긋나거나 원본 접속 정보를 교차 확인할 로그가 부족해 사고 분석이 어려워집니다.

이 셋이 겹치면 꽤 번거로워집니다. 예를 들어 현관 카메라가 외부에 노출돼 있고, 관리자 계정으로 ONVIF를 붙여놨고, 프록시 access log 없이 Home Assistant 로그만 본다고 해보겠습니다. 그러면 누가 어디서 접근했는지 추적이 흐려지고, 연동 편의 때문에 열어둔 기능이 오히려 리스크를 키웁니다. 제 경험상 홈랩 감시 시스템은 “잘 나오느냐”보다 잘 제한돼 있느냐를 먼저 봐야 나중이 편합니다.

2. Home Assistant IP 카메라 연동의 핵심 개념: ONVIF, RTSP, 네트워크 분리

처음엔 ONVIF와 RTSP를 한 묶음으로 보기 쉬운데, 운영 관점에서는 역할을 분리해서 봐야 판단이 빨라집니다. ONVIF는 장치 발견, 프로필 조회, 이벤트, PTZ 같은 제어 채널에 가깝고, RTSP는 영상 전달 채널입니다. 참고로 Home Assistant의 ONVIF 통합은 현재 기준으로 ONVIF Profile S 호환 장치를 대상으로 하며, 영상 처리를 위해 FFmpeg 통합이 필요합니다.

네트워크 분리는 단순히 “분리했다”에서 끝나지 않습니다. 누가 누구에게 먼저 말을 걸 수 있는지를 줄이는 작업에 가깝습니다. 카메라는 Home Assistant에 필요한 포트만 열고, 관리용 PC는 관리 페이지에만 접근하고, 인터넷으로 직접 나가는 경로는 기본 차단하는 식이죠. 이 구조를 먼저 잡아두면 카메라가 늘어나도 판단 기준이 흔들리지 않습니다.

3. 제가 쓰는 연동 전 체크리스트

1. 펌웨어부터 확인: 최신 안정 버전으로 맞추고, 업데이트 직후 ONVIF 프로필과 RTSP 경로가 바뀌지 않았는지 같이 봅니다.
2. 기본 계정 정리: 기본 admin 계정은 비활성화하거나 강한 비밀번호로 바꾸고, Home Assistant용 계정은 별도로 만듭니다.
3. 권한 최소화: Home Assistant 계정에는 영상 조회와 필요한 이벤트 권한만 주고, 사용자 관리나 네트워크 설정 권한은 빼둡니다.
4. 관리 평면 분리: 카메라 웹 UI는 관리 단말 또는 관리 VLAN에서만 열리게 하고, 일반 사용자 대역에서는 막습니다.
5. 시간 동기화: 카메라, Home Assistant, 리버스 프록시, NVR이 있다면 그 장비까지 NTP 기준을 맞춥니다.
6. 스트림 전략 결정: 대시보드에는 서브 스트림, 녹화나 분석은 메인 스트림처럼 역할을 나눕니다.
7. 외부 접속 원칙 결정: 직접 포트포워딩은 피하고, VPN 또는 인증이 명확한 프록시 경로 중 하나만 표준으로 정합니다.
8. 검증 경로 준비: nmap, ffprobe, 패킷 캡처, Home Assistant 로그 확인 순서를 미리 정해둡니다.

여기서 특히 많이 놓치는 게 시간 동기화입니다. 연동은 되는데 이벤트 타임라인이 엇갈리고, 녹화 파일 시각과 자동화 시각이 다르면 원인 찾는 속도가 확 떨어집니다. “움직임 감지됐다는데 왜 같은 시각 로그가 없지?” 하고 헤매는 경우가 은근 많더라고요. 저는 카메라 세팅 끝내면 NTP부터 꼭 확인합니다.

4. 실전 구현 1: 네트워크와 포트부터 줄입니다

실전에서는 카메라가 노출한 서비스부터 확인합니다. 제 기준은 간단합니다. 예상한 포트만 열려 있어야 하고, 예상한 대상에게만 닿아야 합니다. 카메라가 Home Assistant에 스트림을 제공하는 건 괜찮지만, 외부 DNS나 제조사 클라우드 주소로 계속 통신하고 있으면 다시 봐야 합니다. P2P 기능이 숨어 있는 장비도 생각보다 많았습니다.

제가 보통 먼저 돌리는 확인 명령은 아래 순서입니다.

# 1) 카메라가 실제로 어떤 TCP 포트를 열고 있는지 확인
nmap -Pn -sT -sV -p- 192.168.30.10

# 2) RTSP 스트림이 정상인지 Home Assistant 바깥에서 먼저 검증
ffprobe -v error -rtsp_transport tcp \
  -show_entries stream=index,codec_name,codec_type,width,height \
  -show_entries format=format_name \
  -of default=noprint_wrappers=1 \
  "rtsp://ha_viewer:[email protected]:554/stream1"

# 3) 카메라가 예상 밖 목적지와 통신하는지 관찰
sudo tcpdump -ni any host 192.168.30.10

이 세 개만 제대로 봐도 원인 분리가 꽤 빨라집니다. 코드 블록은 예시라서, 실제 환경에서는 IP와 계정명, RTSP 경로를 장비에 맞게 바꿔서 확인하시면 됩니다.

• nmap에서 웹 관리 포트, ONVIF 포트, RTSP 외에 낯선 서비스가 보이면 먼저 정리합니다.
• ffprobe가 여기서 실패하면 Home Assistant 문제가 아니라 스트림 URL, 계정 권한, 코덱, 네트워크 경로 문제일 확률이 높습니다.
• tcpdump에서 카메라가 Home Assistant 말고 다른 내부 장비나 외부 공인 IP와 자주 대화하면, 의도한 경로인지부터 따져봐야 합니다.

방화벽은 장비마다 문법이 다르니 원칙을 먼저 잡는 게 낫습니다. 저는 보통 이렇게 나눕니다.

• 카메라 VLAN -> Home Assistant: RTSP와 필요한 이벤트 포트만 허용
• 관리 VLAN -> 카메라: 웹 UI 등 관리 포트만 허용
• 카메라 VLAN -> 인터넷: 기본 거부
• 일반 사용자 VLAN -> 카메라: 기본 거부

리눅스 기반 방화벽이라면 아래처럼 시작하는 편이 이해가 쉽습니다. 인터페이스명과 IP는 환경에 맞게 바꿔야 하지만, 논리는 그대로 가져가면 됩니다.

# nftables 예시: 기본은 막고, 필요한 경로만 허용
sudo nft add table inet camfilter
sudo nft 'add chain inet camfilter forward { type filter hook forward priority 0; policy drop; }'
sudo nft add rule inet camfilter forward ct state established,related accept
sudo nft add rule inet camfilter forward iifname "vlan30_cam" ip daddr 192.168.10.20 tcp dport { 554 } accept
sudo nft add rule inet camfilter forward iifname "vlan10_mgmt" ip daddr 192.168.30.0/24 tcp dport { 80, 443 } accept

제가 이 단계에서 중요하게 보는 건 “열어둘 포트 목록”보다 “닫아둘 기본 방향”입니다. 카메라는 업데이트할 때만 잠깐 인터넷이 필요할 수 있습니다. 그래서 상시 허용보다 일시 허용 후 다시 차단이 운영이 훨씬 편하더라고요.

카메라 전용 대역에서 Home Assistant로만 제한적으로 접근하도록 설계한 예시입니다.

5. 실전 구현 2: Home Assistant 쪽 설정도 같이 잠급니다

카메라만 분리해도 절반은 정리되지만, Home Assistant가 느슨하면 사고 기록이 흐려집니다. 특히 리버스 프록시를 거치는 환경에서는 Trust X-Forwarded-For, Trusted proxies, 로그인 차단 정책을 같이 봐야 합니다. 다만 2026년 현재 Home Assistant의 HTTP 서버 설정은 보통 Settings > System > Network에서 관리하므로, 예전처럼 configuration.yaml의 http: 블록만 기준으로 보면 오히려 헷갈릴 수 있습니다.

실전 점검 포인트는 이렇습니다.

• Trusted proxies에는 실제 앞단 프록시 IP나 정확한 CIDR만 넣습니다. 대충 넓게 잡으면 나중에 해석이 꼬입니다.
• Enable IP banning과 로그인 시도 제한은 켜두되, 먼저 프록시를 신뢰하는 방식이 맞는지 확인합니다.
• CORS allowed origins는 필요한 도메인만 넣습니다. 편하다고 넓게 열어두면 괜히 문제만 늘어납니다.
• SSL profile은 특별한 호환성 문제가 있을 때만 조정합니다. 기본값을 괜히 건드릴 필요는 거의 없었습니다.

하나 더 짚고 갈 부분이 있습니다. 로그인 실패나 차단 로그는 환경에 따라 프록시 주소 위주로 보일 수 있어서, Home Assistant 로그만으로 원본 IP를 항상 정확히 복원할 수 있다고 기대하면 안 됩니다. 이럴 때는 프록시 access log와 같이 봐야 훨씬 정확합니다. 이거 한 번 이해해두면, 나중에 분석할 때 진짜 편합니다.

카메라 통합 계정도 저는 분리합니다. 공식 ONVIF 문서도 Home Assistant 전용 사용자를 따로 만들고, 현재 기능 범위에서는 표준 사용자 권한이면 충분하다고 안내합니다. PTZ를 안 쓰면 PTZ 권한을 안 주고, 이벤트를 안 쓰면 ONVIF 자체를 줄이거나 끄는 편이 낫습니다. 연동 편의와 공격면은 거의 항상 같이 움직입니다.

# automations.yaml
- id: camera_motion_notification
  alias: Front Door Motion Notification
  triggers:
    - trigger: state
      entity_id: binary_sensor.front_door_motion
      to: "on"
  conditions:
    - condition: state
      entity_id: input_boolean.alerts_enabled
      state: "on"
  actions:
    - action: notify.mobile_app_phone
      data:
        title: "Front Door Motion"
        message: "현관 카메라 이벤트가 감지됐습니다."
  mode: single

이 자동화 예시는 현재 Home Assistant YAML 문법 기준에도 맞는 형태입니다. 자동화는 결국 이벤트를 만든 주체와, 알림을 보낸 주체를 분리해서 추적할 수 있게 짜두는 게 핵심입니다.

외부 접속 방식은 이렇게 고릅니다

제 추천은 분명합니다. 혼자 운영하는 홈랩이면 VPN이 먼저입니다. 반대로 Home Assistant 외에도 여러 웹 서비스를 묶어 외부에 내보내야 하고, 접근 제어를 한 곳에서 관리해야 한다면 리버스 프록시 + 엄격한 trusted proxy 설정이 더 맞습니다. 직접 포트포워딩은 임시 테스트에서도 습관이 되면 별로더라고요.

Home Assistant에서 카메라 통합을 추가하고 이벤트 자동화를 연결하는 흐름을 설명하는 이미지입니다.

6. 자주 겪는 문제와 해결법

이 구간은 제가 실제로 가장 많이 손댄 부분입니다. “아예 안 됨”보다 “가끔 됨”이 더 어렵습니다. 그래서 증상보다 근본 원인으로 묶어보는 편이 훨씬 낫습니다.

1) ONVIF는 잡히는데 영상이 안 나오는 경우

이건 보통 제어 채널과 스트림 채널이 분리돼 있을 때 생깁니다. 장치 정보는 읽히는데, 실제 스트림 URL이나 코덱 지원이 표시 경로와 안 맞는 겁니다.

• 근본 원인: ONVIF 프로필 조회는 성공했지만 RTSP 경로가 다르거나 인증 정보가 다릅니다.
• 근본 원인: 카메라 기본 스트림이 H.265 위주인데, 표시 경로나 중간 구성요소가 기대대로 처리하지 못합니다.
• 해결 순서: ffprobe로 스트림 자체 검증 -> VLC 등 별도 플레이어 검증 -> Home Assistant 통합 문제 확인 순으로 나눕니다.

2) 로그인 실패 차단이 정상 사용자에게 걸리는 경우

이건 거의 항상 프록시 신뢰 설정이나 앱 URL 설정 문제였습니다. Home Assistant가 실제 사용자 흐름을 충분히 구분하지 못하면, 여러 사용자의 실패 시도가 한 지점에 뭉쳐 보일 수 있습니다.

# Home Assistant OS/SSH 애드온 환경에서 로그 보기
ha core logs

# 컨테이너 배포라면
docker logs -f homeassistant

# 프록시가 있다면 access log에서도 실제 전달 흐름 확인
sudo tail -f /var/log/nginx/access.log

• 같은 프록시 주소만 반복되면 프록시 로그와 Home Assistant 설정을 같이 확인합니다.
• 짧은 시간에 여러 계정 실패가 보이면 외부 스캔인지, 비밀번호 관리자 자동 재시도인지 먼저 분리합니다.
• 특정 모바일 앱만 반복 실패하면 저장된 이전 세션이나 잘못된 내부 URL을 물고 있는 경우가 많습니다.

3) 홈랩 감시 시스템이 느려지는 경우

이때 Home Assistant를 범인으로 단정하면 해결이 늦습니다. 병목은 대개 스트림 디코딩, 저장소 I/O, 데이터베이스 기록, 네트워크 재전송 중 하나에서 납니다.

• 라이브 뷰가 느리다: 메인 스트림 대신 서브 스트림을 대시보드에 붙입니다.
• 자동화는 되는데 화면이 버벅인다: 영상 처리와 상태 자동화를 같은 계층에서 무리하게 같이 하고 있지 않은지 봅니다.
• DB가 커진다: recorder 범위를 줄여 카메라 관련 부수 이벤트까지 전부 기록하지 않게 합니다.
• 가끔만 끊긴다: 무선 구간, 케이블, 스위치 상태를 보기 전에 tcpdump나 스위치 통계로 재전송 징후를 확인합니다.

저는 보통 이렇게 결정합니다. 대시보드용 영상은 보기 편한 서브 스트림, 분석이나 녹화는 별도 구성요소, Home Assistant는 상태와 자동화 중심. 이렇게 역할을 나누면 성능 이슈가 생겨도 어디를 손봐야 할지 금방 좁혀집니다.

7. 검증은 이렇게 합니다: 연결 성공보다 중요한 확인 포인트

연동이 끝난 직후보다, 하루 지나고 일주일 지나도 같은 상태가 유지되는지가 더 중요합니다. 저는 아래 항목을 통과해야 “붙였다”고 봅니다.

1. 외부 노출 검증: 외부 네트워크에서 카메라 RTSP와 웹 관리 포트가 직접 보이지 않는지 확인합니다.
2. 권한 검증: Home Assistant용 계정으로 카메라 설정 변경, 사용자 추가, 네트워크 변경이 안 되는지 확인합니다.
3. 이벤트 검증: 실제 움직임을 만들어 엔티티 상태 변화, 알림, 로그 타임스탬프가 이어지는지 봅니다.
4. 재부팅 복구 검증: 카메라 재부팅 후 스트림 재연결과 자동화 복구가 되는지 확인합니다.
5. 로그 품질 검증: 프록시 로그, Home Assistant 로그, 카메라 로그에서 시간과 출발지 정보가 어떻게 남는지 교차 확인합니다.

판단 기준도 애매하게 두지 않는 게 좋습니다. 저는 이렇게 봅니다. 엔티티 상태가 안 바뀌면 이벤트 수집 문제, 상태는 바뀌는데 알림이 안 오면 자동화 문제, 알림은 오는데 영상만 안 보이면 스트림 문제입니다. 이 순서로 자르면 디버깅 시간이 꽤 줄어듭니다.

연동 후 검증해야 할 대시보드 요소와 이벤트 이력을 보여주는 결과 예시입니다.

8. 운영하면서 지키면 좋은 습관

• 카메라별 정책 분리: 실내 카메라와 실외 카메라를 같은 권한, 같은 노출 정책으로 묶지 않습니다.
• 문서화: 카메라 모델, IP, 스트림 URL, Home Assistant 계정, 관리 계정 위치를 남겨둡니다.
• 변경 이력 관리: 펌웨어 업데이트 뒤 RTSP 경로, ONVIF 동작, 이벤트 엔티티 이름이 바뀌었는지 확인합니다.
• 정기 점검: 포트 스캔, 계정 점검, 방화벽 정책, 외부 노출 여부를 주기적으로 다시 봅니다.
• 백업 분리: Home Assistant 설정 백업과 카메라 설정 백업을 같은 위치에만 두지 않습니다.

운영 습관에서 제일 체감이 컸던 건 문서화였습니다. 카메라가 1대일 때는 기억으로 버티지만, 3대만 넘어가도 “이 스트림이 메인인가 서브인가”, “이 계정이 관리자였나 읽기 전용이었나” 금방 헷갈립니다. 그때부터는 문제 해결보다 기억 복구에 시간을 더 쓰게 되더라고요.

같이 읽으면 좋은 글도 내부 링크로 묶어두세요. 예를 들어 Home Assistant 관련 가이드나 네트워크 분리, 리버스 프록시 설정 글을 함께 연결해두면 검색 유입 후 체류 시간이 확실히 좋아집니다.

9. FAQ와 마지막 권고

Q. Home Assistant에서 카메라만 보이면 끝 아닌가요?

아닙니다. 보이는 건 기능 확인일 뿐이고, 보안 확인은 따로 해야 합니다. 관리 포트 노출, 계정 권한, 외부 접근 경로, 로그 품질까지 같이 봐야 실제 운영 기준을 통과합니다.

Q. ONVIF를 끄고 RTSP만 쓰는 게 더 안전한가요?

PTZ나 카메라 이벤트가 필요 없으면 공격면을 줄이는 데 도움이 됩니다. 반대로 이벤트 연동이 필요하면 ONVIF를 쓰되, 관리자 계정 대신 최소 권한 계정으로 붙이는 편이 훨씬 현실적입니다.

Q. 가장 먼저 하나만 하라면 뭘 하시겠어요?

카메라 네트워크 분리입니다. 그다음이 Home Assistant 전용 읽기 계정, 마지막이 외부 접근 경로 정리입니다. 이 순서가 체감 효과가 제일 컸습니다.

제 권고는 명확합니다. 집에서 소규모로 운영하고, 실사용 안정성이 더 중요하다면 VPN + 카메라 전용 네트워크 + Home Assistant 전용 읽기 계정으로 가세요. 반대로 여러 내부 서비스를 함께 공개해야 하고 인증과 접근 제어를 중앙에서 관리해야 한다면 리버스 프록시 + 좁게 잡은 trusted proxy + 로그 검증 체계가 맞습니다. 직접 포트포워딩은 편한 시작처럼 보여도 운영 부채가 큽니다. 저는 이제 카메라가 잘 뜨는지보다, 몇 달 뒤에도 조용히 제한된 상태로 잘 도는지를 더 중요하게 봅니다.

네트워크 분리, 계정 최소 권한, 외부 접속 방식 선택을 한 장으로 정리한 요약 이미지입니다.