BeyondProd

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

이 문서에서는 BeyondProd라는 클라우드 기반 아키텍처를 사용하여 Google이 인프라 보안을 구현하는 방법을 설명합니다. BeyondProd는 워크로드 보호를 위해 함께 작동하는 인프라의 서비스 및 제어 기능을 의미합니다. 워크로드는 애플리케이션이 완료하는 고유의 태스크를 의미합니다. BeyondProd는 코드 변경 방법 및 사용자 데이터 액세스 방법을 포함하여 환경에서 실행되는 마이크로서비스를 보호하는 데 도움이 됩니다.

이 문서는 정교한 위협들로부터 Google 플랫폼을 보호하기 위해 개발한 Chrome Enterprise Premium, 와 같은 기술을 설명하는 일련의 기술 자료 중 일부입니다. Chrome Enterprise Premium은 Google 플랫폼 및 여기에서 실행되는 서비스에 대해 보안 액세스를 제공하도록 설계된 제로 트러스트 아키텍처를 구현합니다. Chrome Enterprise Premium과 같이 BeyondProd는 방화벽과 같은 기존의 네트워크 경계 보호에 의존하지 않습니다. 대신 BeyondProd는 코드 출처, 서비스 ID, 신뢰할 수 있는 하드웨어와 같은 특성을 사용하여 마이크로서비스 간에 신뢰를 만드는 데 도움을 줍니다. 이러한 신뢰는 Google Cloud에서 실행되는 소프트웨어 및 Google Cloud 고객이 배포하고 액세스하는 소프트웨어로 확장됩니다.

이 문서에서는 BeyondProd의 이점, 해당 서비스 및 프로세스, 이 아키텍처로 마이그레이션을 수행한 방법을 설명합니다. 인프라 보안 개요는 Google 인프라 보안 설계 개요를 참조하세요.

소개

최신 보안 아키텍처는 방화벽이 경계를 보호하고 경계 안의 사용자 또는 서비스를 신뢰하는 기존의 경계 기반 보아 모델을 넘어섰습니다.

현대의 사용자들은 일반적으로 집, 커피숍, 비행기 등 조직의 기존 보안 경계를 벗어나서 모바일 상태로 작업을 수행합니다. Chrome Enterprise Premium에서는 다양한 사용자 ID, 리소스 액세스에 사용되는 기기 ID, 기기 상태, 사용자 행동과 같은 신뢰 신호, 액세스 제어 목록과 같은 여러 요소를 사용해서 회사 리소스에 대해 액세스 권한을 부여합니다.

BeyondProd는 Chrome Enterprise Premium가 사용자에 대해 해결하는 것과 동일한 문제를 프로덕션 서비스에 대해 해결해줍니다. 클라우드 기반 아키텍처에서는 단순히 방화벽에만 의존해서 프로덕션 네트워크를 보호할 수 없습니다. 마이크로서비스는 이종 호스트 간의 여러 환경으로 이동 및 배포되고 다양한 신뢰 및 민감도 수준에서 작동합니다. 사용자 신뢰가 기업 네트워크 연결 기능이 아닌 기기의 컨텍스트 인식 상태와 같은 특성에 의존해야 하는 Chrome Enterprise Premium에서와 같이, BeyondProd에서 서비스 신뢰는 IP 주소 또는 호스트 이름과 같은 프로덕션 네트워크 위치보다 코드 출처, 신뢰할 수 있는 하드웨어, 서비스 ID와 같은 특성에 의존해야 합니다.

컨테이너화된 인프라

Google 인프라는 워크로드를 컨테이너의 개별 마이크로서비스로 배포합니다. 마이크로서비스는 애플리케이션이 수행해야 하는 개별 태스크를 여러 서비스로 구분합니다. 각 서비스는 자체 API, 배포, 확장, 할당량 관리를 통해 와 독립적으로 개발 및 관리할 수 있습니다. 마이크로서비스는 독립적인 모듈형으로 나뉘어 동적으로 실행되는 임시 아키텍처로, 여러 호스트와 클러스터뿐 아니라 클라우드에도 분산될 수 있습니다. 마이크로서비스 아키텍처에서 워크로드는 1개 또는 여러 개의 마이크로서비스일 수 있습니다.

