OpenClaw 보안 설정 완전 가이드: Docker 샌드박스부터 권한 제어까지 5단계 방어

빠른 결론(답부터)

다음 세 가지만 적용해도 OpenClaw의 고위험 상황 대부분을 먼저 억제할 수 있습니다.

1. Token/비밀번호 인증을 강제하고 진입점을 제한합니다.
2. 컨테이너 샌드박스, 비 root 사용자, 최소 권한을 적용합니다.
3. 고위험 도구는 허용 목록으로 관리하고 민감한 명령은 기본 거부합니다.
   이 세 단계를 마친 뒤 감사와 네트워크 격리를 차례로 보완하는 것이 보안 효과가 가장 큽니다.

새벽 3시, 한 개발자가 Reddit에 도움을 요청하는 글을 올렸습니다. 그는 자신의 MacBook에 OpenClaw를 기본 설정으로 설치해 2주 동안 잘 사용하고 있었습니다. 그러던 어느 날 OpenClaw에 “최근 프로젝트 파일을 정리해 줘”라고 부탁했는데, AI가 ~/.ssh/와 ~/.aws/ 디렉터리까지 읽고 답변에 그의 개인 키 내용을 “친절하게” 보여 줬습니다.

더 심각한 문제는 그 대화 기록이 업무 그룹에 동기화되었다는 점입니다.

솔직히 이 사례를 처음 봤을 때 등골이 서늘했습니다. OpenClaw는 Shell 명령 실행, 파일 읽기·쓰기, 브라우저 제어까지 가능한 매우 강력한 AI 도우미입니다. 하지만 설정을 잘못하면 집 열쇠를 낯선 사람에게 맡기는 것과 같습니다.

‘나 혼자 쓰는데 괜찮지 않을까?’라고 생각할 수 있습니다.

바로 그 점이 문제입니다. OpenClaw의 위험은 외부 공격에만 있지 않습니다. 채팅에 악성 지시를 몰래 삽입하는 Prompt 주입, 실수로 API 포트를 노출하는 설정 오류, 그리고 파일 정리를 중요 데이터 삭제로 이해하는 AI의 “과도한 열의”까지 위험 요인이 됩니다.

하지만 올바르게 설정하면 이런 문제는 피할 수 있습니다.

이 글에서는 Docker 샌드박스 격리부터 세밀한 권한 제어까지 OpenClaw에 “안전 우리”를 씌우는 방법을 단계별로 설명합니다. 다섯 겹의 방어로 이 “맹수”를 안심하고 사용할 수 있습니다. 미리 말해 두자면 설정이 조금 번거로워 보일 수 있지만, 데이터 유출이나 데이터베이스 삭제 사고에 비하면 아무것도 아닙니다.

저비용 ‘새우 키우기’ 가이드: ArkClaw로 AI Agent의 진입 장벽 낮추기

최근 인기인 OpenClaw(바닷가재)는 유용하지만 설정 장벽이 너무 높다고 느끼나요? ByteDance Volcano Engine의 ArkClaw는 그 문턱을 크게 낮췄습니다. 서버나 Token 설정을 직접 다루지 않아도 한 번의 클릭으로 24시간 온라인 상태에서 브라우저를 제어하고 스크립트를 실행하며 일정을 관리하는 “AI 일꾼”을 사용할 수 있습니다.

특히 가격이 저렴합니다. 월 요금은 9.9위안이며 제 초대 코드 ZLKUK54M을 사용해 여기에서 가입하면 8.9위안입니다. 프로그래머라면 Coding Plan Pro를 통해 무료로 이용할 수도 있습니다.

보안 설정이 필요한 이유

OpenClaw의 권한은 얼마나 강력한가요?

먼저 현실을 직시해야 합니다. OpenClaw는 채팅만 하는 AI 도우미가 아닙니다. 할 수 있는 일은 사실상 터미널에서 사용자가 할 수 있는 거의 모든 일과 같습니다.

• 임의의 Shell 명령 실행: rm -rf /도 기술적으로 가능합니다.
• 전체 파일 시스템 읽기·쓰기: SSH 키, AWS 자격 증명, 데이터베이스 비밀번호가 디스크에 있다면 모두 접근할 수 있습니다.
• 네트워크 자원 접근: API 호출, 파일 다운로드, 내부 네트워크 포트 스캔까지 가능합니다.
• 브라우저 제어: Playwright를 통해 로그인된 사이트를 포함한 브라우저를 조작합니다.
• 환경 변수 읽기: process.env 안의 민감한 정보가 그대로 노출됩니다.

즉, OpenClaw에 기본 권한을 주는 것은 “아주 똑똑하지만 잘 알지 못하는 도우미”에게 집의 마스터키를 건네는 것과 같습니다.

