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

Google escribió varios informes que explican los proyectos que nuestro equipo de seguridad desarrolló de forma interna a fin de ayudar a mejorar la seguridad, como BeyondCorp y BeyondProd. Consulta nuestro informe sobre el diseño de la infraestructura de seguridad para obtener una descripción general de la seguridad de Google.

En este informe, describimos el proceso de revisión de código de Google, su procedencia1 y la necesidad de implementar mecanismos de aplicación. Nos enfocamos en el desarrollo de una verificación de aplicación específica: la autorización binaria para Borg (BAB). Para reducir el riesgo de filtración de datos, BAB garantiza que el software de producción implementado en Google se revise y autorice de forma adecuada, en especial si ese código puede acceder a los datos del usuario. Valoramos la protección de los datos del usuario en todos los productos de Google y nos esforzamos por ser lo más transparentes posible con respecto a las medidas de seguridad que tomamos.

El contenido de este informe corresponde a diciembre de 2019. Este documento representa el statu quo a partir del momento en que se escribió. Es posible que las políticas y los sistemas de seguridad de Google Cloud cambien, ya que mejoramos la protección de nuestros clientes de forma continua.

Resumen para directores generales de información

  • El riesgo de filtración de datos representa una amenaza para la seguridad de los datos del usuario. En Google, hacemos todo lo que está a nuestro alcance para minimizar la posibilidad de que el personal de Google use su conocimiento organizativo o acceso a los datos del usuario de forma no autorizada. Esto incluye ejecutar un trabajo no autorizado.
  • La autorización binaria para Borg, o BAB, es una verificación interna de aplicación en el momento de la implementación que, a fin de minimizar el riesgo de filtración de datos, se asegura de que se revisen y autoricen el software de producción y la configuración implementada en Google de forma adecuada, en especial si ese código puede acceder a los datos del usuario.
  • BAB garantiza que las implementaciones de código y configuración cumplan con determinados estándares mínimos.
  • Además de la aplicación, BAB también se puede usar en un modo de auditoría no aplicable para advertir cuando no se cumplen determinados requisitos.
  • La adopción de BAB ayuda a Google a reducir el riesgo de filtración de datos, evitar posibles ataques y respaldar la uniformidad de los sistemas de producción de Google.

Minimiza el riesgo de filtración de datos en Google

Como somos una empresa que prioriza la seguridad, implementamos medidas para limitar el riesgo relacionado con usuarios con información privilegiada, es decir, la posibilidad de que el personal de Google (o cualquier otra persona de la organización) use su conocimiento organizativo o acceso para realizar acciones maliciosas. El riesgo relacionado con usuarios con información privilegiada también abarca la situación en la que un atacante compromete las credenciales de un empleado de Google para facilitar su ataque. Dedicamos recursos importantes a la innovación en el área de protección contra riesgos de filtración de datos. En Google, es fundamental proteger los datos del usuario, y nos esforzamos mucho por hacerlo de manera integral. Nuestro objetivo es evitar que un empleado de Google acceda a los datos del usuario sin autorización.

Autorización para acceder a los datos del usuario

En Google, hay momentos en que nuestros servicios y empleados tienen que acceder a los datos del usuario. A continuación, se explica cómo interactuamos con los datos del usuario:

  1. Como un usuario final: un empleado que usa un servicio se autentica en el servicio de forma directa, y este muestra sus propios datos. Por ejemplo, un empleado que accede a su Cuenta de Gmail verá sus propios correos electrónicos.
  2. Como parte de su función: la mayoría del trabajo que realiza el personal de Google se puede completar de forma correcta con los datos anónimos del usuario. Sin embargo, en algunas ocasiones, nuestro personal requiere acceso a los datos del usuario como parte de su trabajo (por ejemplo, asistencia o depuración). Nuestro objetivo es brindar la mayor transparencia posible acerca de los accesos a los datos del usuario. Una de las formas de lograr esto es mediante la Transparencia de acceso, una función que permite a los clientes de Google Cloud ver los accesos apropiados de sus datos a través de registros en tiempo real.
  3. Como parte de un servicio, de manera programática: para realizar una tarea, es posible que un servicio necesite acceder a los datos del usuario de manera programática a gran escala. Por ejemplo, una canalización de datos consultará miles de datos de usuarios a la vez a fin de generar estadísticas de uso agregadas. Cuando surge este tipo de necesidad, se otorga acceso a un conjunto de datos en lugar de los datos de un usuario individual. No se registra el acceso a los datos de cada usuario individual.

