보안 패치
이 문서에서는 Google에서 보안 취약점을 관리하고 Google Kubernetes Engine(GKE) 및 GKE Enterprise에 패치를 적용하는 방법을 설명합니다. 별도로 표시되지 않은 한 GKE Enterprise에는 GKE 및 GKE Enterprise 플랫폼이 모두 포함됩니다.
이 페이지는 지원팀에서 에스컬레이션한 이슈 및 문제와 같이 전략적 지원이 필요한 보안 문제 또는 취약점의 해결을 지원하는 보안 전문가를 위해 마련되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 작업에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 작업을 참조하세요.
공유 책임 패치
패치는 Google과 고객이 공유하는 책임입니다. 플랫폼마다 공유하는 책임이 다릅니다. 자세한 내용은 각 플랫폼에 대한 다음 주제를 참조하세요.
취약점을 찾는 방법
Google에서는 선제적인 보안 설계 및 강화에 막대한 투자를 했지만, 최고의 설계 소프트웨어 시스템에도 취약점은 있을 수 있습니다. 이러한 취약점을 발견하고 악용되기 전에 패치하기 위해 Google에서는 여러 측면에 상당한 투자를 했습니다.
패치를 위해 GKE Enterprise는 컨테이너가 실행되는 운영체제(OS) 계층입니다. Container-Optimized OS 또는 Ubuntu는 강화된 운영체제이며 컨테이너를 실행하는 데 필요한 최소 소프트웨어 양을 포함합니다. GKE Enterprise 기능은 컨테이너로서 기본 이미지 위에 실행됩니다.
Google에서는 다음과 같은 방법으로 취약점과 누락된 패치를 식별하고 수정합니다.
Container-Optimized OS: Google에서는 이미지를 스캔하여 잠재적인 취약점 및 누락된 패치를 식별합니다. Container-Optimized OS팀은 문제를 검토하고 해결합니다.
Ubuntu: Canonical은 사용 가능한 모든 보안 패치가 적용된 OS 빌드를 Google에 제공합니다.
Google에서는 Container Registry Artifact Analysis을 통해 컨테이너를 스캔하여 Kubernetes 및 Google 관리 컨테이너에서 취약점과 누락된 패치를 찾습니다. 수정 사항이 있는 경우 스캐너가 자동으로 패치 및 출시 프로세스를 시작합니다.
Google에서는 자동화된 스캔 외에도 다음과 같은 방법으로 스캐너가 감지하지 못하는 취약점을 발견하고 패치합니다.
Google에서는 모든 GKE Enterprise 플랫폼에서 자체 감사, 침투 시험, 취약점 감지를 수행합니다. Google 내부의 숙련된 팀과 신뢰할 수 있는 제3자 보안 공급업체는 자체 공격 연구를 수행합니다. 또한 Google에서는 CNCF와 협력하여 Kubernetes 보안 감사를 위해 구성 및 기술 컨설팅 전문 지식을 제공하고 있습니다.
Google에서는 여러 가지 취약점 발견 보상 프로그램을 통해 보안 연구 커뮤니티와 적극적으로 소통합니다. Google Cloud의 취약점 리워드 프로그램은 매년 중대한 클라우드 취약점을 발견한 대가로 133,337달러를 제공하는 등 큰 혜택을 제공합니다. GKE의 경우 보안 제어를 침투할 수 있는 보안 연구원에게 보상하는 프로그램이 있습니다. 이 프로그램은 모든 GKE 소프트웨어 종속 항목에 적용됩니다.
Google에서는 취약점이 공개되기 전에 취약점, 보안 연구 및 패치를 공유하는 다른 업계 및 오픈소스 소프트웨어 파트너와 협력합니다. 이 공동작업의 목적은 취약점이 공개되기 전에 대규모 인터넷 인프라를 패치하는 것입니다. Google에서는 경우에 따라 발견된 취약점을 이 커뮤니티에 반영합니다. 예를 들어 Google의 Project Zero는 스펙터 및 멜트다운 취약점을 발견하고 공개했습니다. 또한 Google Cloud 보안팀은 정기적으로 커널 기반 가상 머신(KVM)의 취약점을 찾아 수정합니다.
Google의 보안 공동작업은 여러 수준에서 이루어집니다. 때로는 Kubernetes 및 Envoy와 같은 제품의 소프트웨어 취약점에 대한 출시 전 알림을 받기 위해 조직에서 등록한 프로그램을 통해 공식적으로 이루어집니다. 공동작업은 Linux 커널, 컨테이너 런타임, 가상화 기술 등과 같은 여러 오픈소스 프로젝트와의 참여로 인해 비공식적으로 발생하기도 합니다.
Kubernetes의 경우 Google은 활발하게 활동 중인 Security Response Committee(SRC)의 창립 구성원으로서 Security Release Process의 대부분을 작성했습니다. Google은 거의 모든 심각한 Kubernetes 보안 취약점의 분류, 패치, 완화 개발 및 커뮤니케이션에 참여했으며 취약점에 대한 사전 알림을 받는 Kubernetes Distributors List의 구성원입니다. 또한 Google에서는 여러 가지 Kubernetes 취약점을 자체적으로 발견했습니다.
덜 심각한 취약점은 이러한 프로세스 외부에서 발견되고 패치되지만 중요한 보안 취약점 대부분은 앞서 나열된 채널 중 하나를 통해 비공개로 보고됩니다. 조기 보고를 통해 Google에서는 취약점이 공개되기 전에 GKE Enterprise에 미치는 영향을 조사하고 패치 또는 완화를 개발하며 고객을 위한 조언과 커뮤니케이션을 준비할 수 있습니다. 가능한 경우 취약점이 공개 출시되기 전에 모든 클러스터를 패치합니다.
취약점 분류 방법
GKE는 우수한 기본값, 보안 강화 구성, 관리형 구성요소를 설정하는 것 외에 OS, 컨테이너, Kubernetes, 네트워크 레이어를 포함한 전체 스택을 강화하는 보안에 많은 투자를 합니다. 이러한 노력이 결합되어 취약점의 영향과 발생 가능성을 줄일 수 있습니다.
GKE Enterprise 보안팀은 Kubernetes 취약점 점수 산출 시스템에 따라 취약점을 분류합니다. 분류는 GKE 및 GKE Enterprise 구성과 보안 강화를 비롯한 여러 요소를 고려합니다. 이러한 요인과 GKE의 보안에 대한 투자 때문에 GKE 및 GKE Enterprise 취약점 분류는 다른 분류 소스와 다를 수 있습니다.
다음 표에서는 취약점의 심각도 카테고리를 설명합니다.
| 심각도 | 설명 |
|---|---|
| 심각 | 인증되지 않은 원격 공격자가 모든 클러스터에서 쉽게 악용될 수 있어 전체 시스템을 손상시킬 수 있는 취약점. |
| 높음 | 비밀유지, 무결성 또는 가용성의 손실로 이어질 수 있으며 여러 클러스터에서 쉽게 악용될 수 있는 취약점. |
| 보통 | 일반적인 구성, 자체 악용 어려움, 필요한 액세스 또는 사용자 상호작용에 의해 기밀성, 무결성 또는 가용성의 손실이 제한되는 일부 클러스터에서 악용될 수 있는 취약점. |
| 낮음 | 기타 모든 취약점. 악용이 많지 않으며 악용의 결과가 제한적. |
취약점 예시, 수정 및 완화, 평가는 보안 게시판을 참조하세요.
취약점 패치 방법
취약점을 패치하려면 새 GKE 또는 GKE Enterprise 버전 번호로 업그레이드해야 합니다. GKE 및 GKE Enterprise 버전에는 운영체제, Kubernetes 구성 요소, GKE Enterprise 플랫폼을 구성하는 기타 컨테이너의 버전이 지정된 구성 요소가 포함됩니다. 수정을 위해 Google에 의해 GKE에서 자동으로 수행되는 제어 영역 업그레이드만 필요한 취약점이 있는가 하면 제어 영역과 노드 업그레이드가 모두 필요한 취약점도 있습니다.
모든 심각도의 취약점에 대해 클러스터 패치 및 강화를 유지하려면 GKE에서 노드 자동 업그레이드를 사용하는 것이 좋습니다(기본적으로 설정). 출시 채널에 등록된 클러스터의 경우 각 채널의 자격 요구사항을 충족하는 패치 출시 버전이 승격됩니다. 클러스터 채널에 도달하기 전에 GKE 패치 출시 버전이 필요한 경우 패치 출시 버전이 클러스터 출시 채널에서 제공하는 부 버전과 동일하면 패치 버전으로 수동 업그레이드할 수 있습니다.
다른 GKE Enterprise 플랫폼에서는 GKE Enterprise 구성요소를 적어도 한 달에 한 번 업그레이드하는 것이 좋습니다.
일부 보안 스캐너 또는 수동 버전 검사에서 runc 또는 containerd 등의 구성요소에 특정 업스트림 보안 패치가 누락되었다고 잘못 가정할 수 있습니다. GKE는 구성요소를 정기적으로 패치하고 필요할 때만 패키지 버전을 업그레이드하므로, GKE 구성요소의 버전 번호가 업스트림 버전 번호와 일치하지 않더라도 GKE 구성요소는 업스트림의 해당 구성요소와 기능적으로 유사합니다. 특정 CVE에 대한 자세한 내용은 GKE 보안 게시판을 참조하세요.
패치 적용 타임라인
Google의 목표는 감지된 취약점을 나타내는 위험에 적합한 기간 내에 완화하는 것입니다. GKE는 FedRAMP 지속적 모니터링 전략 가이드의 '지속적 모니터링 활동 및 결과물 요약' 표에 있는 제어 RA-5(d)에 지정된 심각도 수준에 따라 알려진 취약점을 특정 기간 내에 수정해야 하는 Google Cloud의 FedRAMP 임시 ATO에 포함되어 있습니다. Google Cloud의 FedRAMP 임시 ATO에 Google Distributed Cloud 및 AWS용 GKE는 포함되지 않지만 해당 제품에 대해서도 동일한 수정 기간을 목표로 합니다.
취약점 및 패치 커뮤니케이션 방법
취약점과 보안 패치에 대한 최신 정보를 얻을 수 있는 가장 좋은 소스는 다음 제품에 대한 보안 게시판 피드에 있습니다.
- GKE
- Google Distributed Cloud
- GKE on AWS
- Azure용 GKE
- Google Distributed Cloud
이러한 게시판은 일반적인 Google Cloud 취약점 번호 지정 체계를 따르며 기본 Google Cloud 게시판 페이지 및 GKE 출시 노트에서 연결될 수 있습니다. 각 보안 게시판 페이지에는 사용자가 업데이트를 구독할 수 있는 RSS 피드가 있습니다.
취약점은 한시적으로 엠바고 하에 비공개로 유지될 때가 있습니다. 엠바고는 취약점을 해결을 위한 조치를 취하기 전 광범위한 악용 시도로 이어질 수 있는 취약점의 조기 공개를 방지하는 데 도움이 됩니다. 엠바고 상황에서 출시 노트는 엠바고가 해제될 때까지 '보안 업데이트'를 참조합니다. 엠바고가 해제된 후 Google에서는 특정 취약점을 포함하도록 출시 노트를 업데이트합니다.
GKE Enterprise 보안팀은 심각도가 높음 및 중요인 취약점에 대해 보안 게시판을 게시합니다. 심각도가 '높음' 및 '중요'인 취약점을 해결하기 위해 고객의 조치가 필요한 경우 Google에서는 이메일로 고객에게 연락합니다. 또한 지원 채널의 지원 계약을 통해 고객에게 연락할 수도 있습니다.