BeyondProd: 클라우드 기반 보안에 대한 새로운 접근법

Google은 보안을 강화하기 위해 내부에서 개발한 프로젝트에 대해 설명하는 몇 가지 백서를 작성했습니다. BeyondProd는 BeyondCorp의 개념 즉, 경계 보안 모델이 더 이상 최종 사용자에게 유효하지 않은 것처럼 마이크로서비스에도 효과가 없다는 점을 의도적으로 이용합니다. BeyondCorp 백서의 원본 내용은 다음과 같이 각색할 수 있습니다. '이 모델의 주요 가정은 더 이상 유효하지 않습니다. 경계가 단순히 기업 [데이터 센터]의 물리적 위치라고는 더 이상 말할 수 없으며 경계 내부에 있는 것이 더 이상 개인 컴퓨팅 기기 및 기업 애플리케이션 [마이크로서비스]를 호스팅할 평화롭고 안전한 장소라고 가정할 수 없습니다.'

이 백서에서는 '클라우드 기반'이라고 알려진 아키텍처에서 Google 인프라의 여러 부분이 함께 작동하여 워크로드를 보호하는 방법을 자세히 설명합니다. Google 보안에 대한 개요는 보안 인프라 설계 백서를 참조하세요.

여기에 포함된 콘텐츠는 2019년 12월 기준으로 작성되었으며, 이 백서는 작성된 당시의 상황을 나타냅니다. Google Cloud의 보안 정책 및 시스템은 보안 성능이 향상됨에 따라 앞으로도 계속 변경될 수 있습니다.

용어

이 문서에는 다음과 같은 용어가 사용됩니다.

  • 마이크로서비스는 애플리케이션을 통해 처리해야 하는 개별 작업을 별도의 서비스로 분리하며, 각 서비스는 자체 API, 배포, 확장, 할당량 관리를 통해 독립적으로 개발 및 관리할 수 있습니다. 최신 아키텍처에서는 웹사이트와 같은 애플리케이션을 단일 모놀리식 서비스가 아닌 마이크로서비스의 모음으로 실행할 수 있습니다. 마이크로서비스는 독립적인 모듈형으로 나뉘어 동적으로 실행되는 임시 아키텍처로, 여러 호스트와 클러스터뿐 아니라 클라우드에도 분산될 수 있습니다.

  • 워크로드는 애플리케이션을 통해 완료하는 고유한 작업입니다. 마이크로서비스 아키텍처에서 워크로드는 1개 또는 여러 개의 마이크로서비스일 수 있습니다.

  • 작업은 애플리케이션의 일부를 실행하는 마이크로서비스의 단일 인스턴스입니다.

  • 마이크로서비스는 서비스 ID를 사용하여 인프라에서 실행 중인 다른 서비스에 자신을 인증할 수 있습니다.

  • 서비스 메시는 트래픽을 제어하고 정책을 적용하며 여러 서비스 호출을 중앙에서 모니터링할 수 있는 서비스 간 통신용 인프라 레이어입니다. 마이크로서비스 아키텍처를 사용하면 이러한 제어 기능을 구현하기 위해 서비스를 개별적으로 관리할 필요가 없으며 여러 마이크로서비스를 중앙에서 간편하게 관리할 수 있습니다.

CIO 수준 요약

  • Google 인프라는 워크로드를 컨테이너의 개별 마이크로서비스로 배포하고 Google의 컨테이너 조정 시스템인 Borg를 사용해 이 워크로드를 관리합니다. 이 인프라는 오늘날 '클라우드 기반'으로 알려진 아키텍처의 기반 역할을 합니다.

  • Google 인프라는 보안 측면을 고려하여 의도적으로 설계되었으며 나중에 추가하지 못합니다. 또한 Google 인프라는 서비스 간의 신뢰 관계를 추측하지 않습니다.

  • Google은 BeyondProd라는 이니셔티브를 통해 마이크로서비스를 보호합니다. 이 보호에는 코드 변경 방법과 마이크로서비스의 사용자 데이터에 액세스하는 방법이 포함됩니다. BeyondProd는 상호 인증된 서비스 엔드포인트, 전송 보안, 글로벌 부하 분산 및 서비스 거부 공격 보호의 에지 종료, 엔드 투 엔드 코드 출처, 런타임 샌드박스 등의 개념을 적용합니다.

  • 기존 보안 모델에서 클라우드 기반 보안 모델로 이전하기 위해 인프라와 개발 프로세스라는 2가지 주요 영역을 변경해야 했습니다. 모든 마이크로서비스가 포함되고 서로 연결되어 있는 공유 패브릭(서비스 메시라고도 함)에 공유 구성요소를 빌드한 결과 변경사항을 더 쉽게 적용하고 서비스 간에 일관된 보안을 유지할 수 있었습니다.

동기

Google은 리소스 활용률을 높이고 가용성이 높은 애플리케이션을 빌드하고 Google 개발자의 업무를 간소화하기 위해 컨테이너와 컨테이너 조정으로 이전했습니다. 컨테이너식 인프라로 이전하려는 또 다른 동기는 Google의 인프라에 맞춰 보안 제어 기능을 구현하는 것이었습니다. 경계 기반 보안 모델이 충분히 안전하지 않다는 점은 명확했습니다. 경계를 침범한 공격자는 네트워크 내에서 자유로운 이동이 가능했습니다. Google은 인프라 전반에 강력한 보안 제어가 필요할 뿐 아니라 Google 개발자가 보안 기능 자체를 직접 구현하지 않고도 보안 애플리케이션을 간편하게 개발하고 배포할 수 있어야 한다는 점을 확실히 인식했습니다.

