분리형 머신의 원격 증명

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

이 문서에서는 데이터 센터 머신 증명에 대한 Google 방식을 설명합니다. 이 문서에서 설명하는 아키텍처는 신뢰 플랫폼 모듈(TPM), 보안 프로토콜 및 데이터 모델(SPDM) 및 Redfish과 같은 개방형 표준과 통합되도록 설계되었습니다. 데이터 센터 머신 증명과 관련해 Google에서 제안한 새로운 표준이나 참조 구현은 GitHub의 플랫폼 무결성(PINT) 프로젝트를 참조하세요. 이 문서는 보안 임원, 보안 설계자, 감사관을 대상으로 합니다.

개요

Google은 분리형 데이터 센터 머신을 설계하고 배포합니다. 많은 머신이 신뢰할 수 있는 단일 루트 대신 측정(RTM), 스토리지, 업데이트, 복구용 신뢰할 수 있는 루트를 포함하여 별도의 신뢰할 수 있는 루트를 포함합니다. 각 RTM은 전체 머신의 하위 섹션을 제공합니다. 예를 들어 머신에는 기본 CPU에서 부팅된 항목을 측정하고 증명하는 RTM 하나와 PCIe 슬롯에 연결된 SmartNIC에서 부팅된 항목을 측정하고 증명하는 다른 RTM이 있을 수 있습니다. 다음 다이어그램에서는 예시 머신을 보여줍니다.

머신의 여러 RTM이 복잡하면 데이터 센터 머신의 막대한 규모와 기대치가 추가되고 인간, 하드웨어 또는 소프트웨어 장애로 인해 발생할 수 있는 다양한 문제가 발생합니다. 요약하면 Fleet의 펌웨어 무결성 보장은 사소한 작업이 아닙니다.

이 문서에 설명된 시스템은 분리형 머신의 원격 증명 문제를 보다 쉽게 관리할 수 있도록 설계되었습니다. 이 증명 인프라는 확장 가능하므로 데이터 센터에 나타나는 것처럼 훨씬 복잡한 머신을 처리하도록 조정할 수 있습니다.

Google의 목표는 이 작업을 공유하여 분리형 머신 증명을 대규모로 수행하는 방법에 대한 관점을 제공하는 것입니다. Google은 업계 파트너와의 협업과 분산 관리 태스크 포스(DMTF), 신뢰할 수 있는 컴퓨팅 그룹(TCG), 오픈 컴퓨팅 프로젝트(OCP)와 같은 표준 기관의 기여를 통해 혁신적인 보안을 계속 지원할 예정입니다.

권장 RTM 속성

이 섹션에서는 RTM에 권장되는 몇 가지 속성을 소개합니다.

RTM 하드웨어 통합

프로세서가 RTM과 연결되면 RTM은 프로세서에서 실행되는 변경 가능한 첫 번째 코드를 통해 측정 값을 캡처해야 합니다. 후속 변경 가능 코드에는 코드가 실행되기 전에 신뢰할 수 있는 루트에 캡처 및 보고된 측정 값이 있어야 합니다. 이 배열은 프로세서의 보안이 중요한 상태를 견고하게 증명하는 신중한 부팅 체인을 생성합니다.

RTM 하드웨어 및 펌웨어 ID 증명

각 RTM에는 외부 유효성 검사를 위해 증명을 내보내는 데 사용되는 서명 키 쌍이 있어야 합니다. 이 키 쌍의 인증서 체인에는 RTM의 고유한 하드웨어 ID에 대한 암호화 증거와 RTM 내에서 실행되는 변경 가능한 코드의 펌웨어 ID가 포함되어야 합니다. 인증서 체인은 RTM 제조업체를 기반으로 합니다. 이 방법을 사용하면 머신이 치명적인 RTM 펌웨어 취약점에서 복구될 수 있습니다.

