제로 트러스트 아키텍처: 위치 신뢰에서 요청별 접근 평가로

1장 개념과 보호 목표#

제로 트러스트는 내부망에 있다는 이유만으로 암묵적 신뢰를 주지 않는 접근 방식입니다. 자원 접근마다 주체, 기기와 요청의 맥락을 평가하고 최소한의 권한을 부여합니다. 하나의 제품을 설치하는 것으로 아키텍처가 완성되지는 않습니다.

2장 원리와 구분#

NIST SP 800-207은 정책 엔진, 정책 관리자, 정책 집행 지점을 구분합니다. 정책 판단에는 신원, 자원 특성, 단말 상태와 위협 정보를 반영할 수 있습니다. 세션이 시작된 뒤에도 변화에 따라 재평가·회수가 필요합니다. 모든 요청마다 사람에게 비밀번호를 다시 입력시키는 것으로 이해하면 운영 목적을 놓칩니다.

3장 비교와 판단 기준#

구성	역할	관측·제어 정보
정책 엔진 PE	접근 허용·거부 판단	신원·자원·기기·위협
정책 관리자 PA	결정에 따른 연결 제어	세션 설정·회수
정책 집행점 PEP	실제 자원 접근 집행	요청·정책 결과·차단

4장 내부 위치의 암묵적 신뢰를 줄인다#

내부 IP·VPN 접속·사무실 기기라는 이유만으로 모든 자원을 허용하지 않습니다. 주체·기기·자원·행위·위험의 조건으로 최소한의 접근을 판단합니다. 네트워크 분리를 버린다는 뜻이 아니라 위치 하나를 충분한 신뢰 근거로 사용하지 않는 접근입니다.

제로 트러스트는 제품 이름보다 집행 경로와 정책 구조입니다. 자산·신원·접근 흐름의 목록이 없으면 무엇을 평가하고 제한할지 정하기 어렵습니다.

5장 보호 단위는 자원과 행위#

사용자가 내부망에 들어온 상태보다 어떤 API·관리 콘솔·데이터를 어떤 행위로 사용하는지 봅니다. 조회·수정·내보내기·관리 명령의 영향이 다릅니다. 세션과 업무 권한을 필요 범위에 연결하고 실제 우회 경로를 조사합니다.

누가 요청하는가?
어느 기기·워크로드인가?
어떤 자원과 행위인가?
필요 조건이 현재도 맞는가?
어디에서 실제 허용·거부를 집행하는가?

6장 PE·PA·PEP의 역할#

정책 엔진은 조건을 평가하고 정책 관리자는 연결 제어를 수행하며 정책 집행점은 실제 접근을 적용하는 역할로 읽습니다. 제품이 여러 역할을 한곳에 구현할 수 있어도 논리적 구분은 유용합니다. 판단과 실제 집행 사이의 우회를 확인해야 합니다.

flowchart LR
 U["주체·기기"] --> P["PEP"]
 P --> E["PE의 정책 판단"]
 S["신원·자원·위험 신호"] --> E
 E --> A["PA의 연결 제어"]
 A --> P
 P --> R["허용된 자원"]

7장 속성의 신뢰와 최신성#

단말이 지난달에 안전했다는 기록으로 오늘의 모든 요청을 허용하면 위험 조건을 반영하지 못할 수 있습니다. 신원·소속·기기 상태·위협 정보의 출처와 갱신·누락·오류를 정합니다. 사용자의 요청값으로 자신에게 유리한 속성을 만들게 하지 않습니다.

변경이 언제 정책에 반영되는지 캐시·토큰·세션의 수명을 연결합니다. 권한을 회수한 뒤 계속 접근할 수 있는 시간을 관측하고 필요한 재평가를 설계합니다.

8장 연속 평가가 매번 수동 로그인을 뜻하지는 않는다#

인증된 신원과 단말·위험 신호를 자동으로 평가하고 필요한 경우 추가 확인을 적용합니다. 요청마다 사람이 비밀번호를 입력해야만 제로 트러스트라고 보면 사용성과 목적을 놓칩니다. 평가 빈도·세션·위험 변화의 처리에 맞춰 설계합니다.

관리 작업·대량 내보내기 등 큰 영향의 행위는 더 강한 조건을 요구할 수 있습니다. 추가 확인과 실제 조치의 대상·인자를 연결해야 합니다.

9장 서비스 계정과 동서 트래픽#

사람의 로그인 경로만 보호하면 서비스 간 호출·배치·관리 포트가 우회로로 남을 수 있습니다. 워크로드 신원·짧은 자격증명·기능·대상 자원을 필요한 범위로 제한합니다. 같은 내부 계정이나 키를 여러 서비스가 공유하는 경로를 조사합니다.

네트워크 분리는 확산을 줄이는 보완 수단입니다. 실제 요청별 인가와 집행이 필요한 이유를 분리해 설명합니다.

10장 관리 콘솔 하나부터 적용한다#

대상 자원·관리자·업무·단말을 파악하고 강한 인증·관리 기기·기능 권한을 연결합니다. 권한 변경·분실·위험 신호·세션 회수·직접 우회를 시험합니다. 관측과 운영을 확인한 뒤 다른 자원으로 확대합니다.

