Google 인프라 보안 설계 개요

여기에 나와 있는 콘텐츠는 2017년 1월 기준으로 작성되었으며 작성 당시의 상황을 나타냅니다. Google에서 고객 보호를 지속적으로 개선하고 있으므로 앞으로 Google 보안 정책과 시스템이 변경될 수 있습니다.

CIO 수준 요약

  • Google은 Google의 정보 처리 수명 주기 전체를 통틀어 보안을 제공하도록 설계된 글로벌 규모의 기술 인프라를 보유하고 있습니다. 이 인프라는 서비스의 안전한 배포, 최종 사용자 개인정보 보호 수단이 적용된 안전한 데이터 저장소, 서비스 간의 안전한 통신, 인터넷을 통한 고객과의 안전한 비공개 통신, 관리자에 의한 안전한 운영을 제공합니다.
  • Google은 이 인프라를 사용하여 검색, Gmail, 포토와 같은 소비자 서비스 및 G Suite, Google Cloud Platform과 같은 기업용 서비스를 포함한 인터넷 서비스를 빌드합니다.
  • 인프라 보안은 데이터 센터의 물리적 보안, 인프라의 기반이 되는 하드웨어와 소프트웨어의 보안, 운영 보안 지원을 위해 적용되는 기술적인 제약조건 및 프로세스에 이르는 점진적인 여러 레이어로 설계되어 있습니다.
  • Google은 모든 Google 서비스에 분산되어 있는 보안 및 개인정보 보호를 전담하는 수백 명의 엔지니어와 함께 인프라 보호에 막대하게 투자하고 있으며 이러한 엔지니어 중 다수가 업계에서 인정을 받는 보안 권위자입니다.

소개

이 문서에서는 Google 기술 인프라에서 보안이 어떻게 설계되어 있는지를 개략적으로 설명합니다. 글로벌 규모의 인프라는 Google의 정보 처리 수명 주기 전체를 통틀어 보안을 제공하도록 설계되어 있습니다. 이 인프라는 서비스의 안전한 배포, 최종 사용자 개인정보 보호 수단이 적용된 안전한 데이터 저장소, 서비스 간의 안전한 통신, 인터넷을 통한 고객과의 안전한 비공개 통신, 관리자에 의한 안전한 운영을 제공합니다.

Google은 이 인프라를 사용하여 검색, Gmail, 포토와 같은 소비자 서비스 및 G Suite, Google Cloud Platform과 같은 기업용 서비스를 포함한 인터넷 서비스를 빌드합니다.

데이터 센터의 물리적 보안부터 시작하여 이어서 인프라의 기반이 되는 하드웨어와 소프트웨어에 보안이 적용되는 방식을, 마지막으로 운영 보안 지원을 위해 적용되는 기술적인 제약조건 및 프로세스를 설명하여 점진적인 여러 레이어로 이루어진 인프라 보안을 설명합니다.

Google 인프라 보안 레이어: 최하위 레이어의 하드웨어 인프라에서부터 최상위 레이어의 운영 보안까지 다양한 보안 레이어가 있습니다. 각 레이어의 내용은 자료에 자세히 설명되어 있습니다.

하위 수준의 보안 인프라

이 섹션에서는 실제 데이터 센터 건물에서부터 목적에 맞게 구축된 데이터 센터 하드웨어와 모든 머신에서 실행되는 하위 수준의 소프트웨어 스택에 이르기까지 Google 인프라의 최하위 레이어에 보안을 적용하는 방식을 설명합니다.

실제 데이터 센터 건물의 보안

Google은 자체 데이터 센터를 설계 및 구축하여 물리적 보안 보호의 여러 레이어를 통합합니다. Google 직원 중 극소수만이 데이터 센터에 액세스할 수 있습니다. 여러 물리적 보안 레이어를 사용하여 데이터 센터 층을 보호하고 생체 정보 식별, 금속 탐지, 카메라, 차량 방지 장벽, 레이저 기반의 침입 탐지 시스템 등의 기술을 사용합니다. 또한 Google은 데이터 센터 운영자가 제공하는 보안 레이어를 바탕으로 Google에서 직접 물리적 보안 조치를 제어할 수 있는 타사 데이터 센터에서 일부 서버를 호스팅합니다. 예를 들어 이러한 타사 데이터 센터에서 Google이 독립적인 생체 정보 식별 시스템, 카메라, 금속 탐지기를 운영할 수 있습니다.

하드웨어 설계 및 출처