컨테이너화된 인프라는 각 마이크로서비스가 이동 및 예약이 가능한 고유한 컨테이너 집합으로 배포된다는 의미입니다. 이러한 컨테이너를 내부적으로 관리하기 위해 Google은 1주일에 수십억 개에 달하는 컨테이너를 배포하는 Borg라는 컨테이너 조정 시스템을 개발했습니다. Borg는 Google의 통합 컨테이너 관리 시스템이며, Kubernetes에 영감을 주었습니다.

컨테이너를 사용하면 시스템 간에 워크로드를 보다 쉽고 효율적으로 예약할 수 있습니다. 마이크로서비스를 컨테이너로 묶으면 유지보수 및 검색을 위해 워크로드를 더 작고 관리하기 쉬운 단위로 분할할 수 있습니다. 이 아키텍처는 필요에 따라 워크로드를 조정합니다. 특정 워크로드에 대한 수요가 많을 경우 필요한 워크로드 규모를 처리하기 위해 동일한 컨테이너의 사본을 실행하는 여러 개의 머신이 있을 수 있습니다.

Google에서 보안은 모든 아키텍처 발전의 핵심 역할을 수행합니다. 이 마이크로서비스 아키텍처 및 개발 프로세스에 대한 목표는 가능한 개발 및 배포 수명 주기 초반에 보안 문제를 해결하는 것입니다. 이때 더 낮은 비용으로 문제를 해결하려면 일관성 있는 표준화된 방법이 필요합니다. 따라서 개발자는 보안에 할애하는 시간을 줄이면서도 보안을 강화할 수 있게 됩니다.

BeyondProd 이점

BeyondProd는 Google 인프라에 많은 자동화 및 보안 이점을 제공합니다. 이러한 이점은 다음과 같습니다.

  • 네트워크 에지 보호: 네트워크 공격 및 인터넷에서 승인되지 않은 트래픽으로부터 워크로드를 격리합니다. 경계 접근법은 새로운 개념이 아니지만 클라우드 아키텍처에서도 보안 권장사항으로 남아 있습니다. 경계 접근법은 볼륨 기반의 DoS 공격과 같이 인터넷에서 승인되지 않은 트래픽 및 잠재적 공격으로부터 가능한 한 인프라를 보호하는 데 도움이 됩니다.
  • 서비스 간 내제된 상호 신뢰 관계 없음: 인증되었고, 신뢰할 수 있고, 특별히 승인된 호출자 또는 서비스만 다른 모든 서비스에 액세스할 수 있습니다. 공격자가 신뢰할 수 없는 코드를 사용하여 서비스에 액세스하지 못하도록 차단됩니다. 서비스가 손상된 경우 이러한 이점 덕분에 공격자가 자신의 범위를 확장할 수 있는 행동을 수행하지 못하도록 방해할 수 있습니다. 이러한 상호 불신은 세부적인 액세스 제어와 함께 손상으로 인한 폭발 반경을 제한하는 데 도움이 됩니다.
  • 알려진 출처의 코드를 실행하는 신뢰할 수 있는 머신: 승인된 코드 및 구성만 사용하고 승인 및 확인된 환경에서만 실행되도록 서비스 ID를 제한합니다.
  • 서비스 전반의 일관된 정책 시행: 일관된 정책 시행을 통해 서비스 전반에서 액세스 결정을 신뢰할 수 있습니다. 예를 들어 사용자 데이터에 대한 액세스 요청을 확인하는 정책 시행을 만들 수 있습니다. 서비스에 액세스하려면 승인된 최종 사용자가 검증된 요청을 제공하고 관리자가 비즈니스 근거를 제공해야 합니다.
  • 자동화되고 표준화된 간단한 변경사항 배포: 인프라 변경사항이 보안에 미치는 영향을 간편하게 검토하고 프로덕션에 미치는 영향 없이 보안 패치를 배포할 수 있습니다.
  • 운영체제를 공유하는 워크로드 간 격리: 서비스가 손상된 경우 동일한 호스트에서 실행되는 다른 워크로드의 보안에 영향을 줄 수 없습니다. 이 격리는 보안 침해의 영향 범위를 제한하는 데 도움이 됩니다.
  • 신뢰할 수 있는 하드웨어 및 증명: 하드웨어 신뢰할 수 있는 루트는 워크로드 실행을 예약하기 전 알려져 있고 승인된 코드(펌웨어부터 사용자 모드까지)만 호스트에서 실행되도록 보장합니다.

