BeyondProd

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 Google implementa la seguridad en nuestra infraestructura con una arquitectura nativa de la nube llamada BeyondProd. BeyondProd hace referencia a los servicios y controles de nuestra infraestructura que trabajan en conjunto para proteger las cargas de trabajo. Las cargas de trabajo son las únicas tareas que completa una aplicación. BeyondProd ayuda a proteger los microservicios que ejecutamos en nuestro entorno, por ejemplo, cómo cambiamos el código y cómo accedemos a los datos del usuario.

Este documento es parte de una serie de documentos técnicos en los que se describen tecnologías, como BeyondCorp Enterprise, que desarrollamos para ayudar a defender las plataformas de Google contra amenazas sofisticadas. Chrome Enterprise Premium implementa una arquitectura de confianza cero diseñada para brindar acceso seguro a las plataformas de Google y los servicios que se ejecutan en ella. Al igual que Chrome Enterprise Premium, BeyondProd no se basa en el perímetro de red tradicional de seguridad, como firewalls. En cambio, BeyondProd ayuda a generar confianza entre microservicios mediante características como el origen del código, las identidades de servicio y el hardware de confianza. Esta confianza se transmite al software que se ejecuta en Google Cloud y al software que los clientes de Google Cloud implementan y acceden.

En este documento se describen los beneficios de BeyondProd, sus servicios y procesos, además de cómo migrar a esta arquitectura. Para obtener una descripción general de nuestra seguridad de infraestructura, consulta la Descripción general del diseño de seguridad de la infraestructura de Google.

Introducción

Las arquitecturas de seguridad modernas se alejan de un modelo de seguridad tradicional basada en perímetro, en el que un firewall protege el perímetro y cualquier usuario o servicio dentro del perímetro se considera de confianza.

En la actualidad, los usuarios son móviles y por lo general operan fuera del perímetro de seguridad tradicional de una organización, como, por ejemplo, desde sus hogares, una cafetería o un avión. Con BeyondCorp Enterprise, brindamos acceso a los recursos de la empresa con varios factores, como la identidad del usuario, la identidad del dispositivo que se usa para acceder al recurso, el estado del dispositivo y los indicadores de confianza (por ejemplo, el comportamiento de los usuarios y las listas de control de acceso).

BeyondProd aborda la misma preocupación respecto de los servicios de producción, así como Chrome Enterprise Premium, para los usuarios. En una arquitectura nativa de la nube, no podemos confiar en un firewall para proteger la red de producción. Los microservicios se mueven y se implementan en diferentes entornos en hosts heterogéneos y operan en varios niveles de confianza y sensibilidad. Cuando BeyondCorp Enterprise indica que la confianza de los usuarios debe depender de características como el estado contextual de los dispositivos, y no de la capacidad de conectarse a la red corporativa, BeyondProd indica que la confianza del servicio debe depender de características como el origen del código, el hardware de confianza y la identidad del servicio, en lugar de la ubicación en la red de producción, como la dirección IP o el nombre de host.

Infraestructura alojada en contenedores

Nuestra infraestructura implementa cargas de trabajo como microservicios individuales en contenedores. Los microservicios separan las tareas individuales que una aplicación debe realizar en diferentes servicios. Cada servicio se puede desarrollar y administrar de forma independiente con su propia API, lanzamiento, escalamiento y administración de cuotas. Los microservicios son independientes, modulares, dinámicos y efímeros. Pueden distribuirse entre muchos hosts, clústeres o incluso nubes. En una arquitectura de microservicios, una carga de trabajo puede ser uno o varios microservicios.

Una infraestructura alojada en contenedores significa que cada microservicio se implementa como su propio conjunto de contenedores móviles y programables. Para administrar estos contenedores de forma interna, desarrollamos un sistema de organización de contenedores llamado Borg,, que implementa varios miles de millones de contenedores por semana. Borg es el sistema de administración de contenedores unificado de Google y la inspiración para Kubernetes.

Los contenedores hacen que la programación de las cargas de trabajo sea más fácil y eficiente en todas las máquinas. El empaquetado de microservicios en contenedores permite dividir las cargas de trabajo en unidades más pequeñas y administrables para su mantenimiento y detección. Esta arquitectura escala las cargas de trabajo según sea necesario: si hay una demanda alta para una carga de trabajo en particular, es posible que varias máquinas ejecuten copias del mismo servicio en simultáneo a fin de manejar la escala requerida de la carga de trabajo.

