Este contenido se actualizó por última vez en mayo del 2024 y representa la situación en el momento en que se redactó. Las políticas y los sistemas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos constantemente la protección que proporcionamos a nuestros clientes.
En este documento se describe cómo usamos las revisiones de código, la infraestructura de seguridad y una comprobación de cumplimiento llamada Autorización binaria para Borg (BAB) para proteger la cadena de suministro de software de Google frente al riesgo interno. BAB ayuda a reducir los riesgos internos porque se asegura de que el software de producción se revise y apruebe antes de desplegarse, sobre todo cuando nuestro código puede acceder a datos sensibles. BAB se aplica a todos los servicios que se ejecutan en Borg. Desde la publicación original de este documento, hemos incluido conceptos clave de BAB en una especificación abierta llamada Niveles de la cadena de suministro para artefactos de software (SLSA).
Este documento forma parte de una serie de documentos técnicos en los que se describen algunos proyectos que ha desarrollado el equipo de seguridad de Google para mejorar la seguridad, como BeyondCorp y BeyondProd. Para obtener información general sobre la seguridad de nuestra infraestructura, consulta la descripción general del diseño de seguridad de la infraestructura de Google.
Introducción
Los riesgos internos representan una amenaza para la seguridad de los datos de usuario, que pueden incluir datos laborales, datos financieros u otros datos confidenciales o empresariales. El riesgo interno es la posibilidad de que un empleado utilice su conocimiento de la organización o su acceso para llevar a cabo actos maliciosos, o de que un atacante externo utilice las credenciales de un empleado que se hayan visto comprometidas para hacer lo mismo.
Para minimizar los riesgos internos en nuestra cadena de suministro de software, utilizamos BAB. BAB es una comprobación interna del cumplimiento que se realiza cuando se despliega el software. BAB se asegura de que los despliegues de código y configuración cumplan una serie de estándares mínimos y respalden la uniformidad de nuestros sistemas de producción.
Ayudamos a proteger los datos de los usuarios en nuestros sistemas de producción limitando el acceso unilateral por parte de nuestros empleados. BAB ayuda a asegurar que los empleados, cuando actúan por su cuenta, no puedan acceder a datos de usuario ni modificarlos, ya sea directa o indirectamente, sin la autorización y la justificación adecuadas. BAB y sus controles asociados nos ayudan a aplicar el principio de mínimos accesos, lo que mejora nuestra postura de seguridad independientemente de un agente de amenazas específico. En otras palabras, BAB limita el acceso unilateral, independientemente de si el actor tiene mala fe, si se ha vulnerado la seguridad de su cuenta o si se le ha concedido acceso de manera accidental.
Ventajas de BAB
La adopción de BAB y de un modelo de despliegue en contenedores aporta muchas ventajas de seguridad a la infraestructura de Google. Entre las ventajas se incluyen las siguientes:
- BAB contribuye a mitigar los riesgos internos generales: BAB exige que el código cumpla unos estándares y unas prácticas de gestión del cambio concretos antes de poder acceder a datos de usuario. Este requisito reduce las probabilidades de que un empleado que actúe individualmente o cuya cuenta se haya visto vulnerada acceda a datos de usuario de manera programática.
- BAB respalda la uniformidad de los sistemas de producción: gracias al uso de sistemas en contenedores y a la verificación de sus requisitos en cuanto a BAB antes del despliegue, nuestros sistemas ganan en facilidad de depuración, en fiabilidad y en claridad en los procesos de gestión del cambio. Los requisitos de BAB aportan un lenguaje común a los requisitos de los sistemas de producción.
- BAB dicta el uso de un lenguaje común para la protección de datos. BAB hace un seguimiento de la conformidad en todos los sistemas de Google. Los datos relativos a dicha conformidad se publican internamente y están disponibles para otros equipos. La publicación de datos de BAB permite a los equipos usar los mismos términos en sus comunicaciones acerca de la protección del acceso a los datos. Este lenguaje común reduce el envío y la recepción de mensajes que caracterizan al trabajo con datos entre varios equipos.
- BAB admite el seguimiento programático de los requisitos de cumplimiento normativo: BAB simplifica lo que anteriormente eran tareas manuales de cumplimiento normativo. Algunos procesos de Google exigen un control más riguroso de la forma en que gestionamos los datos. Por ejemplo, nuestros sistemas de información financiera deben cumplir obligatoriamente la Sarbanes-Oxley Act (SOX, ley estadounidense Sarbanes-Oxley). Antes de desarrollar BAB, contábamos con un sistema que nos ayudaba a hacer verificaciones manuales para asegurarnos de que cumplíamos con la normativa. Con la introducción de BAB, muchas de estas comprobaciones se automatizaron a partir de las políticas de BAB de los servicios. La automatización de dichas comprobaciones posibilitó que el equipo de cumplimiento normativo ampliara el alcance de los servicios cubiertos y la adopción de controles adecuados para estos.
BAB forma parte del marco más amplio BeyondProd que utilizamos para mitigar los riesgos internos.
Nuestro proceso de desarrollo y producción
De forma predeterminada, el proceso de desarrollo y producción de Google incluye cuatro pasos obligatorios: revisión de código, compilaciones verificables, despliegue en contenedores e identidad basada en servicios. En las siguientes secciones se describen estos pasos con más detalle.
Paso 1: Revisión de código
La mayor parte de nuestro código fuente se almacena en un repositorio monolítico central, y requiere la revisión y la aprobación de al menos un ingeniero que no sea el autor. Un código base monolítico permite aplicar un único punto crítico para las revisiones de código.
Como mínimo, nuestro proceso de revisión de código requiere que los propietarios de un sistema aprueben las modificaciones de código de ese sistema.
Al importar cambios procedentes de código fuente de terceros o código abierto, verificamos que el cambio sea pertinente (por ejemplo, comprobando la última versión). Sin embargo, cada uno de los cambios que los desarrolladores externos introducen en esos tipos de código que utilizamos no suelen pasar los mismos controles de revisión.
Paso 2: Compilaciones verificables
Nuestro sistema de compilación es similar a Bazel, que crea y compila código fuente para generar un archivo binario para su despliegue. Nuestro sistema de compilación se ejecuta en un entorno aislado y bloqueado que se encuentra separado de los empleados que hacen las compilaciones. En cada compilación, el sistema genera procedencias de compilaciones verificables . Esta procedencia es un certificado firmado que describe las fuentes y las dependencias que se han usado en la compilación, los hashes criptográficos de cualquier binario u otro artefacto de compilación, y la totalidad de parámetros de la compilación. Esta procedencia permite lo siguiente:
- La capacidad de rastrear un archivo binario hasta el código fuente que se usó en su creación. Por extensión, la procedencia también puede rastrear el proceso asociado a la creación y envío del código fuente que describe a dicho binario.
- La capacidad de verificar que el archivo binario no se ha modificado, ya que cualquier cambio en el archivo invalidaría automáticamente su firma.
Puesto que las acciones de compilación pueden ser constitutivas de código arbitrario, nuestro sistema de compilación se ha fortalecido teniendo en cuenta varios propietarios. Es decir, el diseño de nuestro sistema de compilación está orientado a impedir que una compilación influya en otras. El sistema impide que las compilaciones induzcan cambios que pudieran vulnerar la integridad de la procedencia de la compilación o la del propio sistema. Una vez que se haya completado la compilación, el cambio se desplegará mediante Borg.
Paso 3: Despliegue en contenedores
Una vez que el sistema de compilación crea el archivo binario, se empaqueta en una imagen de contenedor y se despliega como una tarea de Borg en nuestro sistema de orquestación de clústeres, Borg. Ejecutamos cientos de miles de tareas desde muchas aplicaciones de múltiples clústeres. Cada uno de ellos está compuesto por decenas de miles de máquinas. A pesar de una escala como esta, nuestro entorno de producción es bastante homogéneo. En consecuencia, los puntos de contacto correspondientes al acceso a datos de usuario se pueden controlar y auditar con mayor facilidad.
Los contenedores ofrecen importantes ventajas de seguridad. Los contenedores están pensados para ser inmutables y suelen volver a desplegarse a partir de una recompilación íntegra de imágenes. La contenerización nos permite revisar contextualmente los cambios en el código y facilita un único punto crítico para los cambios que se implementan en nuestra infraestructura.
La configuración de una tarea de Borg especifica los requisitos que precisa la tarea que debe desplegarse: las imágenes de contenedor, los parámetros del entorno de ejecución, los argumentos y las marcas. Borg programa la tarea teniendo en cuenta sus limitaciones, prioridad, cuota y cualquier otro requisito que venga recogido en la configuración. Tras su despliegue, la tarea de Borg puede interactuar con otras tareas que estén en fase de producción.
Paso 4: Identidad basada en servicios
Las tareas de Borg se ejecutan como identidades de servicio. Esta identidad se usa para acceder a almacenes de datos o a métodos de llamada a procedimiento remoto (RPC) de otros servicios. Es posible que varias tareas se ejecuten bajo la misma identidad. Solo los empleados responsables de ejecutar el servicio (normalmente, ingenieros de fiabilidad de sitios web (SRE)) pueden desplegar o modificar tareas con una identidad determinada.
Cada vez que Borg inicia una tarea, la aprovisiona mediante credenciales criptográficas. La tarea utiliza estas credenciales para probar su identidad al hacer solicitudes de otros servicios mediante ALTS (seguridad de transporte en la capa de la aplicación). Para que un servicio pueda acceder a determinados datos o a otro servicio, su identidad debe contar con los permisos necesarios.
Nuestras políticas requieren la protección de BAB para las identidades de servicio que tengan acceso a datos de usuario y a cualquier otra información sensible. Las tareas de control de calidad y desarrollo que no tengan acceso a datos sensibles pueden ejecutarse con menos controles.
Cómo funciona BAB
BAB se integra con Borg para asegurarse de que solo se puedan ejecutar tareas autorizadas con la identidad de cada servicio. BAB también crea un registro de auditoría del código y la configuración utilizados en las tareas habilitadas para BAB para permitir la monitorización y la respuesta ante incidentes.
BAB se ha diseñado para asegurarse de que todo el software y la configuración de producción se revisen, se registren, se compilen de forma verificable y se autoricen correctamente, sobre todo cuando el código puede acceder a datos de usuario.
Política específica del servicio
Cuando los propietarios de servicios incorporan su servicio a Borg, crean una política de BAB que define los requisitos de seguridad de su servicio. Esta política se denomina política específica del servicio. La definición o la modificación de cualquier política comporta en sí un cambio en el código que es obligatorio revisar.
La política específica del servicio define qué código y configuración se pueden ejecutar como identidad del servicio, así como las propiedades obligatorias de ese código y configuración. Todos los trabajos que se ejecuten como identidad de servicio deben cumplir la política específica del servicio.
Todos los servicios de Borg de Google deben configurar una política específica del servicio.
De forma predeterminada, esta práctica aplica los siguientes requisitos:
- El código debe poder auditarse: podemos rastrear la imagen de contenedor hasta sus fuentes legibles por humanos mediante la procedencia generada por compilaciones verificables. Una política de conservación mantiene las fuentes legibles por humanos del código durante al menos 18 meses, incluso si el código no se envía.
- Se debe enviar el código: el código se compila a partir de una ubicación especificada y definida de nuestro repositorio de código fuente. El envío suele conllevar que el código se someta a revisión.
- Envío de configuraciones: Toda configuración proporcionada durante el despliegue pasa el mismo proceso de revisión y envío que el código habitual. Por lo tanto, los valores, los argumentos y los parámetros de marca de línea de comandos no se pueden modificar sin que se hayan revisado.
Los servicios que no tienen acceso a datos sensibles (o, en raras ocasiones, los que tienen una excepción válida y aprobada) pueden tener una política más permisiva, como una que solo requiera la auditabilidad del código o incluso una que desactive BAB por completo.
Los sistemas y los componentes que aplican BAB se controlan de manera rigurosa mediante requisitos automatizados estrictos y controles manuales adicionales.
Modos de cumplimiento
BAB usa dos modos obligatorios para asegurarse de que los trabajos cumplan la política específica del servicio:
- La validación en tiempo de implementación, que impide que se implementen las tareas que no cumplen los requisitos.
- Validación continua, que monitoriza y envía alertas sobre los trabajos no conformes que se han desplegado.
Además, en caso de emergencia, los procedimientos de respuesta ante emergencias pueden eludir el cumplimiento en tiempo de implementación.
Modo de cumplimiento en el momento del despliegue
Borg Prime es el controlador centralizado de Borg, que actúa como autoridad de certificación de ALTS. Cuando se envía una tarea nueva, Borg Prime consulta a BAB para comprobar si dicha tarea cumple los requisitos de la política específica del servicio antes de que Borg Prime le conceda el certificado ALTS. Esta comprobación hace las veces de controlador de admisión: Borg solo inicia la tarea si cumple la política específica del servicio. Esta comprobación se realiza incluso cuando el empleado o el servicio que hace la solicitud de implementación tiene autorización.
En casos excepcionales, los servicios pueden inhabilitar la aplicación en tiempo de implementación con una justificación adecuada.
Modo de verificación continua
Una vez que se despliega, la tarea se verifica de forma continuada durante su vida útil, sin importar su modo de cumplimiento en el momento del despliegue. Los procesos de BAB se ejecutan como mínimo una vez al día para comprobar que las tareas iniciadas (y que pudieran estar aún en ejecución) cumplan cualquier actualización de sus políticas. Por ejemplo, el modo de verificación continua comprueba de forma constante si existen tareas que se ejecutan con políticas obsoletas o que se hayan desplegado a través de procedimientos de respuesta ante emergencias. Si se detecta una tarea que incumple la política más reciente, BAB lo notifica a los propietarios de servicios de modo que puedan mitigar el riesgo.
Procedimientos de respuesta ante emergencias
En caso de incidencias o interrupciones, nuestra principal prioridad es restaurar tan rápido como sea posible los servicios afectados. En caso de emergencia, quizás sea necesario ejecutar código que no se ha revisado ni compilado de manera verificable. En consecuencia, se puede anular el modo de cumplimiento mediante una marca de respuesta ante emergencias. Los procedimientos de respuesta ante emergencias también desempeñan funciones de copia de seguridad en caso de que surja cualquier fallo de BAB que acabe bloqueando despliegues de cualquier otra manera. Cuando un desarrollador despliega una tarea mediante el procedimiento de respuesta ante emergencias, debe enviar una justificación como parte de su solicitud.
Durante una respuesta ante emergencias, BAB registra detalles sobre la tarea de Borg asociada y envía una notificación al equipo de seguridad centralizado de Google y al equipo propietario de la identidad del servicio. La entrada de registro incluye una referencia a una instantánea del código que se implementó y la justificación proporcionada por el usuario. Los procedimientos de respuesta ante emergencias solo están concebidos como último recurso.
Extender BAB a otros entornos
Al principio, BAB solo admitía la protección de tareas de Borg y requería que el software se desarrollara con la canalización tradicional de control de código fuente, compilación y empaquetado de Google. Ahora, BAB también protege otros entornos de entrega e implementación de software, y admite sistemas alternativos de control de código fuente, compilación y empaquetado. Los detalles de implementación de estos entornos varían, pero las ventajas de BAB siguen siendo las mismas.
Hay algunos casos que no se prestan con facilidad a revisiones de código por humanos antes de la implementación, como el desarrollo iterativo de código de aprendizaje automático y el análisis de datos de alta frecuencia. En estos casos, tenemos controles alternativos que compensan la revisión humana.
Adopción de controles similares en tu organización
En esta sección se describen las prácticas recomendadas que hemos aprendido al implementar BAB para que puedas adoptar controles similares en tu organización.
Crear un flujo de procesamiento de CI/CD en contenedores homogéneo
La adopción de BAB fue más sencilla porque la mayoría de los equipos usaban un único sistema de control de fuentes, proceso de revisión de código, sistema de compilación y sistema de implementación. Las revisiones de código ya formaban parte de nuestra cultura, por lo que pudimos hacer cambios sin que los usuarios notaran grandes diferencias. Para adoptar BAB, nos centramos en las revisiones de código, las compilaciones verificables, los despliegues en contenedores y las identidades basadas en servicios para el control de accesos. Este enfoque simplificó la adopción de BAB y reforzó las garantías que aportaba una solución como BAB.
El uso generalizado de microservicios e identidades basadas en servicios (como cuentas de servicio) en lugar de identidades basadas en hosts (como direcciones IP) nos permite tener un control pormenorizado sobre el software que puede ejecutar cada servicio.
Si tu organización no puede adoptar una identidad de servicio directamente, puedes probar a proteger los tokens de identidad con otras medidas como paso provisional.
Fíjate metas y define tus políticas en función de los requisitos que tengas
Construye poco a poco un proceso de lanzamiento basado en políticas. Quizás tengas que implementar determinados cambios antes que otros en tu flujo de procesamiento de CI/CD. Por ejemplo, es posible que debas empezar a hacer revisiones de código formales antes de poder implementar dichos cambios en el momento del despliegue.
Un estimulante extraordinario de cualquier proceso de lanzamiento basado en políticas es el cumplimiento normativo. Si eres capaz de codificar, como mínimo, algunos de tus requisitos de cumplimiento en una política, esto puede ayudarte a automatizar tus pruebas y a garantizar su vigencia en todo momento. Empieza con un conjunto básico de requisitos y, paulatinamente, ve codificando requisitos más avanzados.
Implementa las políticas en las fases tempranas del desarrollo
Resulta complicado definir políticas exhaustivas en un software sin conocer antes dónde se va a ejecutar y a qué datos va a acceder. Por lo tanto, la implementación de las políticas específicas de cada servicio se ejecuta no al compilarse el código, sino al desplegarse o al acceder este a datos. Las políticas se definen en términos de identidad en el momento de la ejecución, de modo que el mismo código podría ejecutarse en entornos diferentes y quedar sujeto a políticas distintas.
Nos ayudamos de BAB en combinación con otros mecanismos de acceso para limitar el acceso a datos de usuario. Los propietarios de servicios pueden reforzar las garantías de que a los datos solo acceden tareas que cumplan determinados requisitos de BAB.
Busca agentes del cambio entre los equipos
Una vez que establecimos la norma de desplegar BAB en toda la organización de Google , lo que más favoreció a nuestra tasa de éxito fue encontrar propietarios que impulsaran el cambio en todos los grupos de productos. Identificamos a un grupo de propietarios de servicios que apreciaron las ventajas directas de la implementación y que estaban dispuestos a aportar comentarios. Les pedimos a estos propietarios que se ofrecieran como voluntarios antes de hacer obligatorio cualquier cambio. Tras conseguir su ayuda, constituimos un equipo formal de gestión del cambio para hacer un seguimiento de los cambios en curso. Seguidamente, identificamos en el equipo de cada producto propietarios responsables para implementar los cambios.
Determinar cómo gestionar el código de terceros
Si debes gestionar código de terceros, piensa cómo vas a introducir los requisitos de tu política en la base de código de terceros. Por ejemplo, podrías empezar por mantener un repositorio de todo el código de terceros que se ha utilizado. Te recomendamos que cotejes regularmente ese código con tus requisitos de seguridad.
Para obtener más información sobre cómo gestionar el código de terceros, consulta el artículo Shared success in building a safer open source community (Éxito compartido en la creación de una comunidad de código abierto más segura).
Siguientes pasos
- Consulta información sobre BeyondProd, que usamos para crear un perímetro seguro alrededor de nuestros microservicios.
- Para adoptar una canalización de CI/CD segura, consulta Niveles de la cadena de suministro para artefactos de software (SLSA).