ZTA-ZTNA-SDP
ZTA-ZTNA-SDP
이 글의 흐름 VPN의 한계 → 접근통제 기본 개념 → ZTA(설계 원칙) → ZTNA(서비스 접근) → SDP(연결 구조) → CISA ZTMM(운영 성숙도)
VPN의 구조와 한계
VPN 구조와 역할
- EX) 집에서 회사의 프로젝트 자료를 확인하는 경우, 회사 시스템까지 인터넷을 지나 통신해야 하므로 그 구간에서 정보를 보호할 통로가 필요함
- 원격 접속 VPN은 업무용 단말과 회사의 VPN 게이트웨이 사이에 보호 터널을 만듦
- 터널이 연결된 다음에도 이용 범위는 따로 정함 → 프로젝트 자료를 이용하는 통신은 허용하면서 서버 관리 접속은 제한할 수 있음
flowchart LR
U[재택 단말] -- 암호화 터널 --> G[VPN 게이트웨이]
subgraph 회사 내부망
G --> B[형상관리 서비스 B]
G -.->|원래는 막아야 함| C[서버관리 서비스 C]
G -.-> D[기타 내부 시스템]
end
한계
- VPN은 “터널 안으로 들어왔는가”를 기준으로 신뢰하기 쉬움 → 한 번 접속하면 내부망 전체가 보이는 경우가 많음
- 업무보다 넓은 접근은 침해 후 다른 내부 시스템으로 수평 이동(Lateral Movement) 할 기회를 늘림
- VPN 게이트웨이 자체가 인터넷에 노출되어 있어 취약점 공격의 대상이 됨
문제 → 필요한 접근 통제
| 문제 | 필요한 접근 통제 |
|---|---|
| 업무보다 넓은 내부 접근 | 필요한 사용자와 장치의 이용 범위를 구체화 |
| 처음 확인한 권한을 계속 신뢰 | 업무와 장치 상태가 바뀌면 다시 확인 |
| 변경의 실제 반영 여부가 불명확 | 규칙 전달과 적용 결과를 확인 |
| 외부에 노출된 접속 관문 | 취약점, 설정과 접근 권한을 관리 |
이 네 가지 요구가 뒤에 나오는 ZTA(재평가), ZTNA(서비스 단위 접근), SDP(서비스 은닉) 로 이어진다.
네트워크와 접근통제의 기본 개념
- 네트워크 : 데이터를 주고받는 통신 환경
- 노드 : 통신에 참여하는 장치
- 서비스 : 장치가 제공하는 기능
- EX) 형상관리 서비스 B, 서버관리 서비스 C
주소, 포트, 통신 경로와 접근 권한
| 용어 | 의미 | 예시 |
|---|---|---|
| IP 주소 | 데이터를 보낼 목적지 | 10.0.1.20 |
| 포트 | 같은 주소에서 수신 지점(서비스) 구분 | 22(SSH), 443(HTTPS) |
| 프로토콜 | 통신할 때 따르는 규약 | TCP, UDP, TLS |
| 통신 경로 | 데이터가 전달되는 길 | 단말 → 게이트웨이 → 서버 |
| 접근 권한 | 정한 범위가 이용할 허가 | “개발팀은 B의 443만 허용” |
접근 요청의 구성
접근 요청은 “누가(주체) 무엇에(자원) 무엇을(작업) 어떤 상황에서(조건)” 하려는지로 표현할 수 있다.
| 구성 | 의미 | 예시 |
|---|---|---|
| 주체 | 접근을 요청하는 사용자, 장치나 프로그램 | 개발자 A의 회사 노트북 |
| 자원 | 이용할 서비스나 데이터 | 형상관리 서비스 B |
| 작업 | 자원에서 수행할 행위 | 코드 조회(read), 푸시(write) |
| 조건 | 허용 판단에 사용하는 현재 정보 | MFA 완료, 보안 패치 최신, 업무 시간 |
인증, 인가, 통신 보호의 차이
| 구분 | 질문 | 의미 | 대표 기술 |
|---|---|---|---|
| 인증 (Authentication) | 너 누구야? | 제시한 신원이 맞는지 확인 | 비밀번호, MFA, 인증서 |
| 인가 (Authorization) | 이거 해도 돼? | 요청한 자원과 작업의 허용 여부 판단 | RBAC, ABAC, ACL |
| 통신 보호 | 중간에 새거나 바뀌지 않았어? | 전달 중 기밀성과 무결성 보호 | TLS, mTLS, IPsec, WireGuard |
인증에 성공했다고 인가까지 된 것은 아니다. “회사 직원이 맞다(인증)”와 “이 서버에 관리자로 접속해도 된다(인가)”는 별개의 판단이다.
접근 정책과 최소 권한
- 접근 정책 : 누구에게 어떤 자원을 어떤 조건에서 허용할지 정함
- 최소 권한(Least Privilege) : 맡은 업무에 필요한 범위만 허용하는 원칙
- 침해가 일어나도 공격자가 이용할 수 있는 범위가 줄어듦
접근 정책의 판단, 전달 진행
- 요청 주체(사람이나 장치)가 보호 자원(이용하려는 서비스)에 접근을 시도함
- 요청은 자원으로 바로 가지 않고 먼저 집행 지점을 거침. 집행 지점은 통신을 허용하거나 차단하는 관문
- 허용된 경우에만 통신이 보호 자원까지 이어짐
sequenceDiagram
participant S as 요청 주체
participant E as 집행 지점
participant D as 판단 기능
participant C as 설정 전달 기능
participant R as 보호 자원
S->>E: 접근 요청
E->>D: ① 판단 정보 전달 (누가, 어떤 장치로, 무엇에)
D->>D: ② 신원과 정책 평가
D->>C: 허용 / 거부 결정
C->>E: ③ 집행 지점이 적용할 설정으로 변환해 전달
alt 허용
E->>R: ④ 통신 개방
else 거부
E-->>S: ④ 차단
end
- 집행 지점은 요청에 대해 판단에 필요한 정보(누가, 어떤 장치로, 무엇에 접근하려는지)를 판단 기능에 넘김
- 판단 기능은 신원과 정책을 평가해 허용 여부를 결정함
- 설정 전달 기능은 그 결정을 집행 지점이 적용할 수 있는 설정으로 바꿔 내려보냄
- 집행 지점은 받은 설정대로 통신을 열거나 막음
제어 평면과 데이터 평면
| 구분 | 접근통제 관점 | 네트워크 관점 |
|---|---|---|
| 제어 평면 (Control Plane) | 신원과 정책 평가, 연결 설정 전달 | 패킷을 어디로 보낼지 정함. 라우팅 프로토콜로 경로를 계산하고, 라우팅 테이블과 정책을 만들어 장비에 내려줌 |
| 데이터 평면 (Data Plane) | 허용한 경로에서 업무 데이터 전달과 접근 진행 | 제어 평면이 만든 테이블을 보고 실제 사용자 패킷을 받아 전달하거나 차단함 |
제어 평면은 “결정”, 데이터 평면은 “실행” 이다. Zero Trust 구조에서는 이 둘을 분리해, 데이터가 흐르기 전에 제어 평면에서 먼저 판단하는 것이 핵심이다.
Fabric Controller, Network Map, Node Agent
flowchart TB
FC["Fabric Controller<br/>(제어 평면)"]
subgraph 데이터 평면
A1["Node Agent<br/>개발자 PC"]
A2["Node Agent<br/>형상관리 서버 B"]
A3["Node Agent<br/>서버관리 C"]
end
FC -- "Network Map(PC용)" --> A1
FC -- "Network Map(B용)" --> A2
FC -- "Network Map(C용)" --> A3
A1 -. "상태 보고" .-> FC
A1 == "허용: 직접 암호화 통신" ==> A2
A1 -. "차단 ✕" .- A3
- Fabric Controller : 정책을 평가하고 연결 설정을 생성해 전달
- 전체 네트워크의 중앙 두뇌로, 제어 평면 역할을 함
- 사용자와 기기 인증, 기기 등록, 접근 정책(ACL) 관리, 암호화 키 배포, 각 노드에 줄 설정 계산 등
- Network Map : 노드에 전달할 연결 정보와 접근 규칙의 묶음
- 컨트롤러가 노드마다 따로 만들어 내려주는 설정 묶음
- 이 노드가 통신할 수 있는 상대 노드 목록
- 상대의 주소와 공개키
- 적용할 접근 규칙, DNS, 라우팅 정보
- Node Agent : 등록과 상태 보고, 로컬 설정 적용 및 결과 확인
- 각 기기(PC, 서버, 게이트웨이)에 설치되는 프로그램으로, 데이터 평면에서 시행자 역할을 함
- 컨트롤러에 접속해 Network Map을 받아옴
- 맵을 실제 설정으로 바꿈 → 가상 네트워크 인터페이스, 암호화 터널, 방화벽 규칙 등
- 허용된 상대와 직접 암호화 통신을 맺고, 허용되지 않은 통신은 차단함
- 기기 상태(OS 버전, 보안 설정 등)를 컨트롤러에 보고함
Tailscale, NetBird 같은 WireGuard 기반 오버레이 네트워크가 이 구조의 대표적인 예이다.
ZTA
Zero Trust Architecture : Zero Trust 원칙에 따라 접근 통제를 구성하는 보안 아키텍처
- 회사 내부에 있거나 회사 소유 장치라는 사실만으로 접근을 넓게 허용하지 않고, 보호할 자원과 요청할 접근을 기준으로 판단함
- Zero Trust : 신원과 현재 조건을 확인해 필요한 자원에 필요한 권한만 허용하는 원칙 → “Never Trust, Always Verify”
- Architecture : 시스템 구성요소의 역할과 관계를 정한 전체 구조
경계 기반 보안 vs Zero Trust
| 구분 | 경계 기반 보안 (Perimeter) | Zero Trust |
|---|---|---|
| 신뢰 기준 | 네트워크 위치 (내부 = 신뢰) | 신원 + 장치 상태 + 현재 조건 |
| 접근 단위 | 네트워크 대역 전체 | 개별 자원, 세션 단위 |
| 검증 시점 | 접속할 때 한 번 | 접근 전 + 이용 중 지속적으로 |
| 침해 시 영향 | 내부 전체로 확산 가능 | 허용된 자원으로 한정 |
| 대표 기술 | 방화벽, VPN | ZTNA, SDP, 마이크로 세그멘테이션 |
NIST SP 800-207
- 미국 국립표준기술연구소(NIST)가 2020년 8월에 발간한 제로 트러스트 아키텍처 표준 가이드라인
- 자원을 파악하고 필요한 접근을 정하는 일에서 시작해, 신원과 상태를 근거로 판단하고 통신을 보호하며 변화를 관찰하는 데까지 이어짐
제로 트러스트의 7대 기본 원칙 (Tenets)
| # | 원칙 | 내용 |
|---|---|---|
| 1 | 보호 대상 | 데이터와 컴퓨팅 서비스를 자원으로 관리 |
| 2 | 통신 보호 | 네트워크 위치에 관계없이 모든 통신 보호 |
| 3 | 최소 권한 | 개별 자원에 세션 단위로 필요한 권한 부여 |
| 4 | 동적 정책 | 신원과 자원, 단말 및 현재 조건으로 판단 |
| 5 | 자산 상태 | 보유하거나 연관된 자산의 무결성과 보안 상태 확인 |
| 6 | 지속적 평가 | 접근 전 인증과 인가, 이용 중 조건 재평가 |
| 7 | 정보 활용 | 자산과 통신 정보를 수집해 보안 개선 |
주요 논리적 컴포넌트 : PE, PA, PEP
앞에서 본 “판단 기능 - 설정 전달 기능 - 집행 지점”이 NIST에서는 각각 PE - PA - PEP 로 정의된다.
flowchart LR
subgraph CP["제어 평면"]
PE["PE<br/>Policy Engine<br/>(판단)"]
PA["PA<br/>Policy Administrator<br/>(연결 제어)"]
PE <--> PA
end
subgraph SRC["판단 근거 (입력 정보)"]
direction TB
I1[ID 관리 / IdP]
I2[단말 상태 / EDR]
I3[위협 정보]
I4[활동 로그 / SIEM]
end
SRC --> PE
S["주체<br/>(사용자·기기)"] -- 요청 --> PEP["PEP<br/>Policy Enforcement Point<br/>(집행)"]
PA -- "세션 허용/종료 지시" --> PEP
PEP == "허용된 통신 (데이터 평면)" ==> R["보호 자원"]
| 컴포넌트 | 역할 | 비유 |
|---|---|---|
| PE (Policy Engine, 정책 엔진) | 정책과 관측 정보를 평가해 연결을 허용할지 거부할지 결정하는 두뇌 | 판사 |
| PA (Policy Administrator, 정책 관리자) | PE의 결정을 바탕으로 세션을 생성하거나 종료하도록 지시. 세션용 인증 토큰이나 자격 증명을 발급하기도 함 | 집행관 |
| PEP (Policy Enforcement Point, 정책 집행 포인트) | 주체와 자원 사이 실제 통신을 가로채고, 검증이 완료된 후에만 연결을 열어줌. 실제 통신이 허용 범위를 따르도록 집행 | 출입문 경비 |
PE와 PA를 합쳐 PDP(Policy Decision Point) 라고 부르기도 한다. PE와 PA는 하나의 제품 안에 함께 구현되는 경우가 많다.
Trust Algorithm
- PE가 정책과 관측 정보를 평가해 자원 접근을 결정하는 절차
| 방식 | 판단 방법 | 장점 | 단점 |
|---|---|---|---|
| 조건 기반 (Criteria-based) | 정한 조건을 모두 충족하면 허용 (조건에 최근 접근 이력까지 포함) | 결과를 설명하기 쉬움 | 조건이 많아지면 경직됨 |
| 점수 기반 (Score-based) | 여러 신호로 종합 점수를 계산해 자원별 기준과 비교 (최근 행동에 따라 점수 갱신) | 상황 변화에 유연 | 왜 거부됐는지 설명하기 어려움 |
- EX) 조건 기반 : “MFA 완료 AND 회사 관리 기기 AND 업무 시간” → 허용
- EX) 점수 기반 : 신원 30 + 기기 상태 25 + 위치 15 = 70점 → 일반 문서(기준 60점)는 허용, 소스코드 저장소(기준 80점)는 거부
RBAC, ABAC
| 구분 | RBAC (Role Based Access Control) | ABAC (Attribute Based Access Control) |
|---|---|---|
| 판단 기준 | 역할 | 여러 속성(사용자, 자원, 환경)의 조합 |
| 구조 | 사용자 → 역할 → 권한 | IF 속성 조건 THEN 허용 |
| 예시 | “개발자” 역할은 저장소 쓰기 허용 | “개발팀 AND 회사 기기 AND 09~18시”이면 저장소 쓰기 허용 |
| 장점 | 단순하고 관리가 쉬움, 감사할 때 설명하기 좋음 | 세밀하고 동적 정책에 적합함 |
| 단점 | 상황을 반영하지 못함, 역할이 세분화되면 역할 폭발 및 예외 관리 부담 | 규칙이 복잡해지기 쉽고, 속성 데이터를 정확하게 유지해야 함 |
실무에서는 RBAC로 기본 권한을 정하고, ABAC로 현재 조건(기기 상태, 위치, 시간)을 덧붙이는 혼합 방식이 많이 쓰인다. Zero Trust의 “동적 정책” 원칙은 ABAC 쪽에 가깝다.
ZTA 배치 형태 (Deployment Models)
PEP를 어디에, 어떤 형태로 두느냐에 따라 ZTA 배치 형태를 네 가지로 나눔. 어느 형태든 PE와 PA의 역할은 같고, 달라지는 것은 시행 지점(PEP)의 위치임
flowchart LR
subgraph M1["① 에이전트/게이트웨이"]
direction LR
a1[기기 + 에이전트] == 터널 ==> g1[게이트웨이] --> r1[자원]
end
subgraph M2["② 엔클레이브 게이트웨이"]
direction LR
a2[기기 + 에이전트] == 터널 ==> g2[게이트웨이] --> r2[자원 묶음<br/>Enclave]
end
subgraph M3["③ 자원 포털"]
direction LR
a3[브라우저<br/>에이전트 없음] --> g3[포털] --> r3[자원]
end
subgraph M4["④ 애플리케이션 샌드박스"]
direction LR
a4[기기 안<br/>격리된 업무 앱] --> g4[PEP] --> r4[자원]
end
| 배치 형태 | 구성 | 적합한 경우 | 장점 | 단점 |
|---|---|---|---|---|
| 에이전트/게이트웨이 기반 | 사용자 기기에 에이전트, 자원 앞에 게이트웨이. 에이전트가 PA에 요청하고, 허용되면 에이전트와 게이트웨이 사이에 암호화 터널이 열림 | 회사 관리 기기가 대부분이고, 자원별로 세밀하게 통제하고 싶을 때 | 자원 단위의 세밀한 통제 | 자원마다 게이트웨이 필요, 에이전트 배포 부담 |
| 엔클레이브 게이트웨이 | 게이트웨이가 자원 하나가 아니라 자원 묶음(Enclave) 앞에 놓임 (데이터센터의 특정 구역, 레거시 시스템 묶음 앞에 게이트웨이 하나) | 레거시 시스템처럼 자원마다 에이전트나 게이트웨이를 둘 수 없을 때 | 기존 환경에 적용하기 쉬움 | 엔클레이브 내부는 개별 통제가 약해, 안에 들어오면 다른 자원에도 닿을 수 있음 |
| 자원 포털 기반 | 기기에 에이전트 없이 포털(게이트웨이)이 PEP 역할. 사용자는 브라우저 등으로 포털에 접속 | 개인 기기, 협력사, 외부 인력처럼 에이전트를 설치할 수 없을 때 | 배포가 쉽고 기기 제약이 적음 | 기기 상태 정보를 충분히 얻기 어렵고, 포털 자체가 공격 대상이 될 수 있음 |
| 애플리케이션 샌드박스 | 승인된 앱을 기기 안의 격리된 공간에서 실행하고, 샌드박스가 PEP와 통신 | 기기 자체를 완전히 믿기 어렵지만, 업무 앱만은 보호하고 싶을 때 | 기기가 감염되어도 업무 앱과 데이터가 분리됨 | 모든 업무 앱을 샌드박스로 관리해야 하므로 운영 부담이 큼 |
재평가 (Continuous Evaluation)
- 접근 허용은 한 번 받으면 끝나는 것이 아니라 조건이 바뀔 때마다 다시 판단되며, 판단 결과가 실제 통신 설정에 반영될 때까지 확인해야 함
- 관측 정보와 자원 민감도에 따라 접근을 조정함
| 관측 정보 | 확인 내용 |
|---|---|
| 계정과 인증 상태 | 계정이 정상인지, MFA를 했는지, 인증한 지 얼마나 지났는지, 권한이나 역할이 바뀌었는지 |
| 단말과 서비스 상태 | 기기 보안 패치와 EDR 동작 여부, 접근하려는 서비스가 정상인지 |
| 접근 이력과 위협 정보 | 평소와 다른 시간이나 위치에서 접속했는지, 알려진 위협 IP나 공격 징후가 있는지 |
flowchart LR
O["관측 정보 변화<br/>(계정·단말·위협)"] --> PE["PE<br/>현재 조건 재평가"]
PE --> PA["PA<br/>변경 지시 전달"]
PA --> PEP["PEP<br/>실제 통신에 반영"]
PEP --> K{결과}
K -->|문제 없음| A1[접근 유지]
K -->|애매함| A2["추가 확인<br/>MFA 재인증, 기기 점검"]
K -->|위험| A3["범위 축소 또는 종료<br/>읽기 전용 전환, 세션 끊기"]
PEP -. "반영 결과 확인" .-> PA
- 정책 재평가
- PE가 현재 조건을 평가함 (위 정보와 정책을 비교해 지금도 허용할지 결정)
- PA가 변경 지시를 전달함 (결정을 PEP에 내려 실제 통신에 반영, PE → PA → PEP 구조가 그대로 쓰임)
- 결과에 따른 조치
- 접근 유지 : 조건에 문제가 없으면 그대로 둠
- 추가 확인 : 애매하면 MFA 재인증이나 기기 점검 등을 요구함
- 범위 축소 또는 종료 : 위험하면 읽기 전용으로 바꾸는 등 접근 범위를 줄이거나 세션을 끊음
관련 NIST 후속 문서
| 문서 | 초점 | 주요 내용 |
|---|---|---|
| SP 800-207 | 개념과 원칙 | 7대 원칙, PE/PA/PEP, 배치 형태 |
| SP 800-207A | 클라우드 네이티브 환경 | 클라우드에서 이동하는 서비스의 신원과 호출 권한을 일관되게 관리 |
| SP 1800-35 | 실제 구현 사례 | 여러 상용 기술을 연결해 실제로 구성한 사례 제공 |
- SP 800-207A : 접근 정책을 세 계층으로 나눠 함께 적용함
- 네트워크 : 허용한 경로와 포트
- 서비스 신원 : 호출 서비스의 신원과 호출 권한 (EX. 서비스 메시의 mTLS 인증서)
- 사용자와 자원 : 사용자의 자원별 작업 권한
- SP 1800-35 : NCCoE(NIST 국가 사이버보안 우수센터)의 실증 프로젝트
- 구성 : 신원, 단말 상태와 접근 집행을 연결한 아키텍처
- 검증 : 업무 시나리오와 실제 동작 결과
- 교훈 : 연계의 한계와 추가로 해결할 운영 과제
ZTNA
Zero Trust Network Access : 신원과 정책, 현재 조건에 따라 서비스(애플리케이션) 단위로 접근을 허용하고 계속 통제하는 접근법
- ZTA가 “전체 설계 원칙”이라면, ZTNA는 그 원칙을 원격 접속/서비스 접근에 적용한 구체적인 방식
- 흔히 VPN의 대체재로 소개됨
VPN vs ZTNA
| 구분 | VPN | ZTNA |
|---|---|---|
| 접속 결과 | 내부 네트워크에 들어감 | 허용된 애플리케이션에만 연결됨 |
| 신뢰 시점 | 접속할 때 한 번 인증 | 요청마다 + 이용 중 재평가 |
| 판단 근거 | 주로 계정 인증 | 사용자 + 장치 상태 + 위치·시간 등 여러 신호 |
| 서비스 노출 | 게이트웨이가 인터넷에 노출 | 서비스는 숨기고 브로커/커넥터를 통해서만 연결 |
| 침해 시 영향 | 내부망 수평 이동 가능 | 허용된 앱 범위로 제한 |
NCSC의 ZTNA 설계 요구
NCSC : 영국 국가사이버보안센터(National Cyber Security Centre)
| # | 요구 | 내용 |
|---|---|---|
| 1 | 안전한 전송 | 사용자로부터 애플리케이션까지 통신 보호 |
| 2 | 접근 전 정책 집행 | 정책을 만족한 요청에만 접근 허용 |
| 3 | 여러 신호로 판단 | 사용자와 장치의 신원, 상태를 함께 확인 |
| 4 | 애플리케이션 노출 축소 | 승인된 서비스에 필요한 접근만 제공 |
| 5 | 침해 영향 제한 | 다른 서비스와 구간으로의 확산 제한 |
| 6 | 조건 변화 재평가 | 계정과 장치 상태의 변화를 접근에 반영 |
| 7 | 관측 가능성 | 허용과 거부의 이유, 실제 활동을 기록 |
| 8 | 복원력과 가용성 | 정책 오류와 구성요소 장애에 대비 |
네트워크 접근 정책과 서비스 내부 권한
접근 통제는 여러 층에서 일어나며, ZTNA가 담당하는 범위와 서비스가 스스로 관리해야 하는 범위가 다르다.
flowchart LR
U[사용자] --> L1
subgraph L1["① 네트워크 접근"]
subgraph L2["② 애플리케이션 접근"]
L3["③ 서비스 내부 권한"]
end
end
| 계층 | 통제 범위 | 예시 | 주로 담당 |
|---|---|---|---|
| 네트워크 접근 | 도달 가능한 서비스와 구간 | 형상관리 서버의 443 포트에 도달 가능 | 방화벽, ZTNA |
| 애플리케이션 접근 | 사용할 수 있는 애플리케이션 | GitLab에 로그인 가능 | ZTNA, IdP(SSO) |
| 서비스 내부 권한 | 데이터와 작업의 범위 | 프로젝트 X 저장소에 push 가능 | 애플리케이션 자체 권한 관리 |
ZTNA로 앱 접근을 잘 통제해도, 앱 내부 권한이 과도하면 최소 권한 원칙이 깨진다. 세 계층을 함께 설계해야 한다.
SaaS에서의 ZTNA 접근
SaaS는 회사 네트워크 밖에 있으므로 게이트웨이 대신 IdP(신원 제공자)와 SSO 가 접근 판단 지점 역할을 한다.
sequenceDiagram
participant B as 브라우저
participant S as SaaS
participant I as IdP + 정책 엔진(PE)
B->>S: ① SaaS 접속, TLS 연결 (아직 로그인 전)
S-->>B: ② 조직 IdP 로그인 화면으로 리다이렉트 (SAML / OIDC)
B->>I: ③ 인증 (ID, 비밀번호, MFA)
I->>I: ③ 조건 평가 (관리 기기? 위치·시간? SaaS 이용 권한?)
alt 정책 충족
I-->>B: ④ 서명된 승인 증명 (SAML Assertion / ID Token)
B->>S: ⑤ 승인 증명 제출
S->>S: ⑤ 회사 IdP 서명 검증
S-->>B: 세션 시작
else 정책 불충족
I-->>B: 거부 또는 추가 인증 요구
end
- SaaS 접속과 TLS 연결 (브라우저 → SaaS)
- 사용자가 브라우저로 SaaS 주소에 접속함
- 암호화된 TLS 연결이 맺어지지만, 아직 로그인 전
- 조직 SSO로 이동 (SaaS → 브라우저)
- SaaS가 브라우저를 조직의 IdP(Identity Provider, 신원 제공자) 로그인 화면으로 보냄(리다이렉트)
- SaaS가 직접 비밀번호를 받지 않고 인증을 회사에 맡기는 단계 (SAML, OIDC 같은 SSO 표준을 사용)
- 사용자 인증과 조건 평가 (브라우저 → IdP와 정책 엔진) → 제로 트러스트 판단이 일어나는 단계
- 인증 : 아이디, 비밀번호, MFA로 신원 확인
- 조건 평가 : 정책 엔진(PE 역할)이 상황을 확인함
- 회사 관리 기기인가, 보안 상태는 정상인가
- 접속 위치와 시간은 평소와 같은가
- 이 사용자가 이 SaaS를 쓸 권한이 있는가
- 승인 결과 전달 (IdP → 브라우저)
- IdP가 서명된 승인 증명(SAML Assertion 또는 OIDC ID Token)을 브라우저에 줌
- 승인 결과 확인 후 서비스 이용 (브라우저 → SaaS)
- 브라우저가 토큰을 SaaS에 제출
- SaaS는 토큰의 서명이 회사 IdP 것이 맞는지 확인한 뒤 세션을 엶
여기서 NIST 컴포넌트와 대응시키면 IdP + 정책 엔진 = PE/PA, SaaS의 토큰 검증 = PEP 역할이다.
SDP
Software-Defined Perimeter : 요청 측, 제어 기능, 수신 측을 두고 승인된 상대만 보호 서비스에 연결되도록 구성하는 구조. 서비스에 업무 데이터를 보내기 전에 신원과 권한을 확인하고 연결할 범위를 준비함
- CSA(Cloud Security Alliance)가 제안한 구조로, ZTNA를 구현하는 대표적인 방식
- 물리적 방화벽 경계 대신 소프트웨어로 사용자별 경계를 만든다는 의미
SDP의 구성 요소
| 구성 | 명칭 | 역할 | ZTA 대응 |
|---|---|---|---|
| 요청 측 | IH (Initiating Host) | 접근을 요청하고 보호 연결을 맺음 | 주체 |
| 제어 기능 | SDP Controller | 신원과 정책을 확인하고 연결 관계 조정 | PE + PA |
| 수신 측 | AH (Accepting Host) | 허용된 상대의 연결만 받아 서비스로 전달 | PEP |
SDP의 연결 절차
sequenceDiagram
participant IH as IH (요청 측)
participant CT as SDP Controller
participant AH as AH (수신 측)
AH->>CT: 0. AH가 먼저 컨트롤러에 등록 (mTLS)
IH->>CT: 1. 준비와 제어 통신 (SPA → mTLS, 신원·접근 요청)
CT->>CT: 2. 정책 평가
CT-->>IH: 2. 접근 인가: 연결 가능한 AH 목록
CT-->>AH: 2. 접근 인가: 허용할 IH 정보
IH->>AH: 3. 보호 연결 (SPA → 상호 인증 mTLS)
IH->>AH: 4. 업무 통신 (허용 범위 내)
- 준비와 제어 통신
- 요청 측이 제어 기능에 신원과 접근 요청을 알림
- 접근 인가
- 제어 기능이 정책을 평가하고, 허용한 연결에 필요한 정보를 요청 측과 수신 측에 각각 전달함
- 보호 연결
- 상호 신원 확인 후 보호 연결 수립
- 업무 통신
- 허용 범위에서 업무 데이터 전송
핵심은 “인증 먼저, 연결은 나중에(Authenticate first, connect second)” 이다. 일반적인 TCP 서비스는 연결부터 받고 나서 인증하지만, SDP는 인증되지 않은 상대의 연결 자체를 받지 않는다.
SPA (Single Packet Authorization)
- SDP는 전체 아키텍처이고, SPA는 SDP 안에서 쓰는 핵심 기술 하나
- 보호 연결을 받기 전에, 암호로 보호한 단일 패킷으로 요청을 먼저 검증함
- 컨트롤러와 AH는 기본적으로 모든 포트를 닫아두고(Default Drop), 올바른 SPA 패킷을 보낸 상대에게만 잠시 포트를 열어줌
flowchart LR
X[공격자 / 스캐너] -. "포트 스캔" .-> FW
IH[IH] -- "① SPA 패킷 (UDP, 암호화+HMAC)" --> FW["AH / Controller<br/>모든 포트 Drop"]
FW --> V{"② 검증<br/>신원·권한·재전송"}
V -->|성공| O["③ 해당 IH의 IP에만<br/>포트 임시 개방"]
V -->|실패| D[무시, 응답 없음]
O --> T["④ mTLS 보호 연결"]
FW -. "응답 없음" .-> X
| 단계 | 내용 |
|---|---|
| 1. 승인 요청 | 암호로 보호한 SPA 메시지 전송 (사용자 ID, 타임스탬프, 난수, HMAC 등 포함) |
| 2. 요청 검증 | 신원과 권한, 재전송(Replay) 여부 확인 |
| 3. 허용 범위 반영 | 승인된 상대의 IP에만 접속 조건(방화벽 규칙) 설정 |
| 4. 보호 연결 | mTLS 등의 채널로 업무 통신 |
이전에 쓰이던 Port Knocking(정해진 순서로 여러 포트를 두드리는 방식)은 순서가 노출되면 재사용될 수 있었지만, SPA는 한 개의 암호화된 패킷에 타임스탬프와 HMAC을 넣어 재전송 공격과 위조를 막는다. 대표 구현으로
fwknop이 있다.
서비스 은닉과 Dark Cloud
- Dark Cloud
- 승인되지 않은 사람에게는 보호 자원이 아예 보이지 않게 만든 상태
- 서비스가 인터넷 어딘가에 있어도, 권한 없는 사람이 보기에는 어두운 구름 속에 가려진 것처럼 존재 자체가 드러나지 않는다는 뜻
- 효과
- 포트 스캔에 응답하지 않으므로 공격자가 공격 대상을 찾는 정찰 단계부터 막힘
- 패치되지 않은 취약점이 있어도 외부에서 도달할 수 없어 공격 면이 줄어듦
- VPN 게이트웨이처럼 “외부에 노출된 접속 관문” 문제를 해결
| 구분 | 일반 공개 서비스 | SDP로 보호된 서비스 |
|---|---|---|
| 포트 스캔 | 열린 포트가 보임 | 응답 없음 (닫힌 것처럼 보임) |
| DNS / 주소 | 누구나 확인 가능 | 승인된 IH만 컨트롤러에서 받음 |
| 연결 시도 | TCP 연결 후 인증 | SPA 검증 전에는 연결 불가 |
CISA ZTMM
CISA ZTMM (Zero Trust Maturity Model) : 조직이 Zero Trust를 어디에 적용하고 어떤 방향으로 운영을 개선할지 정리하는 성숙도 모델
- CISA : 미국 사이버보안·기반시설 보안국 (현재 v2.0, 2023년 4월)
- 성숙도 : 원칙을 업무에 일관되게 적용하고 변화에 맞춰 운영하는 수준
- ZTA가 “어떻게 설계할까”라면, ZTMM은 “지금 우리 조직은 어디까지 왔고, 다음엔 무엇을 해야 할까“를 묻는 도구
모델의 구성 : 5개 영역 × 3개 공통 역량 × 4단계
flowchart TB
subgraph P["다섯 보안 영역 (관리할 대상)"]
direction LR
P1[신원<br/>Identity]
P2[장치<br/>Devices]
P3[네트워크<br/>Networks]
P4[애플리케이션<br/>Applications & Workloads]
P5[데이터<br/>Data]
end
subgraph C["세 공통 역량 (모든 영역을 가로지름)"]
direction LR
C1[가시성과 분석]
C2[자동화와 조정]
C3[거버넌스]
end
P --- C
- 다섯 보안 영역 (Pillars) : 무엇을 관리하고 보호할지
| 영역 | 핵심 질문 |
|---|---|
| 신원 | 누가 어떤 권한을 가지는지 |
| 장치 | 어떤 장치가 어떤 상태인지 |
| 네트워크 | 어떤 통신을 허용하는지 |
| 애플리케이션과 워크로드 | 서비스를 어떻게 실행하고 이용하는지 |
| 데이터 | 어떤 정보를 어떻게 보호하는지 |
- 세 공통 역량 (Cross-Cutting Capabilities) : 여러 영역의 운영을 어떻게 연결할지
| 역량 | 의미 | 운영에서 확인할 것 |
|---|---|---|
| 가시성과 분석 | 상태와 사건을 보고 의미와 원인을 파악 | 변경 내용과 실제 적용 결과 확인 |
| 자동화와 조정 | 절차를 자동 실행하고 작업 순서와 연계를 조정 | 관련 시스템에 변경 전달 결과 확인 |
| 거버넌스 | 조직의 기준과 책임, 승인 및 검토 절차 | 승인자와 변경 근거, 재검토 기준 결정 |
- 네 성숙도 단계 : 현재 상태와 다음 개선 방향
flowchart LR
T["Traditional<br/>전통"] --> I["Initial<br/>초기"] --> A["Advanced<br/>발전"] --> O["Optimal<br/>최적"]
| 단계 | 특징 | 신원 영역 예시 |
|---|---|---|
| Traditional (전통) | 수동 설정과 고정 정책, 기능과 조직별로 나뉜 운영 | 비밀번호 위주 인증, 권한 수동 관리 |
| Initial (초기) | 일부 자동화를 시작하고 영역 간 정보와 작업 연결 | MFA 도입, 일부 시스템 SSO 연동 |
| Advanced (발전) | 여러 영역의 정보 통합, 상태와 위험에 따른 권한 조정 및 대응 자동화 | 피싱 저항 MFA, 위험 기반 접근 판단 |
| Optimal (최적) | 조직 전반의 정보를 연결해 필요한 시점과 범위에 맞게 조정 | 지속적 검증, 필요한 순간에만 권한 부여(JIT) |
VPN의 한계에서 본 “변경의 실제 반영 여부가 불명확” 문제는 ZTMM의 가시성과 분석, 자동화와 조정 역량으로 다뤄진다.
ZTA, ZTNA, SDP, ZTMM의 차이와 관계
flowchart TB
ZTMM["CISA ZTMM<br/>조직 운영과 발전 수준 평가"]
ZTA["ZTA (NIST SP 800-207)<br/>Zero Trust 전체 설계 원칙"]
ZTNA["ZTNA<br/>서비스 접근 통제 방식"]
SDP["SDP (CSA)<br/>승인된 보호 연결 구조"]
SPA["SPA<br/>서비스 은닉 기술"]
ZTMM -- "얼마나 잘 운영하나 평가" --> ZTA
ZTA -- "원칙을 원격 접속에 적용" --> ZTNA
ZTNA -- "구현 방식 중 하나" --> SDP
SDP -- "핵심 기술" --> SPA
| 구분 | 한 줄 정의 | 관점 | 핵심 질문 | 대표 문서 |
|---|---|---|---|---|
| ZTA | Zero Trust 전체 설계 | 아키텍처 | 신원과 조건, 접근 판단, 집행과 재평가를 어떤 구조로 할까? | NIST SP 800-207 |
| ZTNA | 서비스 접근 통제 | 접근 방식 | 사용자가 어떤 서비스에 어떻게 접근하도록 허용하고 통제할까? | NCSC, Gartner |
| SDP | 승인된 보호 연결 | 구현 구조 | 요청 측과 수신 측에 연결 정보를 제공하고 수신 범위를 어떻게 구성할까? | CSA SDP Spec |
| ZTMM | 조직 운영과 발전 수준 | 운영 / 평가 | 신원부터 데이터까지 운영 범위와 자동화, 관측 수준은 어디까지 왔나? | CISA ZTMM v2.0 |
정리하면 ZTA는 “무엇을 지켜야 하는가(원칙)”, ZTNA와 SDP는 “어떻게 구현하는가(방법)”, ZTMM은 “얼마나 잘하고 있는가(평가)” 에 대한 답이다.
This post is licensed under CC BY 4.0 by the author.