Google에서 프로덕션 서비스를 보호하는 방법

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

Google은 글로벌 규모의 멀티 테넌트 및 분산형 계산 인프라를 실행하여 전 세계 수십억 명의 사용자에게 제품과 서비스를 제공합니다. 이 인프라는 보안, 신뢰성, 복원력, 효율성, 개발 속도, 디버그 가능성 등의 경쟁적인 우선순위 사이에서 균형을 유지해야 합니다.

이 문서에서는 Google 프로덕션 환경에서 실행되는 서비스에 업계 최고의 보안 상황을 유지하는 데 사용되는 몇 가지 메커니즘을 설명합니다. 이러한 서비스는 민감한 정보에 액세스할 수 없는 개발 실험에서부터 중요한 ID 인프라에 이르기까지 보안 민감도의 전 영역을 차지합니다. 이러한 서비스는 사용자 데이터 처리, 소프트웨어 출시 관리, 개별 물리적 머신의 프로비저닝 및 수명 주기 관리와 같은 태스크를 완료합니다.

이 문서에서는 Google 인프라의 다음 세 가지 주요 레이어를 보호하는 데 도움이 되는 보안 제어를 설명합니다.

• 보안이 가장 중요한 서비스가 포함된 프로덕션 서비스(기본 서비스라고도 함)
• 프로덕션 머신
• 프로덕션 워크로드

Google은 Google 직원이 적법한 업무 목적(예: 유지보수 액세스)으로만 서비스, 머신, 워크로드에 액세스할 수 있도록 하고 내부자 위험과 직원 계정 도용이 방지되도록 이러한 제어를 적용합니다. 이러한 제어는 계정 도용이 방지되는 데 도움이 되는 기존 인프라 보안 제어를 보완하는 더욱 포괄적인 보안을 제공합니다.

지속적 개선

이 문서에 설명된 제어는 Google 프로덕션 환경 전체에서 사용됩니다. 기본 서비스를 포함한 많은 서비스에서 Google에서 제공하는 최신 수준의 제어를 사용합니다. 하지만 Google 인프라의 범위와 복잡성으로 인해 개별 프로덕션 서비스에 고유한 요구사항이 있는 경우가 많으며 최신 권장사항을 구현하는 데 추가 시간이 필요할 수 있습니다. Google의 사이트 안정성 엔지니어링(SRE) 및 보안팀은 지속적인 개선 문화를 통해 변화하는 위협 환경에 맞게 보안 제어를 지속적으로 조정하고 있습니다.

프로덕션 서비스 보호

Google은 Google 직원이 유지보수와 같은 합법적인 비즈니스 목적으로만 서비스에 액세스할 수 있도록 프로덕션 서비스 무결성을 보호합니다. 프로덕션 환경에서 실행되는 서비스에 액세스하는 기본 방법에는 관리 액세스를 통한 방법과 소프트웨어 공급망을 통한 방법 등 두 가지가 있습니다.

다음 목록에서는 각 액세스 경로를 보호하는 데 도움이 되는 제어를 설명합니다.

• 관리 액세스 제어: 프로덕션 서비스에는 정기적인 유지보수(예: 바이너리 또는 구성 출시)가 필요합니다. Google 목표는 제로터치 프로덕션 철학에 따라 자동화, 안전 프록시 또는 감사된 긴급 액세스를 통해 이러한 작업을 수행하는 것입니다. 프로덕션 애셋에 대한 사람의 액세스를 삭제하는 제어 모음을 No Persons(NoPe)라고 합니다. NoPe를 사용하면 Google이 프로덕션 서비스의 민감도와 지속적인 개선을 통해 더욱 강력한 상황을 달성할 수 있는 준비 상태에 따라 유연하게 액세스 제어를 배포할 수 있습니다.

  예를 들어 Google은 기본 서비스에 대한 일방적인 액세스를 허용하지 않습니다. 긴급 액세스조차 다른 Google 직원의 승인을 받아야 합니다. 다른 승인된 개인의 승인 없이 액세스를 수행할 수 있는 경우 액세스는 일방적인 액세스입니다.

• 소프트웨어 공급망 제어: 기초 서비스를 포함한 Google의 프로덕션 워크로드 대부분은 신뢰할 수 있는 소스에 위치한 동료 검토 코드에서 검증 가능한 방식으로 빌드된 바이너리와 작업 구성을 실행합니다. Google에서는 Borg용 Binary Authorization(BAB)을 사용하여 이 프로세스를 적용합니다.

다음 다이어그램에서는 프로덕션 서비스를 보호하는 데 도움이 되는 제어를 보여줍니다.

