Google 인프라 보안 설계 개요

이 콘텐츠는 2024년 6월에 마지막으로 업데이트되었으며 작성된 당시의 상황을 나타냅니다. Google의 보안 정책 및 시스템은 고객 보호를 지속적으로 개선함에 따라 앞으로도 계속 변경될 수 있습니다.

소개

이 문서에서는 Google 기술 인프라에서 보안이 어떻게 설계되어 있는지를 개략적으로 설명합니다. 이 문서는 보안 책임자, 보안 설계자, 감사관을 대상으로 합니다.

이 문서에서는 다음을 설명합니다.

  • Google의 글로벌 기술 인프라는 Google의 정보 처리 수명 주기 전체를 통틀어 보안을 제공하도록 설계되어 있습니다. 이 인프라는 다음을 제공하는 데 도움이 됩니다.
    • 안전한 서비스 배포
    • 최종 사용자 개인 정보 보호 장치가 적용된 안전한 데이터 스토리지
    • 서비스 간 보안 통신
    • 인터넷을 통한 고객과의 안전한 비공개 통신
    • Google 엔지니어의 안전한 운영
  • 이 인프라를 사용하여 Google 검색, Gmail, Google 포토와 같은 인터넷 서비스와 Google Workspace, Google Cloud와 같은 기업용 서비스를 구축하는 방법
  • Google의 보안 요구사항을 충족하기 위해 내부에서 구현한 혁신의 결과로 생성된 보안 제품 및 서비스. 예를 들어 BeyondCorp는 제로 트러스트 보안 모델 내부 구현의 직접적인 결과입니다.

  • 인프라의 보안이 점진적 레이어에서 설계되는 방식입니다. 이러한 레이어에는 다음이 포함됩니다.

이 문서의 나머지 섹션에서는 보안 레이어를 설명합니다.

하위 수준의 보안 인프라

이 섹션에서는 데이터 센터의 실제 데이터 센터, 데이터 센터의 하드웨어, 하드웨어에서 실행되는 소프트웨어 스택을 보호하는 방법을 설명합니다.

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

Google에서는 자체 데이터 센터를 설계 및 구축하여 물리적 보안의 여러 레이어를 통합합니다. 이러한 데이터 센터에 대한 액세스는 엄격하게 제어됩니다. Google에서는 데이터 센터 층을 보호하기 위해 여러 물리적인 보안 레이어를 사용합니다. Google에서는 생체 정보 식별, 금속 탐지, 카메라, 차량 방지 장벽, 레이저 기반의 침입 감지 시스템을 사용합니다. 자세한 내용은 데이터 센터 보안을 참조하세요.

데이터 센터 내부에서는 서버에 대한 물리적 접근을 보호하고 감시하는 추가적인 통제를 시행합니다. 자세한 내용은 Google이 데이터 센터에서 물리적-논리적 공간을 보호하는 방법을 참조하세요.

또한 타사 데이터 센터에 일부 서버를 호스팅합니다. 이러한 데이터 센터는 자체 데이터 센터와 동일한 규제 표준을 준수합니다. Google은 데이터 센터 운영업체가 제공하는 보안 계층에 더하여 Google이 통제하는 물리적 보안 조치와 Google이 통제하는 연결을 보장합니다. 예를 들어 Google에서는 데이터 센터 운영업체가 제공하는 보안 계층에 의존하지 않는 생체 인식 시스템, 카메라, 금속 탐지기를 운영합니다.

별도로 명시되지 않는 한 이 문서의 보안 통제는 Google 소유 데이터 센터와 서드 파티 데이터 센터에 모두 적용됩니다.

하드웨어 설계 및 출처

Google 데이터 센터는 로컬 네트워크에 연결되는 수천 대의 서버로 구성됩니다. 서버 보드 및 네트워킹 장비를 설계합니다. Google에서는 함께 작업할 구성요소 공급업체를 심사한 후 신중하게 구성요소를 선택합니다. Google에서는 공급업체와 협력하여 구성요소가 제공하는 보안 속성을 감사하고 검증합니다. 또한 서버, 기기, 주변기기에 배포되는 하드웨어 보안 칩(Titan이라고 함)을 포함한 커스텀 칩을 설계합니다. 이러한 칩을 통해 하드웨어 수준에서 적법한 Google 기기를 식별 및 인증하고 신뢰할 수 있는 하드웨어 루트 역할을 할 수 있습니다.

