1. 개요
• 섹션 2 : ZT 및 ZTA 정의 및 기업간 ZTA 설계 시 고려사항 나열
• 섹션 3 : ZT의 논리 컴포넌트(또는 빌딩 블록) 설명 동일한 논리적 기능을 제공하면서도, 제로 트러스트 아키텍처 컴포넌트를 다르게 구성하도록 독특하게 구현 가능
• 섹션 4 : 기업 환경을 더 안전하게 할 수 있는 ZTA의 유스케이스 소개
• 섹션 5 : ZTA를 사용하는 기업이 처할 수 있는 위협 언급
• 섹션 6 : ZTA 원리를 기존 지침에 적합하게 하거나 보완하는 방법 설명
• 섹션 7 : 기업을 ZTA로 전환하기 위한 출발선을 명시. ZT 원리가 적용된 애플리케이션 및 기업 인프라스트럭처를 계획/배치하는데 필요한 단계 설명
2. 제로트러스트(ZT)의 기초
- 항상 검증을 전제로 리소스 보호에 초점을 맞춘 사이버 보안 패러다임
- 제로트러스트 아키텍처(ZTA)sms 기업의 리소스/데이터를 보호하기 위한 E2E 접근법
ZT와 ZTA의 정의
- 제로 트러스트란, 네트워크가 침해된 상황에서 정보시스템 및 서비스가 각각의 요청에 대한 접근 권한을 정확하고 최소한으로 판단하려고 할 때 불확실성을 최소화하기 위한 개념과 발상의 모음. 제로 트러스트 아키텍처란, 제로 트러스트 개념을 사용한 기업 사이버 보안 계획이며, 컴포넌트간 관계, 워크플로우 설계, 액세스 정책이 포함됨. 따라서, 제로 트러스트 엔터프라이즈란, 제로 트러스트 아키텍처를 실행함으로써 기업에 존재하는 네트워크 인프라스트럭처(물리/가상) 및 정책을 말함
리소스 접근에 대한 개념적인 모델로 주체는 기업의 리소스에 접근할 때, 정책 결정 포인트(PDP) 및 정책 집행 포인트(PEP)를 통해 허가
시스템은 주체가 확실하고 요청이 유효하다는 것을 반드시 보증해야 함. 이때 정책 결정 포인트 및 정책 집행 포인트는 적절한 판단을 내려, 주체가 리소스에 접근하는 것을 허가함. 이는 제로 트러스트가 인증 및 인가라는 두 가지 기본적인 영역에 적용된다는 것을 의미함. 하지만 주체가 리소스에 접근하는 과정에서 허가를 내리기 위해서는 신뢰성, 접근성, 보안성을 점검하여야 하며, 기업은 주체가 기본적인 인증 수준을 만족했다고 해서 이후 모든 리소스 요청을 타당하다고 가정하여 판단하여서는 안됨(암묵적 신뢰 X)
제로트러스트의 원리
- 제로트러스트에 대한 다수의 정의/논의에서 광범위한 경계 방어(ex. 방화벽)를 제거하는 개념을 강조하고 있지만 모순적이게도 대부분의 정의/논의에서 ZTA가 가져야 할 기능으로써 경계를 어떤 방법으로든(마이트로 세크멘테이션, 마이크로 퍼리미터 등) 정의하고 있음. 그런 관점에서 제로트러스트를 실현하기 위해 포함해야 하는 기본 원리에 대한 정의를 내림
1. 모든 데이터 소스 및 서비스를 리소스로 간주. 개인이 소유한 디바이스 포함(ex. 휴대폰)
2. 네트워크 위치에 관계없이 모든 통신 보호. 위치기반 신뢰 X
3. 기업 리소스에 대한 접근을 세션 단위로 허가. 최소 권한으로 접근하도록 하며, 한 리소스에 인증/인가되었다고 해서 다른 리소스에 자동으로 접근하는 것을 허용하지 않아야 함
4. 동적 정책으로 리소스에 대한 접근 결정. id, app/service 등 기업이 계정/서비스에 할당한 모든 속성을 포함하여, 요청을 보낸 자산의 상태에 대한 동적 정책을 적용해 최소 권한 적용
5. 기업은 모든 자산의 무결성/보안 상태를 감시 및 조치. (모니터링)
6. 모든 리소스의 인증/인가를 동적으로 강력하게 실시한 후 접근 허용. 접근 획득 → 위협 스캔/평가 → 조정 → 지속적인 신뢰 재평가라는 일정한 사이클을 두고 접근 허용
7. 기업은 자산, 네트워크 인프라, 커뮤니케이션의 현 상태에 대해 가능한 많은 정보 수집. 자산의 보안 상태, 네트워크 트래픽, 접근 요청과 관련한 데이터 수집
네트워크에서 제로트러스트 관점
- 네트워크 계획/배치에 ZTA를 이용하는 조직은 네트워크 연결에 대해 기본적으로 가정하는 항목이 있으며, 이 가정을 통해 ZTA를 네트워크 어디에 배치할지를 경정
1. 기업의 프라이빗 네트워크 전체를 암묵적 트러스트 존으로 간주하지 않음. 기업의 네트워크 내에 항상 공격자가 존재한다는 가정하에 진행
2. 네트워크에 연결된 디바이스는 기업 소유 혹은 기업의 관리를 벗어날 수 있음. 용역이나 타 회사에서 네트워크에 접속할 경우 이 디바이스는 기업의 통제가 아닐 수 있음을 가정
3. 본질적으로 신뢰할 수 있는 리소스는 없음. 모든 자산에 대해 PEP로 보안 상태를 평가해야 하며, 그 이후 기업 소유의 리소스에 대한 요청을 허가해야 함.
4. 모든 기업 리소스가 기업 소유 인프라에 위치하고 있는 것은 아님. 클라우드 서비스, 원격 주체를 포함하여 리소스가 기업 소유가 아닌 로컬 네트워크 및 네트워크 서비스인 것을 고려
5. 기업의 원격 주체와 자산은 로컬 네트워크 연결을 완전히 신뢰할 수 없음. 원격 주체는 로컬 네트워크가 적대적이라고 가정
6. 기업-비기업 인프라를 사이의 자산 및 워크플로우의 보안 정택 및 보안상태의 일관성 보장.
3. 제로트러스트 아키텍처의 논리 컴포넌트
컴포넌트 및 컴포넌트 사이의 상호작용을 나타내며, 정책 결정 포인트는 2개의 논리 컴포넌트, 정책 엔진(PE)과 정책 관리자(PA)로 나눔. ZTA의 논리 컴포넌트는 컨트롤 플레인에서 통신하는 반면에 app은 데이터 플레인에서 통신
- 정책엔진(PE) : 주체에게 리소스의 접근 허가여부를 최종적으로 결정
- 정책관리자(PA) : 정책 집행 포인트에 명령하여 주체와 리소스 사이의 통신 경로 설정 및 폐쇄
- 정책 집행 포인트(PEP) : 주체와 기업 리소스 사이를 연결, 모니터링 및 연결 종료 수행
제로트러스트 아키텍처에 대한 다양한 접근법
- 기업의 워크플로우에 대해 ZTA를 수렴하는 접근법들은 사용하는 컴포넌트가 다르고, 정택 규칙의 메인 소스가 다름. 각 접근법은 ZT의 모든 원리를 실행하지만, 일부 원리에 중점을 정책을 수렴. 강화된 ID 거버넌스, 논리적 마이크로 세그멘테이션, 네트워크 기반 세그멘테이션
강화된 ID 거버넌스
- 행위자의 신원을 핵심 요소로 설정하여 정책 작성. id에 할당된 속성을 기반으로 진행하며, 리소스 접근을 위한 기본 요구사항은 주체에게 부여된 접근권한을 기반으로 결정
마이크로 세그멘테이션
- 기업은 보안 게이트웨이로 보호되는 단독 네트워크 세그먼트에 개별 리소스 또는 리소스 그릅을 배치하는 방식으로 ZTA를 구현. 이 접근법에서 기업은 개별 리소스 또는 관련된 소규모 리소스 그룹을 보호하는 인프라 디바이스를 배치하며, 이는 정책 집행 포인트 역할 수행
네트워크 기반 세그멘테이션
- 오버레이 네트워크를 사용하여 구현 가능(SDP). 소프트웨어 정의 네트워크 및 인텐트 기반 네트워킹의 개념을 주로 포함하여 정책 관리자는 네트워크 컨트롤러 역할 수행
제로트러스트 아키텍처의 다양한 배치
- 자산 하나가 다수 논리 컴포넌트 역할 수행 가능. 논리 컴포넌트 하나가 일을 실행하기 위해 다수의 하드웨어/서프트웨어로 구성될 수 있으며, 이 아키텍처의 컴포넌트를 배치하는 형태에는 몇가지 변형이 존재
디바이스 에이전트-게이트웨이 기반 배치
정책 집행 포인트를 2개의 컴포넌트로 분리하여, 정책 관리자가 리소스 접근에 대한 요청을 평가하기 위해 요청을 정책 엔진으로 포워딩한 후 인가되면, 데이터 플레인에서 디바이스 에이전트와 관련된 리소스 케이트웨이 사이의 통신 채널을 설정. 이 모델은 개별 리소스가 게이트웨이와 통신할 수 있고, 강력한 디바이스 관리 프로그램을 보유한 기업에 최적.
소규모 집합 기반 배치
위의 모델에서 소규모 리소스 집합을 설명하여 게이트웨이가 모든 리소스의 앞에 위치하지 않고, 소규모 리소스 집합에 위치함. 이러한 리소스들은 하나의 비즈니스 기능을 제공하거나, 게이트웨이와 직접 통신할 수 없을 수도 있음. 개별적으로 게이트웨이를 가질 수 없는 레거시 app 또는 데이터센터를 보유한 기업에 유용하며, 디바이스 에이전트를 설치/설정하기 위해, 견고한 자산 관리 프로그램 및 형상 관리 프로그램 필요
리소스 포털 기반 배치
주체 요청에 대한 게이트웨이로 동작. 게이트웨이 포털은 각 리소스별로 배치하거나, 하나의 비즈니스 기능을 위해 사용되는 소규모 보안 리소스 집합에 배치 가능. 이 모델의 장점은 모든 클라이언트 디바이스에 소프트웨어 컴포넌트를 설치할 필요가 없음. 기업 관리자는 각 디바이스에 적절한 에이전트가 설치되어 있는지 확인할 필요가 없지만 접근을 요청하는 디바이스로부터 제한된 정보만 추측 가능
디바이스 애플리케이션 샌드박싱
app/프로세스를 자산에서 격리하여 실행하는 모델. 주체는 심사되고 승인된 app을 샌드박스에서 실행하여 정책 집행 포인트와 통신, 리소스에 대한 접근을 요청함. 이 모델의 장점은 app이 자산 내에서 분리되어 있다는 것으로 자산의 취약점을 스캔할 수없더라도, 샌드박싱된 app이 악성코드에 감염되지 않도록 보호할 수 있음. 다만 기업은 모든 자산의 샌드박싱된 app을 관리해야 한다는 단점을 가짐.(즉 모니터링이 힘들다)
트러스트 알고리즘
- ZTA를 실시한 기업의 경우, 정책 엔진을 두뇌로, 정책 엔진의 트러스트 알고리즘을 주요한 사고 프로세스로 간주 가능.트러스트 알고리즘은 리소스에 대한 접근을 최종적으로 허가/거부하기 위해 정태 엔진이 사용하는 프로세스로 정책 엔진은 다양한 소스에서 입력을 가져옴
- 엑세스 요청 : 주체의 실제 요청으로 요청자에 대한 정보도 사용됨. 이 정보에는 OS 버전, 사요중인 소프트웨어, 패치 정보 등이 포함되어 정보와 자산의 보안 상태에 따라 접근 결정
- 주체 데이터베이스 : 누가 리소스에 접근을 요청하는지에 대한 것으로 기업 또는 협력사의 주체에 할당된 속성/권한의 모음
- 자산 데이터베이스 : 기업 소유 자산의 상태를 포함하는 데이터베이스로 자산 데이터베이스와 요청한 자산의 상태를 비교하여 자산에 대한 접근을 제한하거나 거부 가능
- 리소스 요구사항 : 사용자 ID 및 속성 데이터베이스를 보완하고, 리소스에 접근하기 위한 최소한의 요구사항을 정의. 데이터 관리자 및 데이터를 사용하는 비즈니스 프로세스 책임자 양족에서 개발되어야 함
- 위협 인텔리전스 : 일반적인 위협 및 유행하는 악성코드에 대한 정보 피드로 기업이 통제하지 않고, 서비스가 통제하고 있을 가능성이 높은 유일한 컴포넌트
네트워크/환경 컴포넌트
- ZT 환경에서는 네트워크를 제어/설정하는데 사용되는 커뮤니케이션 플로우와 조직에서 실무수행에 사용되는 app/service 커뮤니케이션 플로우가 논리적/물리적으로 분리되어야 함.
ZTA를 지원하기 위한 네트워크 요구사항
1. 기업 자산은 기본적으로 네트워크에 연결. LAN은 기업의 통제 여부와 관계없이 기본 라우팅과 인프라를 제공해야하며 원격 자산은 인프라의 모든 서비스를 사용하지 않을 수 있음
2. 기업은 기업이 소유하거나 관리하는 자산을 구별할 수있어야 하고, 디바이스의 현재 보안 상태를 구별 할 수 있어야 함.
3. 기업은 모든 네트워크 트래픽을 감시할 수 있어야 함. 기업은 데이터 플레인에서 검출된 패킷을 기록해야 하며, 기업은 접근 요청을 평가할 때 연결 관련 메타데이터를 필터링하여, 정책을 동적으로 업데이트하고, 정책 엔진에 전달해야 함
4. 정책 집행 포인트에 접근하지 않고, 기업 리소스에 접근할 수 없어야 함. 기업 리소스는 인터넷으로부터 임의의 연결을 받아들이지 않아야 함.
5. 데이터 플레인과 컨트롤 플레인은 논리적으로 분리해야 함. 정책 엔진. 정책 관리자. 정택 집행 포인트는 분리되어, 기업 자산/리소스가 직접 접근할 수 없는 네트워크에서 통신
6. 기업 자산은 정책 집행 포인트에 접근할 수 있어야 함. 이는 웹 포탈, 네트워크 디바이스 또는 소프트웨어 에이전트의 형태를 취할 수 있음
7. 정책 집행 포인트는 비즈니스 플로우에서 정책 관리자에 접근하는 유일한 컴포넌트임
8. 원격 기업 자산은 기업 네트워크 인프라를 통과하지 않고 기업 리소스에 접근 가능해야 함
9. ZTA의 접근 결정 프로세스에 사용되는 인프라는 프로세스 부하의 변화를 고려하여 확장
10. 정책 또는 식별가능한 요소에 의해, 기업 자산이 특정 정택 집행 포인트에 연결되는 것을 제한할 수 있어야 함
4. 배치 시나리오 / 유스케이스
- 대부분의 조직은 인프라에 제로트러스트의 일부 요소를 이미 가지고 있거나, 정보보안/복구정책/모법사례를 시행하는 중임. 일부 배치 시나리오 및 유스케이스는 ZTA에 매우 적합
위성 시설을 보유한 기업
- 본사와 복수의 자사로 구성된 기업이 가장 일반적인 시나리오. 자사의 직원들은 임무를 수행하기 위해 기업 리소스에 접근해야 하는데 기업은 이 접근에 대해 일부 리소스에 대해서만 접근을 허용하고, 민감한 리소스에 대해서는 접근을 제한/거부할 수 있음
멀티 클라우드 및 C2C를 이용하는 기업
- 다수의 클라우드 서비스 제공자를 사용하는 경우 기업은 로컬 네트워크를 가지고 있지만, 2개 이상의 클라우드 서비스 제공자를 사용하여 app/service 및 데이터를 호스팅하고 이 소스를 엑세스 포인트에 어떻게 정책 집행 포인트를 설치할 것인지 결정
5. 제로 트러스트 아키텍처 관련 위협
- 어떤 기업도 사이버 보안 위험을 제거할 수 없음. 기존에 가지고 있던 사이버 보안으로 보완하고, ZTA를 적절하게 시행/관리하면 전반적인 위험을 줄일 수 있고, 일반적인 위협으로부터 보호할 수 있음. 하지만 이러한 아키텍처 구현에도, 위협은 존재.
제로트러스트 아키텍처의 결정 프로세스 무력화
- ZTA에서 정책엔진 및 정책관리자는 핵심 요소임. 정책 엔진 및 관리자가 승인/설정하지 않으면, 기업 리소스 사이의 어떠한 커뮤니케이션도 이루어질 수 없으므로 이는 반드시 적절하게 설정/관리해야 한다는 것을 의미. 이에 대한 위험을 예방하기 위해 설정/모니터링을 수행하고, 모든 설정 변경을 반드시 기록/감시해야 함
DoS 또는 네트워크 장애
- 정책 관리자가 허가/설정하지 않으면 기업 리소스는 연결할 수 없음. 그런데 이때 서비스 거부 공격 또는 네트워크 장애가 발생하여 접근이 방해/거부되면 기업의 운영에 부정적인 영향을 줄 수 있으므로 기업은 사이버 내성에 관한 지침에 따라 위협을 완화할 필요가 있음.
크리덴셜 도용 및 내부자 위협
- ZT, 정보보안, 복구 정책, 모범 사례를 적절하게 시행하면, 크리덴셜 도용 또는 내부자 위협을 통해 공격자가 광범위한 접근을 얻는 위험을 줄일 수 있음. 공격자는 중요한 계정의 크리덴셜을 획득하기 위해 피싱, 사회공학, 또는 이러한 공격을 조합하여 사용할 수 있고, 이를 예방하기 위해 기업 관리자 계정에 대한 관리가 필요
네트워크 가시성
- 기업 네트워크의 일부 트래픽은 3계층 네트워크 분석 도구로 잘 보이지 않음. 이러한 트래픽은 기업이 소유하지 않는 자산이 원인이거나, 수동 모니터링에 내성이 있는 app/service의 원인이 될 수 있음. 이에 기업은 암호화된 트래픽에 대한 메타 데이터를 수집하여 이를 분석하기 위해 머신러닝을 사용하여 유효한 트래픽과 악의적일 수 있는 트래픽 분류가 가능함
시스템/네트워크 정보 스토리지
- 모든 중요한 기업 데이터는 인가되지 않은 접근 및 접근 시도를 예방하기 위해 적절히 보호되어야 하며, 가장 제한이 엄격한 접근정책을 설정하여, 지정된 관리자 계정만 접근할 수 있도록 해야 함
전용 데이터 포맷 또는 솔루션에 대한 의존
- 정보를 저장/처리하는데 사용되는 자산은 상호 작용 및 정보 교환에 대한 공통의 개방적인 표준이 없는 경우가 많으므로 상호 운용성 문제로 기업이 일부 제공자에게 종속되는 결과를 초래할 수 있음. 관련된 위협을 완화하기 위해, 기업은 벤더의 보안 통제, 교체 비용, 공급망 위험 관리, 성능, 안전성과 같은 요소를 고려하여 서비스 제공자를 종합적으로 평가해야 함.
비 인간 객체에 의한 제로트러스트 아키텍처 관리
- 인공지능 또는 소프트웨어 기반 에이전트에 대해 인간 관리자를 대신해, zta의 관리 컴포넌트와 상호작용해야 함. 설정 및 정책 집행에 자동화된 기술을 사용할 때 발생하는 가장 큰 위험은 기업의 보안 상태에 영향을 줄 수 있는 오탐과 미탐의 가능성으로 이는 잘못된 판단을 바로 잡고, 결정 프로세스를 개선하기 위한 정기적인 분석 튜닝을 통해 줄일 수 있음
6. 제로트러스트 아키텍처와 기존 가이드라인의 연계 가능성
- 기존 정책/가이드라인 중 일부는 ZTA의 계획/전개/운영과 접점이 존재. 이러한 정책들이 ZTA를 도입하는 것을 막지는 않지만, 전략 수립에 영향을 미칠 수 있음. 기존 사이버보안 정책/가이드라인, ICAM, 모니터링 등에 대한 보완이 필요하며 이를 보완했을 때, ZTA는 보안 상태를 강화할 수 있고, 일반적인 위협으로부터 보호할 수 있음
제로트러스트 아키텍처와 NIST 위험 관리 프레임워크
- 제로트러스트의 접근정책은 대부분의 상황에서 지나치게 제한적이어서 업무의 목표 달성을 저해할 수 있으므로, 미션 수행과 관련된 위험을 식별하고 평가하고, 받아들이거나 완화해야 함. 이를 돕기 위해 NIST 위험 관리 프레임워크가 개발되었고, 이를 시행하면 네트워크 경계 방어에 대한 의존성이 감소하기 때문에 전반적인 프로세스는 변하지 않음.
제로트러스트 아키텍처와 NIST 개인정보보호 프레임워크
- 연방 정보보안 현대화에 관련된 법률 등 컴플라이언스 프로그램은 프라이버시/데이터 보호를 포함. 이는 조직에서 저장/처리하는 사용자의 개인정보에 대한 위험을 식별/평가/완화하는 프로세스, 개인정보 위험과 완화전략을 설명하는 프레임워크를 제공하여 프라이버시와 관련된 위험에 대한 프로세스를 개선하는데 도움을 줄 수 있음
제로트러스트 아키텍처와 FICAM 아키텍처
- 제로트러스트 전개를 진행하기 전에 강력한 주체 프로비저닝 및 인증 정책을 마련해야 하며, 기업은 접근 요청을 평가하기 위해 정책 엔진이 사용할 수 있는 명확한 주체 속성 및 정책 필요
제로트러스트 아키텍처와 TIC 3.0
- TIC는 연방 사이버보안 이니셔티브이며, 연방 정부 전체의 네트워크 보안 베이스라인 수렴을 목적으로 함. 이는 엑세스 포인트가 보유해야 할 네트워크 기반 보안 기능의 목록을 제공하며, PEP가 배치된 네트워크 보호 정의를 위해 ZTA에서의 TIC 유스케이스가 개발될 가능성이 높음
제로트러스트 아키텍처와 EINSTEIN
- 여러 시스템을 통합한 시스템으로, 사이버 위협으로부터 연방 정부를 보호하기 위해 침입 탐지, 고급 분석, 정보 공유 및 침입 차단 기능을 제공. 또한 침입차단 기능을 제공하여 정책 집행을 알릴 수 있도록 발전한다면 ZTA를 구현한 연방 기관의 사고 대응 담당자는 인증, 트래픽 검사, 로그에서 정보를 얻을 수 있음.
제로트러스트 아키텍처와 미 국토안보부 상시 진단/완화 프로그램
- 연방 기관의 IT 기술을 개선하기 위한 것으로 시스템 보호를 위해 기관들은 자신의 인프라에 존재하는 기본적인 컴포넌트 및 액터를 발견/이해하기 위한 프로세스를 수립해야 함. 또한 기관들은 네트워크 활동을 분류/설정/감시하기 위해 네트워크에서 자산의 액티브 여부를 반드시 확인할 수 있어야 함
제로트러스트 아키텍처, 클라우드 스마트 전략, 연방 데이터 전략
- 기관리 ZTA를 계획할 때 일부 요구사항에 영향을 줌. 이런 정책들은 기관들이 온프레미스 및 클라우드에서 데이터를 수집/저장/엑세스하는 방법을 목록화하고 평가할 것을 요구. 이는 기업 간 협업 유스케이스에 부합하며, 이런 자산에 ZTA를 사용하는 기관들은 전략을 수립할 때 협업이나 공개 요구를 고려할 필요가 있음
7. 제로트러스트 아키텍처로의 전환
- ZTA를 시행하는 것은 인프라 또는 프로세스의 전면적인 교체보다는 여행이 가까움. 조직은 가장 높은 가치의 데이터를 보호하기 위해 점진적으로 제로트러스트 원칙을 구현하고, 프로세스를 변화시키고, 기술 솔루션을 도입해야함. 이는 상당기간 하이브리드 모드로 운영될 것을 의미하며 기업이 어떤 전략으로 전환할 것인지는 기업의 현재 사이버보안 상태 및 운영에 따라 달라질 수 있음.
순수 제로트러스트 아키텍처(기본)
- 그린필드 접근법을 선택하면, zta를 처음부터 구축가능. 기업은 업무에서 사용하고 싶은 app/service/워크플로우가 있다면, 그 워크플로우를 위한 아키텍처를 제로트러스트 원칙에 근거하여 만들 수 있음. 워크플로우를 식별하면, 기업은 필요한 컴포넌트를 최소화할 수 있고, 각 컴포넌트가 어떻게 상호작용할지 매핑할 수 있음.
하이브리드 아키텍처(기존환경 + ZT)
- 주요 기업이 기술 교체 주기로 제로트러스트로 전환할 수 있는 가능성은 낮음. 기업에서 ZTA 워크플로우와 ZTA가 아닌 워크플로우가 상존하는 시기를 명확하게 구분할 수 없기 때문에 기업은 공통요소에 대해 제로트러스트 및 경계 기반 하이브리드 아키텍처에서 운영할 수 있을 정도의 충분한 유연성을 확보해야 함. 기존 워크플로우를 ZTA로 전환 시, 부분적인 재설계가 필요할 수 있으며, 이는 기업에서 시큐어 시스템 엔지니어링 사례를 채택할 기회가 될 수 있음
제로트러스트 아키텍처 전환 단계
조직은 자신의 물리/가상 자산에 대한 상세한 지식을 바탕으로 수행되어야 하며, ZTA를 도입하긴 전에, 자산/주체/데이터플로우/워크플로우를 조사해야 함. 이후 위험 관리 프레임워크와 매핑하여 인벤토리 생성부터 유지보수 및 업데이트를 위한 정기적인 주기를 거쳐 수행함.
주체 식별
- 기업에서 제로트러스트를 운영하려면, 정책 엔진은 기업 주체에 대한 지식을 갖춰야 하며 주체는 사람과 NPE를 모두 포함. 개발자 및 시스템 관리자 등 특수 권한을 가진 사용자에게 속성/역할을 할당할 때는 추가적인 정밀 조사 필요.
기업 소유 자산 식별
- ZTA의 핵심 요구 사항중 디바이스 식별/관리, 모니터링 등을 수행하면서 기업은 기업 소유 인프라에서 새롭게 발견된 자산에 대해 빠르게 식별/구분/엑세스하는 능력을 갖춰야 함. 이는 단순히 DB를 관리한다는 것 외에 설정 관리 및 모니터링도 포함되며, 자산의 현 상태를 관찰하는 능력은 접근 요청을 평가하는 프로세스의 일부분임. 이 작업이 수행된 후 비즈니스 프로세스를 ZTA로 설계할 수 있으며 이는 기업의 변화에 확장/적응할 수 있게 설계되어야 함.
핵심 프로세스 식별 및 위험 평가
- 기업 경계를 클라우드에 옮기거나 클라이언트가 VPN을 통해 기업 네트워크를 사용하는 것이 아니라, 기업의 클라이언트가 클라우드 서비스를 직접 요청할 수 있음. 기업의 정책 집행 포인트는 클라이언트에게 리소스에 대한 접근을 허가하기 전에 클라이언트가 기업 정책을 따른다는 것을 보증. 또한 ZTA를 수립할 때 성능. 사용자 경험, 워크플로우 취약점 증가 가능성 사이의 균형을 고려해야 함
제로트러스트 아키텍처 후보에 대한 정책 수립
- 후보 서비스/워크플로우는 몇가지 요인으로 결정되며, 이는 프로세스의 중요성, 영향을 받는 주체, 워크플로우에 사용되는 리소스의 현재 상태임. NIST 위험 관리 프레임워크를 사용해, 위험을 기반으로 자산/워크플로우의 가치를 평가할 수 있음. 기업 관리자는 후보 비즈니스 프로세스가 사용하는 리소스에 대해 기준들을 결정하거나, 중요도에 따른 가중치를 결정해야함.
솔루션 후보 식별
- 고려요인을 통해 특정 워크플로우 및 현재 기업 생태계에 더 적합한 배치 모델을 선정
1. 클라이언트에 컴포넌트를 설치해야 하는가?
2. 비즈니스 프로세스 리소스가 모두 온프레미스인 경우에도 동작하는가?
3. 분석을 위해 로그 상호작용에 대한 방법을 제공하는가?
4. 다양한 애플리케이션, 서비스, 프로토콜을 지원하는가?
5. 주체의 행위에 변경이 필요한가?
최초 전개 및 모니터링
- 후보 워크플로우 및 ZTA 컴포넌트를 선택하면, 최초 전개를 시작할 수 있고, 기업 관리자는 선택된 컴포넌트를 사용하여, 수렴한 정책을 시행해야 함. 그 과정에서 시행착오를 대비하기 위해 모니터링 및 레포팅 과정을 수행할 수 있으며, 이를 통해 기업은 자산/리소스에 대한 접근 요청/행위/통신 패턴의 베이스라인을 인식 할 수 있음. 워크플로우에 대한 액티비티 패턴 베이스라인이 설정되면, 비정상 행위를 쉽게 식별할 수 있음. 이러한 운영 경험을 기반으로 접근정책을 수정할 수 있도록 준비해야 함.
제로트러스트 아키텍처 확대
- 위의 단계를 모두 수행하였다면, 기업은 정상적인 운영단계에 돌입하여 네트워크/자산을 지속적으로 모니터링하고, 트래픽을 로그에 기록함. 주체 및 리소스/프로세스의 이해 관계자는 운영 개선을 위한 피드백을 제공해야 함. 최초 전개와 마찬가지로 워크플로우 및 솔루션 후보를 식별하고, 초기 정책을 작성해야 함. 그러나, 워크플로우에 변화가 생긴다면, ZTA 운영에 대한 재평가를 수행하여, 전체 프로세스를 재검토하는 과정이 필요함.