Autorización binaria para Borg: cómo verifica Google la procedencia del código e implementa la identidad de este

Google ha elaborado varios informes en los que se detallan diversos proyectos internos desarrollados por nuestro equipo de seguridad para contribuir a mejorar la seguridad, como BeyondCorp y BeyondProd. Para obtener información general sobre las medidas de seguridad de Google, consulta nuestro informe Descripción general del diseño de seguridad de la infraestructura de Google.

En este informe, describimos el proceso de revisión de código de Google, la procedencia1 de este y la necesidad de implantar mecanismos de cumplimiento. Nos centramos en desarrollar un proceso concreto de verificación de cumplimiento: la autorización binaria para Borg (BAB, por sus siglas en inglés). El objetivo de BAB es mitigar los riesgos internos asegurándose de que el software de producción que se despliega en Google se someta a una revisión y autorización adecuadas, sobre todo si el código correspondiente puede acceder a datos de usuario. Valoramos la protección de los datos de usuario en relación con todos los productos de Google y procuramos ser tan transparentes como sea posible en cuanto a las medidas de seguridad que adoptamos.

El contenido de este informe es válido a fecha de diciembre del 2019. Este documento representa la situación en el momento de su redacción. Las políticas y sistemas de seguridad de Google Cloud podrían cambiar en el futuro, ya que mejoramos constantemente la protección que ofrecemos a nuestros clientes.

Resumen para directores de sistemas de información

  • Los riesgos internos representan una amenaza para la seguridad de los datos de usuario. Nuestra voluntad en Google es minimizar en lo posible las probabilidades de que nuestro personal utilice su conocimiento de la organización o acceda a datos de usuario sin autorización, lo cual incluye ejecutar tareas no autorizadas.
  • La autorización binaria de Borg, o BAB, es un proceso de verificación interna de cumplimiento en el momento del despliegue que minimiza los riesgos internos. Para ello, se asegura de que el software y la configuración de producción que se despliegan en Google sean revisados y autorizados de forma adecuada, sobre todo si el código correspondiente puede acceder a datos de usuario.
  • BAB se asegura de que los despliegues de código y configuración cumplan una serie de estándares mínimos.
  • Además de para tareas de cumplimiento, BAB también se puede usar en modo de auditoría no exigible para emitir advertencias en caso de que no se satisfagan determinados requisitos.
  • La adopción de BAB contribuye a que Google mitigue los riesgos internos, prevenga posibles ataques y respalde la uniformidad de nuestros sistemas de producción.

Minimización de riesgos internos en Google

Puesto que Google prioriza la seguridad, hemos adoptado medidas destinadas a limitar nuestros riesgos internos, es decir, la probabilidad de que nuestro personal (o cualquier otra persona de la empresa) se ayude de los conocimientos de la organización o del acceso que ofrece esta para cometer actos malintencionados. Los riesgos internos también abarcan aquellas situaciones en las que un atacante haya vulnerado las credenciales de alguna persona que trabaje en Google para facilitar la comisión del ataque. Hemos dedicado cuantiosos recursos a la innovación en el ámbito de la protección frente a riesgos internos. En Google, la protección de los datos de usuario es primordial y tratamos de protegerlos de forma exhaustiva. Nuestro objetivo es impedir que cualquier empleado de Google acceda a datos de usuario sin autorización.

Autorización de acceso a datos de usuario

Existen ocasiones en las que los servicios y el personal de Google tienen que acceder a datos de usuario. Las formas que Google tiene de interactuar con los datos de usuario son las siguientes:

  1. Como usuario final: un empleado que utiliza un servicio se autentica en este directamente, y el servicio devuelve sus propios datos. Por ejemplo, todo empleado que inicie sesión en Gmail suele ver sus propios correos.
  2. Como parte de su trabajo: la mayor parte del trabajo que hace el personal de Google se puede completar correctamente mediante datos de usuarios anónimos. Sin embargo, existen algunas raras ocasiones en las que nuestro personal solicita acceso a datos de usuario como parte de su trabajo (por ejemplo, para hacer tareas de asistencia o depuración). Procuramos aportar tanta transparencia como sea posible en cuanto a accesos a datos de usuario. Una de las formas que tenemos de conseguir este objetivo es con la función Transparencia de acceso, la cual permite a los clientes de Google Cloud saber a través de registros en tiempo real si se ha producido un acceso a sus datos.
  3. Como parte de un servicio y de modo programático: para completar una tarea, es posible que un servicio tenga que acceder a datos de usuario de forma programática a gran escala. Por ejemplo, un flujo de procesamiento de datos suele consultar a la vez miles de datos de usuarios para generar estadísticas de uso agregadas. Cuando surge este tipo de necesidad, el acceso se concede para un conjunto de datos, no para los datos de un usuario en particular. El acceso a los datos de cada uno de los usuarios no queda registrado.

