BeyondProd

Este contenido se actualizó por última vez en mayo del 2024 y representa la situación en el momento en que se redactó. Las políticas y los sistemas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos constantemente la protección que proporcionamos a nuestros clientes.

En este documento se describe cómo implementa Google la seguridad en nuestra infraestructura mediante una arquitectura nativa de la nube llamada BeyondProd. BeyondProd hace referencia a los servicios y controles de nuestra infraestructura que trabajan conjuntamente para proteger las cargas de trabajo. Las cargas de trabajo son las tareas únicas que completa una aplicación. BeyondProd nos ayuda a proteger los microservicios que ejecutamos en nuestro entorno, incluido el modo en que cambiamos el código y accedemos a los datos de los usuarios.

Este documento forma parte de una serie de documentos técnicos que describen las tecnologías, como Chrome Enterprise Premium, que hemos desarrollado para ayudar a proteger las plataformas de Google frente a amenazas sofisticadas. Chrome Enterprise Premium implementa una arquitectura de confianza cero diseñada para proporcionar acceso seguro a las plataformas de Google y a los servicios que se ejecutan en ellas. Al igual que Chrome Enterprise Premium, BeyondProd no se basa en protecciones de perímetro de red tradicionales, como los cortafuegos. En su lugar, BeyondProd ayuda a crear confianza entre microservicios mediante características como la procedencia del código, las identidades de servicio y el hardware de confianza. Esta confianza se extiende al software que se ejecuta en Google Cloud y al software que implementan y al que acceden los clientes Google Cloud.

En este documento se describen las ventajas de BeyondProd, sus servicios y procesos, y cómo hemos migrado a esta arquitectura. Para obtener información general sobre la seguridad de nuestra infraestructura, consulta la descripción general del diseño de seguridad de la infraestructura de Google.

Introducción

Las arquitecturas de seguridad modernas han dejado atrás el tradicional modelo de seguridad basado en perímetros, en el que un cortafuegos protegía el perímetro y se daba plena confianza a los usuarios o los servicios que estuvieran dentro.

En la actualidad, los usuarios son móviles y tienden a operar fuera del perímetro de seguridad convencional de la organización, por ejemplo, desde sus casas, una cafetería o un avión. Con Chrome Enterprise Premium, concedemos acceso a los recursos de la empresa mediante varios factores, como la identidad del usuario, la identidad del dispositivo que se utiliza para acceder al recurso, el estado del dispositivo, señales de confianza (como el comportamiento del usuario) y listas de control de acceso.

BeyondProd aborda el mismo problema en los servicios de producción que Chrome Enterprise Premium en los usuarios. En una arquitectura nativa de la nube, no podemos depender solo de un cortafuegos para proteger la red de producción. Los microservicios se desplazan y se despliegan en entornos diferentes entre hosts heterogéneos, y operan en varios niveles de confianza y sensibilidad. Mientras que Chrome Enterprise Premium establece que la confianza del usuario debe depender de características como el estado contextual de los dispositivos y no de la capacidad de conectarse a la red corporativa, BeyondProd establece que la confianza del servicio debe depender de características como la procedencia 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 en contenedores

Nuestra infraestructura despliega cargas de trabajo en forma de microservicios en contenedores. Los microservicios separan las tareas concretas que una aplicación debe realizar en distintos servicios. Cada servicio puede desarrollarse y gestionarse de manera independiente, con su propia gestión de APIs, lanzamientos, escalados y cuotas. Los microservicios son independientes, modulares, dinámicos y efímeros. Se pueden distribuir entre muchos hosts, clústeres o incluso nubes diferentes. En una arquitectura de microservicios, una carga de trabajo podría ser uno o varios microservicios.

Una infraestructura en contenedores implica que cada microservicio se despliega con su propio conjunto de contenedores móviles y programables. Para gestionar estos contenedores internamente, desarrollamos un sistema de orquestación de contenedores denominado Borg, que despliega varios miles de millones de contenedores a la semana. Borg es el sistema de gestión de contenedores unificado de Google y sirvió de inspiración a los creadores de Kubernetes.