가장 높은 수준의 NoPe 및 BAB를 적용하면 긴급한 경우라도 어떠한 Google 직원도 기본 서비스에 일방적으로 액세스할 수 없으며 직원에게 제공되는 모든 권한 있는 액세스에는 범위와 기간이 명확하게 정의되어 있습니다. 권한 있는 액세스는 자동화로 해결되지 않는 고유한 상황에서 중요한 프로덕션 서비스를 관리할 수 있도록 직원에게 부여되는 승격된 액세스 수준입니다. Google에서 잠김 상태를 해제할 수 있는 방법을 제공하기 위해 이 규칙에 예외가 적용됩니다.

Filestore 또는 Cloud SQL과 같은 제품과 Borg 및 Spanner와 같은 내부 인프라 제품을 포함한 다른 많은 프로덕션 서비스는 가장 높은 수준의 NoPe 및 BAB를 사용하도록 구성되어 있으며 Google은 프로덕션 서비스 소유자가 시간이 지남에 따라 NoPe 및 BAB를 더 쉽게 채택할 수 있도록 지속적으로 노력하고 있습니다.

관리 액세스 제어

Borg에서 프로덕션 역할의 구성원은 프로덕션 역할에서 소유한 데이터를 읽거나 쓰거나 삭제할 수 있으며 역할의 권한을 사용하여 코드를 실행할 수 있습니다. 프로덕션 역할은 Google의 프로덕션 환경에서 워크로드를 실행할 수 있는 ID입니다.

프로덕션 역할의 영구 멤버십으로 인해 프로덕션에 의도하지 않은 결과가 발생하고 이러한 권한이 악용될 수 있습니다. 하지만 SRE의 사명에서는 팀에 담당 서비스를 유지할 수 있는 권한을 부여할 것을 요구하므로 완전한 액세스 제거는 실행 가능한 전략이 아닐 수 있습니다.

NoPe 모음은 팀에게 권한을 부여하고 프로덕션 시스템을 안전하게 유지하는 상반된 요구사항 사이에서 균형을 맞추는 액세스 권한을 구성하는 방법을 제공합니다. NoPe를 사용하면 Google 직원이 프로덕션 서비스에 액세스하려고 할 때 Google 직원 계정 권한에 제약 조건이 적용됩니다. NoPe는 다음과 같은 제약 조건을 허용합니다.

• 액세스 요청에 승인 담당자와 근거 필요: 다자간 승인(MPA)이라는 제어를 사용하면 Google 직원이 비즈니스 근거와 액세스 요청을 확인할 수 있는 권한이 있는 개인의 승인 없이 프로덕션 서비스에 액세스할 수 없게 할 수 있습니다.
• 프로덕션 서비스 역할에 직접 액세스 없음: 직원은 NoPe용 안전 프록시를 통해서만 프로덕션 서비스에 액세스할 수 있습니다. 안전 프록시는 잘 정의된 명령어 집합만 실행될 수 있도록 설계되었습니다. Google 보안 및 SRE 조직에서 위험하다고 판단하는 명령어(예: 서비스 종료 또는 데이터 액세스나 삭제)를 사용하려면 MPA도 필요합니다.
• 영구 프로덕션 역할 멤버십 없음: 주문형 액세스(AoD)라는 제어를 사용하려면 직원 계정을 허용하는 대신 직원이 항상 액세스 권한이 있는 임시 멤버십을 요청해야 합니다. 이 제어를 사용하면 승격된 권한이 특정 이유로만 일시적으로 부여되도록 할 수 있습니다.
• 프로덕션 서비스에 대한 직원 액세스 요청 모니터링: Google은 프로덕션 서비스를 실행하는 프로덕션 역할에 대한 액세스 패턴을 정기적으로 감사해야 합니다. 감사 목표는 관리 API의 지속적인 개선을 통해 향후 이러한 요청이 필요하지 않도록 하는 것입니다. 프로덕션 서비스에 대한 액세스는 긴급 대응 상황에만 예약되어야 합니다. 기본 서비스의 경우 액세스가 부여되는 상황이 너무 적어 보안팀에서 부여된 각 액세스 권한을 감사하여 해당 권한의 유효성을 확인합니다.

다음 섹션에서는 각 제어를 자세히 설명합니다.

NoPe의 다자간 승인

MPA를 사용하려면 다른 승인된 Google 직원이 액세스 요청을 승인해야 합니다.

충분히 민감한 서비스에 액세스를 요청한 경우 MPA를 사용하려면 직원이 각 요청 시 진행 중인 프로덕션 비상사태를 언급하는 비즈니스 근거도 제공해야 합니다.

이러한 두 가지 조건은 액세스 악용을 방지하는 장벽이 됩니다.

NoPe용 안전 프록시