En este informe ponemos el foco en el modelo de amenazas que se presenta en la tercera situación. Queremos tener la certeza de que los administradores que dirigen los sistemas que acceden a datos de usuario no pueden abusar de sus facultades.

Modelo de amenazas

Los controles que analizamos en este artículo se diseñaron para proteger los datos de usuario mediante la prevención de accesos unilaterales. Nuestra intención es impedir que, sin una autorización o justificación adecuadas, el personal de Google acceda por sí mismo a datos de usuario o los modifique, ya sea directa o indirectamente. Nuestros controles previenen este tipo de acciones, sin importar si la persona en cuestión tiene mala fe, si se ha vulnerado la seguridad de su cuenta o si se le ha concedido autorización de manera accidental.

Infraestructura en contenedores de Google

Nuestra infraestructura está creada en contenedores y utiliza un sistema de gestión de clústeres denominado 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.

Además, gracias al uso de contenedores, hemos logrado notables ventajas en materia de seguridad. Los contenedores están pensados para un uso inmutable y suelen volver a desplegarse a partir de una recompilación íntegra de imágenes. Esta propiedad nos permite revisar contextualmente los cambios en el código y facilita un único punto crítico para todos los cambios que se despliegan en nuestra infraestructura.

Para entender cómo hemos desarrollado una solución que restringe el acceso programático de un servicio a los datos de usuario, conviene entender antes cómo pasan los servicios de Google a la fase de producción.

Paso 1: Revisión de código

Nuestro código fuente se almacena en un repositorio monolítico central que posibilita que miles de empleados verifiquen código en una sola ubicación. El uso de un único código base simplifica la gestión del código fuente, sobre todo nuestras dependencias de código de terceros. El carácter monolítico del código base también hace posible la implantación obligatoria de un único punto crítico destinado a revisar código. El proceso de revisión de código que seguimos en Google incluye la inspección y la aprobación de al menos un ingeniero que no sea el autor e impone la obligación de que, como mínimo, toda modificación que se hace al código de cualquier sistema debe contar con la aprobación de los propietarios de dicho sistema. Tras la verificación del código, se procede a su compilación.

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 programadores externos introducen en esos tipos de código que utilizamos no suelen pasar los mismos controles de revisión.

Paso 2: Compilaciones verificables

El sistema de compilación que empleamos es muy similar a Bazel, el cual crea y compila código fuente generando un 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. El sistema genera un archivo de manifiesto verificable con cada compilación, es decir, un certificado firmado que describe íntegramente las fuentes que lleva aparejadas la compilación correspondiente, los hashes criptográficos de cualquier binario u otro artefacto de dicha compilación, y la totalidad de parámetros de esta. Este archivo nos permite rastrear cualquier binario hasta el código fuente que se empleó en la generación del binario correspondiente y, por extensión, también rastrearemos el proceso asociado a la creación y envío del código fuente que describe a dicho binario. Además, el archivo de manifiesto posibilita que verifiquemos si el binario se ha modificado, ya que cualquier cambio invalidaría automáticamente su firma.

Puesto que las acciones de compilación pueden contener teóricamente código arbitrario, nuestro sistema de compilación se ha fortalecido para tener en cuenta a varios propietarios. Es decir, el diseño de nuestro sistema de compilación está orientado a impedir que una compilación influya en cualquiera de las otras. El sistema impide que las compilaciones realicen cambios que pudieran vulnerar la integridad de los archivos verificables de manifiesto de las compilaciones o la del propio sistema. Terminada la compilación, el cambio se despliega mediante Borg.