Google 데이터 센터는 로컬 네트워크에 연결되는 수천 개의 서버 머신으로 구성됩니다. 서버 보드 및 네트워킹 장비 둘 다 Google에서 커스텀 설계했습니다. Google은 함께 작업할 부품 공급업체를 심사한 후 신중하게 부품을 선택하며, 공급업체와 협력하여 부품이 제공하는 보안 속성을 감사하고 검증합니다. 또한 현재 서버 및 주변기기에 배치되고 있는 하드웨어 보안 칩을 비롯해 커스텀 칩을 설계합니다. 이러한 칩을 통해 하드웨어 수준에서 정당한 Google 기기인지 안전하게 식별하고 인증할 수 있습니다.

안전한 부팅 스택 및 머신 ID

Google 서버 머신은 올바른 소프트웨어 스택을 부팅하고 있는지 확인하기 위해 다양한 기술을 사용합니다. BIOS, 부트로더, 커널, 기본 운영체제 이미지와 같은 하위 수준의 요소에 암호화 서명을 사용합니다. 부팅 또는 업데이트할 때마다 이러한 서명이 검증될 수 있습니다. 이러한 요소는 전적으로 Google에서 제어하고 구축 및 강화합니다. Google은 새로운 세대의 하드웨어마다 지속적으로 보안을 개선하기 위해 최선을 다하고 있습니다. 예를 들어 서버 설계 세대에 따라 잠글 수 있는 펌웨어 칩, Google에서 작성한 보안 코드를 실행하는 마이크로 컨트롤러 또는 위에서 언급한 Google에서 설계한 보안 칩에서 부팅 체인의 신뢰 기반을 구축합니다.

데이터 센터의 각 서버 머신에는 하드웨어 신뢰 기반 및 머신이 부팅되는 소프트웨어에 연결될 수 있는 특정 자체 ID가 있습니다. 이 ID는 머신에서 하위 수준 관리 서비스와의 API 호출을 인증하는 데 사용됩니다.

Google은 서버에서 서버 패치를 포함한 최신 버전의 소프트웨어 스택을 실행하고, 하드웨어와 소프트웨어 문제를 감지 및 진단하고, 필요한 경우 서비스에서 머신을 삭제할 수 있도록 자동화 시스템을 제작했습니다.

안전한 서비스 배포

이제 기본 하드웨어 및 소프트웨어를 통해 Google 인프라에 서비스가 안전하게 배포될 수 있도록 하는 방법을 설명해 보겠습니다. '서비스'란 개발자가 작성하여 Google 인프라에서 실행할 애플리케이션 바이너리를 의미합니다. 예를 들어 Gmail SMTP 서버, Bigtable 저장소 서버, YouTube 동영상 트랜스코더 또는 커스텀 애플리케이션을 실행하는 App Engine 샌드박스 등이 있습니다. 필요한 작업 규모를 처리하기 위해 동일한 서비스의 사본을 실행하는 수천 개의 머신이 있을 수 있습니다. 인프라에서 실행되는 서비스는 Borg라는 클러스터 조정 서비스가 제어합니다.

이 섹션에서 볼 수 있듯이 인프라는 인프라에서 실행 중인 서비스 간에 신뢰가 있다고 가정하지 않습니다. 즉, 인프라는 기본적으로 다중 테넌트로 설계되어 있습니다.

서비스 ID, 무결성, 격리

Google은 서비스 간 통신을 위해 애플리케이션 레이어에서 암호화 인증 및 승인을 사용합니다. 이 방식은 관리자와 서비스가 자연스럽게 이해할 수 있는 추상화 수준 및 세분성으로 강력한 액세스 제어를 제공합니다.

Google은 내부 네트워크 세분화나 방화벽을 기본 보안 메커니즘으로 사용하지 않지만 네트워크의 다양한 지점에서 수신 및 송신 필터링을 사용하여 추가 보안 레이어로 IP 위장을 방지합니다. 이 방식은 네트워크의 성능 및 가용성을 극대화하는 데도 도움이 됩니다.

인프라에서 실행하는 각 서비스에는 연결된 서비스 계정 ID가 있습니다. 다른 서비스에 원격 절차 호출(RPC)을 보내거나 받을 때 ID를 증명하는 데 사용할 수 있는 암호화 사용자 인증 정보가 서비스에 제공됩니다. 이러한 ID를 사용하여 클라이언트에서 의도한 올바른 서버와 통신 중인지 확인하고 서버에서 메소드와 데이터에 대한 액세스를 특정 클라이언트로 제한할 수 있습니다.