En Google, la seguridad cumple un rol fundamental en cada evolución de nuestra arquitectura. Nuestro objetivo con este proceso de arquitectura y desarrollo de microservicios es abordar los problemas de seguridad lo antes posible en el ciclo de desarrollo y de implementación (cuando los problemas son menos costosos) y hacerlo de manera estandarizada y coherente. El resultado final es que los desarrolladores dediquen menos tiempo a la seguridad y, a su vez, obtengan resultados más seguros.

Beneficios de BeyondProd

BeyondProd ofrece muchos beneficios de automatización y seguridad a la infraestructura de Google. Los beneficios son los siguientes:

  • Protección perimetral de la red: Las cargas de trabajo están aisladas de los ataques de red y del tráfico no autorizado de Internet. Aunque el método perimetral no es un concepto nuevo, sigue siendo una práctica recomendada de seguridad para las arquitecturas de la nube. El método perimetral ayuda a proteger la mayor infraestructura posible contra el tráfico no autorizado y los posibles ataques de Internet, como los ataques de DoS basados en el volumen.
  • No existe una confianza mutua inherente entre los servicios: Solo los emisores o servicios autenticados, confiables y autorizados específicamente pueden acceder a cualquier otro servicio. Esto impide que los atacantes usen un código que no sea de confianza para acceder a un servicio. Si un servicio está en peligro, este beneficio ayuda a impedir que el atacante lleve a cabo acciones que le permitan expandir su alcance. Esta desconfianza mutua, combinada con el control de acceso detallado, ayuda a limitar el radio de impacto de una vulneración.
  • Máquinas confiables en las que se ejecuta un código con procedencia conocida: Las identidades del servicio están limitadas a usar solo códigos y configuraciones autorizadas, y se ejecutan solo en entornos verificados y autorizados.
  • Aplicación de políticas coherentes en todos los servicios: La aplicación coherente de políticas ayuda a garantizar que las decisiones de acceso sean confiables en todos los servicios. Por ejemplo, puedes crear una aplicación de políticas en la que se verifiquen las solicitudes de acceso a los datos del usuario. Para acceder al servicio, un usuario final autorizado debe presentar una solicitud validada, y un administrador debe proporcionar una justificación comercial.
  • Lanzamiento de cambios simple, automatizado y estandarizado: Facilita la revisión del impacto sobre la seguridad de los cambios en la infraestructura y permite la aplicación de parches de seguridad con poco impacto en la producción.
  • Aislamiento entre cargas de trabajo que comparten un sistema operativo: Si un servicio está en peligro, no puede afectar la seguridad de otra carga de trabajo que se ejecuta en el mismo host. Este aislamiento ayuda a limitar el radio de impacto de una vulneración.
  • Hardware y certificación de confianza: Una raíz de confianza de hardware ayuda a garantizar que solo se ejecute un código conocido y autorizado en el host (desde el firmware hasta el modo de usuario) antes de que se programen las cargas de trabajo para ejecutarse en ella.

Estos beneficios permiten que los contenedores y los microservicios que se ejecutan dentro de nuestra arquitectura en la nube puedan implementarse, comunicarse entre sí y ejecutarse uno al lado del otro sin debilitar la seguridad de la infraestructura. Además, los desarrolladores de microservicios individuales no se deben abrumar con los detalles de implementación y seguridad de la infraestructura subyacente.

Servicios de seguridad de BeyondProd

Diseñamos y desarrollamos varios servicios de seguridad de BeyondProd a fin de generar los beneficios que se analizan en Beneficios de BeyondProd. En las siguientes secciones se describen estos servicios de seguridad.

Google Front End para la protección perimetral de la red

Google Front End (GFE)ofrece protección perimetral de la red. GFE finaliza la conexión del usuario final y proporciona un punto central para aplicar las prácticas recomendadas de TLS.

GFE es una parte importante de nuestra estrategia para proteger los servicios internos contra ataques de DoS, a pesar de que nuestro énfasis ya no se centra en la seguridad perimetral. GFE es el primer punto de entrada para un usuario que se conecta a la infraestructura de Google. Después de que un usuario se conecta a nuestra infraestructura, GFE también es responsable del balanceo de cargas y de redirigir el tráfico entre regiones según sea necesario. GFE es el proxy perimetral que dirige el tráfico al microservicio correcto.