안전 프록시는 안전 프록시가 호출자를 대신하여 실행할 수 있는 사전 정의된 명령어 집합을 노출하는 도구입니다. 안전 프록시는 세분화된 규칙 기반 승인 정책을 구현하여 프로덕션 서비스에 대한 액세스에 제약 조건을 적용합니다. 예를 들어 보안이나 신뢰성에 부정적인 영향을 미칠 수 있는 명령어(예: 파일을 삭제하는 명령어)를 실행하려면 이러한 정책에서 다른 승인된 개인의 승인을 요구할 수 있습니다. 정책을 통해 특정 안전 명령어(예: 리소스 사용량을 나열하는 명령어)를 승인 없이 실행할 수도 있습니다. 이러한 유연성은 운영상 반복 업무를 최소화하는 데 중요합니다.

액세스 악용의 경우에도 계정은 여전히 안전 프록시에서 허용하는 작업으로 제한됩니다. 계정은 안전 명령어만 일방적으로 실행할 수 있으며 권한이 있는 작업을 수행하려면 다른 승인된 사용자가 승인해야 합니다. 모든 작업에 감사 추적이 명확하게 남습니다.

안전 프록시에 대한 자세한 내용은 제로 터치 프로덕션의 SREcon 프레젠테이션을 참조하세요. 제로 터치 프로덕션은 프로덕션의 모든 변경사항이 자동(관련된 사용자자 없음)으로 수행되거나 소프트웨어로 사전 검증되거나 감사된 긴급상황 지원 메커니즘으로 수행되도록 강제하는 원칙 및 도구 세트입니다.

주문형 액세스

주문형 액세스(AoD)를 사용하면 Google에서 영구 멤버십을 적격한 멤버십으로 바꿔 직원 권한을 줄일 수 있습니다.

적격한 역할 구성원도 권한에 액세스할 수 없습니다. 적격한 역할 구성원에게 액세스 권한이 필요하면 AoD 권한 부여라고 하는 임시 멤버십을 요청할 수 있습니다. 다른 승인된 개인이 승인하면 AoD 권한 부여를 통해 요청자가 제한된 기간 동안(일반적으로 1일 미만) 역할 구성원이 됩니다.

적격한 멤버십 모델을 사용하면 직원은 필요한 기간 동안 필요한 액세스 권한의 하위 집합만 요청할 수 있습니다. 개념적으로 AoD는 Unix의 sudo -u 명령어와 비슷하게 시간이 제한된 프로덕션 sudo로 생각할 수 있습니다. 이 명령어를 사용하면 지정된 사용자와 연결된 승격된 권한을 사용하여 일부 명령어를 실행할 수 있기 때문입니다. 그러나 Unix sudo와 달리 AoD 권한 부여를 받으려면 비즈니스 근거와 MPA가 필요하며 감사 추적이 남습니다. AoD 권한 부여에도 시간 제한이 있습니다.

적격한 멤버십 이면의 민감한 권한을 보호하면 드물지만 액세스 악용이 발생하더라도 활성 부여가 있는 경우에만 계정에서 이러한 권한에 액세스할 수 있습니다. 안전 프록시를 채택하면 이러한 부여가 거의 필요하지 않게 됩니다.

액세스 요청 모니터링

Google 프로덕션의 많은 영역에서 액세스 축소 관행으로 NoPe를 사용하지만 가장 민감한 프로덕션 역할에는 AoD 권한 부여가 매우 드물며 긴급 대응용으로만 예약되어 있습니다. 또한 각 이벤트는 추후 수동 감사를 트리거합니다. 감사 목표는 향후 AoD 권한 부여 빈도를 줄이는 것입니다(예: 이러한 이벤트를 사용하여 관리 API 개선 유도).

Google은 회사 전체에서 AoD 권한 부여 및 이러한 권한 부여를 유지하는 동안 수행한 작업을 지속적으로 모니터링합니다. Google은 실시간 모니터링 데이터를 사용하여 잠재적인 손상을 감지하고 추가 액세스 감소 영역을 파악합니다. 이슈가 발생하면 감사 추적에서 신속한 대응을 지원합니다.

Borg용 Binary Authorization

NoPe를 사용하면 권한 있는 액세스 경로를 보호할 수 있는 것처럼 Borg용 Binary Authorization(BAB)을 사용하면 Google 소프트웨어 공급망을 보호할 수 있습니다. BAB는 특히 프로덕션 소프트웨어와 작업 구성에서 민감한 정보에 액세스할 수 있는 경우 이들이 배포되기 전에 검토 및 승인되도록 보장합니다. 원래 Google의 프로덕션 인프라용으로 고안된 BAB의 주요 개념에는 이제 소프트웨어 아티팩트에 대한 공급망 등급(SLSA)라는 개방형 사양에 포함되었습니다.