Google의 소스 코드는 서비스의 현재 및 이전 버전을 모두 감사할 수 있는 중앙 저장소에 저장됩니다. 검토, 확인, 테스트를 거친 특정 소스 코드에서 서비스의 바이너리를 제작하도록 인프라를 추가로 구성할 수 있습니다. 코드 검토 시 작성자 외의 엔지니어 1명 이상이 검사 및 승인해야 하며, 해당 시스템의 소유자가 시스템에 대한 코드 수정을 실행하는 시스템을 승인해야 합니다. 이러한 요구사항은 내부자나 공격자가 소스 코드를 악의적으로 수정하는 것을 제한하는 것은 물론 서비스 이면에서부터 소스에 이르기까지 범죄 과학 수사에 사용할 수 있는 흔적을 제공합니다.

Google은 동일한 머신에서 실행되는 다른 서비스로부터 서비스를 보호하기 위해 다양한 격리 및 샌드박스 기술을 보유하고 있습니다. 이러한 기술로는 일반 Linux 사용자 분리, 언어 및 커널 기반 샌드박스, 하드웨어 가상화가 있습니다. 대개 위험도가 높은 작업에 더 많은 격리 레이어를 사용합니다. 사용자가 제공한 데이터에 복잡한 파일 형식 변환기를 실행하는 경우나 Google App Engine 또는 Google Compute Engine과 같은 제품에 사용자가 제공한 코드를 실행하는 경우를 예로 들 수 있습니다. 보안 경계를 강화하기 위해 Google은 클러스터 조정 서비스 및 일부 키 관리 서비스와 같은 매우 민감한 서비스를 전용 머신에서만 단독으로 실행하도록 사용 설정합니다.

서비스 간 액세스 관리

서비스의 소유자는 인프라에서 제공하는 액세스 관리 기능을 사용하여 통신 가능한 다른 서비스를 정확히 지정할 수 있습니다. 예를 들어 서비스에서 다른 서비스의 특정 허용 목록에만 일부 API를 제공하고자 할 수 있습니다. 허용된 서비스 계정 ID의 허용 목록으로 서비스를 구성할 수 있으며 그러면 인프라가 이 액세스 제한사항을 자동으로 적용합니다.

서비스에 액세스하는 Google 엔지니어도 개별 ID가 발급되므로 서비스에서 엔지니어의 액세스를 허용하거나 거부하도록 비슷하게 구성할 수 있습니다. 이러한 모든 유형의 ID(머신, 서비스, 직원)는 인프라가 유지관리하는 글로벌 네임스페이스에 보관됩니다. 이 문서의 뒷부분에 설명된 것과 같이 최종 사용자 ID는 별도로 취급됩니다.

인프라는 이러한 내부 ID에 승인 체인, 로깅, 알림 등의 풍부한 ID 관리 워크플로 시스템을 제공합니다. 예를 들어 두 당사자 간의 제어를 허용하는 시스템을 통해 제어 그룹에 액세스할 수 있도록 ID를 할당할 수 있습니다. 한 엔지니어가 그룹의 관리자이기도 한 다른 엔지니어에게 승인을 받아야 하는 그룹 변경사항을 제안하는 경우가 이에 해당합니다. 이러한 시스템을 사용하면 안전한 액세스 관리 프로세스가 인프라에서 실행되는 수천 개의 서비스로 확장될 수 있습니다.

자동 API 수준 액세스 제어 메커니즘 외에도 필요한 경우 세밀한 자체 커스텀 액세스 제어를 구현할 수 있도록 인프라가 중앙 ACL에서 읽고 데이터베이스를 그룹화할 수 있는 기능을 서비스에 제공합니다.

서비스 간 통신 암호화

이전 섹션에서 설명한 RPC 인증 및 승인 기능 외에도 인프라는 네트워크의 RPC 데이터에 대한 암호화 개인정보 보호 및 무결성을 제공합니다. HTTP와 같은 다른 애플리케이션 레이어 프로토콜에 이러한 보안 이점을 제공하기 위해 인프라 RPC 메커니즘 내부에 캡슐화합니다. 본질적으로 이를 통해 애플리케이션 레이어 격리를 제공하고 네트워크 경로의 보안에서 모든 종속 항목을 삭제합니다. 네트워크가 도청되거나 네트워크 기기가 도용된 경우에도 암호화된 서비스 간 통신이 안전하게 유지될 수 있습니다.