Paso 3: Tareas de despliegue

Una vez que se ha compilado, el binario se puede desplegar en nuestra infraestructura en contenedores en forma de tarea de Borg. Estas tareas utilizan paquetes que posiblemente contengan binarios o datos de cuya instalación se encarga Borg. La configuración de Borg especifica los requisitos que precisa la tarea que debe desplegarse: los paquetes, 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 de tareas

Las tareas de Borg se ejecutan en forma de identidades, que sirven para acceder a almacenes de datos o a métodos de llamada a procedimiento remoto (RPC, por sus siglas en inglés), pertenecientes a otros servicios. Las identidades adoptan las formas de cuentas de rol (como un servicio) o de cuentas de usuario (como la cuenta particular de un empleado). Es posible que varias tareas se ejecuten bajo la misma identidad. Limitamos la capacidad de desplegar o modificar tareas con una identidad determinada a las personas responsables de ejecutar el servicio, que por regla general son nuestros ingenieros de Site Reliability Engineering (SRE, por sus siglas en inglés).

Cada vez que Borg inicia una tarea, la aprovisiona mediante credenciales criptográficas. La tarea utiliza dichas 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. Analicemos el ejemplo de un servicio como la API DLP (Data Loss Prevention) de Google Cloud. Para poder acceder a datos con fines de escaneado, la API DLP necesita dos cosas. La primera, ser configurada de modo que se ejecute con una identidad diferenciada, en este caso, una cuenta de rol. La segunda, la inclusión de dicha cuenta en los permisos de los datos que la API DLP va a escanear. Si el servicio carece de una identidad válida y los permisos adecuados, no puede hacer el escaneado.

Nuestras políticas exigen que BAB y otros sistemas de seguridad controlen rigurosamente cualquier cuenta de rol que tenga acceso a datos de usuario (o a cualquier otra información sensible). Las tareas de control de calidad y desarrollo que no tienen acceso a datos o recursos sensibles tienen autorización para ejecutarse bajo menos controles.

Visión de conjunto: ciclo de vida de las tareas

En resumen, los pasos para ejecutar una tarea en nuestra infraestructura son los siguientes:

  1. Un programador de Google crea un cambio en el código. A continuación, lo envía a uno o varios ingenieros de Google para su revisión. La revisión incluye verificaciones destinadas a comprobar que la autorización y el almacenamiento de registros sean los adecuados. Una vez que se aprueba, se verifica el código.
  2. El sistema de compilación compila y empaqueta los binarios de manera verificable en una zona de pruebas, acciones que inicia el programador. Este proceso compilador genera un paquete que posteriormente firma el sistema de compilación con fines de verificación.
  3. El despliegue de la tarea en Borg corre a cargo de un ingeniero que cuenta con una autorización específica para gestionar tareas que se ejecuten bajo la identidad segura conveniente.
  4. Cada vez que una tarea de Borg trate de acceder a recursos sujetos a privilegios, como datos de usuario, se verifica la identidad de dicha tarea para su autorización.

Ya has aprendido cómo se ejecutan las tareas en nuestro entorno de producción. Ahora vamos a pasar a estudiar el modelo de amenazas que aborda BAB: evitar que cualquier persona que pertenezca a la propia organización, y que posiblemente actúe de mala fe, ejecute tareas no autorizadas. Con este fin, BAB verifica que se hayan efectuado todas las comprobaciones de seguridad necesarias antes de desplegar cualquier binario.

En esta sección, hemos descrito a grandes rasgos nuestra infraestructura en contenedores. Es necesario que tengas algunos conocimientos elementales de nuestro entorno de producción para comprender el funcionamiento de los controles que regulan el acceso programático a datos por parte de los usuarios. Dichos controles se describen en mayor profundidad en la próxima sección.

Autorización binaria para Borg (BAB)

Llevamos varios años poniendo en práctica medidas relevantes para prevenir el acceso manual a los datos de usuario. Tales medidas incluyen limitar el acceso a los datos y a la gestión de tareas a los equipos de personal de Google que lo necesiten para hacer su trabajo.

