이병호 AWS코리아 솔루션즈 아키텍트

이병호 AWS코리아 솔루션즈 아키텍트
이병호 AWS코리아 솔루션즈 아키텍트

[컴퓨터월드] 사이버보안을 현대화하기 위한 제로트러스트 도입 전략이 드디어 국내에서도 구체화되고 있다. 과학기술정보통신부는 지난 7월 9일 K-제로트러스트 가이드라인 1.0을 발행했고, 국가정보원에서도 2026년까지 국가・공공기관 대상 제로트러스트 도입을 추진 중이라고 발표했다. 이번 기고문에서는 2020년 8월 미국 국립표준기술연구소(NIST)에서 발행한 ‘제로트러스트 아키텍처(ZeroTrust Architecture, SP 800-207)’를 중심으로 제로트러스트를 소개하고, 클라우드 환경에서 구현가능한 유즈케이스(Use-case)를 살펴보고자 한다.


캐슬모델과 제로트러스트

제로트러스트(ZeroTrust)는 전통적인 네트워크 경계 안팎으로 위협이 있다고 간주하고, 신뢰하지 않고 항상 검증하는 보안모델이다. ‘Never trust, Always verify’로 대표되는 제로트러스트는 트러스트가 디폴트로 ‘제로(Zero)’다. 모든 것은 기본적으로 차단돼 있고 사용자가 리소스에 접근하기 위해서는 인증, 디바이스 검사 등을 통해 정책허용지점을 반드시 통과해야 한다. 이후 리소스에 접근하는 최소권한이 부여되는데 이 권한은 일시적이다. 이 모든 과정은 지속적으로 검증돼야 하고, 모니터링돼야 한다.

위에서 언급한 제로트러스트 주요특징을 살펴보면, 자칫 기존 보안모델과 차이점이 없다고 오해할 수 있다. 고성능 보안솔루션을 더 많이 구매하고, 보안정책을 강화하며, 보안모니터링을 철저하게 하면 제로트러스트가 아닌가 생각할 수 있다. 만약 이렇게 생각이 들었다면 아래 전통적인 보안을 비유한 ‘성과 해자(Castle and Moat)’ 모델을 살펴보자.

성과 해자(Castle and Moat) 모델
성과 해자(Castle and Moat) 모델

지난 사이버보안 접근방식은 네트워크 경계기반 보호(Perimeter-based security) 중심이었다. 네트워크 경계는 ‘성(Castle)’을 중심으로 설정된다. 성 바깥은 인터넷과 같이 신뢰할 수 없는 영역(Untrusted zone)으로 전 세계 모든 사람들이 위치하는 영역이다. 그리고 성 내부는 인트라넷과 같이 신뢰할 수 있는 영역(Trusted zone)으로 왕, 신하, 군인 등 허가받은 사람들만 위치할 수 있다. 방화벽은 네트워크 경계를 에워싸고 보호하는 ‘해자(Moat)’ 역할을 한다.

이 접근 방식의 본질적인 문제는 방화벽을 통과한 신뢰영역 내에 위치한 모든 내부 장치와 사용자를 ‘사실상 신뢰’할 수 있다고 분류하는 데 있다. 그러나 장치 및 사용자는 언제든지 해킹될 수 있으며, 일단 해킹되면 그들에게 부여된 신뢰권한을 사용하여 공격을 시작할 수 있다. 나아가 공격자는 신뢰영역 내에서 횡적이동(Lateral Movement)을 수행하여 획득한 권한으로 다른 장치를 감염시켜 공격자로 만들 수도 있다.

다음과 같은 간단한 비유를 들 수 있다. 성 안에 위치한 군인 한 명이 갑자기 누군가에게 물려서 좀비가 되었다고 생각해보자. 이제 그는 근처의 다른 사람을 공격하고 그들은 좀비가 돼 새로운 공격자가 된다. 이렇게 계속 공격이 전파되면서 성 내 전체 업무가 마비될 것이다!


제로트러스트 보안모델

제로트러스트 개념에 관한 논의는 오래전부터 있었지만, 본격적으로 언급하게 된 시점은 2010년 포레스터 리서치(Forrester Research)의 존 킨더버그(John Kindervag)가 두 차례 발표한 보고서 이후부터였다.