BAB는 직원이 동료 검토 없이 소스 코드를 수정하거나 바이너리를 실행하거나 작업을 구성할 수 없게 하고 모든 바이너리 아티팩트나 소프트웨어 구성이 체크인된 동료 검토 소스 코드에서 검증 가능한 방식으로 빌드되도록 보장합니다.

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

프로덕션 머신 보호

Google은 권한 있는 액세스 경로 강화 및 소프트웨어 공급망 무결성 유지 외에도 프로덕션 서비스가 실행되는 머신을 보호합니다. 특히 다음을 구현합니다.

• 셸 액세스 제어: 대부분의 Google 직원은 프로덕션 머신 또는 Google 클러스터 관리 시스템인 Borg에서 실행되는 워크로드에 대한 셸 액세스(예: SSH를 통한 액세스)가 없습니다. 대신 개인은 다른 승인된 사용자가 명령어가 실행되기 전에 각 명령어를 검토하고 승인해야 하는 안전 프록시를 사용해야 합니다.

  하위 수준 인프라에서 작업하는 일부 팀만 일방적이지 않은 셸 액세스 권한을 유지하므로 안전 프록시를 실용적으로 사용할 수 없는 가장 복잡한 문제를 디버깅할 수 있습니다. 한 명 이상 추가된 승인된 직원의 승인이 필요하면 액세스는 일방적이지 않습니다. Google은 일방적인 셸 액세스가 허용되는 한 가지 예외를 적용합니다. 이는 Google에서 잠김 상황을 방지하는 방법을 확보하기 위함입니다.

• 물리적 액세스 제어: 머신이 제대로 작동하게 하려면 정기적인 물리적 유지보수가 필요합니다. 데이터 센터 기술자가 타당한 비즈니스 이유가 있을 때만 물리적 머신에 액세스할 수 있도록 Google은 물리적-논리적 제어를 사용합니다.

• 펌웨어 및 시스템 소프트웨어 제어: Google은 신뢰할 수 있는 하드웨어 루트를 기반으로 하는 측정된 부팅 보안 흐름을 구현합니다. 신뢰할 수 있는 하드웨어 루트를 통해 각 머신의 부팅 펌웨어와 시스템 소프트웨어의 무결성을 보장할 수 있습니다.

다음 다이어그램에서는 데이터 센터의 머신을 보호하는 데 도움이 되는 제어를 보여줍니다.

셸 액세스 제어

SSH는 Linux 기반 서버에 대한 광범위한 액세스를 허용하는 데 널리 사용되는 오픈소스 관리 도구입니다. SSH 액세스를 제어하지 않으면 올바른 사용자 인증 정보가 있는 계정에서 감사하기 어려운 방식으로 임의의 코드를 실행할 수 있는 셸을 가져올 수 있습니다.

프로덕션 서비스에 대한 셸 액세스를 사용하면 계정에서 예를 들어 실행 중인 태스크의 동작을 변경하거나 사용자 인증 정보를 추출하거나 사용자 인증 정보를 사용하여 환경에 지속적인 기반을 마련할 수 있습니다.

이 위험이 완화되도록 Google은 다음과 같은 제어 집합을 사용하여 프로덕션 머신에 대한 SSH 액세스를 안전한 대체 방법으로 바꿉니다.

• 좁은 API: 이전에 SSH가 필요했던 잘 정의된 워크플로가 있는 팀의 경우 SSH를 좁게 정의되고 감사 가능한 API로 바꿉니다.
• SSH용 안전 프록시: 더 유연한 액세스가 필요한 팀의 경우 안전 프록시를 사용하면 명령어를 개별적으로 승인하고 감사할 수 있습니다.
• MPA: SRE에서 머신에 대한 긴급 SSH 액세스가 필요한 경우 Google은 비즈니스 근거와 승인된 개인의 액세스 승인을 요구합니다. 전체 셸 세션 스크립트가 로깅됩니다.
• 잠금 시나리오: 일방적인 SSH 액세스가 허용되는 유일한 예외입니다. 전체 셸 세션 스크립트가 로깅됩니다.

이러한 제어는 적법한 셸 액세스의 니즈와 지나치게 광범위한 셸 액세스와 관련된 위험 간의 균형을 유지합니다.

배경: Google의 SSH

이전에 Google은 SSH를 사용하여 머신을 관리했습니다. Borg가 개발됨에 따라 대부분의 Google 직원이 바이너리를 실행하는 Linux 머신에 직접 액세스할 필요가 없게 되었지만 다음과 같은 몇 가지 이유로 셸 액세스는 유지되었습니다.

• 직원이 디버깅 목적으로 머신에 직접 액세스해야 하는 경우가 있습니다.
• SSH 액세스는 다양한 추상화 계층을 이해하는 데 유용한 교육 도구입니다.
• 예상치 못한 재해 복구 시나리오에서는 상위 수준 도구를 사용하지 못하게 될 수 있습니다.