La misión que tiene BAB es garantizar que la totalidad del software y la configuración de producción que se despliega en Google sea sometida a una revisión y autorización adecuadas, sobre todo si el código en cuestión puede acceder a datos de usuario. Para lograrlo, BAB presta un servicio de cumplimiento en el momento del despliegue destinado a evitar que se inicien tareas no autorizadas y proporciona un registro de auditoría del código y la configuración utilizados en tareas habilitadas para BAB.

Verificación

BAB verifica que, cuando se despliegan, los binarios satisfagan determinados requisitos. Por ejemplo, el propietario de un servicio podría exigir que el binario de dicho servicio se compile a partir de código que haya pasado por fases de revisión, verificación, pruebas y autorización. A este tipo de comprobaciones las denominamos comprobaciones en el momento del despliegue. BAB también tiene capacidad para hacer comprobaciones después de que los binarios se hayan desplegado, acciones que conocemos como comprobaciones posdespliegue. Para obtener más información sobre estas verificaciones posdespliegue, consulta la sección Modos de cumplimiento.

Todo cambio en el código genera un nuevo binario. Para que surtan efecto los cambios que recoge el nuevo binario, debe desplegarse. BAB permite hacer multitud de tipos de comprobaciones en el momento del despliegue, entre los que se incluyen los siguientes:

  • ¿Se ha compilado el binario a partir de código verificado?

    ¿Se ha enviado el código al repositorio de código fuente de Google? ¿Se ha verificado el código en dicho repositorio? Para que el código se pueda enviar, por lo general es obligatorio que un segundo ingeniero de Google lo revise.

  • ¿Se ha compilado el binario de manera verificable?

    ¿Es posible rastrear el binario hasta fuentes auditables? ¿Se ha compilado con un sistema de compilación aprobado?

  • ¿Se ha compilado el binario a partir de código probado?

    ¿Cumple el binario los requisitos de las pruebas?

  • ¿Se ha compilado el binario a partir de código destinado al despliegue?

    ¿Se ha enviado el código al área adecuada de nuestro repositorio de código fuente que se corresponde con el proyecto o equipo pertinente para esa tarea de Borg en concreto?

Aunque estas comprobaciones son características de nuestro entorno de producción, es posible aplicar requisitos similares en tus entornos CI/CD (integración continua/despliegue continuo) en función de los requisitos que tengas en cuanto a seguridad, cumplimiento normativo o fiabilidad.

Política específica del servicio

Las tareas que acceden a datos sensibles requieren, por lo general, el envío del código, aunque se dan algunas excepciones por motivos comerciales legítimos. Entre los datos sensibles se incluyen datos de usuario, datos laborales y financieros, y cualquier otro dato confidencial o empresarial cuyo conocimiento sea necesario. En Google es obligatorio que todas las tareas cuenten con una política; hasta las tareas de Borg que no precisan acceder a datos de usuario suelen llevar aparejada una política definida, aunque en esta no se enumeren requisitos concretos.

Cuando se incorporan a BAB, los propietarios de servicios definen una política que incluye los requisitos de seguridad adecuados para el servicio correspondiente. Todas las cuentas de rol utilizadas para implementar su servicio deben especificar una política sobre BAB. Dicha política define, por cada cuenta de rol, las tareas de lanzamiento previstas y los requisitos de código y configuración de dichas tareas. La definición o la modificación de cualquier política comporta en sí un cambio en el código que es obligatorio revisar.

Entre los requisitos que se pueden implementar en cualquier política sobre BAB se incluyen los siguientes:

  • Compilación verificable del código: todo código que sea compilado de manera verificable es susceptible de auditarse, aunque eso no significa necesariamente que el código se haya sometido a revisión; de hecho, hay casos en los que se anula el envío del código. El código que se utiliza en compilaciones verificables es susceptible de auditoría durante, como mínimo, 18 meses, incluso en el caso de que no se envíe.

  • Envío del código: el código se compila a partir de una ubicación especificada y prevista de nuestro repositorio de código fuente. Este requisito 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 sistemas y los componentes que aplican BAB deben controlarse de manera rigurosa. Para ello se implementan los requisitos más estrictos posibles y se implantan controles manuales complementarios.

Modos de cumplimiento

