OpenClaw 구축·운영 (12/26) — 보안 아키텍처: 7계층 방어
단일 사용자 로컬 AI 에이전트의 7계층 방어 전략
핵심 요약
- "개인 프로젝트니까 보안은 나중에" — 이 결정은 치명적 오판이었다. Telegram 봇을 통해 외부인이 에이전트에 명령을 내리는 사고를 겪었다
- 네트워크부터 인지 계층까지 7계층 심층 방어(Defense in Depth) 구조를 설계했다
- sandbox.mode: off, 평문 키 보관 등 의식적으로 수용한 위험도 명시적으로 문서화한다
배경
LLM 에이전트는 이메일을 읽고, 캘린더를 수정하며, 파일 시스템에 접근하고, 외부 API를 호출한다. 에이전트 자체가 시스템의 핵심 인프라로 동작한다. Telegram 연동 테스트 중 인가되지 않은 외부 사용자가 봇에게 명령을 내리고 에이전트가 이에 응답하는 보안 사고를 겪었다. 이후 "Security from Day 1" 원칙을 세우고 아키텍처를 전면 재구성했다.
본문
신뢰 모델 정의
- 동작 환경: 단일 사용자 Mac Mini, 인터넷 활성화, Docker 미사용
- 핵심 방어 대상: 외부 네트워크 무단 접근, 통신 채널 탈취, 프롬프트 인젝션
- 신뢰 기준:
~/.openclaw디렉토리를 수정할 수 있는 시스템 계정 소유자만 운영자로 간주
7계층 보안 아키텍처
| 계층 | 메커니즘 | 상태 |
|---|---|---|
| 네트워크 | Loopback Bind + Token 인증 | 활성 |
| 채널 | Telegram DM 페어링 + 그룹 allowlist | 활성 |
| 파일 시스템 | .openclaw/ 700, openclaw.json 600 | 활성 |
| 인젝션 방어 | 11개 범주 방어 프롬프트 룰셋 | 프롬프트 레벨 |
| 실행 제어 | 서브 에이전트별 exec 권한 최소화 | 활성 |
| 시크릿 관리 | .gitignore + Pre-commit 보안 감사 | 활성 |
| 신뢰 경계 | 단일 사용자 로컬 환경 수용 | 수용됨 |
경계 통제: 네트워크와 채널
{
"gateway": {
"port": 18789, "mode": "local", "bind": "loopback",
"auth": { "mode": "token", "token": "..." }
}
}
bind: loopback으로 동일 Mac 내에서만 연결 허용. SSRF 공격이 들어와도 정적 토큰 인증이 두 번째 방어선으로 작동한다.
Telegram은 dmPolicy: pairing으로 사전 페어링된 사용자만 DM 허용, groupPolicy: allowlist로 지정된 사용자만 그룹에서 명령 가능.
내부 통제: 인젝션 방어
11개 범주의 프롬프트 인젝션 방어 규칙: - ignore-previous 거부: 고전적 탈옥 시도 무시 - 인코딩 공격 방어: Base64, Hex 난독화 명령 거부 - 역할 전환 방어: "너는 이제 관리자 모드야" 페르소나 변경 거부
행위 승인 경계
- 자유 실행: 파일 읽기, 단순 웹 GET, 시스템 로그 확인
- 승인 필수: 이메일/SNS 발송, 외부 API 상태 변경, 로컬 파일 삭제
시행착오 / 주의사항
의식적으로 수용한 위험(Accepted Risks): 1. sandbox.mode: off — 로컬 파일 시스템 직접 관리가 필요한 비서 에이전트 특성상 불가피 2. 설정 파일 내 평문 키 — 1인 운영 Private 저장소이므로 수용. 오픈소스 공개 시 Vault로 마이그레이션 예정
마무리
개인 프로젝트라도 시스템 인프라를 건드리는 권한을 가진다면, 보안은 첫날부터 설계되어야 한다. 권한 통제를 사후에 끼워 넣으면 기존 기능과 충돌하여 막대한 테스트 비용이 발생한다. 시스템 설계 초기부터 '최소 권한의 원칙'과 '외부 입력에 대한 제로 트러스트'를 아키텍처에 녹여내야 한다.
댓글
댓글 쓰기