Este informe se enfoca en el modelo de amenaza que se presenta en la tercera situación. Queremos tener la certeza de que los administradores que ejecutan los sistemas que acceden a los datos del usuario no pueden abusar de sus facultades.

Modelo de amenaza

Los controles que abordamos en este documento se crearon para proteger los datos del usuario, ya que impiden el acceso unilateral. Queremos impedir que el personal de Google actúe solo, acceda de forma directa o indirecta a los datos del usuario o modifique los datos sin la debida autorización y justificación. Nuestros controles impiden que se realicen estas acciones, independientemente de si la persona tiene una intención maliciosa, si su cuenta se vio comprometida o si se le otorgó autorización de manera involuntaria.

Infraestructura en contenedores de Google

Nuestra infraestructura se basa en contenedores y utiliza un sistema de administración de clústeres llamado 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.

Además, obtuvimos notables beneficios de seguridad mediante el uso de contenedores. Los contenedores están diseñados con el objetivo de que se los utilice de manera inmutable, con frecuentes implementaciones nuevas a partir de una compilación completa de la imagen. Esta propiedad nos permite revisar un cambio de código en contexto y proporciona un punto de bloqueo único para todos los cambios que se implementan en nuestra infraestructura.

Para comprender de qué manera desarrollamos una solución que restringe el acceso programático a los datos del usuario por parte de un servicio, es importante comprender primero cómo funciona un servicio en Google.

Paso 1: Revisión del código

Nuestro código fuente se almacena en un repositorio central monolítico que permite a miles de empleados verificar el código en una sola ubicación. Usar una base de código única simplifica la administración del código fuente, en particular nuestras dependencias con códigos de terceros. Una base de código monolítica también permite la aplicación de un punto de bloqueo único para las revisiones de códigos. En Google, nuestras revisiones de códigos incluyen la inspección y la aprobación de al menos un ingeniero distinto del autor. Nuestro proceso de revisión de códigos aplica una regla que establece, como mínimo, que los propietarios de un sistema deben aprobar las modificaciones del código en ese sistema. El código se compilará una vez que se registre.

Cuando importamos cambios de código 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 utilizamos.

Paso 2: Compilaciones verificables

Utilizamos un sistema de compilación muy similar a Bazel, que desarrolla y compila el código fuente, y crea un objeto binario para la implementación. Nuestro sistema de compilación se ejecuta en un entorno aislado y bloqueado, independiente al entorno donde los empleados realizan las compilaciones. En cada compilación, el sistema produce un manifiesto de compilación verificable, un certificado firmado que describe en detalle las fuentes que ingresaron a la compilación, los hash criptográficos de los objetos binarios o los elementos de compilación, y los parámetros de compilación completos. Este manifiesto nos permite realizar un seguimiento de un objeto binario en el código fuente que se usa durante su creación y, por extensión, en el proceso de creación y envío del código fuente que describe. Además, el manifiesto nos permite verificar que no se modificó el objeto binario, ya que cualquier cambio en el archivo invalidaría su firma de forma automática.

Dado que las acciones de compilación pueden ser, en teoría, un código arbitrario, nuestro sistema de compilación se reforzó para múltiples instancias. 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 los manifiestos de compilación verificables o del propio sistema. Una vez que se completa la compilación, el cambio se implementa con Borg.

Paso 3: Trabajos de implementación