BAB realiza acciones diferentes en función de la política que se especifique en la tarea de Borg. Estas acciones se denominan "modos de cumplimiento" y se agrupan en tres tipos: cumplimiento en el momento del despliegue, auditoría en el momento del despliegue y verificación continua. A la hora de definir cualquier política, el propietario del servicio debe escoger entre el cumplimiento o la auditoría en el momento del despliegue. El modo de verificación continua está habilitado de manera predeterminada. En las secciones siguientes, se facilita más información sobre cada uno de estos modos.

Modo de cumplimiento en el momento del despliegue

Cuando se envía una tarea nueva, el borgmaster2 consulta a BAB para comprobar si dicha tarea cumple los requisitos expuestos en la política sobre BAB. Esta comprobación hace las veces de controlador de admisión: si se cumplen los requisitos, el borgmaster inicia la tarea; en caso contrario, el borgmaster deniega la solicitud aunque el usuario solicitante cuente con autorización.

En este modo, BAB suele bloquear el despliegue de la tarea de Borg si esta no cumple los requisitos establecidos en su política sobre BAB. Los servicios recién llegados a BAB suelen empezar en modo de auditoría (que se describe en la próxima sección), para más adelante pasarse al modo de cumplimiento.

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 verificado. 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 pueda acabar bloqueando despliegues de cualquier otra manera. Los programadores que desplieguen una tarea por medio del procedimiento de respuesta ante emergencias deben aportar una justificación como parte de su solicitud.

Transcurridos varios segundos desde la utilización del procedimiento de respuesta ante emergencias, BAB registra datos sobre la tarea de Borg relacionada. El registro incluye el código utilizado y la justificación facilitada por el usuario. Varios segundos más tarde, se envía un registro de auditoría a nuestro equipo de seguridad centralizado. En cuestión de varias horas, el equipo propietario de la cuenta de rol recibe dicho registro. Los procedimientos de respuesta ante emergencias solo están concebidos como último recurso.

Modo de auditoría en el momento del despliegue

En el modo de auditoría, BAB registra si una tarea de Borg no cumple los requisitos de la política, pero no bloquea su despliegue. El incumplimiento de esta política activa una alerta, que recibe el equipo propietario de la cuenta de rol.

En Google exigimos que determinados servicios, como los que acceden a datos de usuario, utilicen el modo de cumplimiento. Recomendamos encarecidamente a todos los propietarios de servicios que utilicen el modo de cumplimiento y que solo utilicen el modo de auditoría al incorporarse a otro servicio. Para utilizar el modo de auditoría, los propietarios de servicios deben aportar una justificación para lograr una excepción. Por ejemplo, cualquier servicio cuyo objetivo de nivel de servicio sea notablemente superior a las prestaciones que ofrece BAB usaría el modo de auditoría.

Aunque el modo de auditoría es útil al ajustar cualquier política inicial, no aporta estabilidad práctica a la mayoría de los servicios. Si se utiliza el modo de auditoría, el propietario del servicio no recibe notificaciones de cualquier infracción de la política pertinente hasta varias horas después de su que ocurra. Esto puede desembocar en un molesto flujo de notificaciones y provocar que errores o configuraciones inadecuadas de la política introducidos por el propietario acaben ocultando verdaderos problemas de seguridad. El modo de cumplimiento permite que el propietario del servicio reciba comentarios inmediatos cada vez que trata de iniciar una tarea que incumpla la política. De este modo, su flujo de notificaciones es mucho más reducido. Además, el modo de cumplimiento con BAB capta errores involuntarios, como la ejecución accidental de tareas en un rol que no sea el rol designado.

Verificación continua

Cuando una tarea se despliega, sin importar si se comprueba el cumplimiento en el momento del despliegue, se verifica de forma continuada durante su vida útil. Los procesos de BAB se ejecutan como mínimo una vez al día para comprobar que toda tarea iniciada (y que pudiera estar aún en ejecución) cumpla cualquier actualización de su política. Por ejemplo, el modo de verificación continua comprueba de forma constante si existen tareas que se ejecutan con políticas obsoletas o con una identidad que se haya desplegado a través de procedimientos de respuesta ante emergencias. Si se detecta una tarea que incumple la versión actualizada de la política, BAB lo notifica a los propietarios de servicios de modo que puedan mitigar el riesgo.