존 킨더버그는 전통적인 계층형 네트워크는 구식이고 안전하지 않다고 했고, 어느 트래픽도 믿을 수 없고 검사돼야 한다고 했다. 따라서 제로트러스트를 패킷이 들어올 때(Outside In) 뿐만이 아니라 나갈 때(Inside Out)도 믿어서는 안되며, 안팎으로 철저하게 검증해야 하는 보안모델로 설명했다.

전통적인 경계방어와 제로트러스트 모델 비교. 출처: Zero Trust Cybersecurity: ‘Never Trust, Always Verify’, NIST, Oct. 2020.
전통적인 경계방어와 제로트러스트 모델 비교. 출처: Zero Trust Cybersecurity: ‘Never Trust, Always Verify’, NIST, Oct. 2020.

제로트러스트 보안모델의 아이디어가 된 공항승객 심사모델을 예로 들어보겠다. 모든 승객은 공항 보안검색대를 통과해 터미널구역으로 이동한다. 터미널구역은 암묵적 신뢰영역으로 승객, 공항 직원, 항공기 승무원 등은 터미널구역을 돌아다니며, 구역 내에서 개인은 신뢰할 수 있는 것으로 간주한다.

이후 탑승게이트, 비행기 및 조종석(Cockpit)까지 접근하기 위해서는 지속적인 심사와 더 높은 권한을 필요로 한다. 예를 들면, 공항직원은 탑승게이트까지 입장할 수 있지만, 비행기를 탈 수는 없다. 그러나 승객 또는 승무원은 탑승게이트 및 비행기까지 입장할 수 있고, 조종석 접근은 제한된다. 파일럿은 출입증 또는 별도 인증수단을 통해 조종석까지 접근할 수 있다. 이때 보안검색대, 탑승게이트, 비행기 및 조종석은 각각 보안 게이트웨이 역할을 하며, 보안정책이 심사되고 시행되는 지점이 된다.

2020년 NIST에서 발행한 제로트러스트 아키텍처 (NIST SP 800-207)는 산업・기관 별로 해석이 다르고 개념적인 모호함이 있던 제로트러스트를 표준화했다. NIST SP 800-207에서 정의한 제로트러스트는 아래와 같다.

“제로트러스트는 네트워크가 침해됐다고 간주되는 상황에서, 정보 시스템 및 서비스 접근 시 정확하고 최소 권한을 가진 요청당 액세스 결정을 내리는 데 따르는 불확실성을 최소화하도록 설계된 개념과 아이디어의 집합이다. 제로트러스트 아키텍처는 제로트러스트 개념을 활용하고 구성 요소 관계, 워크플로우 계획 및 액세스 정책을 포괄하는 기업의 사이버 보안 계획이다. 따라서 제로트러스트 엔터프라이즈는 제로트러스트 아키텍처 계획의 산물로서 기업에 적용되는 물리적 및 가상 네트워크 인프라 및 운영 정책이다”

요약하면 제로트러스트는 검증된 주체가 검증된 대상에 접근할 때 최소권한을 갖도록 하는 보안모델이다. 제로트러스트 아키텍처는 제로트러스트를 기업에서 구현하기 위한 아키텍처, 방법론, 정책 등 일체이고, 제로트러스트 엔터프라이즈는 제로트러스트 아키텍처를 기반으로 구현한 실제 환경이다.

경계기반 보안과 제로트러스트 비교
경계기반 보안과 제로트러스트 비교

따라서 제로트러스트는 기존 네트워크 중심 경계기반 보안모델을 강화하는 방식이 아니라, 새로운 데이터 중심 보안모델이다. 제로트러스트는 현대화된 사이버보안 접근방법으로서 IaaS(Infrastructure as a Service), PaaS(Platform as a Service), SaaS(Software as a Service)를 포함한 안전한 클라우드 도입을 가속화하며, 분산되어 있는 사이버보안 데이터를 중앙집중화하며, 복잡한 시스템 액세스 절차를 간소화한다. 이를 통해 기업은 사이버보안 현대화 전략에 맞게 태스크 우선순위를 정하고 기술, 인력 및 자본을 투자할 수 있다.


제로트러스트 아키텍처

제로트러스트 액세스 개념도
제로트러스트 액세스 개념도