기기 식별자 구성 엔진(DICE) 사양은 증명 솔루션에 사용되는 패턴의 공식화입니다. RTM 제조업체는 고유한 기기 키 쌍을 인증하며 이는 RTM의 하드웨어 ID 및 펌웨어 이미지와 관련된 별칭 키 쌍을 인증합니다. 별칭 키 인증서 체인에는 RTM 펌웨어 및 RTM의 일련번호 측정값이 포함됩니다. 확인자는 지정된 별칭 키로 서명된 모든 데이터가 해당 별칭 키의 인증서 체인에 삽입된 암호화 하드웨어와 펌웨어 ID 측정에 설명된 RTM에서 방출되었음을 확신할 수 있습니다.

원격 증명 작업

증명 스킴은 사용자 데이터와 작업이 원하는 부팅 스택을 실행하는 머신에만 발급되도록 보장하면서, 문제 해결을 위해 Fleet 유지보수 자동화를 계속 수행할 수 있도록 설계되었습니다. 내부 클라우드에서 호스팅되는 작업 스케줄러 서비스는 머신 내에서 RTM 수집에 도전하고 증명된 측정 결과를 해당 머신에 고유한 정책과 비교할 수 있습니다. 스케줄러는 증명된 측정값이 머신 정책을 준수하는 경우에만 머신에 작업과 사용자 데이터를 발급합니다.

원격 증명에는 다음과 같은 두 작업이 포함됩니다.

• 증명 정책 생성: 머신에서 사용할 하드웨어나 소프트웨어가 변경될 때마다 발생합니다.

• 증명 확인: 머신 확인 흐름의 정의된 지점에서 발생합니다. 이러한 지점 중 하나는 머신에서 작업이 예약되기 직전입니다. 머신은 증명 확인을 통과한 후에만 작업과 사용자 데이터에 액세스할 수 있습니다.

증명 정책

Google은 정책이라고 하는 서명된 머신에서 읽을 수 있는 문서를 사용하여 머신 내에서 실행될 것으로 예상되는 하드웨어와 소프트웨어를 설명합니다. 이 정책은 머신의 RTM 컬렉션에서 증명될 수 있습니다. 각 RTM에 대한 다음 세부정보가 정책에 표시됩니다.

• RTM에서 내보내는 증명의 유효성을 검사할 수 있는 신뢰할 수 있는 ID 루트 인증서입니다.
• RTM을 고유하게 식별하는 전역적으로 고유한 하드웨어 ID입니다.
• RTM에서 실행되어야 하는 예상 버전을 설명하는 펌웨어 ID입니다.
• RTM에서 보고되는 각 부팅 단계의 측정 기대치입니다.
• Redfish 리소스 이름과 유사한 RTM의 식별자입니다.
• 머신 내에서 RTM을 물리적 위치에 연결하는 식별자입니다. 이 식별자는 Redfish 리소스 이름과 유사하며 자동 머신 복구 시스템에 사용됩니다.

또한 정책에는 승인되지 않은 정책 롤백을 방지하는 데 도움이 되는 전역적으로 고유한 취소 일련번호가 포함됩니다. 다음 다이어그램에서는 정책을 보여줍니다.

다이어그램에서는 정책의 다음 항목을 보여줍니다.

• 서명은 정책 인증을 제공합니다.
• 해지 일련번호는 롤백을 방지할 수 있는 정책 최신 상태를 제공합니다.
• RTM 기대치는 머신의 각 RTM에 대한 세부정보를 열거합니다.

다음 섹션에서는 이러한 항목을 자세히 설명합니다.

정책 조립

머신의 하드웨어를 조립하거나 수리하면 해당 머신의 모든 예상 RTM을 정의하는 하드웨어 모델이 생성됩니다. Google의 제어 영역은 부품 교체나 하드웨어 업그레이드와 관련된 복구와 같은 이벤트 전반에서 이 정보를 최신 상태로 유지하는 데 도움이 됩니다.

또한 제어 영역은 머신에 설치될 소프트웨어에 대한 기대치와 어떤 RTM이 어떤 소프트웨어를 측정해야 하는지에 대한 기대치를 유지합니다. 제어 영역은 하드웨어 모델과 함께 이러한 기대치를 사용하여 머신의 예상 상태를 설명하는 서명되고 취소 가능한 증명 정책을 생성합니다.