Paquetes admitidos globalmente

En Google, existen paquetes que son usados por muchos de nuestros servicios. En lugar de forzar a todos los servicios a mantener su propia versión, estos paquetes se admiten de forma centralizada; los denominamos paquetes gestionados globalmente. Al elaborar su política sobre BAB, el propietario de un servicio puede asignar un paquete admitido globalmente a una tarea determinada. También existe un mecanismo global predeterminado pensado para paquetes de uso extensivo, de modo que dichos paquetes no tengan que integrarse de forma individual en la política de cada uno de los servicios. De esta forma, Google mantiene un control explícito sobre componentes comunes del sistema en toda la organización y se garantiza que estos se revisan y actualizan oportunamente sin involucrar a equipos particulares. Aunque un propietario concreto de un servicio podría admitir estos paquetes de manera explícita en la política sobre BAB de su servicio, esto facilita que los propietarios sigan la estrategia recomendada y admitida.

Casos límite

Google implementa sólidos controles de seguridad concebidos para código desplegado en la fase de producción, incluidas revisiones de código y compilaciones verificables. BAB actúa como punto complementario de control y cumplimiento para garantizar que dichos controles de seguridad se implementen adecuadamente.

Sin embargo, no es posible utilizar BAB con eficacia en todos los casos. BAB no admite los siguientes casos límite: código compilado mediante sistemas de compilación no estándar; código desplegado en entornos diferentes a Borg; y código de análisis de datos y de aprendizaje automático que no se preste con facilidad a revisiones por humanos antes de que los parámetros de producción definitivos sean escogidos. En estos casos, se han implantado varias medidas de mitigación de seguridad, incluidos otros sistemas de procedencia de código. Aun así, este código sigue sujeto a los controles de seguridad general de Google.

Implementación de autorización binaria para Borg

Para implementar BAB, el equipo de BAB desarrolló varias funciones nuevas, incluidos distintos procedimientos de respuesta ante emergencias y un modo de auditoría. Estas herramientas facilitaron tanto como era posible que los mismos propietarios de servicios probaran BAB. Si estás pensando en desplegar una tecnología parecida a BAB en tu organización, quizás tengas que hacer algunos preparativos para facilitar esta transición. En esta sección se describen las labores de gestión organizativa y del cambio que llevamos a cabo como parte de nuestro plan de implementación.

Ventajas

BAB presenta tres ventajas que favorecieron el estudio económico de su desarrollo y adopción en Google: reducción de riesgos internos, robustecimiento de la identidad del código y simplificación del cumplimiento normativo.

Reducción de riesgos internos

BAB se desarrolló fundamentalmente para impedir que cualquier individuo obtuviera acceso programático no autorizado a datos de usuario. BAB dificulta que cualquier ingeniero, o cualquier atacante que consiga las credenciales de un ingeniero, acceda a datos sensibles de forma inadecuada y sin que sea detectado.

Fortalecimiento de la identidad del código

Tal y como se ha descrito en la sección sobre la infraestructura en contenedores de Google, las tareas de Borg se ejecutan en forma de identidad, generalmente una cuenta de rol. Otros servicios utilizan dicha identidad para verificar que la autorización sea adecuada antes de conceder acceso a cualquier dato. Sin embargo, otros servicios no pueden implementar el uso de esos datos. Por lo tanto, deben confiar en que la identidad de la tarea no abuse de los datos que recibió. BAB vincula la identidad de una tarea a un código específico y se asegura así de que solo el código especificado pueda utilizarse para ejercer los privilegios aparejados a dicha identidad. Se posibilita así la transición desde una identidad de tarea, en la que la confianza transitiva se deposita en una identidad y en cualquiera de sus usuarios humanos que tengan privilegios, a una identidad de código, donde la confianza se deposita en una sección concreta de código que fue revisada de tal forma que adquiriese un significado determinado y que no se puede modificar sin haber completado procesos de aprobación.

Simplificación del cumplimiento normativo

BAB vino a simplificar lo que anteriormente eran tareas manuales de cumplimiento normativo. Algunos procesos de Google exigen un control más riguroso de la forma en que gestionan 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. Tras la introducción de BAB, muchas de estas comprobaciones se automatizaron a partir de las políticas sobre 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.