위 제로트러스트 액세스 개념도는 주체(Subject)가 리소스에 제로트러스트 모델을 사용하여 액세스하는 과정을 모식화했다. 주체는 일반적인 모바일, PC, 프린터 또는 IoT 단말 사용자가 될 수 있다. 그리고 기업 리소스는 기업 내 위치한 데이터베이스, 파일시스템, 애플리케이션 등이 될 수 있다. 주체는 리소스에 액세스할 때 정책시행지점(PEP : Policy Enforcement Point)을 거치며, 정책결정지점(PDP : Policy Decision Point)에 의해 적용할 정책이 결정된다. 다시 말하면 PDP는 관리자가 보안정책을 정의하는 지점이고, PEP는 주체에게 리소스에 접근할 수 있는 정책이 부여되는 지점이다.

제로트러스트 아키텍처 Logical Components. 출처: Zero Trust Architecture Logical Components, NIST SP 800-207.
제로트러스트 아키텍처 Logical Components. 출처: Zero Trust Architecture Logical Components, NIST SP 800-207.

이를 상세화하면 다음과 같다. 주체와 PEP 사이는 모두 비신뢰 영역(Untrusted Zone)으로 간주되고, PEP와 기업 리소스는 암묵적 신뢰(Implicit Trusted Zone) 영역으로 간주된다. 통과 전까지 주체의 요청은 신뢰되지 않지만, PEP 통과 후 세분화된 권한으로 리소스에 액세스할 수 있다. 따라서 PEP는 최종 리소스의 마지막 게이트웨이가 되어 주체 진위여부 및 요청 유효성 판단을 한다.

정책 관리자(PA, Policy Administrator)는 주체와 리소스 간 통신 경로를 설정 및/또는 종료하는 역할을 한다. PA는 PEP에 연결되어 정책 엔진(PE, Policy Engine) 결정에 따라 모든 액세스 요청을 인증하고 동적으로 권한을 부여한다. 권한 부여는 컨텍스트 속성, 신뢰 수준 및 보안 전략을 기반으로 한다. 세션이 승인되고 요청이 인증되면 PA는 PEP에 신호를 보내 세션을 시작할 수 있도록 한다. 그렇지 않으면 세션이 거부되고 PA는 PEP에 연결을 종료하도록 지시한다.

정책 엔진은 주어진 주제와 리소스에 대한 액세스 권한을 부여하는 최종 결정을 담당한다. PE는 PA와 연결돼 정책 승인 시 신뢰알고리즘을 기반으로 리소스에 대한 액세스 권한을 승인, 거부 또는 취소한다. PE는 주체, 주제 속성 및 역할, 과거 주체 행동 패턴, 위협 인텔리전스 소스 및 기타 메타데이터 소스 등을 결합해 액세스 결정(액세스 허용, 거부 또는 취소)을 내리고 평가한다. PE가 액세스 결정을 내리고 기록하는 동안, PA는 이 결정을 실행한다.

NIST 문서에 따르면, 제로트러스트는 데이터 및 서비스에 대한 무단 액세스를 방지하고 액세스 제어를 최대한 세분화하는 것을 목표로 한다. 즉, 인증되고 권한을 가진 주체(사용자, 애플리케이션 및 장치 조합)는 다른 모든 주체(공격자)를 제외하고 데이터에 액세스할 수 있다. 불확실성을 줄이기 위해서는 가용성을 유지하고 인증 메커니즘의 일시적인 지연을 최소화하면서 인증, 권한 부여 및 암묵적 신뢰 영역(Implicit trust zone)을 축소해야 한다. 그리고 액세스 규칙은 요청에서 작업을 수행하는 데 필요한 최소한의 권한을 적용할 수 있도록 최대한 세분화된다. 즉, 제로트러스트의 본질은 PDP/PEP를 리소스에 최대한 가깝게 배치해 암묵적 신뢰 영역을 ‘제로’로 만드는 것이다.


제로트러스트 아키텍처 구현방안

제로트러스트 아키텍처 주요 접근방식
제로트러스트 아키텍처 주요 접근방식

제로트러스트 아키텍처를 구현하기 위해서 대표적으로 ID 거버넌스향상, 마이크로 세그멘테이션(Micro-segmentation), 소프트웨어정의 경계(SDP, Software-Defined Perimeter) 기법을 사용할 수 있다. 이러한 접근 방식은 각 기업에서 사용하는 유즈케이스에 따라 달라지게 되며, 위 방법 중 하나를 사용하거나 혹은 둘 이상을 조합해 사용할 수 있다.

