이 글은 Claude Code 보안 심층 분석 시리즈의 네 번째 편입니다.
시리즈 목차
- 왜 지금 이야기해야 하는가
- 어디서 무엇이 새는가 — 위협과 공격 표면
- 탐지 전략 — 파일시스템에서 네트워크까지
- 통제와 한계 — 클라이언트 영역의 현실 (본 편)
- 놓치기 쉬운 것들 — 코드 품질, 포렌식, 컴플라이언스
3편에서 Claude Code 사용을 탐지하는 구체적 방법을 다뤘다. 탐지 다음은 당연히 통제다. 그런데 여기서 근본적인 질문과 마주하게 된다. “클라이언트 측 도구를 서버 측에서 강제할 수 있는가?”
결론부터 말하면, 완벽한 강제는 불가능하다. 이번 편에서는 가용한 통제 수단과 그 효과를 솔직하게 분석하고, 각 수단이 어떤 조건에서 유효하며 어떻게 우회되는지를 구체적으로 다룬다. 그리고 이 현실 위에서 어떤 전략이 합리적인지를 논한다.
가용한 통제 수단
1. managed-settings.json — 엔터프라이즈 정책 강제
Anthropic이 제공하는 가장 강력한 통제 메커니즘이다. 시스템 경로에 배포되며, 사용자/프로젝트 설정보다 항상 우선한다.
# 배포 경로
macOS: /Library/Application Support/ClaudeCode/managed-settings.json
Linux: /etc/claude-code/managed-settings.json
Windows: C:\Program Files\ClaudeCode\managed-settings.json
설정 가능한 항목:
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Read(./config/credentials.json)"
],
"disableBypassPermissionsMode": "disable"
},
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"hooks": {
"allowManagedHooksOnly": true
}
}
효과: disableBypassPermissionsMode로 --dangerously-skip-permissions 플래그를 비활성화할 수 있다. forceLoginMethod와 forceLoginOrgUUID로 기업 계정만 사용하도록 강제할 수 있다. allowManagedHooksOnly를 true로 설정하면 사용자/프로젝트/플러그인 훅이 차단되고 관리자 훅만 실행된다.
한계: 이 파일은 관리형 기기(MDM으로 관리되는 기업 장비)에서만 신뢰할 수 있다. BYOD(개인 기기) 환경에서는 사용자가 파일을 삭제하거나 수정할 수 있다. 시스템 경로에 대한 쓰기 권한이 없는 일반 사용자라면 보호되지만, 로컬 관리자 권한을 가진 사용자라면 무력화된다.
2. 네트워크 통제 — 도메인 차단 및 트래픽 모니터링
회사 네트워크에서 Claude Code가 통신하는 도메인을 차단하거나 모니터링한다.
차단 대상 도메인:
api.anthropic.com— 완전 차단 시 Claude Code 자체가 동작 불가claude.ai— OAuth 인증 차단statsig.anthropic.com— 텔레메트리 차단*.ingest.sentry.io— 에러 리포팅 차단
프록시/방화벽 설정 예시 (Squid):
# Claude Code API 차단
acl claude_api dstdomain api.anthropic.com
acl claude_auth dstdomain claude.ai
http_access deny claude_api
http_access deny claude_auth
효과: 회사 네트워크(사무실, VPN) 안에서는 Claude Code 사용을 효과적으로 차단할 수 있다. 프록시 로그를 통해 우회 시도도 탐지할 수 있다.
한계: 개발자가 개인 핫스팟, 테더링, 또는 VPN을 사용하면 회사 네트워크를 우회할 수 있다. 재택근무 환경에서는 회사 VPN을 강제하지 않는 한 효과가 없다. 또한 Claude Code는 ANTHROPIC_BASE_URL을 통해 서드파티 호환 API(예: AWS Bedrock, Google Vertex AI)로 우회할 수 있으므로, api.anthropic.com 차단만으로는 Claude Code의 모든 형태를 막지 못한다.
3. SSO/인증 강제
managed-settings.json의 forceLoginMethod와 forceLoginOrgUUID로 기업 SSO 인증을 강제한다.
효과: Claude Code가 기업 계정으로만 로그인하도록 제한하면, 조직의 감사 로그에 사용이 기록된다. Analytics API를 통해 사용자별 세션 수, 도구 호출 수, 터미널 유형 등을 추적할 수 있다.
한계: 개발자가 개인 Anthropic API 키를 ANTHROPIC_API_KEY 환경변수에 설정하면 SSO를 완전히 건너뛸 수 있다. 이 경우 조직의 감사 로그에는 아무것도 남지 않는다.
4. 파일 접근 권한 통제
permissions.deny 설정으로 민감 파일에 대한 Claude Code의 접근을 차단한다.
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Read(./config/credentials.json)",
"Read(./.aws/**)",
"Read(./.ssh/**)"
]
}
}
효과: Claude Code의 기본 도구(Read, Edit)를 통한 직접적인 민감 파일 접근을 차단한다.
한계: Anthropic 공식 문서에서 인정하듯, Bash 패턴은 프리픽스 매치이며 우회될 수 있다. 예를 들어 Read(./.env) 규칙은 Claude Code의 Read 도구를 차단하지만, Bash(cat .env) 명령은 별도로 차단해야 한다. 그리고 Bash 패턴 차단도 다양한 인코딩이나 간접 접근으로 우회될 가능성이 있다. 공식 문서의 표현을 빌리면, 이것은 “보안 경계(security boundary)”가 아니라 “가드레일(guardrail)”이다.
5. 샌드박스 격리
Claude Code는 Bash 명령을 파일시스템과 네트워크로부터 격리하는 샌드박스 기능을 제공한다.
효과: /sandbox 모드를 활성화하면 permissions.deny로 정의된 규칙이 OS 수준(macOS: Seatbelt, Linux: bubblewrap)에서 강제되어, Bash 명령을 통한 우회도 차단된다.
한계: 샌드박스 기능은 사용자가 활성화해야 한다. managed-settings.json에서 강제할 수 있지만, 기기 관리가 안 되는 환경에서는 보장할 수 없다. 또한 샌드박스가 활성화되면 일부 정상적인 개발 작업(외부 패키지 설치, 네트워크 테스트 등)이 제한되어 개발자의 저항이 발생할 수 있다.
6. Git/CI 기반 통제
코드 저장소와 CI/CD 파이프라인에서 설정 파일 변경을 통제한다.
CODEOWNERS를 통한 리뷰 강제:
# .github/CODEOWNERS
.claude/ @security-team
.mcp.json @security-team
CLAUDE.md @security-team
이렇게 설정하면 .claude/ 디렉토리, .mcp.json, CLAUDE.md의 변경이 포함된 PR은 보안 팀의 승인이 필수가 된다.
CI 파이프라인에서 설정 검증:
# .github/workflows/claude-security-check.yml
name: Claude Code Security Check
on:
pull_request:
paths:
- '.claude/**'
- '.mcp.json'
- 'CLAUDE.md'
jobs:
security-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check for dangerous hooks
run: |
if grep -r "c u r l\|w g e t\|nc " .claude/settings.json 2>/dev/null; then
echo "::error::위험한 hooks 패턴 발견"
exit 1
fi
- name: Check for API URL override
run: |
if grep -r "ANTHROPIC_BASE_URL" .claude/ 2>/dev/null; then
echo "::error::ANTHROPIC_BASE_URL 오버라이드 발견"
exit 1
fi
효과: 공급망 공격의 가장 효과적인 방어 수단이다. 레포지토리를 통한 악성 설정 주입을 코드 리뷰 단계에서 차단할 수 있다.
한계: 로컬에서 직접 수정하는 경우에는 적용되지 않는다. 또한 CODEOWNERS 규칙이 해당 레포지토리에 설정되어 있어야 하며, 모든 프로젝트에 일괄 적용하려면 조직 수준의 정책이 필요하다.
통제 수단 종합 평가
| 통제 수단 | 관리형 기기 | BYOD/개인 기기 | 재택/외부망 | 우회 난이도 |
|---|---|---|---|---|
| managed-settings.json | ✅ 효과적 | ❌ 무력화 가능 | ✅ 기기에 종속 | 중 (관리자 권한 필요) |
| 네트워크 차단 | ✅ 효과적 | ✅ 회사망 한정 | ❌ 무력화 | 하 (핫스팟/VPN) |
| SSO 강제 | ✅ 효과적 | △ 부분적 | △ 부분적 | 하 (개인 API 키) |
| 파일 접근 차단 | △ 가드레일 | △ 가드레일 | △ 가드레일 | 하 (Bash 우회) |
| 샌드박스 | ✅ OS 수준 격리 | △ 설정 필요 | ✅ 기기에 종속 | 중 (설정 삭제) |
| Git/CI 통제 | ✅ 효과적 | ✅ 효과적 | ✅ 효과적 | 고 (리뷰 우회 어려움) |
주목할 점: Git/CI 기반 통제가 환경에 관계없이 가장 일관되게 효과적이다. 왜냐하면 이것은 클라이언트가 아닌 서버(레포지토리) 측에서 작동하기 때문이다. Claude Code가 어디서 실행되든, 코드가 레포지토리에 들어오는 시점에서 통제할 수 있다.
왜 100% 강제는 불가능한가
근본적인 이유는 단순하다. Claude Code는 클라이언트 측 도구이기 때문이다.
서버 측 서비스(예: SaaS 애플리케이션)는 서비스 제공자가 접근 통제를 완전히 관리할 수 있다. 사용자 인증, 권한, 데이터 접근이 서버에서 결정된다. 그러나 Claude Code는 개발자의 로컬 머신에 설치되어 실행된다. 이 머신에 대한 물리적, 논리적 통제는 개발자에게 있다.
이것은 Claude Code만의 문제가 아니라, 모든 클라이언트 측 AI 코딩 도구(GitHub Copilot, Cursor, Amazon CodeWhisperer 등)에 공통으로 적용되는 구조적 한계다. DRM(디지털 저작권 관리)이 완벽하지 않은 것과 같은 이유다. 클라이언트에게 데이터를 보내는 순간, 클라이언트가 그 데이터로 무엇을 하는지 완벽히 통제할 수 없다.
현실적 전략: 다층 방어
100% 강제가 불가능하다는 현실을 인정한 위에서, 합리적인 보안 전략은 **다층 방어(Defense in Depth)**와 유형별 차등 대응이다.
계층 1: 예방(Preventive)
완벽하지 않더라도 장벽을 겹겹이 쌓는다.
- 관리형 기기에
managed-settings.json배포 - 회사 네트워크에서
api.anthropic.com모니터링 (차단 또는 로깅) - Git 레포지토리에 CODEOWNERS + CI 보안 체크 적용
- 샌드박스 모드 기본 활성화 가이드
계층 2: 탐지(Detective)
예방을 우회하는 경우를 잡아낸다.
- 3편에서 다룬 파일시스템/네트워크/프로세스/Git 탐지 자동화
- EDR/MDM과 연동한 주기적
.claude디렉토리 스캔 - 네트워크 프록시 로그 분석
- Analytics API를 통한 기업 계정 사용 모니터링
계층 3: 정책(Administrative)
기술적 통제의 빈틈을 정책으로 보완한다.
- 사용 정책 수립: Claude Code 사용 가능/불가 프로젝트 분류, 프롬프트에 넣으면 안 되는 데이터 유형 명시, 승인된 계정만 사용하도록 규정
- 데이터 분류: 프로젝트별 데이터 민감도를 분류하고, 민감도에 따라 AI 도구 사용 범위를 차등 적용
- 인시던트 대응 절차: Claude Code 관련 보안 사고 발생 시 대응 절차 수립 (5편에서 상세히 다룸)
계층 4: 교육(Awareness)
궁극적으로 개발자의 인식이 가장 중요한 통제 수단이다.
- “프롬프트에 입력하는 모든 것이 외부 서버로 전송된다”는 사실 인식
.env, 시크릿, 고객 데이터를 프롬프트에 포함하지 않는 습관- 외부 레포지토리를 클론할 때
.claude/디렉토리 내용을 확인하는 습관 - API 키 관리의 중요성 (특히 Workspaces 기능과의 관계)
시나리오별 권장 전략
시나리오 A: 엄격한 보안이 필요한 환경 (금융, 의료, 군사)
[권장 조합]
관리형 기기 + managed-settings.json 강제
+ 네트워크 차단 (api.anthropic.com 완전 차단)
+ VPN 강제 (외부망에서도 회사 네트워크 경유)
+ 승인된 프로젝트에서만 사용 허용 (정책)
+ 3rd party 호환 API 도메인도 추가 차단
이 조합이면 관리형 기기에서의 사용을 거의 완전히 통제할 수 있다. 다만 개발자의 개인 기기에서의 사용까지 막으려면 “소스코드 반출 금지” 같은 물리적/정책적 통제가 병행되어야 한다.
시나리오 B: 중간 수준의 통제 (일반 기업)
[권장 조합]
managed-settings.json 배포 (민감 파일 차단, SSO 강제)
+ 네트워크 모니터링 (차단 아닌 로깅)
+ Git CODEOWNERS + CI 보안 체크
+ 사용 정책 수립 + 교육
+ 정기적 파일시스템/Git 탐지 스캔
사용 자체를 막기보다, 안전한 사용 환경을 만들고 이탈을 탐지하는 전략이다.
시나리오 C: 유연한 환경 (스타트업, 개인 프로젝트)
[권장 조합]
Git 기반 통제 (CODEOWNERS, CI 체크)
+ 교육 (시크릿 관리, 데이터 분류)
+ 정기 탐지 스캔 (월 1회)
최소한의 통제로도 가장 심각한 리스크(공급망 공격, 시크릿 유출)는 방어할 수 있다.
마무리 — 막는 것이 아니라 관리하는 것
Claude Code의 보안 통제에 대해 가장 중요한 인식 전환은, “사용을 막는다”에서 “사용을 관리한다”로의 전환이다.
클라이언트 측 도구의 완벽한 차단은 구조적으로 불가능하며, 시도하더라도 개발자의 생산성을 심각하게 저해한다. 보안의 목표는 위험을 0으로 만드는 것이 아니라, 수용 가능한 수준으로 관리하는 것이다.
다음 편에서는 탐지와 통제를 넘어, 놓치기 쉬운 영역들 — AI 생성 코드의 보안 품질, 인시던트 대응, 법적 리스크 — 을 다루며 시리즈를 마무리한다.