Este contenido se actualizó por última vez en junio 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.
Google ejecuta una infraestructura de procesamiento distribuido, multiusuario y a escala mundial para proporcionar productos y servicios a miles de millones de personas en todo el mundo. Esta infraestructura debe equilibrar las prioridades en competencia de seguridad, confiabilidad, resiliencia, eficiencia, velocidad de desarrollo, capacidad de depuración y mucho más.
En este documento, se describen algunos de los mecanismos que usamos para mantener una postura de seguridad líder en la industria para los servicios que se ejecutan en el entorno de producción de Google. Estos servicios ocupan todo el espectro de sensibilidad de seguridad, desde experimentos de desarrollo que no tienen acceso a ningún dato sensible hasta la infraestructura de identidad fundamental. Estos servicios completan tareas como el procesamiento de datos del usuario, la administración de lanzamientos de software y el aprovisionamiento y la administración del ciclo de vida de máquinas físicas individuales.
En este documento, se describen los controles de seguridad que ayudan a proteger las siguientes tres capas clave de nuestra infraestructura:
- Servicios de producción, que incluyen los servicios más críticos en términos de seguridad (también conocidos como servicios fundamentales)
- Máquinas de producción
- Cargas de trabajo de producción
Aplicamos estos controles para que el personal de Google solo pueda acceder a servicios, máquinas y cargas de trabajo con fines comerciales legítimos (por ejemplo, acceso de mantenimiento) y para defenderse contra el riesgo de personas con información privilegiada y la vulneración de cuentas del personal. Estos controles proporcionan una mayor protección de defensa en profundidad que complementa los controles de seguridad de la infraestructura existentes que ayudan a evitar que se comprometan las cuentas.
Mejora continua
Los controles que se describen en este documento se usan en todo el entorno de producción de Google. Muchos servicios, incluidos los servicios básicos, usan los niveles de control más recientes que ofrecemos. Sin embargo, debido al alcance y la complejidad de la infraestructura de Google, los servicios de producción individuales suelen tener requisitos únicos y pueden requerir tiempo adicional para implementar las recomendaciones más recientes. Gracias a una cultura de mejora continua, los equipos de ingeniería de confiabilidad de sitios (SRE) y de seguridad de Google adaptan constantemente los controles de seguridad para satisfacer el panorama cambiante de amenazas.
Protección de los servicios de producción
Google ayuda a proteger la integridad de los servicios de producción para que el personal de Google solo pueda acceder a los servicios con un propósito comercial legítimo, como el mantenimiento. Existen dos formas principales de obtener acceso a los servicios que se ejecutan en el entorno de producción: a través del acceso administrativo y a través de la cadena de suministro de software.
En la siguiente lista, se describen los controles que ayudan a proteger cada ruta de acceso.
Controles de acceso administrativo: Los servicios de producción necesitan mantenimiento regular (por ejemplo, lanzamientos de configuración o binarios). En Google, nuestro objetivo es que esas operaciones se realicen a través de la automatización, los proxies seguros o el acceso de emergencia auditado, siguiendo la filosofía de producción sin intervención. El paquete de controles que quita el acceso humano a los activos de producción se denomina Sin personas (NoPe). NoPe le brinda a Google la flexibilidad para implementar controles de acceso que se basan en la sensibilidad de un servicio de producción y su preparación para lograr una postura aún más sólida a través de la mejora continua.
Por ejemplo, Google no permite el acceso unilateral a los servicios fundamentales, incluso el acceso de emergencia requiere la aprobación de otro personal de Google. Un acceso es unilateral si alguien puede realizarlo sin la aprobación de otra persona autorizada.
Controles de la cadena de suministro de software: La mayoría de las cargas de trabajo de producción de Google, incluidos los servicios fundamentales, ejecutan objetos binarios y configuraciones de trabajo que se compilan de forma verificable a partir de código revisado por pares que se encuentra en una fuente de confianza. Aplicamos este proceso con la Autorización Binaria para Borg (BAB).
En el siguiente diagrama, se muestran los controles que ayudan a proteger un servicio de producción.
Cuando aplicamos los niveles más altos de NoPe y BAB, ayudamos a garantizar que ningún personal tenga acceso unilateral, incluso en emergencias, a los servicios fundamentales y que cualquier acceso con privilegios que reciba tenga un alcance y una duración bien definidos. El acceso con privilegios es un nivel de acceso elevado que se otorga al personal para administrar servicios de producción críticos en circunstancias únicas que la automatización no aborda. Hacemos una excepción a esta regla para asegurarnos de que Google tenga una forma de salir de situaciones de bloqueo.
Muchos otros servicios de producción, incluidos productos como Filestore o Cloud SQL y productos de infraestructura interna como Borg y Spanner, están configurados para usar los niveles más altos de NoPe y BAB, y trabajamos de forma continua para facilitar a los propietarios de servicios de producción la adopción de NoPe y BAB con el tiempo.
Controles de acceso de administrador
En Borg, los miembros de un rol de producción pueden leer, escribir o borrar los datos que posee el rol de producción, y pueden ejecutar código con la autoridad del rol. Un rol de producción es una identidad que puede ejecutar cargas de trabajo en el entorno de producción de Google.
La membresía permanente en los roles de producción conlleva el riesgo de consecuencias no deseadas para la producción y el riesgo de que se abuse de estos privilegios. Sin embargo, la misión de SRE exige que los equipos tengan la capacidad de mantener los servicios de los que son responsables, por lo que la eliminación completa del acceso podría no ser una estrategia viable.
El paquete NoPe proporciona una forma de configurar el acceso que equilibra las demandas competitivas de fortalecer a los equipos y mantener la seguridad de los sistemas de producción. Con NoPe, el personal de Google encuentra restricciones en los privilegios de sus cuentas cuando intenta acceder a los servicios de producción. NoPe permite las siguientes restricciones:
- Las solicitudes de acceso requieren una persona que las apruebe y una justificación: un control que se denomina autorización de múltiples partes (MPA) ayuda a garantizar que el personal de Google no pueda obtener acceso a los servicios de producción sin una justificación comercial y la aprobación de otra persona autorizada para verificar la solicitud de acceso.
- Sin acceso directo a los roles de servicio de producción: El personal solo puede acceder a los servicios de producción a través de proxies seguros para NoPe. Los proxies seguros están diseñados para que solo se pueda ejecutar un conjunto de comandos bien definido. Cualquier comando que las organizaciones de Seguridad de Google y SRE consideren peligroso (por ejemplo, rechazar un servicio o acceder a datos o borrarlos) también requiere MPA.
- No hay membresía permanente de roles de producción: Un control llamado acceso a pedido (AoD) requiere que el personal solicite una membresía temporal, en lugar de permitir que las cuentas del personal siempre tengan privilegios de acceso. Este control ayuda a garantizar que los poderes elevados solo se otorguen de forma temporal y por motivos específicos.
- Supervisión de las solicitudes de acceso del personal a los servicios de producción: Google requiere una auditoría periódica de los patrones de acceso a los roles de producción que ejecutan un servicio de producción. El objetivo de la auditoría es eliminar la necesidad de realizar tales solicitudes en el futuro, a través de la mejora continua de las APIs administrativas. El acceso a los servicios de producción debe reservarse solo para situaciones de respuesta de emergencia. En el caso de los servicios básicos, la cantidad de situaciones en las que se otorga acceso es tan baja que un equipo de seguridad realiza una auditoría de cada acceso otorgado para confirmar su validez.
En las siguientes secciones, se analiza cada control en detalle.
Autorización de varias partes para NoPe
La MPA requiere que otro personal autorizado de Google apruebe una solicitud de acceso.
En el caso de las solicitudes de acceso a servicios lo suficientemente sensibles, la MPA también requiere que el personal proporcione una justificación comercial que haga referencia a una emergencia de producción en curso con cada solicitud.
Ambas condiciones son barreras contra el abuso de acceso.
Proxies seguros para NoPe
Los proxies seguros son herramientas que exponen un conjunto predefinido de comandos que el proxy seguro puede ejecutar en nombre de un llamador. Los proxies seguros implementan políticas de autorización detalladas y basadas en reglas para proporcionar restricciones en el acceso a los servicios de producción. Por ejemplo, estas políticas pueden requerir la aprobación de otra persona autorizada para ejecutar comandos que podrían afectar negativamente la seguridad o la confiabilidad (por ejemplo, comandos que borran archivos). Las políticas también pueden permitir que ciertos comandos seguros (por ejemplo, comandos que enumeran el uso de recursos) se ejecuten sin necesidad de aprobación. Esta flexibilidad es fundamental para minimizar el trabajo operativo.
En casos de abuso de acceso, las cuentas siguen limitadas a las operaciones que permite el proxy seguro. La cuenta solo puede ejecutar comandos seguros de forma unilateral, mientras que las operaciones con privilegios requieren la aprobación de otra persona autorizada. Todas las operaciones dejan un registro de auditoría claro.
Para obtener más información sobre los proxies seguros, consulta la presentación de SREcon sobre producción sin intervención. La producción sin intervención es un conjunto de principios y herramientas que aplican la automatización a cada cambio en la producción (sin personas involucradas), lo validan previamente con software o lo realizan con un mecanismo auditado y capaz de responder ante emergencias.
Acceso on demand
El acceso on demand (AoD) permite que Google reduzca los privilegios del personal reemplazando la membresía permanente por una apta.
Los miembros aptos de un rol no tienen acceso a sus privilegios. En su lugar, si un miembro de un rol apto requiere acceso, puede solicitar una membresía temporal, conocida como otorgamiento de AoD. Si otra persona autorizada lo aprueba, una concesión de AoD hace que el solicitante sea miembro del rol por un período limitado, por lo general, menos de un día.
El modelo de membresía apta permite que el personal solicite solo el subconjunto de acceso que necesita durante el tiempo que lo necesite. Conceptualmente, puedes considerar a la AoD como un sudo de producción con límite de tiempo, similar al comando sudo -u en Unix, que te permite ejecutar algunos comandos con los permisos elevados asociados con un usuario especificado. Sin embargo, a diferencia de Unix sudo, recibir una concesión de AoD requiere una justificación comercial y un MPA, y deja un registro de auditoría. Las concesiones de AoD también tienen un límite de tiempo.
Proteger los privilegios sensibles detrás de las membresías aptas significa que, incluso en casos poco probables de abuso de acceso, las cuentas solo pueden acceder a esos privilegios cuando hay una concesión activa. La adopción de proxies seguros elimina en gran medida la necesidad de dichos otorgamientos.
Supervisión de solicitudes de acceso
Si bien muchas áreas de producción de Google usan NoPe como práctica de reducción de acceso, las concesiones de AoD son muy raras para nuestros roles de producción más sensibles y solo se reservan para la respuesta ante emergencias. Además, cada evento activa una auditoría manual posterior. El objetivo de la auditoría es reducir la frecuencia de las concesiones de AoD en el futuro (por ejemplo, mediante el uso de estos eventos para motivar mejoras en las APIs de administración).
Google supervisa de forma continua las subvenciones de AoD y las acciones que se realizan mientras se mantienen en toda la empresa. Usamos los datos de supervisión en tiempo real para detectar posibles vulneraciones y, así, identificar áreas en las que se puede reducir aún más el acceso. Si ocurre un incidente, el registro de auditoría permite una respuesta rápida.
Autorización Binaria para Borg
Así como NoPe ayuda a proteger las rutas de acceso con privilegios, la Autorización binaria para Borg (BAB) ayuda a proteger la cadena de suministro de software de Google. BAB ayuda a garantizar que el software de producción y la configuración de los trabajos se revisen y aprueben antes de que se implementen, en especial cuando pueden acceder a datos sensibles. Los conceptos clave de BAB, que se diseñaron originalmente para la infraestructura de producción de Google, ahora se incluyen en una especificación abierta llamada Niveles de cadena de suministro para artefactos de software (SLSA).
La BAB ayuda a garantizar que el personal no pueda modificar el código fuente, ejecutar objetos binarios ni configurar trabajos sin revisión por pares, y que cualquier artefacto binario o configuración de software se compile de manera verificable a partir de un código fuente revisado por pares y verificado.
Si deseas obtener más información, consulta Autorización Binaria para Borg.
Cómo proteger máquinas de producción
Además de endurecer las rutas de acceso con privilegios y mantener la integridad de la cadena de suministro de software, Google protege las máquinas en las que se ejecutan los servicios de producción. En particular, implementamos lo siguiente:
Controles de acceso de shell: La mayoría del personal de Google no tiene acceso a la shell (por ejemplo, a través de SSH) a las máquinas de producción ni a las cargas de trabajo que se ejecutan en Borg, el sistema de administración de clústeres de Google. En cambio, las personas deben usar proxies seguros que requieran que otra persona autorizada revise y apruebe cada comando antes de que se ejecute.
Solo unos pocos equipos que trabajan en la infraestructura de bajo nivel retienen el acceso a la shell no unilateral para depurar los problemas más complejos en los que no es práctico usar proxies seguros. Un acceso es no unilateral si requiere la autorización de uno o más miembros del personal autorizado adicional. Google hace una excepción en la que se permite el acceso unilateral a la shell: para garantizar que Google tenga una forma de salir de situaciones de bloqueo.
Controles de acceso físico: Las máquinas necesitan un mantenimiento físico regular para que funcionen bien. Para garantizar que los técnicos del centro de datos solo accedan a las máquinas físicas en el contexto de un motivo comercial válido, Google usa controles de físico a lógico.
Controles de firmware y software del sistema: Google implementa un flujo de seguridad de inicio medido que se basa en una raíz de confianza de hardware. La raíz de confianza de hardware ayuda a garantizar la integridad del firmware de inicio y el software del sistema de cada máquina.
En el siguiente diagrama, se muestran los controles que ayudan a proteger una máquina en un centro de datos.
Controles de acceso de shell
SSH es una herramienta administrativa de código abierto que es popular por permitir un acceso amplio a los servidores basados en Linux. Sin controles de acceso a SSH, las cuentas con las credenciales correctas pueden obtener una shell que les permita ejecutar código arbitrario de una manera difícil de auditar.
Con el acceso de shell a un servicio de producción, la cuenta podría, por ejemplo, cambiar el comportamiento de una tarea en ejecución, extraer credenciales o usar credenciales para lograr un punto de entrada persistente en el entorno.
Para mitigar este riesgo, usamos el siguiente conjunto de controles que reemplaza el acceso SSH a las máquinas de producción por métodos alternativos y seguros:
- APIs estrechas: Para los equipos con flujos de trabajo bien definidos que antes requerían SSH, reemplazamos SSH por APIs auditables y definidas de forma estrecha.
- Proxies seguros para SSH: Para los equipos que requieren un acceso más flexible, los proxies seguros permiten que los comandos se autoricen y auditen de forma individual.
- MPA: Cuando los SRE necesitan acceso SSH de emergencia a una máquina, Google requiere una justificación comercial y una persona autorizada para aprobar el acceso. Se registran las transcripciones completas de la sesión de shell.
- Situaciones de bloqueo: La única excepción cuando se permite el acceso SSH unilateral. Se registran las transcripciones completas de la sesión de shell.
Estos controles equilibran la necesidad de acceso legítimo a la shell con el riesgo asociado con un acceso a la shell demasiado amplio.
Antecedentes: SSH en Google
En el pasado, Google usaba SSH para administrar sus máquinas. El desarrollo de Borg permitió que la mayoría del personal de Google dejara de requerir acceso directo a las máquinas de Linux que ejecutan sus objetos binarios, pero el acceso a la shell persistió por varios motivos:
- A veces, el personal requiere acceso directo a una máquina para depurar.
- El acceso a SSH es una herramienta de enseñanza valiosa para comprender las diferentes capas de abstracción.
- En situaciones de recuperación ante desastres imprevistas, es posible que las herramientas de nivel superior no estén disponibles.
Para equilibrar estos motivos y el riesgo de seguridad que implicaban, Google persiguió una serie de hitos para eliminar de forma incremental el riesgo de SSH y, luego, su uso.
Logro de la supervisión y el control de acceso centralizados
Google invirtió en un sistema central de supervisión y autorización de SSH conocido como autorización de supervisión basada en la identidad del host (HIBA). La HIBA proporciona visibilidad de cualquier uso de SSH y habilita la aplicación forzosa de políticas de autorización estrictas. Los intentos de SSH se registran, no solo por la máquina de destino, sino también por el proxy de BeyondCorp centralizado. Los comandos que ejecuta el shell se registran y se alimentan a las canalizaciones de detección de comportamiento malicioso. Sin embargo, la detección es inherentemente reactiva y vulnerable a la evasión y la ofuscación.
Eliminación del hito de acceso unilateral
Para la mayoría del personal, Google quitó el acceso a la shell (por ejemplo, a través de SSH) a las máquinas de producción o a las cargas de trabajo que se ejecutan en Borg. Sin embargo, los equipos de desarrollo pueden acceder a él en máquinas de prueba (por ejemplo, máquinas que se usan para calificar hardware o software de bajo nivel nuevos, pero que no ejecutan servicios de producción).
APIs estrechas
Algunos equipos de Google que históricamente dependían de SSH para ejecutar una cantidad limitada de comandos definidos con precisión (por ejemplo, en una guía) o para obtener datos cuya estructura es predecible, ahora usan APIs definidas de forma estricta que se ajustan al caso de uso específico y proporcionan datos estructurados.
Las APIs estrechas tienen una pequeña cantidad de métodos alineados con los recorridos comunes de los usuarios y abstraen los detalles de acceso de bajo nivel. En consecuencia, son la solución preferida de Google porque proporcionan la mejor seguridad y auditabilidad. Cuando los compilamos en la infraestructura de llamadas de procedimiento remoto (RPC) de Google, nos beneficiamos de décadas de inversión en seguridad y auditoría.
Proxies seguros para SSH
Algunos equipos de Google no pueden determinar los comandos que podrían necesitar con anticipación. En este caso, Google usa un daemon de ejecución de comandos que solo acepta solicitudes de ejecución de comandos arbitrarias de un proxy de confianza que ejecuta un equipo de seguridad. Esta tecnología es similar a la que se usa en los proxies seguros para NoPe.
Los proxies seguros para SSH son responsables de la autorización detallada de la ejecución de comandos y de la auditoría. La autorización se basa en el argumento y el entorno del comando, los parámetros de limitación de frecuencia, las justificaciones comerciales y la MPA. Este proceso de autorización habilita restricciones arbitrariamente precisas sobre los comandos que se pueden ejecutar siguiendo las prácticas recomendadas y los manuales de equipo. En condiciones de fallas inesperadas que no se capturan en los libros de jugadas existentes, el personal aún puede ejecutar los comandos de depuración necesarios después de que otra persona autorizada los haya aprobado.
MPA para SSH
Los pocos equipos restantes que trabajan en la infraestructura de bajo nivel retienen una forma no unilateral de acceso a la shell para depurar los problemas más complejos.
SSH en situaciones de bloqueo
Google hace una excepción cuando se permite el acceso unilateral a la shell para garantizar que pueda solucionar situaciones de bloqueo. Las claves SSH que se usan para este fin se generan con un proceso de auditoría distinto y se almacenan sin conexión en hardware resistente a la manipulación. Cuando se usan estas claves, se registran las transcripciones completas de la sesión de shell.
Controles de acceso físico
Los centros de datos de Google son un entorno complejo de servidores, dispositivos de herramientas de redes y sistemas de control que requieren una amplia variedad de roles y habilidades para administrar, mantener y operar.
Google implementa seis capas de controles físicos y muchos controles lógicos en las máquinas para ayudar a proteger las cargas de trabajo en el centro de datos. También defendemos un espacio entre las máquinas, al que llamamos espacio físico-lógico.
Los controles de físico a lógico proporcionan capas adicionales de defensa a través de controles que se denominan endurecimiento de la máquina, control de acceso basado en tareas y autodefensa del sistema. Los controles físicos a lógicos protegen contra un adversario que intenta aprovechar el acceso físico a una máquina y derivar a un ataque lógico en las cargas de trabajo de la máquina.
Para obtener más información, consulta Cómo Google protege el espacio físico-lógico en un centro de datos.
Controles de firmware y software del sistema
La postura de seguridad de una máquina de centro de datos se establece en el momento del inicio. El proceso de inicio de la máquina configura el hardware de la máquina y, luego, inicializa su sistema operativo, a la vez que mantiene la máquina segura para ejecutarse en el entorno de producción de Google.
En cada paso del proceso de inicio, Google implementa controles líderes en la industria para ayudar a aplicar el estado de inicio que esperamos y para mantener seguros los datos del cliente. Estos controles ayudan a garantizar que nuestras máquinas se inicien en el software previsto, lo que nos permite quitar las vulnerabilidades que podrían comprometer la postura de seguridad inicial de la máquina.
Para obtener más información, consulta Cómo Google aplica la integridad de inicio en las máquinas de producción.
Protección de las cargas de trabajo
De acuerdo con nuestra filosofía de confianza cero, Google también introdujo controles que ayudan a defenderse contra amenazas de movimiento lateral entre cargas de trabajo con diferentes requisitos de seguridad. La infraestructura de Google usa una jerarquía de cargas de trabajo llamada anillos de seguridad de cargas de trabajo (WSR). El WSR ayuda a garantizar que las cargas de trabajo críticas no se programen en las mismas máquinas que las cargas de trabajo menos seguras, a la vez que evita el impacto negativo en la utilización de recursos. WSR agrupa las cargas de trabajo en cuatro clases de sensibilidad: fundamentales, sensibles, endurecidas y no endurecidas, y trata de programarlas en diferentes grupos de máquinas.
En el siguiente diagrama, se muestra cómo el WSR agrupa y programa cargas de trabajo en máquinas básicas, de producción y de desarrollo.
Los WSR proporcionan una capa adicional de defensa contra la elevación de privilegios local mediante ataques de vulnerabilidad del kernel o ataques de canal lateral de la CPU. El WSR ayuda a garantizar que solo las cargas de trabajo con requisitos de seguridad similares se programen de forma conjunta en las mismas máquinas. Para implementar WSR, hacemos lo siguiente:
- Clasifica las cargas de trabajo según sus requisitos de seguridad. Cada clase se conoce como un anillo de carga de trabajo.
- Distribuye las máquinas físicas en varios grupos de máquinas que están aislados entre sí. En otras palabras, eliminamos las rutas de movimiento lateral entre los grupos.
- Aplica restricciones de programación para evitar que las cargas de trabajo con diferentes requisitos de seguridad se ejecuten en la misma máquina. Estas restricciones de programación mitigan el riesgo de compromiso a través de la elevación de privilegios local.
Por ejemplo, el WSR requiere que las cargas de trabajo fundamentales se ejecuten en máquinas dedicadas y que nunca se programen de forma conjunta con cargas de trabajo no fundamentales. Esta restricción proporciona un aislamiento sólido de las cargas de trabajo menos seguras.
Métodos para aislar cargas de trabajo
El software del sistema moderno es complejo, y los investigadores de seguridad descubren periódicamente vulnerabilidades de escalamiento de privilegios locales, como exploits de día cero del kernel o nuevos ataques de canal lateral de la CPU. El WSR, que se presentó por primera vez en USENIX ;login:, permite que Google reduzca el riesgo asociado con la colocalización de cargas de trabajo y, al mismo tiempo, mantenga una alta utilización de recursos.
De forma predeterminada, Borg usa límites de procesos a nivel del SO para aislar contenedores. Estos procesos ofrecen un límite de aislamiento más débil que las máquinas virtuales que usan virtualización basada en hardware. Por lo general, este aislamiento más débil es una buena compensación entre eficiencia y seguridad para entornos multiusuario que ejecutan cargas de trabajo confiables. Una carga de trabajo confiable es una carga de trabajo en la que el objeto binario y la configuración se compilaron de manera verificable a partir de código revisado por pares de procedencia certificada. Las cargas de trabajo de confianza no procesan datos no confiables arbitrarios. Algunos ejemplos de procesamiento de datos no confiables son alojar código de terceros o codificar videos.
Google logra la confianza en nuestros objetos binarios con el uso de BAB. Sin embargo, la BAB no es suficiente para garantizar la integridad de las cargas de trabajo que procesan datos no confiables. Además de la BAB, esas cargas de trabajo también deben ejecutarse dentro de una zona de pruebas. Una zona de pruebas es un entorno limitado, como gVisor, que permite que un objeto binario se ejecute de forma segura. Tanto la BAB como las zonas de pruebas tienen limitaciones.
La BAB es un control sólido para productos maduros, pero podría reducir la velocidad durante las primeras etapas del desarrollo de sistemas nuevos y cuando se ejecutan experimentos sin datos sensibles (por ejemplo, optimizar la codificación de datos que ya son públicos). Esta limitación significa que algunas cargas de trabajo siempre deben ejecutarse sin BAB. Estas cargas de trabajo tienen, de forma inherente, un mayor riesgo de elevación de privilegios locales (por ejemplo, explotando una vulnerabilidad del kernel para obtener acceso raíz local en una máquina).
La creación de zonas de pruebas para cargas de trabajo no confiables también mitiga el riesgo de seguridad, pero a costa de un mayor uso de procesamiento y memoria. La eficiencia puede disminuir en un porcentaje de dos dígitos, según la carga de trabajo y el tipo de zona de pruebas. Para ver un ejemplo de los impactos en el rendimiento de una carga de trabajo en zona de pruebas, consulta las comparativas detalladas en la Guía de rendimiento de gVisor. El WSR nos permite abordar las limitaciones de eficiencia que se derivan del aislamiento de las cargas de trabajo.
Anillos de cargas de trabajo
Google define cuatro clases de cargas de trabajo según sus requisitos de seguridad: básicas, sensibles, endurecidas y no endurecidas. En la siguiente tabla, se describen con más detalle.
| Anillo de carga de trabajo | Descripción |
|---|---|
| Básica | Cargas de trabajo que son fundamentales para la seguridad de Google, como los servicios de administración de identidades y accesos. Las cargas de trabajo fundamentales tienen los requisitos de seguridad más altos y, con frecuencia, intercambian eficiencia por mayor seguridad y confiabilidad. |
| Sensible | Cargas de trabajo que pueden causar interrupciones generalizadas o que tienen acceso a datos sensibles específicos del producto, como datos de usuarios o clientes. |
| Endurecimiento | Admite cargas de trabajo que no son fundamentales para la seguridad, pero que adoptaron BAB o están en zona de pruebas, de modo que representen poco riesgo para las cargas de trabajo vecinas. |
| No endurecido | Todas las demás cargas de trabajo, incluidas las que ejecutan código no confiable |
En Google, clasificamos las cargas de trabajo críticas que admiten productos específicos como sensibles, mientras que las cargas de trabajo fundamentales son aquellas que podrían afectar a todos los productos.
A diferencia de las cargas de trabajo básicas y sensibles, podemos clasificar cualquier carga de trabajo como endurecida únicamente en función de los controles adoptados y el tipo de entrada que procesa. Con las cargas de trabajo endurecidas, lo que más nos preocupa es su impacto en otras cargas de trabajo, por lo que las soluciones de endurecimiento pueden incluir la zona de pruebas.
Grupos de máquinas
Para evitar la programación conjunta de servicios sensibles con cargas de trabajo que son menos confiables (por ejemplo, las que procesan datos no confiables sin una zona de pruebas), debemos ejecutarlas en grupos aislados de máquinas. El aislamiento de máquinas facilita la comprensión de las invariantes de seguridad, pero cada grupo de máquinas adicional introduce compensaciones en el uso de recursos y la capacidad de mantenimiento.
El aislamiento de máquinas genera un menor uso de recursos físicos, ya que garantizar que los grupos de máquinas se utilicen por completo se vuelve más difícil a medida que agregamos más grupos. El costo de eficiencia puede ser significativo cuando hay varios grupos de máquinas grandes y aislados.
A medida que la huella de recursos de las cargas de trabajo fluctúa en cada grupo, el aislamiento estricto agrega sobrecarga de administración para reequilibrar y reutilizar las máquinas de forma periódica entre los grupos. Este reequilibrio requiere agotar todas las cargas de trabajo de una máquina, reiniciarla y realizar nuestro proceso de limpieza de máquinas más pesado que ayuda a garantizar la autenticidad y la integridad del firmware.
Estas consideraciones significan que la implementación del aislamiento de máquinas de Google debe proporcionar formas de optimizar el uso de recursos físicos y, al mismo tiempo, defender las cargas de trabajo fundamentales y sensibles contra los adversarios.
En Kubernetes, este enfoque se conoce como aislamiento de nodos. Los nodos de Kubernetes se pueden asignar a máquinas físicas o virtuales. En este documento, nos enfocaremos en las máquinas físicas. Además, los productos de Google Cloud, como Compute Engine, ofrecen tenancies únicas para proporcionar aislamiento de máquinas físicas.
Restricciones de programación de cargas de trabajo
Google aprovisiona máquinas en tres tipos de grupos aislados: máquinas básicas, máquinas de producción y máquinas de desarrollo. Google opera varios grupos aislados que alojan cargas de trabajo fundamentales y sensibles, pero, para simplificar, en este documento, cada uno se presenta como un grupo.
Para ofrecer la protección más eficaz, implementamos las siguientes restricciones de programación para WSR:
- Las cargas de trabajo básicas solo se pueden ejecutar en máquinas básicas.
- Las cargas de trabajo sensibles solo se pueden ejecutar en máquinas de producción.
- Las cargas de trabajo no endurecidas solo se pueden ejecutar en máquinas de desarrollo.
- Las cargas de trabajo endurecidas se pueden ejecutar en máquinas de producción o de desarrollo, con preferencia por las máquinas de producción.
En el siguiente diagrama, se muestran las restricciones de programación.
En este diagrama, los límites de aislamiento separan diferentes clases de cargas de trabajo entre los grupos de máquinas y dentro de ellos. Las cargas de trabajo fundamentales son los únicos inquilinos de máquinas fundamentales dedicadas. La autorización binaria o la zona de pruebas para cargas de trabajo que se ejecutan en máquinas de producción ayudan a evitar ataques de elevación de privilegios locales. En las máquinas de desarrollo, existe un riesgo residual de que una carga de trabajo no endurecida pueda comprometer otra, pero el compromiso se limita a las máquinas de desarrollo porque las cargas de trabajo endurecidas no pueden crear trabajos nuevos.
Las cargas de trabajo endurecidas se programan en máquinas de producción o de desarrollo según la disponibilidad. Permitir la programación en varios grupos puede parecer contrario a la intuición, pero es esencial para aliviar la disminución de la utilización causada por las restricciones de programación. Las cargas de trabajo endurecidas cubren las brechas que se generan cuando se aíslan trabajos sensibles y no endurecidos. Además, cuanto mayor sea la huella de recursos endurecida, más fluctuaciones en el uso de recursos de las otras dos clases se pueden admitir sin necesidad de realizar movimientos costosos de máquinas entre los anillos.
En el siguiente diagrama, se muestran las restricciones de programación que se imponen a diferentes clases de cargas de trabajo. Una carga de trabajo endurecida se puede ubicar en una máquina de producción o de desarrollo.
Cuando Google aísla las cargas de trabajo fundamentales en varios grupos fundamentales, cambia la eficiencia de los recursos por una mayor seguridad. Por fortuna, las cargas de trabajo fundamentales suelen tener una huella de recursos relativamente pequeña, y los grupos pequeños y aislados de máquinas dedicadas tienen un impacto insignificante en el uso general. Sin embargo, incluso con una automatización extensa, el mantenimiento de varios grupos de máquinas no es gratuito, por lo que evolucionamos constantemente nuestros diseños de máquinas para mejorar el aislamiento.
La WSR proporciona una garantía sólida de que las cargas de trabajo no fundamentales nunca se pueden ejecutar en máquinas fundamentales. Las máquinas fundamentales están protegidas contra el movimiento lateral, ya que solo las cargas de trabajo fundamentales se pueden ejecutar en esas máquinas.
Resumen de los controles
Google usa varios controles en toda su infraestructura para ayudar a proteger los servicios, las máquinas y las cargas de trabajo de producción. Los controles incluyen lo siguiente:
- Controles de acceso administrativo y BAB para servicios de producción
- Controles de acceso de shell, controles de acceso físico y controles de firmware y software del sistema para máquinas de producción
- WSR para diferentes clases de cargas de trabajo
Juntos, estos controles aplican restricciones que ayudan a proteger a los usuarios y clientes de Google, así como sus datos. En el siguiente diagrama, se ilustra cómo los controles trabajan en conjunto para respaldar la postura de seguridad de Google.
¿Qué sigue?
- Para obtener más información sobre los controles de seguridad en la infraestructura de Google, consulta la descripción general del diseño de seguridad de la infraestructura de Google.
- Para obtener más información sobre la cultura de seguridad de Google, consulta Compila sistemas seguros y confiables (libro de O'Reilly).
- Para obtener más información sobre la producción sin intervención manual, consulta la presentación de SREcon.
Autores: Michael Czapiński and Kevin Plybon