Una vez compilado, el objeto binario se puede implementar en nuestra infraestructura en contenedores como un trabajo de Borg. Estos trabajos usan paquetes que pueden contener objetos binarios o datos, cuya instalación la administra Borg. Una configuración de Borg especifica los requisitos para el trabajo que se implementará: paquetes, parámetros de entorno de ejecución, argumentos y marcas. Borg programa el trabajo en función de sus restricciones, prioridad, cuota y otros requisitos que se incluyan en la configuración. Una vez implementado, el trabajo de Borg puede interactuar con otros trabajos en producción.

Paso 4: Identidad del trabajo

Un trabajo de Borg se ejecuta como una identidad, que es la que se usa para acceder a los almacenes de datos o métodos de llamada de procedimiento remoto (RPC) de otros servicios. Una identidad puede ser una cuenta de función (como un servicio) o una cuenta de usuario (como la cuenta individual de un empleado). Es posible que varios trabajos se ejecuten como la misma identidad. Restringimos la capacidad de implementar o modificar trabajos con una identidad específica a los responsables de ejecutar el servicio, que, por lo general, son nuestros ingenieros de confiabilidad de sitios (SRE).

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). Para que un servicio acceda a determinados datos o a otro servicio, su identidad debe contar con los permisos necesarios. Considera el ejemplo de un servicio, como la API de Cloud Data Loss Prevention (Cloud DLP) de Google Cloud. A fin de que la API de DLP acceda a los datos para su análisis, necesita dos condiciones. En primer lugar, la API de DLP debe estar configurada para que se ejecute con una identidad distinta, en este caso, una cuenta de función. En segundo lugar, los permisos de los datos que analiza la API de DLP deben incluir esa cuenta de función. Sin una identidad válida y los permisos correctos, el servicio no podría realizar el análisis.

Nuestras políticas requieren que BAB y otros sistemas de seguridad controlen de forma estricta una cuenta de función con acceso a los datos del usuario (o alguna otra información sensible). Los trabajos de control de calidad y desarrollo que no tienen acceso a los recursos o datos sensibles se pueden ejecutar con menos controles.

Revisión general: Ciclo de un trabajo

En resumen, para ejecutar un trabajo en nuestra infraestructura, se deben seguir estos pasos:

  1. Un desarrollador de Google autoriza que se realice un cambio en el código. Luego, se envía a uno o más ingenieros de Google para su revisión. La revisión incluye verificaciones para la autorización y el registro adecuados. El código se registra una vez que se aprueba.
  2. El sistema de compilación que activa el desarrollador crea y empaqueta de forma verificable los objetos binarios en un entorno de zona de pruebas. Esta operación de compilación genera un paquete que el sistema de compilación firma para fines de verificación.
  3. Un ingeniero específicamente autorizado para administrar trabajos que se ejecutan con la identidad segura adecuada implementa el trabajo en Borg.
  4. Cuando un trabajo de Borg intenta acceder a recursos con privilegios, como los datos del usuario, se verifica la identidad del trabajo para su autorización.

Ahora que sabes cómo se ejecutan los trabajos en nuestro entorno de producción, analicemos el modelo de amenaza que BAB aborda para impedir que un posible usuario malintencionado con información privilegiada ejecute un trabajo no autorizado. Para lograrlo, BAB verifica que se realicen todos los controles de seguridad necesarios antes de que se implemente un objeto binario.

En esta sección, se proporciona una descripción general de nuestra infraestructura en contenedores. El alcance básico de nuestro entorno de producción es un requisito necesario a fin de que comprendas los controles que implementamos en el acceso de usuario programático a los datos. Estos controles se describen con más detalle en la siguiente sección.

Autorización binaria para Borg (BAB)

Durante varios años, realizamos importantes esfuerzos para proteger el acceso a los datos del usuario de forma manual. Estos esfuerzos implican restringir el acceso a la administración de los datos y trabajos al personal de Google que lo necesitaba para realizar su trabajo.

