OpenClaw는 사람들이 AI를 사용하는 방식에 큰 변화를 가져왔습니다. 클라우드에서 호스팅되는 챗봇이 아니라 노트북이나 워크스테이션에서 로컬로 실행되는 OpenClaw는 사용자를 대신하여 코드를 작성하고, 파일을 관리하고, 도구를 호출하고, 자율적으로 작동할 수 있는 기능을 제공합니다.
그 힘이 바로 판돈을 키우는 힘입니다.
OpenClaw는 활발하고 빠른 속도로 개발 중이며 새로운 기능이 빠르게 추가되고 있습니다. 이러한 속도는 강점이지만 인증, 권한 부여, 감사 가능성과 같은 기본 영역이 여전히 진화하고 있다는 의미이기도 합니다. OpenClaw 에이전트가 더욱 자율적이고 널리 사용됨에 따라 이러한 격차는 초기 단계의 트레이드오프에서 실제 보안 위험으로 옮겨가고 있습니다.
이 문서에서는 OpenClaw의 현재 인증 모델, 최근 개선 사항(신뢰할 수 있는 프록시 모드 포함), 아직 부족한 점, 그리고 이를 Aryaka AI>Secure와 같은 엔터프라이즈 ZTNA와 통합하는 것이 가장 깔끔하고 확장 가능한 솔루션인 이유에 대해 살펴봅니다.
OpenClaw의 기본 인증: 토큰 기반 액세스
현재 OpenClaw는 주로 공유 비밀 토큰 모델에 의존하고 있습니다.
설정하는 동안 OpenClaw는 게이트웨이 토큰(길고 임의의 비밀 문자열)을 생성하여 로컬에 저장합니다(예: 사용자의 홈 디렉토리 내 OpenClaw 구성 파일 아래). 이 토큰은 로컬 HTTP 인터페이스를 통해 OpenClaw 에이전트에 액세스하는 데 필요한 자격 증명 역할을 합니다.
사용자가 OpenClaw 브라우저 기반 제어 UI를 열면 이 토큰을 제공하라는 메시지가 표시됩니다. 토큰을 제공하면 브라우저는 반복적인 인증 프롬프트 없이 에이전트와 통신할 수 있습니다.
최근 버전에서는 새 브라우저 세션이 연결을 시도할 때 터미널에서 수동 승인을 추가했습니다. 이는 의미 있는 안전 개선 사항이지만 핵심 신뢰 모델을 변경하지는 않습니다:
토큰을 소유한 사람은 누구나 에이전트에 대한 전체 액세스 권한을 갖습니다.
아직 사용자 ID, MFA, 역할 분리 또는 상황별 평가가 없습니다.
브라우저 지속성: 위험을 감수하는 편의성
사용 편의성을 위해 브라우저 UI는 일반적으로 토큰을 로컬 (예: 브라우저 저장소)에 유지합니다. 이렇게 하면 반복되는 프롬프트는 피할 수 있지만 예측 가능한 위험이 발생합니다:
- 토큰은 수명이 긴 자격 증명이 됩니다.
- 멀웨어 또는 악성 브라우저 확장 프로그램이 이를 추출할 수 있습니다.
- 세션 만료 또는 컨텍스트 유효성 검사가 없습니다.
보안 관점에서 토큰은 사용자 로그인이라기보다는 API 키처럼 작동합니다.
단일 사용자 및 다중 사용자 시나리오의 리스크
단일 사용자 설정에서도 멀웨어 또는 브라우저 감염을 통한 토큰 유출은 전체 에이전트 탈취로 이어집니다.
공유 환경이나 팀 환경에서는 상황이 더 악화됩니다:
- 사용자 ID 없음
- 역할 또는 권한 없음
- 개인에게 작업을 귀속시킬 수 있는 방법 없음
- 세분화된 취소 기능 없음
- 엔터프라이즈급 감사 추적 없음
이는 기업, 규제 또는 프로덕션 사용과는 근본적으로 호환되지 않습니다.
신뢰할 수 있는 프록시 모드: 올바른 아키텍처 방향
이러한 한계를 해결하기 위해 OpenClaw는 신뢰할 수 있는 프록시 모드를 도입했으며, 이는 매우 의미 있고 긍정적인 아키텍처 단계입니다.
신뢰할 수 있는 프록시 모드에서:
- OpenClaw는 지정된 업스트림 프록시에서만 요청을 수락합니다.
- 게이트웨이 토큰은 해당 프록시에만 국한됩니다.
- 최종 사용자는 상담원과 직접 상호작용하지 않습니다.
이 설계는 ID 및 액세스 제어가 에이전트 외부에 있어야 한다는 핵심 원칙을 명시적으로 인정합니다.
ZTNA 통합: 신원 주입을 안전하게 수행
바로 이 지점에서 ZTNA는 OpenClaw의 신뢰할 수 있는 프록시 설계와 깔끔하고 의도적으로 통합됩니다.
Aryaka AI>Secure와 같은 ZTNA 플랫폼은 OpenClaw 앞에 위치하여 트래픽이 에이전트에 도달하기 전에 전체 인증, 권한 부여 및 계정(AAA) 을 수행합니다.
엔터프라이즈 IdP(Okta, Azure AD, Google Workspace)를 통해 사용자를 인증하고, MFA를 적용하고, 디바이스 상태를 확인한 후 ZTNA는 일반적으로 다음과 같은 헤더를 사용하여 확인된 ID 컨텍스트가 삽입된 요청을 OpenClaw에 전달합니다:
- X-포워딩 사용자
- X-포워딩 그룹
OpenClaw의 신뢰할 수 있는 프록시 모드는 구성된 프록시에서만 이러한 헤더를 신뢰하도록 설계되었습니다.
중요한 보안 요구 사항: 블라인드 헤더 포워딩 금지
한 가지 점을 명확히 해야 합니다:
ZTNA는 클라이언트 연결에서 상담원에게 ID 헤더를 무작위로 전달해서는 안 됩니다.
X-Forwarded-User와 같은 헤더가 클라이언트 요청에서 직접 복사되는 경우, 공격자는 간단하게 ID 헤더를 스푸핑하여 OpenClaw 에이전트 계층의 보안 제어를 우회할 수 있습니다.
올바른 ZTNA 통합은 엄격한 규칙을 따릅니다:
- 클라이언트가 제공한 모든 ID 헤더가 제거됩니다 .
- 신원 헤더는 JWT의 인증 후 ZTNA에 의해 재구성됩니다.
- 헤더가 암호화 또는 논리적으로 신뢰할 수 있는 이유는 다음과 같습니다:
- ZTNA 프록시에서만 발생합니다.
- OpenClaw는 신뢰할 수 있는 프록시 모드에서만 허용합니다.
- 클라이언트 제어 입력이 ID 컨텍스트로 재사용되지 않습니다.
이러한 분리로 인해 OpenClaw + ZTNA 모델은 관행이 아닌 설계상 보안을 유지합니다.
에이전트 변경 없는 권한 부여 및 감사 가능성
OpenClaw에는 아직 기본 사용자나 역할이 없습니다:
- ZTNA는 에이전트에 액세스할 수 있는 사용자를 제어합니다.
- 사용자, 그룹, 디바이스 및 네트워크 컨텍스트별로 정책을 적용할 수 있습니다.
- 모든 요청은 신원이 확인된 사람으로 기록됩니다.
- 기업은 규정 준수 및 포렌식을 위한 깔끔한 감사 추적을 확보할 수 있습니다.
OpenClaw는 여전히 에이전트 행동에 초점을 맞추고 있습니다.
결론: OpenClaw가 진화하더라도 여전히 중요한 ZTNA
OpenClaw는 올바른 방향으로 빠르게 진화하고 있습니다. 신뢰할 수 있는 프록시 모드는 프로젝트가 외부화된 신뢰의 중요성을 이해하고 있다는 강력한 아키텍처 신호입니다.
나중에 OpenClaw가 기본 사용자 인증이나 역할을 구현하더라도 ZTNA는 기업에서 여전히 가치 있고 종종 필수적인 역할을 합니다.
왜 그럴까요?
기업에는 모든 애플리케이션에 걸쳐 일관된 보안 제어가 필요하기 때문입니다:
- SaaS
- 내부 웹 앱
- API
- 개발자 도구
- 그리고 이제, AI 에이전트
ZTNA가 제공합니다: 중앙 집중식 정책
- 일관된 MFA 및 디바이스 상태
- 통합 감사 로그
- 이기종 시스템 전반의 단일 적용 계층
OpenClaw는 보안을 위해 완전한 IAM 플랫폼이 될 필요는 없습니다.
OpenClaw의 신뢰할 수 있는 프록시 모드와 제대로 구현된 ZTNA 계층을 결합하면 기업은 두 가지 장점을 모두 누릴 수 있습니다:
- 빠르게 움직이는 강력한 AI 에이전트
- 엔터프라이즈급 제로 트러스트 보안