이러한 이점 덕분에 컨테이너와 클라우드 아키텍처 내에서 실행되는 마이크로서비스를 배포하고, 서로 통신하고, 인프라 보안을 약화시키지 않으면서도 서로 병행해서 실행할 수 있습니다. 또한 개별 마이크로서비스 개발자에게도 기본 인프라의 보안 및 구현 세부정보로 인한 부담이 없습니다.

BeyondProd 보안 서비스

Google은 BeyondProd 이점에 설명된 대로 여러 BeyondProd 보안 서비스를 설계하고 개발했습니다. 다음 섹션에서 이러한 서비스에 대해 설명합니다.

네트워크 에지 보호를 위한 Google 프런트엔드

Google 프런트엔드(GFE)는 네트워크 에지 보호를 제공합니다. GFE는 최종 사용자 연결을 종료하고 TLS 권장사항을 적용하기 위한 중앙 지점을 제공합니다.

Google은 더 이상 경계 기반 보안에 중점을 두고 있지 않지만, GFE는 DoS 공격으로부터 내부 서비스를 보호하는 전략에서 중요한 역할을 합니다. GFE는 Google 인프라에 연결하는 사용자의 첫 번째 시작 지점입니다. 사용자가 인프라에 연결한 후 GFE는 필요에 따라 부하 분산 및 리전 간 트래픽 라우팅 조정도 수행합니다. GFE는 트래픽을 올바른 마이크로서비스로 라우팅하는 에지 프록시입니다.

Google Cloud의 고객 VM은 GFE에 등록하지 않습니다. 대신 Compute Engine 네트워킹 스택을 사용하는 GFE의 특수 구성인 Cloud Front End에 등록합니다. Cloud Front End를 사용하면 고객 VM에서 공개 또는 비공개 IP 주소를 사용하여 Google 서비스에 직접 액세스할 수 있습니다. (비공개 IP 주소는 비공개 Google 액세스가 사용 설정된 경우에만 사용할 수 있습니다.)

서비스 간 신뢰를 위한 애플리케이션 레이어 전송 보안

애플리케이션 레이어 전송 보안(ALTS)은 서비스 간에 내재된 상호 신뢰가 없도록 보장합니다. ALTS는 리모트 프로시져 콜(RPC) 인증,무결성, 트래픽 암호화 및 서비스 ID에 사용됩니다. ALTS는 Google 인프라의 서비스를 위한 상호 인증 및 전송 암호화 시스템입니다. 일반적으로 ID는 특정 서버 이름 또는 호스트 대신 서비스에 바인딩됩니다. 이 바인딩은 원활한 마이크로 서비스 복제, 부하 분산, 여러 호스트에 걸친 일정 조정에 도움이 됩니다.

각 머신은 호스트 무결성 시스템을 사용하여 프로비저닝된 ALTS 사용자 인증 정보를 포함하며 호스트 무결성 시스템에서 보안 부팅이 성공한 것으로 확인된 경우에만 복호화할 수 있습니다. 대부분의 Google 서비스는 Borg를 기반으로 하여 마이크로서비스로 실행되며 이러한 마이크로서비스는 각각 고유한 ALTS ID를 가집니다.Borg 중앙 컨트롤러인 Borg Prime은 마이크로서비스 ID를 기반으로 이러한 ALTS 마이크로서비스 사용자 인증 정보를 워크로드에 부여합니다. 머신 수준 ALTS 사용자 인증 정보는 마이크로서비스 사용자 인증 정보를 프로비저닝하는 보안 채널을 구성하므로 호스트 무결성의 자체 검사 부팅에 성공한 머신만 마이크로서비스 워크로드를 호스팅할 수 있습니다. ALTS 사용자 인증 정보에 대한 자세한 내용은 워크로드 인증서를 참조하세요.

코드 출처에 대한 Borg용 Binary Authorization