La misión de BAB es garantizar que se revisen y autoricen todo el software de producción y la configuración implementada en Google de manera adecuada, en especial si el código puede acceder a los datos del usuario. Para cumplir su misión, BAB proporciona un servicio de aplicación en el momento de la implementación a fin de evitar que se inicien trabajos no autorizados, así como un registro de auditoría del código y la configuración que se utiliza en los trabajos habilitados para BAB.

Verificación

BAB verifica que los objetos binarios cumplan con determinados requisitos cuando se implementan. Por ejemplo, el propietario de un servicio podría solicitar que el objeto binario de su servicio se deba compilar a partir de un código revisado, registrado, probado y autorizado. Nos referimos a este tipo de verificaciones como verificaciones en el momento de la implementación. BAB también puede realizar verificaciones una vez que se implementa un objeto binario, a las que nos referimos como verificaciones posteriores a la implementación. Para obtener más información sobre estas verificaciones posteriores a la implementación, consulta nuestra sección Modos de aplicación.

Un cambio de código crea un objeto binario nuevo. El objeto binario nuevo se debe implementar para que se le apliquen los cambios. BAB permite muchos tipos de verificaciones en el momento de la implementación. A continuación, se presentan algunos ejemplos de estas verificaciones:

  • ¿Se compila el objeto binario a partir del código registrado?

    ¿Se envía y se registra el código en el repositorio de código fuente de Google? Por lo general, para que se envíe el código, un segundo ingeniero de Google debe revisarlo.

  • ¿Se compila el objeto binario de forma verificable?

    ¿Se puede hacer el seguimiento de este objeto binario en fuentes auditables? ¿Se compiló mediante un sistema de compilación aprobado?

  • ¿Se compila el objeto binario a partir del código probado?

    ¿Cumple el objeto binario con los requisitos de prueba?

  • ¿Se compila el objeto binario a partir del código que se va a utilizar en la implementación?

    ¿Se envió el código al área correcta de nuestro repositorio de código fuente que corresponde al proyecto o equipo relevante para ese trabajo específico de Borg?

Si bien estos requisitos son específicos de nuestro entorno de producción, se podrían aplicar otros similares a los entornos de IC/EC (integración continua/implementación continua) según tus propios requisitos de seguridad, cumplimiento o confiabilidad.

Política específica del servicio

Por lo general, los trabajos que acceden a datos sensibles requieren que se envíe el código, con algunas excepciones por motivos comerciales válidos. Los datos sensibles incluyen datos del usuario, de empleo y financieros, y otros necesarios de la empresa o propiedad. En Google, todos los trabajos deben tener una política. Incluso un trabajo de Borg que no necesita acceder a los datos del usuario debe tener una política definida, pero sin los requisitos específicos descritos.

Cuando los propietarios del servicio se integran a BAB, definen una política con los requisitos de seguridad para su servicio. Todas las cuentas de función utilizadas para implementar su servicio deben especificar una Política de BAB. En cada cuenta de función, la política de BAB define los trabajos previstos que se iniciarán y los requisitos de código y configuración del trabajo. Definir o modificar una política implica un cambio de código que se debe revisar.

A continuación, se describen los requisitos que se pueden aplicar a una política de BAB:

  • Compilación de código verificable: se puede auditar el código que se compila de manera verificable, pero no siempre significa que se sometió a una revisión. Incluso existen casos en los que no se envía el código. El código que se usa en compilaciones verificables se puede auditar durante al menos 18 meses, incluso si no se envía.

  • Código enviado: el código se compila en una ubicación especificada y prevista en nuestro repositorio de código fuente. Por lo general, esto implica que el código se sometió a una revisión.

  • Configuración enviada: cualquier configuración proporcionada 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 sistemas y componentes que aplica BAB se deben controlar de forma estricta. Esto se logra mediante la implementación de los requisitos más estrictos posibles, además de controles manuales adicionales.

Modos de aplicación

