구글의 BeyondCorp 1부 – 보안 네트워크의 새로운 패러다임

대부분의 기업은 보안 아키텍쳐를 설계할 때 전형적인 Perimeter Model 을 적용하고 있다.
Perimeter Security Model은 외곽 경계, 즉 방화벽, IDS, IPS 등등의 보안 제품이나 서비스를
성벽을 쌓듯이 겹겹이 설치하여 자산을 보호하는 방식이다.

cap-2016-10-31-11-14-23-729

그러나, 이러한 Perimeter 방식은 몇가지 문제점을 안고 있다.
첫번째, 공격자의 방식이 진화하면서 어플라이언스 장비의 방어 효용성이 낮아졌으며,
둘째, 여러 장비가 있더라도 취약점은 항상 존재한다는 점이다.

따라서 공격자가 Perimeter 모델을 공격/또는 우회하여 내부로 진입할 수만 있다면
그 이후부터는 정상 유저와 공격자의 구분이 어려워 관리자 입장에서 탐지와 조치가  매우 어렵다.

또한 모빌리티 업무 환경이 확산되면서 “언제 어디서든 편하게 접속 가능하면서도”
“안전한” 기업 네트워크 아키텍쳐의 필요성이 대두되었다.

이에 구글은 ’13년도 USENIX 컨퍼런스를 통해 기존 Perimeter 모델의 한계를 극복하면서도
사용자 Usability를 동시에 만족시킬 수 있는 새로운 보안 아키텍쳐 BeyondCorp모델을 발표하게 된다.

이번 포스팅에서는 구글이 새로운 보안 네트워크 아키텍쳐를 어떻게 설계하고
실제 환경에 적용했는지에 대해 자세하게 다루어 보고자 한다.


[ Usenix 발표 영상 – Enterprise Architecture Beyond the Perimeter ]

Google BeyondCorp 개요

앞서 언급한 것과 같이 기존 Perimeter 모델의 전형성을 탈피하고 보안성을 높이기 위해
구글은 BeyondCorp 프로젝트를 시작하였다.

이 프로젝트에서 추구하는 새로운 보안 네트워크 아키텍쳐의 방향은 다음과 같이 정리할 수 있다.

  1. 모든 엔터프라이즈 시스템  접속 시 Authentication, Authorization, Encryption 적용
  2. 사내/외 구분없이 어디서든 접속이 가능해야 함 (Cloud Based)
  3. VPN 접속 프로그램과 같은 별도의 연결절차 없이 Security Policy 만으로도 네트워크 접근 통제 가능
  4. 모든 접속은 기기와 사용자에 대한 안전성(Secure)이 완벽하게 검증되었을 경우만 허용

cap-2016-11-03-11-04-01-618[ BeyondCorp Architecture Vision ]

사실 기존의 Perimeter 모델의 잔재(?)인 방화벽, VPN 등 여러 네트워크 장비를
모두 걷어내는 것 자체만으로도 굉장히 큰 도전으로 느껴지기 마련이다.
그럼에도 불구하고 구글이 이를 완벽하게 적용했다니 기술력도 기술이지만
이러한 프로젝트가 가능했던 기업 문화나 분위기도 참 대단하다는 생각이든다.

 

BeyondCorp의 구성

BeyondCorp 아키텍쳐를 구성하는 컴포넌트는 여러가지가 있으나
기능적인 면을 고려해볼 때 크게 세 부분으로 나눌 수 있다.

cap-2016-11-02-17-26-22-382

① 기기 인증 (Device Inventory)
– 접근을 요청한 호스트가 정상적으로 구글에서 제공한 신뢰할수 있는 기기임을 확인② 사용자 인증 (User/Group Database)
– 접근하는 호스트 사용자가 정상적인 구글 임직원인지 여부 확인
– 사용자의 소속 그룹과 업무 (Job Description) 확인

③ 접근 제어 엔진 (Access Control Engine)
– 기기정보, 사용자 정보, 취약점 정보등을 상관분석 (Correlation) 하여
사용자 접근 허용 여부를 결정하는 엔진

위 그림과 같이 BeyondCorp 모델은 방화벽이나 VPN과 같은 전형적인 보안 장비 없이
기기,사용자 인증을 비롯한 다양한 요소를 분석한 결과 만으로 접근 제어를 하고 있다.

기존 Perimeter 모델에서의 접속 환경을 한번 가정해보자.
일단 사내에서 어떤 시스템에 접속 하기 위해서는 방화벽 등록 절차를 거쳐야 할 것이다.
그리고 이 사용자가 사외에서 접속할때는 VDI 혹은 VPN을 사용해야만 사내 시스템에
접근이 가능하며, 단순히 사업장 이동이나 해외 출장 등 상황에서 역시
별도의 예외 혹은 네트워크 등록 프로세스가 필요하다.

그러나 BeyondCorp 모델에서는 모든 시스템이 Public DNS에 등록되어 있으며,
언제 어디서든 별도의 등록 절차 없이 곧바로 업무를 진행할 수 있는 장점이 있다.
또한 여러 장비에 사용자 IP를 등록해야 하는 번거로운 프로세스가 없다는 것도
좋은 점 중의 하나이다.