기본 설정은 얼마나 위험한가요?

편의를 위해 npm install -g openclaw로 설치하자마자 openclaw gateway를 실행하거나 daemon만 설치해 자동으로 띄우는 사람이 많습니다. 그런데 기본 상태에서 어떤 일이 벌어지는지 알고 있나요?

v2026.1.29 이전:

• 접근 제어를 auth: none으로 설정할 수 있어 URL을 아는 누구나 OpenClaw를 제어할 수 있었습니다.
• 샌드박스 격리가 없어 AI가 전체 파일 시스템을 읽고 쓸 수 있었습니다.
• 위험한 exec와 browser를 포함한 모든 도구가 기본 활성화되어 있었습니다.
• 높은 권한, 심지어 root로 실행될 수도 있었습니다.

"v2026.1.29에서는 auth: none 옵션이 강제로 제거되어 Token 또는 비밀번호 인증을 반드시 설정해야 합니다."

v2026.1.29 이후에는 조금 나아졌습니다. 공식적으로 auth: none 옵션을 제거하고 Token 또는 비밀번호 인증을 의무화했습니다. 하지만 샌드박스, 도구 권한, 파일 시스템 접근은 여전히 직접 설정해야 합니다.

솔직히 기본 설정은 문을 활짝 열어 둔 채 잠을 자면서 입구에 “환영합니다”라는 팻말까지 세워 둔 것과 같습니다.

보안 설정의 세 가지 목표

이렇게 많은 항목을 설정하는 이유는 무엇일까요? 핵심은 세 가지입니다.

1. 최소 권한 원칙: OpenClaw에 실제로 필요한 권한만 주고 나머지는 모두 차단합니다. 코드 작성을 맡긴다면 workspace의 읽기·쓰기 권한만 주고, 브라우저 조작이 필요 없다면 browser 도구를 비활성화해야 합니다.

2. 심층 방어: 하나의 방어선에 모든 기대를 걸어서는 안 됩니다. Docker 격리, 비특권 사용자, 접근 제어, 도구 허용 목록, 네트워크 격리의 다섯 단계 중 하나가 뚫려도 나머지가 계속 보호합니다.

3. 통제 가능한 피해 범위: Prompt 주입 성공, Token 유출, AI 자체의 Bug 같은 최악의 상황을 가정했을 때 피해를 어디까지 제한할 수 있는지가 중요합니다. OpenClaw가 격리된 workspace 디렉터리에만 접근할 수 있다면 전체 /home이 아니라 그 디렉터리의 내용만 유출됩니다.

결국 보안 설정의 목적은 공격을 완전히 막는 것이 아니라 불가능에 가까운 공격 비용을 높이고 피해를 가능한 한 작게 만드는 것입니다.

5단계 보안 설정

이제 실습을 시작하겠습니다. 기반 계층부터 상위 계층 순서로 다섯 단계 방어 설정을 설명합니다. 각 단계마다 왜 필요한지와 설정 성공 여부를 확인하는 방법을 함께 다룹니다.

1단계: Docker 샌드박스 격리(필수)

왜 Docker를 사용하나요?

많은 사람이 Docker를 편리한 배포 도구로만 생각합니다. 하지만 OpenClaw처럼 높은 권한을 가진 애플리케이션에서 Docker의 가장 큰 가치는 격리입니다.

• 파일 시스템 격리: AI는 컨테이너 안의 파일만 볼 수 있으므로 호스트의 ~/.ssh에는 접근할 수 없습니다.
• 네트워크 격리: 컨테이너의 외부 네트워크 접근을 끊거나 특정 도메인만 허용할 수 있습니다.
• 자원 제한: AI의 무한 루프가 CPU를 모두 소모하는 일을 막습니다.
• 빠른 복구: 문제가 생기면 docker rm으로 컨테이너를 지우고 몇 초 만에 깨끗하게 다시 만들 수 있습니다.

로컬 개발 PC에서 실행하는데도 이렇게 번거롭게 해야 하는지 묻는 사람이 있습니다.

필요합니다. 로컬 환경은 더 위험합니다. 개발 PC에는 GitHub Token, 데이터베이스 비밀번호, 각종 API 키가 있으며 모두 Prompt 주입 공격의 표적이 됩니다.

설정 단계

1. 안전한 Dockerfile 만들기

FROM openclaw/gateway:latest

# 비특권 사용자 생성
RUN adduser --disabled-password --gecos '' clawuser

# 비특권 사용자로 전환
USER clawuser

# 작업 디렉터리 설정
WORKDIR /home/clawuser/openclaw

