Estás viendo la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.
En este documento, se describe cómo Google administra las vulnerabilidades y los parches de seguridad de Apigee hybrid. Excepto cuando se indique lo contrario, Apigee incluye el plano de administración y el plano de datos.
Responsabilidad de los parches compartidos
La aplicación de parches es una responsabilidad compartida entre Google y el cliente. Apigee X y Apigee hybrid tienen diferentes responsabilidades compartidas, ya que el plano de datos de Apigee hybrid es completamente administrado por el cliente. Para obtener información sobre las responsabilidades compartidas de Apigee hybrid, consulta Modelo de responsabilidad compartida de Apigee hybrid.
Cómo se descubren las vulnerabilidades
Google adopta un enfoque proactivo para la seguridad de los sistemas de software mediante el uso de los principios de diseño Seguro de forma predeterminada y la implementación de varias prácticas de endurecimiento de seguridad.
Por ejemplo, las aplicaciones alojadas en contenedores impulsan las diversas funciones de la plataforma de administración de APIs de Apigee. Las aplicaciones alojadas en contenedores se implementan en Kubernetes. Las imágenes del contenedor se compilan sobre las imágenes base mínimas (por ejemplo, imágenes base distroless) para maximizar la seguridad y mejorar el rendimiento.
Sin embargo, incluso los sistemas de software de mejor diseño pueden tener vulnerabilidades. Para encontrar esas vulnerabilidades y aplicar parches antes de que puedan ser aprovechadas, Google hizo inversiones significativas en varios frentes.
Escáneres de seguridad
Google identifica y corrige de forma proactiva las vulnerabilidades en diferentes tipos de imágenes de contenedor:
- Contenedores de origen: Imágenes de contenedor compiladas y distribuidas por Google como parte de la plataforma de Apigee. Estas son aplicaciones propiedad de Google que potencian la plataforma de administración de APIs de Apigee, incluidas las funciones principales, como el enrutamiento de tráfico, la administración de cuotas y la administración de claves.
- Contenedores de terceros: imágenes de contenedor compiladas por la comunidad de código abierto, pero distribuidas por Google como parte de la plataforma de Apigee. Estos son principalmente componentes de código abierto que usa la plataforma para tareas operativas comunes, como el registro, la supervisión y la administración de certificados.
Google analiza los contenedores mediante Container Registry Container Analysis a fin de descubrir vulnerabilidades y parches faltantes en contenedores propios y de terceros. Si hay correcciones disponibles, Google inicia el proceso de aplicación de parches y actualizaciones. Estos análisis se ejecutan con regularidad (cuando se publican imágenes nuevas) y a pedido (antes del lanzamiento) para maximizar las posibilidades de detectar vulnerabilidades nuevas y planificar la solución o mitigación de manera temprana.
Investigación de seguridad
Además del análisis automatizado, Google descubre vulnerabilidades desconocidas para los escáneres y aplica parches de las siguientes maneras:
- Google realiza sus propias auditorías de seguridad y cumplimiento, pruebas de penetración de aplicaciones y redes, pruebas de segmentación y descubrimiento de vulnerabilidades de seguridad en todos los componentes de Apigee.
Los equipos especializados dentro de Google y proveedores de seguridad externos de confianza realizan su propia investigación sobre ataques. - Google colabora con otros socios de software de industria y código abierto que comparten vulnerabilidades, investigaciones de seguridad y parches antes del lanzamiento público de la vulnerabilidad.
El objetivo de esta colaboración es aplicar un parche a grandes partes de la infraestructura de Internet antes de que se anuncie al público la vulnerabilidad. En algunos casos, Google contribuye con vulnerabilidades que se encuentran en esta comunidad. Por ejemplo, Project Zero de Google descubrió y publicó las vulnerabilidades Spectre y Meltdown. El equipo de seguridad de Google Cloud también encuentra y corrige vulnerabilidades en la máquina virtual basada en kernel (KVM) con regularidad.
Programas de recompensas por detección de vulnerabilidades
Google participa de forma activa con la comunidad de investigación de seguridad mediante varios programas de recompensas por detección de vulnerabilidades. Un programa dedicado de recompensas por detección de vulnerabilidades de Google Cloud proporciona recompensas significativas, que incluyen USD 133,337 para la mejor vulnerabilidad de la nube descubierta cada año. El programa abarca todas las dependencias de software de Apigee.
OSS
La colaboración en seguridad de Google ocurre en muchos niveles. En ocasiones, se produce formalmente a través de programas en los que las organizaciones se registran a fin de recibir notificaciones previas al lanzamiento sobre vulnerabilidades de software para productos como Kubernetes y Envoy La colaboración también se realiza de manera informal debido a nuestra participación en muchos proyectos de código abierto, como el kernel de Linux, los entornos de ejecución de contenedores, la tecnología de virtualización y otros.
Si bien se detectan vulnerabilidades menos graves y se aplican parches fuera de estos procesos, las vulnerabilidades de seguridad más importantes se informan de forma privada a través de uno de los canales enumerados antes. Los informes anticipados le brindan a Google tiempo antes de que la vulnerabilidad se haga pública para investigar cómo afecta a Apigee, desarrollar parches o mitigaciones, y preparar consejos y comunicaciones para los clientes. Cuando sea posible, Google aplica parches a todos los clústeres (para Apigee X) antes del lanzamiento público de la vulnerabilidad. En el caso de Apigee hybrid, las actualizaciones de parches están disponibles con regularidad para abordar las vulnerabilidades de seguridad en las imágenes de contenedor y se recomienda a los clientes que se mantengan al día con las últimas versiones de parches.
Cómo se clasifican las vulnerabilidades
Apigee realiza grandes inversiones en el endurecimiento de la seguridad en toda la pila, incluida la imagen base, las bibliotecas de terceros y el software de aplicación de origen, además de establecer valores predeterminados adecuados, parámetros de configuración con seguridad endurecida y componentes administrados. Juntos, estos esfuerzos ayudan a reducir el impacto y la probabilidad de vulnerabilidades.
El equipo de seguridad de Apigee clasifica las vulnerabilidades según el Sistema de puntuación de vulnerabilidades común (CVSS).
En la siguiente tabla, se describen las categorías de gravedad de las vulnerabilidades:
| Gravedad | Descripción |
| Críticas | Una vulnerabilidad fácilmente capaz de afectar todos los clústeres mediante un atacante remoto no autenticado que representa un peligro para todo el sistema. |
| Alta | Una vulnerabilidad que se puede aprovechar fácilmente para muchos clústeres que hace que se pierdan la confidencialidad, la integridad o la disponibilidad. |
| Medio | Una vulnerabilidad que afecta a algunos clústeres en los que la pérdida de confidencialidad, integridad o disponibilidad está limitada por configuraciones comunes, dificultad de la explotación en sí, acceso obligatorio o interacción del usuario. |
| Bajo | El resto de las vulnerabilidades. El riesgo de explotación es poco probable o las consecuencias de la explotación son limitadas. |
Cómo se comunican las vulnerabilidades y los parches
El objetivo de Google es mitigar las vulnerabilidades detectadas dentro de un período adecuado para los riesgos que representan. Apigee se incluye en el ATO provisional de FedRAMP de Google Cloud, que requiere que las vulnerabilidades conocidas se solucionen en períodos específicos según su nivel de gravedad, como se especifica en FedRAMP RA-5d. El ATO provisional de FedRAMP de Google Cloud no incluye componentes del plano de datos de Apigee hybrid (administrados por el cliente), pero tenemos como objetivo los mismos períodos de solución en esos productos.
Vulnerabilidades detectadas por el análisis proactivo
Google detecta vulnerabilidades de seguridad mediante el análisis proactivo de los objetos binarios y la infraestructura subyacente que aloja la plataforma de Apigee. Apigee lanza actualizaciones de parche regulares para abordar estas vulnerabilidades de forma oportuna según la gravedad de las CVE subyacentes. El parche de una vulnerabilidad implica actualizar a una versión nueva de Apigee hybrid y una actualización de la versión secundaria o de parche, según la naturaleza de la vulnerabilidad. Estas vulnerabilidades se abordan, como parte de las actualizaciones de parche mensuales para Apigee hybrid y se incluyen en las actualizaciones regulares de software de nuestra flota administrada en el caso de Apigee X. Los parches de seguridad se comunican a través de las notas de la versión de Apigee X y Apigee hybrid.
Para corregir algunas vulnerabilidades, solo se requiere una actualización del plano de control que Google realiza de manera automática en Apigee, mientras que otras requieren que se implementen objetos binarios nuevos en el plano de datos. En el caso de Apigee X, Google se encarga de implementar los objetos binarios nuevos en toda la flota. Los clientes que ejecutan Apigee hybrid deben aplicar la versión de parche a sus clústeres de Apigee hybrid para lanzar los objetos binarios actualizados.
A fin de mantener los clústeres con parches y endurecidos contra las vulnerabilidades de todos los niveles de gravedad, recomendamos aplicar la última versión del parche para cualquier versión secundaria de Apigee hybrid. Para quienes ejecutan Apigee hybrid en Anthos, Google recomienda actualizar los componentes de Anthos al menos una vez al mes.
Vulnerabilidades informadas por el cliente
Con Apigee hybrid, los clientes reciben objetos binarios de Apigee para ejecutarlos en sus centros de datos o sus plataformas de nube preferidas. Como parte de los estándares de seguridad de un cliente para lanzar software a producción en sus propios centros de datos, puede ejecutar una serie de pruebas de seguridad. Estas pruebas pueden incluir pruebas de penetración, análisis de contenedores, análisis de código estático, etc. Estas pruebas pueden informar posibles vulnerabilidades en el software de Apigee. Antes de habilitar estos paquetes en sus centros de datos, los clientes deben determinar si estos elementos informados se pueden explotar y, por lo tanto, son un riesgo para la seguridad.
Vulnerabilidad con una prueba de concepto de explotación
Si el cliente identifica una vulnerabilidad que se puede explotar y tiene una prueba de concepto (POC) para explotarla, deben informar este problema a través del Programa de recompensa de vulnerabilidades de Google que se encuentra en goo.gle/vulnz.. Esto informa el problema al equipo de seguridad de Google, que validará la prueba de concepto y determinará su gravedad y su posible impacto. El problema se escalará a Apigee. Es posible que el cliente sea apto para recibir una recompensa a través del programa de VRP.
Vulnerabilidad identificada mediante una herramienta automatizada
Si el cliente generó un informe de posibles vulnerabilidades en el producto de Apigee según el análisis estático u otra herramienta o técnica, pero no tiene ninguna prueba de concepto sobre cómo explotar los problemas, estos elementos se pueden informar al equipo de asistencia a través del portal de asistencia de Google Cloud. Si informas el problema al servicio de asistencia, el cliente tiene un número de ticket para realizar el seguimiento y puede ver las actualizaciones y respuestas del informe. El equipo de asistencia derivará los problemas informados de internamente, según corresponda.
Identificadores de CVE
Los clientes deben incluir la mayor cantidad de información posible sobre la vulnerabilidad y, en particular, incluir para cada elemento el identificador de CVE, el nombre de la biblioteca o el paquete, el nombre de la imagen del contenedor, etcétera. Las CVE nos permiten saber si estamos viendo la misma vulnerabilidad. Proporcionar solo una descripción del problema o algún otro número de seguimiento propio no permite correlacionar el problema entre las herramientas de detección o los procesos de informes. Sin una CVE, es posible que Google no pueda responder al elemento específico.
Respuesta
En el caso de los elementos informados al equipo de asistencia que tienen una puntuación de gravedad crítica o alta, los clientes pueden esperar una respuesta a través del sistema de tickets de asistencia. Para los elementos informados al VRP, consulta las reglas y la documentación que proporciona el programa.