주의해야 할 부분은 전통적인 보안모델에 제로트러스트 관련 ‘솔루션’을 추가하는 게 아니라, 제로트러스트적인 접근방법으로 ‘아키텍처’를 개선해야 한다는 점이다. 기존 사용자 인증, 네트워크 구성, 디바이스 관리정책을 분석해 제로트러스트 아키텍처 접근방법에 맞게 마이그레이션 해야 하며, 이를 통해 사용자 중심적이고, 데이터 기반이며, 최소 신뢰 영역을 갖는 제로트러스트 엔터프라이즈를 구축할 수 있다.


최적화(Optimal)를 향한 제로트러스트 여정

제로트러스트 여정을 시작하기 위해서 경계형 모델에서 제로트러스트 모델로 보안 시각을 바꾸는 근본적인 변화가 필요하다. BYOD 적용 단말이 늘어나고, 컨테이너 기반 환경으로 현대화되며, 다양한 SaaS 도입이 점차 확대된다면 각 조직은 기존 모델로는 유즈케이스에 맞는 아키텍처를 구현하기가 어렵게 된다.

또한 과거에는 SQL 인젝션(Injection), DDoS, 크로스사이트스크립트(XSS) 등 기업 네트워크 바깥에서 시스템을 무력화하려는 시도가 많았다. 그러나 최근엔 공급망 해킹과 같이 백도어를 설치해 경계를 무력화하고, 횡적 이동(Lateral Movement) 으로 내부에서 은밀하게 공격을 수행하는 형태가 증가했다. 이 경우 경계보안을 아무리 강화한다고 하더라도 대응이 쉽지 않다. 따라서 네트워크 위치에 기반한 ‘암묵적 신뢰’ 영역을 제로로 만드는 제로트러스트로 보안패러다임을 바꾸고, 이에 맞는 정보보안 거버넌스를 수립해야 한다.

제로 트러스트 성숙도 모델. 출처: Zero Trust Maturity Model, CISA.
제로 트러스트 성숙도 모델. 출처: Zero Trust Maturity Model, CISA.

그렇다면 제로트러스트 여정의 이상적인 목표는 어떻게 될까? 이를 위해 2023년 4월 CISA에서 개정・발표한 제로트러스트 성숙도 모델(Zero Trust Maturity Model v2)을 참고할 수 있다. 전통(Traditional), 초기(Initial), 고급(Advanced), 최적(Optimal)까지 이어지는 제로트러스트 여정 4단계는 조직의 제로트러스트 아키텍처 수준을 점검하고, 위험요인을 완화하기 위한 전략적 방향성을 제시한다. 조직은 각 단계에서 아이덴티티, 디바이스, 네트워크, 워크로드, 데이터 별 원칙을 중심으로 제로트러스트 구현수준을 평가, 계획, 유지 및 개선할 수 있다.
 

●전통(Traditional) : 대체로 수동으로 구성된 전통적 아키텍처로 수동 운영 절차, 사일로(SILO) 화된 정책집행, 로그 및 원격 모니터링 간 제한적 상관관계가 특징이다.

●초기(Initial) : 수명주기별 속성이 할당되며, 정책결정 및 적용, 외부시스템 통합으로 초기 자동화가 시작된다.

●고급(Advanced) : 자동화, 중앙집중식 관리, 정책집행 개선, 외부시스템 의존도 증가, 사고대응 및 완화절차 강화, 전사적 인식 구축이 포함된다.

●최적(Optimal) : 대부분 보안 인프라 요소에서 자동화 시스템을 사용하며 관련 보안 표준 연계, 향상된 중앙 집중식 관리, 더 나은 정책 집행, 향상된 사고 대응 및 이벤트 완화가 이루어진다.
 

제로트러스트 여정 시작점은 기업마다 다를 수 있다. 이미 제로트러스트와 관련되었거나 혹은 유사한 기술을 도입한 경우, 제로트러스트 전환 및 고도화는 쉬울 수 있다. 그러나 어떤 기업은 망분리, 레거시 솔루션, 보안정책 또는 규제로 인해 진입장벽이 있을 수 있다.