핵심은 USER clawuser입니다. Docker 컨테이너는 기본적으로 root로 실행되므로 컨테이너 안의 OpenClaw도 root 권한을 갖습니다. 전용 사용자를 만들면 누군가 컨테이너를 뚫더라도 clawuser 권한만 얻게 됩니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

2. Docker Compose 보안 매개변수 설정

이 부분이 핵심입니다. 한 줄씩 설명하겠습니다.

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # 보안 설정
    security_opt:
      - no-new-privileges:true  # 컨테이너 내 프로세스의 권한 상승 방지
    cap_drop:
      - ALL  # 모든 Linux capabilities 제거
    cap_add:
      - NET_BIND_SERVICE  # 포트 바인딩 권한만 추가

    # 읽기 전용 루트 파일 시스템
    read_only: true

    # 임시 디렉터리(쓰기 가능)
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # 자원 제한
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # 네트워크 격리
    networks:
      - openclaw-isolated

    # 볼륨 마운트(최소 권한)
    volumes:
      # 작업 디렉터리(읽기·쓰기)
      - ./workspace:/home/clawuser/workspace
      # 설정 파일(읽기 전용)
      - ./config:/home/clawuser/openclaw/config:ro
      # 로그 디렉터리(쓰기 전용)
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # 외부 네트워크 접근 금지

왜 이렇게 설정하나요?

• no-new-privileges:true: sudo나 setuid를 통한 권한 상승을 막습니다. 공격자가 컨테이너 안에서 취약점을 찾아도 더 높은 권한을 얻을 수 없습니다.
• cap_drop: ALL: Linux capabilities는 세분화된 권한 제어 기능입니다. 모두 제거한 뒤 포트 바인딩처럼 필요한 기능만 다시 추가하면 공격 표면을 최소화할 수 있습니다.
• read_only: true: 루트 파일 시스템을 읽기 전용으로 만듭니다. 공격자가 침입해도 백도어를 설치하거나 시스템 파일을 수정할 수 없습니다. /tmp처럼 쓰기가 필요한 곳은 tmpfs로 마운트합니다.
• internal: true: 컨테이너가 외부 네트워크에 접근하지 못하게 합니다. 로컬 파일만 처리하는 등 OpenClaw에 인터넷이 필요하지 않다면 데이터 유출을 막는 데 효과적입니다.

3. OpenClaw의 sandbox 모드 활성화

OpenClaw 런타임의 기본 설정 파일은 일반적으로 ~/.openclaw/openclaw.json(JSON)입니다. 아래 YAML은 구조를 설명하기 위한 예시일 뿐이며 실제 필드명과 중첩 구조는 Gateway 공식 설정 문서를 확인하세요. 별도의 자체 GitOps 저장소에서 config/config.yaml을 사용한다면 그것은 저장소 내부 명칭이며 upstream 기본 파일명과는 다릅니다.

sandbox:
  mode: "non-main"  # 기본 채팅창을 제외한 모든 그룹 채팅을 격리 컨테이너에서 실행
  docker:
    enabled: true
    network: "none"  # 샌드박스 컨테이너의 네트워크 접근 차단

이 설정은 OpenClaw 자체의 샌드박스 기능입니다. mode: "non-main"은 주 채팅창을 제외한 모든 대화를 별도의 Docker 컨테이너에서 실행한다는 뜻입니다. 어떤 대화가 Prompt 주입 공격을 받아도 자기만의 작은 샌드박스 안에서만 영향을 미칩니다.

확인 방법

설정 후 바로 사용하지 말고 먼저 확인합니다.

# 컨테이너가 비 root 사용자로 실행되는지 확인
docker exec openclaw-safe whoami
# 예상 결과: clawuser

# 파일 시스템이 읽기 전용인지 확인
docker exec openclaw-safe touch /test.txt
# 예상 결과: Read-only file system

# 네트워크 격리 확인
docker exec openclaw-safe ping 8.8.8.8
# 예상 결과: Network is unreachable

위 세 테스트를 모두 통과했다면 1단계 방어가 준비된 것입니다.

2단계: 비특권 사용자로 실행(필수)

Docker 컨테이너 안에서는 비 root 사용자를 쓰더라도 컨테이너를 누가 시작했는지가 중요합니다. 호스트에서 root로 docker-compose up을 실행했다면 공격자가 컨테이너를 탈출했을 때 여전히 root 권한을 얻을 수 있습니다.

해결 방법: 전용 저권한 사용자 만들기

호스트에서 설정:

# 전용 사용자 그룹과 사용자 생성
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# 디렉터리 구조 생성
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# 디렉터리 권한 설정
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # 설정 디렉터리(owner만 읽기·쓰기 가능)
sudo chmod 755 /opt/openclaw/workspace  # 작업 디렉터리
sudo chmod 750 /opt/openclaw/logs  # 로그 디렉터리