안전한 부팅 스택 및 머신 ID

Google 서버는 의도한 소프트웨어 스택을 부팅하기 위해 다양한 기술을 사용합니다. 부팅 프로세스의 각 단계에서 Google은 기대하는 부팅 상태를 시행하고 고객 데이터를 보호하는 데 도움이 되도록 업계 최고의 제어를 구현합니다.

Google은 하드웨어의 발전 동향에 발맞춰 서버를 지속적으로 개선하고 신뢰 컴퓨팅 그룹 및 DMTF의 표준 프로세스에 참여하여 업계 전반에서 이러한 개선의 혜택을 누리도록 노력합니다.

데이터 센터의 각 서버에는 고유한 ID가 있습니다. 이 ID는 신뢰할 수 있는 하드웨어 루트와 머신이 부팅되는 소프트웨어에 연결될 수 있습니다. 이 ID는 머신에서 하위 수준 관리 서비스와의 API 호출을 인증하는 데 사용됩니다. 이 ID는 상호 서버 인증 및 전송 암호화에도 사용됩니다. Google에서는 인프라 내에서 리모트 프러시저 콜(RPC) 통신의 보안을 유지하기 위해 애플리케이션 레이어 전송 보안(ALTS) 시스템을 개발했습니다. 이러한 머신 ID를 중앙에서 취소하여 보안 이슈에 대응할 수 있습니다. 또한 인증서와 키가 정기적으로 순환되고 이전 인증서는 취소됩니다.

Google에서는 다음을 수행하도록 자동화된 시스템을 개발했습니다.

  • 서버가 소프트웨어 스택의 최신 버전(보안 패치 포함)을 실행하는지 확인합니다.
  • 하드웨어 및 소프트웨어 문제를 감지하고 진단합니다.
  • 자체 검사 부팅 및 증명으로 머신과 주변기기의 무결성을 확인합니다.
  • 의도한 소프트웨어 및 펌웨어를 실행하는 머신만 프로덕션 네트워크에서 통신할 수 있도록 사용자 인증 정보에 액세스할 수 있는지 확인합니다.
  • 무결성 검사에 실패하거나 더 이상 필요하지 않은 머신을 제거하거나 수리합니다.

부팅 스택 및 머신 무결성을 보호하는 방법에 대한 자세한 내용은 Google이 프로덕션 머신에서 부팅 무결성을 적용하는 방법 및 분리형 머신의 원격 증명을 참조하세요.

안전한 서비스 배포

Google 서비스는 개발자가 Google 인프라에서 작성하고 실행하는 애플리케이션 바이너리입니다. Google 서비스의 예시로는 Gmail 서버, Spanner 데이터베이스, Cloud Storage 서버, YouTube 동영상 트랜스코더, 고객 애플리케이션을 실행하는 Compute Engine VM이 있습니다. 필요한 워크로드 규모를 처리하기 위해 수천 개의 머신이 동일한 서비스의 바이너리를 실행할 수 있습니다. Borg라는 클러스터 조정 서비스는 인프라에서 직접 실행되는 서비스를 제어합니다.

인프라는 인프라에서 실행 중인 서비스 간에 신뢰가 있다고 가정하지 않습니다. 이 신뢰 모델을 제로 트러스트 보안 모델이라고 합니다. 제로 트러스트 보안 모델에서는 네트워크 내부 또는 외부에 상관없이 기본적으로 신뢰할 수 있는 기기 또는 사용자가 없습니다.