flowchart TB
 I["자원과 신원 파악"] --> P["정책과 집행 위치"]
 P --> T["제한된 적용·우회 시험"]
 T --> R["변경·회수·장애 검증"]
 R --> E["운영 가능한 범위 확대"]

11장 정책 서버 장애의 선택#

모든 오류를 무제한 허용하면 보호가 사라지고 무조건 차단하면 중요한 업무가 중단될 수 있습니다. 업무별 장애 조건·제한된 긴급 접근·승인·시간·기록을 미리 정합니다. 긴급 경로를 정규 접근보다 넓은 영구 예외로 만들지 않습니다.

복구 후 긴급 변경과 접근을 검토하고 원래 정책이 적용되는지 시험합니다. 가용성과 보안의 판단을 사고 중 임의로 바꾸지 않도록 준비합니다.

12장 정책 우회 경로를 찾는다#

중앙 게이트웨이 외의 직접 IP·관리 포트·구형 API·배치·내부 연결을 조사합니다. UI가 정책을 지키더라도 다른 경로가 집행점을 거치지 않으면 결과가 달라질 수 있습니다. 실제 연결과 서버의 거부를 확인합니다.

허용한 요청에도 애플리케이션 인가·상태·입력 검증이 필요합니다. 하나의 PEP 통과가 다른 모든 자원의 권한을 증명하지 않습니다.

13장 효과는 접근 경계와 정상 업무로 평가한다#

불필요한 접근·회수 지연·우회·민감 조치의 통제를 측정하고 정상 이용자의 성공률·복구 시간·지원 부담도 봅니다. 제품 수와 로그인 횟수만으로 아키텍처의 성과를 판단하지 않습니다.

정책과 실제 집행, 변경·회수·장애 증거가 연결되면 제로 트러스트를 추상적인 구호가 아니라 설명 가능한 운영 구조로 만들 수 있습니다.

14장 적용 사례와 운영 방법#

관리자 콘솔은 강한 인증과 관리 기기 조건을 요구하고 작업 범위를 제한합니다. 위험 신호가 발생하면 세션을 회수하거나 추가 확인을 적용합니다. 서비스 계정·워크로드 신원과 동서 트래픽도 범위에 포함해야 사용자의 로그인 경로만 보호하는 데서 끝나지 않습니다.

15장 제로 트러스트 정책 판단과 집행#

flowchart LR
 U["주체·기기"] --> P["PEP: 요청 집행"]
 P --> E["PE: 접근 판단"]
 S["정책·자원·위협 신호"] --> E
 E --> A["PA: 연결 제어"]
 A --> P
 P -->|"허용된 요청"| R["보호 자원"]

16장 정책 판단 정보의 출처와 갱신을 확인한다#

정책 엔진이 단말 상태를 판단하더라도 오래된 검사 결과를 무기한 신뢰하면 위험한 단말에 접근이 계속될 수 있습니다. 사용자·기기·워크로드 신원의 출처, 위험 신호의 갱신 주기, 속성 누락 때의 동작을 정해야 합니다. 내부 주소라는 사실 하나를 허용 근거로 사용하지 않습니다.

PE는 결정, PA는 연결 제어, PEP는 실제 집행의 역할로 읽으면 구성이 쉬워집니다. 정책을 거치지 않고 자원에 직접 접근하는 경로가 있다면 중앙 정책이 있어도 우회가 가능합니다. 관리 포트·배치·서비스 간 호출도 실제 집행 경로에 넣습니다.

17장 하나의 관리 자원부터 단계적으로 적용하기#

관리 콘솔을 대상으로 자산과 사용자를 파악하고 필요한 업무 범위를 정합니다. 강한 인증·관리 단말·작업 권한을 정책으로 연결한 뒤 위험 신호와 권한 변경 시 세션 회수를 시험합니다. 이후 서비스 계정과 동서 트래픽으로 확대하면 관측·운영상의 공백을 확인하기 쉽습니다.

정책 서버 장애가 나면 무제한 허용할지 무조건 차단할지를 업무별로 미리 정해야 합니다. 제한된 긴급 접근은 승인·시간·기록을 두고 복구 후 검토합니다. 접근 가능성이 줄어드는 성과와 정상 업무의 성공률을 함께 측정해야 운영 가능한 구조가 됩니다.

18장 적용 전 확인할 사항#

사용자·기기·워크로드·자원 목록을 확보한다
정책 판단과 집행 위치를 연결한다
권한 회수·재평가·장애 시 동작을 검증한다

19장 자주 묻는 질문#

VPN을 없애야 제로 트러스트인가요?#

네트워크 연결 기술보다 접근 판단과 자원 보호 방식이 핵심입니다. 기존 연결을 사용하는 환경도 신원·조건 기반 인가와 최소 권한을 적용할 수 있습니다.

제로 트러스트는 모든 사용자를 매번 의심해 로그인시키는 방식인가요?#

자동으로 신원과 맥락을 평가하고 필요한 경우 추가 확인하는 구조입니다. 매 요청의 수동 로그인과 동일한 뜻은 아닙니다.

PEP를 통과한 요청은 이후 모든 시스템에서 허용해도 되나요?#

허용은 대상 자원·행위·세션 조건의 범위에서 해석해야 합니다. 다른 시스템의 권한과 위험 조건까지 자동으로 충족하지는 않습니다.