이러한 이유와 그로 인해 발생한 보안 위험 간의 균형을 맞추기 위해 Google은 SSH 위험과 사용을 점진적으로 제거하기 위한 일련의 마일스톤을 추구했습니다.

중앙 집중식 모니터링 및 액세스 제어 마일스톤

Google은 호스트 ID 기반 모니터링 승인(HIBA)이라는 중앙 SSH 모니터링 및 승인 시스템에 투자했습니다. HIBA는 SSH 사용에 대한 가시성을 제공하고 엄격한 승인 정책을 시행할 수 있게 합니다. SSH 시도는 대상 머신뿐만 아니라 중앙 집중식 BeyondCorp 프록시에서도 로깅됩니다. 셸에서 실행되는 명령어는 로깅되고 악의적인 행동 감지 파이프라인에 전달됩니다. 그러나 감지는 본질적으로 반응적이며 회피와 난독화에 취약합니다.

일방적인 액세스 제거 마일스톤

Google은 대부분의 직원에게서 프로덕션 머신이나 Borg에서 실행되는 워크로드에 대한 셸 액세스(예: SSH를 통한 액세스)를 삭제했습니다. 하지만 개발팀에서 테스트 머신(예: 새 하드웨어 또는 새 하위 수준 소프트웨어를 검증하는 데 사용되지만 프로덕션 서비스를 실행하지 않는 머신)에 계속 액세스할 수 있도록 유지합니다.

좁은 API

이전에는 정확하게 정의된 명령어를 제한된 수로 실행하거나(예: 플레이북에서) 구조가 예측 가능한 데이터를 얻기 위해 SSH를 사용하는 일부 Google 팀은 이제 구체적인 사용 사례와 정형 데이터를 제공하는 좁게 정의된 API를 사용합니다.

좁은 API는 일반적인 사용자 여정에 맞는 소수의 메서드를 가지고 있으며 낮은 수준의 액세스 세부정보를 추상화합니다. 따라서 최고의 안전성과 감사 가능성을 제공하므로 Google에서 선호하는 솔루션입니다. Google은 좁은 API를 리모트 프러시저 콜(RPC) 인프라에 빌드함으로써 수십 년간 진행된 보안 및 감사 투자로부터 이점을 얻고 있습니다.

SSH용 안전 프록시

일부 Google 팀에서는 사전에 필요할 수 있는 명령어를 결정할 수 없습니다. 이 경우 Google은 보안팀에서 실행하는 신뢰할 수 있는 프록시의 임의 명령어 실행 요청만 수락하는 명령어 실행 데몬을 사용합니다. 이 기술은 NoPe용 안전 프록시에서 사용되는 기술과 유사합니다.

SSH용 안전 프록시는 명령어 실행의 세분화된 승인과 감사를 담당합니다. 승인은 명령어의 인수와 환경, 비율 제한 매개변수, 비즈니스 근거, MPA를 기반으로 합니다. 이 승인 프로세스를 통해 다음 팀 플레이북과 권장사항을 실행할 수 있는 명령어를 임의로 정확하게 제한할 수 있습니다. 기존 플레이북에서 캡처되지 않은 예기치 않은 실패 조건에서 직원은 다른 승인된 개인이 승인한 후에도 필요한 디버깅 명령어를 계속 실행할 수 있습니다.

SSH용 MPA

하위 수준 인프라에서 작업하는 나머지 소수의 팀은 가장 복잡한 문제를 디버그하기 위해 일방적이지 않은 형태의 셸 액세스를 유지합니다.

잠금 시나리오에서 SSH

Google은 잠금 상황을 해결할 수 있도록 일방적인 셸 액세스가 허용되는 예외를 적용합니다. 이 목적으로 사용되는 SSH 키는 고유한 감사 가능한 프로세스로 생성되고 변조 방지 하드웨어에 오프라인으로 저장됩니다. 이러한 키를 사용하면 전체 셸 세션 스크립트가 로깅됩니다.

물리적 액세스 제어

Google 데이터 센터는 서버, 네트워킹 기기, 제어 시스템으로 구성된 복잡한 환경으로, 이를 관리, 유지보수, 운영하는 데 다양한 역할과 기술이 필요합니다.

Google은 데이터 센터의 워크로드를 보호하기 위해 머신 자체에 물리적 제어 레이어 6개와 여러 논리적 제어를 구현합니다. 또한 Google은 물리적-논리적 공간이라고 하는 머신 사이의 공간을 방어합니다.

물리적-논리적 제어는 머신 강화, 태스크 기반 액세스 제어, 시스템 자체 방어라고 하는 제어를 통해 방어를 강화합니다. 물리적-논리적 제어는 머신에 대한 물리적 액세스를 악용하고 머신의 워크로드에 대한 논리적 공격으로 에스컬레이션하려는 공격자를 방어합니다.