인프라는 멀티 테넌트로 설계되었으므로 고객의 데이터(소비자, 비즈니스, 심지어 자체 데이터)도 공유 인프라에 분산됩니다. 이 인프라는 수만 개의 동종 머신으로 구성됩니다. 인프라는 Google Cloud를 사용하여 Compute Engine용 단독 테넌트 노드에 VM을 프로비저닝하는 경우와 같은 특정 경우를 제외하고 고객 데이터를 단일 머신 또는 머신 집합으로 분리하지 않습니다.

Google Cloud 및 Google Workspace는 데이터 상주와 관련된 규정 요구사항을 지원합니다. 데이터 상주 및 Google Cloud에 대한 자세한 내용은 데이터 상주 및 주권 요구사항 구현을 참조하세요. 데이터 상주 및 Google Workspace에 대한 자세한 내용은 데이터 리전: 데이터의 지리적 위치 선택을 참조하세요.

서비스 ID, 무결성, 격리

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

서비스는 내부 네트워크 세분화나 방화벽을 기본 보안 메커니즘으로 사용하지 않습니다. 네트워크의 다양한 지점에서 인그레스 및 이그레스 필터링을 사용하면 IP 스푸핑을 방지할 수 있습니다. 이 방식은 네트워크의 성능 및 가용성을 극대화하는 데도 도움이 됩니다. Google Cloud의 경우 VPC 서비스 제어 및 Cloud Interconnect와 같은 보안 메커니즘을 추가할 수 있습니다.

인프라에서 실행하는 각 서비스에는 연결된 서비스 계정 ID가 있습니다. RPC를 만들거나 수신할 때 다른 서비스에 ID를 증명하는 데 사용할 수 있는 암호화 사용자 인증 정보가 서비스에 제공됩니다. 이러한 ID는 보안 정책에 사용됩니다. 보안 정책은 클라이언트가 의도한 서버와 통신하고 서버가 특정 클라이언트가 액세스할 수 있는 메서드와 데이터를 제한하도록 보장합니다.

Google에서는 동일한 머신에서 실행되는 다른 서비스로부터 서비스를 보호하기 위해 다양한 격리 및 샌드박스 기술을 사용합니다. 이러한 기술로는 Linux 사용자 분리, 언어 기반(예: Sandboxed API), 커널 기반 샌드박스, 컨테이너용 애플리케이션 커널(예: gVisor), 하드웨어 기반 가상화가 있습니다. 일반적으로 위험도가 높은 워크로드에 더 많은 격리 레이어를 사용합니다. 위험도가 더 높은 워크로드에는 인터넷의 미검수 입력을 처리하는 워크로드가 포함됩니다. 위험도가 더 높은 워크로드의 예시로는 신뢰할 수 없는 입력으로 복잡한 파일 변환기를 실행하는 경우 또는 Compute Engine과 같은 제품에 대해 임의 코드를 서비스로 실행하는 경우 등이 있습니다.

보안 강화를 위해 클러스터 조정 서비스 및 일부 키 관리 서비스와 같은 민감한 서비스는 전용 머신에서만 단독으로 실행됩니다.

Google Cloud는 워크로드에 더 강력한 암호화 격리를 제공하고 사용 중 데이터를 보호하기 위해 Compute Engine 가상 머신(VM) 인스턴스 및 Google Kubernetes Engine(GKE) 노드에 컨피덴셜 컴퓨팅 서비스를 지원합니다.

서비스 간 액세스 관리

서비스의 소유자는 서비스와 통신할 수 있는 다른 서비스의 목록을 만들어 액세스를 관리할 수 있습니다. 이 액세스 관리 기능은 Google 인프라에서 제공됩니다. 예를 들어 서비스는 수신 RPC를 다른 서비스의 허용 목록으로만 제한할 수 있습니다. 소유자는 인프라가 자동으로 적용하는 허용 서비스 ID 목록으로 서비스를 구성할 수도 있습니다. 시행에는 감사 로깅, 근거, 일방적인 액세스 제한(예: 엔지니어 요청)이 포함됩니다.