Los contenedores hacen que sea más fácil y eficiente programar cargas de trabajo en diferentes máquinas. El empaquetado de microservicios en contenedores permite dividir las cargas de trabajo en unidades más pequeñas y fáciles de gestionar con fines de mantenimiento y detección. Esta arquitectura escala las cargas de trabajo según sea necesario: si sube la demanda de una carga en concreto, podrá haber varias máquinas ejecutando copias del mismo contenedor para gestionar el nivel de carga de trabajo que se precise.

En Google, la seguridad desempeña un papel fundamental en todas las fases evolutivas de nuestra arquitectura. Nuestro objetivo al crear esta arquitectura de microservicios y este proceso de desarrollo es abordar los problemas de seguridad en las fases tempranas del ciclo de desarrollo y despliegue (ya que estos son los momentos en los que la resolución de problemas es menos costosa) y, además, hacerlo de forma normalizada y uniforme. El resultado final es que los programadores dedican menos tiempo preocupándose por la seguridad y, a la vez, consiguen resultados más seguros.

Ventajas de BeyondProd

BeyondProd ofrece muchas ventajas de automatización y seguridad a la infraestructura de Google. Entre las ventajas se incluyen las siguientes:

  • Protección de redes en el perímetro: las cargas de trabajo se aíslan de los ataques a la red y del tráfico no autorizado procedente de Internet. Aunque el enfoque perimetral no es un concepto nuevo, sigue siendo una práctica recomendada de seguridad para las arquitecturas de nube. El enfoque perimetral ayuda a proteger tantos componentes de la infraestructura como sea posible frente al tráfico no autorizado y posibles ataques procedentes de Internet (por ejemplo, ataques DoS por volumen).
  • Inexistencia de confianza mutua inherente entre servicios: solo pueden acceder a otro servicio las llamadas o los servicios autenticados, de confianza y portadores de una autorización específica. De este modo, se impide que los atacantes utilicen código no confiable para acceder a un servicio. Si un servicio se ve comprometido, esta ventaja ayuda a evitar que el atacante lleve a cabo acciones que le permitan ampliar su alcance. Esta desconfianza mutua, combinada con el control de acceso granular, contribuye a limitar el alcance de cualquier posible vulneración.
  • Máquinas de confianza que ejecutan código de procedencia conocida: se obliga a las identidades de servicio a utilizar solo código y configuraciones autorizados, así como a ejecutarse solo en entornos autorizados y verificados.
  • Implementación coherente de políticas en los servicios: la implementación coherente de políticas ayuda a garantizar que las decisiones de acceso sean fiables en todos los servicios. Por ejemplo, puedes crear una aplicación de la política que verifique las solicitudes de acceso a los datos de usuario. Para acceder al servicio, un usuario final autorizado debe presentar una solicitud validada, y un administrador debe proporcionar una justificación empresarial.
  • Simplificación, automatización y normalización del lanzamiento de cambios: se pueden revisar con facilidad los cambios en la infraestructura para ver cómo repercuten en la seguridad y se pueden lanzar los parches de seguridad ocasionando el mínimo impacto posible en la producción.
  • Aislamiento entre cargas de trabajo que compartan sistema operativo: si se vulnera un servicio, no puede afectar a la seguridad de otra carga de trabajo que se ejecute en el mismo host. Este aislamiento ayuda a limitar el alcance de una vulneración.
  • Hardware de confianza y certificación: una raíz de confianza de hardware ayuda a asegurar que solo se ejecute en el host código conocido y autorizado (desde el firmware hasta el modo de usuario) antes de que se programe la ejecución de cualquier carga de trabajo en él.

Gracias a estas ventajas, los contenedores y los microservicios que se ejecutan en nuestra arquitectura de nube se pueden implementar, comunicar entre sí y ejecutar unos junto a otros sin que se vea afectada la seguridad de nuestra infraestructura. Además, los detalles de seguridad e implementación de la infraestructura subyacente no suponen una carga para los programadores de los microservicios.

Servicios de seguridad de BeyondProd

Hemos diseñado y desarrollado varios servicios de seguridad de BeyondProd para ofrecer las ventajas que se describen en la sección Ventajas de BeyondProd. En las siguientes secciones se describen estos servicios de seguridad.