조정 시스템을 사용해 모놀리식 애플리케이션에서 컨테이너에서 배포된 분산형 마이크로서비스로 이전하면서 용이한 관리와 효율적인 확장 등 실질적인 운영상의 이점을 누릴 수 있었습니다. 클라우드 기반 아키텍처를 사용하기 위해서는 관리와 확장성 측면의 마이크로서비스 이점에 맞춰 배포를 보호하기 위해 여러 도구를 사용하는 다양한 보안 모델이 필요했습니다.

이 문서에서는 Google에서 클라우드 기반 보안을 구현하는 방법, 즉 BeyondProd를 설명합니다. 여기에는 클라우드 기반으로의 변경이 보안에 미치는 영향, 클라우드 기반 보안의 원칙, 이러한 요구사항을 해결하기 위해 구축한 시스템, 유사한 변경을 직접 구현하는 방법에 대한 몇 가지 안내가 포함됩니다.

Google에 구현한 클라우드 기반 보안

컨테이너식 마이크로서비스

초창기부터 Google은 고가의 가용성이 높은 하드웨어에 투자하기 보다는 저렴한 비용의 상용 서버에서 데이터 센터 용량을 구축한다는 의도적인 결정을 내렸습니다. 과거부터 지금까지 안정성에 관한 Google의 지도 철학은 시스템을 구성하는 개별 요소에서 오류가 발생하는 경우 사용자가 확인할 수 있는 서비스의 가용성에 영향을 미치지 않아야 한다는 것입니다. 이러한 가용성을 실현하기 위해 한 번의 오류로 서비스 중단이 발생하지 않도록 서비스의 중복 인스턴스를 실행해야 했습니다. 결과적으로 중복성이 높은 분산형 시스템의 배포를 확장 가능한 방식으로 관리하기 위해 컨테이너, 마이크로서비스, 컨테이너 조정을 개발했습니다.

컨테이너식 인프라는 개별 워크로드가 이전과 예약이 가능한 불변성의 고유한 컨테이너 집합으로 배포된다는 것을 의미합니다. Google은 내부적으로 이러한 컨테이너를 관리하기 위해 Borg1라는 컨테이너 조정 시스템을 개발했으며, 이를 통해 지금까지도 일주일에 수십억 개에 이르는 컨테이너를 배포하고 있습니다.

컨테이너를 통해 머신 간에 워크로드를 보다 간편하게 적재하고 일정을 변경할 수 있었고, 마이크로서비스는 애플리케이션의 여러 부분을 더 쉽게 개발하고 디버깅할 수 있게 해줬습니다. 마이크로서비스와 컨테이너를 함께 사용하면 유지보수와 검색을 위해 워크로드를 효율적으로 관리할 수 있는 더 작은 단위로 분할할 수 있습니다. 마이크로서비스 아키텍처를 통해 컨테이너식 인프라로 이전하는 것을 '클라우드 기반' 전환이라고 합니다. 서비스는 Borg에서 배포한 컨테이너 내에서 실행됩니다. 이 아키텍처는 필요에 따라 워크로드를 조정합니다. 특정 워크로드에 대한 수요가 많을 경우 필요한 워크로드 규모를 처리하기 위해 동일한 서비스의 사본을 실행하는 여러 개의 머신이 있을 수 있습니다.

Google이 두각을 나타내는 이유는 아키텍처 진화의 모든 과정에서 보안을 고려했기 때문입니다. 최근 생겨난 클라우드 기반 보안의 개념은 Google이 수년간 인프라 보안을 위해 적용해 온 개념과 유사합니다. 이 마이크로서비스 아키텍처 및 개발 프로세스에 대한 목표는 가능한 개발 및 배포 수명 주기 초반에 보안 문제를 해결하는 것입니다. 이때 더 낮은 비용으로 문제를 해결하려면 일관성 있는 표준화된 방법이 필요합니다. 따라서 개발자는 보안에 할애하는 시간을 줄이면서도 보안을 강화할 수 있게 됩니다.

클라우드 기반 아키텍처로 마이그레이션

최신 보안 아키텍처는 방화벽이 경계를 보호하고 경계 내부의 사용자와 서비스를 전적으로 신뢰하는 기존의 경계 기반 보안 모델을 넘어섰습니다. BeyondCorp는 현대의 기업 사용자들의 업무 방식 변화에 대응하기 위한 프로젝트입니다. 현대의 사용자들은 조직의 기존 보안 경계 범위를 벗어난 커피숍, 비행기 또는 이동 중에도 평소와 같이 업무를 수행해야 하는 경우가 많습니다. BeyondCorp에서는 사용자의 네트워크 위치에 관계없이 기기, 사용자 인증 정보, 속성만으로 기업 네트워크에 권한을 부여하고 액세스 권한을 승인한다는 개념이 사라졌습니다.

클라우드 기반 보안은 사용자 측면에서와 마찬가지로 서비스에 대해서도 동일한 문제를 해결합니다. 즉, 클라우드 기반 환경에서 기업 네트워크를 보호하기 위해 방화벽에 의존할 수 없는 것과 마찬가지로 단순히 방화벽에 의존하여 프로덕션 네트워크를 보호할 수 없습니다. 사용자가 모두 동일한 물리적 위치나 기기를 사용하지 않는 것과 마찬가지로 개발자도 모두 동일한 환경에 코드를 배포하지는 않습니다. BeyondProd를 통해 마이크로서비스는 방화벽으로 보호된 데이터 센터뿐만 아니라 퍼블릭 클라우드, 프라이빗 클라우드 또는 타사 호스팅 서비스에서도 실행될 수 있습니다. 단, 모든 플랫폼에 보안 설정이 되어 있어야 합니다.