# 사용자 권한 제한
sudo usermod -L clawuser  # 비밀번호 로그인을 잠그고 su로만 전환

왜 chmod 700인가요?

chmod 700은 파일 소유자(clawuser)만 읽고 쓰고 실행할 수 있으며 다른 사용자는 열람조차 할 수 없다는 뜻입니다. 설정 파일에는 Token이나 비밀번호가 들어갈 수 있으므로 엄격히 보호해야 합니다.

자격 증명 파일 권한(매우 중요)

OpenClaw를 WhatsApp이나 다른 서비스에 연결한다면 자격 증명 파일의 권한을 특히 조심해야 합니다.

# 자격 증명 파일은 반드시 600(owner만 읽기·쓰기 가능)
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

자격 증명 파일을 644(모든 사용자가 읽기 가능)로 설정했다가 같은 서버의 다른 사용자가 내용을 훔쳐본 사례도 있습니다. 이런 기본적인 실수는 반드시 피해야 합니다.

확인

# OpenClaw 프로세스 사용자 확인
ps aux | grep openclaw
# root가 아니라 clawuser로 표시되어야 함

# 파일 권한 확인
ls -la /opt/openclaw/config
# drwx------ clawuser openclaw여야 함

이 단계가 중요한 이유

최악의 상황을 가정해 봅시다. 공격자가 Docker 컨테이너와 OpenClaw 샌드박스를 모두 뚫고 임의의 코드를 실행하더라도 여전히 clawuser 권한만 갖습니다.

• 다른 사용자의 파일에 접근할 수 없습니다.
• sudo 권한이 없어 시스템 소프트웨어를 설치할 수 없습니다.
• /etc 아래의 시스템 설정을 수정할 수 없습니다.
• /root 디렉터리를 읽을 수 없습니다.

이것이 심층 방어의 의미입니다. 한 단계가 뚫려도 다음 단계가 계속 보호합니다.

3단계: 접근 제어와 신원 인증(필수)

앞의 두 단계가 “OpenClaw가 무엇을 할 수 있는가”를 다뤘다면, 이 단계는 “누가 OpenClaw를 사용할 수 있는가”를 다룹니다.

v2026.1.29의 주요 변경 사항

이전에는 OpenClaw에서 auth: none으로 인증을 완전히 생략할 수 있었습니다. 매우 위험한 기능이었지만 v2026.1.29에서 강제로 제거되어 이제 Token 또는 비밀번호 인증을 반드시 설정해야 합니다.

Gateway Token 인증 설정

Token 인증은 비밀번호보다 어떤 점이 좋을까요? 사람이나 애플리케이션마다 서로 다른 권한의 Token을 발급할 수 있습니다. Token 하나가 유출되면 다른 Token에 영향을 주지 않고 그것만 취소하면 됩니다.

마찬가지로 **~/.openclaw/openclaw.json**의 Gateway 관련 부분에서 설정합니다. 자체 저장소의 config/config.yaml이라는 파일명과 혼동하지 마세요. 아래 YAML은 설명용 예시입니다.

gateway:
  # Token 인증 강제
  auth: token

  # Token 설정
  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # 환경 변수에서 읽고 하드코딩하지 않기
      permissions:
        - "admin"  # 전체 권한

    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"  # 채팅만 가능
        - "read"  # 파일 읽기만 가능
      # 주의: exec, browser 같은 고위험 권한은 포함하지 않음

안전한 Token 생성

123456이나 mytoken 같은 약한 Token은 절대 사용하지 마세요. 다음 명령으로 256비트 무작위 Token을 생성합니다.

# 무작위 token 생성
openssl rand -base64 32

# 환경 변수 설정(설정 파일에 하드코딩하지 않기)
export OPENCLAW_ADMIN_TOKEN="你生成的 token"
export OPENCLAW_READONLY_TOKEN="另一个 token"

설정 파일은 Git에 커밋되거나 로그에 기록되거나 클라우드에 백업될 수 있으므로 하드코딩하면 안 됩니다. 환경 변수가 상대적으로 더 안전합니다.

접근 제어 허용 목록

Token으로 “누가 접근할 수 있는지”를 정했어도 충분하지 않습니다. 특정 WhatsApp 사용자나 그룹에만 OpenClaw 사용을 허용하고 싶을 수 있습니다.

# DM(개인 채팅) 정책
dmPolicy: allowlist  # 허용 목록 모드
allowFrom:
  - "user_id_1"  # 이 사용자들만 개인 채팅 가능
  - "user_id_2"