따라서 제로트러스트 도입은 하향식(Top-down) 접근이 효과적이며, 한번에 최적(Optimal) 단계를 달성하려 하기보다 초기(Initial) 단계를 시작으로 점진적으로 성숙도를 높이는 방법이 바람직하다. 마지막으로 제로트러스트는 만능이 아니기 때문에 기존 정보보안 프레임워크와 연계해 기밀성, 무결성, 가용성을 달성하기 위한 전사적 노력을 지속해야 한다.

 


제로트러스트 7가지 기본원칙
 

제로트러스트 아키텍처(ZTA, ZeroTrust Architecture)는 다음과 같은 제로트러스트(ZT) 기본원칙을 준수해 설계 및 배포된다.

1. 모든 데이터 소스 및 컴퓨팅 서비스는 리소스로 간주 : 이제 엔드포인트 사용자 단말 또는 서버만 리소스로 간주하던 시대는 지났다. 오늘날 네트워크는 개인 단말기, IoT 장치 및 다른 리소스에 특정 권한으로 실행할 수 있는 FaaS(Function-as-a-Service)와 같이 보다 다양한 장치의 동적 배열로 구성된다.

2. 모든 통신은 네트워크 위치에 관계없이 안전하게 보호 : 제로트러스트 환경에서는 제로트러스트 네트워크 액세스(ZTNA) 개념이 구현된다. ZTNA 환경에서는 대신 액세스 정책이 기본적으로 거부된다. ZTNA에서는 사용자가 리소스에 접근 시 해당 리소스에 명시적 액세스 권한을 부여해야 한다. 이는 사용자가 VPN에 인증한 후 네트워크 내 또는 네트워크를 경유해 자유롭게 액세스할 수 있는 기존 원격 액세스 패러다임과 대조된다.

3. 개별 엔터프라이즈 리소스에 대한 액세스 권한은 세션별로 부여 : 디지털 ID에 대한 신뢰는 단일 세션을 넘어서서는 안된다. 분산 컴퓨팅 환경, 클라우드 네이티브 아키텍처, 그리고 끊임없이 위협에 노출되는 원격근무 환경 특성 때문에 신뢰 범위는 단일 세션을 넘어서서는 안된다. 즉, 이전 세션에서 기기 또는 ID를 신뢰했다고 해서 후속 세션에서도 해당 기기 또는 ID를 신뢰한다는 의미는 아니며, 각 세션마다 동일한 수준의 엄격한 검증을 거쳐야 한다.

4. 리소스에 대한 액세스는 클라이언트 ID, 애플리케이션/서비스, 요청 자산의 관찰 가능한 상태를 비롯한 동적 정책에 따라 결정되며 다른 행동 및 환경 속성을 포함할 수 있음 : 기업은 사용자 정보 및 위치, 장치 및 보안상태, 실시간 위험 및 애플리케이션 컨텍스트 등을 포함해 액세스 및 권한 부여 결정을 내릴 수 있다. 클라이언트 ID에는 사용자 계정 및 자동화된 작업을 인증하기 위해 기업에서 해당 계정 또는 아티팩트에 할당한 모든 관련 속성이 포함될 수 있다. 전통적으로 역할기반 접근제어(RBAC, Role-Based Access Control)를 사용해 권한부여를 수행했지만, 동적인 보안상태 변화에 따른 대응에는 한계가 있었다. 제로트러스트 모델에서는 속성기반 접근제어(ABAC, Attribute-Based Access Control)를 사용해, 보안 주체, 리소스 및 액세스 요청 환경과 연결된 속성에 따라 액세스를 정의할 수 있다.

5. 기업은 모든 소유 및 관련 리소스의 무결성 및 보안 상태를 모니터링하고 측정 : 제로트러스트 모델에서는 어떤 장치나 리소스도 근본적으로 신뢰하지 않는다. ZTA를 구현하는 애플리케이션, 데이터베이스, 서버 등 리소스에 대한 접근 요청을 평가할 때 리소스 보안 상태를 평가해야 한다. 지속적인 진단 및 완화(CDM, Continuous Diagnostics and Mitigation) 또는 유사한 시스템을 구축해 장치 및 애플리케이션 상태를 모니터링하고 필요에 따라 패치/수정을 적용해야 한다. 알려진 취약점이 있는지, 최신 패치가 적용돼 있는지, 기업에서 관리하지 않는 자산이 있는지 모니터링해 무결성 및 보안 상태를 검증해야 한다.