사용자가 이동하고 여러 기기를 이용하고 서로 다른 위치에서 연결하는 것처럼 마이크로서비스도 이동하고 이기종 호스트 간의 서로 다른 환경에 배포됩니다. BeyondCorp에서 '사용자의 신뢰도는 기업 네트워크에 연결할 수 있는 권한이 아니라 기기의 컨텍스트 인식 상태와 같은 특성에 좌우된다'는 부분은 BeyondProd에서 '서비스의 신뢰도는 IP 또는 호스트 이름 ID 등 프로덕션 네트워크의 위치가 아니라 코드 출처 및 서비스 ID와 같은 특성에 좌우된다'는 부분과 대응됩니다.

클라우드 기반 및 애플리케이션 개발

경계 기반 보안에 중점을 둔 종래의 보안 모델은 클라우드 기반 아키텍처 보호에 그다지 효과가 없습니다. 이에 대한 예를 살펴보겠습니다. 3단계 아키텍처를 사용하는 모놀리식 애플리케이션이 중요한 이벤트의 최대 부하를 처리하기에 충분한 용량이 있는 기업의 비공개 데이터 센터에 배포됩니다. 특정 하드웨어 또는 네트워크 요구사항을 준수해야 하는 애플리케이션은 일반적으로 고정 IP 주소를 유지관리하는 특정 머신에 의도적으로 배포됩니다. 배포는 간헐적이지만 큰 규모로 발생하고 조정이 어려운데, 이는 결과로 발생하는 변경사항이 애플리케이션의 여러 부분에 동시에 적용되기 때문입니다. 이에 따라 애플리케이션이 오랫동안 유지되며 업데이트 빈도와 보안 패치 적용 빈도는 상대적으로 낮습니다.

그러나 클라우드 기반 모델에서 컨테이너는 애플리케이션에 필요한 바이너리를 기본 호스클라우드트 운영체제에서 분리하므로 애플리케이션의 이동성이 향상됩니다. 컨테이너는 불변성이 보장되므로 배포 후에도 변경되지 않습니다. 따라서 재빌드되고 재배포되는 빈도가 높습니다. 작업은 부하가 증가할 때 새 작업을 배포하고 부하가 감소하면 기존 작업을 종료하는 방식으로 부하를 처리하도록 확장됩니다. 컨테이너가 자주 재시작, 종료 또는 일정 변경됨에 따라 하드웨어와 네트워킹을 재사용하고 공유하는 빈도도 높아집니다. 공통의 표준화된 빌드와 분산 프로세스를 사용하므로 여러 팀에서 마이크로서비스의 개발을 독립적으로 관리하는 경우에도 팀 간의 개발 프로세스가 보다 일관되고 균일해집니다. 그 결과, 개발 주기 초기에 보안 고려 사항(예: 보안 검토, 코드 검색, 취약점 관리)이 적용될 수 있습니다.

보안에 미치는 영향

Google은 BeyondCorp의 사용자들과 내부 환경을 신뢰하지 않는 모델을 어떻게 하면 BeyondProd의 마이크로서비스에도 적용할 수 있을지에 대해 많은 이야기를 나누었습니다. 그렇다면 이러한 변화가 미치는 영향은 어떨까요? 표 1은 기존 인프라의 보안 측면과 클라우드 기반 아키텍처의 보안 측면을 비교한 것입니다. 이 표에는 기존 인프라에서 클라우드 기반으로 전환하는 데 필요한 요구사항도 나와 있습니다. 이 섹션의 나머지 부분에서는 표의 각 행에 대해 자세히 설명합니다.

기존 인프라 보안 클라우드 기반 보안 클라우드 기반 보안의 암시적 요구사항
내부 통신이 신뢰할 수 있는 통신으로 간주되는 경계 기반 보안(예: 방화벽) 서비스 간 통신이 확인되고 환경 내 서비스에 암시적 신뢰 관계가 없는 제로 트러스트 보안 에지에서 네트워크 보호(적용 가능한 상태로 유지) 및 서비스 간에 내재된 상호 신뢰 관계가 없음
특정 애플리케이션의 고정 IP 및 하드웨어 IP와 하드웨어를 비롯하여 리소스 활용, 재사용 및 공유 향상 알려진 출처의 코드를 실행하는 신뢰할 수 있는 머신
IP 주소 기반 ID 서비스 기반 ID
알려진 예상 위치에서 서비스 실행 퍼블릭 클라우드 및 비공개 데이터 센터 전반의 하이브리드 배포를 비롯하여 환경 내 어디에서든 서비스 실행이 가능합니다.
보안별 요구사항은 각 애플리케이션에 내장되어 별도로 적용됩니다.공유된 보안 요구사항은 중앙 집중식 적용 정책에 따라 서비스 스택에 통합됩니다. 서비스 전반에 정책을 일관되게 적용하기 위한 초크 포인트
서비스 빌드 및 검토 방법에 대한 제한사항이 많지 않음 보안 요구사항이 모든 서비스에 일관되게 적용됨
보안 구성요소에 대한 감독 부족 보안 정책 및 정책 준수 여부를 확인할 수 있는 중앙 집중식 보기
전문화되고 간헐적인 배포 개별 마이크로서비스의 변경 빈도가 높은 표준화된 빌드 및 배포 프로세스 자동화되고 표준화된 간단한 변경사항 배포
워크로드는 대개 VM이나 물리적 호스트에 배포되며 물리적 머신이나 하이퍼바이저를 통해 격리됩니다. 적재된 워크로드와 관련 프로세스는 공유된 운영체제에서 실행되므로 워크로드를 격리할 메커니즘이 필요합니다. 운영체제를 공유하는 워크로드 간 격리

표 1: 클라우드 기반 아키텍처로의 전환 시 보안 관련 암시적 요구사항

경계 기반 보안에서 제로 트러스트 보안으로의 전환