Integración en un servicio

El equipo de BAB tuvo que asegurarse de que el proceso de integración fuera sencillo y claro. Al principio, la adopción de BAB les generaba dos inquietudes a los propietarios de servicios que trabajaban en Google:

  • Si BAB carecía de la suficiente fiabilidad, su implementación podría bloquear cambios en situaciones críticas.
  • BAB podría ralentizar el desarrollo de cualquier servicio debido al frecuente volumen de verificaciones de código y a los procesos iterativos.

Para dar respuesta a estas inquietudes iniciales, el equipo de BAB desarrolló el modo de auditoría. Este modo permitió al equipo demostrar a algunos de los usuarios pioneros más importantes que BAB funcionaba. Para reforzar más su fiabilidad, el equipo de BAB desarrolló un objetivo de nivel de servicio respecto de la disponibilidad e introdujo procedimientos de respuesta ante emergencias diseñados para el modo de cumplimiento.

Al integrar un servicio que ya existía en BAB, el propietario suele habilitar el modo solo de auditoría en primer lugar. Esto le ayuda a identificar y abordar cualquier posible problema antes de activar el modo de cumplimiento. La política predeterminada para cualquier tarea que utilice BAB en la fase de producción establece el uso del modo de cumplimiento. Para desplegar su tarea, el propietario del servicio debe enviar una política que, como mínimo, exija el envío y la compilación verificables del código. Existe la posibilidad de que el propietario del servicio despliegue la tarea sin cumplir estos estándares mínimos, pero para ello necesita obligatoriamente una excepción. Si el servicio precisa acceder a datos o servicios más sensibles, el propietario puede adoptar requisitos más estrictos. Ya que definir una política inicial puede ser una tarea difícil, el equipo de BAB ideó un conjunto de herramientas automatizadas destinadas a ayudar a los propietarios de servicios a escribir sus políticas. Las herramientas analizan qué secciones del repositorio de código fuente sirven para una tarea dada y sugieren una política conveniente.

Al incorporar un servicio nuevo a BAB, su propietario habilita el modo de cumplimiento desde el principio. Además, el propietario del servicio redacta una política inicial y hace iteraciones con rapidez de modo que vayan agregándose otros requisitos. Las propias políticas se gestionan a medida que hay cambios en el código y, por lo tanto, es necesario que un segundo ingeniero de Google revise las actualizaciones.

Impacto

La adopción de BAB y de un modelo de despliegue en contenedores aporta múltiples ventajas a Google en términos de seguridad y asistencia.

  • BAB contribuye a mitigar los riesgos internos generales. Al exigir que el código cumpla unos estándares y unas prácticas de gestión del cambio concretos antes de acceder a datos de usuario, BAB reduce las probabilidades de que cualquier Googler, que actúe individualmente o que haya sufrido la vulneración de la seguridad en su cuenta, 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 la 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 nuestros sistemas. Los datos relativos a dicha conformidad se publican internamente y son susceptibles de consulta por otros equipos. Al publicar los datos de BAB de esta manera, los equipos pueden usar los mismos términos en sus comunicaciones acerca de la protección de 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. Hay procesos, como los relativos a los informes financieros, que tienen que cumplir determinados requisitos de gestión del cambio con fines de cumplimiento normativo. Gracias a BAB, estas comprobaciones se pueden automatizar, con el consiguiente ahorro de tiempo e incremento del alcance de la cobertura.

BAB es una de las numerosas tecnologías que Google utiliza para mitigar los riesgos internos.

Adopción de controles similares en tu organización

La implementación de BAB en Google nos enseñó muchas lecciones importantes. La operación de un cambio de tal calibre puede parecer una labor abrumadora. En esta sección, compartimos las lecciones que aprendimos en el proceso con la esperanza de que puedas aplicar los principios de BAB en tu organización.

Céntrate en lograr un flujo de procesamiento de CI/CD en contenedores más homogéneo

