메인 콘텐츠로 건너뛰기
스테이징에서 신뢰하는 firewall 정책이 이미 있고, 두 규칙이 변경된 프로덕션용 두 번째 정책을 원합니다 — 또는 무엇이 변경되었는지 추적을 잃지 않고 라이브 정책을 조이고 싶습니다. 둘 다 정책 수명 주기 동작입니다: 시작점으로 두 번째 정책을 세우고, 모든 업데이트에서 올라가는 버전에 기대어 변경이 전파되었음을 압니다. 이 페이지는 수명 주기 레퍼런스입니다 — 분기, 버전, 기본값, 그리고 활성화/비활성화/삭제. 최초 설정은 Create & attach를; 규칙 문법은 Firewall Rules를 참조하세요.
모든 정책 관리는 콘솔(또는 세션 / 액세스 토큰으로 인증하는 /api/workspace/firewall/* 관리 라우트 — 릴레이 sk-orca-… 키가 아님)에서 일어납니다. 에이전트의 /v1/* 호출만 릴레이 키를 사용합니다. 정책을 생성, 편집, 기본값 설정하는 것은 Developer+ 액션입니다; 정책 목록과 그 버전을 읽는 것은 모든 Member에게 개방됩니다.

​
1. 자세를 두 번째 정책으로 분기

“fork” 판정이나 복사 버튼은 없습니다 — 정책 이름은 워크스페이스당 고유하므로, 패턴은 두 번째, 독립적으로 버전 관리되는 정책을 세우고 원본을 건드리지 않고 자유롭게 분기하는 것입니다. 그것을 시드하는 두 가지 방법:
1

새 정책을 생성한 다음, 그 규칙 작성

Security → Firewall → Policies → New policy를 엽니다. 새 정책은 규칙 없이 그리고 선택한 default_verdict로 생성됩니다 — 편집기에서 그 규칙을 작성하세요(또는 소스 정책에서 몇 개를 손으로 복사하세요). 워크스페이스 고유 이름을 주세요(예: staging-firewall 옆에 prod-firewall).
2

또는 사용 사례 템플릿 적용

Templates 갤러리(POST /api/workspace/firewall/templates/apply)는 하나의 새 정책 과 그 모든 규칙을 단일 트랜잭션으로 생성합니다 — Coding, Support, RAG, Data, DevOps, Browser, 또는 Baseline. 템플릿이 매치할 때 직접 작성보다 빠릅니다.
3

분기하고 연결

새 정책의 규칙을 편집하고 — 파괴적 셸 deny를 조이고, egress 허용 목록 호스트를 교체 — 그 다음 firewall_policy_id를 통해 프로덕션 키에 연결하거나, 워크스페이스 기본값으로 표시하세요. 소스 정책은 손대지 않습니다.
두 번째 정책은 더 위험한 자세를 테스트하는 안전한 방법입니다. 하나를 세우고, 거기에 shadow mode를 켜고, 한 카나리 키에 연결하고, 이벤트 피드를 보세요 — 다른 모든 키의 프로덕션 정책은 변경 없이 계속 강제합니다.
각 정책은 자체 출처, 자체 연결된 키 카운트, 그리고 자체 버전 라인을 지닙니다.

​
2. 모든 업데이트에서 올라가는 버전

모든 firewall 정책은 version 정수를 가집니다. 정책이 생성될 때 1에서 시작하고 모든 업데이트에서 하나씩 증가합니다 — 규칙 편집, 기본 판정 변경, 활성화/비활성화 토글, shadow mode 전환. 그것은 단조적이고 결코 리셋되지 않습니다. 
// GET /api/workspace/firewall/policies/:id  → (abridged)
{
  "id": 42,
  "name": "prod-firewall",
  "enabled": true,
  "is_default": true,
  "default_verdict": "audit",
  "shadow_mode": false,
  "version": 7,          // bumped from 6 → 7 by your last save
  "rule_count": 11,
  "attached_key_count": 3
}
버전은 전파 신호입니다: 게이트웨이는 해석된 정책을 잠깐 캐시하고, 모든 저장이 그 캐시를 무효화하므로 편집이 몇 초 안에 연결된 키에 효력을 발휘합니다 — 재배포 없음, 에이전트 코드 변경 없음. version은 캐시를 구동하지 않습니다; 그것은 다시 읽는 단조적 변경 카운터입니다. 정책을 저장하고 변경이 라이브임을 확인하고 싶을 때, 정책을 다시 읽고 version이 전진했는지 확인하세요.
정책 version은 복원 지점이 아니라 변경 카운터입니다. 그것은 정책이 변경되었음을 알려주고 게이트웨이가 편집을 전파하게 합니다 — 버전별 diff나 롤백이 아닙니다. diff와 원클릭 되돌리기가 있는 버전 관리 이력 전체는 Guardrails에 존재합니다: GET /api/guardrail/:id/history, …/history/diff, 그리고 POST /api/guardrail/:id/revert(되돌리기는 Developer+). firewall 정책의 경우, 감사 추적과 강등된 알려진-양호 정책을 목록에 유지하는 것이 복원 지점을 보존하는 방법입니다 — §5 참조.

​
3. 워크스페이스 기본값 설정 및 이동

워크스페이스는 하나의 정책을 기본값으로 표시할 수 있습니다. 자체 firewall_policy_id가 없는 모든 키는 그것으로 해석됩니다(해석 순서).
  • 정책을 편집하고 워크스페이스 기본값으로 설정합니다. 새 기본값을 프로모트하면 동일한 트랜잭션에서 이전 것이 강등됩니다 — 두 기본값이 있는 윈도우도, 교체 중간에 없는 윈도우도 결코 없습니다.
  • 두 번째 정책을 세우는 것은 기본값을 앞으로 굴리는 깔끔한 방법입니다: 새 정책을 구축하고, 조정하고, shadow mode하에서 검증한 다음, 그것을 프로모트하세요. 이전 기본값은 강등된 채로, 폴백으로 목록에 남습니다.
기본값을 이동하면 모든 연결되지 않은 키에 대해 한 번에 강제가 변경됩니다. 새 기본값이 default_verdict를 deny로 조이면, 규칙이 명시적으로 허용하지 않는 호출이 즉시 차단되기 시작합니다. 새 기본값을 shadow mode 뒤에서 롤아웃하고 프로모트하기 전에 Events를 보세요.

​
4. 활성화, 비활성화, 그리고 삭제

Enabled를 끄면 정책이 해석되는 것을 멈춥니다. 하지만 firewall 폴스루를 기억하세요: 연결된 정책이 비활성화된 키는 워크스페이스 기본값으로 폴백합니다 — 비활성화는 키를 firewall 범위 밖으로 빼내지 않습니다. 키를 강제에서 제거하려면, 그것을 떼어내세요(firewall_policy_id를 0으로 설정), 그냥 정책을 비활성화하지 마세요. (이는 guardrails와 다릅니다. guardrails에서는 비활성화된 연결이 없음으로 해석됩니다.)
DELETE /api/workspace/firewall/policies/:id(Developer+)는 정책을 제거합니다 — 하지만 어떤 키가 여전히 그것을 참조하면 409를 반환합니다. 그 키들을 먼저 떼어내거나 다시 가리킨 다음, 삭제하세요. 이 가드가 제자리 재작성이 아니라 두 번째 정책을 세우는 것이 라이브 키가 의존하는 정책을 진화시키는 더 안전한 방법인 이유입니다.
정책 이름은 워크스페이스 내에서 고유하므로, 두 번째 정책은 새 이름이 필요합니다. policy-copy-2보다는 수명 주기를 견디는 관습을 사용하세요 — staging-firewall / prod-firewall, 또는 날짜 접미사.

​
5. 감사 추적

모든 정책 생성, 업데이트(기본값 프로모션이나 shadow mode 전환 포함), 그리고 삭제는 변경이 커밋된 후에 감사 행 — 워크스페이스 행과 중앙 admin 행 둘 다 — 을 씁니다. 실패한 저장(중복 이름, 유효하지 않은 판정)은 아무것도 쓰지 않습니다. 규칙 blob과 시크릿은 결코 감사 로그에 쓰이지 않습니다. 그래서 firewall 정책이 자체 diff-와-되돌리기 이력을 지니지 않더라도, 감사 추적은 누가 어느 정책을, 언제 변경했는지 알려주고, 단조적 version은 그것이 몇 번 변경되었는지 알려줍니다. 그것을 강등된 알려진-양호 정책을 목록에 유지하는 것과 짝지으면, 실용적인 복원 경로를 갖게 됩니다.

​
6. 수명 주기 한눈에 보기

액션라우트역할
정책 목록(+ 버전, 카운트)GET /api/workspace/firewall/policiesMember
정책 하나 읽기GET /api/workspace/firewall/policies/:idMember
정책 생성(규칙 없음)POST /api/workspace/firewall/policiesDeveloper+
템플릿 적용(정책 + 규칙)POST /api/workspace/firewall/templates/applyDeveloper+
업데이트(version 올림)PUT /api/workspace/firewall/policiesDeveloper+
삭제(키 연결되어 있으면 409)DELETE /api/workspace/firewall/policies/:idDeveloper+
새롭거나 막 프로모트된 정책에 의존하기 전에, 샌드박스 Test 탭에서 dry-run하세요 — 아무것도 디스패치하지 않고 판정, 매치된 규칙, 이유를 반환합니다. 규칙 테스트 참조.

​
다음으로 갈 곳

Create & attach

최초 설정 경로 — 정책을 생성하고 키를 그것에 가리킵니다.

Shadow mode

라이브 트래픽을 변경하지 않고 새롭거나 다시 기본값이 된 정책을 롤아웃합니다.

Firewall + Guardrails

액션 정책이 텍스트 guardrails와 어떻게 조합되는가 — 그리고 버전 관리 되돌리기가 어디에 존재하는가.

범위: 키, 정책, 워크스페이스

연결과 워크스페이스 기본값이 어떻게 해석되는가.