Las VMs de clientes en Google Cloud no se registran con GFE. En su lugar, se registran en Cloud Front End, que es una configuración especial de GFE que usa la pila de herramientas de redes de Compute Engine. Cloud Front End permite que las VMs de los clientes accedan a un servicio de Google directamente con su dirección IP pública o privada. (Las direcciones IP privadas solo están disponibles cuando el Acceso privado a Google está habilitado).

Seguridad de transporte de la capa de la aplicación para la confianza entre servicios

Seguridad de transporte de la capa de la aplicación (ALTS)ayuda a garantizar que no haya confianza mutua inherente entre los servicios. ALTS se usa para la autenticación de llamada de procedimiento remoto (RPC), la integridad, la encriptación del tráfico y las identidades del servicio. ALTS es un sistema de encriptación mutuo de autenticación y transporte para los servicios de la infraestructura de Google. Por lo general, las identidades están vinculadas a los servicios, en lugar de a un host o nombre de servidor específico. Esta vinculación ayuda con la replicación sin interrupciones del microservicio, el balanceo de cargas y la reprogramación entre hosts.

Cada máquina dispone de una credencial de ALTS que se aprovisiona con el sistema de integridad de host y solo se puede desencriptar si el sistema de integridad de host verificó que el inicio seguro se realizó correctamente. La mayoría de los servicios de Google se ejecutan como microservicios sobre Borg y cada uno tiene su propia identidad de ALTS. Borg Prime,el controlador centralizado de Borg, otorga estas credenciales de microservicio de ALTS a las cargas de trabajo según la identidad del microservicio. Las credenciales de ALTS a nivel de la máquina forman el canal seguro para el aprovisionamiento de las credenciales de microservicio, de modo que solo las máquinas que pasaron correctamente el inicio verificado de la integridad del host pueden alojar cargas de trabajo de microservicios. Consulta Certificados de carga de trabajo para obtener más información sobre las credenciales de ALTS.

Autorización binaria para Borg, a fin de verificar la procedencia del código

La Autorización binaria para Borg (BAB)proporciona la verificación de la procedencia del código. La BAB es una verificación de aplicación en el momento de la implementación que ayuda a garantizar que el código cumpla con los requisitos internos de seguridad antes de implementar el código. Por ejemplo, la verificación de aplicación de la BAB incluye garantizar que un segundo ingeniero revise los cambios antes de enviar el código a nuestro repositorio de código fuente y que los objetos binarios se compilen de manera verificable en una infraestructura dedicada. La BAB restringe la implementación de los microservicios no autorizados en nuestra infraestructura.

Integridad del host para la confianza de la máquina

Integridad del hostverifica la integridad del software del sistema host mediante un proceso de inicio seguro y cuenta con el respaldo de un chip de seguridad de hardware que brinda una raíz de confianza (llamado Titan) cuando es compatible. Las verificaciones de integridad del host incluyen la verificación de firmas digitales en el BIOS, el controlador de administración de la placa base (BMC),el bootloader y el kernel del SO. Cuando sean compatibles, las verificaciones de integridad del host pueden incluir un código de modo de usuario y un firmware periférico (como NIC). Además de la verificación de firmas digital, la integridad del host ayuda a garantizar que cada host ejecute la versión deseada de estos componentes de software.

Administración de acceso a servicios y tickets de contexto del usuario final para la aplicación de políticas

La administración de acceso a serviciosy los tickets de contexto del usuario finalayudan a aplicar políticas de manera coherente en todos los servicios.

La administración de acceso a servicios limita la forma en que se accede a los datos entre servicios. Cuando se envía una RPC de un servicio a otro, la administración de acceso a servicios define las políticas de autorización y auditoría que los servicios necesitan para acceder a los datos del servicio receptor. Esto limita la forma en que se accede a los datos, otorga el nivel mínimo de acceso necesario y especifica cómo se puede auditar el acceso. En la infraestructura de Google, la administración de acceso a servicios limita el acceso de un microservicio a los datos de otro y permite que se lleven a cabo análisis globales de los controles de acceso.