자세한 내용은 Google이 데이터 센터에서 물리적-논리적 공간을 보호하는 방법을 참조하세요.

펌웨어 및 시스템 소프트웨어 제어

데이터 센터 머신의 보안 상황은 부팅 시에 설정됩니다. 머신의 부팅 프로세스는 머신의 하드웨어를 구성하고 운영체제를 초기화하면서 Google의 프로덕션 환경에서 머신을 안전하게 실행합니다.

부팅 프로세스의 각 단계에서 Google은 기대하는 부팅 상태를 시행하고 고객 데이터를 보호하는 데 도움이 되도록 업계 최고의 제어를 구현합니다. 이러한 제어를 통해 머신이 의도한 소프트웨어로 부팅되도록 할 수 있으므로 머신의 초기 보안 상황을 손상시킬 수 있는 취약점을 삭제할 수 있습니다.

자세한 내용은 Google이 프로덕션 머신에서 부팅 무결성을 적용하는 방법을 참조하세요.

워크로드 보호

또한 Google의 제로 트러스트 철학에 따라 Google은 다양한 보안 요구사항이 있는 워크로드 간의 측면 이동 위협을 방어하는 데 도움이 되는 제어를 도입했습니다. Google 인프라는 워크로드 보안 링(WSR)이라는 워크로드 계층 구조를 사용합니다. WSR을 사용하면 보안 수준이 낮은 워크로드와 동일한 머신에 중요한 워크로드가 예약되지 않게 하면서 리소스 활용도에 부정적인 영향을 미치지 않도록 할 수 있습니다. WSR은 워크로드를 4가지 민감도 클래스(기본, 민감, 강화, 강화 없음)로 그룹화하고 다른 머신 풀에서 예약하려고 시도합니다.

다음 다이어그램에서는 WSR이 기본, 프로덕션, 개발 머신에서 워크로드를 그룹화하고 예약하는 방식을 보여줍니다.

WSR은 커널 취약점 공격이나 CPU 사이드 채널 공격을 사용하여 로컬 권한 에스컬레이션에 대한 방어를 강화합니다. WSR을 사용하면 유사한 보안 요구사항이 있는 워크로드만 같은 머신에서 공동 예약되도록 할 수 있습니다. WSR을 구현하기 위해 Google은 다음을 수행합니다.

• 보안 요구사항에 따라 워크로드를 분류합니다. 각 클래스를 워크로드 링이라고 합니다.
• 물리적 머신을 서로 격리된 여러 머신 풀에 분산합니다. 즉, 풀 사이의 측면 이동 경로를 제거합니다.
• 예약 제약 조건을 적용하여 보안 요구사항이 다른 워크로드가 같은 머신에서 실행되지 않도록 합니다. 이러한 예약 제약 조건은 로컬 권한 에스컬레이션을 통해 손상 위험을 완화합니다.

예를 들어 WSR을 사용하려면 기본 워크로드가 전용 머신에서 실행되고 기본이 아닌 워크로드와 함께 예약되지 않도록 해야 합니다. 이 제약 조건은 보안 수준이 낮은 워크로드로부터의 강력한 격리를 제공합니다.

워크로드 격리 방법

최신 시스템 소프트웨어는 복잡하며 보안 연구원은 커널 제로데이 취약점 악용이나 새로운 CPU 부채널 공격과 같은 로컬 권한 에스컬레이션 취약점을 주기적으로 감지합니다. USENIX ;login:에서 처음 소개된 WSR을 사용하면 Google에서 높은 리소스 활용도를 유지하면서 워크로드 공동 배치와 관련된 위험을 줄일 수 있습니다.

기본적으로 Borg는 OS 수준 프로세스 경계를 사용하여 컨테이너를 격리합니다. 이러한 프로세스는 하드웨어 기반 가상화를 사용하는 가상 머신보다 약한 격리 경계를 제공합니다. 이러한 약한 격리는 일반적으로 신뢰할 수 있는 워크로드를 실행하는 멀티 테넌트 환경의 효율성과 보안 간의 적절한 절충안입니다. 신뢰할 수 있는 워크로드는 바이너리와 구성이 확인된 출처의 동료 검토 코드에서 검증 가능하게 빌드된 워크로드입니다. 신뢰할 수 있는 워크로드는 임의의 신뢰할 수 없는 데이터를 처리하지 않습니다. 신뢰할 수 없는 데이터를 처리하는 예시로는 서드 파티 코드 호스팅 또는 동영상 인코딩이 있습니다.

