Este contenido se actualizó por última vez en mayo de 2024 y representa el statu quo en el momento de su redacción. Es posible que cambien las políticas y los sistemas de seguridad de Google de ahora en adelante, ya que mejoramos la protección de nuestros clientes de forma continua.
En este documento, se describe cómo usamos las revisiones de código, la infraestructura de seguridad y una verificación de aplicación llamada Autorización binaria para Borg (BAB) a fin de ayudar a proteger la cadena de suministro de software de Google contra el riesgo de tener usuarios con información privilegiada. BAB ayuda a reducir el riesgo con respecto a los usuarios con información privilegiada porque garantiza que el software de producción se revise y apruebe antes de que se implemente, en especial cuando nuestro código puede acceder a los datos sensibles. BAB se aplica a todos los servicios que se ejecutan en Borg. Desde la publicación original de este documento, incluimos conceptos clave de BAB en una especificación abierta llamada Niveles de cadena de suministro para artefactos de software (SLSA).
Este documento es parte de una serie de documentos técnicos que describen algunos proyectos que el equipo de seguridad de Google desarrolló para ayudar a mejorar la seguridad, como BeyondCorp y BeyondProd. Para obtener una descripción general de la seguridad de nuestra infraestructura, consulta la descripción general del diseño de seguridad de la infraestructura de Google.
Introducción
El riesgo relacionado con usuarios con información privilegiada representa una amenaza a la seguridad de los datos del usuario, que puede incluir datos de empleo, datos financieros, o bien otros datos propietarios o de la empresa. El riesgo de infiltración es la posibilidad de que un empleado use su conocimiento organizativo o acceso para realizar acciones maliciosas o que un atacante externo use las credenciales vulneradas de un empleado para hacer lo mismo.
Para minimizar el riesgo de tener usuarios con información privilegiada dentro de nuestra cadena de suministro de software, usamos BAB. BAB es una verificación de aplicación interna que se produce cuando se implementa un software. BAB garantiza que las implementaciones de código y configuración cumplan con determinados estándares y uniformidad de asistencia en nuestros sistemas de producción.
Ayudamos a proteger los datos del usuario dentro de nuestros sistemas de producción, ya que limitamos el acceso unilateral de nuestros empleados. BAB ayuda a garantizar que los empleados, cuando actúen solos, no puedan acceder de forma directa ni indirecta a los datos del usuario ni afectarlos de otra manera sin la autorización y la justificación adecuadas. BAB y sus controles asociados nos ayudan a aplicar el privilegio mínimo, lo que mejora nuestra postura de seguridad de manera independiente de un actor de amenaza específico. En otras palabras, BAB limita el acceso unilateral, sin importar si la persona tiene una intención maliciosa, si su cuenta se vio comprometida o si se le otorgó acceso de forma involuntaria.
Beneficios de BAB
La adopción de BAB y un modelo de implementación en contenedores ofrece muchos beneficios de seguridad a la infraestructura de Google. Los beneficios son los siguientes:
- BAB ayuda a reducir el riesgo general con respecto a los usuarios con información privilegiada: BAB requiere código para cumplir determinados estándares y prácticas de administración de cambios antes de que el código pueda acceder a los datos del usuario. Este requisito reduce la posibilidad de que un empleado que actúa solo (o una cuenta de empleado comprometida) acceda a los datos del usuario de manera programática.
- BAB admite la uniformidad de los sistemas de producción: cuando se utilizan sistemas en contenedores y se verifican los requisitos de BAB antes de la implementación, nuestros sistemas se vuelven más fáciles de depurar y más confiables, y tienen procesos de administración de cambios bien definidos. Los requisitos de BAB proporcionan un lenguaje común para los requisitos del sistema de producción.
- BAB dicta un lenguaje común para la protección de los datos: BAB realiza un seguimiento de la conformidad en todos los sistemas de Google. Los datos sobre esta conformidad se publican de forma interna y están disponibles para otros equipos. La publicación de datos de BAB permite a los equipos usar términos comunes cuando se comunican entre sí sobre la protección de acceso a los datos. Este lenguaje común reduce el trabajo de ida y vuelta que se necesita cuando se trabaja con datos entre equipos.
- BAB permite realizar un seguimiento programático de los requisitos de cumplimiento: BAB simplifica las tareas que antes eran manuales. Algunos procesos en Google requieren controles más estrictos sobre cómo manejamos los datos. Por ejemplo, nuestros sistemas de informes financieros deben cumplir con la Ley Sarbanes-Oxley (SOX). Antes de BAB, teníamos un sistema que nos ayudaba a realizar verificaciones de forma manual para garantizar nuestro cumplimiento. Con la introducción de BAB, muchas de estas verificaciones se automatizaron según las políticas de BAB para los servicios. La automatización de estas verificaciones le permitió al equipo de cumplimiento aumentar los permisos de los servicios cubiertos y la adopción de los controles adecuados para estos servicios.
BAB es parte del framework más grande de BeyondProd que usamos para mitigar el riesgo con respecto a los usuarios con información privilegiada.
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, compilación verificable, implementación alojada en contenedores e identidad basada en servicios. En las siguientes secciones, se describen esos pasos con más detalle.
Paso 1: Revisión del código
La mayor parte de nuestro código fuente se almacena en un repositorio monolítico central , y requiere revisión y aprobación de al menos un ingeniero distinto del autor. Una base de código monolítica permite la aplicación de un punto de bloqueo único para las revisiones de códigos.
Como mínimo, nuestro proceso de revisión de códigos requiere que los propietarios de un sistema deben aprobar las modificaciones del código en ese sistema.
Cuando importas cambios de terceros o código fuente abierto, verificamos que el cambio sea apropiado (por ejemplo, la versión más reciente). Sin embargo, no solemos tener los mismos controles de revisión para cada cambio que realizan los desarrolladores externos en el código de terceros o código fuente abierto que usamos.
Paso 2: Compilaciones verificables
Nuestro sistema de compilación es similar a Bazel, que crea y compila código fuente a fin de crear un objeto binario para la implementación. Nuestro sistema de compilación se ejecuta en un entorno aislado y bloqueado que está separado de los empleados que realizan las compilaciones. Para cada compilación, el sistema produce procedencia generada por compilaciones verificables . Esta procedencia es un certificado firmado que describe las fuentes y las dependencias que ingresaron a la compilación, los hash criptográficos de cualquier objeto binario o de otros artefactos de compilación y los parámetros de compilación completos. Esta procedencia habilita lo siguiente:
- La capacidad de realizar un seguimiento de un objeto binario en el código fuente que se usa durante su creación. Por extensión, la procedencia también puede rastrear el proceso en torno a la creación y el envío del código fuente que describe.
- La capacidad de verificar que el objeto binario no se modificó, ya que cualquier cambio en el archivo invalidaría su firma de forma automática.
Debido a que las acciones de compilación pueden ser código arbitrario, nuestro sistema de compilación se reforzó para multiusuario. En otras palabras, nuestro sistema de compilación está diseñado para impedir que una compilación influya en otra. El sistema impide que las compilaciones realicen cambios que podrían comprometer la integridad de la procedencia de compilación o del propio sistema. Una vez que se completa la compilación, el cambio se implementa con Borg.
Paso 3: Implementación en contenedores
Una vez que el sistema de compilación crea el objeto binario, se empaqueta en una imagen de contenedor y se implementa como un Trabajo de Borg en nuestro sistema de organización de clústeres, Borg. Ejecutamos cientos de miles de trabajos desde diferentes aplicaciones en varios clústeres, cada uno con hasta decenas de miles de máquinas. A pesar de esta escala, nuestro entorno de producción es bastante homogéneo. Por ello, los puntos de contacto para acceder a los datos del usuario se pueden controlar y auditar con mayor facilidad.
Los contenedores proporcionan beneficios de seguridad notables. Los contenedores están diseñados para ser inmutables, con reimplementaciones frecuentes a partir de una recompilación completa de la imagen. La creación de contenedores nos permite revisar un cambio de código en contexto y proporciona un punto de bloqueo único para los cambios que se implementan en nuestra infraestructura.
La configuración de un trabajo de Borg especifica los requisitos para el trabajo que se implementará: imágenes de contenedor, parámetros de entorno de ejecución, argumentos y marcas. Borg programa el trabajo y tiene en cuenta las restricciones, prioridad, cuota y otros requisitos del trabajo que se enumeran en la configuración. Después de implementar el trabajo, el trabajo de Borg puede interactuar con otros trabajos en producción.
Paso 4: Identidad basada en el servicio
Un trabajo de Borg se ejecuta como una identidad de servicio. Esta identidad se usa para acceder a almacenes de datos o a procedimientos remotos llamadas (RPC) de otros servicios. Es posible que varios trabajos se ejecuten como la misma identidad. Solo los empleados que son responsables de ejecutar el servicio (por lo general, ingenieros de confiabilidad de sitios (SRE)) pueden implementar o modificar trabajos con una identidad específica.
Cuando Borg inicia un trabajo, lo aprovisiona con credenciales criptográficas. El trabajo usa estas credenciales para demostrar su identidad cuando realiza solicitudes de otros servicios (mediante la Seguridad de transporte de la capa de la aplicación (ALTS). Para que un servicio acceda 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 tienen acceso a los datos del usuario y a cualquier otra información sensible. Trabajos de control de calidad y desarrollo que no tienen acceso a datos sensibles se pueden ejecutar con menos controles.
Cómo funciona BAB
BAB se integra en Borg para garantizar que solo los trabajos autorizados puedan ejecutarse con la identidad de cada servicio. BAB también crea un registro de auditoría del código y la configuración que se usa en los trabajos habilitados para BAB a fin de permitir la supervisión y el respuesta ante incidentes.
BAB se diseñó para garantizar que todo el software de producción y la configuración se revisen, verifiquen, compilen y autoricen de forma adecuada, en especial cuando ese código puede acceder a los datos del usuario.
Política específica del servicio
Cuando los propietarios del servicio integran su servicio a Borg, crean una política de BAB que define los requisitos de seguridad para su servicio. Esta política se denomina política específica del servicio. Definir o modificar una política implica un cambio de código que debe someterse a una revisión.
La política específica del servicio define qué código y configuración se puede ejecutar como la identidad del servicio, así como las propiedades obligatorias de ese código y esa configuración. Todos los trabajos que se ejecutan como la identidad del servicio deben cumplir con la política específica del servicio.
Todos los servicios de Borg en Google son necesarios para configurar una política específica del servicio.
De forma predeterminada, esta práctica aplica los siguientes requisitos:
- El código debe ser auditable: Podemos rastrear la imagen del contenedor hasta sus fuentes legibles a través de procedencia generadas por compilaciones verificables. Una política de retención conserva las fuentes de lectura legibles 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 en una ubicación definida y especificada en nuestro repositorio de código fuente. Por lo general, esto implica que el código se sometió a una revisión.
- Se deben enviar las configuraciones: Cualquier configuración que se proporcione durante la implementación pasa por el mismo proceso de revisión y envío que el código normal. Por lo tanto, los valores, argumentos y parámetros de la marca de la línea de comandos no se pueden modificar sin revisión.
Los servicios que no tienen acceso a datos sensibles o, en circunstancias excepcionales, los servicios que tienen una excepción válida y aprobada, pueden tener una política más permisiva, como una que solo requiere auditabilidad de código, o incluso uno que desactive BAB por completo.
Los sistemas y componentes que aplica BAB se controlan de forma estricta mediante requisitos automatizados estrictos y controles manuales adicionales.
Modos de aplicación
BAB usa dos modos de aplicación para garantizar que todos los trabajos cumplan con la política específica del servicio:
- Aplicación en el momento de la implementación, que bloquea la implementación de trabajos que no cumplan con las políticas.
- Validación continua, que supervisa y alerta sobre los trabajos que no cumplen con las normas que se implementaron.
Además, en caso de una emergencia, los procedimientos de respuesta ante emergencias pueden omitir la aplicación en el momento de la implementación.
Modo de aplicación en el momento de la implementación
Borg Prime es el controlador centralizado de Borg, que actúa como la autoridad certificadora para ALTS. Cuando se envía un trabajo nuevo, Borg Prime consulta a BAB para verificar que el trabajo cumpla con los requisitos de la política específica del servicio antes de que Borg Prime le otorgue el certificado ALTS al trabajo. Esta verificación funciona como un controlador de admisión: Borg solo inicia el trabajo si cumple con la política específica del servicio. Esta verificación se produce incluso cuando el empleado o servicio que realiza la solicitud de implementación está autorizado.
En casos excepcionales, los servicios pueden inhabilitar la aplicación en el momento de la implementación con una justificación adecuada.
Modo de verificación continua
Después de implementar un trabajo, se verifica de forma continua durante su vida útil, sin importar el modo de aplicación en el momento de la implementación. Un proceso de BAB se ejecuta al menos una vez al día para verificar que los trabajos que se iniciaron (y que aún puedan seguir en ejecución) se ajusten a las actualizaciones de sus políticas. Por ejemplo, el modo de verificación continua verifica en todo momento los trabajos que se ejecutan con políticas desactualizadas o que se implementaron con procedimientos de respuesta ante emergencias. Si se descubre que un trabajo no cumple con la política más reciente, BAB notifica a los propietarios del servicio para que puedan mitigar el riesgo.
Procedimientos de respuesta ante emergencias
Cuando ocurre un incidente o una interrupción, nuestra prioridad es restablecer el servicio afectado lo más rápido posible. En una situación de emergencia, es posible que sea necesario ejecutar un código que no se revisó ni se compiló de forma verificable. Por ello, se puede anular el modo de aplicación con una marca de respuesta ante emergencias. Los procedimientos de respuesta ante emergencias también funcionan como una copia de seguridad en caso de existir una falla de BAB que, de lo contrario, bloquearía una implementación. Cuando un desarrollador implementa un trabajo mediante el procedimiento de respuesta ante emergencias, debe enviar una justificación como parte de su solicitud.
Durante una respuesta ante emergencias, BAB registra los detalles sobre el trabajo de Borg asociado y envía una notificación al equipo de seguridad centralizado de Google y el equipo que posee la identidad del servicio. En la entrada de registro, se incluye una referencia a una instantánea del código que se implementó y la justificación que proporcionó el usuario. Los procedimientos de respuesta ante emergencias solo se deben usar como un último recurso.
Extiende BAB a otros entornos
En un principio, BAB solo admitía la protección de los trabajos de Borg y requería que el software se desarrollara con la canalización de compilación, empaquetado y control de fuente tradicionales de Google. Ahora, BAB agregó compatibilidad para proteger otros entornos de entrega y de implementación de software y compatibilidad con sistemas alternativos de control de fuente, compilación y empaquetado. Los detalles de implementación para estos diversos entornos difieren, pero los beneficios de BAB permanecen.
Existen algunos casos que no son adecuados para las revisiones de códigos manuales antes de la implementación, en particular el desarrollo iterativo del 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 manual.
Adopta controles similares en tu organización
En esta sección, se describen las prácticas recomendadas que aprendimos a medida que implementamos BAB para que puedas adoptar controles similares en tu organización.
Crea una canalización de CI/CD en contenedores homogénea
Se facilitó la adopción de BAB porque la mayoría de los equipos usaron un solo sistema de control de origen, proceso de revisión de código, sistema de compilación y sistema de implementación. Las revisiones de código ya eran parte de nuestra cultura, por lo que pudimos realizar cambios sin demasiados cambios visibles para el usuario. Para adoptar BAB, nos enfocamos en las revisiones de código, las compilaciones verificables, las implementaciones en contenedores y las identidades basadas en servicios para el control de acceso. Este enfoque simplificó la adopción de BAB y reforzó las garantías que una solución como BAB puede ofrecer.
Nuestro uso generalizado de microservicios e identidades basadas en servicios (como cuentas de servicio), en lugar de identidades basadas en host (como direcciones IP), nos permite compilar un control detallado sobre el software que puede ejecutar cada servicio.
Si tu organización no puede adoptar una identidad de servicio directamente, puedes intentar proteger los tokens de identidad con otras medidas como un paso intermedio.
Determina los objetivos y define las políticas según los requisitos
Compila el proceso de actualización basado en políticas parte por parte. Es posible que debas implementar algunos cambios antes que otros en la canalización de CI/CD. Por ejemplo, es posible que debas comenzar a realizar revisiones de código formales antes de poder aplicarlas en el momento de la implementación.
Un gran motivador para un proceso de actualización basado en políticas es el cumplimiento. Si puedes codificar al menos algunos de tus requisitos de cumplimiento en una política, esto puede ayudar a automatizar las pruebas y garantizar que estén vigentes de manera confiable. Comienza con una serie de requisitos básicos y codifica los requisitos más avanzados sobre la marcha.
Aplica las políticas al principio del desarrollo
Es difícil definir políticas integrales en una parte del software sin primero saber dónde se ejecutará y a qué datos accederá. Por lo tanto, la aplicación de políticas específica del servicio se realiza cuando se implementa el código y este accede a los datos, y no cuando se compila. Una política se define en términos de una identidad de entorno de ejecución, por lo que el mismo código se puede ejecutar en entornos distintos y estar sujeto a políticas diferentes.
Además de otros mecanismos de acceso, usamos BAB para restringir el acceso a los datos del usuario. Los propietarios del servicio pueden asegurarse de que un trabajo que cumple con los requisitos de BAB solo acceda a los datos.
Recluta agentes de cambio en todos los equipos
Cuando creamos un mandato para todo Google para la implementación de BAB, lo que más afectó nuestra tasa de éxito fue encontrar propietarios que impulsaran el cambio en cada grupo de productos. Identificamos a algunos propietarios del servicio que vieron los beneficios inmediatos de la aplicación y estaban dispuestos a proporcionar comentarios. Solicitamos a estos propietarios que se ofrecieran como voluntarios antes de hacer cambios obligatorios. Una vez que obtuvimos su ayuda, creamos un equipo formal de administración de cambios para realizar un seguimiento de los cambios en curso. Luego, identificamos a los propietarios responsables de cada equipo de productos para implementar los cambios.
Determina cómo administrar el código de terceros
Si debes administrar el código de terceros, considera cómo presentarás los requisitos de la política a la base de código de terceros. Por ejemplo, primero podrías comenzar por mantener un repositorio de todo el código de terceros utilizado. Te recomendamos que revises con regularidad ese código en función de tus requisitos de seguridad.
Para obtener más información sobre cómo administrar código de terceros, consulta Éxito compartido en la compilación de una comunidad de código abierto más segura.
¿Qué sigue?
- Lee sobre BeyondProd, que usamos para compilar un perímetro seguro alrededor de nuestros microservicios.
- Para adoptar una canalización de CI/CD segura, consulta Niveles de cadena de suministro para artefactos de software (SLSA).