PEP (2) 썸네일형 리스트형 [Zero Trust - Policy Engine] Connector와 Gateway: 정책 결정이 실제 트래픽으로 집행되는 방법 보안 감사 중에 이런 질문이 나올 때가 있다."VPN 없이 내부 개발 서버에 접근한다면, 그 연결은 어떻게 만들어지나요? 내부 서버의 포트가 외부에 열려 있는 건가요?" 이 질문이 불편하게 느껴지는 데는 이유가 있다. VPN을 걷어냈다고 선언했다면, 그 자리를 대체하는 것이 무엇인지를 구체적으로 설명할 수 있어야 한다. "Zero Trust를 도입했습니다"라는 말만으로는 충분하지 않다. Vol.11에서 PDP(Policy Decision Point)가 접근 요청에 허용/거부를 결정한다고 설명했다. 앞선 포스팅에서는 OPA와 Cedar가 그 결정을 어떤 언어로 표현하는지를 다뤘다. 그런데 OPA가 allow = true를 반환했다고 해서 사용자의 노트북과 내부 앱 서버 사이에 연결이 저절로 생기지는 않는다.. [Zero Trust - Policy Engine] PDP · PEP · PAP · PIP: 접근 결정의 분리 새벽 2시, 보안팀의 슬랙 채널에 경보가 울렸다. 시니어 엔지니어 계정의 자격증명이 피싱 공격으로 탈취됐다는 신고가 들어왔다. 해당 계정은 프로덕션 DB, 내부 API, CI/CD 파이프라인, 로그 시스템에 접근 권한이 있었다. 대응팀이 해야 할 일은 단순했다. 해당 계정의 접근을 지금 당장 막는 것. 하지만 생각만큼 단순하지 않았다. 그 회사의 접근 제어 로직은 각 서비스에 분산되어 있었다. API 서버는 JWT 클레임을 파싱해서 if claims["role"] == "engineer" 조건을 검사했다. 내부 대시보드는 LDAP 그룹 멤버십을 직접 조회했다. CI/CD 시스템은 자체 권한 테이블을 가지고 있었다. 로그 집계 서비스는 IP 기반 allowlist를 쓰고 있었다. 공통 정책 레이어 같은 것.. 이전 1 다음