La adopción de BAB por parte de Google fue una realidad gracias a la coherencia y la integración de las herramientas que empleamos en la programación de nuestro código. Esta labor incluía revisiones de código, compilaciones verificables, despliegues en contenedores e identidad basada en servicios para el control de accesos. Las compilaciones verificables te permiten comprobar cómo se compilan los binarios que manejas; los contenedores sirven para distinguir binarios de entre los datos y procurarte un punto crítico de implantación que te permita garantizar que dichos binarios cumplen los requisitos de uso. Este enfoque simplificó la adopción de BAB y reforzó las garantías que aportaba una solución como BAB.

La introducción de microservicios posibilitó la adopción de una identidad basada en servicios (como una cuenta de servicio) en vez de una identidad basada en hosts (como una dirección IP). El cambio hacia una identidad basada en servicios te permitirá cambiar la forma en la que gestionas la autenticación y la autorización entre servicios. Por ejemplo, si utilizas un token de identidad integrado en la imagen de un contenedor para certificar la identidad, las garantías que proporciona la procedencia del código no tienen la misma solidez. Si te resulta imposible adoptar una identidad de servicio directamente, podrías esforzarte más por proteger tokens de identidad 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 esta razón, la implementación de las políticas sobre BAB se ejecuta no al compilarse el código, sino al desplegarse o al acceder este a datos. Toda política sobre BAB viene definida 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. Al usar BAB de este modo, los propietarios de servicios pueden reforzar las garantías de que a los datos solo acceden tareas que cumplan determinados requisitos de BAB, con lo que en realidad se trata al código como si fuera una identidad.

Decide cómo incorporar a propietarios de servicios

Identifica a un grupo de propietarios de servicios que probablemente aprecien las ventajas directas de la implementación y que estén dispuestos a aportar comentarios. Un modo de identificarlos podría ser preguntarles si se ofrecerían como voluntarios antes de hacer obligatorio cualquier cambio.

A ser posible, favorece el modo de cumplimiento en detrimento del modo de auditoría; o bien transmite contundencia limitando el periodo de gracia del modo de auditoría. El modo de auditoría permite a los propietarios incorporarse con rapidez y comprender mejor los riesgos internos. Su inconveniente consiste en que la reducción de riesgos internos posiblemente tarde en verse. Debido a estos retrasos, el valor no se percibe de forma directa y resulta difícil convencer a terceros de la idoneidad de adoptar el modo de cumplimiento. Cuando los procedimientos de respuesta ante emergencias destinados a este modo se publicaron, los propietarios estaban más dispuestos a adoptarlo, ya que les ofrecía una salida de emergencia en caso necesario.

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. 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 de implementar los cambios.

Determina cómo se gestiona el código de terceros

Muchos de los controles de CI/CD que describimos en este artículo se implantan en los casos en que una sola organización se encargue de programar, revisar y mantener tu código. Si esta es tu situación, piensa cómo vas a incluir código de terceros en los requisitos de tu política. Por ejemplo, podrías empezar por excluir el código mientras vas concibiendo una forma ideal de mantener un repositorio de todo el código de terceros que se ha utilizado y, luego, cotejar regularmente ese código con tus requisitos de seguridad.

Conclusión

La puesta en práctica de una comprobación de cumplimiento en el momento del despliegue como parte de la infraestructura en contenedores y del proceso de CI/CD de Google nos ha permitido asegurarnos de que el código y la configuración que desplegamos cumplan determinados estándares mínimos de seguridad. Se trata de un control crítico que sirve para limitar la capacidad de cualquier persona que pertenezca a la propia organización, y que posiblemente actúe de mala fe, de ejecutar tareas no autorizadas que podrían acceder a datos de usuario. La adopción de BAB ha posibilitado que Google reduzca los riesgos internos, prevenga posibles ataques y respalde la uniformidad de nuestros sistemas de producción.

Otras referencias

Para obtener más información sobre la infraestructura global de seguridad y en contenedores de Google, consulta los siguientes recursos:

Notas

1 La procedencia describe los componentes, los cambios introducidos en estos y su punto de origen. Consulta la definición en https://csrc.nist.gov/glossary/term/Provenance.

5 El borgmaster es el controlador centralizado perteneciente a Borg. Se encarga de gestionar la programación de tareas y de comunicarse con las que estén en ejecución acerca de su estado.