6. 모든 리소스 인증 및 권한 부여는 동적이며 액세스가 허용되기 전에 엄격하게 적용 : 액세스 및 신뢰 부여는 역동적이고 지속적으로 진행된다. ZTA를 구현하는 기업은 자격 증명 및 액세스 관리(ICAM, Identity, Credential and Access Management), 다단계 인증(MFA, Multi-Factor Authentication) 및 관리 시스템을 갖춰야 한다. 사용자 트랜잭션 전반에 걸쳐 지속적으로 모니터링하고, 리소스 권한을 가진 계정이라 하더라도 추가적인 신뢰 결정을 내리기 전에 재인증 및 재승인이 이뤄질 수 있다.

7. 기업은 자산, 네트워크 인프라 및 통신의 현재 상태에 대해 최대한 많은 정보를 수집해 보안 태세를 개선하는 데 사용 : 기술 환경은 무수한 위협에 노출돼 있으므로 환경 내에서 발생하는 상황을 파악할 수 있도록 지속적인 모니터링 기능을 유지해야 한다. 아울러 최대한 많은 데이터를 수집하여 액세스 요청에 대한 컨텍스트를 분석, 활용할 수 있다.

 


제로트러스트 유즈케이스
 

모든 엔터프라이즈 환경은 제로트러스트 원칙을 염두에 두고, 유즈케이스에 맞게 설계해야 한다. 먼저, 기업은 원격근무, 외부 사용자 접속, 클라우드 연계 등 다양한 환경에서 사용하므로, 비즈니스 요구사항과 제로트러스트 원칙에 기반해 워크로드 포트폴리오를 평가해야 한다. 이후 비즈니스 워크플로에 적합한 제로트러스트 아키텍처를 만들어야 하며, 트래픽 흐름, 기존 보안모델과 종속성 맵핑을 고려해야 한다. 이때 경계기반 보호 의존성을 줄여야 하지만, 보안목표 및 정책에 따라 기존 솔루션을 같이 활용할 수도 있다. 망분리, 방화벽, 인증정책은 제로트러스트 원칙에 맞게 테일러링(Tailoring)하고, 네트워크 기능과 ID 기능을 결합해 신뢰성 있는 주체만 리소스에 액세스할 수 있는 환경을 구현할 수 있다.

보안은 AWS의 최우선 과제이기 때문에, AWS는 AWS Well-architected framework를 기반으로 성능효율성, 안정성, 운영우수성, 보안성, 비용최적화, 지속가능성을 준수하면서 제로트러스트를 구현하기 위한 빌딩블록을 제공한다. 아래는 AWS 클라우드를 사용해 소프트웨어 간 통신, 임직원 원격근무 및 IoT 서비스를 제로트러스트 원칙에 맞게 구현한 유즈케이스이다.

AWS 기반 제로트러스트 M2M 통신환경
AWS 기반 제로트러스트 M2M 통신환경

●M2M(Machine-to-machine) 통신환경 : M2M 환경은 서버 간 혹은 소프트웨어 컴포넌트 간 통신 환경으로, 제로트러스트 구현 시 두 구성요소 간에는 불필요한 경로를 제거하고, 독립적인 경로를 생성할 수 있다. 그리고 최소권한 원칙을 적용해, 이 두 구성요소가 통신할 필요가 없는 경우에는 동일한 네트워크 세그먼트 내에 있더라도 통신할 수 없어야 한다.

위 유즈케이스는 개인화 추천 서비스에서 특정 고객 주문이력에 접근하는 환경이다. 추천 서비스가 동작하는 다수 EC2 인스턴스는 주문이력 서비스 REST API를 호출하며, 제로트러스트 환경에서는 인터넷에서 직접 액세스 할 수 없도록 AWS PrivateLink를 구성할 수 있다. 리소스 중심 동적 마이크로 경계(Micro-perimeter)를 생성하기 위해 Security Group을 사용하고, Amazon API Gateway를 통한 요청 서명으로 자동화된 서비스를 연결할 수 있다. 추가적으로 서비스 연결성을 단순화하기 위해 Amazon VPC Lattice를 사용할 수 있다.

AWS 기반 제로트러스트 임직원 원격접속환경
AWS 기반 제로트러스트 임직원 원격접속환경