기존 보안 모델에서 조직의 애플리케이션은 수신 트래픽으로부터 보호하기 위해 비공개 데이터 센터 주변의 외부 방화벽을 사용했습니다. 클라우드 기반 환경에서는 BeyondCorp 모델에서처럼 네트워크 경계를 보호해야 하지만 경계 기반 모델로는 충분하지 않습니다. 이를 통해 새로운 보안 문제가 발생하지는 않지만, 방화벽이 기업 네트워크를 완벽하게 보호하지 못하면 프로덕션 네트워크도 완벽하게 보호하지 못한다는 현실에 직면했습니다. 제로 트러스트 보안 모델에서는 내부 트래픽을 더 이상 암시적으로 신뢰할 수 없으므로, 인증과 암호화 같은 다른 보안 제어 기능이 필요합니다. 동시에 마이크로서비스로 전환할 때 기존의 보안 모델을 재고해 볼 기회를 얻게 됩니다. 단일 네트워크 경계(예: 방화벽)에서 종속 항목을 제거하면 서비스를 기준으로 네트워크를 더 세분화할 수 있습니다. 여기에서 한 걸음 더 나아가 서비스 간에 고유한 신뢰 관계없이 마이크로서비스 수준의 세분화를 구현할 수 있습니다. 마이크로서비스의 트래픽에는 여러 제어 기능을 사용하는 다양한 수준의 신뢰 관계가 포함되어 있으므로, 더 이상 내부 트래픽과 외부 트래픽을 비교하지 않아도 됩니다.

고정 IP 및 하드웨어에서 활용률이 높은 공유된 리소스로의 전환

기존 보안 모델에서 조직의 애플리케이션은 특정 머신에 배포되고 해당 머신의 IP 주소는 자주 바뀌지 않았습니다. 즉, 보안 도구는 예측 가능한 방식으로 애플리케이션을 연결한 비교적 정적인 아키텍처 맵을 사용할 수 있었습니다. 예를 들어 방화벽과 같은 도구의 보안 정책은 IP 주소를 식별자로 사용할 수 있습니다.

하지만 공유 호스트와 자주 변경되는 작업이 있는 클라우드 기반 환경에서는 방화벽을 통해 마이크로서비스 간 액세스를 제어할 수 없습니다. 특정 IP 주소가 특정 서비스에 연결되어 있다는 사실에 의존해서는 안됩니다. 따라서 IP 주소나 호스트 이름의 ID를 기반으로 하는 대신 서비스의 ID를 기준으로 합니다.

애플리케이션별 보안 구현에서 서비스 스택에 통합된 공유 보안 요구사항으로 전환

기존 보안 모델에서 개별 애플리케이션은 다른 서비스와는 별개로 자체 보안 요구사항을 충족해야 했습니다. 이러한 요구사항에는 ID 관리, SSL/TLS 종료, 데이터 액세스 관리가 포함됩니다. 이로 인해 구현이 일관되지 않거나 여러 위치에서 보안 문제가 해결되지 않은 경우가 많아 변경사항을 적용하기가 더 어려워졌습니다.

클라우드 기반 환경에서는 서비스 간에 구성요소가 재사용되는 빈도가 훨씬 더 높으며 서비스 전반에 정책이 일관되게 적용되도록 하는 초크 포인트가 있습니다. 다양한 정책이 있을 경우 여러 보안 서비스를 사용해 적용할 수 있습니다. 모든 애플리케이션에서 중요한 보안 서비스를 별도로 구현할 필요 없이 다양한 정책을 별도의 마이크로서비스로 분할할 수 있습니다. 예를 들어 한 정책은 사용자 데이터에 대해 승인된 액세스를 보장하도록 구현하고 다른 정책은 최신 TLS 암호화 모음의 사용을 보장하도록 구현합니다.

전문화되고 간헐적인 배포 프로세스에서 배포 빈도가 높은 표준화된 프로세스로 전환

기존 보안 모델에서는 공유 서비스가 많지 않았습니다. 로컬 개발과 결부되어 코드가 더 분산되어 있기 때문에 애플리케이션의 여러 부분에 영향을 미친 변경사항의 영향을 확인하기가 어려우며, 결과적으로 배포 빈도가 낮고 조정하기가 어려웠습니다. 개발자가 각 구성요소를 직접 업데이트해야 변경할 수 있었습니다. 예를 들어 구성을 업데이트하려면 SSH를 통해 가상 머신에 연결해야 했습니다. 그 결과 애플리케이션이 전반적으로 꽤 오랫동안 유지되었습니다. 보안 측면에서는 코드가 더 분산되면서 검토하기가 더 어려워졌고, 모든 곳에서 취약점을 수정하기가 더욱 어려워졌습니다. 빈도가 높고 표준화된 배포 프로세스를 사용하는 클라우드 기반으로 이전하면 소프트웨어 개발 수명 주기에서 원점 회귀2 보안을 구현할 수 있습니다. 이렇게 하면 정기적인 보안 패치 적용을 포함하여 보안 위생을 더 간편하고 일관되게 적용할 수 있습니다.

물리적 머신 또는 하이퍼바이저를 통해 격리된 워크로드에서 동일한 머신에서 실행되어 더 강력한 격리가 필요한 적재 워크로드로의 전환

기존 보안 모델에서는 공유 리소스 없이 자체 인스턴스에 워크로드를 예약했습니다. 애플리케이션은 머신과 네트워크 경계를 기준으로 효과적으로 구분되었고 워크로드는 물리적 호스트 분리, 하이퍼바이저, 기존 방화벽만 사용해도 격리할 수 있었습니다.

클라우드 기반 환경에서 워크로드는 컨테이너화되어 공유 호스트 및 공유 리소스에 적재됩니다. 따라서 워크로드 간에는 더욱 강력한 격리 조치를 적용해야 합니다. 워크로드는 네트워크 제어 및 샌드박스 기술을 사용하여 부분적으로 서로 격리된 마이크로서비스로 분리할 수 있습니다.