Un servicio de autenticación de usuario final emite los tickets de contexto del usuario final que proporcionan una identidad de usuario distinta de su identidad de servicio. Estos tickets son credenciales protegidas por la integridad y emitidas de forma centralizada; se pueden reenviar y certifican la identidad de un usuario final que realizó una solicitud del servicio. Además, reducen la necesidad de confianza entre los servicios, ya que las identidades de pares que usan la ALTS pueden no ser suficientes para otorgar acceso cuando esas decisiones de acceso también se basen en la identidad del usuario final.

Herramientas de Borg para el lanzamiento automático de cambios y escalabilidad

Las herramientas de Borg para implementaciones azul-verde proporcionan un lanzamiento de cambios simple, automatizado y estandarizado. Una implementación azul-verde es una forma de implementar un cambio en una carga de trabajo sin afectar el tráfico entrante, de modo que los usuarios finales no experimenten ningún tiempo de inactividad cuando accedan a la aplicación.

Un trabajo de Borges una instancia única de un microservicio que ejecuta una parte de una aplicación. Los trabajos escalan para manejar la carga, ya que se implementan trabajos nuevos cuando la carga aumenta y se cancelan trabajos existentes cuando la carga disminuye.

Las herramientas de Borg son responsables de migrar cargas de trabajo en ejecución cuando se realizan tareas de mantenimiento. Cuando se implementa un nuevo trabajo de Borg, un balanceador de cargas mueve el tráfico de forma gradual de un trabajo existente a uno nuevo. Esto permite que un microservicio se actualice sin tiempo de inactividad y sin que el usuario lo note.

También usamos esta herramienta para aplicar actualizaciones del servicio cuando agregamos características nuevas y actualizaciones de seguridad críticas sin tiempo de inactividad. Para los cambios que afectan nuestra infraestructura, usamos la migración en vivo de las VMs del cliente a fin de garantizar que las cargas de trabajo no se vean afectadas.

Si deseas obtener más información, consulta Autorización binaria para Borg.

Kernel de gVisor para el aislamiento de la carga de trabajo

El kernel de gVisorpermite el aislamiento entre las cargas de trabajo que comparten un sistema operativo. gVisor usa un kernel de espacio de usuario para interceptar y manejar las llamadas del sistema, lo que reduce la interacción con el host y la posible superficie expuesta a ataques. Este kernel proporciona la mayor parte de la funcionalidad necesaria a fin de ejecutar una aplicación y limita la superficie del kernel del host a la que puede acceder la aplicación. gVisor es una de las varias herramientas que usamos para aislar cargas de trabajo internas y de clientes de Google Cloud que se ejecutan en el mismo host. Para obtener más información sobre otras herramientas de zonas de pruebas, consulta Zonas de pruebas del código.

Protege los datos del usuario con BeyondProd

En esta sección, se describe cómo los servicios de BeyondProd trabajan en conjunto para proteger los datos del usuario en nuestra infraestructura. En las secciones a continuación se describen dos ejemplos:

  • El acceso a las solicitudes de datos del usuario desde su creación hasta la entrega en su destino
  • Un cambio de código desde el desarrollo hasta la producción

No todas las tecnologías mencionadas se usan en nuestra infraestructura; su uso dependerá de los servicios y las cargas de trabajo.

Acceso a los datos del usuario

En el siguiente diagrama se muestra el proceso que usa nuestra infraestructura a fin de verificar que un usuario tiene permiso para acceder a los datos del usuario.

Controles de seguridad nativos de la nube de Google que permiten el acceso a los datos del usuario.

Los pasos para acceder a las cuentas de usuario son los siguientes:

  1. Un usuario envía una solicitud a GFE.
  2. GFE finaliza la conexión de TLS y reenvía la solicitud al frontend del servicio correspondiente con la ALTS.
  3. El frontend de la aplicación autentica la solicitud del usuario mediante un servicio central de autenticación de usuario final (EUA) y, si no hay errores, recibe un ticket de contexto criptográfico y de corta duración para el usuario final.
  4. El frontend de la aplicación realiza una RPC sobre la ALTS a un servicio de backend de almacenamiento y reenvía el ticket en la solicitud de backend.
  5. El servicio de backend usa la administración de accesos a servicios para garantizar que se cumplan los siguientes criterios:
    • El frontend se autentica mediante un certificado válido y sin revocar. Esta verificación implica que se ejecuta en un host de confianza y que las verificaciones de la BAB se realizaron de forma correcta.
    • La identidad ALTS del servicio de frontend está autorizada para hacer solicitudes al servicio de backend y presentar un ticket de EUC.
    • El ticket de contexto del usuario final es válido.
    • El usuario en el ticket de EUC está autorizado para acceder a los datos solicitados.