Borg용 Binary Authorization(BAB)는 코드 출처를 확인합니다. BAB는 코드 배포 전 코드가 내부 보안 요구사항을 충족하는지 확인하는 배포 시 시행 검사입니다. 예를 들어 BAB 시행 검사에는 소스 코드 저장소에 코드가 제출되기 전 보조 엔지니어가 변경사항을 검토하고 전용 인프라에서 바이너리가 검증 가능하게 구축되었는지 확인하는 과정이 포함됩니다. Google 인프라에서 BAB는 승인되지 않은 마이크로서비스의 배포를 제한합니다.

머신 트러스트의 호스트 무결성

호스트 무결성은 보안 부팅 프로세스를 통해 호스트 시스템 소프트웨어 무결성을 확인하고 지원되는 경우 하드웨어 신뢰할 수 있는 루트 보안 칩(Titan)으로 지원됩니다. 호스트 무결성 검사에는 BIOS의 디지털 서명 확인, 베이스보드 관리 컨트롤러(BMC),부트로더, OS 커널이 포함됩니다. 지원되는 경우 호스트 무결성 검사에 사용자 모드 코드 및 주변기기 펌웨어(예: NIC)가 포함될 수 있습니다. 디지털 서명 확인 외에도 호스트 무결성은 각 호스트가 이러한 소프트웨어 구성요소의 의도된 버전을 실행하고 있는지 확인하는 데 도움이 됩니다.

정책 시행을 위한 서비스 액세스 관리 및 최종 사용자 컨텍스트 티켓

서비스 액세스 관리및 최종 사용자 컨텍스트 티켓은 서비스 간에 정책을 일관되게 적용하는 데 도움이 됩니다.

서비스 액세스 정책은 서비스 간 데이터 액세스 방법을 제한합니다. RPC가 한 서비스에서 다른 서비스로 전송될 때 서비스 액세스 관리는 서비스가 수신 서비스의 데이터에 액세스하는 데 필요한 승인 및 감사 정책을 정의합니다. 이를 통해 데이터 액세스 방식을 제한하고, 필요한 최소한의 액세스 수준을 부여하며, 해당 액세스 권한을 감사할 수 있는 방법을 지정합니다. Google 인프라에서 서비스 액세스 관리는 하나의 마이크로서비스 액세스를 다른 마이크로서비스 데이터로 제한하고 액세스 제어에 대한 전역 분석을 가능하게 해줍니다.

최종 사용자 컨텍스트 티켓은 최종 사용자 인증 서비스에서 발급되고, 서비스 ID와 별개인 사용자 ID를 서비스에 제공합니다. 이러한 티켓은 무결성이 보호되고 중앙에서 발급되며 전달 가능한 사용자 인증 정보로 서비스 요청을 실행하는 최종 사용자의 신원을 증명합니다. 액세스 결정이 일반적으로 최종 사용자 ID에 기반할 때 ALTS를 사용하는 피어 ID가 액세스 권한을 부여하는 데 부족할 수 있으므로, 이러한 티켓은 서비스 간 신뢰 요구를 줄여 줍니다.

변경사항 및 확장성 자동 배포를 위한 Borg 도구

블루-그린 배포를 위한 Borg 도구는 간단하고, 자동화되고, 표준화된 변경 배포를 제공합니다. 블루-그린 배포는 수신 트래픽에 영향을 주지 않고 워크로드에 변경사항을 출시하는 방법입니다. 따라서 최종 사용자가 애플리케이션을 액세스할 때 다운타임이 발생하지 않습니다.

Borg 작업은 애플리케이션 일부를 실행하는 마이크로서비스의 단일 인스턴스입니다. 작업은 부하가 증가할 때 새 작업을 배포하고 부하가 감소하면 기존 작업을 종료하는 방식으로 부하를 처리하도록 확장됩니다.

Borg 도구는 유지보수 태스크를 수행할 때 실행 중인 워크로드를 마이그레이션합니다. 새 Borg 작업을 배포하면 부하 분산기가 기존 작업에서 새 작업으로 트래픽을 점진적으로 이동합니다. 이렇게 하면 다운타임 없이 사용자가 눈치채지 않게 마이크로서비스를 업데이트할 수 있습니다.

또한 새 기능을 추가할 때 이 도구를 사용하여 서비스 업그레이드를 적용하고 다운타임 없이 중요한 보안 업데이트를 적용합니다. 인프라에 영향을 미치는 변경사항의 경우 워크로드가 영향을 받지 않도록 고객 VM의 라이브 마이그레이션을 사용합니다.