그런 다음 서명된 정책이 설명하는 머신의 영구 스토리지에 기록됩니다. 이 방식은 머신을 증명할 때 원격 확인자에 필요한 네트워크와 서비스 종속 항목의 수를 줄이는 데 도움이 됩니다. 확인자는 정책의 데이터베이스를 쿼리하는 대신 머신 자체에서 정책을 가져올 수 있습니다. 이 방식은 작업 스케줄러에 엄격한 SLO 요구사항이 있고 가용성이 높게 유지되어야 하므로 중요한 설계 기능입니다. 다른 서비스에서 이러한 머신의 네트워크 종속 항목을 줄이면 서비스 중단 위험을 줄이는 데 도움이 됩니다. 다음 다이어그램에서는 이 이벤트 흐름을 보여줍니다.

다이어그램에서는 제어 영역이 정책 조립 프로세스에서 완료되는 다음과 같은 단계를 설명합니다.

• 소프트웨어 패키지 할당 및 머신 하드웨어 모델에서 증명 정책을 가져옵니다.
• 정책에 서명합니다.
• 데이터 센터 머신에 정책을 저장합니다.

정책 취소

지정된 머신의 하드웨어 및 소프트웨어 인텐트는 시간이 경과함에 따라 변경됩니다. 인텐트가 변경되면 이전 정책을 취소해야 합니다. 각 서명된 증명 정책에는 고유한 해지 일련번호가 포함됩니다. 확인자는 서명된 정책을 인증하는 데 적합한 공개 키 및 정책이 여전히 유효한지 확인하는 데 적합한 인증서 해지 목록을 가져옵니다.

키 서버 또는 취소 데이터베이스를 양방향으로 쿼리하면 작업 스케줄러의 가용성이 영향을 받습니다. 대신 Google에서는 비동기 모델을 사용합니다. 서명된 증명 정책을 인증하는 데 사용되는 공개 키 집합은 각 머신의 기본 운영체제 이미지의 일부로 푸시됩니다. CRL은 Google에서 다른 사용자 인증 정보 유형에 사용하는 시스템과 동일한 중앙 집중식 취소 배포 시스템을 사용하여 비동기적으로 푸시됩니다. 이 시스템은 사고 응답 조건 중에서도 신속하게 비상 푸시를 수행할 수 있도록 정상 조건 중에 안정적으로 작동하도록 설계되었습니다.

확인자 머신의 로컬에 저장된 확인 공개 키와 CRL 파일을 사용하여 중요 경로에 외부 서비스를 사용하지 않고도 원격 머신의 증명문의 유효성을 검사할 수 있습니다.

증명 정책 검색 및 측정 결과 유효성 검사

머신을 원격으로 증명하는 프로세스는 다음 단계로 구성됩니다.

• 증명 정책 검색 및 유효성 검사
• 머신의 RTM에서 증명된 측정값을 가져오기
• 증명된 측정값을 정책과 비교하여 평가

다음 다이어그램 및 섹션에서는 이러한 단계를 자세히 설명합니다.

증명 정책 검색 및 유효성 검사

원격 확인자는 머신의 서명된 증명 정책을 검색합니다. 정책 어셈블리에서 언급한 대로 가용성 이유로 정책은 대상 머신에 서명된 문서로 저장됩니다.

반환된 정책이 신뢰할 수 있는지 확인하기 위해 원격 확인자는 관련 CRL의 확인자 로컬 복사본을 참조합니다. 이 작업을 수행하면 신뢰할 수 있는 기관에서 검색된 정책을 암호화 서명했고 정책이 취소되지 않았는지 확인할 수 있습니다.

증명된 측정값 가져오기

원격 확인자는 머신에 문제가 발생하여 각 RTM에서 측정값을 요청합니다. 확인자는 이러한 요청에 암호화 nonce를 포함하여 최신 상태를 유지합니다. 베이스보드 관리 컨트롤러(BMC)와 같은 머신 내 항목은 각 요청을 각 RTM으로 라우팅하고 서명된 응답을 수집하며 원격 확인자에게 다시 보냅니다. 이 머신 내 항목은 RTM의 서명된 측정을 전송만 하므로 증명 관점에서 이 항목에는 권한이 없습니다.