Si alguna de estas verificaciones falla, se rechaza la solicitud.

Si estas verificaciones se aprueban, los datos se devuelven al frontend de la aplicación autorizada y se entregan al usuario autorizado.

En muchos casos, hay una cadena de llamadas de backend y cada servicio intermediario realiza una verificación de acceso a servicios en las RPC entrantes y el ticket se reenvía en las RPC salientes.

Para obtener más información sobre cómo se enruta el tráfico dentro de nuestra infraestructura, consulta Cómo se enruta el tráfico.

Cambio de código

En el diagrama que se encuentra a continuación se muestra cómo se implementa un cambio de código.

Cómo se realizan los cambios de código.

Los pasos para hacer un cambio de código son los siguientes:

  1. Un desarrollador realiza un cambio en un microservicio protegido por la BAB. El cambio se envía a nuestro repositorio de código central,, en el que se aplica de manera forzosa la revisión de código. Después de la aprobación, el cambio se envía al sistema de compilación central y confiableen el que se crea un paquete con un certificado de manifiesto de compilación firmado y verificable.

  2. En el momento de la implementación, la BAB valida el certificado firmado de la canalización de compilación para verificar que se haya seguido el proceso.

  3. Borg controla todas las actualizaciones de cargas de trabajo mediante un modelo de confiabilidad en el que se garantiza una interrupción mínima de los servicios, ya sea un lanzamiento rutinario o un parche de seguridad de emergencia.

  4. GFE mueve el tráfico a la implementación nueva mediante el balanceo de cargas para garantizar la continuidad de las operaciones.

Para obtener más información sobre este proceso, consulta Nuestro proceso de desarrollo y producción.

Todas las cargas de trabajo requieren aislamiento. Si la carga de trabajo es menos confiable porque el código fuente se origina fuera de Google, se puede implementar en un entorno protegido por gVisor o usar otras capas de aislamiento. Este aislamiento ayuda a contener a un adversario que logra poner en peligro una aplicación.

Implicaciones de seguridad nativas de la nube

En las siguientes secciones se proporciona una comparación entre los aspectos de seguridad de la infraestructura tradicional y sus contrapuntos en una arquitectura nativa de la nube.

Arquitectura de aplicaciones

No se puede proteger una arquitectura nativa de la nube con un solo modelo de seguridad más tradicional, centrado en la seguridad basada en el perímetro. Antes, las aplicaciones monolíticas usaban una arquitectura de tres niveles y se implementaban en centros de datos corporativos privados que tenían suficiente capacidad para manejar la carga máxima de los eventos críticos. Las aplicaciones con requisitos específicos de red o hardware se implementaban de manera intencional en máquinas específicas que, por lo general, mantenían direcciones IP fijas. Los lanzamientos eran poco frecuentes, grandes y difíciles de coordinar, ya que los cambios resultantes afectaban al mismo tiempo a muchas partes de la aplicación. Esto dio lugar a aplicaciones de muy larga duración que se actualizaban con menos continuidad y en las que los parches de seguridad, por lo general, se aplicaban con menos frecuencia.

Sin embargo, en un modelo nativo de la nube, las aplicaciones deben ser portátiles entre diferentes entornos, ya que pueden ejecutarse en nubes públicas, centros de datos privados o servicios alojados por terceros. Por lo tanto, en lugar de una aplicación monolítica, una aplicación alojada en contenedores que se divide en microservicios es ideal para los entornos de la nube. Los contenedores separan los objetos binarios que necesita la aplicación del sistema operativo del host subyacente y permiten que las aplicaciones sean más portátiles. Nuestros contenedores son inmutables, lo que significa que no cambian después de la implementación. En cambio, se vuelven a compilar y a implementar con frecuencia.