자세한 내용은 Borg용 Binary Authorization을 참조하세요.

워크로드 격리를 위한 gVisor 커널

gVisor 커널은 운영체제를 공유하는 워크로드 간의 격리를 허용합니다. gVisor는 사용자 공간 커널을 사용하여 시스템 호출을 가로채서 처리하고 호스트와의 상호작용과 잠재적인 공격 표면을 줄입니다. 이 커널은 애플리케이션을 실행하는 데 필요한 대부분의 기능을 제공하고, 애플리케이션에 액세스할 수 있는 호스트 커널 영역을 제한합니다. gVisor는 내부 워크로드 및 동일한 호스트에서 실행되는 Google Cloud 고객 워크로드를 격리하기 위해 사용되는 여러 도구 중 하나입니다. 다른 샌드박스 도구에 대한 자세한 내용은 코드 샌드박스를 참조하세요.

BeyondProd를 사용하여 사용자 데이터 보호

이 섹션에서는 BeyondProd 서비스를 사용하여 인프라에서 사용자 데이터를 보호하는 방법을 설명합니다. 이 섹션에서는 두 가지 예시를 설명합니다.

  • 생성부터 대상 전달까지 사용자 데이터 요청 액세스
  • 개발부터 생산까지의 코드 변경사항

여기에 나열된 모든 기술이 모든 인프라 부분에 사용되지는 않으며, 서비스 및 워크로드에 따라 달라집니다.

사용자 데이터 액세스

아래 다이어그램은 사용자 데이터 액세스가 허가되었는지 확인하기 위해 인프라에 사용되는 프로세스를 보여줍니다.

Google 클라우드 기반 보안으로 사용자 데이터 액세스 제어

사용자 계정에 액세스하는 단계는 다음과 같습니다.

  1. 사용자가 GFE에 요청을 전송합니다.
  2. GFE가 TLS 연결을 종료하고 ALTS를 사용하는 적합한 서비스의 프런트엔드로 요청을 전달합니다.
  3. 애플리케이션 프런트엔드가 중앙 최종 사용자 인증(EUA) 서비스를 사용하여 사용자 요청을 인증하고, 성공하면 단기 암호화 최종 사용자 컨텍스트 티켓을 수신합니다.
  4. 애플리케이션 프런트엔드가 ALTS로 스토리지 백엔드 서비스에 RPC를 수행하고 백엔드 요청으로 티켓을 전달합니다.
  5. 백엔드 서비스가 서비스 액세스 관리를 사용해서 다음 조건에 해당하는지 확인합니다.
    • 프런트엔드가 취소되지 않은 유효한 인증서를 사용하여 인증되었습니다. 이 검사는 신뢰할 수 있는 호스트에서 실행 중이고 BAB 검사가 성공했음을 의미합니다.
    • 프런트엔드 서비스의 ALTS ID가 백엔드 서비스에 대해 요청을 실행하고 EUC 티켓을 전달하도록 승인되었습니다.
    • 최종 사용자 컨텍스트 티켓이 유효합니다.
    • EUC 티켓의 사용자가 요청된 데이터에 액세스하도록 승인되었습니다.

이러한 검사 중 하나라도 실패하면 요청이 거부됩니다.

이러한 검사가 통과하면 데이터가 승인된 애플리케이션 프런트엔드로 반환되어 승인된 사용자에게 제공됩니다.

대부분의 경우 일련의 백엔드 호출이 있고 모든 중간 서비스는 인바운드 RPC에서 서비스 액세스 검사를 수행하고 티켓이 아웃바운드 RPC로 전달됩니다.

인프라 내에서 트래픽의 라우팅 방법에 대한 자세한 내용은 트래픽 라우팅 방법을 참조하세요.

코드 변경

아래 다이어그램은 코드 변경이 배포되는 방법을 보여줍니다.

코드 변경 수행 방법

