Zero Trust와 최신 IT 이슈
Zero Trust의 자원 중심 접근통제와 정책 구성요소를 이해하고 SBOM·공급망 보안·양자내성암호·디지털 트윈 등 최신 이슈를 구분한다.
1. Zero Trust의 핵심
Zero Trust는 네트워크 내부·외부라는 위치만으로 암묵적인 신뢰를 부여하지 않고, 보호할 자원에 대한 각 접근을 신원·장치·상태·정책·위험에 따라 검증하는 보안 접근이다.
사용자·장치·서비스
│ 접근 요청
▼
신원·장치상태·위치·행동·자원 민감도
│ 정책 평가
▼
최소권한 접근 허용
│
▼
지속 모니터링·재평가
“아무도 믿지 않는다”는 구호보다 명시적 검증, 최소권한, 침해 가정, 자원 중심 보호를 이해해야 한다.
2. 기존 경계보안과의 차이
전통 경계 중심
Internet ─ Firewall ─ 내부망
내부는 상대적으로 신뢰
Zero Trust
모든 사용자·장치·워크로드
─ 개별 정책·검증 ─► 각 자원
방화벽과 네트워크 분리를 버리는 것이 아니라 신원·장치·애플리케이션·데이터 정책과 결합한다.
3. 기본 원칙
- 모든 데이터·서비스를 자원으로 간주
- 네트워크 위치와 무관하게 통신 보호
- 세션별 자원 접근 허용
- 최소권한
- 사용자·장치·워크로드의 동적 정책
- 접근 전 인증·인가
- 자산·보안상태의 지속 측정
- 가능한 많은 텔레메트리를 이용해 정책 개선
인증에 한 번 성공했다고 세션 전체를 영구 신뢰하지 않는다.
4. 논리 구성요소
NIST의 대표 논리 구조:
Subject
│ 요청
▼
Policy Enforcement Point(PEP)
│ 판단 요청
▼
Policy Administrator(PA)
│
▼
Policy Engine(PE)
├─ 신원·권한
├─ 장치 상태
├─ 위협 정보
├─ 자원 정책
└─ 행동·환경
│ 허용·거부·조건
▼
PA가 세션 설정
↓
PEP가 실제 접근 집행
- Policy Engine: 정책결정
- Policy Administrator: 연결·세션 설정과 종료
- Policy Enforcement Point: 트래픽·접근을 실제 허용·차단
제품 구현에서는 구성요소가 결합될 수 있다.
5. 정책 입력
사용자
- 계정·역할·MFA·위험
장치
- 등록·패치·암호화·EDR
요청
- 시간·위치·행동·프로토콜
자원
- 보안등급·업무·데이터 민감도
환경
- 위협정보·이상징후·현재 장애
예:
재무담당자
AND 관리 장치
AND MFA 성공
AND 업무시간
AND 국내 승인 네트워크
→ 재무 시스템 읽기 허용
대량 다운로드
→ 재인증·추가승인·차단
6. 사용자·장치·워크로드 신원
Zero Trust는 사람 계정만 보는 것이 아니다.
- 사용자 신원
- 장치 신원·상태
- 서비스·워크로드 신원
- API·자동화 계정
- 컨테이너·함수·VM
- 인증서·토큰·키
Service A ─ workload identity ─► Service B
서비스 간 통신도 상호인증과 최소권한이 필요하다.
7. 세분화와 지속평가
Micro-segmentation은 자원·워크로드 사이 통신을 작게 나누어 침해 확산을 줄이는 방법 중 하나이다. 그러나 Zero Trust 전체를 네트워크 세분화 하나와 동일시하면 안 된다.
Web → API : 443 허용
API → DB : 지정 계정·포트만
Web → DB : 차단
개발망 → 운영 DB : 기본 차단
지속평가는 세션 중 위험이 높아지면 다음 조치를 할 수 있다.
- 재인증
- 권한 축소
- 읽기 전용 전환
- 세션 종료
- 장치 격리
- 추가 승인
8. 도입 순서
중요 자원·데이터 식별
↓
사용자·장치·워크로드·흐름 파악
↓
정책과 최소권한 정의
↓
신원·장치·로그 기반 강화
↓
우선 업무부터 단계적 적용
↓
측정·예외·사용자 경험 개선
한 번에 전사망을 전환하기보다 중요 자원과 위험이 높은 경로부터 적용하는 것이 현실적이다.
9. Zero Trust의 오해
- VPN을 없애는 제품 하나가 아님
- 내부 사용자를 무조건 차단하는 방식이 아님
- MFA 하나만 도입하면 완성되는 것이 아님
- 네트워크 분리만 의미하지 않음
- 신뢰를 완전히 제거하는 것이 아니라 매 요청의 신뢰 판단을 명시적으로 관리
- 기존 보안통제를 모두 교체하기보다 통합·강화
10. 소프트웨어 공급망과 SBOM
소프트웨어는 자체 코드뿐 아니라 오픈소스·상용 라이브러리·빌드도구·컨테이너 이미지·CI 플러그인으로 구성된다.
개발자 코드
+ 외부 라이브러리
+ 빌드 도구
+ Base Image
+ 배포 패키지
↓
최종 소프트웨어
SBOM은 소프트웨어를 구성하는 컴포넌트와 공급망 관계를 기록한 목록이다.
활용:
- 취약 라이브러리 영향 분석
- 라이선스 확인
- 구성요소·버전 식별
- 사고 시 신속한 탐색
- 공급자 투명성
SBOM이 있다고 취약점이 자동 제거되는 것은 아니다. 서명·출처·빌드 재현성·취약점 관리·업데이트 절차와 결합해야 한다.
11. 공급망 보안 흐름
소스 출처 확인
↓
의존성 고정·검증
↓
빌드 환경 보호
↓
자동 테스트·취약점 검사
↓
SBOM 생성
↓
아티팩트 서명
↓
배포 시 서명·정책 확인
↓
운영 중 취약점·업데이트 추적
개발자 계정, 소스 저장소, CI/CD, 패키지 저장소가 침해되면 정상 서명된 악성 변경이 배포될 수 있으므로 전체 체인을 보호한다.
12. 양자내성암호(PQC)
충분히 큰 양자컴퓨터는 현재 널리 쓰이는 일부 공개키 암호에 위협이 될 수 있다. PQC는 양자 공격에도 안전하도록 설계한 공개키 알고리즘을 일반 컴퓨터에서 실행하는 기술이다.
NIST가 2024년에 확정한 표준:
| 표준 | 알고리즘 이름 | 목적 |
|---|---|---|
| FIPS 203 | ML-KEM | 키 캡슐화·공유비밀 설정 |
| FIPS 204 | ML-DSA | 디지털 서명 |
| FIPS 205 | SLH-DSA | 해시 기반 디지털 서명 |
현재 암호자산 조사
↓
인증서·프로토콜·제품·데이터 수명 파악
↓
교체 가능한 Crypto-Agility 확보
↓
PQC 호환성·성능 시험
↓
단계적 혼합·전환
↓
기존 키·데이터·인증서 정리
HQC는 NIST가 2025년에 추가 표준화 대상으로 선택했지만 2026년 현재 최종 FIPS로 완성된 세 표준과 동일하게 취급하면 안 된다. FIPS 206 관련 작업도 최종 상태를 공식 자료에서 계속 확인해야 한다.
13. Crypto-Agility
Crypto-Agility는 알고리즘·키 길이·인증서·프로토콜을 시스템 전체 재개발 없이 교체할 수 있는 능력이다.
- 암호 알고리즘 하드코딩 제거
- 키·인증서 목록과 만료 관리
- 프로토콜 협상
- 라이브러리 추상화
- 성능·메시지 크기 시험
- 구 알고리즘 폐기 계획
“Harvest Now, Decrypt Later” 위험 때문에 장기간 기밀성을 유지해야 하는 데이터는 양자컴퓨터가 현실화되기 전부터 전환 계획이 필요할 수 있다.
14. 디지털 트윈
디지털 트윈은 실제 물리·비물리 개체의 상태와 행동을 전자적으로 표현해 모니터링·예측·시뮬레이션·최적화를 지원한다.
현실 자산
⇄ 센서·상태·명령
디지털 트윈
⇄ 모델·시뮬레이션
운영 의사결정
최신 이슈로 볼 때 다음을 함께 묻는다.
- IoT·Edge 연계
- 모델 신뢰성과 검증
- 양방향 데이터 교환
- 전체 생명주기 연결
- 사이버·물리 보안
- 표준과 상호운용성
단순 3D 모델과 디지털 트윈을 구분한다.
15. Serverless와 Event-Driven Computing
Serverless는 사용자가 서버 프로비저닝을 직접 관리하는 부담을 줄이고 함수·관리형 서비스를 이벤트에 따라 실행하는 클라우드 실행모델이다.
이벤트·HTTP·파일
↓
Function 실행
↓
DB·Queue·API
↓
실행량 기반 확장·과금
장점:
- 자동 확장
- 유휴 자원 관리 감소
- 빠른 이벤트 처리
주의:
- Cold Start
- 실행시간·환경 제약
- 상태 관리
- 관측성
- 공급자 종속
- 권한과 이벤트 위조
- 예상치 못한 비용
PaaS·컨테이너·Serverless의 책임 경계와 실행 단위를 구분한다.
16. 최신 이슈 학습법
최신 기술은 제품명을 외우기보다 다음 틀로 정리한다.
① 해결하려는 문제
② 핵심 원리와 구성요소
③ 기존 기술과 차이
④ 장점과 한계
⑤ 보안·법·운영 위험
⑥ 실제 적용 사례
⑦ 표준화·성숙도
참고 기준
- NIST SP 800-207: Zero Trust Architecture
- NIST Post-Quantum Cryptography Project
- NIST IR 8356: Digital Twin Security and Trust
- NIST SBOM Glossary
17. Zero Trust 정책 결정 흐름
NIST ZTA의 대표 논리 구성은 Policy Engine(PE), Policy Administrator(PA), Policy Enforcement Point(PEP)이다.
접근 요청 → PEP → PE가 신원·장치·자원·위험·정책 평가
↓
허용/거부/추가인증
↓
PA가 세션 명령·구성
↓
PEP 집행
MFA를 한 번 통과했다고 세션 전체를 무조건 신뢰하지 않는다. 장치 준수상태, 위치, 행동, 위협정보, 자원 민감도에 따라 권한을 축소하거나 재인증·차단할 수 있다. 정책이 충돌하면 고위험 환경에서는 명시적 deny 우선과 같은 결합 규칙을 사전에 정한다.
18. 공급망 증적: SBOM·VEX·Provenance
- SBOM: 제품에 포함된 구성요소 목록
- VEX: 특정 취약점이 해당 제품에 실제로 영향이 있는지에 대한 상태 설명
- Provenance: 누가 어떤 소스·빌드 환경·절차로 산출물을 만들었는지에 대한 증적
SBOM만 있다고 악성 빌드나 취약성 악용 가능성이 자동 차단되는 것은 아니다. 서명 검증, 격리된 빌드, 최소권한 CI, 의존성 고정, 비밀정보 보호와 배포 정책이 함께 필요하다.
19. PQC와 Crypto-Agility
NIST가 2024년 확정한 핵심 표준은 다음과 같다.
- FIPS 203 ML-KEM: 키 캡슐화
- FIPS 204 ML-DSA: 격자 기반 전자서명
- FIPS 205 SLH-DSA: 해시 기반 전자서명
PQC 마이그레이션은 알고리즘 교체만이 아니라 인증서·프로토콜·HSM·성능·키·메시지 크기·상호운용성 점검을 포함한다. 현재 암호문을 저장했다가 미래 양자컴퓨터로 해독하려는 harvest-now-decrypt-later 위험 때문에 장기 기밀 데이터부터 암호 자산을 조사한다.
Crypto-agility는 알고리즘·키 길이·인증서·프로토콜을 코드 전체에 고정하지 않고 정책과 추상화를 통해 교체 가능하게 하는 능력이다. 전환기에는 기존 방식과 PQC를 함께 쓰는 hybrid 접근이 사용될 수 있으나 결합 방식과 실패 정책을 검증해야 한다.
20. Serverless·Event-Driven의 상태 문제
Serverless는 서버가 없다는 뜻이 아니라 인프라 운영의 많은 부분을 제공자가 관리한다는 뜻이다. Cold start, 실행시간 제한, 동시성, 외부 상태, 관측성과 vendor lock-in을 고려한다.
이벤트 재시도는 중복을 만들 수 있으므로 idempotency key, 처리 상태, DLQ, 최대 재시도와 backoff가 필요하다. 세 계층이 각 3회씩 재시도하면 최악의 호출 수가 3³=27로 증폭될 수 있다.
21. 최신 이슈를 다루는 방법
최신 기술 문제는 제품 이름보다 다음 불변 질문으로 판정한다.
- 어떤 신뢰 경계와 자산을 보호하는가?
- 상태·권한·데이터 흐름이 어디에 존재하는가?
- 장애·재시도·부분 실패에서 결과가 어떻게 되는가?
- 표준이 최종인지 초안인지, 기준일이 언제인가?
- 공급망·개인정보·비용·운영 복잡성까지 포함했는가?
확인 문제
- 접근 요청을 실제로 차단·허용하는 ZTA 구성요소는?
- FIPS 203의 ML-KEM 용도는?
- SBOM과 VEX의 차이는?
- 3계층이 각각 최대 3회 호출하면 최악 호출 수는?
- Zero Trust가 의미하는 것은 내부 사용자를 모두 차단하는 것인가?