서비스는 각 인프라 RPC에 사용할 암호화 보호의 수준(예: 데이터 센터 내부에 있는 가치가 낮은 데이터에 무결성 수준의 보호만 구성)을 구성할 수 있습니다. 비공개 WAN 링크를 도청하려고 시도하는 높은 수준의 공격자로부터 보호하기 위해 서비스에서 명시적으로 구성할 필요 없이 인프라가 데이터 센터 간에 WAN을 통해 전송되는 모든 인프라 RPC 트래픽을 자동으로 암호화합니다. Google에서 이러한 기본 암호화를 Google 데이터 센터 내부의 모든 인프라 RPC 트래픽으로 확대하는 하드웨어 암호화 가속기를 배포하기 시작했습니다.

최종 사용자 데이터의 액세스 관리

일반적인 Google 서비스는 최종 사용자와 관련된 작업을 하도록 작성됩니다. 예를 들어 최종 사용자가 Gmail에 이메일을 저장할 수 있습니다. Gmail과 같은 애플리케이션과의 최종 사용자 상호작용이 인프라 내의 다른 서비스로 이어집니다. 따라서 이 예에서 Gmail 서비스가 연락처 서비스에서 제공하는 API를 호출하여 최종 사용자의 주소록에 액세스할 수 있습니다.

이전 섹션에서 연락처 서비스에서 허용할 다른 특정 서비스나 Gmail 서비스의 RPC 요청만 허용하도록 연락처 서비스를 구성할 수 있다는 것을 확인했습니다.

하지만 여전히 권한 모음이 매우 광범위합니다. 이 권한 범위 내에서는 Gmail 서비스가 언제든지 모든 사용자의 연락처를 요청할 수 있습니다.

Gmail 서비스가 특정 최종 사용자를 대신하여 연락처 서비스에 RPC 요청을 하는 것이므로 인프라가 RPC의 일부로 '최종 사용자 권한 티켓'을 제시할 수 있는 기능을 Gmail 서비스에 제공합니다. 이 티켓은 Gmail 서비스가 현재 특정 최종 사용자를 대신하여 요청하고 있음을 증명합니다. 이 방식을 통해 연락처 서비스가 티켓에 지정된 최종 사용자의 데이터만 반환하는 보호 수단을 구현할 수 있습니다.

인프라가 이러한 '최종 사용자 권한 티켓'을 발급하는 중앙 사용자 ID 서비스를 제공합니다. 중앙 ID 서비스가 최종 사용자 로그인을 검증한 다음 쿠키나 OAuth 토큰과 같은 사용자 인증 정보를 사용자의 클라이언트 기기에 발급합니다. 클라이언트 기기에서 Google로 보내는 모든 후속 요청에서 이 사용자 인증 정보를 제시해야 합니다.

서비스가 최종 사용자 인증 정보를 수신하면 검증을 위해 중앙 ID 서비스에 사용자 인증 정보를 전달합니다. 최종 사용자 인증 정보가 올바르게 검증되면 중앙 ID 서비스가 요청과 관련된 RPC에 사용할 수 있는 단기 '최종 사용자 권한 티켓'을 반환합니다. 이 문서의 예에서는 '최종 사용자 권한 티켓'을 가져오는 서비스가 Gmail 서비스이며 연락처 서비스에 전달합니다. 이 시점부터 모든 연속 호출에서 RPC 호출의 일부로 호출자에 서비스를 호출하여 '최종 사용자 권한 티켓'을 전달할 수 있습니다.

서비스 ID 및 액세스 관리: 인프라가 서비스 ID, 자동 상호 인증, 암호화된 서비스 간 통신, 서비스 소유자가 정의한 액세스 정책 적용 등의 기능을 제공합니다.

안전한 데이터 저장소

지금까지 서비스를 안전하게 배포하는 방법을 설명했습니다. 이제 인프라에서 안전한 데이터 저장소를 구현하는 방법을 설명해 보겠습니다.

미사용 데이터 암호화

Google 인프라는 Bigtable 및 Spanner와 같은 다양한 저장소 서비스와 중앙 키 관리 서비스를 제공합니다. Google에 있는 대부분의 애플리케이션은 이러한 저장소 서비스를 통해 간접적으로 물리적 저장소에 액세스합니다. 물리적 저장소에 데이터를 쓰기 전에 중앙 키 관리 서비스의 키로 데이터를 암호화하도록 저장소 서비스를 구성할 수 있습니다. 키 관리 서비스는 자동 키 순환을 지원하고, 광범위한 감사 로그를 제공하며, 앞에서 언급한 최종 사용자 권한 티켓과 통합하여 키를 특정 최종 사용자와 연결합니다.

