배경
Nodease의 외부 통신은 Gateway뿐 아니라 Workflow Worker, Knowledge ingestion과 LLM provider adapter에서도 발생한다. 따라서 Gateway middleware 하나로 통제할 수 없으며, 애플리케이션 guard와 배포 네트워크 경계를 함께 사용하는 다층 방어가 필요하다.
nodease/mbased#471은 Workflow Generic HTTP의 address-pinned transport와 Worker NetworkPolicy를 구현했고, nodease/mbased#392은 Connector test 경계를 완료했다. nodease/mbased#290은 production HTTPS 경계와 우선 고위험 outbound consumer를 공통 보안 계약으로 정렬한다.
현재 기준선
완료
보완 필요
Shared safe_http_request()는 URL 검증 뒤 일반 HTTP client가 hostname을 다시 해석하고, 실제 peer 확인도 요청 이후에 수행할 수 있다. 민감한 header 또는 body가 있는 호출은 요청 byte 전송 전에 검증된 destination으로 연결이 고정되어야 한다.
Docker Squid와 현재 NetworkPolicy는 보조 방어선이지만 모든 workload의 proxy 사용을 강제하지 않는다. 전용 egress proxy와 cluster-level enforcement는 nodease/mbased#592에서 별도 결정한다.
목표
- production browser/API 공개 경계를 same-origin 또는 공개 HTTPS로 고정한다.
- production CORS에서 localhost와 개발용 HTTP origin을 제거한다.
- Shared에 재사용 가능한 저수준 address-pinned transport primitive를 두되, 각 호출은 operation별 application port를 사용한다.
- 우선 고위험 outbound consumer가 실제 외부 I/O 직전에 동일한 guard를 통과하도록 한다.
- 평문 HTTP, DNS 변경, redirect, peer 불일치와 unsafe destination을 요청 전 fail-closed한다.
- secret, credential, prompt, query, 문서 원문과 provider raw payload를 오류·로그·audit·trace에 남기지 않는다.
구현 범위
Browser 및 Ingress
- production
NEXT_PUBLIC_API_URL의 same-origin/public HTTPS 제한
- production CORS와 local/development origin 분리
- TLS termination, 내부 service HTTP와 외부 공개 HTTPS 책임 문서화
Application outbound
- Shared address-pinned transport primitive
- operation별 port/composition 경계
- Knowledge API source/file/preview 외부 호출
- Workflow FileExtraction 외부 호출
- LLM catalog, validation, generation과 embedding 외부 호출
- 요청 전 destination 검증과 원래 hostname 기준 TLS 검증
- bounded redirect, timeout, request/response size와 safe error taxonomy
- 허용된 composition root 이외 직접 HTTP client 생성 방지 검사
관측 및 실패 정책
- policy denial과 일시 장애 분리
- raw URL query, header, body, credential과 provider 예외 비노출
- observe-only rollout에서도 거부된 민감 요청은 전송하지 않음
- safe reason code와 bounded metric/audit metadata만 기록
완료 조건
- production browser bundle에 내부 HTTP service 주소가 포함되지 않는다.
- production CORS에 localhost 또는 개발용 HTTP origin이 남지 않는다.
- credential·Authorization header·prompt·query·문서 body가 있는 평문 HTTP 요청은 network I/O 전에 차단된다.
- 대상 consumer가 검증된 destination으로 연결을 고정하기 전에 request byte를 전송하지 않는다.
- redirect와 DNS 변경으로 private·local·metadata destination에 도달하지 않는다.
- 대상 모듈에 승인되지 않은 직접
requests/httpx 생성 경로가 남지 않는다.
- 오류·audit·trace·metric에 secret 또는 raw payload가 남지 않는다.
- 코드, 배포 설정, ADR과 feature 문서의 current/target 상태가 일치한다.
비범위
후속 이슈
관계
배경
Nodease의 외부 통신은 Gateway뿐 아니라 Workflow Worker, Knowledge ingestion과 LLM provider adapter에서도 발생한다. 따라서 Gateway middleware 하나로 통제할 수 없으며, 애플리케이션 guard와 배포 네트워크 경계를 함께 사용하는 다층 방어가 필요하다.
nodease/mbased#471은 Workflow Generic HTTP의 address-pinned transport와 Worker NetworkPolicy를 구현했고, nodease/mbased#392은 Connector test 경계를 완료했다. nodease/mbased#290은 production HTTPS 경계와 우선 고위험 outbound consumer를 공통 보안 계약으로 정렬한다.
현재 기준선
완료
보완 필요
Shared
safe_http_request()는 URL 검증 뒤 일반 HTTP client가 hostname을 다시 해석하고, 실제 peer 확인도 요청 이후에 수행할 수 있다. 민감한 header 또는 body가 있는 호출은 요청 byte 전송 전에 검증된 destination으로 연결이 고정되어야 한다.Docker Squid와 현재 NetworkPolicy는 보조 방어선이지만 모든 workload의 proxy 사용을 강제하지 않는다. 전용 egress proxy와 cluster-level enforcement는 nodease/mbased#592에서 별도 결정한다.
목표
구현 범위
Browser 및 Ingress
NEXT_PUBLIC_API_URL의 same-origin/public HTTPS 제한Application outbound
관측 및 실패 정책
완료 조건
requests/httpx생성 경로가 남지 않는다.비범위
후속 이슈
관계