제로 트러스트 아키텍처

간략한 요약

ZT (Zero Trust) 는 네트워크 경계가 더 이상 신뢰할 수있는 영역으로 간주되지 않는 보안 모델입니다. 각 요청 (사용자 → 앱, 서비스 → 서비스, 장치 → 네트워크) 은 상황 신호 (신원, 장치 상태, 위치, 위험, 동작) 를 고려하여 명시 적으로 인증, 권한 부여 및 암호화됩니다. 목표는 폭발 반경을 최소화하고 측면 이동의 위험을 줄이며 준수를 단순화하는 것입니다.

제로 트러스트 기초

1. 명시적인 신뢰가 없음-신뢰는/VPN/ASN 네트워크에서 상속되지 않습니다.
2. 접근은 최소한의 필요입니다. "지금 필요한 것만 제공하는 정책".
3. 지속적인 검증: 세션 및 토큰은 정기적으로 위험 및 컨텍스트에 대해 재평가됩니다.
4. 타협의 가정: 세분화, 관찰 가능성, 빠른 격리 및 주요 회전.
5. 어디에서나 암호화: TLS 1. 2+/1. KMS/HSM의 데이터 요금제 내부 3 및 mTLS, 보호 된 DNA, 비밀.

대상 조경 및 제어 도메인

신원: 인간 (IdP: SSO, MFA, Passkeys/FIDO2), 기계 (SPIFFE/SVID, x509/mSL).
장치: 정책 준수 (MDM/EDR, 디스크 암호화, 패치, 탈옥/루트 금지).
네트워크: L3/L7 마이크로 세그먼트, ZTNA/SDP 게이트웨이, 서비스 메쉬 (Envoy/Istio/Linkerd).
응용 프로그램/API: mSL, OIDC/JWT, 요청 서명 (HMAC), 속도 제한, DLP/마스킹.
데이터: 분류 (공개/기밀/제한), 필드 레벨의 토큰 화/암호화.
관찰 가능성: 중앙 집중식 인증/인증 로그, 행동 분석, SLO/SLA.

참조 아키텍처 (평면별로 분류)

제어 비행기: IdP/CIAM, PDP/PEP (OPA/Envoy), 정책 카탈로그, PKI/CA, 장치 자격.
데이터 평면: 프록시 액세스 (ZTNA), mTLS 및 L7 정책에 대한 사이드카 프록시 (Envoy), GW 서비스 게이트웨이/API.
관리 비행기: 서비스 카탈로그, CMDB, CI/CD, 비밀 관리 (Vault/KMS), 중앙 집중식 감사.

1. 식별 (SSO + 피싱 저항성 MFA) → 2) 장치 평가 (MDM 자세) → 3) ZTNA 프록시는 응용 프로그램에 mTLS를 설정합니다 → 4) PDP (정책) 는 속성 (ABAC/RBAC) → 5) 연속 위험 재평가 (시간, 지리, 이상).

신원 및 승인

IdP/SSO: OIDC/SAML, 기본 MFA, 바람직하게는 FIDO2 (통과).
RBAC/ABAC: 역할 + 컨텍스트 속성 (장치 상태, 부서, 위험 프로파일).

JIT (Just-In-Time) 액세스: 자동 취소가있는 임시 권한; 브레이크 글래스-엄격하게 규제됩니

기계 용 mTLS: SPIFFE/SVID 또는 수명이 짧은 인증서가있는 내부 PKI; 자동 로터리 릴리스.

장치 및 상황

자세: OS/EDR 버전, 디스크 암호화, 방화벽; 비준수 → 최소 액세스 또는 블록.
증명: 장치 신원 + 서명 된 증명 (MDM/Endpoint).
네트워크 제한: 타사 터널 블록, 강제 기업 DNS, DNA/WebRTC 누출에 대한 보호.

네트워킹 및 미세 분해

"평평한" VLAN 폐기: 대신 세그먼트/VRF 및 L7에 대한 정책.
서비스 메시: 사이드카 프록시는 mSL, 정책 승인 (OPA/EnvoyFilter), 원격 측정을 제공합니다.
ZTNA/SDP: 네트워크가 아닌 특정 응용 프로그램에 대한 액세스; kliyent ² 브로커 앱, PDP 정책.
원격 액세스: "두꺼운" VPN을 앱 프록시로 대체; 대체 터널은 경로/포트로 제한됩니다.

정책 및 솔루션 엔진

PDP/PEP: 정책 결정 포인트 (OPA/Styra, 삼나무) + 정책 시행 지점 (특사/Istio/게이트웨이).
정책 모델: 선언적 규칙 (Rego/Cedar), 정적 및 상황 적 속성, 위험 평가.

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

추적 솔루션: 감사를 위해 '입력 '/' 결과 '/' 설명' 로그.

기본 암호화 및 신뢰

TLS 1. 2+/1. 모든 곳, 엄격한 암호 스위트, HSTS, OCSP 스테이플링.
내부 mTLS: 서비스 인증서는 상호 인증서에 의해서만 가능합니다. 단기 키 (시간/일).
비밀: KMS/HSM, 동적 비밀 (Vault), 짧은 TTL, 응용 프로그램에 대한 최소 권한.

관찰 가능성, SLO 및 응답

• 인증 및 인증 성공 (%), p95 PDP 결정 시간, p95 TLS 핸드 셰이크.
• 정책에 의해 차단 된 요청 비율 (이상/거짓).
• ZTNA 브로커 및 Mesh 컨트롤러의 가용성.
• 호환 장치 및 트렌드의 비율.

• "ZTNA 소 99 가용성. 95 %/월; p95 작은 Z 결정
• "mTLS를 사용한 요청의 비율 9%».
• "0을 넘지 않습니다. 1% 잘못된 액세스 실패/일 ".