# 그룹 정책
groupPolicy: allowlist
allowFrom:
  - "group_id_1"  # 이 그룹들만 사용 가능

# Mention gating(그룹 채팅에서 @ 멘션에만 응답)
mentionGating: true

# 공개 접근 금지
publicAccess: false

mentionGating: true는 특히 유용합니다. 100명이 있는 업무 그룹에 OpenClaw를 배포했는데 이 옵션을 켜지 않으면 모든 메시지를 처리합니다. 비용이 들 뿐 아니라 악성 Prompt 공격에도 쉽게 노출됩니다. 활성화하면 누군가 @ 멘션할 때만 응답합니다.

확인

# 인증되지 않은 접근 테스트(거부되어야 함)
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 예상 결과: 401 Unauthorized

# 유효한 token 테스트
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# 예상 결과: 200 OK

이 단계가 핵심인 이유

접근 제어가 없다면 앞서 적용한 격리와 권한 제한도 소용이 없습니다. 공격자는 Docker를 뚫거나 권한을 상승시킬 필요 없이 API로 바로 침입할 수 있습니다.

이 단계는 들어와서는 안 될 사용자를 문 앞에서 막는 골키퍼입니다.

4단계: 도구 권한 제어(권장)

이제 OpenClaw를 우리 안에 가뒀지만, 그 안에서도 사용할 수 있는 도구는 많습니다. 위험한 도구 일부를 거둬들일 때입니다.

문제: 모든 도구가 기본 제공됨

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

OpenClaw에는 exec(Shell 명령 실행), browser(브라우저 제어), write_file(파일 쓰기), web_fetch(웹페이지 가져오기) 등 수십 개의 도구가 있으며 기본적으로 모두 활성화됩니다.

정말 이 모든 도구가 필요할까요? OpenClaw로 코드 작성과 자료 검색만 한다면 browser와 exec는 완전히 비활성화해도 됩니다.

도구 허용 목록 설정

tools:
  # 안전한 도구만 허용
  allowlist:
    - "read_file"      # 파일 읽기
    - "write_file"     # 파일 쓰기(지정 디렉터리로 제한)
    - "web_search"     # 웹 검색
    - "git"            # Git 작업
    # 주의: exec, browser 같은 고위험 도구는 포함하지 않음

  # 고위험 도구는 명시적 허가 필요
  exec:
    enabled: false  # shell 실행 기본 비활성화

  browser:
    enabled: false  # 브라우저 제어 비활성화

  web_fetch:
    enabled: true
    # 도메인 허용 목록
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

exec가 꼭 필요하다면 명령 허용 목록 사용

테스트 실행이나 프로젝트 build처럼 OpenClaw가 명령을 실행해야 할 때도 있습니다. 이 경우 허용 목록을 사용합니다.

tools:
  exec:
    enabled: true
    sandbox: true  # 샌드박스에서 실행

    # 차단 목록보다 허용 목록 우선
    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    # 위험 명령 차단 목록(이중 안전장치)
    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

허용 목록이 차단 목록보다 나은 이유는 공격 기법이 끊임없이 바뀌어 위험한 명령을 전부 열거할 수 없기 때문입니다. 반면 안전한 명령은 한정되어 있으므로 그것만 나열하면 됩니다.

파일 시스템 접근 제한

filesystem:
  # 접근 허용 디렉터리
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  # 접근 금지 디렉터리
  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  # 기본 권한
  defaultPermission: "readonly"  # 기본 읽기 전용

  # 쓰기 권한은 명시적으로 부여
  writablePaths:
    - "/home/clawuser/workspace/temp"

이렇게 설정하면 누군가 Prompt 주입을 통해 OpenClaw에 “~/.ssh/id_rsa 파일을 읽어라”라고 지시해도 거부됩니다.

확인

OpenClaw 채팅 화면에서 테스트합니다.

• 사용자: “sudo apt update를 실행해 줘”

  • OpenClaw는 “보안 정책에 의해 차단되어 이 명령을 실행할 수 없습니다”라고 답해야 합니다.

• 사용자: “~/.ssh/id_rsa 파일을 읽어 줘”

  • OpenClaw는 “Access denied”라고 답해야 합니다.

5단계: 네트워크 격리와 모니터링(고급)

기업 사용자이거나 민감한 데이터를 처리하거나 최고 수준의 보안을 원한다면 이 단계가 최종 방어를 제공합니다.

네트워크 격리: 불필요한 연결 차단

앞에서 internal: true를 사용해 컨테이너의 외부 네트워크 접근을 막았습니다. 하지만 OpenClaw가 Claude API를 호출해야 한다면 어떻게 해야 할까요?