보안 원칙

클라우드 기반 아키텍처 개발과 동시에 보안을 강화하기 위해 Google은 다음과 같은 보안 원칙을 개발하고 최적화했습니다.

  • 에지에서 네트워크 보호: 워크로드를 인터넷에서 들어오는 무단 트래픽 및 네트워크 공격으로부터 격리합니다. 방화벽 기반의 접근법은 클라우드 기반에 새로 도입된 개념은 아니지만 여전히 보안 권장사항으로 사용할 수 있습니다. 클라우드 기반 환경에서 경계 접근법은 인터넷에서 들어오는 무단 트래픽 및 공격 가능성(예: 볼륨 기반의 서비스 거부 공격)으로부터 가능한 많은 인프라를 보호하는 데 사용됩니다.

  • 서비스 간 내재된 상호 신뢰 관계 없음: 알려지고 신뢰할 수 있으며 특별히 승인된 호출자만 서비스를 활용할 수 있으므로, 신뢰할 수 없는 코드를 사용하는 공격자가 서비스에 액세스하지 못하도록 차단할 수 있습니다. 서비스 보안 침해가 발생하면 공격자가 이 취약점을 악용해 공격 범위를 확장하지 못하도록 방지합니다. 이러한 상호 신뢰하지 않은 구조는 보안 침해의 영향 범위를 제한하는 데 도움이 됩니다.

  • 알려진 출처의 코드를 실행하는 신뢰할 수 있는 머신: 서비스 ID가 승인 코드와 구성만 사용하여 승인되고 검증된 환경에서만 실행되도록 제한합니다.

  • 서비스 전반에 정책을 일관되게 적용하기 위한 초크 포인트 예를 들어 서비스의 액세스가 승인된 최종 사용자의 검증된 요청에서 파생되고 관리자의 액세스에 비즈니스 근거가 필요한 경우 사용자 데이터에 대한 액세스 요청을 확인하기 위한 초크 포인트입니다.

  • 자동화되고 표준화된 간단한 변경사항 배포: 인프라 변경사항이 보안에 미치는 영향을 간편하게 검토하고 프로덕션에 미치는 영향 없이 보안 패치를 배포할 수 있습니다.

  • 운영체제를 공유하는 워크로드 간 격리: 서비스 보안 침해가 발생해도 동일한 호스트에서 실행 중인 다른 워크로드의 보안에는 영향을 미치지 않습니다. 따라서 잠재적인 보안 침해의 '영향 범위'가 제한됩니다.

Google의 목표는 Google의 인프라 전반에서 개별 항목에 좌우되지 않는 자동화된 보안 기능을 갖추는 것입니다. 보안은 서비스 확장과 동일한 방식으로 확장되어야 합니다. 서비스는 기본적으로 보안이 유지되어야 하며 안전하지 않은 서비스는 예외로 처리해야 합니다. 사람의 개입은 루틴이 아닌 예외적으로 허용되고 감사가 가능해야 합니다. 그러면 서비스를 배포한 사용자 대신 서비스에 배포된 코드 및 구성을 기반으로 서비스를 인증할 수 있습니다.

위의 보안 원칙을 함께 구현하면 클라우드 기반 아키텍처의 속성(예: 간편한 워크로드 관리, 노옵스(no-ops) 확장, 효과적인 적재)을 약화시키지 않고도 내부에서 실행되는 컨테이너와 마이크로서비스가 배포되고 서로 통신하며 서로 인접한 거리에서 실행될 수 있습니다. 이 모든 것은 기본 인프라의 보안 및 구현 세부정보를 통해 개별 마이크로서비스 개발자의 부담을 최소화하면서 실현할 수 있습니다.

Google의 내부 보안 서비스