서비스에 액세스해야 하는 Google 엔지니어에게도 개별 ID가 발급됩니다. ID를 기준으로 액세스를 허용하거나 거부하도록 서비스를 구성할 수 있습니다. 이러한 모든 ID(머신, 서비스, 직원)는 인프라가 유지관리하는 글로벌 네임스페이스에 보관됩니다.

이러한 ID를 관리하기 위해 인프라는 승인 체인, 로깅, 알림이 포함된 워크플로 시스템을 제공합니다. 예를 들어 보안 정책은 다자간 승인을 시행할 수 있습니다. 이 시스템은 두 사람 규칙을 사용하여 단독으로 작업하는 엔지니어가 먼저 승인된 다른 엔지니어의 승인을 받기 전에는 민감한 작업을 수행할 수 없습니다. 이러한 시스템을 사용하면 안전한 액세스 관리 프로세스가 인프라에서 실행되는 수천 개의 서비스로 확장될 수 있습니다.

또한 인프라는 사용자, 그룹, 멤버십 관리를 위한 표준 서비스를 제공하여 필요한 경우 세밀한 커스텀 액세스 제어를 구현할 수 있도록 합니다.

최종 사용자 ID는 Google Workspace에서 최종 사용자 데이터의 액세스 관리에 설명된 대로 별도로 관리됩니다.

워크로드 간 통신 암호화

인프라는 네트워크의 RPC 데이터에 대한 기밀성 및 무결성을 제공합니다. 모든 Google Cloud 가상 네트워킹 트래픽은 암호화됩니다. Google Cloud 인프라 워크로드 간의 통신은 암호화되며, 트래픽이 Google 에지의 여러 물리적 보안 레이어를 거치지 않는 고성능 워크로드에만 예외가 적용됩니다. Google Cloud 인프라 서비스 간의 통신에는 암호화 무결성 보호 기능이 있습니다.

하드웨어 오프로드의 도움을 받아 인프라가 자동으로 데이터 센터 간의 네트워크를 통과하는 인프라 RPC 트래픽에 엔드 투 엔드 암호화를 효율적으로 제공합니다.

Google Workspace에서 최종 사용자 데이터의 액세스 관리

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

서비스 간 통신 암호화 섹션에서는 다른 서비스(예: Gmail)의 RPC 요청을 보호하도록 서비스(예: Google 주소록)를 설계하는 방법을 설명합니다. 하지만 Gmail이 언제든지 사용자의 연락처를 요청할 수 있기 때문에 이러한 수준의 액세스 제어는 여전히 광범위한 권한입니다.

Gmail이 최종 사용자를 대신하여 Google 연락처에 RPC 요청을 하는 경우 인프라는 Gmail이 RPC 요청에 최종 사용자 권한 티켓을 전달할 수 있도록 합니다. 이 티켓은 Gmail이 특정 최종 사용자를 대신하여 RPC 요청을 수행하고 있음을 증명합니다. 티켓은 Google 주소록에서 티켓에 이름이 지정된 최종 사용자의 데이터만 반환하도록 보호 장치를 구현할 수 있게 해줍니다.

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

서비스가 최종 사용자 인증 정보를 수신하면 검증을 위해 이 서비스가 ID 서비스에 사용자 인증 정보를 전달합니다. 최종 사용자 인증 정보가 확인되면 ID 서비스는 사용자 요청과 관련된 RPC에 사용할 수 있는 단기 최종 사용자 컨텍스트 티켓을 반환합니다. 이 예시에서 최종 사용자 컨텍스트 티켓을 받는 서비스는 Gmail로, 티켓을 Google 주소록으로 전달합니다. 이 시점부터 모든 연속 호출에서 호출 서비스는 RPC의 일부로 피호출자에 최종 사용자 컨텍스트 티켓을 보낼 수 있습니다.

다음 다이어그램은 서비스 A와 서비스 B가 통신하는 방법을 보여줍니다. 인프라는 서비스 ID, 자동 상호 인증, 암호화된 서비스 간 통신, 서비스 소유자가 정의한 액세스 정책 시행을 제공합니다. 각 서비스에는 서비스 소유자가 만드는 서비스 구성이 있습니다. 암호화된 서비스 간 통신의 경우 자동 상호 인증은 호출자 및 피호출자 ID를 사용합니다. 액세스 규칙 구성에서 허용하는 경우에만 통신이 가능합니다.

