Estás consultando la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de
Apigee Edge.
En este documento se describe cómo gestiona Google las vulnerabilidades de seguridad y los parches de Apigee hybrid. Salvo que se indique lo contrario, Apigee incluye tanto el plano de gestión como el plano de datos.
Responsabilidad compartida de aplicar parches
La aplicación de parches es una responsabilidad compartida entre Google y el cliente. Apigee X y Apigee Hybrid tienen responsabilidades compartidas diferentes, ya que el plano de datos de Apigee Hybrid lo gestiona por completo el cliente. Para obtener información sobre las responsabilidades compartidas de Apigee Hybrid, consulta el modelo de responsabilidad compartida de Apigee Hybrid.
Cómo se descubren las vulnerabilidades
Google adopta un enfoque proactivo en la seguridad de los sistemas de software, utilizando principios de diseño de seguridad predeterminada e implementando varias prácticas de refuerzo de la seguridad.
Por ejemplo, las aplicaciones contenerizadas impulsan las distintas funciones de la plataforma de gestión de APIs de Apigee. Las aplicaciones en contenedores se despliegan en Kubernetes. Las imágenes de contenedor se crean a partir de imágenes base mínimas (por ejemplo, imágenes base sin distribución) para maximizar la seguridad y mejorar el rendimiento.
Sin embargo, incluso los sistemas de software mejor diseñados pueden tener vulnerabilidades. Para detectar esas vulnerabilidades y corregirlas antes de que se puedan aprovechar, Google ha hecho inversiones significativas en varios frentes.
Analizadores de seguridad
Google identifica y corrige de forma proactiva las vulnerabilidades de diferentes tipos de imágenes de contenedor:
- Contenedores propios: imágenes de contenedor creadas y distribuidas por Google como parte de la plataforma Apigee. Se trata de aplicaciones propiedad de Google que impulsan la plataforma de gestión de APIs Apigee, incluidas las funciones principales, como el enrutamiento del tráfico, la gestión de cuotas y la gestión de claves.
- Contenedores de terceros: imágenes de contenedor creadas por la comunidad de código abierto, pero distribuidas por Google como parte de la plataforma Apigee. Se trata principalmente de componentes de código abierto que la plataforma utiliza para tareas operativas comunes, como el registro, la monitorización y la gestión de certificados.
Google analiza los contenedores con Container Analysis de Container Registry para detectar vulnerabilidades y parches que faltan en contenedores propios y de terceros. Si hay correcciones disponibles, Google inicia el proceso de aplicación de parches y lanzamiento. Estos análisis se ejecutan de forma periódica (cuando se publican imágenes nuevas) y bajo demanda (antes de un lanzamiento) para maximizar las probabilidades de detectar nuevas vulnerabilidades y planificar la corrección o mitigación tempranas.
Investigación de seguridad
Además del análisis automatizado, Google descubre y corrige vulnerabilidades desconocidas para los analizadores de las siguientes formas:
- Google realiza sus propias auditorías de seguridad y cumplimiento, pruebas de penetración de aplicaciones y redes, pruebas de segmentación y detección de vulnerabilidades de seguridad en todos los componentes de Apigee.
Equipos especializados de Google y proveedores de seguridad externos de confianza llevan a cabo sus propias investigaciones sobre ataques. - Google colabora con otros partners del sector y de software de código abierto que comparten vulnerabilidades, investigaciones de seguridad y parches antes de que se publiquen las vulnerabilidades.
El objetivo de esta colaboración es parchear grandes partes de la infraestructura de Internet antes de que se anuncie públicamente la vulnerabilidad. En algunos casos, Google contribuye a esta comunidad con las vulnerabilidades que encuentra. 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 periódicamente vulnerabilidades en la máquina virtual basada en kernel (KVM).
Programas de recompensas por vulnerabilidades
Google colabora activamente con la comunidad de investigación en temas de seguridad a través de varios programas de recompensas por vulnerabilidades. Un programa de recompensas por vulnerabilidades de Google Cloud específico ofrece recompensas importantes, incluidos 133.337 USD por la mejor vulnerabilidad en la nube que se encuentre cada año. El programa cubre todas las dependencias de software de Apigee.
OSS
La colaboración de Google en materia de seguridad se produce en muchos niveles. A veces, se produce de forma oficial a través de programas en los que las organizaciones se registran para recibir notificaciones previas al lanzamiento sobre vulnerabilidades de software de productos como Kubernetes y Envoy. La colaboración también se produce de forma informal debido a nuestra participación en muchos proyectos de código abierto, como el kernel de Linux, los tiempos de ejecución de contenedores, la tecnología de virtualización y otros.
Aunque se descubren y se corrigen vulnerabilidades menos graves fuera de estos procesos, la mayoría de las vulnerabilidades de seguridad críticas se comunican de forma privada a través de uno de los canales indicados anteriormente. Si nos avisas con antelación, Google tendrá tiempo antes de que la vulnerabilidad se haga pública para investigar cómo afecta a Apigee, desarrollar parches o medidas de mitigación y preparar consejos y comunicaciones para los clientes. Cuando es posible, Google parchea todos los clústeres (en Apigee X) antes de que se publique la vulnerabilidad. En Apigee hybrid, las versiones de parches se publican periódicamente para abordar las vulnerabilidades de seguridad de las imágenes de contenedor. Recomendamos a los clientes que mantengan actualizadas las versiones de parches.
Cómo se clasifican las vulnerabilidades
Apigee invierte mucho en reforzar la seguridad de toda la pila, incluida la imagen base, las bibliotecas de terceros y el software de aplicaciones propio, además de establecer valores predeterminados adecuados, configuraciones reforzadas y componentes gestionados. En conjunto, estas medidas ayudan a reducir el impacto y la probabilidad de que se produzcan vulnerabilidades.
El equipo de seguridad de Apigee clasifica las vulnerabilidades según el sistema común de puntuación de vulnerabilidades (CVSS).
En la siguiente tabla se describen las categorías de gravedad de las vulnerabilidades:
| Gravedad | Descripción |
| Crítica | Una vulnerabilidad que puede explotar fácilmente en todos los clústeres un atacante remoto no autenticado, lo que provoca que el sistema se vea comprometido por completo. |
| Alta | Una vulnerabilidad que se puede aprovechar fácilmente en muchos clústeres y que provoca la pérdida de confidencialidad, integridad o disponibilidad. |
| Medio | Una vulnerabilidad que se puede aprovechar en algunos clústeres en los que la pérdida de confidencialidad, integridad o disponibilidad está limitada por configuraciones comunes, la dificultad de la vulnerabilidad en sí, el acceso necesario o la interacción del usuario. |
| Bajo | Todas las demás vulnerabilidades. Es poco probable que se produzca una explotación 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 en un periodo de tiempo adecuado a los riesgos que representan. Apigee está incluido en la autorización provisional de funcionamiento de FedRAMP de Google Cloud, que requiere que las vulnerabilidades conocidas se corrijan en plazos específicos según su nivel de gravedad, tal como se especifica en FedRAMP RA-5d. La autorización provisional de funcionamiento (ATO) de FedRAMP de Google Cloud no incluye los componentes del plano de datos híbrido de Apigee (gestionados por el cliente), pero nuestro objetivo es que esos productos tengan los mismos plazos de corrección.
Vulnerabilidades detectadas mediante análisis proactivos
Google detecta vulnerabilidades de seguridad mediante el análisis proactivo de los archivos binarios y la infraestructura subyacente que aloja la plataforma Apigee. Apigee lanza actualizaciones de parches periódicas para abordar estas vulnerabilidades de forma oportuna en función de la gravedad de los CVE subyacentes. Para aplicar un parche a una vulnerabilidad, debes actualizar a una nueva versión de Apigee hybrid, ya sea una versión secundaria o una versión del parche, en función de la naturaleza de la vulnerabilidad. Estas vulnerabilidades se suelen abordar en las versiones de parches mensuales de Apigee hybrid y se incluyen en las actualizaciones de software periódicas de nuestra flota gestionada en el caso de Apigee X. Los parches de seguridad se comunican a través de las notas de las versiones de Apigee X y Apigee Hybrid.
Para corregir algunas vulnerabilidades, solo es necesario actualizar el plano de control, lo que Google hace automáticamente en Apigee, mientras que para otras es necesario implementar nuevos archivos binarios en el plano de datos. En el caso de Apigee X, Google se encarga de implementar los nuevos archivos binarios en toda la flota. Los clientes que ejecuten Apigee Hybrid deben aplicar la versión del parche a sus clústeres de Apigee Hybrid para implementar los archivos binarios actualizados.
Para que los clústeres estén parcheados y protegidos frente a vulnerabilidades de cualquier gravedad, te recomendamos que apliques la versión de parche más reciente de cualquier versión secundaria de Apigee hybrid. Si utilizas Apigee Hybrid en Anthos, Google te recomienda que actualices tus componentes de Anthos al menos una vez al mes.
Vulnerabilidades comunicadas por los clientes
Con Apigee Hybrid, los clientes reciben archivos binarios de Apigee para ejecutarlos en sus centros de datos o en las plataformas en la nube que prefieran. Como parte de los estándares de seguridad de un cliente para lanzar software en producción en sus propios centros de datos, puede realizar 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 de posibles vulnerabilidades en el software de Apigee. Antes de habilitar estos paquetes en sus centros de datos, los clientes deben determinar si los elementos notificados se pueden aprovechar y, por lo tanto, suponen un riesgo para la seguridad.
Vulnerabilidad con una prueba de concepto de exploit
Si el cliente identifica una vulnerabilidad explotable y tiene una prueba de concepto (POC) sobre cómo explotarla, debe informar de este problema a través del programa de recompensas por vulnerabilidades de Google, que se encuentra en goo.gle/vulnz. De esta forma, se informa del problema al equipo de seguridad de Google, que validará la prueba de concepto y determinará su gravedad y su posible impacto. El problema se derivará a Apigee. El cliente puede cumplir los requisitos para recibir una recompensa a través del programa de vulnerabilidades.
Vulnerabilidad identificada por una herramienta automatizada
Si el cliente ha generado un informe de posibles vulnerabilidades en el producto Apigee basado en un análisis estático u otra herramienta o técnica, pero no tiene ninguna prueba de concepto sobre cómo aprovechar las vulnerabilidades, puede informar de estos elementos al equipo de Asistencia a través del portal de Asistencia de Google Cloud. Al informar del problema al equipo de Asistencia, el cliente recibe un número de incidencia para hacer un seguimiento y puede ver las actualizaciones y respuestas del informe. El equipo de Asistencia derivará internamente los problemas denunciados según corresponda.
Identificadores de CVE
Los clientes deben incluir toda la información posible sobre la vulnerabilidad y, en concreto, el identificador CVE, el nombre de la biblioteca o del paquete, el nombre de la imagen del contenedor, etc., de cada elemento. Los CVEs nos permiten saber que estamos analizando la misma vulnerabilidad. Si solo se proporciona una descripción del problema u otro número de seguimiento propietario, no se podrá correlacionar el problema en las herramientas de detección ni en los procesos de creación de informes. Si no se indica un CVE, es posible que Google no pueda responder al elemento específico.
Respuesta
En el caso de los elementos comunicados al equipo de Asistencia que tengan una puntuación de gravedad crítica o alta, los clientes pueden esperar una respuesta a través del sistema de asistencia. Para obtener información sobre los elementos denunciados al VRP, consulta las reglas y la documentación proporcionadas por el programa.