정보 유출 사고는 지속적으로 발생하고 있습니다. 가장 큰 유출 사고라고 할 수 있는 야후는 최소 5억 개의 사용자 계정이 해커의 손에 넘어가 피해를 입었으며, 2016년 미국 대선 역시 정치인들이 이메일 폭로 스캔들로 얼룩졌습니다.
최근 2018년 11월에는 미국 최대 세일 시즌인 ‘블랙 프라이데이’를 이틀 앞두고 전자상거래 업체 아마존에서 고객 정보(이름과 이메일 주소 등)가 유출되는 사고가 발생했습니다. 이와 같은 기술적인 원인이나 해킹에 의한 유출도 많지만, 많은 기업의 경우 인가된 사용자에 의한 정보 유출 비중이 증가하고 있습니다.
이렇게 다양한 원인에 의한 정보 유출 공격이 기업들을 위협하고 있고 매년 사이버 보안에 더 많은 자원을 투자하고 있음에도 피해 규모가 줄어들지 않고 있는데, 기업은 어떻게 데이터를 보호할 수 있을까요? 이에 대한 대응 방안으로 ‘제로 트러스트 모델(Zero Trust Model)’이라는 개념이 솔루션에 도입되고 있습니다.
제로 트러스트 모델이란?
제로 트러스트 보안 모델은 기본적으로 기업 내•외부를 막론하고 적절한 인증 절차 없이는 그 누구도 신뢰해서는 안 되며, 시스템에 접속하고자 하는 모든 것에 접속 권한을 부여하기 전 신원 확인 과정을 거쳐야 한다는 것입니다.
제로 트러스트 모델이라는 용어는 2010년 분석 기관인 포레스트 리서치의 존 킨더버그가 만들었습니다. 네트워크 자산에 연결하려는 모든 사람과 장치를 신뢰할 수 없는 것으로 취급하는 보안 모델을 설명하기 위한 것으로 네트워크 자산에 대한 액세스 권한을 부여하거나 거부하는 근거로 네트워크 위치보다는 장치의 사용과 사용자 인증을 강조했습니다.
내부 네트워크를 사용하는 사용자와 트래픽을 암묵적으로 신뢰하는 한편 외부 사용자만 신뢰할 수 없는 것으로 간주한다는 오랜 관행에 문제가 있다는 것입니다. 또한, 위협 주체만 문제가 되는 것이 아니라 모바일 환경이 증가하고 애플리케이션과 서비스를 호스팅 하는데 클라우드 서비스를 사용하는 사례가 증가하면서 많은 기업이 네트워크 경계를 설정하고 시행하는 것이 더욱 어려워진 환경적인 요인도 있습니다.
제로 트러스트 모델은 매우 적극적인 보안 방식으로 모든 파일이 잠재적 위험 요소라는 전제하에 모든 데이터를 모니터링하며, 모든 데이터에 접근할 때 안전한 경로를 통하도록 하며, 데이터 액세스 권한은 꼭 필요한 경우에만 허락하는 방식입니다.
또한 시스템 설계 시 기존에 외부에서 내부가 아니라 내부에서 외부로 설계하며, 언제나 불신을 원칙으로 하고 신원을 확인하며 모든 트래픽을 검사, 로그 리뷰합니다.
제로 트러스트 개념
- 내부에서 외부로 설계: 보호가 필요한 자산•데이터 식별부터 필요
- 접속하기 위해 필요한 신원 및 권한 결정
- 모든 트래픽을 검사 및 로깅
기업에 적용을 어떻게 할 수 있는지 좀 더 이해하기 쉽게 이 분야의 개척자인 구글의 예를 살펴보도록 하겠습니다.
구글 BeyondCorp
BeyondCorp는 6년에 걸친 구글의 상시 확인 네트워크 구축 경험을 바탕으로 하는 엔터프라이즈 보안 모델로서, 제로 트러스트 보안 개념을 구현한 것입니다. 액세스 제어 기능을 네트워크 경계에서 개별 기기로 이전해 직원들이 전통적인 VPN을 사용하지 않고도 어느 위치에서나 안전하게 업무를 수행할 수 있도록 합니다.
기존의 IT 인프라 구조에서는 경계 보안 모델(Perimeter Security Model)이 사용되었습니다. 이는 중세 시대 성처럼 성벽으로 내•외부가 구분되어 성 밖에 있는 모든 것이 위험하게 간주되고 성 안으로 들어오면 그 안의 모든 리소스를 사용할 수 있는 개념입니다. 모든 임직원이 오직 회사 빌딩에서 근무하는 환경인 경우에 적당한 모델입니다.
그러나 클라우드 환경을 사용하거나, 모바일 휴대기기를 사용해 다양한 환경에서 내부 리소스를 사용하는 경우, 경계가 더 이상 물리적 위치에 한정되지 않습니다.
구글의 BeyondCorp는 권한 있는 엔터프라이즈 네트워크를 배제하는 새로운 모델로 옮겨 가고 있습니다. 액세스는 사용자의 네트워크 위치(엔터프라이즈 위치, 홈 네트워크, 호텔 또는 커피숍)에 관계없이 장치 및 사용자 자격 증명에만 의존합니다.
엔터프라이즈 리소스에 대한 모든 액세스는 장치 상태 및 사용자 자격 증명을 기반으로 완전하게 인증, 승인 및 암호화됩니다. 서로 다른 부분의 엔터프라이즈 리소스에 대한 세밀한 액세스를 구현해 결과적으로 모든 구글 직원은 권한이 부여된 네트워크에 기존 VPN 연결 없이 모든 네트워크에서 성공적으로 작업할 수 있습니다. 잠재적인 대기 시간의 차이를 제외하고는 엔터프라이즈 리소스에 대한 로컬 액세스와 원격 액세스 간의 사용자 경험이 동일합니다.
새로운 보안 네트워크 아키텍처의 방향은 다음과 같습니다.
- 모든 엔터프라이즈 시스템 접속 시 Authentication, Authorization, Encryption 적용
- 사내•외 구분 없이 어디서든 접속이 가능해야 함(Cloud Based)
- VPN 접속 프로그램과 같은 별도의 연결 절차 없이 Security Policy만으로도 네트워크 접근 통제 가능
- 모든 접속은 기기와 사용자에 대한 안전성(Secure)이 완벽하게 검증되었을 경우만 허용
다음은 BeyondCorp 주요 컴포넌트에 대해 알아보겠습니다.
기능적인 면을 고려해 볼 때 크게 세 부분으로 구분할 수 있습니다.
[BeyondCorp 컴포넌트 1: 기기 인증]
접근을 요청한 호스트가 정상적으로 구글에서 제공한 신뢰할 수 있는 기기임을 확인하는 것으로 인증된 기기(Managed Device)에서만 접속 가능합니다.
- 디바이스 인벤토리 데이터베이스(Device Inventory Database): 회사 네트워크에 접속하는 모든 디바이스 식별
- 디바이스 아이덴티티: 관리하는 모든 디바이스는 유일하게 식별. 디바이스 인증서 사용
호스트 내부에서는 사용자 인증서, Configuration 상태, OS Patch 정보를 에이전트를 통해 수집하고, 호스트 외부에서는 등록된 자산 정보, 디렉토리 서비스, 네트워크 정보, 취약점 스캔 정보를 수집해 Device Inventory에 저장합니다. 요청이 발생하면 현 사용자의 Trust Level을 결정하기 위한 근거 데이터를 Pipeline을 통해 전달합니다.
[BeyondCorp 컴포넌트 2: 사용자 인증]
접근하는 호스트 사용자가 정상적인 구글 임직원인지 확인 및 사용자의 소속 그룹과 업무(Job description) 확인합니다.
- 사용자 인증(User•Group Database): 구글 사내 시스템은 정상적인 인가된 사용자에게만 접속이 허용됩니다. 구글의 모든 User 및 Group 데이터베이스와 연동되어 있어, 사용자명, 소속 그룹, 업무 카테고리, 사용자 근무 위치 정보를 반영합니다. 임직원의 업무가 변경되거나, 퇴사 등 인사 변경 발생 즉시, 이 DB에 반영되며, 접근 제어 엔진이 이를 반영하여 시스템 접속 허용 여부를 결정하게 됩니다.
- Single Sign-On System: 외부에서도 접속 가능한 SSO Portal을 통해 이루어지며 인증 방식을 Two-factor로 사용자 계정과 OTP 혹은 USB 형태의 물리적 키가 사용됩니다.
[BeyondCorp 컴포넌트 3: 접근 제어 엔진(Access Control Engine)]
기기 정보, 사용자 정보, 취약점 정보 등을 상관 분석(Correlation)해 사용자 접근 허용 여부를 결정하는 엔진입니다.
접근 제어 엔진이 접속 허용•차단 의사 결정을 내릴 때 활용하는 데이터의 타입은 관측 데이터와 입력 데이터 두 가지로 분류되는데 두 가지 타입의 데이터는 하나의 공통된 포맷으로 변환된 후, Trust Evaluation(보안 등급 평가) 과정을 거쳐 접근 제어 엔진에 반영됩니다. 사용자에 관련된 수집된 데이터 각각의 요소에 대해 안정성과 적합성을 판단해, 시스템에 접속할 충분한 Trust Level을 부여 받지 못하면 접근 제어 엔진이 접속을 차단합니다.
- 관측 데이터(Observed Data): 계획적으로 생성된 데이터(취약점 스캔 결과, AD 정책, OS 버전 및 패치 여부, 설치된 SW 목록 등)
- 입력 데이터(Prescribed Data): IT 운영자가 수동으로 관리하는 데이터(기기의 소유자, 기기에 접속할 수 있는 사용자•그룹, DNS, DHCP 정보, 특정 VLAN 등)
이제 BeyondCorp에서 애플리케이션에 접속할 때의 Flow를 살펴보겠습니다.
① 사용자가 시스템 접속을 요청하면 Access Proxy로 redirect 되고 이때 디바이스에 설치된 사용자 인증서가 전달됩니다.
- Access Proxy: 클라이언트와 애플리케이션 사이 암호화
- Public DNS Entries: 구글의 모든 회사 애플리케이션은 외부에 노출되어 있고 CNAME(Access Proxy에서 해당 애플리케이션을 가리킴)으로 public DNS에 등록되어 있음.
② Access Proxy에서 사용자를 확인하기 위해 SSO 시스템으로 Redirect 시킵니다.
③ SSO 시스템에서 2-Factor 인증을 요구하며, 인증이 완료되면 다시 Access Proxy로 Redirect 됩니다.
④ Access Proxy가 사용자 인증서와 SSO 토큰을 검증해 사용자와 디바이스의 정상 여부를 확인합니다.
⑤ 접근 제어 엔진(Access Control Engine)이 모든 접속 요청에 대한 상세한 검증을 수행합니다.
- 해당 사용자가 대상 시스템에 접속 가능한 그룹인지 확인한다.
- 해당 사용자가 충분한 Trust Level을 소유하고 있는지 권한을 확인한다.
- 해당 디바이스가 관리되는 기기인지 확인한다.
- 디바이스가 충분한 Trust Level을 소유하는지 확인한다.
- 위 검증 사항 중 하나라도 실패하는 경우에는 접속이 거부된다.
위에서 살펴봤듯이 구글은 직무 역할과 분류에 대한 재정의와 재구성, 장치 추적을 위한 완전히 새로운 마스터 인벤토리 서비스 구축, 앱에 대한 가기성 향상, 사용자 인증 및 액세스 제어 정책 개편 등의 작업을 해야 했습니다.
구글의 BeyondCorp와 같이 제로 트러스트 모델을 적용하려면 어떻게 해야 할까요? 여러 전문가들이 정의한 제로 트러스트 모델을 도입하기 위한 5 단계를 알아보겠습니다.
제로 트러스트 보안 모델 도입을 위한 5 단계
● 1 단계: 제로 트러스트 정의
정책 측면에서 목표를 설정하고 그 목표를 달성하기 위한 로드맵을 만들어 보는 단계로 기술적인 것에 얽매이지 말고 ‘제로 트러스트’란 어떤 것인지를 정의하고 나서 제로 트러스트 및 관련 기술의 이행 방법에 대해 결정하면 됩니다.
● 2 단계: 사용자 경험 이해
제로 트러스트 모델을 기획하는 과정에서 사용자 경험에 미칠 영향을 생각해 봐야 합니다. 인증 및 확인 절차 없이는 그 어떤 사용자도 신뢰하지 않기 때문에 사용자의 시스템 및 데이터 사용 경험도 확연히 달라지기 때문입니다.
사용자 경험 관련 고려 사항
- 사용자 신원, 접근하려고 하는 앱, 접속 경로, 접근을 안전하게 관리할 방법
- 정책 관리 주체 (애플리케이션 소유자 – 분산 통제, IT 또는 보안팀 – 중앙집권 통제)
- 안전한 데이터 접근을 위해 요구되는 사항 충족 방법
● 3 단계: 적합한 아키텍처 선택
제로 트러스트 모델 이행에는 세 가지 방식이 있는데 각각의 장단점을 확인하고 목적에 맞는 방식을 선택합니다.
● 4 단계: 사용자 및 기기에 대한 까다롭고 정확한 인증 절차 도입
제로 트러스트가 다른 보안 패러다임과 구분되는 가장 큰 차이점은 보안 이행 메커니즘이 네트워크 주변부에 집중하는 것이 아니라 타깃이 되는 시스템과 애플리케이션 자체에 집중한다는 것입니다.
인증 절차 고려 사항
- 사용자 다중 인증(MFA, multifactor authentication)을 통한 패스워드 강화 및 추가적인 인증 절차를 통한 접근 권한 부여
- 인증받은 사용자가 자신의 기기를 등록해 확인받을 수 있는 시스템 필요
- 기기 인증에도 최소한의 보안 요구 사항을 설정하고 해당 기준 충족하는 기기만 네트워크에 접근할 수 있도록 해야 함. (탈옥한 상태의 기기는 아닌가? 기기 설정이 디스크 암호화, 바이러스 보호 및 최신 패치와 같은 회사 정책을 준수하고 있는가 등)
● 5 단계: 문제점에 대비
통합 인증 및 접근 제어 시스템을 구현하고 관리하고, 중요한 데이터에 대한 접근을 제공하는 모든 애플리케이션을 식별하는 것도 큰 과제입니다. 또한 사용자에게 부여된 모든 권한은 일시적이고 시간 제한적이며, 자동으로 말소될 수 있도록 관리할 수 있어야 합니다. 이렇듯 제로 트러스트 구현에 필요한 작업의 범위와 규모를 잘 산정하고 이에 대한 문제점에 대비할 수 있어야 합니다.
문제 발생 및 이에 대한 해결 예
- 제로 트러스트 모델 도입 기업 및 이행 방식: A사 – 제로 트러스트 프록시
- 문제 대상: 비 웹 애플리케이션(non- web application)
- 원인: MFA같은 인증 절차 미지원
- 해결 방안: 경량 클라이언트 구축 및 경량 클라이언트 측 애플리케이션 터널 구현
제로 트러스트 보안과 클라우드, 빅데이터
2019년 보안 트렌드 중 하나로 많은 보안 기업들이 제로 트러스트 기반의 보안 모델에 대해 고민하고 있습니다. 대규모 글로벌 보안 기업의 홈페이지를 방문해 보면, 제로 트러스트라는 용어를 많이 접할 수 있습니다.
이렇게 제로 트러스트 모델을 도입하면 엄청난 양의 실시간 데이터를 얻게 되며 이러한 데이터를 분석하다가는 IT 매니저가 로그 파일, 취약점 스캔 보고서, 경고 보고서 등의 홍수에서 살게 될지도 모릅니다.
최근 급부상하고 있는 IT 트렌드인 빅데이터 애널리틱스를 활용하면 리스크 종류, 리스크 심각성, 보안 취약점 보완 방법 등을 한눈에 파악할 수 있습니다. 또한, 데이터에 행동 애널리틱스를 적용하여 보안에 위협을 가할 수 있는 수상한 활동을 사전에 차단할 수 있게 됩니다.
네트워크 보안 제품 업체에서는 차세대 방화벽(NGFW)을 기반으로 Segmentation Gateway를 사용해 마이크로 세그먼테이션 방식으로 제로 트러스트 네트워크를 제안하고 구현하고 있습니다. 클라우드 보안 전문 업체를 인수해 클라우드 보안 분석, 지능형 위협 탐지, 지속적인 보안 및 컴플라이언스 모니터링을 제공하고 이를 통해 기업들이 주요 위협에 보다 빠르게 대응할 수 있도록 합니다.
이처럼 빠르게 변화하는 인프라 환경, 갈수록 교묘해지는 공격에 대해 기업 데이터와 시스템을 안전하게 보호할 수 있도록 제로 트러스트 보안에 대해 생각해 보는 기회가 되면 좋겠습니다.
글 l LG CNS 보안컨설팅팀
● 참고 문서
- https://ai.google/research/pubs/pub43231 (BeyondCorp: A New Approach to Enterprise Security)
- https://www.usenix.org/conference/lisa13/enterprise-architecture-beyond-perimeter