Google은 BAB를 사용하여 바이너리에 대한 신뢰를 얻습니다. 그러나 BAB는 신뢰할 수 없는 데이터를 처리하는 워크로드의 무결성을 보장하기에 부족합니다. BAB 외에도 이러한 워크로드는 샌드박스 내에서 실행되어야 합니다. 샌드박스는 gVisor와 같은 제한된 환경으로, 바이너리를 안전하게 실행할 수 있게 해 줍니다. BAB와 샌드박스 모두 제한사항이 있습니다.

BAB는 성숙한 제품을 위한 강력한 제어이지만 새로운 시스템 개발 초기 단계와 민감한 정보 없이 실험을 실행할 때(예: 이미 공개된 데이터 인코딩 최적화) 속도가 저하될 수 있습니다. 이러한 제한사항으로 인해 일부 워크로드는 항상 BAB 없이 실행되어야 합니다. 이러한 워크로드에는 기본적으로 로컬 권한 에스컬레이션의 위험이 높습니다(예: 커널 취약점을 악용하여 머신에서 로컬 루트 얻기).

신뢰할 수 없는 워크로드를 샌드박스 처리하면 보안 위험을 완화할 수 있지만 컴퓨팅 및 메모리 사용이 증가한다는 단점이 있습니다. 워크로드와 샌드박스 유형에 따라 효율성이 두 자릿수 백분율까지 떨어질 수 있습니다. 샌드박스 처리된 워크로드가 성능에 미치는 영향의 예시는 gVisor 성능 가이드에서 자세한 벤치마크를 참조하세요. WSR을 사용하면 워크로드 격리로 발생하는 효율성 제한사항을 해결할 수 있습니다.

워크로드 링

Google은 보안 요구사항에 따라 워크로드의 네 가지 클래스(기본, 민감, 강화, 강화되지 않음)를 정의합니다. 다음 표에서 이를 자세히 설명합니다.

워크로드 링	설명
기본	ID 및 액세스 관리 서비스와 같은 Google 보안에 중요한 워크로드. 기본 워크로드에는 가장 높은 보안 요구사항이 있으며 보안과 신뢰성 강화를 위해 일상적으로 효율성을 희생합니다.
민감	광범위한 서비스 중단을 일으킬 수 있거나 사용자 또는 고객 데이터와 같은 민감한 제품별 데이터에 액세스할 수 있는 워크로드
강화	보안에 중요하지 않지만 BAB를 채택했거나 샌드박스 처리된 워크로드를 지원하므로 인접한 워크로드에 거의 위험을 주지 않습니다.
강화되지 않음	신뢰할 수 없는 코드를 실행하는 워크로드를 포함한 기타 모든 워크로드.

Google에서는 특정 제품을 지원하는 중요한 워크로드를 민감으로 분류하고 모든 제품에 영향을 줄 수 있는 워크로드를 기본 워크로드로 분류합니다.

기본 및 민감과 달리 채택된 제어와 처리되는 입력 유형만을 기준으로 모든 워크로드를 강화로 분류할 수 있습니다. 강화된 워크로드가 있을 때는 주로 다른 워크로드에 미치는 영향을 중요하게 생각하므로 솔루션 강화에 샌드박스가 포함될 수 있습니다.

머신 풀

신뢰도가 낮은 워크로드(예: 샌드박스 없이 신뢰할 수 없는 데이터를 처리하는 워크로드)와 민감한 서비스를 함께 예약하지 않으려면 격리된 머신 풀에서 이러한 서비스를 실행해야 합니다. 머신 격리를 사용하면 변하지 않는 보안 요소를 더 쉽게 이해할 수 있지만 머신 풀이 추가될 때마다 리소스 사용률과 유지보수 간에 절충됩니다.

머신 격리를 사용하면 물리적 리소스 사용률이 낮아집니다. 풀을 더 추가할수록 머신 풀이 완전히 활용되도록 하는 것이 더 어려워지기 때문입니다. 크고 격리된 머신 풀이 여러 개 있으면 효율성 비용이 높아질 수 있습니다.

각 풀에서 워크로드의 리소스 사용 공간이 변동함에 따라 엄격한 격리에서 주기적으로 풀 간의 머신을 재조정하고 재구성하도록 관리 오버헤드를 추가합니다. 이렇게 재조정하려면 머신에서 모든 워크로드를 드레이닝하고 머신을 재부팅하며 펌웨어 신뢰성과 무결성을 보장하는 데 도움이 되는 가장 엄격한 머신 정리 프로세스를 수행해야 합니다.

이러한 고려 사항은 Google의 머신 격리 구현에서 물리적 리소스 사용률을 최적화하는 동시에 기본 및 민감한 워크로드를 공격자로부터 방어할 수 있는 방법을 제공해야 한다는 것을 의미합니다.

Kubernetes에서는 이 방식을 노드 격리라고 합니다. Kubernetes 노드는 물리적 머신이나 가상 머신에 매핑될 수 있습니다. 이 문서에서는 물리적 머신에 중점을 둡니다. 또한 Compute Engine과 같은 Google Cloud 제품은 단독 테넌시를 제공하여 물리적 머신 격리를 제공합니다.