서비스 A와 서비스 B가 통신하는 방법을 보여주는 다이어그램

Google Cloud의 액세스 관리에 대한 자세한 내용은 IAM 개요를 참조하세요.

Google Cloud에서 최종 사용자 데이터의 액세스 관리

Google Workspace에서 최종 사용자 데이터의 액세스 관리와 마찬가지로 인프라는 서비스 계정을 인증하고 서비스 계정이 인증된 후 최종 사용자 컨텍스트 티켓을 발급하는 중앙 사용자 ID 서비스를 제공합니다. Google Cloud 서비스 간 액세스 관리는 일반적으로 최종 사용자 컨텍스트 티켓을 사용하는 대신 서비스 에이전트를 통해 수행됩니다.

Google Cloud에서는 IAM(Identity and Access Management)과 IAP(Identity-Aware Proxy)와 같은 컨텍스트 인지 제품을 사용하여 Google Cloud 조직의 리소스 액세스를 관리할 수 있습니다. Google Cloud 서비스에 대한 요청은 IAM을 통해 권한을 확인합니다.

액세스 관리 프로세스는 다음과 같습니다.

  1. 고객 VM의 Google 프런트엔드 서비스 또는 Cloud 프런트엔드 서비스를 통해 요청이 접수됩니다.
  2. 인증 검사를 완료하고 최종 사용자 컨텍스트 티켓을 발급하는 중앙 사용자 ID 서비스로 요청이 라우팅됩니다.
  3. 또한 다음과 같은 항목을 확인하기 위해 요청이 라우팅됩니다.
  4. 이러한 모든 검사를 통과하면 Google Cloud 백엔드 서비스가 호출됩니다.

Google Cloud의 액세스 관리에 대한 자세한 내용은 IAM 개요를 참조하세요.

안전한 데이터 스토리지

이 섹션에서는 인프라에 저장된 데이터의 보안을 구현하는 방법을 설명합니다.

저장 데이터 암호화

Google 인프라는 다양한 스토리지 서비스, 분산 파일 시스템(예: Spanner 및 Colossus), 중앙 키 관리 서비스를 제공합니다. Google의 애플리케이션은 스토리지 인프라를 사용하여 물리적 스토리지에 액세스합니다. Google에서는 여러 암호화 레이어를 사용하여 저장 데이터를 보호합니다. 기본적으로 스토리지 인프라는 사용자 데이터가 물리적 스토리지에 기록되기 전에 사용자 데이터를 암호화합니다.

인프라가 애플리케이션 또는 스토리지 인프라 레이어에서 암호화를 수행합니다. 이 암호화의 키는 Google에서 관리하고 소유합니다. 암호화를 수행하면 스토리지의 하위 수준에서 악의적인 디스크 펌웨어와 같은 잠재적인 위험으로부터 인프라를 격리할 수 있습니다. 해당되는 경우 Google에서는 하드 드라이브와 SSD에서 하드웨어 암호화 지원을 사용 설정하고 수명 주기 내내 각 드라이브를 세심하게 추적합니다. 폐기된 암호화 스토리지 기기를 데이터 센터에서 물리적으로 반출하기 전에 독립적인 검증 절차 2가지를 포함하여 여러 단계의 프로세스를 통해 기기를 정리합니다. 이 정리 프로세스를 통과하지 못한 기기는 온프레미스에서 물리적으로 폐기(즉, 파쇄)됩니다.

