shell.exec에 대한
deny, egress 허용 목록 — 그리고 그것이 옳다고 믿습니다. 하지만 그것을
프로덕션 에이전트 트래픽에 대해 켜는 것은 믿음의 도약입니다: 지나치게
광범위한 규칙 하나면 에이전트가 정당하게 만드는 호출을 차단하게 됩니다.
Firewall shadow mode는 안전한 롤아웃 스위치입니다. 그것은 게이트웨이에게
정책을 프로덕션에서와 정확히 동일하게 평가하고, 모든 것을 로깅하되,
아무것도 차단하지 말라고 알리는 정책별 플래그입니다. 모든 강제 판정이
audit로 강등되고, 이벤트 이유에 [shadow] would …가 접두되므로 — 정책이
아직 아무것도 하지 않은 채로 — 정책이 무엇을 했을지 정확히 읽어낼 수
있습니다.
Shadow mode는 콘솔에서(또는 세션 / 액세스 토큰을 사용하는
/api/workspace/firewall/policies 관리 라우트에서 — 릴레이 sk-orca-…
키가 아님) 설정되는 정책에 대한 플래그입니다. 그것을 토글하는 것은
Developer+ 액션입니다. 에이전트의 /v1/* 릴레이 호출은 변하지
않습니다.1. firewall shadow mode가 하는 일
정책의shadow_mode 플래그가 켜져 있으면, 게이트웨이는 전체 평가를
실행하고 — 정책을 해석하고, 규칙을 우선순위 순으로 순회하고, 판정을
고름 — 그런 다음 판정이 효력을 발휘하기 바로 직전에, 호출을 변경했을
모든 것을 강등합니다:
| 해석된 판정 | shadow mode하에서 |
|---|---|
deny | → audit, 이유 [shadow] would deny — … |
sanitize | → audit, 이유 [shadow] would sanitize — … |
pending_approval | → audit, 이유 [shadow] would pending_approval — … |
allow / audit | 변경 없음(이미 비차단) |
2. 하나의 구체적인 롤아웃
파괴적 셸 명령에 대한deny 규칙이 있는 prod-agents 정책이 있고, 그것이
정당한 어떤 것에도 걸리지 않음을 확인하고 싶다고 합시다.
shadow mode 켜기
Security → Firewall → Policies에서
prod-agents를 열고, Shadow
mode를 켠 다음 저장합니다. 정책은 연결과 규칙을 유지합니다 — 그저
강제만 멈춥니다.실제 트래픽 흐르게 하기
에이전트는 이전과 정확히 동일하게 게이트웨이를 계속 호출합니다. 모든
툴 호출이 평가됩니다; 아무것도 차단되지 않습니다. 대표적인 윈도우를
주세요 — 실제 툴 믹스를 커버할 만큼 충분히 길게.
차단되었을 거부 읽기
Events를 열고
[shadow] 이유로
필터링합니다. 각 행은 툴, 표면, 실행, 그리고 매치된 규칙을 보여줍니다
— 그래서 shell.exec 호출의 [shadow] would deny — destructive shell command는 HTTP 400을 뺀, 프로덕션에서 볼 것과 정확히 같습니다.shadow mode 끄기
피드가 정책이 예상한 것에 발동하고 예상치 않은 것에는 발동하지
않음을 보이면, Shadow mode를 끕니다. 다음 호출부터 그
[shadow] would deny 이벤트는 실제
firewall_blocked 거부가 됩니다.deny 규칙에 매치한 정당한 호출 — 을
드러냈다면, 여전히 shadow 상태에서 규칙을
고치고(glob을 좁히거나
인자 절을 추가), 피드를 다시
보세요. 폭발 반경 제로로 실제 트래픽에 대해 반복합니다.
3. shadow mode가 완화하지 않는 것
Shadow mode는 정책의 미리 보기이지, 마스터 오프 스위치가 아닙니다. 알아둘 만한 몇 가지 경계가 더 있습니다:Allow와 audit 판정은 손대지 않음
Allow와 audit 판정은 손대지 않음
강제 판정(
deny, sanitize, pending_approval)만 강등됩니다.
allow이나 audit은 이미 호출을 통과시키므로 완화할 것이 없습니다 —
그 이벤트들은 여전히 shadow 배지를 지니므로 기록될 때 정책이 shadow
상태였음을 알 수 있습니다.cap_cost는 강등 전에 해석됨
cap_cost는 강등 전에 해석됨
cap_cost 규칙은 실행의 누적 지출에
기반하여 구체적인 allow 또는 deny로 해석되며, shadow mode가 그런
다음 강등하는 것은 그 해석된 판정입니다 — 상한 초과 거부였을 것은
다른 어떤 것처럼 [shadow] would deny로 나타납니다.워크스페이스별이 아니라 정책별
워크스페이스별이 아니라 정책별
Shadow mode는 각 정책에 독립적으로 존재합니다. 검증된 정책이 계속
강제하는 동안 완전히 새 정책을 shadow할 수 있습니다 — 끄는 것을 잊을
워크스페이스 전역 shadow 스위치는 없습니다.
4. Shadow mode 대 다른 롤아웃 다이얼
firewall은 세 가지 서로 다른 “아직 아무것도 깨지 않기” 컨트롤을 제공합니다. 그것들은 서로 다른 문제를 해결합니다:| 컨트롤 | 범위 | 답하는 질문 |
|---|---|---|
| Shadow mode | 한 정책 | ”이 정책을 강제하면 무엇을 차단할까?” |
audit 기본 판정 | 한 정책 | ”어떤 규칙도 지명하지 않는 모든 것을 로깅, 아무것도 차단 안 함.” |
| Observe mode | 워크스페이스 | ”정책 없이 실행되는 툴은 어떤 것들인가?” |
audit은 한 정책의 매치되지 않은 꼬리를 위한 것입니다; observe mode는
특정 정책의 강제가 아니라 워크스페이스 전반의 커버리지 갭에 관한
것입니다.
그것들을 쌓을 수 있습니다. shadow mode하의 새 기본 거부 정책은 가능한
가장 부드러운 롤아웃입니다: 기본 거부 바닥조차 차단하는 대신
[shadow] would deny만 로깅하므로, deny가 라이브가 되기 전에 allow 규칙이 아직
커버하지 않는 호출의 전체 집합을 봅니다.5. 컴플라이언스 팩은 먼저 shadow로 떨어집니다
컴플라이언스 팩을 설치할 때 observe(비강제) 모드에서 설치하면, 그것이 구체화하는 firewall 정책은 shadow mode 켬으로 생성됩니다 — 아무것도 차단하지 않고 트래픽에 대해 평가하고 로깅합니다. 팩을 강제로 프로모트하면 그 정책들이 shadow에서 벗어납니다. 같은 메커니즘이 여러분을 위해 적용됩니다: 컨트롤을 dry-run하고, 차단되었을 판정을 읽은 다음, 강제합니다.6. 토글하기
콘솔에서 shadow mode는 정책 편집기의 토글입니다. 동일한 플래그가 관리 API에서 정책 객체의shadow_mode로 노출됩니다 — 이 라우트들은 세션 /
액세스 토큰을 사용하며 **Developer+**를 요구합니다:
| 메서드 및 경로 | 역할 | 비고 |
|---|---|---|
PUT /api/workspace/firewall/policies | Developer+ | 본문에서 정책에 shadow_mode: true / false를 설정. |
GET /api/workspace/firewall/policies/:id | Member | 정책의 현재 shadow_mode 상태 읽기. |
version 정수를 올리므로, shadow를 켜고 끄는 것 자체가 추적됩니다.
다음으로 갈 곳
정책 생성 & 연결
shadow mode가 롤아웃하는 두 단계 설정 — 정책 생성, 키 연결.
이벤트 로그
[shadow] would …가 나타나는 곳 — 필터링하고, 실행과 규칙으로
파고듭니다.Verdicts
shadow mode가 강등하는 강제 판정과 각각이 라이브에서 하는 일.
강제 모드
shadow, audit, observe가 더 넓은 강제 모델에 어떻게 들어맞는가.