워크로드 예약 제약 조건

Google은 머신을 기본 머신, 프로덕션 머신, 개발 머신 등 세 가지 유형의 격리된 풀로 프로비저닝합니다. Google은 기본 워크로드와 민감한 워크로드를 호스팅하는 격리된 풀 여러 개를 운영하지만 이 문서에서는 편의상 각 풀을 풀 하나로 표시합니다.

가장 효과적인 보호를 제공하기 위해 Google은 WSR에 다음과 같은 예약 제약 조건을 배포합니다.

• 기본 워크로드는 기본 머신에서만 실행될 수 있습니다.
• 민감한 워크로드는 프로덕션 머신에서만 실행될 수 있습니다.
• 강화되지 않은 워크로드는 개발 머신에서만 실행될 수 있습니다.
• 강화된 워크로드는 프로덕션 머신이나 개발 머신에서 실행될 수 있지만 프로덕션 머신이 우선시됩니다.

다음 다이어그램에서는 예약 제약 조건을 보여줍니다.

이 다이어그램에서 격리 경계는 머신 풀 간에 그리고 머신 풀 내에서 서로 다른 워크로드 클래스를 구분합니다. 기본 워크로드는 전용 기본 머신의 단독 테넌트입니다. 프로덕션 머신에서 실행되는 워크로드에 대한 Binary Authorization 또는 샌드박스는 로컬 권한 에스컬레이션 공격을 방지하는 데 도움이 됩니다. 개발 머신에서는 강화되지 않은 워크로드가 다른 워크로드를 손상시킬 수 있는 위험이 남아 있지만 강화된 워크로드에서 새 작업을 만들 수 없으므로 손상을 개발 머신으로 제한됩니다.

강화된 워크로드는 가용성에 따라 프로덕션 머신이나 개발 머신에 예약됩니다. 여러 풀에서 예약을 허용하는 것이 직관적이지 않다고 보일 수 있지만 예약 제약 조건으로 인한 사용률 감소를 완화하는 데 필수적입니다. 강화된 워크로드는 민감한 작업과 강화되지 않은 작업을 격리하여 발생하는 간격을 메웁니다. 또한 강화된 리소스 사용 공간이 클수록 링 간 값비싼 머신을 이동할 필요 없이 다른 두 클래스의 리소스 사용량 변동을 더 많이 수용할 수 있습니다.

다음 다이어그램에서는 여러 워크로드 클래스에 적용되는 예약 제약 조건을 보여줍니다. 강화된 워크로드는 프로덕션 머신이나 개발 머신에 위치할 수 있습니다.

Google은 여러 기본 풀에서 기본 워크로드를 격리하여 리소스 효율성을 높이는 대신 보안을 강화합니다. 다행히도 기본 워크로드는 상대적으로 리소스 사용 공간이 작고 전용 머신의 소규모 격리된 풀은 전반적인 사용량에 큰 영향을 미치지 않습니다. 하지만 다양한 자동화를 도입하더라도 여러 머신 풀을 유지하는 데 비용이 발생하지 않으므로 격리가 향상되도록 머신 설계를 지속적으로 발전시키고 있습니다.

WSR은 기본이 아닌 워크로드가 기본 머신에서 실행되지 않게 합니다. 기본 워크로드만 기본 머신에서 실행될 수 있으므로 기본 머신은 측면 이동으로부터 보호됩니다.

제어 요약

Google은 인프라 전반에서 다양한 제어를 사용하여 프로덕션 서비스, 프로덕션 머신, 워크로드를 보호합니다. 제어는 다음과 같습니다.

• 프로덕션 서비스의 관리 액세스 제어 및 BAB
• 프로덕션 머신의 셸 액세스 제어, 물리적 액세스 제어, 펌웨어 및 시스템 소프트웨어 제어
• 다양한 워크로드 클래스의 WSR

이러한 제어를 함께 사용하면 Google 사용자와 고객, 그들의 데이터를 보호하는 데 도움이 되는 제약 조건을 적용할 수 있습니다. 다음 다이어그램에서는 Google 보안 상황이 지원되도록 제어가 함께 작동하는 방식을 보여줍니다.

다음 단계

• Google 인프라의 보안 제어에 대한 자세한 내용은 Google 인프라 보안 설계 개요를 참조하세요.
• Google 보안 문화에 대한 자세한 내용은 안전하고 안정적인 시스템 구축(O'Reilly 도서)을 참조하세요.
• 제로터치 프로덕션에 대한 자세한 내용은 SREcon 프레젠테이션을 참조하세요.

저자: 미카엘 차피니스키, 케빈 플리본