출발: 거부의 폭발, p95 핸드 쉐이크의 저하, 유효하지 않은 체인, 호환 장치의 비율 감소, 지리 이상/ASN.

주변에서 제로 트러스트로 이동: 로드맵

1. 인벤토리: 응용 프로그램, 데이터 흐름, 소비자, 감도 (PII/카드/지불).
2. 아이덴티티 및 MFA: 모두를위한 SSO 및 피싱 방지 MFA.
3. 장치 컨텍스트: MDM/EDR, 기본 준수 정책, 비준수 블록.

4. 우선 순위 경로의 미세화: 지불, 백 오피스, 관리자; mTLS를 입력하십시오

5. 사용자 액세스를위한 ZTNA: 프록시를 통해 응용 프로그램을 게시하고 "와이드 VPN" 을 제거하십시오.
6. ABAC 정책: 중앙 집중식 PDP, 선언적 규칙, 감사.
7. 서비스 메쉬 확장: S2S mSL, L7 정책, 원격 측정.
8. 자동화 및 SLO: 경고, 정책 테스트 (정치 CI), 게임 일 "IdP를 사용할 수없는 경우 어떻게해야합니까? ».

iGaming/fintech의 특성

엄격한 도메인 세분화: 지불/PII/사기 방지/콘텐츠-별도의 경계 및 정책; ZTNA를 통해서만 액세스하십시오.
PSP/뱅크와의 상호 작용: ASN/range의 허용 목록, mTLS에서 PSP 엔드 포인트까지의 허용 목록, Time-to-Wallet 모니터링 및 autZ 실패.
콘텐츠 제공 업체 및 파트너: 임시 JIT API 액세스, 짧은 TTL 토큰, 통합 감사.
준수: PCI DSS/GDPR-데이터 최소화, DLP/가명 화, 민감한 테이블에 대한 액세스 로깅.

공급망 보안 및 CI/CD

아티팩트 서명 (SLSA/Provenance): 컨테이너 서명 (cosign), K8의 입학 정책.
SBOM 및 취약점: SBOM 생성 (CycloneDX), 파이프 라인의 정책 게이트.
CI의 비밀: OIDC 연맹-Cloud KMS; 정적 키에 대한 금지.
회전: 빈번하고 자동으로; 사건에 대한 강제 철회.

일반적인 버그 및 패턴 방지

"ZTNA = 새로운 VPN": 응용 프로그램 대신 네트워크를 게시하는 것은 제로 트러스트가 아닙니다.
장치 확인 없음: MFA는 있지만 감염/뿌리 장치는 액세스 할 수 있습니다.
단일 슈퍼 사용자: JIT 부족 및 별도의 역할.
서비스 코드의 정책: 중앙 감사/업데이트가 불가능합니다.
mTLS 부분: mTLS가없는 서비스의 일부 → "누설 된" 루프.
제로 UX: 중복 MFA 요청, SSO 없음; 결과-명령에 대한 저항.

기술 선택을위한 미니 가이드

사용자 액세스: ZTNA/SDP 브로커 + IdP (OIDC, FIDO2 MFA).
서비스 중 보안: 서비스-메시 (Istio/Linkerd) + OPA/Envoy 저작권.
PKI: 짧은 TTL을 가진 SPIFFE/SVID 또는 Vault PKI.
정치인: OPA/Rego 또는 Cedar; Git에 저장하고 CI (정책 테스트) 를 확인하십시오.
로그 및 원격 측정: OpenTelemetry → 중앙 집중식 분석, 이상 감지.

샘플 구성 (조각)

특사 (서비스 간 상호 TLS)

yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego: 근무 시간 동안 호환 장치의 "금융" 에서만 보고서에 액세스

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

제로 트러스트 구현 점검표

1. 모든 사용자 및 관리자에게 SSO 및 FIDO2 MFA 사용

2. 비준수 잠금 장치로 장치 자세 (MDM/EDR) 를 입력하십시오.
3. 사용자 액세스를 ZTNA (앱 당) 로 전송하고 좁은 S2S 채널의 경우에만 VPN을 남깁니다.
4. 기본적으로 + 수명이 짧은 인증서로 내부 -mTLS.
5. 중앙 집중식 정책 (PDP/OPA), Git에 저장, CI에서 테스트.
6. 세그먼트 민감한 도메인 (결제/PII/백 오피스) 및 동서 제한.
7. 원격 측정법, SLO를 설정하고 자세 신호에 대해 경고합니다.
8. "게임 일" (IdP 실패, 키 누출, 브로커 드롭) 을 수행하고 SOP/롤백을 수정하십시오.

FAQ

제로 트러스트가 VPN을 완전히 대체합

사용자 액세스의 경우-예, ZTNA에 유리합니다. S2S 트렁크의 경우 VPN/IPsec은 그대로 유지 될 수 있지만 mTLS가 초과되고 엄격한 정책이 있습니다.

ZT가 UX를 악화시킬 수 있습니까?
무의식적으로. SSO + FIDO2, 적응 형 MFA 및 앱 당 액세스를 통해 UX는 일반적으로 향상됩니다.

서비스 메쉬를 도입해야합니까?
항상 그런 것은 아닙니다 그러나 넓은 마이크로 서비스 환경의 경우 메쉬는 mSL/정책/원격 측정을 근본적으로 단순화합니다.

합계

Zero Trust는 제품이 아니라 건축 분야입니다. 새로운 경계, 장치 컨텍스트, ZTNA (Application Access), 마이크로 세그먼트 및 mTLS, 중앙 집중식 정책 및 측정 가능한 신뢰성. 로드맵 및 점검표를 따르면 "기본 신뢰" 없이 공격 표면을 줄이고 감사 속도를 높이며 지속 가능한 보안을 얻을 수 있습니다.