Google은 클라우드 기반 인프라를 보호하기 위해 몇 가지 내부 도구와 서비스를 설계하고 개발했습니다. 아래에 나열된 보안 서비스를 연계하여 보안 원칙 섹션에 정의된 보안 원칙을 해결할 수 있습니다.

  • Google 프런트 엔드(GFE): 최종 사용자와의 연결을 종료하고 TLS 권장사항을 적용하는 중심점을 제공합니다. Google은 더 이상 경계 기반 보안에 중점을 두고 있지 않지만, GFE는 서비스 거부 공격으로부터 내부 서비스를 보호하는 전략에서 중요한 역할을 합니다. GFE는 사용자와 Google 간의 연결에서 첫 번째 진입점 역할을 하며, 인프라 내에 배치된 GFE는 필요에 따라 리전 간 트래픽의 경로를 변경하고 부하를 분산하는 역할도 합니다. Google 인프라에서 GFE는 적절한 마이크로서비스로 트래픽을 라우팅하는 에지 프록시입니다.

  • 애플리케이션 레이어 전송 보안(ALTS): RPC 인증, 무결성, 암호화에 사용됩니다. ALTS는 Google 인프라의 서비스를 위한 상호 인증 및 전송 암호화 시스템입니다. 일반적으로 ID는 특정 서버 이름 또는 호스트가 아니라 서비스에 바인딩됩니다. 이를 통해 여러 호스트 간의 원활한 마이크로서비스 복제, 부하 분산, 일정 변경이 용이해집니다.

  • Borg용 Binary Authorization호스트 무결성은 각각 마이크로서비스 및 머신 무결성 확인에 사용됩니다.

    • Borg용 Binary Authorization(BAB): 코드를 배포하기 전 해당 코드가 내부 보안 요구사항을 충족하는지 여부를 확인하는 배포-시간 시행 확인입니다. BAB 확인에는 변경사항이 다른 엔지니어로부터 검토를 받았는지, 코드가 소스 코드 저장소에 제출되었는지, 전용 인프라에 검증 가능한 방식으로 바이너리가 빌드되었는지가 포함됩니다. Google 인프라에서 BAB는 승인되지 않은 마이크로서비스의 배포를 제한합니다.
    • 호스트 무결성(HINT): 보안 부팅 프로세스를 통해 호스트 시스템 소프트웨어의 무결성을 확인하고 지원되는 경우 보안 마이크로컨트롤러 하드웨어에서 지원됩니다. HINT 확인에는 BIOS, BMC, 부트로더, OS 커널의 디지털 서명 확인이 포함됩니다.
  • 서비스 액세스 정책최종 사용자 컨텍스트 티켓은 데이터에 대한 액세스를 제한하는 데 사용됩니다.

    • 서비스 액세스 정책: 서비스 간 데이터 액세스 방식을 제한합니다. RPC가 한 서비스에서 다른 서비스로 전송될 때 서비스 액세스 정책은 수신 서비스의 데이터에 액세스하는 데 필요한 인증, 승인, 감사 정책을 정의합니다. 이를 통해 데이터 액세스 방식을 제한하고, 필요한 최소한의 액세스 수준을 부여하며, 해당 액세스 권한을 감사할 수 있는 방법을 지정합니다. Google 인프라에서 서비스 액세스 정책은 한 마이크로서비스의 데이터에 대한 다른 마이크로서비스의 액세스를 제한하며 액세스 제어에 대한 글로벌 분석을 허용합니다.
    • 최종 사용자 컨텍스트(EUC) 티켓: 최종 사용자 인증 서비스에서 발급하는 티켓으로 서비스 ID와는 별개의 사용자 ID를 서비스에 제공합니다. 또한 무결성이 보호되고 중앙에서 발급되며 전달 가능한 사용자 인증 정보로 서비스 요청을 실행하는 최종 사용자의 신원을 증명합니다. 따라서 ALTS를 통해 피어 ID를 사용할 경우 일반적으로 최종 사용자 ID에 기반하는 승인 결정으로 액세스 권한을 부여하기에 충분하지 않기 때문에 서비스 간 신뢰 관계의 필요성이 줄어듭니다.
  • 블루-그린 배포용 Borg 도구3: 이 도구는 유지보수 작업을 수행할 때 실행 중인 워크로드를 마이그레이션합니다. 새 Borg 작업은 기존 Borg 작업과 함께 배포되며 부하 분산기는 트래픽을 점진적으로 이동합니다. 이렇게 하면 다운타임 없이 사용자가 눈치채지 않게 마이크로서비스를 업데이트할 수 있습니다. 이 도구는 새로운 기능을 추가할 때 서비스 업그레이드를 적용하고 다운타임(예: Heartbleed 및 스펙터/멜트다운) 없이 중요한 보안 업데이트를 적용하는 데 사용됩니다. Google Cloud 인프라에 영향을 미치는 변경사항의 경우 라이브 마이그레이션을 통해 VM 워크로드가 영향을 받지 않도록 해야 합니다.

  • 워크로드 격리에 사용되는 gVisor는 사용자 공간 커널을 사용하여 syscall을 가로채 처리하므로 호스트 및 공격에 취약한 부분과의 상호작용을 줄일 수 있습니다. 이 커널은 애플리케이션을 실행하는 데 필요한 기능 대부분을 제공하고 애플리케이션에 액세스할 수 있는 호스트 커널 영역을 제한합니다. Google 인프라에서 gVisor는 동일한 호스트에서 실행되는 내부 워크로드와 Google Cloud 고객 워크로드를 각기 따로 격리하는 데 사용되는 몇 가지 중요한 도구 중 하나입니다.

표 2에는 보안 원칙 섹션에서 설명한 각 원칙과 Google에서 해당 원칙을 구현하기 위해 사용하는 도구가 나와 있습니다.

보안 원칙 Google의 내부 보안 도구/서비스
에지에서 네트워크 보호 Google 프런트 엔드(GFE): 수신 트래픽을 위한 TLS 종료 및 정책 관리
서비스 간 내재된 상호 신뢰 관계 없음 애플리케이션 레이어 전송 보안(ALTS): RPC 인증, 무결성, 암호화, 서비스 ID에 사용
알려진 출처의 코드를 실행하는 신뢰할 수 있는 머신 Borg용 Binary Authorization(BAB): 코드 출처 확인

호스트 무결성(HINT): 머신 무결성 확인

서비스 전반에 정책을 일관되게 적용하기 위한 초크 포인트 서비스 액세스 정책: 서비스 간 데이터 액세스 방식 제한

최종 사용자 컨텍스트(EUC) 티켓: 원래 요청자의 신원 증명

자동화되고 표준화된 간단한 변경사항 배포 Borg 도구: 블루-그린 배포
운영체제를 공유하는 워크로드 간 격리 gVisor: 워크로드 격리

표 2: Google에서 클라우드 기반 보안을 구현하기 위한 원칙 및 보안 도구

하나로 결합

이 섹션에서는 지금까지 논의한 구성요소가 클라우드 기반 환경에서 사용자 요청을 처리하기 위해 어떻게 연결되는지 보여줍니다. 여기에서는 두 가지 예시를 살펴보게 되는데, 먼저 일반적인 사용자 데이터 요청을 생성부터 대상에 도착할 때까지 추적하고, 그 다음 개발에서 프로덕션까지의 코드 변경을 추적합니다. 여기에 나열된 기술 중 일부는 서비스와 워크로드에 따라 Google 인프라의 모든 부분에 사용됩니다.

사용자 데이터 액세스