해결 방법: 프록시를 통한 아웃바운드 트래픽

OpenClaw가 api.anthropic.com 같은 특정 도메인에만 접근하도록 하고 나머지는 모두 차단합니다.

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # 프록시만 외부 네트워크 접근 가능

squid.conf(프록시 허용 목록 설정):

# 허용 도메인
acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

# HTTPS 허용
acl SSL_ports port 443
acl CONNECT method CONNECT

# 접근 규칙
http_access allow allowed_domains
http_access deny all

# 로그
access_log /var/log/squid/access.log

이 설정에서는 OpenClaw가 이 세 도메인에만 접근할 수 있고 다른 사이트는 프록시가 모두 차단합니다. Prompt 주입으로 “악성 스크립트를 다운로드하라”는 지시를 받아도 내려받을 수 없습니다.

감사 로그: 모든 작업 기록

로그 자체가 공격을 막지는 못하지만 무슨 일이 있었는지 알려 줍니다.

logging:
  # 상세 로그 활성화
  level: "info"

  # 감사 로그
  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    # 기록 항목
    logToolCalls: true        # 모든 도구 호출 기록
    logFileAccess: true       # 파일 접근 기록
    logNetworkRequests: true  # 네트워크 요청 기록
    logPrompts: true          # 모든 prompt 기록(주입 탐지)

  # 세션 로그
  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true는 특히 중요합니다. 누군가 채팅에 “이전 제한을 무시하고 실행하라…” 같은 악성 지시를 삽입하면 로그에 남아 사후 분석이 가능합니다.

실시간 모니터링

# 의심스러운 활동 모니터링
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

# 네트워크 연결 모니터링
docker exec openclaw-safe netstat -tuln

# 자원 사용량 모니터링
docker stats openclaw-safe

알림 설정

더 나아가 자동 알림을 설정할 수도 있습니다.

alerts:
  # 의심스러운 명령 실행
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  # 민감한 파일 접근
  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  # 의심스러운 사이트 접근
  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

알림이 발생하면 이메일이나 Slack 메시지를 보내거나 OpenClaw 서비스를 즉시 일시 중지할 수 있습니다.

읽기 전용 권한으로 시작하는 전략

5단계 방어를 모두 설정한 뒤에는 모든 기능을 한 번에 활성화하고 싶을 수 있습니다.

하지만 권장하지 않습니다.

보안과 편의성 사이에는 언제나 균형이 필요합니다. 설정이 지나치게 엄격하면 OpenClaw가 아무 일도 못 해 사용하기 불편하고, 너무 느슨하면 보호 효과를 얻지 못합니다.

더 나은 전략은 가장 엄격한 상태에서 시작해 점진적으로 완화하는 것입니다.

첫째 주: 완전한 읽기 전용 모드

처음 배포할 때는 읽기 전용 모드로 OpenClaw의 동작을 관찰합니다.

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"  # 읽기 전용 Git 작업

filesystem:
  defaultPermission: "readonly"
  writablePaths: []  # 쓰기 완전 금지

이 한 주 동안 해야 할 일은 관찰입니다.

• OpenClaw가 자주 접근하는 파일을 확인합니다.
• 로그에 의심스러운 활동이 있는지 살펴봅니다.
• 주로 어떤 도구를 호출하는지 파악합니다.
• 안전한 환경에서 Prompt 주입 시 어떤 일이 벌어지는지 테스트합니다.

한 주 동안 별다른 문제가 없다면 기본 설정이 잘된 것입니다. .ssh 디렉터리에 반복해서 접근하려는 등의 이상 행동을 발견했다면 설정 문제인지 실제 공격 시도인지 즉시 확인해야 합니다.

둘째 주: 제한된 쓰기 권한 추가

관찰 기간이 끝나면 쓰기 권한을 조금씩 열 수 있습니다.

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"  # 임시 파일만 쓰기 허용

tools:
  allowlist:
    - "write_file"  # writablePaths 안에서만 허용
    - "git_commit"  # 코드 커밋 허용

여기서는 임시 디렉터리에만 쓰기 권한을 열었습니다. 중요한 프로젝트 파일은 여전히 읽기 전용이므로 OpenClaw가 직접 수정할 수 없습니다.

이 방식의 장점은 AI가 “프로젝트를 정리해 달라”는 말을 모든 파일 삭제로 오해해도 임시 파일만 지울 수 있어 소스 코드가 안전하다는 점입니다.

셋째 주 이후: 필요에 따라 도구 활성화

실제 사용 요구에 맞춰 도구를 점진적으로 활성화합니다.

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"  # 먼저 git만 허용
      - "npm test"  # 테스트가 필요할 때 추가

