Apigee 및 Apigee Hybrid 문서입니다.
Apigee Edge 문서 보기
이 문서에서는 Google에서 Apigee Hybrid의 보안 취약점과 패치를 관리하는 방법을 설명합니다. 별도로 명시된 경우를 제외하고 Apigee에는 관리 영역과 데이터 영역이 모두 포함됩니다.
공유 패치 책임
패치는 Google과 고객이 공유하는 책임입니다. Apigee X 및 Apigee Hybrid는 Apigee Hybrid의 데이터 영역을 고객이 전적으로 관리하는 경우 서로 다른 공유 책임을 갖습니다. Apigee Hybrid 공유 책임에 대한 자세한 내용은 Apigee Hybrid 공유 책임 모델을 참조하세요.
취약점 발견 방법
Google은 보안은 기본 설계 원칙을 사용하고 다양한 보안 강화 권장사항을 구현하여 소프트웨어 시스템 보안에 사전 대응 방식을 취합니다.
예를 들어 컨테이너화된 애플리케이션은 다양한 Apigee API 관리 플랫폼 기능을 지원합니다. 컨테이너화된 애플리케이션은 Kubernetes에 배포됩니다. 컨테이너 이미지는 보안과 성능 향상 극대화를 위해 최소 기본 이미지(예: distroless 기본 이미지)를 기반으로 빌드됩니다.
그러나 최적으로 설계된 소프트웨어 시스템에도 취약점이 있을 수 있습니다. 이러한 취약점을 발견하고 악용되기 전에 패치하기 위해 Google에서는 여러 측면에 상당한 투자를 했습니다.
보안 스캐너
Google에서는 다양한 유형의 컨테이너 이미지에서 취약점을 사전에 식별하고 수정합니다.
- 퍼스트 파티 컨테이너: Google에서 Apigee 플랫폼의 일부로 빌드하고 배포하는 컨테이너 이미지입니다. 트래픽 라우팅, 할당량 관리, 키 관리와 같은 핵심 기능을 포함하여 Apigee API 관리 플랫폼을 지원하는 Google 독점 애플리케이션입니다.
- 타사 컨테이너: 오픈소스 커뮤니티에서 빌드했지만 Apigee 플랫폼의 일부로 Google에서 배포한 컨테이너 이미지입니다. 플랫폼에서 로깅, 모니터링, 인증서 관리와 같은 일반적인 운영 작업에 사용하는 오픈소스 구성요소가 대부분입니다.
Google에서는 Container Registry 컨테이너 분석을 통해 컨테이너를 스캔하여 퍼스트 파티 및 서드 파티 컨테이너에서 취약점과 누락된 패치를 찾습니다. 수정 사항이 있는 경우 Google에서 패치 및 출시 프로세스를 시작합니다. 이러한 스캔은 새로운 취약점 감지 및 조기 해결 또는 완화 계획의 가능성을 극대화하기 위해 정기적으로(새 이미지가 게시될 때) 또는 주문형으로(출시 전) 실행됩니다.
보안 연구
Google에서는 자동화된 스캔 외에도 다음과 같은 방법으로 스캐너가 감지하지 못하는 취약점을 발견하고 패치합니다.
- Google에서는 모든 Apigee 구성요소에서 자체 보안 및 규정 준수 감사, 애플리케이션 및 네트워크 침투 테스트, 세분화 테스트, 보안 취약점 감지를 수행합니다.
Google 내부의 숙련된 팀과 신뢰할 수 있는 제3자 보안 공급업체는 자체 공격 연구를 수행합니다. - Google에서는 취약점이 공개되기 전에 취약점, 보안 연구 및 패치를 공유하는 다른 업계 및 오픈소스 소프트웨어 파트너와 협력합니다.
이 공동작업의 목적은 취약점이 공개되기 전에 대규모 인터넷 인프라를 패치하는 것입니다. Google에서는 경우에 따라 발견된 취약점을 이 커뮤니티에 반영합니다. 예를 들어 Google의 Project Zero는 스펙터 및 멜트다운 취약점을 발견하고 공개했습니다. 또한 Google Cloud 보안팀은 정기적으로 커널 기반 가상 머신(KVM)의 취약점을 찾아 수정합니다.
취약점 포인트 제도
Google에서는 여러 가지 취약점 포인트 제도를 통해 보안 연구 커뮤니티와 적극적으로 소통합니다. Google Cloud의 취약점 포인트 제도는 매년 중대한 클라우드 취약점을 발견한 대가로 133,337달러를 제공하는 등 큰 혜택을 제공합니다. 이 제도는 모든 Apigee 소프트웨어 종속 항목에 적용됩니다.
OSS
Google의 보안 공동작업은 여러 수준에서 이루어집니다. 때로는 Kubernetes 및 Envoy와 같은 제품의 소프트웨어 취약점에 대한 출시 전 알림을 받기 위해 조직에서 등록한 프로그램을 통해 공식적으로 이루어집니다. 공동작업은 Linux 커널, 컨테이너 런타임, 가상화 기술 등과 같은 여러 오픈소스 프로젝트와의 참여로 인해 비공식적으로 발생하기도 합니다.
덜 심각한 취약점은 이러한 프로세스 외부에서 발견되고 패치되지만 중요한 보안 취약점 대부분은 앞서 나열된 채널 중 하나를 통해 비공개로 보고됩니다. 조기 보고를 통해 Google에서는 취약점이 공개되기 전에 Apigee에 미치는 영향을 조사하고 패치 또는 완화를 개발하며 고객을 위한 조언과 커뮤니케이션을 준비할 수 있습니다. 가능한 경우 취약점이 공개 출시되기 전에 모든 클러스터(Apigee X용)를 패치합니다. Apigee Hybrid의 경우 컨테이너 이미지의 보안 취약점을 해결하기 위해 패치 버전이 정기적으로 제공되며 고객은 최신 패치 버전을 사용하는 것이 좋습니다.
취약점 분류 방법
Apigee는 우수한 기본값, 보안 강화 구성, 관리형 구성요소를 설정하는 것 외에 기본 이미지, 서드 파티 라이브러리, 퍼스트 파티 애플리케이션 소프트웨어를 포함한 전체 스택의 보안 강화에 많은 투자를 합니다. 이러한 노력이 결합되어 취약점의 영향과 발생 가능성을 줄일 수 있습니다.
Apigee 보안팀은 공통 취약점 점수 산출 시스템(CVSS)에 따라 취약점을 분류합니다.
다음 표에서는 취약점의 심각도 카테고리를 설명합니다.
| 심각도 | 설명 |
| 심각 | 인증되지 않은 원격 공격자가 모든 클러스터에서 쉽게 악용될 수 있어 전체 시스템을 손상시킬 수 있는 취약점. |
| 높음 | 비밀유지, 무결성 또는 가용성의 손실로 이어질 수 있으며 여러 클러스터에서 쉽게 악용될 수 있는 취약점. |
| 중간 | 일반적인 구성, 자체 악용 어려움, 필요한 액세스 또는 사용자 상호작용에 의해 기밀성, 무결성 또는 가용성의 손실이 제한되는 일부 클러스터에서 악용될 수 있는 취약점. |
| 낮음 | 기타 모든 취약점. 악용이 많지 않으며 악용의 결과가 제한적. |
취약점 및 패치 커뮤니케이션 방법
Google의 목표는 감지된 취약점을 나타내는 위험에 적합한 기간 내에 완화하는 것입니다. Apigee는 FedRAMP RA-5d에 지정된 심각도 수준에 따라 알려진 취약점을 특정 기간 내에 수정해야 하는 Google Cloud의 FedRAMP 임시 ATO에 포함되어 있습니다. Google Cloud의 FedRAMP 임시 ATO에 Apigee Hybrid 데이터 영역 구성요소(고객 관리형)는 포함되지 않지만 해당 제품에 대해서도 동일한 해결 기간을 목표로 합니다.
사전 스캔에서 감지된 취약점
Google에서는 Apigee 플랫폼을 호스팅하는 기본 인프라 및 바이너리의 사전 스캔을 통해 보안 취약점을 감지합니다. Apigee는 기본 CVE의 심각도에 따라 이러한 취약점을 시기적절하게 해결하기 위해 정기적인 패치 업데이트를 출시합니다. 취약점을 패치하려면 취약점의 특성에 따라 새로운 Apigee Hybrid 버전으로 업그레이드해야 합니다(마이너 버전 업그레이드 또는 패치 버전 업그레이드). 이러한 취약점은 대부분 Apigee Hybrid의 월별 패치 출시의 일부로 해결되며 Apigee X의 경우 Google 관리형 기기에 대한 정기 소프트웨어 업데이트에 포함됩니다. 보안 패치는 Apigee X 및 Apigee Hybrid의 출시 노트를 통해 전달됩니다.
수정을 위해 Google에 의해 Apigee에서 자동으로 수행되는 제어 영역 업그레이드만 필요한 취약점이 있는가 하면 데이터 영역에 새 바이너리를 출시해야 하는 취약점도 있습니다. Apigee X의 경우 새 바이너리를 전체 기기에 출시하는 작업을 Google에서 대신 처리합니다. Apigee Hybrid를 실행하는 고객이 업데이트된 바이너리를 출시하려면 패치 출시 버전을 Apigee Hybrid 클러스터에 적용해야 합니다.
모든 심각도의 취약점에 대해 클러스터 패치 및 강화를 유지하려면 지정된 Apigee Hybrid 마이너 버전에 최신 패치 출시 버전을 적용하는 것이 좋습니다. Anthos에서 Apigee Hybrid를 실행하는 경우 Anthos 구성요소를 한 달에 한 번 이상 업그레이드하는 것이 좋습니다.
고객이 신고한 취약점
Apigee Hybrid를 사용하는 고객에게는 데이터 센터나 선호하는 클라우드 플랫폼에서 실행할 수 있는 Apigee 바이너리가 제공됩니다. 자체 데이터 센터에서 소프트웨어를 프로덕션으로 출시하기 위한 고객의 보안 표준에 따라 일련의 보안 테스트를 실행할 수 있습니다. 이러한 테스트에는 침투 테스트, 컨테이너 스캔, 정적 코드 스캔 등이 포함될 수 있습니다. 이 테스트는 Apigee 소프트웨어의 잠재적인 취약점을 보고할 수 있습니다. 고객은 데이터 센터에서 이러한 패키지를 사용 설정하기 전에 보고된 항목이 악용될 수 있는지 여부와 그에 따른 보안 위험을 고려해야 합니다.
악용 개념 증명을 통한 취약점
고객이 악용 가능한 취약점을 발견하고 취약점을 악용하는 방법에 대한 개념 증명(POC)을 수행한 경우 Google 취약점 포인트 제도(goo.gle/vulnz)를 통해 이 문제를 보고해야 합니다. 그러면 Google 보안팀에 문제가 보고되고, 이 팀이 개념 증명을 검증하고 심각도와 잠재적인 영향을 확인합니다. 그런 다음 Apigee로 문제가 에스컬레이션됩니다. 고객은 VRP 프로그램을 통해 리워드를 받을 수 있습니다.
자동화된 도구로 식별된 취약점
고객이 정적 스캔이나 다른 도구나 기법을 기반으로 Apigee 제품의 가능한 취약점 보고서를 생성했지만 문제를 악용하는 방법에 대한 개념 증명을 수행하지 않은 경우 Google Cloud 지원 포털을 통해 이러한 항목을 지원팀에 보고할 수 있습니다. 지원팀에 문제를 신고하면 고객은 추적용 티켓 번호를 갖게 되며 보고서에 대한 업데이트와 응답을 확인할 수 있습니다. 그런 다음 지원팀이 보고된 문제를 내부에서 적절하게 에스컬레이션합니다.
CVE 식별자
고객은 취약점에 대한 정보를 최대한 많이 포함해야 하며, 특히 각 항목의 CVE 식별자, 라이브러리/패키지 이름, 컨테이너 이미지 이름 등을 포함해야 합니다. CVE를 통해 Google은 동일한 취약점을 보고 있다는 것을 알 수 있습니다. 문제에 대한 설명 또는 기타 고유 추적 번호만 제공하면 감지 도구 또는 보고 프로세스 간에 문제를 연관시킬 수 없습니다. CVE가 없으면 Google에서 특정 항목에 대응하지 못할 수 있습니다.
응답
심각도 점수가 심각 또는 높음으로 지원팀에 보고된 항목의 경우 고객이 지원 티켓팅 시스템을 통해 응답을 받을 수 있습니다. VRP에 보고된 항목의 경우 이 프로그램에서 제공하는 규칙 및 문서를 참조하세요.