Google Front End para la protección del perímetro de la red

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

A pesar de que hemos dejado de hacer hincapié en la seguridad basada en perímetros, GFE sigue siendo una parte importante de nuestra estrategia de protección de los servicios internos frente a los ataques de denegación de servicio. GFE es el primer punto de entrada para un usuario que se conecta a la infraestructura de Google. Una vez que un usuario se conecta a nuestra infraestructura, GFE también se encarga del balanceo de carga y del redireccionamiento del tráfico entre regiones según sea necesario. GFE es el proxy perimetral que enruta el tráfico al microservicio pertinente.

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

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

Seguridad de transporte en la capa de la aplicación (ALTS) ayuda a asegurar que no haya confianza mutua inherente entre los servicios. ALTS se usa para la autenticación de llamadas a procedimientos remotos (RPC), la integridad, el encriptado del tráfico y las identidades de servicio. ALTS es un sistema de encriptado durante el transporte y autenticación mutua para los servicios de la infraestructura de Google. Por lo general, las identidades están vinculadas a los servicios en lugar de a un nombre de servidor o host específicos. Esta vinculación facilita la replicación de microservicios, el balanceo de carga y la reprogramación entre hosts.

Cada máquina tiene una credencial ALTS que se aprovisiona mediante el sistema de integridad del host y solo se puede descifrar si el sistema de integridad del host ha verificado que el arranque seguro se ha realizado correctamente. La mayoría de los servicios de Google se ejecutan en forma de microservicios sobre Borg, cada uno de los cuales tiene su propia identidad ALTS. Borg Prime, el controlador centralizado de Borg, otorga estas credenciales de microservicio ALTS a las cargas de trabajo en función de la identidad del microservicio. Las credenciales ALTS de nivel de máquina forman el canal seguro destinado a aprovisionar credenciales de microservicios, de modo que solo las máquinas que hayan superado el inicio verificado de la integridad del host puedan alojar cargas de trabajo de microservicios. Para obtener más información sobre las credenciales de ALTS, consulta Certificados de carga de trabajo.

Autorización binaria para Borg para la procedencia del código

Autorización binaria para Borg (BAB) proporciona verificación de la procedencia del código. BAB es un mecanismo de comprobación del cumplimiento en el momento del despliegue que se asegura de que el código cumpla los requisitos de seguridad internos antes de ser desplegado. Por ejemplo, la comprobación del cumplimiento de BAB incluye asegurarse de que un segundo ingeniero revise los cambios antes de que el código se envíe a nuestro repositorio de código fuente y de que los binarios se compilen de forma verificable en infraestructuras dedicadas. En nuestra infraestructura, BAB restringe el despliegue de microservicios que no cuenten con autorización.

Integridad de hosts para la confianza de las máquinas

Integridad de hosts verifica la integridad del software del sistema host a través de un proceso de arranque seguro y tiene el respaldo de un chip de seguridad de raíz de confianza de hardware (llamado Titan) cuando existe compatibilidad. Las comprobaciones de integridad de hosts incluyen la verificación de firmas digitales en el BIOS, el controlador de gestión de placa base (BMC), el bootloader y el kernel del SO. Cuando se admite, las comprobaciones de integridad del host pueden incluir código en modo de usuario y firmware periférico (como NICs). Además de la verificación de la firma digital, la integridad del host ayuda a asegurar que cada host ejecute la versión prevista de estos componentes de software.

Gestión del acceso a servicios y tickets de contexto de usuarios finales para aplicar políticas

La gestión del acceso a servicios y las incidencias contextuales de usuarios finales ayudan a aplicar las políticas de forma coherente en todos los servicios.

La gestión del acceso a servicios limita la forma de acceder a datos entre los servicios. Cuando se envía una RPC de un servicio a otro, la gestió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. De este modo, se restringe la forma de acceso a los datos, se concede el nivel mínimo de acceso necesario y se especifican las opciones de auditar ese acceso. En la infraestructura de Google, la gestión de acceso a servicios limita el acceso de un microservicio a los datos de otro y permite realizar análisis globales de controles de acceso.