애플리케이션 레이어에서 암호화를 수행하면 저장소의 하위 수준에서 악의적인 디스크 펌웨어 등의 잠재적인 위험으로부터 인프라를 격리할 수 있습니다. 즉, 인프라가 보안의 추가 레이어도 구현합니다. Google은 하드 드라이브와 SSD에서 하드웨어 암호화 지원을 사용 설정하고 수명 주기 내내 각 드라이브를 세심하게 추적합니다. 폐기된 암호화 저장소 기기를 데이터 센터에서 물리적으로 반출하기 전에 독립적인 검증 절차 2가지를 포함하여 여러 단계의 절차를 통해 데이터를 완전히 삭제합니다. 완전 삭제 절차를 통과하지 못한 기기는 데이터 센터 내부에서 물리적으로 파손(예: 분쇄)됩니다.

데이터 삭제

Google의 데이터 삭제는 대부분 실제로 데이터를 완전히 삭제하는 것보다는 특정 데이터를 '삭제 예약됨'으로 표시하는 것으로 시작됩니다. 그러면 고객이 시작한 절차인지 아니면 내부 버그 또는 처리 오류로 인한 것인지에 관계없이 의도하지 않은 삭제로부터 복구할 수 있습니다. '삭제 예약됨'으로 표시된 후 서비스별 정책에 따라 데이터가 삭제됩니다.

최종 사용자가 전체 계정을 삭제하면 인프라에서 계정이 삭제된 최종 사용자 데이터를 취급하는 서비스에 알립니다. 그러면 서비스가 삭제된 최종 사용자 계정에 연결된 데이터의 삭제를 예약할 수 있습니다. 이 기능을 사용하면 서비스 개발자가 손쉽게 최종 사용자 제어를 구현할 수 있습니다.

안전한 인터넷 통신

이 문서에서 지금까지 인프라의 서비스에 보안을 적용하는 방법을 설명했습니다. 이 섹션에서는 인터넷 및 서비스 간의 통신에 보안을 적용하는 방법을 설명합니다.

앞에서 설명한 것과 같이 인프라는 LAN 및 WAN을 통해 상호 연결된 여러 물리적 머신의 모음으로 구성되며 서비스 간의 통신 보안은 네트워크 보안에 의존하지 않습니다. 하지만 서비스 거부(DoS) 공격에 대한 방어와 같이 추가 보호를 보다 쉽게 구현할 수 있도록 Google은 머신의 하위 집합만 외부 인터넷 트래픽에 직접 노출하는 방식으로 인프라를 인터넷에서 비공개 IP 공간으로 격리합니다.

Google 프런트 엔드 서비스

서비스 자체를 인터넷에서 사용할 수 있게 하려면 Google 프런트 엔드(GFE)라는 인프라 서비스로 등록하면 됩니다. GFE가 올바른 인증서를 사용하고 권장사항(예: PFS(Perfect Forward Secrecy) 지원)에 따라 모든 TLS 연결이 종료되도록 합니다. 또한 GFE가 서비스 거부 공격에 대한 보호를 적용하며 자세한 내용은 뒷부분에 안내되어 있습니다. 그런 다음 GFE가 앞에서 설명한 RPC 보안 프로토콜을 사용하여 서비스에 대한 요청을 전달합니다.

실제로 외부에 서비스를 게시하도록 선택한 내부 서비스는 GFE를 역 프록시 방식의 스마트 프런트 엔드로 사용합니다. 이 프런트 엔드는 공개 DNS 이름의 공개 IP 호스팅, 서비스 거부(DoS) 보호, TLS 종료를 제공합니다. GFE는 다른 서비스와 마찬가지로 인프라에서 실행되므로 수신 요청 크기에 맞게 확장할 수 있습니다.

서비스 거부(DoS) 보호

Google 인프라의 엄청난 규모로 인해 여러 DoS 공격을 간단하게 흡수할 수 있습니다. 즉, Google은 GFE 뒤에서 실행되는 서비스에 DoS가 영향을 미칠 위험을 더 줄이는 다중 계층의 다중 레이어 DoS 보호를 갖추고 있습니다.

백본에서 데이터 센터 중 한 곳에 외부 연결을 전달한 후 여러 레이어의 하드웨어 및 소프트웨어 부하 분산을 거칩니다. 이러한 부하 분산기가 인프라에서 실행되는 중앙 DoS 서비스에 수신 트래픽에 대한 정보를 보고합니다. 중앙 DoS 서비스가 DoS 공격이 진행 중임을 감지하면 부하 분산기를 구성하여 공격과 관련된 트래픽을 끊거나 제한할 수 있습니다.

