OpenClaw를 한 문장으로 정의하면
OpenClaw는 LLM(예: Claude/GPT)의 판단을 “메신저/대시보드 입력”과 “로컬/서버 도구 실행(파일·쉘·웹·채널)”로 연결하는 게이트웨이형 AI 에이전트 플랫폼입니다. 그래서 일반 챗봇과 달리, 설정 실수 = 곧바로 로컬/서버 침해면(attack surface)으로 이어질 수 있습니다.
전체 구조(운영 관점) – “입력면 + 실행면” 분리해서 생각하기
OpenClaw 운영을 안전하게 설계하려면, 아래 2면을 분리해 보셔야 합니다.
- 입력면(대화 표면, Chat Surface)
- Control UI(브라우저 대시보드), WhatsApp/Telegram/Discord/Slack 등 채널
- 누가/어디서/어떤 메시지를 보낼 수 있나 = 인증·승인·페어링의 영역
- 실행면(도구/권한, Tools & Permissions)
- 파일 접근, 쉘 실행, 네트워크 호출, 외부 연동(스킬/확장)
- 무엇을/어디까지/어떤 조건에서 실행할 수 있나 = 최소권한·격리·감사로그 영역
안전한 운영의 요점은 “입력면을 좁히고(누가 말할 수 있나), 실행면을 더 좁히는 것(무엇을 할 수 있나)”입니다. 공식 문서도 “완벽한 보안은 없고, 작게 시작해 점진적으로 넓혀라”는 철학을 명시합니다.
Getting Started 요약 – 가장 빠른 시작 경로
공식 문서에서 제시하는 “가장 빠른 첫 사용”은 채널 연결 없이 Control UI로 먼저 채팅하는 방식입니다.
openclaw dashboard실행 후- 게이트웨이 호스트에서
http://127.0.0.1:18789/접속
즉, “처음부터 WhatsApp/Telegram 붙이지 말고” 로컬 UI로 기능/권한을 점검한 뒤 채널을 확장하는 흐름이 안전합니다.
위협 모델(Threat Model)을 먼저 박아두기
OpenClaw는 “실험적이면서 강력한 제품”이고, 현실적인 주요 리스크는 아래 4가지로 정리됩니다.
- 과도한 실행권한(로컬 파일/쉘/네트워크)
- 잘못된 설정/오용 시 피해가 큼
- 스킬(확장) 공급망 위험
- “스킬 마켓” 기반 확장은 공격자에게 매우 매력적
- 최근 실제로 악성 스킬 이슈가 크게 보도됨(사회공학+명령 실행 유도 포함)
- 프롬프트 인젝션/명령 주입(입력면 공격)
- “사용자 메시지/외부 콘텐츠”가 모델 판단을 오염 → 위험행동으로 연결
- 원격 노출(대시보드/게이트웨이를 인터넷에 노출)
- “편의성” 때문에 외부 공개하는 순간 난이도가 급상승
- 릴리즈 노트에서도 원격 접근(Tailscale Serve) 인증 강화 같은 보안 수정이 언급될 정도로, 원격면은 신중해야 함
“완전하게” 안전하게 구축/운영하는 레퍼런스 아키텍처
아래는 현업 보안 관점에서 추천하는 “정석 구성”입니다. (가능하면 이 흐름을 그대로 따르시면 됩니다.)
운영 원칙(필수 6개)
(1) 인터넷 공개 금지: Control UI/게이트웨이는 기본적으로 로컬/내부망 전용
(2) 격리 실행: 전용 VM 또는 컨테이너에서만 구동(호스트/업무PC와 분리)
(3) 최소권한: 파일/명령/네트워크 범위를 “필요한 것만”
(4) 감사로그: “누가/언제/무엇을/어떤 결과로 실행했나”를 중앙 수집
(5) 스킬 화이트리스트: 기본은 “차단”, 승인된 것만 허용
(6) 고위험 액션은 Human-in-the-loop: 삭제/외부전송/쉘 실행은 승인 후 수행
공식 문서의 “작게 시작해서 자신감이 생기면 넓혀라”는 원칙을, 운영 표준으로 고정한다고 보시면 됩니다.
단계별 구축 가이드(보안 강화 포함)
1단계: “로컬 UI만”으로 초기 검증
채널을 붙이기 전 아래만 먼저 확인합니다.
- 게이트웨이 상태 확인
openclaw gateway status - 로컬 Control UI 열기
openclaw dashboard # 또는 브라우저에서 http://127.0.0.1:18789/
이 단계의 목표는 “편의”가 아니라 권한/동작/로그/데이터 저장 위치를 확인하는 것입니다.
2단계: 페어링/승인 흐름을 “먼저” 설계한 뒤 채널 연결
외부 채널(WhatsApp 등)을 붙이면 입력면이 급격히 넓어집니다. 따라서 “연결”보다 먼저, 신규 대화 상대 승인(페어링) 프로세스를 운영 룰로 고정하세요. (문서/가이드 흐름에서도 pairing 승인 명령이 언급됩니다.)
예시(문서에 등장하는 흐름 기반)
openclaw pairing list whatsapp
openclaw pairing approve whatsapp <code>운영 팁
- “기본 거부(Default Deny)” + “업무용 허용 리스트”가 정답입니다.
- 개인/그룹 채팅을 분리하고, 그룹에서는 명령 실행을 제한하세요.
3단계: 실행면(도구/권한) 통제 – 가장 중요한 파트
여기서부터가 진짜 보안입니다.
파일 접근
- 특정 디렉터리만 허용(예:
/data/openclaw_workspace만) - 홈 디렉터리 전체 접근 금지
- API 키/SSH키/브라우저 프로필/클라우드 자격증명 경로는 명시적으로 차단
쉘 실행
- 가능하면 “금지” 또는 “허용 명령 화이트리스트”
- 부득이하면 “비루트 + 격리 + 네트워크 이그레스 제한”을 함께 적용
네트워크
- 기본은 Outbound 최소화(필요 도메인만)
- 내부 자산(예: Git, Jira, Wiki)에 접근시키려면 별도 프록시/정책으로 통제
스킬(확장) 운영 정책 – “VirusTotal이 있어도 내부 통제가 핵심”
왜 스킬이 가장 위험한가
스킬은 사실상 “내 권한으로 실행되는 코드/지침”입니다.
최근 악성 스킬이 이슈가 되었고, 사용자를 속여 터미널 명령을 실행하게 만드는 방식(사회공학)도 거론됩니다.
OpenClaw × VirusTotal 파트너십 요약(무엇이 좋아졌나)
OpenClaw는 ClawHub(스킬 마켓)에 대해 VirusTotal 기반 스캐닝을 도입한다고 발표했습니다. 목적은 스킬 보안 스캐닝(악성/의심 탐지) 강화입니다.
중요 포인트
- VT 스캔은 “보안의 한 겹”일 뿐,
- 프롬프트 인젝션/사회공학/권한 오남용까지 완벽히 막아주진 못합니다.
따라서 조직 운영에서는 아래 정책이 필요합니다.
스킬 운영 “완전체” 정책(권장)
(1) 기본 차단 + 승인제(화이트리스트)
(2) 사내 미러(내부 레지스트리) 운영: 승인된 스킬만 내부 저장소로 재배포
(3) 코드 리뷰 체크리스트(필수 항목)
- 외부 다운로드/원격 스크립트 실행 여부
- 난독화/베이스64/쉘 파이프(
curl | bash) 유도 문구 여부 - 민감정보(토큰/키/쿠키) 접근 시도 여부
- 파일/프로세스/브라우저 저장소 접근 범위
(4) 샌드박스 테스트: 운영 반영 전 VM에서 실행/로그 확인
(5) 버전 고정 + 변경관리: 업데이트 자동 반영 금지(검증 후 반영)
로깅/감사/모니터링 – “에이전트는 반드시 증적이 남아야” 합니다
목표: “나중에 무슨 일이 있었는지 1시간 안에 재구성 가능”
수집해야 할 최소 로그
- 입력 이벤트(누가/어디서/무슨 메시지)
- 모델 호출(어떤 프롬프트/툴 호출 계획)
- 툴 실행(명령/대상 파일/네트워크 목적지/결과코드)
- 스킬 설치/업데이트 이력
- 페어링 승인/거부 이벤트
탐지 룰 예시(운영 경보)
- 새 스킬 설치/업데이트 발생
- “외부로 파일 업로드/전송” 행동
- “쉘 실행 + 네트워크 다운로드” 조합
- 실행 대상이 민감 경로(SSH키, 브라우저 프로필, 클라우드 크리덴셜)일 때
사고 대응(IR) 시나리오 – 최소 3가지는 미리 준비
시나리오 A: 악성 스킬 설치 의심
- 즉시 게이트웨이/채널 연결 차단(격리)
- 설치/업데이트 이력 확인
- VM 스냅샷/디스크 이미지 확보
- 토큰/API 키 전면 회수/교체
- 재발 방지: 승인제/내부 미러 강제
시나리오 B: 프롬프트 인젝션으로 위험 명령 실행
- 입력 원문(메시지/링크/첨부) 보존
- 모델이 생성한 툴 호출 계획/명령 확인
- “승인 없는 고위험 액션”이 가능했던 설정을 즉시 폐쇄(HITL 적용)
시나리오 C: 원격 노출로 외부 접근 의심
- 외부 포트/터널 즉시 차단
- 접근 로그(누가, 어떤 헤더/아이덴티티)를 검증
- 원격 접근은 VPN/Tailscale 등 “강한 신원 검증”만 허용(가능하면 사내 SSO 연계)
참고로 릴리즈에서 “Tailscale Serve 인증을 더 단단히 검증”하는 보안 하드닝 언급이 있는 만큼,
원격면은 특히 보수적으로 운영하는 편이 안전합니다.
운영 체크리스트
구축 전(Design)
- 인터넷 공개 없음(대시보드/게이트웨이)
- 전용 VM/컨테이너 격리
- 비루트 계정 구동
- 파일 접근 경로 제한
- 쉘 실행 정책(금지 또는 화이트리스트)
- 네트워크 이그레스 제한(필요 도메인만)
채널 연결 전
- 페어링 승인 절차 문서화/담당자 지정
- 그룹 채팅 정책(명령 제한/읽기전용)
- 운영시간/업무시간 정책(야간 고위험 액션 차단 등)
스킬 운영
- 기본 차단 + 승인제
- VirusTotal 결과 확인(있어도 내부 검증 필수)
- 샌드박스 테스트 후 반영
- 버전 고정/변경관리
운영 중(감사/탐지)
- 실행로그 중앙 수집(SIEM/EDR 연동)
- “새 스킬/쉘 실행/외부전송” 경보 룰 적용
- 키/토큰 주기적 로테이션
“완전하게”의 현실적 의미
OpenClaw 공식 보안 문서가 말하듯, “완벽하게 안전한 구성”은 없습니다. 대신 우리가 할 수 있는 “완전함”은 보안 레이어를 빠짐없이 쌓는 것입니다. 제가 추천하는 결론은 이것입니다.
- 격리(전용 VM) + 최소권한(파일/쉘/네트워크) + 승인(HITL/페어링) + 공급망 통제(스킬 화이트리스트) + 감사로그/탐지 이 5가지를 모두 넣으면, “업무에 쓸 수 있는 수준”까지 안전도를 현실적으로 끌어올릴 수 있습니다.
댓글