Un servicio de autenticación de usuarios finales emite las incidencias contextuales de usuarios finales, que prestan servicios con una identidad de usuario que es independiente de su identidad de servicio. Se trata de credenciales protegidas por integridad, emitidas de forma centralizada y susceptibles de reenvío que certifican la identidad de cualquier usuario final que haya solicitado el servicio. Estas incidencias reducen la necesidad de que haya confianza entre servicios, ya que las identidades de emparejamiento que usan ALTS pueden no ser suficientes para conceder acceso, cuando tales decisiones de acceso suelen basarse también en la identidad del usuario final.

Herramientas de Borg para la implementación automática de cambios y la escalabilidad

Las herramientas de Borg para los despliegues azul-verde proporcionan una implementación de cambios sencilla, automatizada y estandarizada. Un despliegue azul-verde es una forma de lanzar un cambio en una carga de trabajo sin afectar al tráfico entrante, de modo que los usuarios finales no experimenten tiempo de inactividad al acceder a la aplicación.

Una tarea de Borg es una instancia de un microservicio que ejecuta alguna parte de una aplicación. Las tareas se escalan para gestionar la carga, de tal forma que se despliegan tareas nuevas cuando la carga se incrementa y se eliminan las que ya existen cuando esta se reduce.

Las herramientas de Borg se encargan de migrar las cargas de trabajo en ejecución cuando realizamos tareas de mantenimiento. Cuando se despliega una nueva tarea de Borg, un balanceador de carga va traspasando tráfico de una tarea a otra. Se posibilita así la actualización de un microservicio sin que haya periodo inactivo alguno y sin que el usuario se dé cuenta.

También usamos esta herramienta para aplicar mejoras a los servicios cada vez que les añadimos nuevas funciones, así como para aplicar actualizaciones de seguridad críticas sin que haya tiempo de inactividad. En cuanto a los cambios que afectan a nuestra infraestructura, empleamos la migración activa de las máquinas virtuales de los clientes para asegurarnos de que no afecten a las cargas de trabajo.

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

Kernel de gVisor para el aislamiento de cargas de trabajo

El kernel de gVisor permite aislar las cargas de trabajo que comparten un sistema operativo. gVisor utiliza un kernel de espacio de usuario para interceptar y gestionar syscalls, con lo que se reducen la interacción con el host y la posible superficie de ataque. Este kernel proporciona la mayor parte de la funcionalidad que se necesita para 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 las cargas de trabajo internas y las Google Cloud cargas de trabajo de los clientes que se ejecutan en el mismo host. Para obtener más información sobre otras herramientas de aislamiento, consulta Aislamiento de código.

Proteger los datos de los usuarios con BeyondProd

En esta sección se describe cómo funcionan conjuntamente los servicios de BeyondProd para proteger los datos de los usuarios en nuestra infraestructura. En las secciones siguientes se describen dos ejemplos:

  • Acceder a las solicitudes de datos de usuario desde su creación hasta su entrega en destino.
  • Un cambio de código de desarrollo a producción.

No todas las tecnologías que se indican se utilizan en todas las partes de nuestra infraestructura, sino que ello depende de los servicios y las cargas de trabajo.

Acceder a datos de usuario

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

Controles de seguridad nativos de la nube de Google que acceden a datos de usuario.

Para acceder a las cuentas de usuario, sigue estos pasos:

  1. Un usuario envía una solicitud a GFE.
  2. GFE termina la conexión TLS y reenvía la solicitud al frontend del servicio correspondiente mediante ALTS.
  3. El frontend de la aplicación autentica la solicitud del usuario mediante un servicio de autenticación de usuarios finales (EUA) centralizado y, si es correcta, recibe una incidencia contextual de usuarios finales criptográfica de corta duración.
  4. El frontend de la aplicación hace una RPC a través de ALTS a un servicio de backend de almacenamiento y reenvía la incidencia en la solicitud de backend.
  5. El servicio de backend usa la gestión de acceso a servicios para asegurarse de que se cumplan los siguientes criterios:
    • El frontend se autentica mediante un certificado válido y no revocado. Esta comprobación implica que se está ejecutando en un host de confianza y que las comprobaciones de BAB se han completado correctamente.
    • La identidad ALTS del servicio frontend tiene autorización para hacer solicitudes al servicio de backend y presentar una incidencia EUC.
    • El ticket de contexto del usuario final es válido.
    • El usuario de la incidencia EUC tiene autorización para acceder a los datos solicitados.