코드 변경을 수행하는 단계는 다음과 같습니다.:

  1. 개발자가 BAB로 보호되는 마이크로서비스를 변경합니다. 변경사항이 코드 검토를 시행하는 Google의 중앙 코드 저장소에 제출됩니다. 승인 후에는 변경사항이 서명된 확인 가능한 빌드 매니페스트 인증서로 패키지를 생성하는 신뢰할 수 있는 중앙 빌드 시스템에 제출됩니다.

  2. 배포 시 BAB는 빌드 파이프라인에서 서명된 인증서를 검증하여 이 프로세스가 수행되었는지 확인합니다.

  3. Borg는 일상 배포 또는 긴급 보안 패치에 관계없이 서비스에 대해 최소한의 중단을 보장하는 안정성 모델을 사용하여 모든 워크로드 업데이트를 처리합니다.

  4. GFE는 운영 연속성을 보장하기 위해 부하 분산을 사용하여 새 배포로 트래픽을 이동합니다.

이 프로세스에 대한 자세한 내용은 개발 및 프로덕션 프로세스를 참조하세요.

모든 워크로드는 격리해야 합니다. 소스 코드가 Google 외부에서 비롯되어 워크로드 신뢰도가 낮으면 gVisor로 보호되는 환경에 배포하거나 다른 격리 레이어를 사용할 수 있습니다. 이 격리는 애플리케이션을 손상시키는 공격자를 억제하는 데 도움이 됩니다.

클라우드 기반 보안 영향

다음 섹션에서는 기존 인프라의 보안 측면과 클라우드 기반 아키텍처의 보안 측면을 비교해서 보여줍니다.

애플리케이션 아키텍처

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

그러나 클라우드 기반 모델에서는 공개 클라우드, 비공개 데이터 센터, 타사 호스팅 서비스에서 실행될 수 있기 때문에 여러 다른 환경 간에 애플리케이션을 이동할 수 있어야 합니다. 따라서 클라우드 환경에는 모놀리식 애플리케이션 대신 마이크로서비스로 분할된 컨테이너화된 애플리케이션이 이상적입니다. 컨테이너는 애플리케이션에 필요한 바이너리를 기본 호스트 운영체제에서 분리하고 애플리케이션을 보다 이동 가능하게 만듭니다. 컨테이너는 불변성을 갖습니다. 즉, 배포된 후에 변경되지 않습니다. 대신 자주 다시 빌드되고 다시 배포됩니다.

컨테이너가 자주 재시작, 중지 또는 일정 변경됨에 따라 하드웨어와 네트워킹을 재사용하고 공유하는 빈도도 높아집니다. 공통의 표준화된 빌드와 분산 프로세스를 사용하므로 여러 팀에서 마이크로서비스의 개발을 독립적으로 관리하는 경우에도 팀 간의 개발 프로세스가 보다 일관되고 균일해집니다. 그 결과, 보안 고려사항(보안 검토, 코드 검색, 취약점 관리 등)을 개발 주기 초기에 적용할 수 있습니다.

서비스 메시

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

서비스 메시는 인프라 레이어에서 모든 마이크로서비스를 포함하고 연결하는 공유 패브릭입니다. 서비스 메시를 사용하면 트래픽을 제어하고 정책을 적용하며 여러 서비스 호출을 중앙에서 모니터링할 수 있는 서비스 간 통신이 가능합니다.

제로 트러스트 보안

비공개 데이터 센터를 사용하는 기존 보안 모델에서 조직의 애플리케이션은 외부 네트워크 기반 위협으로부터 워크로드를 보호하기 위해 방화벽에 의존합니다.

제로 트러스트 보안 모델을 사용하면 승인 결정이 방화벽에 의존하지 않습니다. 대신 워크로드 아이덴티티, 인증, 승인과 같은 다른 제어 수단을 통해 트랜잭션 이전에 내부 또는 외부 연결을 검증하여 마이크로서비스를 보호합니다. 방화벽 또는 네트워크 기반 제어 수단에 대한 종속성을 없앰으로써 서비스 간에 내재된 신뢰 없이 마이크로서비스 수준의 세분화를 구현할 수 있습니다. 마이크로서비스 수준의 세분화를 사용해서 각 제어마다 트래픽이 여러 신뢰 수준을 가질 수 있고, 더 이상 내부 트래픽과 외부 트래픽을 비교할 필요가 없습니다.

서비스 스택에 통합된 공유 보안 요구사항

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

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