그림 1에 나와 있는 것처럼 GFE에 사용자의 요청이 수신되면(1단계) GFE에서 TLS 연결을 종료하고 해당 요청을 ALTS4를 통해 적절한 서비스의 프런트엔드로 전달합니다(2단계). 애플리케이션 프런트엔드는 중앙의 최종 사용자 인증(EUA) 서비스를 통해 사용자의 요청을 인증하고, 인증에 성공하면 단기 암호화 최종 사용자 컨텍스트(EUC) 티켓이 수신됩니다(3단계).

도표

그림 1: Google의 클라우드 기반 아키텍처 보안 제어 - 사용자 데이터 액세스

그러면 애플리케이션 프런트엔드는 ALTS를 통해 스토리지 백엔드 서비스에 대해 RPC 호출을 실행하여 백엔드 요청에서 EUC 티켓을 전달합니다(4단계). 백엔드 서비스는 다음을 확인하기 위해 서비스 액세스 정책을 사용합니다.

  1. 프런트엔드 서비스의 ALTS ID가 백엔드 서비스에 대해 요청을 실행하고 EUC 티켓을 전달할 권한이 있는지 여부
  2. 프런트엔드의 ID가 Google의 Borg용 Binary Authorization(BAB)에서 보호되는지 여부
  3. EUC 티켓이 유효한지 여부

이제 백엔드 서비스는 EUC 티켓 사용자가 요청된 데이터에 액세스할 권한이 있는지 확인합니다. 이러한 확인 중 하나라도 실패하면 요청이 거부됩니다. 대부분의 경우 일련의 백엔드 호출이 있고 모든 중간 서비스는 인바운드 RPC에서 서비스 액세스 정책을 확인하며 EUC 티켓은 아웃바운드 RPC로 전달됩니다. 이러한 확인에 통과하면 데이터가 승인된 애플리케이션 프런트엔드로 반환되어 승인된 사용자에게 제공됩니다.

각 머신에는 HINT 시스템을 통해 프로비저닝된 ALTS 사용자 인증 정보가 있으며 HINT에서 머신이 부팅되었음을 확인한 경우에만 복호화될 수 있습니다. 대부분의 Google 서비스는 Borg를 기반으로 하여 마이크로서비스로 실행되며 이러한 마이크로서비스는 각각 고유한 ALTS ID를 가집니다. Borgmaster5는 그림 1에서 설명한 것처럼 마이크로서비스 ID를 기준으로 이러한 ALTS 마이크로서비스 사용자 인증 정보를 워크로드에 부여합니다. 머신 수준 ALTS 사용자 인증 정보는 마이크로서비스 사용자 인증 정보를 프로비저닝하는 보안 채널을 구성하므로 HINT 자체 검사 부팅에 성공한 머신만 실제로 마이크로서비스 워크로드를 호스팅할 수 있습니다.

코드 변경하기

그림 2에 나와 있는 것처럼 Google 직원이 적절한 강도의 BAB로 보호되는 마이크로서비스를 변경하면 해당 변경사항은 코드 검토를 시행하는 Google의 중앙 코드 저장소에 제출되어야 합니다. 승인된 변경사항은 서명되고 검증 가능한 빌드 매니페스트 인증서가 포함된 패키지를 생성하는 중앙의 신뢰할 수 있는 빌드 시스템에 제출됩니다(1단계). 배포 시 BAB는 빌드 파이프라인에서 서명된 인증서를 검증해 이 프로세스가 준수되었는지 확인합니다(2단계).

도표

그림 2: Google의 클라우드 기반 아키텍처 보안 제어 - 코드 변경하기

모든 워크로드 업데이트는 정기적인 배포이든 긴급 보안 패치이든 관계없이 블루-그린 배포를 통해 처리됩니다(3단계). GFE는 작업의 연속성을 유지하기 위해 새 배포에 트래픽을 부하 분산합니다.

모든 워크로드는 격리해야 합니다. 예를 들어 워크로드가 멀티 테넌트이거나 소스 코드 출처가 Google 외부인 경우와 같이 워크로드의 신뢰도 수준이 낮으면 gVisor로 보호된 환경에 배포되거나 다른 격리 레이어를 사용할 수 있습니다. 이렇게 격리하면 애플리케이션의 한 인스턴스가 손상되더라도 다른 인스턴스는 영향을 받지 않습니다.

BeyondProd 적용

모든 항목 통합

클라우드 기반으로 전환하고 인프라를 적절하게 보호함으로써 Google은 Google Cloud 내부 및 외부 워크로드에 매우 강력한 보안 속성을 제공할 수 있습니다.

공유 구성요소를 빌드하면 공통적인 보안 요구사항을 충족하기 위해 개별 개발자에게 가중되는 부담이 최소화됩니다. 보안 기능은 각 개별 애플리케이션에 대한 통합을 거의 또는 전혀 요구하지 않는 것이 가장 좋지만, 모든 마이크로서비스가 포함되고 서로 연결되어 있는 패브릭으로 제공됩니다. 이 패브릭을 서비스 메시라고도 합니다. 또한, 이에 따라 보안이 정기적인 개발 또는 배포 활동과 별개로 관리되고 구현될 수 있습니다.

클라우드 기반으로 변경하기

Google은 클라우드 기반으로 전환하기 위해 인프라와 개발 프로세스라는 2가지 주요 영역을 변경해야 했습니다. Google은 이러한 변경사항을 동시에 처리했지만, 분리해 독립적으로 해결하는 것도 가능합니다.

인프라 변경