Google이 소유하고 관리하는 키로 인프라에서 암호화를 수행할 뿐 아니라 Google Cloud 및 Google Workspace는 사용자가 소유하고 관리할 수 있는 키에 대한 키 관리 서비스를 제공합니다. Google Cloud의 경우 Cloud KMS는 사용자가 하드웨어 기반 FIPS 140-3 L3 인증 키를 포함하여 자체 암호화 키를 만들 수 있는 클라우드 서비스입니다. 이러한 키는 Google Cloud 서비스가 아닌 사용자에게 귀속되며 사용자가 자신의 정책과 절차에 따라 키를 직접 관리할 수 있습니다. Google Workspace의 경우 클라이언트 측 암호화를 사용할 수 있습니다. 자세한 내용은 클라이언트 측 암호화 및 Google Workspace의 강화된 공동작업을 참조하세요.

데이터 삭제

암호화 자료 또는 데이터 삭제는 일반적으로 특정 키 또는 데이터를 삭제 예약됨으로 표시하는 것으로 시작됩니다. 삭제를 위해 데이터를 표시하는 프로세스에는 서비스별 정책과 고객별 정책이 고려됩니다.

우선 데이터를 삭제 예약하거나 키를 사용 중지하는 방식을 사용하면 고객의 실수, 버그 또는 내부 프로세스 오류의 결과에 따른 의도치 않은 삭제로부터 복구할 수 있습니다.

최종 사용자가 계정을 삭제하면 인프라에서 계정이 삭제된 최종 사용자 데이터를 처리하는 서비스에 알립니다. 그러면 서비스는 삭제된 최종 사용자 계정에 연결된 데이터의 삭제를 예약할 수 있습니다. 이 기능을 사용하면 최종 사용자가 자신의 데이터를 제어할 수 있습니다.

자세한 내용은 Google Cloud에서 데이터 삭제를 참조하세요. Cloud Key Management Service를 사용하여 자체 키를 사용 중지하는 방법은 키 버전 폐기 및 복원을 참조하세요.

안전한 인터넷 통신

이 섹션에서는 인터넷과 Google 인프라에서 실행되는 서비스 간의 통신을 보호하는 방법을 설명합니다.

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

Google 프런트엔드 서비스

서비스 자체를 인터넷에서 사용할 수 있도록 해야 한다면 Google 프런트엔드(GFE)라는 인프라 서비스로 등록하면 됩니다. GFE는 모든 TLS 연결이 올바른 인증서를 사용하고 권장사항(예: PFS(Perfect Forward Secrecy) 지원)에 따라 종료되도록 합니다. 또한 GFE는 DoS 공격에 대한 보호를 적용합니다. 그런 다음 GFE는 Google Workspace에서 최종 사용자 데이터의 액세스 관리에서 설명한 RPC 보안 프로토콜을 사용하여 서비스에 대한 요청을 전달합니다.

실제로 외부에 직접 게시해야 하는 모든 내부 서비스는 GFE를 역 프록시 방식의 스마트 프런트엔드로 사용합니다. GFE는 공개 DNS 이름, DoS 보호, TLS 종료의 공개 IP 주소 호스팅을 제공합니다. GFE는 다른 서비스와 마찬가지로 인프라에서 실행되며 수신 요청 볼륨에 맞게 확장될 수 있습니다.

Google Cloud VPC 네트워크의 고객 VM이 Borg에 직접 호스팅된 Google API 및 서비스에 액세스하는 경우 고객 VM은 Cloud 프런트엔드라는 특정 GFE와 통신합니다. 지연 시간을 최소화하기 위해 Cloud 프런트엔드는 고객 VM과 동일한 클라우드 리전 내에 있습니다. 고객 VM에 외부 IP 주소가 없어도 고객 VM과 Cloud 프런트엔드 간에 네트워크 라우팅이 가능합니다. 비공개 Google 액세스가 사용 설정된 경우 내부 IP 주소만 있는 고객 VM은 Cloud 프런트엔드를 사용하여 Google API 및 서비스의 외부 IP 주소와 통신할 수 있습니다. 고객 VM, Google API, 서비스 간의 모든 네트워크 라우팅은 Google의 프로덕션 네트워크 내의 다음 홉에 의존하며, 고객 VM에 외부 IP 주소가 있더라도 마찬가지입니다.

DoS 보호