Si alguna de estas comprobaciones fracasa, se rechaza la solicitud.

Si estas comprobaciones prosperan, 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, cada uno de los servicios intermediarios somete a las RPC entrantes a una verificación de acceso a servicios y la incidencia se reenvía con RPC salientes.

Para obtener más información sobre cómo se enruta el tráfico dentro de nuestra infraestructura, consulta el artículo ¿Cómo se enruta el tráfico?

Cambios en el código

En el diagrama siguiente se muestra cómo se implementa un cambio de código.

Cómo se realizan los cambios en el código.

Para cambiar el código, sigue estos pasos:

  1. Un desarrollador hace un cambio en un microservicio protegido por BAB. El cambio se envía a nuestro repositorio central de código,, que aplica una revisión de código. Una vez aprobado, el cambio se envía al sistema de compilación central y confiable que genera un paquete con un certificado de archivo de manifiesto de compilación verificable y firmado.

  2. En el momento del despliegue, BAB verifica que se haya seguido este proceso validando el certificado firmado procedente del flujo de procesamiento de compilación.

  3. Borg gestiona todas las actualizaciones de las cargas de trabajo mediante un modelo de fiabilidad que asegura que los servicios sufran interrupciones mínimas, ya se trate de un lanzamiento rutinario o de un parche de seguridad urgente.

  4. GFE mueve el tráfico al nuevo despliegue mediante el balanceo de carga para ayudar a 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 precisan aislamiento. Si la carga de trabajo es menos confiable porque el código fuente procede de fuera de Google, se desplegará con capas de aislamiento más sólidas, como en un entorno protegido por gVisor. Este aislamiento ayuda a contener a un adversario que consiga vulnerar una aplicación.

Implicaciones de la seguridad nativa de la nube

En las siguientes secciones se comparan algunos aspectos de la seguridad de las infraestructuras tradicionales y sus equivalentes en una arquitectura nativa de la nube.

Arquitectura de aplicaciones

Un modelo de seguridad más tradicional, que se centre en la seguridad basada en perímetros, no tiene la capacidad necesaria para proteger una arquitectura nativa de la nube. Tradicionalmente, las aplicaciones monolíticas usaban una arquitectura de tres niveles y se desplegaban en centros de datos corporativos privados que tenían capacidad suficiente para gestionar cargas máximas para eventos críticos. Las aplicaciones con requisitos específicos de hardware o redes se desplegaban en máquinas concretas cuyas direcciones IP suelen ser fijas. Los lanzamientos se realizaban con poca frecuencia, eran voluminosos y difíciles de coordinar, ya que los cambios resultantes afectaban simultáneamente a muchas secciones de la aplicación. Esto se traduce en aplicaciones de muy largo recorrido que se actualizan con menos frecuencia y cuyos parches de seguridad se implementan con menos regularidad.

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 en contenedores dividida en microservicios es ideal para entornos de nube. Los contenedores desvinculan los binarios que tu aplicación necesita del sistema operativo del host subyacente y dotan a tus aplicaciones de mayor portabilidad. Nuestros contenedores son inmutables, lo que significa que no cambian después de desplegarse. En su lugar, se vuelven a crear y a desplegar con frecuencia.

Al reiniciarse, detenerse o reprogramarse a menudo los contenedores, se da una mayor frecuencia de reutilización y uso compartido del hardware y las redes. Gracias a un proceso normalizado y compartido de compilación y distribución, el proceso de programación gana en coherencia y uniformidad entre los equipos, aunque estos gestionen la programación de sus microservicios de manera independiente. Por tanto, los aspectos de seguridad (por ejemplo, las revisiones de seguridad, los análisis de código y la gestión de vulnerabilidades) se pueden abordar en fases prematuras del ciclo de desarrollo.