Google은 먼저 서비스 ID, 인증, 승인을 위한 강력한 기반을 구축했습니다. 신뢰할 수 있는 기존의 서비스 ID를 기반으로 서비스 액세스 정책 및 EUC 티켓과 같은 서비스 ID를 검증한 결과에 따라 더 높은 수준의 보안 기능을 구현할 수 있었습니다. 새로운 서비스와 기존 서비스를 간단하게 전환하기 위해 ALTS는 우선 하나의 도우미 데몬이 있는 라이브러리로 제공되었습니다. 이 데몬은 모든 서비스에서 호출되고 시간 경과에 따라 서비스 사용자 인증 정보를 사용한 라이브러리로 진화하는 호스트에서 실행되었습니다. ALTS 라이브러리는 핵심 RPC 라이브러리와 완벽하게 통합되었으며, 이를 통해 개별 개발팀에 가중되는 부담 없이 폭넓게 채택하는 것이 가능했습니다. ALTS 배포를 수행하려면 먼저 서비스 액세스 정책 및 EUC 티켓이 먼저 배포되어야 합니다.

개발 프로세스 변경

강력한 빌드 및 코드 검토 프로세스를 설정하는 것이 Google에 중요했습니다. 이를 통해 실행 중인 서비스의 무결성과 ALTS에 사용된 ID가 유의미한지 확인할 수 있었습니다. Google은 2인 코드 검토와 빌드 및 배포 시 자동화된 테스트와 같은 요구사항 적용을 시작할 수 있는 중앙 집중식 빌드 프로세스를 구축했습니다. 배포에 관한 자세한 내용은 Borg용 Binary Authorization 백서를 참조하세요.

기본사항을 모두 갖춘 후에 Google 환경에서 외부의 신뢰할 수 없는 코드를 실행하는 데 필요한 요구사항을 해결하기 시작했습니다. 이 목표를 달성하기 위해 우선 ptrace로 시작한 후 gVisor를 사용하여 샌드박스 생성을 시작했습니다. 마찬가지로 블루-그린 배포는 보안(예: 패치 적용)뿐 아니라 안정성 측면에서 상당한 이점을 제공했습니다.

Google은 서비스가 위반사항을 차단하는 대신 정책 위반을 로깅하는 것이 더 쉽다는 것을 빠르게 파악했습니다. 이 접근법의 이점은 두 가지입니다. 첫 번째는 서비스 소유자에게 변경사항을 테스트하고 클라우드 기반 환경으로의 이전이 서비스에 미치는 영향을 가늠할 수 있는 기회를 제공했다는 점이고, 두 번째는 이를 통해 버그를 수정하고 서비스 팀에 제공해야 할 추가 기능을 식별할 수 있게 해줬다는 점입니다. 예를 들어 서비스가 BAB에 온보딩되면 서비스 소유자는 감사 전용 모드를 사용 설정합니다. 따라서 요구사항을 충족하지 않는 코드나 워크플로를 식별할 수 있습니다. 감사 전용 모드에서 표시된 문제가 해결되면 서비스 소유자는 시행 모드로 전환합니다. gVisor에서는 샌드박스 기능에 호환성 차이가 있는 경우에도 먼저 샌드박스 워크로드를 처리한 다음 이러한 차이를 체계적으로 해결하여 샌드박스를 개선했습니다.

변경의 이점

BeyondCorp를 통해 경계 기반 보안 모델 범위를 넘어 진화한 것과 같은 방법으로 BeyondProd는 프로덕션 단계의 보안 접근법에서 큰 도약을 만들어 냈습니다. BeyondProd 접근법은 서비스 간의 신뢰 관계를 추측하지 않고, 워크로드 간을 격리하고, 중앙에서 빌드된 애플리케이션만 배포되는지 확인하고, 취약성 관리를 자동화하며, 중요한 데이터에 대해 강력한 액세스 제어를 적용하는 클라우드 기반 보안 아키텍처를 설명합니다. Google은 BeyondProd 아키텍처를 통해 이러한 요구사항을 충족할 수 있도록 몇 가지 새로운 시스템을 혁신했습니다.

새로운 아키텍처로의 마이그레이션을 결정했을 때 보안이 가장 마지막에 '고려'되는 경우가 허다합니다. 클라우드 기반 아키텍처는 보안팀을 조기에 투입하여 보다 단순한 패치 관리와 보다 확실한 액세스 제어 같은 새로운 보안 모델의 이점에 집중함으로써 애플리케이션 개발팀과 보안팀에 상당한 이점을 제공할 수 있습니다. 이 문서에 설명된 보안 원칙을 클라우드 기반 인프라에 적용할 경우 워크로드의 배포, 워크로드의 통신 보안, 워크로드 간에 미치는 영향을 강화할 수 있습니다.

참고

1 Borg는 규모에 맞춰 워크로드를 예약하고 실행하기 위한 Google의 클러스터 관리 시스템입니다. Borg는 Google 최초의 통합 컨테이너 관리 시스템으로 Kubernetes 개발의 계기가 되었습니다.

2 '원점 회귀'는 코드, 빌드, 테스트, 검증, 배포 등의 단계를 포함할 수 있는 소프트웨어 개발 수명 주기의 초기 단계로 돌아가는 것을 의미합니다. 수명 주기 다이어그램은 왼쪽에서 오른쪽으로 그리는 경우가 많으므로 왼쪽은 초기 단계를 의미합니다.

3 블루-그린 배포는 수신 트래픽에 영향을 주지 않고 워크로드 변경사항을 배포하여 최종 사용자가 애플리케이션에 액세스할 때 다운타임이 발생하지 않도록 하는 방법입니다.

4 Google 인프라 내에서 GFE에서 서비스로 트래픽이 라우팅되는 방식을 더 잘 이해하려면 전송 중인 데이터 암호화 백서에서 트래픽이 라우팅되는 방식 섹션을 참조하세요.

5 Borgmaster는 Borg의 중앙 집중식 컨트롤러로, 작업 예약을 관리하고 현재 상태로 실행 중인 작업과 통신합니다.