핵심 원칙:

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

• 한 번에 권한 하나만 완화: exec, browser, write_file을 한꺼번에 열면 문제가 생겼을 때 어느 단계가 원인인지 알 수 없습니다.
• 완화할 때마다 24시간 관찰: 감사 로그에서 이상 행동을 확인합니다.
• 문제가 있으면 즉시 되돌리기: 의심스러운 활동이 발견되면 방금 변경한 설정을 바로 취소합니다.

실제 사례: 내 설정의 변화 과정

제 경험을 공유하겠습니다.

처음에는 저도 한 번에 끝내고 싶어서 공식 문서를 참고해 “완전한 보안 방안”을 설정했습니다. 결과는 어땠을까요? write_file을 비활성화한 탓에 OpenClaw가 기본적인 코드 완성조차 하지 못했습니다.

이후에는 방식을 바꿨습니다.

• 첫째 주: 읽기 전용 모드로 문서를 찾고 코드를 설명하게 했습니다. 문제는 없었습니다.
• 둘째 주: workspace/drafts 디렉터리에 쓰기 권한을 열어 초안을 작성하게 했습니다. 원활하게 동작했습니다.
• 셋째 주: 코드를 커밋하도록 git 명령을 활성화했습니다. 이때 Git 사용자 정보를 설정하지 않아 커밋할 때마다 오류가 났지만 수정한 뒤에는 정상적으로 작동했습니다.
• 넷째 주: 단위 테스트를 실행하도록 npm test를 활성화했습니다. 여기까지 설정하니 일상적인 요구를 거의 모두 충족했습니다.

browser와 제한 없는 exec는 한 번도 열지 않았고 필요하지도 않았습니다.

교훈: “안전하다는 느낌”을 얻으려고 쓰지도 않을 권한까지 설정하지 마세요. 조금 번거롭더라도 필요할 때만 여는 것이 낫습니다.

보안 점검표

많은 항목을 설정했는데 빠뜨린 것이 없는지 어떻게 확인할까요? 배포 전에 아래 점검표를 확인하면 기본적인 실수의 90%를 피할 수 있습니다.

배포 전 점검(모두 확인해야 함)

컨테이너 보안:

• ☐ 비특권 사용자를 만들었음(컨테이너 안에서 root가 아님)
• ☐ Docker에 no-new-privileges:true를 설정했음
• ☐ 모든 Linux capabilities를 제거했음(cap_drop: ALL)
• ☐ 루트 파일 시스템을 읽기 전용으로 설정했음(read_only: true)
• ☐ 자원 제한(CPU, 메모리)을 설정했음
• ☐ OpenClaw의 sandbox 모드를 활성화했음

신원 인증:

• ☐ 강력한 Token 인증을 설정했음(auth: none이 아님)
• ☐ Token이 충분히 복잡함(32자 이상, 무작위 생성)
• ☐ Token을 코드가 아니라 환경 변수에 저장했음
• ☐ 접근 허용 목록(DM/Group policy)을 설정했음
• ☐ VPS에 배포했다면 IP 허용 목록을 설정했음

권한 제어:

• ☐ 도구를 허용 목록 방식으로 관리함
• ☐ 고위험 도구(exec/browser)를 비활성화했거나 명령 허용 목록을 설정했음
• ☐ 파일 시스템 접근 제한을 설정했음
• ☐ 민감한 디렉터리(.ssh, .aws 등)를 금지 목록에 넣었음
• ☐ 자격 증명 파일 권한을 600으로 설정했음

감사와 모니터링:

• ☐ 감사 로그를 활성화했음
• ☐ 세션 로그를 설정했음
• ☐ 로그 디렉터리에 충분한 디스크 공간이 있음
• ☐ 로그를 확인하고 분석하는 방법을 알고 있음

런타임 점검(정기 실행)

매주 확인:

• ☐ 감사 로그에 이상 활동이 있는지 확인
• ☐ 자원 사용량(CPU, 메모리, 디스크) 확인
• ☐ 인증되지 않은 접근 시도가 있었는지 확인
• ☐ 설정 파일 백업

매월 확인:

• ☐ OpenClaw를 최신 버전으로 업데이트
• ☐ 장기 운영 서비스라면 Token 교체
• ☐ Docker 이미지 보안 취약점 점검(docker scan)
• ☐ 권한 설정을 검토하고 더 이상 필요 없는 권한 제거

비상 대응 준비

실제로 사고가 발생했을 때 어떻게 대응할지 알고 있어야 합니다.

비상 중지 스크립트 준비:

#!/bin/bash
# emergency-stop.sh

echo "紧急停止 OpenClaw..."