La reutilización y el uso compartido del hardware y de las redes es más frecuente, dado que los contenedores se reinician, detienen o reprograman con frecuencia. El proceso de desarrollo es más coherente y uniforme entre los equipos con un proceso común y estandarizado de compilación y distribución, aunque los equipos administren el desarrollo de sus microservicios de manera independiente. Como resultado, las consideraciones de seguridad (como las revisiones de seguridad, el escáner de código y la administración de vulnerabilidades) se pueden abordar de forma anticipada en los ciclos de desarrollo.

Malla de servicios

Cuando se compila una infraestructura compartida y diseñada de forma segura que todos los desarrolladores utilicen, se minimiza la carga de los desarrolladores de implementar y conocer los requisitos de seguridad comunes. La funcionalidad de seguridad debería requerir poca o ninguna integración en cada aplicación y, en cambio, se proporciona como una estructura que abarca y conecta todos los microservicios. Por lo general, esto se denomina malla de servicios. Esto también significa que la seguridad se puede implementar y administrar por separado de las actividades normales de desarrollo o implementación.

Una malla de servicios es una estructura compartida en la capa de infraestructura que abarca y conecta todos los microservicios. Una malla de servicios permite la comunicación entre servicios, que puede controlar el tráfico, aplicar políticas y proporcionar supervisión centralizada para las llamadas de servicio.

Seguridad de confianza cero

En un modelo de seguridad tradicional en el que se usan centros de datos privados, las aplicaciones de una organización dependen de un firewall para ayudar a proteger las cargas de trabajo de las amenazas externas basadas en la red.

Con un modelo de seguridad de confianza cero, las decisiones de autorización no dependen de los firewalls. En cambio, otros controles, como la identidad de las cargas de trabajo, la autenticación y la autorización, ayudan a proteger los microservicios, ya que garantizan que las conexiones internas o externas se validen antes de que puedan realizar transacciones. Cuando ya no dependes de los firewalls o controles basados en la red, puedes implementar la segmentación a nivel de microservicios, sin confianza inherente entre los servicios. Mediante la segmentación a nivel de microservicios, el tráfico puede tener niveles de confianza variables con diferentes controles y ya no solo se compara el tráfico interno con el externo.

Requisitos de seguridad compartidos que están integrados en las pilas de servicios

En un modelo de seguridad tradicional, las aplicaciones individuales son responsables de cumplir con sus propios requisitos de seguridad al margen de otros servicios. Estos requisitos incluyen la administración de identidades, la finalización de TLS y la administración de acceso a los datos. Esto puede generar implementaciones incoherentes o problemas de seguridad no resueltos, ya que estos problemas se deben corregir en muchos lugares, lo que dificulta la aplicación de correcciones.

En una arquitectura nativa de la nube, los componentes se reutilizan con mucha más frecuencia entre los servicios. Los cuellos de botella permiten que las políticas se apliquen de manera coherente en todos los servicios. Se pueden aplicar políticas distintas con servicios de seguridad diferentes. Se pueden dividir las distintas políticas en microservicios separados, en lugar de requerir que cada aplicación implemente los servicios de seguridad críticos por separado. Por ejemplo, se puede crear una política para garantizar el acceso autorizado a los datos del usuario y otra para garantizar el uso de conjuntos de algoritmos de cifrado de TLS actualizados.

Procesos estandarizados con lanzamientos más frecuentes

En un modelo de seguridad tradicional, los servicios compartidos son limitados y, a menudo, el código se duplica y se combina con el desarrollo local. El uso compartido limitado dificulta la determinación del impacto de un cambio y la manera en que este afecte muchas partes de una aplicación. Como resultado, los lanzamientos son poco frecuentes y difíciles de coordinar. Para realizar un cambio, es posible que los desarrolladores necesiten actualizar cada componente directamente (por ejemplo, abrir conexiones SSH a cada máquina virtual para actualizar una configuración). En general, esto puede conducir a aplicaciones de muy larga duración.

Desde una perspectiva de seguridad, debido a que el código a menudo está duplicado, es más difícil de revisar y es aún más difícil garantizar que cuando se corrija una vulnerabilidad lo haga en todas partes.