각각의 컴포넌트의 구성과 동작 방식에 대해 좀 더 상세하게 들여다 보자.

BeyondCorp 세부요소 ① – 기기 인증

구글의 임직원용 시스템 혹은 서비스는 인증된 기기(Managed Device)에서만 접속이 가능하다.
BeyondCorp의 “Device Inventory”라는 핵심 컴포넌트는 사용자 기기(Device)에 관련된
다양한 정보를 수집하고 분석하여, 안전한 기기에서만 접근을 허용하도록 검증하는 역할을 한다.

cap-2016-10-31-17-37-10-983[ BeyondCorp – Device Inventory Service ]

먼저 호스트 (PC라고 가정) 내부에서는 사용자 인증서(Certification), Configuration 상태,
OS Patch 정보를 에이전트를 통해 수집하고,

호스트 외부에서는 등록된 자산 정보, 디렉토리(MS의 Active Directory 개념), 네트워크 정보,
취약점 스캔 정보를 수집하게 된다.

사용자 기기에 관련된 다양한 내/외부 요소를 수집하여 Device Inventory에 저장이 되고
요청이 발생하면, 현 사용자의 Trust Level을 결정하기 위한 근거 데이터를 Pipeline을 통해 전달한다.

BeyondCorp 세부요소 ② – 사용자 인증

기기 인증과 마찬가지로, 구글 사내 시스템은 정상적인 인가된 사용자에게만 접속이 허용된다.
매우 당연한 이론이긴 하나 BeyondCorp의 사용자 인증은 몇가지 특징이 존재한다.

먼저 BeyondCorp 아키텍쳐는 구글의 모든 User 및 Group 데이터베이스와 연동되어 있어,
사용자명, 소속 그룹, 업무 카테고리 (Job Categorization), 사용자 근무 위치 정보를 반영한다.

만약 임직원의 업무가 변경되거나 퇴사 등 인사 변경이 발생하게 되면 즉시 이 DB에 반영되며,
접근 제어 엔진이 이를 반영하여 시스템 접속 허용 여부를 결정하게 된다.

사용자 인증은 외부에서도 접속가능한 SSO Portal을 통해 이루어지며
인증 방식은 Two-Factor 로써, 사용자 계정과 OTP 혹은 USB형태의 물리적 키가 사용된다.

cap-2016-11-01-09-08-23-083[ SSO Portal and User/Group Database ]

BeyondCorp 세부요소 ③ – 접근제어 엔진

A라는 사용자가 B라는 구글 사내 시스템에 접속을 요청하게 되면
Access Control Engine이 위에서 언급한 다양한 요소를 분석/판단하여 접속을 허용하거나
차단하는 역할을 담당한다.

제어 엔진이 접속 허용/차단 의사 결정을 내릴 때 활용하는 데이터의 타입은
다음 두가지로 분류할 수 있다.

① 관측 데이터 (Observed Data) : 호스트 에이전트 프로그램, 관리 시스템 등에 의해 수집된 데이터
– 사용자 PC 취약점 스캔 결과, AD 정책, OS 버전 및 패치 여부, 설치된 SW 목록 등

② 입력 데이터 (Prescribed Data) : IT 운영자(Ops)가 수동으로 사전에 입력한 데이터
– 기기에 등록 정보, DNS, DHCP, VLAN 등 네트워크 관련 정보

cap-2016-11-03-17-03-18-604[ BeyondCorp – Data Processing Pipeline ]

이 두가지 타입의 데이터는 하나의 공통된 포맷으로 변환된 후,
Trust Evaluation(보안 등급 평가) 과정을 거쳐 Access Control Engine에 반영된다.

즉, 사용자에 관련된 수집된 데이터 각각의 요소에 대해 안정성과 적합성을 판단하여,
시스템에 접속할 수 있는 요건을 갖췄는지 아닌지를 결정하게 되는 것이다.

예를 들어 가장 높은 등급의 보안 수준을 요구하는 코드 빌드 시스템이 있다고 가정해보자.
수집된 여러가지 데이터 중 사용자의 OS 버전이 낮거나, 제로데이 패치가 되지 않았다고 판단 되면,
충분한 Trust Level을 부여 받지 못하게 되어 Access Control Engine이 접속을 차단하게 된다.

2부에서 다루게 될 내용

1부에서는 Google의 BeyondCorp의 개요와 핵심 구성 요소에 대해 간단하게 알아보았다.

2부에서는 실제 사례를 통해 BeyondCorp 동작 흐름을 알아보고,
기존의 Perimeter 모델에서 BeyondCorp로 의 이전(Migration) 전략에 대해 다뤄 볼 예정이다.

아울러, 위 내용은 본인이 직접 알아본 내용을 기반으로 하고 있기 때문에,
실제 구글 내부 상황과 맞지 않은 부분이 있을 수 있음을 밝힌다.

다만,  기업 보안 네트워크의 큰 변화를 소개하는 관점으로 읽어주었으면 하는 바램이다.

Site Footer

Sliding Sidebar

About Me

About Me

June Park