또한 다음 레이어에서 GFE 인스턴스가 부하 분산기에 없는 애플리케이션 레이어 정보를 포함하여 수신 중인 요청에 대한 정보를 중앙 DoS 서비스에 보고할 수 있습니다. 그러면 중앙 DoS 서비스가 GFE 인스턴스를 구성하여 공격 트래픽을 끊거나 제한할 수도 있습니다.

사용자 인증

DoS 보호 이후에는 중앙 ID 서비스가 보안의 다음 레이어를 제공합니다. 이 서비스는 대개 최종 사용자에게는 Google 로그인 페이지로 나타납니다. 간단한 사용자 이름 및 비밀번호 요청 외에도 이전과 동일한 기기나 비슷한 위치에서 로그인했는지 여부와 같은 위험 요소를 기준으로 서비스가 지능적으로 사용자에게 추가 정보를 요청할 수도 있습니다. 사용자 인증 후 ID 서비스가 쿠키 및 OAuth 토큰과 같이 후속 호출에 사용할 수 있는 사용자 인증 정보를 발급합니다.

사용자가 로그인할 때 OTP 또는 피싱 방지 보안 키와 같은 2단계 인증도 사용할 수 있습니다. Google 단독으로 제공 가능한 것 이상의 이점을 제공하기 위해 Google은 여러 기기 공급업체가 포함된 FIDO Alliance와 협력하여 범용 2단계 인증(U2F) 개방형 표준을 개발했습니다. 현재 이러한 기기가 시판되고 있으며 다른 주요 웹 서비스도 Google을 따라 U2F 지원을 구현했습니다.

운영 보안

지금까지 인프라에서 보안이 어떻게 설계되어 있는지 설명하고 RPC의 액세스 제어와 같은 안전한 작업의 몇 가지 메커니즘도 설명했습니다.

이제 Google에서 인프라를 실제로 어떻게 안전하게 운영하는지 설명해 보겠습니다. Google은 인프라 소프트웨어를 안전하게 만들며, Google 직원의 머신 및 사용자 인증 정보를 보호하고, 내부자 및 외부 행위자의 인프라에 대한 위협으로부터 방어합니다.

안전한 소프트웨어 개발

앞에서 설명한 중앙 소스 제어 및 두 당사자 간의 검토 기능 외에도 개발자가 특정 보안 버그 클래스를 도입하는 것을 방지하는 라이브러리를 제공합니다. 예를 들어 웹 앱에서 XSS 취약점을 제거하는 라이브러리와 프레임워크가 있습니다. 또한 퍼징 도구, 정적 분석 도구, 웹 보안 스캐너 등 자동으로 보안 버그를 감지하기 위한 자동화 도구도 있습니다.

최종 확인으로는 위험도가 낮은 기능에 대한 신속한 심사에서부터 위험도가 가장 높은 기능에 대한 심층 설계 및 구현 검토에 이르기까지 수동 보안 검토를 사용합니다. 웹 보안, 암호화, 운영체제 보안에 대한 전문가가 포함된 팀에서 이러한 검토를 수행합니다. 또한 검토를 통해 새 보안 라이브러리 기능 및 퍼징 도구가 이후 다른 제품에 적용될 수 있습니다.

이 외에도 취약점 리워드 프로그램을 운영하여 Google 인프라나 애플리케이션의 버그를 발견하고 알린 사람에게 리워드를 지급합니다. 이 프로그램에서 리워드로 수백만 달러를 지급했습니다.

또한 Google은 Google에서 사용하는 모든 오픈소스 소프트웨어에서 제로데이 악용 및 기타 보안 문제를 찾고 이러한 문제를 업스트림하기 위해 많은 노력을 기울이고 있습니다. 예를 들어 Google에서 OpenSSL Heartbleed 버그를 찾았으며 Google은 CVE 및 Linux KVM 하이퍼바이저의 보안 버그 수정을 다량으로 제출해 왔습니다.

직원 기기 및 사용자 인증정보를 안전하게 유지

Google은 직원 기기 및 사용자 인증 정보가 도용되지 않도록 보호하는 것은 물론 활동을 모니터링하여 잠재적인 도용 또는 불법 내부자 활동을 찾기 위해 막대한 투자를 하고 있습니다. 이러한 투자는 인프라를 안전하게 운영하기 위한 투자에서 중요한 부분을 차지합니다.

정교한 피싱은 집요하게 Google 직원을 대상으로 하고 있습니다. 이러한 위협으로부터 방어하기 위해 직원 계정에서 피싱 가능한 OTP 2단계 인증 방식을 U2F 호환 보안 키를 필수적으로 사용하는 방식으로 바꿨습니다.