●임직원 원격접속환경 : 전통적 보안모델에서는 애플리케이션 액세스 시 사용자가 어느 네트워크에 위치하는지가 중요했다. 그러나 원격근무, 모바일 및 협업환경 확대로 지금은 어디서든 보안을 유지하면서 비즈니스 애플리케이션에 액세스할 수 있어야 한다. 애플리케이션에 대한 세분화된 권한 부여 및 권한 관리를 위해 서울 리전을 포함해 일반적으로 사용할 수 있는 서비스인 Amazon Verified Permissions는 애플리케이션 로직에서 권한을 분리하고, 중앙 집중식 정책 저장소, 재사용 가능한 정책 템플릿 및 정책 테스트를 통해 더 안전한 애플리케이션을 더 빠르게 구축한다.

사용자와 그룹을 관리하는 기존 ID 공급자를 사용하여 애플리케이션 권한을 관리하고 애플리케이션에서 액세스를 제어할 수 있다. Amazon WorkSpaces Family를 사용하면 모든 위치에서 다양한 작업자 유형에 적합한 가상 업무 공간을 위한 완전관리형 가상 데스크톱을 구현할 수 있다. Amazon AppStream 2.0를 사용하면 사용자가 어디서나 데스크톱 애플리케이션에 즉시 액세스할 수 있도록 하는 완전관리형 애플리케이션 스트리밍 서비스를 구현할 수 있다.

AWS 기반 제로트러스트 IoT 솔루션 환경
AWS 기반 제로트러스트 IoT 솔루션 환경

●IoT 솔루션 환경 : IoT인프라를 보호하기 위해 전통적인 경계보안에서는 IT 네트워크와 OT 네트워크를 분리하는 경우가 많았다. 그리고 OT망은 구형 디바이스 중심의 폐쇄적인 네트워크를 구축하여 네트워크 세분화에 크게 의존했다.

그러나 제로트러스트 환경에서는 IT, OT, IoT 및 IIoT를 포함하는 확장된 네트워크를 사용하고, 강력한 사용자 인증, 디바이스 검사 및 권한 부여를 통해 엔드투엔드 보안을 구현해야 한다.

AWS에서는 제로트러스트 기반 IoT 솔루션 구축 시 다계층 보안접근으로 구현할 수 있다. AWS IoT Core, AWS IoT Device Defender, AWS IoT Device Management 및 Amazon SNS(Amazon Simple Notification Service)를 사용하면 고유한 자격 증명, 최소 권한 제어, 디바이스 상태 및 이상징후 탐지를 포함한 아키텍처를 구축하여 유즈케이스에 집중할 수 있다. 보안은 AWS의 최우선 과제이며, 이를 통해 비즈니스 가치를 창출하는 동시에 조직의 보안 수준을 개선할 수 있다.

 


참조
1. Zero Trust Architecture, SP 800-207, NIST, 2020. 8
2. A Zero Trust Architecture Model 3 for Access Control in Cloud-Native 4 Applications in Multi-Location 5 Environments, SP 800-207A, Initial Public draft, 2023. 4
3. ero Trust Maturity Model, CISA, 2023. 4
4. 한국제로트러스트포럼, 제로트러스트가이드라인 1.0, 2023. 7
5. 제로트러스트 보안동향, 박춘식 교수, 주간기술동향 2098호, 2023. 7
6. Build Security Into Your Network’s DNA: The Zero Trust Network Architecture, John Kindervag, 2010. 11
7.https://medium.com/devopsiraptor/trust-is-a-vulnerability-the-zero-trust-security-model-8c3bbdcd76bf
8.https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know
9.https://aws.amazon.com/security/zero-trust/
10.https://aws.amazon.com/ko/blogs/compute/understanding-vpc-links-in-amazon-api-gateway-private-integrations/
11.https://aws.amazon.com/ko/blogs/networking-and-content-delivery/integrating-aws-verified-access-with-device-trust-providers/
12.https://aws.amazon.com/ko/blogs/iot/how-to-implement-zero-trust-iot-solutions-with-aws-iot-3/
13.https://www.nist.gov/blogs/taking-measure/zero-trust-cybersecurity-never-trust-always-verify

저작권자 © 컴퓨터월드 무단전재 및 재배포 금지