Google의 인프라 규모는 여러 DoS 공격을 흡수할 수 있습니다. Google에서는 DoS가 서비스에 미치는 위험을 더 줄이기 위해 다중 계층의 다중 레이어 DoS 보호를 갖추고 있습니다.

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

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

사용자 인증

DoS 보호 이후에는 보안 통신을 위한 다음 방어 레이어가 중앙 ID 서비스에서 제공됩니다. 최종 사용자는 Google 로그인 페이지를 통해 이 서비스와 상호작용합니다. 이 서비스는 사용자 이름과 비밀번호를 요청하고 위험 요소에 따라 사용자에게 추가 정보를 요청할 수도 있습니다. 위험 요인의 예시로는 사용자가 동일한 기기 또는 과거에 유사한 위치에서 로그인했는지 여부 등이 있습니다. 사용자 인증 후 ID 서비스가 쿠키 및 OAuth 토큰과 같이 후속 호출에 사용할 수 있는 사용자 인증 정보를 발급합니다.

사용자가 로그인하면 OTP 또는 피싱 방지 보안 키(예: Titan 보안 키)와 같은 두 번째 단계를 사용할 수 있습니다. Titan 보안 키는 FIDO 범용 2단계 인증(U2F)을 지원하는 물리적 토큰입니다. Google은 FIDO Alliance와 함께 U2F 개방형 표준 개발을 도왔습니다. 대부분의 웹 플랫폼 및 브라우저는 이 개방형 인증 표준을 채택했습니다.

운영 보안

이 섹션에서는 Google에서 인프라 소프트웨어를 개발하고, Google 직원의 머신 및 사용자 인증 정보를 보호하고, 내부자 및 외부 행위자의 인프라에 대한 위협으로부터 방어하는 방법을 설명합니다.

안전한 소프트웨어 개발

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

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

또한 Google의 인프라 또는 애플리케이션의 버그를 발견하고 알린 사람에게 보상하는 취약점 발견 리워드 프로그램을 운영합니다. 제공된 보상 등 이 프로그램에 대한 자세한 내용은 Bug Hunters 주요 통계를 참조하세요.

Google에서는 또한 사용하는 오픈소스 소프트웨어에서 제로데이 악용 및 다른 보안 문제를 찾기 위해 투자하고 있습니다. Google에서는 스펙터 및 멜트다운과 같은 제로데이 취약점을 연구하는 Google 연구원으로 구성된 팀인 Project Zero를 운영합니다. 또한 Google에서는 CVE 및 Linux KVM 하이퍼바이저의 보안 버그 수정을 다량으로 제출해 왔습니다.

소스 코드 보호

Google의 소스 코드는 소스 무결성 및 거버넌스 기능이 내장된 저장소에 저장되며, 서비스의 현재 및 이전 버전을 모두 감사할 수 있습니다. 인프라를 사용하려면 서비스의 바이너리를 검토, 체크인, 테스트한 후 특정 소스 코드에서 빌드해야 합니다. Borg용 Binary Authorization(BAB)은 서비스가 배포될 때 수행되는 내부 시행 확인입니다. BAB는 다음을 수행합니다.

  • Google에 배포된 프로덕션 소프트웨어 및 구성이 검토되고 승인되도록 합니다(특히 해당 코드에 사용자 데이터에 액세스할 수 있는 경우).
  • 코드 및 구성 배포가 특정 최소 기준을 충족하도록 보장합니다.
  • 내부자나 공격자가 소스 코드를 악의적으로 수정할 수 있는 권한을 제한하고 서비스에서 다시 소스에 이르기까지 포렌식 추적을 제공합니다.

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

Google에서는 직원의 기기 및 사용자 인증 정보가 도용되지 않도록 보호하는 보호 장치를 구현합니다. Google에서는 정교한 피싱 시도로부터 직원을 보호하기 위해 OTP 2단계 인증을 U2F 호환 보안 키를 필수적으로 사용하는 방식으로 변경하였습니다.

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