BAB realiza diferentes acciones en función de la política que especifica el trabajo de Borg. Nos referimos a estas acciones como modos de aplicación. Existen tres modos: aplicación en el momento de la implementación, auditoría en el momento de la implementación y verificación continua. Cuando se define una política, el propietario del servicio debe elegir la aplicación en el momento de la implementación o la auditoría en el momento de la implementación. El modo de verificación continua está habilitado de forma predeterminada. En las siguientes secciones, se brindan más detalles sobre cada modo.

Modo de aplicación en el momento de la implementación

Cuando se envía un trabajo nuevo, Borgmaster2 consulta a BAB para verificar que el trabajo cumpla con los requisitos establecidos en la política de BAB. Esta verificación funciona como un controlador de admisión. Si se cumplen los requisitos, Borgmaster iniciará el trabajo. De lo contrario, rechazará la solicitud, incluso si el usuario que la realiza está autorizado.

En el modo de aplicación, BAB bloqueará la implementación de un trabajo de Borg si no cumple con los requisitos establecidos en la política de BAB para el trabajo de Borg. Por lo general, los servicios nuevos en BAB comienzan en el modo de auditoría (se describe en la siguiente sección) y, luego, pasan al modo de aplicación.

Procedimientos de respuesta ante emergencias

En el caso de 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 registró. 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. Un desarrollador que implementa un trabajo mediante el procedimiento de respuesta ante emergencias debe presentar una justificación como parte de su solicitud.

Unos segundos después de que se usa el procedimiento de respuesta ante emergencias, BAB registra los detalles acerca del trabajo de Borg asociado. El registro incluye el código que se utilizó y la justificación que proporcionó el usuario. Unos segundos más tarde, se envía un registro de auditoría a nuestro equipo de seguridad centralizado. A las pocas horas, el registro de auditoría se envía al equipo propietario de la cuenta de función. Los procedimientos de respuesta ante emergencias solo se deben usar como un último recurso.

Modo de auditoría en el momento de la implementación

En el modo de auditoría, BAB registra cuando un trabajo de Borg no cumple con los requisitos de la política, pero no bloquea su implementación. Este incumplimiento de la política activa una alerta para el equipo propietario de la cuenta de función.

En Google, requerimos que determinados servicios, como los que acceden a los datos del usuario, usen el modo de aplicación. Recomendamos a todos los propietarios del servicio que usen el modo de aplicación y que solo utilicen el modo de auditoría cuando se integre un servicio nuevo. Para usar el modo de auditoría, los propietarios del servicio deben proporcionar una justificación a fin de obtener una excepción. Por ejemplo, un servicio cuyo SLO de confiabilidad (objetivo de nivel de servicio) es mucho más alto que el que proporciona BAB, usará el modo de auditoría.

Si bien el modo de auditoría resulta útil cuando se ajusta una política inicial, no es un estado práctico estable para la mayoría de los servicios. Cuando se usa el modo de auditoría, el propietario del servicio no recibe ninguna notificación de incumplimientos de política hasta varias horas después de que se produce la infracción. Esto puede generar una transmisión de notificaciones contaminada, lo que puede ocasionar que la configuración incorrecta o los errores de la política que ingresó el propietario del servicio oculten los verdaderos problemas de seguridad. Con el modo de aplicación, el propietario del servicio recibe comentarios inmediatos cuando se intenta iniciar un trabajo que no cumple con la política. Por ello, su transmisión de notificaciones es mucho más clara. Además, el modo de aplicación en BAB detecta errores involuntarios, como el inicio accidental de un trabajo en una función distinta de la que está designada para que se ejecute.

Verificación continua

Una vez que se implementa un trabajo, independientemente de su aplicación en el momento de la implementación, se verifica de forma continua durante su ciclo de vida. 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 se siguen ejecutando) 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 con una identidad que se implementó mediante procedimientos de respuesta ante emergencias. Si se descubre un trabajo que no cumple con la política actualizada, BAB informará a los propietarios del servicio para que puedan mitigar el riesgo.

Paquetes admitidos a nivel global