Google은 내부 API를 사용하여 측정을 증명합니다. 또한 SPDM을 사용하여 머신이 아닌 확인자가 RTM 측정에 대한 BMC에 도전할 수 있도록 Redfish에 개선사항을 제공하고 있습니다. 내부 머신 라우팅은 다음을 포함한 구현별 프로토콜과 채널을 통해 수행됩니다.

• 서브넷을 통한 Redfish
• 지능형 플랫폼 관리 인터페이스(IPMI)
• i2c/i3c를 통한 관리 구성요소 전송 프로토콜(MCTP)
• PCIe
• 직렬 주변기기 인터페이스(SPI)
• USB

증명된 측정 평가

Google의 원격 확인자는 각 RTM에서 내보낸 서명의 유효성을 검사하여 머신의 증명 정책에 포함된 RTM ID로 다시 루트합니다. RTM의 인증서 체인에 있는 모든 하드웨어 및 펌웨어 ID는 정책에 따라 유효성이 검사되어 각 RTM이 올바른 인스턴스이고 올바른 펌웨어를 실행하도록 보장합니다. 최신 상태를 유지하기 위해 서명된 암호화 nonce가 검사됩니다. 마지막으로 증명된 측정은 해당 기기의 정책 예상과 일치하는지 확인합니다.

원격 증명 결과에 대응

증명이 완료된 후에는 증명된 머신의 운명을 결정하는 데 결과를 사용해야 합니다. 다이어그램과 같이 두 가지 가능한 결과가 있습니다. 즉, 증명이 성공했고 머신에 태스크 사용자 인증 정보와 사용자 데이터가 발급되거나 증명이 실패하고 알림이 복구 인프라로 전송됩니다.

다음 섹션에서는 이러한 프로세스를 자세히 설명합니다.

실패한 증명

머신 증명이 실패하면 Google은 머신을 사용하여 고객 작업을 제공하지 않습니다. 대신 머신 이미지를 자동으로 재설치하려는 복구 인프라로 알림이 전송됩니다. 악의적인 인텐트로 인해 증명 실패가 발생할 수 있지만 대부분의 증명 실패는 소프트웨어 출시의 버그로 인한 것입니다. 따라서 증명 실패가 갈수록 증가하는 출시의 경우 더 많은 머신에서 증명 실패가 발생하지 않도록 자동으로 중지됩니다. 이 이벤트가 발생하면 SRE에 알림이 전송됩니다. 자동화된 이미지 재설치에 의해 수정되지 않은 머신의 경우 출시가 롤백되거나 수정된 소프트웨어가 출시됩니다. 머신이 성공적인 원격 증명을 다시 받을 때까지 고객 작업을 지원하는 데 사용되지 않습니다.

성공한 증명

머신 원격 증명이 성공하면 Google은 머신을 사용하여 Google Cloud 고객을 위한 VM 또는 Google 포토의 이미지 처리와 같은 프로덕션 작업을 제공합니다. Google에서는 네트워크 서비스가 포함된 모든 의미 있는 작업을 단기 LOAS 작업 사용자 인증 정보로 관리하도록 요구합니다. 이러한 사용자 인증 정보는 성공적인 증명 도전과제 이후 보안 연결을 통해 부여되며 작업에 필요한 권한을 제공합니다. 이러한 사용자 인증 정보에 대한 자세한 내용은 애플리케이션 레이어 전송 보안을 참조하세요.

소프트웨어 증명은 해당 소프트웨어를 빌드하는 인프라만큼만 우수합니다. 결과 아티팩트가 인텐트를 정확하게 반영하도록 Google은 빌드 파이프라인의 무결성에 많은 투자를 했습니다. 소프트웨어 공급망 무결성 및 신뢰성을 해결하기 위해 Google에서 제안한 표준에 대한 자세한 내용은 소프트웨어 공급망 무결성을 참조하세요.

다음 단계

BeyondProd이 Google 데이터 센터 머신의 보안 연결 설정에 어떤 도움을 주는지 알아보세요.