기업 LAN에 연결되었다고 해서 액세스 권한을 부여하는 것은 Google의 기본 메커니즘이 아닙니다. 대신 제로 트러스트 보안을 사용하여 리소스에 대한 직원 액세스를 보호합니다. 애플리케이션 수준의 액세스 관리 제어는 직원이 관리형 기기를 사용하고 예상 네트워크 및 지리적 위치에서 연결할 때만 내부 애플리케이션을 직원에게 노출합니다. 클라이언트 기기는 개별 머신에 발급된 인증서 및 해당 머신 구성에 대한 어설션(예: 최신 소프트웨어)을 기반으로 신뢰됩니다. 자세한 내용은 BeyondCorp를 참조하세요.

내부자 위험 감소

내부자 위험은 네트워크, 시스템 또는 데이터에 대한 액세스 권한을 가지고 있거나 가졌던 현재 또는 이전 직원, 계약직 직원 또는 다른 비즈니스 파트너가 액세스 권한을 오용할 가능성으로, Google의 정보 또는 정보 시스템의 기밀성, 무결성 또는 가용성을 손상시킬 수 있습니다.

Google에서는 내부자 위험을 줄이기 위해 인프라에 대한 관리 액세스 권한이 부여된 직원의 활동을 제한하고 적극적으로 모니터링합니다. Google에서는 안전하고 제어되는 방식으로 동일한 작업을 수행할 수 있는 자동화를 사용하여 특정 작업에 액세스 권한을 부여할 필요가 없도록 지속적으로 노력하고 있습니다. 민감한 정보를 노출하지 않고 디버깅할 수 있는 제한된 API를 노출하며 작업자가 수행하는 특정 민감한 작업에는 2단계 승인이 필요합니다.

최종 사용자 정보에 액세스하는 Google 직원은 하위 수준 인프라 후크를 통해 로깅될 수 있습니다. Google 보안팀은 액세스 패턴을 모니터링하고 비정상적인 이벤트를 조사합니다. 자세한 내용은 Google Cloud의 액세스 권한 관리(PDF)를 참조하세요.

Google은 Borg용 Binary Authorization을 사용하여 내부자 위험으로부터 공급망을 보호합니다. 또한 BeyondProd에 투자하여 Google 인프라에서 사용자 데이터를 보호하고 Google 서비스에 대한 신뢰를 구축하고 있습니다.

Google Cloud에서는 액세스 투명성을 사용하여 데이터에 대한 액세스를 모니터링할 수 있습니다. 액세스 투명성 로그를 사용하면 Google 직원이 서비스 중단의 수정이나 지원 요청에 대한 참여와 같은 업무적으로 타당한 이유로만 사용자 콘텐츠에 액세스하고 있는지 확인할 수 있습니다. 액세스 승인을 사용하면 Cloud Customer Care 및 엔지니어링팀에서 사용자의 데이터에 액세스해야 할 때 명시적인 승인을 요구하도록 보장합니다. 승인은 암호화 방식으로 확인되어 액세스 승인의 무결성을 보장합니다.

프로덕션 서비스 보호에 대한 자세한 내용은 Google이 프로덕션 서비스를 보호하는 방법을 참조하세요.

위협 모니터링

Google의 위협 분석 그룹은 위협자와 그 전술 및 기술의 진화를 모니터링합니다. 이 그룹의 목표는 Google 제품의 안전과 보안을 개선하고 온라인 커뮤니티의 이익을 위해 인텔리전스를 공유하는 것입니다.

Google Cloud의 경우 Google Security Operations용 Google Cloud Threat Intelligence 및 VirusTotal을 사용하여 여러 유형의 멀웨어를 모니터링하고 응답할 수 있습니다. Google Security Operations용 Google Cloud Threat Intelligence는 Google Security Operations와 함께 사용할 위협 인텔리전스를 개발하는 위협 연구팀입니다. VirusTotal은 기업 내 멀웨어의 작동 방식을 더 잘 이해하는 데 사용할 수 있는 멀웨어 데이터베이스 및 시각화 솔루션입니다.

위협 모니터링 활동에 대한 자세한 내용은 위협 범위 보고서를 참조하세요.

침입 감지

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

다음 단계