En Google, existen algunos paquetes que nuestros servicios utilizan con mucha frecuencia. En lugar de forzar a cada servicio para mantener su propia versión, estos paquetes se admiten a nivel central. Nos referimos a estos como paquetes administrados a nivel global. Cuando redacta su Política de BAB, el propietario de un servicio puede especificar un paquete admitido a nivel global para un trabajo determinado. También existe un mecanismo global predeterminado para los paquetes que se usan con mucha frecuencia, de modo que no es necesario que se incluyan de manera individual como parte de la política de cada servicio. Esto permite a Google mantener un control explícito sobre los componentes comunes del sistema que se utilizan en toda la organización y garantiza que estos se revisen y actualicen de forma correcta sin involucrar a equipos individuales. Si bien un propietario del servicio individual podría permitir estos paquetes de manera explícita como parte de la política de BAB de su servicio, esto hace que los propietarios usen la ruta recomendada y admitida fácilmente.

Casos extremos

Google implementa controles de seguridad eficaces para el código implementado en producción, como revisiones de código y compilaciones verificables. BAB funciona como un punto de control y aplicación adicional para garantizar que estos controles de seguridad se implementen de forma correcta.

Sin embargo, BAB no se puede usar de manera eficaz en todos los casos. BAB no admite los siguientes casos extremos: código compilado mediante sistemas de compilación no estándar, código implementado en entornos distintos de Borg y código de análisis de datos y aprendizaje automático, el cual no es adecuado para revisiones de códigos manuales antes de que se seleccionen los parámetros de producción definitivos. En estos casos, existen muchas otras mitigaciones de seguridad, que incluyen otros sistemas de procedencia de código. Sin embargo, este código aún está sujeto a los controles de seguridad generales de Google.

Implementa la autorización binaria para Borg

Para implementar BAB, el equipo de BAB desarrolló varias funciones nuevas, que incluyen los procedimientos de respuesta ante emergencias y el modo de auditoría. Estas herramientas facilitaron a los propietarios del servicio probar BAB por su cuenta. Si consideras implementar algún tipo de BAB en tu organización, es posible que debas realizar un trabajo adicional a fin de facilitar esta transición. En esta sección, se describe el trabajo de organización y administración de cambios que realizamos como parte de nuestro plan de implementación.

Beneficios

BAB ofrece tres beneficios que ayudaron a crear un caso empresarial para su desarrollo y adopción en Google, es decir, menos riesgos de filtración de datos, identidad de código eficaz y cumplimiento simplificado.

Menor riesgo de filtración de datos

En principio, BAB se desarrolló para impedir que una sola persona obtenga acceso programático no autorizado a los datos del usuario. BAB dificulta que un ingeniero, o atacante que obtiene las credenciales de un ingeniero, pueda acceder a datos sensibles de forma inapropiada y sin detección.

Identidad de código eficaz

Según se describe en la sección Infraestructura en contenedores, los trabajos de Borg se ejecutan como una identidad, por lo general, una cuenta de función. Otros servicios usan esta identidad para verificar la autorización adecuada antes de otorgar acceso a los datos. Sin embargo, otros servicios no pueden aplicar el uso de esos datos y, por lo tanto, deben confiar en que la identidad del trabajo no abusa de los datos que recibió. BAB vincula la identidad de un trabajo a un código específico, lo que garantiza que solo se pueda usar el código especificado para usar los privilegios de la identidad del trabajo. Esto permite realizar una transición de una identidad del trabajo, que confía en una identidad y en sus usuarios privilegiados de forma transitiva, a una identidad de código, que confía en un fragmento de código específico que se revisó para tener una semántica específica y que no se puede modificar sin los procesos de aprobación.

Cumplimiento simplificado

BAB simplificó lo que antes eran las tareas de cumplimiento manuales. Algunos procesos en Google requieren controles más estrictos sobre cómo se manejan 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. Después de BAB, muchas de estas verificaciones se automatizaron según las políticas de BAB de 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.

Integración de un servicio