Service Mesh

Al crear una infraestructura compartida y diseñada de forma segura que todos los desarrolladores utilizan, se minimiza la carga que soportan los desarrolladores al tener que conocer e implementar requisitos de seguridad comunes. La funcionalidad de seguridad apenas debería exigir integración en cada aplicación y habría de proporcionarse como un tejido que envolviera y conectara todos los microservicios. Esta es una característica que conocemos como malla de servicios. Esto significa, además, que la seguridad se puede gestionar e implementar por separado a partir de actividades rutinarias de programación y despliegue.

Una malla de servicios es un tejido compartido en la capa de infraestructura que envuelve y conecta todos los microservicios. Una malla de servicios permite que los servicios se comuniquen entre sí, lo que puede controlar el tráfico, aplicar políticas y proporcionar una monitorización centralizada de las llamadas de servicio.

Seguridad de confianza cero

En un modelo de seguridad tradicional que utiliza centros de datos privados, las aplicaciones de una organización dependen de un cortafuegos para proteger las cargas de trabajo frente a las amenazas externas basadas en la red.

Con un modelo de seguridad de confianza cero, las decisiones de autorización no dependen de los cortafuegos. En su lugar, otros controles, como la identidad de carga de trabajo, la autenticación y la autorización, ayudan a proteger los microservicios asegurándose de que las conexiones internas o externas se validen antes de que puedan realizar transacciones. Cuando te independizas de los cortafuegos o de los controles basados en la red, puedes implementar una segmentación a nivel de microservicio, procurando que no haya confianza inherente entre los servicios. Con la segmentación a nivel de microservicio, el tráfico puede tener distintos niveles de confianza con diferentes controles, y ya no solo comparas el tráfico interno con el externo.

Requisitos de seguridad compartidos que se integran en pilas de servicios

En el modelo de seguridad tradicional, cada una de las aplicaciones se encarga de cumplir sus propios requisitos de seguridad de manera independiente respecto de otros servicios. Entre esos requisitos se encuentran la gestión de identidades, la terminación TLS y la gestión del acceso a los datos. Esto puede dar lugar a implementaciones incoherentes o problemas de seguridad pendientes de resolución debido a que deben rectificarse en demasiados 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 puntos críticos permiten que las políticas se implementen de forma coherente en los servicios. Es posible implementar políticas diferentes a través de servicios de seguridad diferentes. En lugar de exigir a cada una de las aplicaciones que implemente por separado servicios de seguridad críticos, puedes dividir las distintas políticas en microservicios independientes. Por ejemplo, puedes crear una política que garantice el acceso autorizado a datos de usuario y otra que garantice el uso de suites actualizadas de algoritmos de cifrado TLS.

Procesos normalizados con lanzamientos más frecuentes

En el modelo de seguridad tradicional, el número de servicios compartidos es limitado y el código se duplica a menudo y se combina con el desarrollo local. La limitación del uso compartido dificulta la determinación del impacto de un cambio y de cómo podría afectar a muchas partes de una aplicación. Por lo tanto, los lanzamientos se realizan con poca frecuencia y es difícil coordinarlos. Para hacer cualquier cambio, es posible que los desarrolladores tuvieran que actualizar todos los componentes directamente (por ejemplo, abriendo conexiones SSH a cada máquina virtual para actualizar un parámetro). En términos generales, esto puede dar lugar a aplicaciones de recorrido extremadamente largo.

Desde el punto de vista de la seguridad, como el código se duplica a menudo, es más difícil de revisar y aún más complicado asegurarse de que, cuando se corrige una vulnerabilidad, se corrija en todas partes.

En una arquitectura nativa de la nube, los lanzamientos son frecuentes y están normalizados. Este proceso permite que la seguridad se desplace hacia la izquierda en el ciclo de vida del desarrollo de software. "Desplazarse a la izquierda" hace referencia a hacer cambios en pasos anteriores del ciclo de vida del desarrollo de software, que puede incluir pasos como la codificación, la compilación, la realización de pruebas, la validación y el despliegue. Al hacerlo, se posibilita una implementación más sencilla y coherente de la seguridad, incluida la implantación regular de parches de seguridad.