Google은 직원이 인프라를 운영하는 데 사용하는 클라이언트 기기를 모니터링하는 데 많은 투자를 하며, 이러한 클라이언트 기기의 운영체제 이미지가 보안 패치가 적용된 최신 상태인지 확인하고 설치 가능한 애플리케이션을 제어합니다. 또한 사용자가 설치한 앱, 다운로드, 브라우저 확장 프로그램, 웹에서 탐색한 콘텐츠가 기업 클라이언트에 적합한지 스캔하는 시스템이 있습니다.

기업 LAN에 있다고 해서 액세스 권한을 부여하는 것은 Google의 기본 메커니즘이 아닙니다. Google은 특정 사용자가 올바르게 관리되는 기기 및 예상 네트워크와 지리적 위치에서 접속하는 경우에 내부 애플리케이션을 해당 사용자에게만 노출할 수 있는 애플리케이션 수준의 액세스 관리 제어를 사용합니다. 자세한 내용은 'BeyondCorp'에 대한 추가 자료를 참조하세요.

내부자 위험 감소

Google은 인프라에 대한 관리자 액세스 권한이 부여된 직원의 활동을 공격적으로 제한하고 적극적으로 모니터링하며, 지속적으로 안전하고 제어되는 방식으로 동일한 작업을 수행할 수 있는 자동화 기능을 제공하여 특정 작업에 액세스 권한을 부여할 필요가 없도록 지속적으로 작업하고 있습니다. 여기에는 일부 작업에 두 당사자 간의 승인을 요구하는 것과 민감한 정보를 노출하지 않고 디버깅할 수 있는 제한된 API를 도입하는 것이 포함됩니다.

최종 사용자 정보에 액세스하는 Google 직원은 하위 수준 인프라 후크를 통해 로깅될 수 있습니다. Google 보안팀이 액세스 패턴을 적극적으로 모니터링하고 비정상적인 이벤트를 조사합니다.

침입 감지

Google에는 개별 기기의 호스트 기반 신호, 인프라의 다양한 지점에서 발생한 네트워크 기반 신호, 인프라 서비스의 신호를 통합하는 정교한 데이터 처리 파이프라인이 있습니다. 이러한 파이프라인을 바탕으로 구축한 규칙 및 인공 지능이 운영 보안 엔지니어에게 가능한 이슈에 대한 경고를 제공합니다. Google의 조사 및 이슈 대응팀이 연중무휴 24시간 이러한 잠재적인 이슈를 심사 및 조사하고 대응합니다. Google은 레드팀 훈련을 통해 탐지 및 대응 메커니즘의 효율성을 측정하고 개선합니다.

Google Cloud Platform(GCP) 보안

이 섹션에서는 Google 공용 클라우드 인프라인 GCP가 기본 인프라의 보안 이점을 어떻게 활용하는지 강조하여 보여줍니다. Google Compute Engine을 이 섹션의 서비스 예로 사용하여 인프라를 바탕으로 구축하는 서비스별 보안 개선사항을 자세히 설명합니다.

Compute Engine을 사용하면 고객이 Google 인프라에서 자체 가상 머신을 실행할 수 있습니다. Compute Engine 구현은 특히 관리 제어부 및 가상 머신 자체 등 여러 논리적 요소로 구성됩니다.

관리 제어부는 외부 API 표면을 노출하고 가상 머신 생성 및 이전과 같은 작업을 조정합니다. 인프라에서 다양한 서비스를 실행하므로 자동으로 보안 부팅 체인과 같은 기본 무결성 기능이 제공됩니다. 개별 서비스가 확실한 내부 서비스 계정에서 실행되므로 나머지 제어부에 원격 절차 호출(RPC)을 할 때 모든 서비스에 필요한 권한만 부여할 수 있습니다. 앞에서 설명한 것처럼 이러한 모든 서비스의 코드가 Google 중앙 소스 코드 저장소에 저장되며 이 코드와 최종 배포되는 바이너리 간에 감사 추적이 있습니다.

Compute Engine 제어부는 GFE를 통해 API를 노출하므로 서비스 거부(DoS) 보호와 같은 인프라 보안 기능 및 중앙 관리형 SSL/TLS 지원을 활용할 수 있습니다. 고객은 선택에 따라 GFE를 바탕으로 구축된 Google Cloud 부하 분산기 서비스를 사용하여 Compute Engine VM에서 실행 중인 애플리케이션에 비슷한 보호를 적용할 수 있으며 다양한 유형의 DoS 공격을 완화할 수 있습니다.