El equipo de BAB se aseguró de que el proceso de integración fuera simple y directo. En un principio, los propietarios del servicio en Google tenían dos preocupaciones principales con respecto a la adopción de BAB:

  • Si BAB no era lo bastante confiable, su implementación podría bloquear los cambios en situaciones críticas.
  • BAB podría ralentizar el desarrollo de un servicio con verificaciones de código frecuentes y procesos iterativos.

Para abordar estos problemas iniciales, el equipo de BAB desarrolló el modo de auditoría. Con este modo, el equipo de BAB pudo demostrarles a algunos de los usuarios pioneros más importantes que BAB funcionaba. Para reforzar aún más su confiabilidad, el equipo de BAB desarrolló un SLO de disponibilidad y, luego, incorporó procedimientos de respuesta ante emergencias al modo de aplicación.

Cuando se integra un servicio existente a BAB, el propietario del servicio suele habilitar primero el modo de auditoría. Esto lo ayuda a identificar y abordar cualquier problema antes de activar el modo de aplicación. La política predeterminada para cualquier trabajo que use BAB en producción es el modo de aplicación. Para implementar el trabajo, el propietario del servicio debe presentar una política que, como mínimo, requiera que el código se envíe y compile de forma verificable. Un propietario del servicio puede implementar su trabajo sin cumplir con este estándar mínimo, pero se le debe conceder una excepción. Si el servicio necesita acceder a servicios o datos más sensibles, el propietario puede pasar a los requisitos más estrictos. Definir una política inicial puede ser una tarea difícil, por lo que el equipo de BAB creó herramientas automatizadas para ayudar a los propietarios del servicio a redactar sus políticas. Las herramientas analizan qué partes del repositorio de código fuente se usan para un trabajo existente y sugieren una política adecuada.

Cuando se integra un servicio nuevo a BAB, el propietario del servicio habilita el modo de aplicación desde el principio. El propietario del servicio redacta un borrador de una política inicial y, luego, la itera con rapidez para agregar requisitos adicionales. Las políticas en sí se administran como cambios de código y, por lo tanto, se requiere un segundo ingeniero de Google para que revise las actualizaciones.

Impacto