Cambiar a BeyondProd

La transición de Google a BeyondProd requirió cambios en dos áreas principales: nuestra infraestructura y nuestro proceso de desarrollo. Aunque los abordamos simultáneamente, puedes abordarlos de forma independiente si quieres configurar algo similar en tu entorno.

Cambio de nuestra infraestructura

Nuestro objetivo es automatizar la seguridad en toda nuestra infraestructura, ya que creemos que la seguridad debería escalarse en la misma medida que lo hagan los servicios. Los servicios deben ser seguros de forma predeterminada y solo pueden ser inseguros si se ha tomado una decisión explícita para aceptar los riesgos. La intervención humana directa en nuestra infraestructura debe ser una excepción, no una rutina, y las intervenciones deben ser auditables cuando se produzcan. De ese modo, podremos autenticar un servicio en función del código y la configuración desplegados para el servicio, en lugar de las personas que lo desplegaron.

Comenzamos levantando una sólida base de identidad, autenticación y autorización de servicios. Un microservicio usa una identidad de servicio para autenticarse ante otros servicios que se ejecutan en la infraestructura. Los cimientos que construimos a modo de identidades de servicio confiables nos permitieron implementar funciones de seguridad de nivel superior que dependieran de la validación de estas identidades, como la gestión del acceso a servicios y las incidencias contextuales de usuarios finales. Con el objetivo de agilizar esta transición para los servicios nuevos y actuales, el sistema ALTS se proporcionó inicialmente como biblioteca con un único daemon auxiliar. Este daemon se ejecutaba en el host al que llamaban todos los servicios y con el tiempo evolucionó hasta convertirse en una biblioteca que utilizaba credenciales de servicios. La biblioteca de ALTS se integró a la perfección en la biblioteca principal de RPC. Esta integración facilitó su amplia adopción, y no impuso una carga significativa a equipos de desarrollo en concreto. El lanzamiento de ALTS era un requisito previo para lanzar la gestión de acceso a servicios y las incidencias contextuales de usuarios finales.

Cambio de nuestros procesos de programación

Para Google fue crucial establecer un proceso sólido de compilación y revisión de código para asegurar la integridad de los servicios que se están ejecutando. Creamos un proceso de compilación centralizado que nos permitía comenzar a aplicar requisitos, como la revisión de código por dos personas y la realización automatizada de pruebas en las fases de compilación y despliegue. Consulta el artículo Autorización binaria para Borg para obtener más detalles sobre el despliegue.

Tras levantar la estructura básica, comenzamos a abordar la necesidad de ejecutar código externo y no confiable en nuestros entornos. Para ello, empezamos a trabajar creando zonas de pruebas: primero con ptrace y, luego, con gVisor. Del mismo modo, los despliegues azules-verdes aportaron una ventaja notable en términos de seguridad (por ejemplo, en la aplicación de parches) y fiabilidad.

No tardamos en darnos cuenta de que todo se simplificaba si los servicios se iniciaban registrando infracciones de políticas en lugar de bloqueándolas. La ventaja de este enfoque fue doble:

  • Les brindaba a los propietarios de servicios la oportunidad de probar el cambio y medir el impacto (si lo hubiera) que tendría en su servicio la migración a un entorno nativo de la nube.
  • Nos permitió corregir errores e identificar cualquier funcionalidad adicional que fuera necesario proporcionar a los equipos de servicio.

Por ejemplo, cuando un servicio se incorpora a BAB, los propietarios de servicios habilitan el modo de solo auditoría. Esto les facilita la identificación de código o flujos de trabajo que no cumplan con sus requisitos. Una vez que abordan los problemas indicados por el modo de solo auditoría, los propietarios de servicios se pasan al modo de cumplimiento. En gVisor esto lo logramos, en primer lugar, demarcando zonas de pruebas y asignándoles cargas de trabajo, a pesar de que ello comportara carencias de compatibilidad; y, en segundo lugar, resolviendo estas carencias sistemáticamente para mejorar la zona de pruebas.

Siguientes pasos