Compute Engine 제어부 API에 대한 최종 사용자 인증은 도용 감지 등의 보안 기능을 제공하는 Google의 중앙 ID 서비스를 통해 이루어집니다. 승인은 중앙 Cloud IAM 서비스를 사용하여 진행됩니다.

GFE에서 GFE 뒤에 있는 첫 번째 서비스로 전송되는 트래픽과 다른 제어부 서비스 간에 전송되는 트래픽을 모두 포함하여 제어부의 네트워크 트래픽은 자동으로 인프라에 의해 인증되고 한 데이터 센터에서 다른 데이터 센터로 이동할 때마다 암호화됩니다. 또한 데이터 센터 내의 일부 제어부 트래픽도 암호화하도록 인프라가 구성되어 있습니다.

각 가상 머신(VM)은 연결된 가상 머신 관리자(VMM) 서비스 인스턴스로 실행됩니다. 인프라가 이러한 서비스에 2가지 ID를 제공합니다. 한 ID는 자체 호출을 위해 VMM 서비스 인스턴스에서 사용되고 다른 ID는 VMM에서 고객의 VM을 대신하여 호출하는 데 사용됩니다. 이를 통해 VMM에서 보내는 호출에 대한 신뢰를 더 세분화할 수 있습니다.

Compute Engine 영구 디스크는 미사용 시 중앙 인프라 키 관리 시스템에서 보호하는 키를 사용하여 암호화됩니다. 그러면 자동화된 순환이 가능해지고 이러한 키에 대한 액세스를 중앙에서 감사할 수 있습니다.

현재 고객은 고객 VM에서 다른 VM이나 위험 요소가 없는 인터넷으로 트래픽을 보낼지, 아니면 이 트래픽에 원하는 암호화를 구현할지 선택할 수 있습니다. Google은 VM 트래픽으로 전달되는 고객 VM의 WAN 통과 호프에 대한 자동 암호화를 점진적으로 적용하고 있습니다. 앞에서 설명한 것처럼 인프라 내의 모든 제어부 WAN 트래픽은 이미 암호화되어 있습니다. 앞으로 데이터 센터 내의 VM LAN 간 트래픽도 암호화하기 위해 앞에서 설명한 하드웨어 가속 네트워크 암호화를 활용할 예정입니다.

VM에 제공되는 격리는 오픈소스 KVM 스택을 사용하는 하드웨어 가상화를 기반으로 합니다. 일부 제어 및 하드웨어 에뮬레이션 스택을 커널 외부의 권한이 없는 프로세스로 이전하여 특정 KVM 구현을 더욱 강화했습니다. 또한 퍼징, 정적 분석, 수동 코드 검토와 같은 기술을 사용하여 KVM의 코어를 광범위하게 테스트했습니다. 앞에서 언급한 것처럼 최근에 KVM에 업스트림된 공개된 취약점의 대부분은 Google에서 공개한 것입니다.

마지막으로, Google 운영 보안 제어는 데이터에 대한 액세스가 정책을 준수하는지 확인하는 데 있어 핵심적인 부분입니다. Google Cloud Platform의 일부인 Compute Engine에서 고객 데이터를 사용할 때 GCP 고객 데이터 사용 정책을 따릅니다. 즉, 고객에게 서비스를 제공하는 데 필요한 경우를 제외하고는 Google에서 고객 데이터에 액세스하거나 이러한 데이터를 사용하지 않습니다.

결론

지금까지 인터넷 규모에서 안전하게 서비스를 구축, 배포, 운영하기 위해 Google 인프라가 어떻게 설계되어 있는지 설명했습니다. 여기에는 Gmail과 같은 소비자 서비스와 기업용 서비스가 둘 다 포함됩니다. Google Cloud에서 제공하는 서비스도 동일한 인프라를 토대로 구축되었습니다.

Google은 인프라 보호에 막대하게 투자하고 있습니다. 수백 명의 엔지니어가 모든 Google 서비스에 분산되어 있는 보안 및 개인정보 보호를 전담하며 이 중 다수가 업계에서 인정을 받는 보안 권위자입니다.

앞에서 확인한 것처럼 인프라의 보안은 물리적 요소 및 데이터 센터에서부터 하드웨어 출처, 안전한 부팅, 안전한 서비스 간 통신, 미사용 데이터 보안 적용, 인터넷에서의 서비스 액세스 보호, 운영 보안을 위해 Google에서 배포하는 기술 및 인력 프로세스에 이르기까지 여러 레이어로 설계되어 있습니다.

추가 자료

특정 분야에 대한 자세한 내용은 다음 문서를 참조하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...