La adopción de BAB y un modelo de implementación en contenedores ofrece muchos beneficios a Google en términos de seguridad y compatibilidad:

  • BAB ayuda a reducir el riesgo general con respecto a los usuarios con información privilegiada: cuando se requiere un código para cumplir determinados estándares y prácticas de administración de cambios antes de acceder a los datos del usuario, BAB reduce la posibilidad de que un Googler (o cuya cuenta se vio 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 son más fáciles de depurar, más confiables y tienen una administración de cambios más clara. 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 nuestros sistemas. Los datos sobre esta conformidad se publican de forma interna y otros equipos pueden consultarlos. Esta forma de publicación de los datos de BAB permite a los equipos usar términos comunes cuando se comunican entre sí sobre la protección de los datos. Este lenguaje común reduce el trabajo de ida y vuelta necesario cuando se trabaja con datos en todos los equipos.
  • BAB permite realizar un seguimiento programático de los requisitos de cumplimiento: algunos procesos, como los de informes financieros, deben cumplir con determinados requisitos de administración de cambios para fines de cumplimiento. Con BAB, se pueden automatizar estas verificaciones, lo que ahorra tiempo y aumenta el alcance de la cobertura.

BAB es una de las tantas tecnologías que se usan en Google para mitigar el riesgo de filtración de datos.

Adopta controles similares en tu organización

Aprendimos muchas lecciones importantes cuando implementamos BAB en Google. Hacer un cambio tan grande puede parecer una tarea abrumadora. En esta sección, compartimos las lecciones que aprendimos durante el proceso para que puedas aplicar los principios de BAB en tu organización.

Trabaja para lograr una canalización de IC/EC en contenedores más homogénea

La adopción de BAB en Google fue posible gracias a la coherencia y la integración de las herramientas que usamos en el desarrollo de nuestro código. Este trabajo incluyó revisiones de código, implementaciones en contenedores, identidad basada en servicios y compilaciones verificables en el control de acceso. Las compilaciones verificables te permiten comprobar de qué manera se compilan tus objetos binarios. Los contenedores te permiten separar los objetos binarios de los datos y te ofrecen un punto de bloqueo para garantizar que cumplan con los requisitos de uso. Este enfoque simplificó la adopción de BAB y reforzó las garantías que una solución como BAB puede ofrecer.

La introducción de microservicios permitió la adopción de una identidad basada en servicios (como una cuenta de servicio), en lugar de una identidad basada en host (como una dirección IP). Realizar el cambio hacia una identidad basada en servicios te permitirá cambiar el modo en que administras la autenticación y la autorización entre servicios. Por ejemplo, si usas un token de identidad procesado en una imagen de contenedor para certificar una identidad, las garantías que ofrece la procedencia del código no serán muy eficaces. Si no puedes adoptar una identidad de servicio de forma directa, puedes intentar proteger los token de identidad de manera más eficaz 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 IC/EC. 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 siempre vigentes. 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á. Esta es la razón por la que se lleva a cabo la aplicación de la política de BAB cuando se implementa el código y este accede a los datos, y no cuando se compila. Una política de BAB se define en términos de identidad del 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. Cuando BAB se usa de esta manera, los propietarios del servicio pueden asegurarse de que un trabajo que cumple con los requisitos de BAB solo acceda a los datos y trate el código como una identidad de forma eficaz.

Determina cómo integrar a los propietarios del servicio existente

Identifica a algunos propietarios del servicio que verán los beneficios inmediatos de la aplicación y estarán dispuestos a proporcionar comentarios. Una forma de hacerlo podría ser pedirles a los propietarios que se ofrezcan como voluntarios antes de hacer cambios obligatorios.

Si es posible, se requiere el modo de aplicación en lugar del modo de auditoría, o se aplica de forma contundente cuando se limita el período de gracia para el modo de auditoría. El modo de auditoría permite a los propietarios integrarse con rapidez y comprender mejor el riesgo de filtración de datos. El problema del modo de auditoría es que puede llevar tiempo ver una reducción tangible del riesgo con respecto a los usuarios con información privilegiada. Esta demora puede hacer que sea difícil mostrar el valor y convencer a los demás de adoptar el modo de aplicación. Cuando el equipo de BAB proporcionó los procedimientos de respuesta ante emergencias para la aplicación, los propietarios de servicios estaban más dispuestos a adoptar el modo de aplicación, lo que les daba una vía de escape si lo necesitaban.

Recluta agentes de cambio en todos los equipos

Cuando creamos un mandato de 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. 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.

Descubre cómo administrar el código de terceros

Muchos de los controles de IC/EC que describimos en este documento se encuentran donde una organización desarrolla, revisa y mantiene tu código. Si te encuentras en esta situación, considera cómo vas a incluir el código de terceros como parte de los requisitos de tu política. Por ejemplo, primero podrías eximir el código, mientras pasas a un estado ideal de mantenimiento de un repositorio de todo el código de terceros utilizado y revisarlo con regularidad en función de tus requisitos de seguridad.

Conclusión

Implementar una verificación de aplicación en el momento de la implementación como parte de la infraestructura en contenedores y el proceso de IC/EC nos permitió verificar que el código y la configuración que implementamos cumplen con algunos estándares mínimos de seguridad. Este es un control fundamental que se usa con el objetivo de limitar la capacidad de un posible usuario malintencionado con información privilegiada para ejecutar un trabajo no autorizado que podría acceder a los datos del usuario. La adopción de BAB permitió a Google reducir el riesgo con respecto a los usuarios con información privilegiada, evitar posibles ataques y respaldar la uniformidad de nuestros sistemas de producción.

Referencias adicionales

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

Notas

1La procedencia describe los componentes, los cambios realizados en los componentes y su origen. Consulta https://csrc.nist.gov/glossary/term/Provenance.

2Borgmaster es el controlador centralizado de Borg. Administra la programación de los trabajos y se comunica con los trabajos en ejecución para obtener información sobre su estado.