피드로 돌아가기
Dev.toSecurity
원문 읽기
Kernel-level Enforcement를 통한 AI Agent Egress 보안 통제 설계
Politeness vs Enforcement: Why "Set HTTPS_PROXY" Isn't a Security Control
AI 요약
Context
HTTPS_PROXY 설정과 같은 환경 변수 기반의 보안 통제는 Agent 프로세스의 자발적 준수에 의존하는 Policy 단계에 불과함. Subprocess 생성 시 환경 변수 미전달 혹은 의도적 무시를 통해 보안 레이어를 우회하는 구조적 결함 존재.
Technical Solution
- Agent UID와 Proxy UID를 완전히 분리하여 권한 체계를 계층화한 3-UID 모델 설계
- nftables의 meta skuid 매칭 기능을 활용해 Agent UID의 모든 외부 트래픽을 Kernel 레벨에서 Drop 처리
- Agent UID에 대해 Localhost 내 Proxy 서비스로의 통신만 허용하는 엄격한 Egress 화이트리스트 적용
- Kubernetes 환경에서 Proxy를 별도 Pod로 분리하여 Container 단위가 아닌 Pod 단위 NetworkPolicy 적용
- Agent Pod의 Egress 목적지를 Proxy Pod의 Service IP로 한정하여 네트워크 네임스페이스 기반의 강제 격리 구현
실천 포인트
1. Agent 프로세스가 Proxy와 동일한 UID로 실행 중인지 확인
2. firewall 규칙에 Agent UID 기반의 직접적인 인터넷 차단 설정 여부 검토
3. K8s 환경에서 Agent와 Proxy가 동일 Pod 내에 배치되어 NetworkPolicy가 무력화되었는지 확인
4. `env -u HTTPS_PROXY curl` 명령을 통해 Kernel 레벨의 강제 차단 여부 실측 테스트 수행