더 잦은 배포로 표준화된 프로세스

기존의 보안 모델에는 공유 서비스가 제한적이고 코드가 복제되고 로컬 개발과 결합되는 경우가 많습니다. 공유가 제한적이어서 변경으로 인한 영향과 변경의 영향을 받는 애플리케이션 부분이 얼마나 많은지 확인하는 것이 어렵습니다. 따라서 배포가 빈번하지 않고 조정하기 어렵습니다. 변경을 위해서는 개발자가 각 구성요소를 직접 업데이트해야 할 수 있습니다. 예를 들어 구성을 업데이트하려면 각 가상 머신에 SSH로 연결해야 합니다. 그 결과 애플리케이션이 전반적으로 꽤 오랫동안 유지되었습니다.

보안 측면에서는 코드가 복제되는 경우가 많아서 검토하기도 어렵고, 취약점이 해결되었을 때 모든 위치에서 취약점이 해결되었는지 확인하는 것이 더 어렵습니다.

클라우드 기반 아키텍처에서 배포는 빈번하게 발생하고 표준화됩니다. 이 프로세스는 소프트웨어 개발 수명 주기에서 보안이 원점으로 회귀할 수 있게 해줍니다. 원점 회귀는 코드, 빌드, 테스트, 검증, 배포 등의 단계를 포함할 수 있는 소프트웨어 개발 수명 주기의 초기 단계로 돌아가는 것을 의미합니다. 원점 회귀를 통해 정기적인 보안 패치 적용을 포함하여 더 간단하고 더 일관적인 보안 시행이 가능합니다.

BeyondProd 변경

Google은 BeyondProd로 전환하기 위해 인프라와 개발 프로세스라는 두 가지 주요 영역을 변경해야 했습니다. Google은 이러한 두 가지 변경 사항을 동시에 처리했지만, 사용자 환경에서 비슷한 상황을 설정할 때는 둘을 독립적으로 해결할 수 있습니다.

인프라 변경

보안이 서비스와 동일한 방식으로 확장된다는 믿음에 따라 목표는 전체 인프라에서 보안을 자동화하는 것입니다. 서비스는 기본적으로 보호되어야 하며 위험을 감수하기 위한 명시적인 결정을 내린 후에만 안전하지 않아야 합니다. 인프라에 대한 사람의 직접 개입은 일상이 아닌 예외를 기반으로 하며, 개입이 있으면 이에 대한 감사가 가능해야 합니다. 그러면 서비스를 배포한 사용자를 기반으로 하는 대신 서비스에 배포된 코드 및 구성을 기반으로 서비스를 인증할 수 있습니다.

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

개발 프로세스 변경

Google은 실행 중인 서비스의 무결성을 보장하기 위해 강력한 빌드 및 코드 검토 프로세스를 설정하는 것이 중요했습니다. Google은 빌드 및 배포 시에 2인 코드 검토 및 자동화된 테스트와 같은 요구사항을 적용할 수 있는 중앙 빌드 프로세스를 만들었습니다. 배포에 대한 자세한 내용은 Borg용 Binary Authorization을 참조하세요.

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

Google은 서비스가 위반사항을 차단하는 대신 정책 위반을 로깅하는 것이 더 쉽다는 것을 빠르게 파악했습니다. 이 접근법의 이점은 두 가지입니다.

  • 서비스 소유자에게 변경사항을 테스트하고 클라우드 기반 환경으로의 이전이 서비스에 미치는 영향을 가늠할 수 있는 기회를 제공했습니다.
  • 이를 통해 버그를 수정하고 서비스팀에 제공해야 할 추가 기능을 식별할 수 있게 되었습니다.

예를 들어 서비스가 BAB에 온보딩되면 서비스 소유자는 감사 전용 모드를 사용 설정합니다. 따라서 요구사항을 충족하지 않는 코드나 워크플로를 식별할 수 있습니다. 감사 전용 모드에서 표시된 문제가 해결되면 서비스 소유자는 시행 모드로 전환합니다. gVisor에서는 샌드박스 기능에 호환성 차이가 있는 경우에도 먼저 샌드박스 워크로드를 처리한 다음 이러한 차이를 체계적으로 해결하여 샌드박스를 개선했습니다.

다음 단계