Distribuir software de forma segura
Actualmente, las organizaciones se centran en la velocidad y el tiempo de lanzamiento de su software y aplicaciones. Sin embargo, las prácticas de seguridad actuales no pueden seguir el ritmo que hay, lo que provoca retrasos en el desarrollo, riesgos de riesgo y vulnerabilidades en las amenazas.
En este informe, aprenderás a solucionar el problema de la seguridad de la cadena de suministro de software haciendo lo siguiente:
- Adoptar estándares y frameworks del sector
- Implementar estos estándares con servicios gestionados que usan los principios de mínimos accesos en una arquitectura de confianza cero
Descubre cómo pasar rápidamente del código a la compilación, el empaquetado, el despliegue y la ejecución de software, todo ello desde una base segura.
Información sobre la cadena de suministro de software
Panorama de seguridad actual
La velocidad y el tiempo de lanzamiento son las principales prioridades de las organizaciones de todo el mundo que desarrollan software y aplicaciones para satisfacer las necesidades de sus clientes. Estos imperativos estratégicos han sido el motor de un enorme crecimiento de contenedores como plataforma de elección. Durante el último año, muchas de esas organizaciones han empezado a aprovechar las ventajas de los contenedores, entre los que se incluyen un tiempo de lanzamiento más reducido, una mayor disponibilidad, una seguridad mejorada, una mayor escalabilidad y una reducción de costes, muchas de estas organizaciones también han comenzado a pensar en el enfoque sin servidor.
Aunque las soluciones de software han reducido el tiempo necesario para lanzar una función nueva o incluso un producto nuevo, muchas de las prácticas de seguridad disponibles no pueden adaptarse al aumento de la velocidad, lo que lleva a uno de estos tres problemas:
- Los desarrolladores ralentizan los procesos, por lo que se producen retrasos
- Los equipos de seguridad y operaciones ponen en riesgo a la organización ante amenazas
- Los equipos de desarrollo trabajan en torno a los procesos de seguridad para cumplir las fechas límite, por lo que son vulnerables
En los últimos años, se han producido infracciones de seguridad clasificadas como ataques a la "cadena de suministro de software".
Log4Shell era una vulnerabilidad peligrosa del software Apache Log4j identificada en diciembre del 2021. Marcada con la puntuación máxima de CVSS de 10, esta vulnerabilidad ha sido especialmente devastadora debido a la popularidad de Log4j, un framework de registro basado en Java. Dos factores fueron los que contribuyeron a la gravedad: en primer lugar, fue muy fácil explotar y permitir la ejecución completa del código remoto; y, en segundo lugar, estaba a menudo en muchas capas en el árbol de dependencias y, por tanto, faltaban fácilmente.
Solarwinds, una empresa de software de gestión informática, fue atacada por agentes estatales de Estados Unidos que introdujeron código malicioso en compilaciones oficiales de software libre que usaba la empresa. Esta actualización maliciosa se implementó para 18.000 clientes, incluidos los departamentos del Tesoro y Comercio de Estados Unidos.
Kaseya, otra empresa de software de gestión informática, sufrió un ataque que la puso en riesgo mediante una vulnerabilidad de cero días que interceptó el servidor Kaseya VSA y envió una secuencia de comandos maliciosa para distribuir ransomware que encriptaba todos los archivos. en los sistemas afectados.
La necesidad urgente de responder a estos y otros incidentes similares llevaron a la Casa Blanca a publicar una orden ejecutiva en mayo del 2021, en la que se exigía a las organizaciones que trabajan con el Gobierno federal mantener determinados estándares de seguridad del software.
La cadena de suministro de software
En muchos sentidos, el término "cadena de suministro de software" es muy adecuado: los procesos para crear una cadena de suministro de software son muy similares a los que se usan para fabricar un coche.
El fabricante de un coche compra piezas de fábrica, fabrica sus propios componentes y los combina mediante un proceso muy automatizado. Los fabricantes se encargan de proteger sus operaciones y se aseguran de que todos los componentes de terceros procedan de fuentes de confianza. Los componentes propios se prueban exhaustivamente para verificar que no tienen problemas de seguridad. Por último, el montaje se lleva a cabo mediante un proceso fiable que genera coches acabados.
La cadena de suministro de software es similar en muchos aspectos. Los fabricantes de software obtienen componentes de terceros a menudo de código abierto que realizan funciones específicas y desarrollan su propio software, que es su propiedad intelectual principal. A continuación, el código se ejecuta mediante un proceso de compilación que combina estos componentes en artefactos desplegables, que se despliegan en producción.
El eslabón débil de la cadena
Solo se necesita un enlace no seguro para incumplir la cadena de suministro de software.
Igual que ocurre con los ataques destacados del año pasado, cada uno de los pasos del proceso puede dar lugar a la debilidad de un atacante.
Por ejemplo, el paquete medio de npm tiene 12 dependencias directas y unas 300 dependencias indirectas. Además, sabemos que casi el 40% de todos los paquetes de npm publicados dependen de código con vulnerabilidades conocidas.
Las vulnerabilidades podrían no hacer que el código sea seguro (por ejemplo, la vulnerabilidad podría pertenecer a una biblioteca que nunca se use). No obstante, se deben seguir comprobando esas vulnerabilidades.
La escala de este problema es monumental. Incluso si se tuviera una de estas vulnerabilidades, se podría dar la oportunidad de que algunos agentes perniciosos accedieran a tu cadena de suministro de software.
A continuación, se muestran algunos ejemplos de ataques que han aprovechado las vulnerabilidades de cada una de las fases que se muestran en el diagrama anterior.
| Amenaza | Ejemplo conocido | |
| A | Enviar código incorrecto al repositorio de origen | Compromisos hipócritos de Linux: el investigador intentó introducir intencionadamente vulnerabilidades en el kernel de Linux a través de parches en la lista de distribución. |
| B | Plataforma de control de fuentes vulnerada | PHP: el atacante ha vulnerado el servidor Git alojado en PHP y ha inyectado dos confirmaciones maliciosas. |
| C | Se ha creado con un proceso oficial, pero desde un código que no coincide con el control del código fuente | Webmin: Attacker ha modificado la infraestructura de compilación para usar archivos de origen que no coinciden con el control de origen. |
| D | Plataforma de compilación de compromiso | SolarWinds: Attacker ha vulnerado la plataforma de compilación y ha instalado un implante para inyectar comportamiento malicioso durante cada compilación. |
| E | Utiliza una dependencia negativa (por ejemplo, AH, de forma recurrente) | event-stream: el atacante ha añadido una dependencia inocua y, luego, ha actualizado la dependencia para añadir un comportamiento malicioso. La actualización no coincide con el código enviado a GitHub (es decir, el ataque F). |
| F | Sube un artefacto que no haya sido creado por el sistema CI/CD | Codecov: Attacker ha usado credenciales filtradas para subir un artefacto malicioso a un segmento de Google Cloud Storage del que los usuarios pueden descargar directamente. |
| G | Repositorio de paquetes de compromiso | Ataques a la replicación de paquetes: el investigador ha ejecutado espejos de varios repositorios populares de paquetes que se podrían haber utilizado para publicar paquetes maliciosos. |
| H | Engaña al consumidor para que utilice el paquete | Mensaje tipográfico con Browserify: el atacante ha subido un paquete malicioso con un nombre similar al original. |
Refuerza la cadena: el liderazgo de opinión de Google Cloud en código abierto
En Google, llevamos décadas desarrollando aplicaciones a escala mundial. Con el tiempo, hemos abierto muchos de nuestros proyectos internos para ayudar a aumentar la velocidad de desarrollo. Al mismo tiempo, hemos desarrollado varios procesos internos para ayudar a asegurar la experiencia de software.
Estas son algunas de las iniciativas que estamos realizando para que las cadenas de suministro de software sean más sólidas en todas partes.
- Aumento de la inversión: en agosto del 2020 anunciamos que íbamos a invertir 10.000 millones de dólares en los próximos cinco años para reforzar la ciberseguridad, lo que incluye desplegar programas de confianza cero, proteger la cadena de suministro de software, y mejorar la seguridad de software libre.
- Niveles de la cadena de suministro para artefactos de software (SLSA): el SLSA es un marco integral para la integridad de la cadena de suministro. Es un equivalente de código abierto de muchos de los procesos que hemos implementado internamente en Google. La herramienta SLSA proporciona pruebas comprobables de lo que se ha creado y cómo.
- DevOps Research and Assessment (DORA) el rendimiento organizativo.
- Foundation de seguridad de código abierto: cofundamos la fundación de seguridad de código abierto en el 2019, un foro multisector sobre la seguridad de la cadena de suministro.
- Allstar: Allstar es una aplicación de GitHub instalada en organizaciones o repositorios para establecer y aplicar políticas de seguridad. Como consecuencia, se aplican prácticas recomendadas de seguridad en los proyectos de GitHub de forma continua.
- Cuadros de resultados de código abierto: las tarjetas de resultados usan métricas de evaluación, como una política de seguridad bien definida, un proceso de revisión de código y una cobertura de pruebas continua con herramientas de fuzzing y análisis de código estático para proporcionar una puntuación de riesgo para proyectos de software libre.
Creemos que son dos cosas necesarias para superar el problema de la seguridad de la cadena de suministro de software:
- Estándares y frameworks del sector.
- Los servicios gestionados que implementan estos estándares mediante los principios de los mínimos accesos se conocen como arquitectura de confianza cero. Una arquitectura de confianza cero es aquella en la que ninguna persona, dispositivo o red disfruta de la confianza inherente. sino que debe obtenerse toda la confianza, que permite el acceso a la información.
A continuación, veremos uno por uno:
Marcos y estándares del sector
Para conocer los principios en los que se basa la seguridad de la cadena de suministro de software, vamos a empezar por SLSA.
Actualmente, la SLSA establece un conjunto de directrices de seguridad que se pueden adoptar de forma incremental y que está consensuada por el consenso del sector. En su forma final, SLSA difiere de una lista de prácticas recomendadas en cuanto a su aplicabilidad, ya que admitirá la creación automática de metadatos auditables que se podrán introducir en los motores de políticas para otorgar la certificación SLSA a un paquete o una plataforma de compilación específicos.
El SLSA está diseñado para ser incremental, práctico y ofrecer ventajas de seguridad en cada paso. Una vez que un artefacto cumple los requisitos de un nivel superior, los consumidores pueden confiar en que no se ha manipulado y, si es seguro, que se puede rastrear hasta su origen, algo que suele ser difícil, o imposible.
SLSA consta de cuatro niveles: SLSA 4 representa el estado final ideal. Los niveles inferiores representan hitos incrementales con sus correspondientes garantías de integridad incrementales. A continuación se indican los requisitos que deben cumplirse para conseguir estos objetivos.
El proceso SLSA 1 requiere que el proceso de compilación esté completamente guionizado o automatizado, y que genere procedencia. La procedencia es los metadatos sobre cómo se ha creado un artefacto, incluidos el proceso de compilación, la fuente de nivel superior y las dependencias. Esta información permite que los consumidores de software tomen decisiones de seguridad basadas en riesgos. Aunque la procedencia de las normas de SLSA 1 no ofrece protección frente a la manipulación, ofrece un nivel básico de identificación de las fuentes de código y puede ayudar a gestionar vulnerabilidades.
SLSA 2 requiere el control de versiones y un servicio de compilación alojado que genera procedencias autenticadas. De este modo, los consumidores pueden confiar más en el origen del software. A este nivel, la procedencia impide la manipulación si el servicio de compilación es de confianza. SLSA 2 también ofrece una ruta de actualización sencilla a SLSA 3.
Además, la SLSA 3 exige que las plataformas de origen y compilación cumplan unos estándares concretos para garantizar la fiabilidad de la fuente y la integridad de la procedencia, respectivamente. SLSA 3 ofrece protección mucho más segura contra manipulaciones que los niveles anteriores, ya que previene amenazas específicas, como la contaminación por compilación cruzada.
Actualmente, el nivel SLSA 4 es el más alto, ya que requiere que dos personas revisen todos los cambios y un proceso de compilación hermético y reproducible. La reseña de dos personas es una práctica recomendada del sector para detectar errores y disuadir a los usuarios de comportamientos inadecuados. Las versiones de Hermetic garantizan que la lista de dependencias de procedencia es completa. Las compilaciones reproducibles, aunque no estrictamente necesarias, ofrecen muchas ventajas de fiabilidad y auditoría. En general, SLSA 4 ofrece al consumidor una alta certeza de que no se ha manipulado el software. Puedes consultar más detalles de estos niveles propuestos en el repositorio de GitHub, incluidos los requisitos de origen y compilación o procedencia correspondientes.
La cadena de suministro de software se puede dividir en cinco fases distintas: código, compilación, paquete, despliegue y ejecución. Trataremos cada una de estas fases en relación con nuestra estrategia de seguridad.
Servicios gestionados para cada fase
En Google Cloud ofrecemos herramientas totalmente gestionadas (desde el código y la compilación hasta el despliegue y la ejecución) con los estándares y las prácticas recomendadas anteriores que se implementan de forma predeterminada.
Asegurar la cadena de suministro de software requiere determinar, verificar y mantener una cadena de confianza que determine el código y garantice que lo que ejecutas en producción es lo que quieres. Para ello, llevamos a cabo estas atestaciones, que se generan y comprueban durante todo el desarrollo de software y el proceso de despliegue, lo que permite ofrecer un nivel de seguridad ambiental mediante revisiones de código, procedencia del código verificado y medidas por incumplimiento de políticas. Juntos, estos procesos nos ayudan a minimizar los riesgos de la cadena de suministro de software y, a la vez, a mejorar la productividad de los desarrolladores.
Su base incluye servicios de infraestructura segura, como gestión de identidades y accesos, y registros de auditoría. A continuación, protegemos tu cadena de suministro de software con una forma de definir, comprobar e implementar atestaciones a lo largo de todo su ciclo de vida de software.
Veamos con más detalle cómo puedes conseguir la seguridad ambiental en tu proceso de desarrollo mediante políticas y procedencias de Google Cloud.
Fase 1: Código
La seguridad de tu cadena de suministro de software empieza cuando los desarrolladores empiezan a diseñar tu aplicación y a escribir el código. Eso incluye el software propio y los componentes de código abierto, cada uno de los cuales tiene sus propios retos.
Software libre y dependencias de código abierto
El software libre permite que los desarrolladores creen cosas más rápido para que las organizaciones puedan ser más ágiles y productivas. Sin embargo, el software libre no es perfecto ni mucho menos y, aunque nuestro sector depende de él, a menudo tenemos muy poca información sobre sus dependencias y los distintos niveles de riesgo que conlleva. Para la mayoría de las empresas, el riesgo se debe principalmente a vulnerabilidades o licencias.
La base de tu "cadena de confianza" es el software libre, los paquetes, las imágenes base y otros artefactos que necesitas.
Por ejemplo, piensa que tu organización está creando software "a". En este diagrama se muestra la cadena de confianza; es decir, el número de dependencias implícitas de tu proyecto. En el diagrama, las letras que pasan de "b" a "h" son dependencias directas, y de "i" a "m" son dependencias indirectas.
Ahora, ten en cuenta que hay una vulnerabilidad en el árbol de dependencias más profundo. El problema puede aparecer rápidamente en muchos componentes. Además, las dependencias cambian con bastante frecuencia: en un día medio, los paquetes de 40.000 npm observan un cambio en sus dependencias.
Datos de código abierto es una herramienta desarrollada por Google Cloud que proporciona un gráfico transitorio de dependencias para que puedas ver tus dependencias y sus dependencias, todo ello por el árbol de dependencias. Open Source Insights se actualiza continuamente con avisos de seguridad, información sobre licencias y otros datos de seguridad sobre varios idiomas en un mismo lugar. Cuando se utiliza junto con las tarjetas de resultados de código abierto, que ofrecen una puntuación de riesgo para los proyectos de software libre, esta herramienta ayuda a los desarrolladores a tomar mejores decisiones en los millones de paquetes de código abierto disponibles.
Para abordar esta preocupación, es fundamental centrarse en las dependencias como código. Como estas dependencias se acercan al final de la cadena de suministro, es más difícil inspeccionarlas. Para proteger tus dependencias, te recomendamos que empieces por el suministro:
- Usa herramientas como Open Source Insights y las tarjetas de resultados de software libre para comprender mejor tus dependencias.
- Escanea y verifica todo el código, los paquetes y las imágenes de base mediante un proceso automatizado, que es una parte clave de tu flujo de trabajo.
- Controla cómo acceden las personas a estas dependencias. Es fundamental controlar detenidamente los repositorios de código propio y de código abierto, con restricciones de revisión de código exhaustiva y requisitos de auditoría.
Veremos con más detalle los procesos de compilación y despliegue, pero también es importante verificar la procedencia de la compilación, aprovechar un entorno de compilación seguro y comprobar que las imágenes estén firmadas y posteriores. se valida en el momento del despliegue.
Los desarrolladores también pueden utilizar varias prácticas de programación segura:
- Automatizar prueba
- Usa lenguajes de software seguros para la memoria
- Revisiones del código de orden
- Asegura la autenticidad de las confirmaciones
- Identificar el código malicioso antes
- Evita exponerte a información sensible
- Requerir almacenamiento de registros y resultados de compilación
- Gestión de licencias
Fase 2: Creación
El siguiente paso para proteger tu cadena de suministro de software es establecer un entorno de compilación seguro a escala. En esencia, el proceso de compilación consiste en importar el código fuente en posiblemente uno de los muchos idiomas de un repositorio y ejecutar compilaciones para cumplir las especificaciones incluidas en los archivos de configuración.
Los proveedores de servicios en la nube, como Google, te permiten acceder a un entorno de compilación gestionado y actualizado que te permite crear imágenes a cualquier escala.
A lo largo del proceso de compilación, hay varias cuestiones que debes tener en cuenta:
- ¿Tus secretos están protegidos durante el proceso de compilación y después?
- ¿Quién tiene acceso a tus entornos de compilación?
- ¿Qué ocurre con los vectores de ataque o los riesgos de filtración externa relativamente nuevos?
Para desarrollar un entorno de compilación seguro, debes empezar por secretos. Son esenciales y relativamente fáciles de proteger. En primer lugar, asegúrate de que tus secretos nunca sean texto sin formato y, en la medida de lo posible, no formen parte de tu compilación. En lugar de eso, debes asegurarte de que están cifrados y de que tus compilaciones se han parametrizado para hacer referencia a secretos externos que pueden usarse según sea necesario. Esto también simplifica la rotación periódica de secretos y minimiza el impacto de las fugas.
El siguiente paso es configurar los permisos de la compilación. El proceso de compilación incluye diferentes cuentas de usuario y de servicio. Por ejemplo, puede que algunos usuarios tengan que gestionar secretos y otros tengan que añadir o modificar pasos para gestionar el proceso de compilación y que otros necesiten ver los registros.
Para ello, es importante seguir estas prácticas recomendadas:
- Lo más importante es el principio de mínimos accesos. Implementa permisos detallados para dar a los usuarios y a las cuentas de servicio los permisos precisos que necesitan para hacer sus tareas de forma eficaz.
- Debes saber cómo interactúan los usuarios y las cuentas de servicio, y debes conocer claramente la cadena de responsabilidad, desde la creación de una compilación hasta su ejecución con los efectos secundarios de la compilación.
Después, a medida que amplíes este proceso, establece límites en torno a tu compilación en la medida de lo posible y, a continuación, usa la automatización para escalarla a través de la configuración como código y parametrización. Esto te permite auditar los cambios que hagas en tu proceso de compilación de forma eficaz. Además, asegúrate de que cumples los requisitos de cumplimiento mediante pasarelas de aprobación para compilaciones y despliegues sensibles, solicitudes de extracción de cambios en la infraestructura y revisiones periódicas de los registros de auditoría humanas.
Por último, comprueba que la red se adapte a tus necesidades. En la mayoría de los casos, es mejor alojar tu propio código fuente en redes privadas protegidas por cortafuegos. Google Cloud te da acceso a funciones como los grupos privados de Cloud Build, a un entorno de compilación sin servidor bloqueado dentro de tu propio perímetro de red privada y a funciones como los Controles de Servicio de VPC para evitar la filtración externa de tu propiedad intelectual.
Autorización binaria
Aunque IAM es un elemento imprescindible y un punto de partida lógico, no es infalible. Las credenciales filtradas representan un riesgo de seguridad grave. Por ello, para reducir la dependencia de IAM, puedes cambiar a un sistema basado en atestaciones, menos propenso a errores. Google utiliza un sistema llamado "autorización binaria", que solo permite desplegar cargas de trabajo de confianza.
El servicio de autorización binaria establece, verifica y mantiene una cadena de confianza mediante atestaciones y comprobaciones de las políticas durante todo el proceso. Esencialmente, la autorización binaria genera firmas criptográficas (atestaciones) a medida que el código y otros artefactos avanzan a la fase de producción y, antes de desplegarse, se comprueban estas atestaciones según las políticas.
Cuando se usa Google Cloud Build, se registra un conjunto de atestaciones y se añade a tu cadena general de confianza. Por ejemplo, se generan atestaciones de qué tareas se han ejecutado, qué herramientas de creación y procesos se han utilizado, etc. En concreto, Cloud Build te ayuda a conseguir el nivel de SLSA nivel 1, ya que captura la fuente de la configuración de la compilación, que se puede usar para validar que la compilación se ha programado. Las compilaciones con secuencias de comandos son más seguras que las compilaciones manuales y son necesarias para el nivel 1 de SLSA. Además, puedes consultar la procedencia y las atestaciones de tu compilación con el resumen de la imagen del contenedor, que crea una firma única para cualquier imagen y también es obligatorio para el nivel 1 de SLSA.
Fase 3: Paquete
Una vez que se haya completado la compilación, dispones de una imagen de contenedor que está casi lista para producción. Es importante que tengas un lugar seguro donde almacenar tus imágenes para evitar que se manipulen imágenes que ya tengas y que se suban imágenes no autorizadas. Es probable que tu gestor de paquetes necesite tener imágenes tanto de compilaciones propias como de código abierto, así como de paquetes de lenguajes que usen tus aplicaciones.
Artifact Registry de Google Cloud te proporciona este repositorio. Con Artifact Registry, tu organización puede gestionar tanto imágenes de contenedor como paquetes de lenguajes (como Maven y npm). Está totalmente integrado con las herramientas y los entornos de ejecución de Google Cloud y, además, ofrece compatibilidad con protocolos de artefactos nativos. Por eso, es muy fácil integrar esta solución con tus herramientas de CI/CD mientras configuras flujos de procesamiento automáticos.
Al igual que en el paso de la compilación, es esencial asegurarse de que los permisos de acceso a Artifact Registry se piensen detenidamente y sigan los principios de mínimos accesos. Además de restringir el acceso no autorizado, el repositorio de paquetes puede aportar mucho más valor. Por ejemplo, Artifact Registry incluye un análisis de vulnerabilidades para analizar tus imágenes y asegurarte de que son seguras. Este servicio analiza las imágenes en una base de datos de vulnerabilidades actualizada continuamente para evaluar las nuevas amenazas y puede avisarte cuando se detecte una vulnerabilidad.
Con este paso, se generan metadatos adicionales, como una atestación que indique si los resultados de la vulnerabilidad de un artefacto cumplen determinados umbrales de seguridad. Luego, esta información se almacena en nuestro servicio de análisis, que estructura y organiza los metadatos del artefacto, de modo que sea accesible fácilmente para la autorización binaria. Puedes usarlo para impedir automáticamente que se desplieguen imágenes peligrosas en Google Kubernetes Engine (GKE).
Fases 4 y 5: Desplegar y ejecutar
Las dos fases finales de la cadena de suministro de seguridad de software se despliegan y ejecutan. Aunque son dos pasos independientes, es lógico pensar en ellos como una forma de asegurarse de que solo las compilaciones autorizadas lleguen a producción.
En Google, hemos desarrollado prácticas recomendadas para determinar qué tipos de compilaciones se deben autorizar. Lo primero es garantizar la integridad de la cadena de suministro, de modo que solo produzca artefactos de confianza. A continuación, incluye la gestión de vulnerabilidades como parte del ciclo de vida de la entrega de software. Por último, hemos unido ambas piezas para aplicar flujos de trabajo según las políticas de integridad y análisis de vulnerabilidades.
Cuando llegues a esta fase, ya habrás completado las fases de código, compilación y paquete; Las atestaciones recogidas en la cadena de suministro se pueden verificar para verificar su autenticidad mediante autorización binaria. En el modo de cumplimiento, las imágenes solo se despliegan cuando las atestaciones cumplen las políticas de tu organización. En el modo de auditoría, las infracciones de las políticas se registran y activan alertas. También puedes usar la autorización binaria para impedir que se ejecuten las compilaciones, a menos que se hayan creado con el tratamiento de Cloud Build. La autorización binaria garantiza que solo se despliegue correctamente el código revisado y autorizado. .
Es fundamental desplegar las imágenes en un entorno de ejecución de confianza. Nuestra plataforma de Kubernetes gestionada, GKE, adopta un enfoque de seguridad centrado en los contenedores.
GKE se ocupa de la mayoría de las cuestiones de seguridad de los clústeres que necesitas. Las actualizaciones automáticas de clústeres te permiten mantener el parche y la actualización automática de Kubernetes automáticamente mediante los canales de lanzamiento. El inicio seguro, los nodos blindados y las comprobaciones de integridad garantizan que los componentes del kernel y el clúster de tu nodo no se hayan modificado, se esté ejecutando lo que quieres y los nodos maliciosos no puedan unirse a tu clúster. Por último, la computación confidencial te permite ejecutar clústeres con nodos cuya memoria está cifrada para que los datos puedan mantenerse confidenciales incluso mientras se procesan. Gracias a este servicio, puedes cifrar los datos mientras están en reposo y en tránsito por la red, y GKE proporciona un entorno muy seguro, privado y confidencial para ejecutar tus cargas de trabajo en contenedores.
Además de esto, GKE también ofrece una mejor seguridad para tus aplicaciones gracias a la gestión de certificados para tus balanceadores de carga, la identidad de las cargas de trabajo y las funciones avanzadas de red, gracias a un potente método de configuración y protección de la entrada en el clúster. GKE también ofrece entornos de espacio aislado para ejecutar aplicaciones que no son de confianza, al mismo tiempo que protege el resto de tus cargas de trabajo.
Con Autopilot de GKE, las funciones y las prácticas recomendadas de seguridad de GKE se implementan automáticamente, lo que reduce la superficie de ataque y minimiza la configuración errónea que puede provocar problemas de seguridad.
Por supuesto, no hace falta verificarla durante el despliegue. La autorización binaria también es compatible con la validación continua, lo que permite la conformidad continua de la política definida incluso después del despliegue. Si una aplicación en ejecución no cumple una política que ya existe o se acaba de añadir, se crea y se registra una alerta para que tengas la certeza de que lo que estás ejecutando en producción es exactamente lo que quieres.
Gestión de las vulnerabilidades
Además de garantizar la integridad, otro aspecto de la seguridad de la cadena de suministro es asegurarse de que las vulnerabilidades se encuentren rápidamente y tengan parches. Los atacantes han evolucionado para insertar vulnerabilidades en proyectos ascendentes. La gestión de vulnerabilidades y la detección de defectos se deben incorporar en todas las fases del ciclo de vida de la entrega de software.
Una vez que el código esté listo para desplegarse, usa un flujo de procesamiento de CI/ CD y aprovecha las numerosas herramientas disponibles para escanear los códigos fuente y los artefactos generados. Entre estas herramientas se incluyen analizadores estáticos, fuzzing y varios tipos de escáneres de vulnerabilidades.
Una vez que hayas desplegado tu carga de trabajo en producción y mientras se ejecuta y ofreces servicios a tus usuarios, debes monitorizar las amenazas emergentes y tener planes para resolver los problemas inmediatamente.
Conclusión
En resumen, para proteger una cadena de suministro de software, hay que seguir las prácticas recomendadas, como la SLSA, y usar servicios gestionados de confianza que te ayuden a implementarlas.
Es fundamental:
- Empieza por tu código y tus dependencias, y asegúrate de que sean de confianza.
- Protege tu sistema de compilación y usa atestaciones para verificar que se han seguido todos los pasos de compilación necesarios.
- Asegúrate de que todos tus paquetes y artefactos sean de confianza y que no se puedan manipular.
- Aplica controles sobre quién puede desplegar qué elementos y mantén un registro de auditoría. Usa la autorización binaria para validar atestaciones de cada artefacto que quieras desplegar.
- Ejecuta tus aplicaciones en un entorno de confianza y asegúrate de que nadie pueda manipularlas mientras se ejecutan. Presta atención a las vulnerabilidades recién descubiertas para proteger tu despliegue.
En Google, seguimos las prácticas recomendadas para cada paso de este recorrido, dentro de nuestra cartera de productos, para que tengas unos cimientos fiables sobre los que partir.
Primeros pasos
¿Todo listo para proteger tu cadena de suministro de software? Para empezar, está claro que el punto de partida no es exhaustivo, es decir, no hay ninguna acción que proteja toda la cadena de suministro, ni ninguna más importante que otra. en cuanto a la seguridad de la cadena de suministro. No obstante, aquí van cuatro recomendaciones para empezar.
1. Reparar el software
Si has implementado código en tu entorno de producción con vulnerabilidades conocidas, ya le has facilitado el trabajo al atacante. En ese caso, no importa si has protegido la cadena de suministro de software porque ya pueden entrar. Por ello, aplicar parches es fundamental.
2. Controla lo que se ejecuta en tu entorno
Una vez que hayas superado los parches, podrás controlar la cadena de suministro de tu software. En primer lugar, se debe poder verificar que lo que se está ejecutando realmente procede de tus herramientas de compilación o de repositorios de confianza. Ese nivel de control ayuda a evitar ataques intencionados y errores involuntarios, como el caso de un desarrollador que desarrolló algo que no sabía que no era seguro. De este modo, sentará una base sólida para añadir herramientas como las pruebas de clics y la autorización binaria.
3. Comprobar que los paquetes de proveedores externos sean seguros
Un problema emergente en la seguridad de la cadena de suministro es la frecuencia con la que se pone en riesgo el software de los proveedores para proporcionar un conducto de ransomware o acceso no autorizado a los despliegues de clientes de destino. Los paquetes de terceros que ejecutas en tu entorno (por ejemplo, productos de gestión de sistemas, de gestión de redes o de seguridad) suelen tener un alto grado de privilegios. Recomendamos a los proveedores que vayan más allá de las declaraciones de seguridad estándar para proporcionar un cierto nivel de garantía sobre los paquetes que usas. Podrías preguntar cuál es el nivel de conformidad del SLSA o si su ámbito cumple los requisitos de la reciente orden ejecutiva.
4. Ten una copia privada de tu código fuente
Si usas software de código abierto, no uses ninguna versión que hayas extraído directamente de Internet. Es mejor que tengas una copia privada con un parche que tengas siempre listo para que tengas un sitio desde el que empezar con todas las compilaciones y puedas saber con total confianza de dónde procede el código fuente.
Más información
Prácticas recomendadas de DevOps
- cloud.google.com/devops - Seis años del informe State of DevOps, un conjunto de artículos con información detallada sobre las capacidades que predicen el rendimiento del envío de software y una comprobación rápida para ayudarte a descubrir cómo te va y cómo mejorar.
- Informe "Google State 2021 Accelerate State of DevOps" 2021
- Informe de Google Cloud: Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale
Proteger la cadena de suministro de software
- Blog de Google Cloud: ¿Qué es la seguridad de identidad de confianza cero?
- Blog sobre seguridad de Google: Presentamos SLSA, un framework integral para la integridad de la cadena de suministro
- Informe de Google Cloud sobre cómo proteger la seguridad en las cadenas de suministro de software
¿Todo listo para dar los siguientes pasos?
Rellena el formulario y nos pondremos en contacto contigo. Ver formulario