En una arquitectura nativa de la nube los lanzamientos son frecuentes y estandarizados. Este proceso permite que la seguridad se desplace hacia la izquierda en el ciclo de desarrollo de software. El desplazamiento a la izquierda hace referencia a los pasos anteriores en el ciclo de desarrollo de software, que puede incluir pasos como codificar, compilar, probar, validar y, luego, implementar. El cambio a la izquierda permite una aplicación de la seguridad más simple y coherente, por ejemplo, la aplicación regular de parches de seguridad.

El cambio a BeyondProd

La transición de Google hacia BeyondProd requirió cambios en dos áreas principales: en nuestra infraestructura y en nuestro proceso de desarrollo. Abordamos estos cambios de forma simultánea, pero se pueden abordar por separado si se desea configurar algo similar en el entorno.

Cambios en nuestra infraestructura

Nuestro objetivo es automatizar la seguridad en toda la infraestructura, ya que creemos que la seguridad debe escalar de la misma manera que los servicios. Los servicios deben ser seguros de forma predeterminada y ser inseguros solo después de que se tome una decisión explícita para aceptar los riesgos. Las intervenciones humanas en nuestra infraestructura deben ser excepcionales y no rutinarias, y se deben poder auditar cuando se produzcan. De esta forma, podemos autenticar un servicio en función del código y de la configuración que se implementa para el servicio, en lugar de basarse en las personas que implementaron el servicio.

Comenzamos por crear una base sólida de identidad, autenticación y autorización de servicios. Un microservicio usa una identidad de servicioa fin de autenticarse en otros servicios que se ejecutan en la infraestructura Tener una base de identidades de servicio confiable nos permitió implementar funciones de seguridad de nivel superior que dependen de la validación de estas identidades, como la administración de acceso a servicios y los tickets de contexto del usuario final. A fin de facilitar la transición de los servicios nuevos y los existentes, se proporcionó la ALTS en un principio como una biblioteca con un único daemon auxiliar. Este daemon se ejecutaba en el host al que llamaban todos los servicios y con el tiempo evolucionó hacia una biblioteca en la que se usan las credenciales de servicio. La biblioteca de la ALTS se integró sin problemas en la biblioteca principal de la RPC. Esta integración facilitó su amplia adopción, sin una carga significativa para los equipos de desarrollo individuales. El lanzamiento de la ALTS era un requisito para implementar la administración de acceso a servicios y los tickets de contexto del usuario final.

Cambios en nuestros procesos de desarrollo

Es fundamental que Google establezca un proceso sólido de compilación y revisión de código para garantizar la integridad de los servicios que se ejecutan. Creamos un proceso de compilación central en el que podemos comenzar a aplicar requisitos, como una revisión de código de dos personas y pruebas automatizadas en el momento de la compilación y la implementación. (Consulta Autorización binaria para Borg para obtener más información sobre la implementación).

Una vez implementados los conceptos básicos, comenzamos a abordar la necesidad de ejecutar código externo y no confiable en nuestros entornos. Para lograr este objetivo, comenzamos a trabajar con zonas de pruebas: primero con ptracey, luego, con gVisor. Del mismo modo, las implementaciones azul-verde proporcionaron beneficios significativos en términos de seguridad (por ejemplo, aplicación de parches) y confiabilidad.

Descubrimos con rapidez que era más fácil si un servicio comenzaba por registrar incumplimientos de política en lugar de bloquearlos. El beneficio de este enfoque era doble:

  • Les dio a los propietarios del servicio la oportunidad de probar el cambio y medir el impacto (si lo hubiera) que tendría el traspaso a un entorno nativo de la nube en su servicio.
  • Nos permitió corregir cualquier error, así como identificar cualquier funcionalidad adicional que pudiéramos proporcionar a los equipos de servicio.

Por ejemplo, cuando un servicio se incorpora a la BAB, los propietarios del servicio habilitan el modo de solo auditoría. Esto los ayuda a identificar código o flujos de trabajo que no cumplen con sus requisitos. Una vez que abordan los problemas marcados por el modo de solo auditoría, los propietarios del servicio cambian al modo de aplicación. En gVisor, logramos esto mediante la ejecución de cargas de trabajo en zonas de prueba, incluso con brechas de compatibilidad en las capacidades de la zona de pruebas y, luego, resolvimos estas brechas sistemáticamente para mejorar la zona de pruebas.

¿Qué sigue?