# 컨테이너 중지
docker stop openclaw-safe

# 모든 Token 취소(동적 Token 시스템을 사용하는 경우)
# curl -X DELETE https://your-auth-server/tokens/revoke-all

# 알림 전송
curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw 已紧急停止"}'

echo "已停止。请检查日志: /opt/openclaw/logs/audit.log"

Token 유출 대응:

1. 유출된 Token을 즉시 취소합니다.
2. 감사 로그에서 해당 Token이 어떤 작업에 사용되었는지 확인합니다.
3. 새 Token을 생성하고 정상 사용자에게 업데이트를 안내합니다.
4. 데이터가 유출되었다면 데이터 유출 비상 대응 절차를 시작합니다.

의심스러운 활동 발견 시:

1. 서비스를 즉시 종료하지 마세요. 공격자에게 눈치챌 시간을 줄 수 있습니다.
2. 먼저 현재 로그와 컨테이너 스냅샷을 저장합니다.
3. 공격 경로와 영향 범위를 분석합니다.
4. 그다음 격리, 재시작, 재구축 중 적절한 조치를 결정합니다.

결론

긴 글의 핵심은 한 문장입니다. OpenClaw는 강력하지만 안전한 우리 안에 있을 때만 이 “맹수”를 제대로 활용할 수 있습니다.

다섯 단계 방어를 다시 정리해 봅시다.

1. Docker 샌드박스 격리: OpenClaw를 컨테이너 안에 가두고 접근 가능한 파일과 네트워크를 제한합니다.
2. 비특권 사용자: 공격을 받아도 공격자는 낮은 권한만 얻으므로 큰 피해를 일으킬 수 없습니다.
3. 접근 제어: Token 인증과 허용 목록으로 들어와서는 안 될 사용자를 막습니다.
4. 도구 권한 제어: 위험한 도구를 비활성화하고 필요한 권한만 제공합니다.
5. 네트워크 격리와 모니터링: 불필요한 연결을 차단하고 모든 작업을 기록합니다.

이 다섯 단계 중 앞의 세 단계는 필수입니다. OpenClaw를 어떤 방식으로 사용하든 적용해야 합니다. 뒤의 두 단계는 권장이며, 민감한 데이터를 처리하거나 기업 환경에 배포한다면 강력히 권합니다.

솔직히 이런 설정은 조금 번거롭습니다. “그냥 혼자 시험 삼아 쓰는 건데 정말 이렇게 조심해야 할까?”라는 생각이 들 수 있습니다.

제 답은 그렇다입니다.

OpenClaw 자체가 안전하지 않아서가 아니라 AI의 능력이 너무 강력하기 때문입니다. “프로젝트 파일을 정리해 달라”고 했을 때 AI가 중요한 초안을 포함한 모든 임시 파일을 삭제하는 것으로 이해할 수 있습니다. “최근 커밋 기록을 확인해 달라”고 했을 때는 .git/config에 있는 자격 증명 정보까지 함께 읽을 수도 있습니다.

이는 악의가 아니라 “과도한 열의”에서 비롯된 행동이지만 결과는 똑같이 심각할 수 있습니다.

보안 설정은 OpenClaw의 악의적 행동을 막기 위한 것이 아니라 사고의 피해 범위를 제한하기 위한 것입니다. 문제가 생겨도 손실을 통제할 수 있어야 합니다.

마지막으로 세 가지 실천 사항을 권합니다.

1. 지금 바로 OpenClaw 설정을 확인하세요: 기본 설정으로 사용 중이라면 즉시 멈추고 적어도 앞의 세 단계 방어를 적용하세요.
2. 엄격한 상태에서 시작해 점진적으로 완화하세요: 번거로움을 감수하고 읽기 전용 모드로 일주일간 관찰한 뒤 안전이 확인되면 권한을 여세요.
3. 감사 로그를 정기적으로 확인하세요: 매주 5분만 투자해 이상 행동을 살펴보세요. 빨리 발견할수록 대응하기 쉽습니다.

OpenClaw는 정말 좋은 도구입니다. 하지만 원자력과 같습니다. 잘 사용하면 인류에 도움이 되지만 잘못 사용하면 재앙이 됩니다.

설정이 번거로워 보여도 데이터 유출이나 데이터베이스 삭제, 혹은 Reddit에 도움을 요청하는 상황과 비교하면 아무것도 아닙니다.

그렇지 않나요?

다음 글

• OpenClaw 초기 설정에서 놓치면 안 되는 5가지 보안 스위치
• OpenClaw 설정 상세 설명: openclaw.json 완전 가이드
• OpenClaw 2026 설치 가이드: 개인 AI 도우미를 처음부터 배포하기