Este contenido se actualizó por última vez en junio 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.
Google gestiona una infraestructura de computación distribuida, multicliente y a escala mundial para ofrecer productos y servicios a miles de millones de personas de todo el mundo. Esta infraestructura debe equilibrar las prioridades contrapuestas de seguridad, fiabilidad, resiliencia, eficiencia, velocidad de desarrollo, capacidad de depuración y más.
En este documento se describen algunos de los mecanismos que usamos para mantener una postura de seguridad líder en el sector para los servicios que se ejecutan en el entorno de producción de Google. Estos servicios abarcan todo el espectro de sensibilidad de seguridad, desde experimentos de desarrollo que no tienen acceso a ningún dato sensible hasta infraestructuras de identidad críticas. Estos servicios completan tareas como el procesamiento de datos de usuario, la gestión de lanzamientos de software y el aprovisionamiento y la gestió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 tres capas clave de nuestra infraestructura:
- Servicios de producción, que incluyen los servicios más importantes para la seguridad (también conocidos como servicios básicos)
- 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 empresariales legítimos (por ejemplo, para realizar tareas de mantenimiento) y para protegernos frente a riesgos internos y vulneraciones de cuentas de personal. Estos controles proporcionan una protección de defensa en profundidad adicional que complementa los controles de seguridad de la infraestructura que ayudan a evitar que se vulnere la cuenta.
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 fundamentales, 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 necesitar más tiempo para implementar las últimas recomendaciones. Gracias a una cultura de mejora continua, los equipos de ingeniería de fiabilidad del sitio (SRE) y de seguridad de Google adaptan constantemente los controles de seguridad para hacer frente a los cambios en el panorama de las amenazas.
Proteger 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 fin empresarial legítimo, como el mantenimiento. Hay dos formas principales de acceder a los servicios que se ejecutan en el entorno de producción: mediante acceso administrativo y mediante la cadena de suministro de software.
En la siguiente lista se describen los controles que ayudan a proteger cada vía de acceso.
Controles de acceso de administrador: los servicios de producción necesitan un mantenimiento periódico (por ejemplo, lanzamientos de binarios o de configuraciones). En Google, nuestro objetivo es que estas operaciones se realicen mediante la automatización, proxies seguros o acceso de emergencia auditado, siguiendo la filosofía de Zero Touch Prod. El conjunto de controles que elimina el acceso humano a los recursos de producción se llama No Persons (NoPe). NoPe ofrece a Google la flexibilidad de implementar controles de acceso basados en la sensibilidad de un servicio de producción y su preparación para lograr una postura aún más sólida mediante la mejora continua.
Por ejemplo, Google no permite el acceso unilateral a los servicios básicos. Incluso el acceso de emergencia requiere la aprobación de otro miembro del 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 básicos, ejecutan archivos binarios y configuraciones de tareas 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 mediante 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, nos aseguramos de que ningún miembro del personal tenga acceso unilateral, ni siquiera en caso de emergencia, a los servicios básicos, y de que cualquier acceso privilegiado que reciba tenga un ámbito y una duración bien definidos. El acceso privilegiado es un nivel de acceso superior que se concede al personal para administrar servicios de producción críticos en circunstancias únicas que no se pueden abordar mediante la automatización. 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, e infraestructuras internas como Borg y Spanner, se han configurado para usar los niveles más altos de NoPe y BAB. Además, trabajamos continuamente para que los propietarios de servicios de producción puedan adoptar 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 eliminar los datos que posee el rol de producción, así como 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 pertenencia permanente a roles de producción conlleva el riesgo de que se produzcan consecuencias no deseadas en la producción y 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 eliminar el acceso por completo podría no ser una estrategia viable.
El paquete NoPe ofrece una forma de configurar el acceso que equilibra las demandas contrapuestas de empoderar a los equipos y mantener seguros los sistemas de producción. Con NoPe, el personal de Google se encuentra con 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 un aprobador y una justificación: un control llamado autorización de varios grupos (MPA) ayuda a asegurar que el personal de Google no pueda acceder a los servicios de producción sin una justificación empresarial 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 y SRE de Google consideren arriesgado (por ejemplo, desactivar un servicio o acceder a datos o eliminarlos) también requiere MPA.
- No se asignan roles de producción permanentes: un control llamado acceso bajo demanda (AoD) requiere que el personal solicite una membresía temporal, en lugar de permitir que las cuentas del personal tengan privilegios de acceso en todo momento. Este control ayuda a asegurar que los privilegios elevados solo se concedan temporalmente y por motivos específicos.
- Monitorizació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 enviar estas solicitudes en el futuro mediante la mejora continua de las APIs administrativas. El acceso a los servicios de producción solo debe reservarse para situaciones de emergencia. En el caso de los servicios básicos, el número de situaciones en las que se concede acceso es tan bajo que un equipo de seguridad audita cada acceso concedido para confirmar su validez.
En las siguientes secciones se explica cada control en detalle.
Autorización multiparte para NoPe
La MPA requiere que otro miembro autorizado del personal de Google apruebe una solicitud de acceso.
En el caso de las solicitudes de acceso a servicios suficientemente sensibles, 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 uso inadecuado del 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 pormenorizadas basadas en reglas para proporcionar restricciones de 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 puedan afectar negativamente a la seguridad o la fiabilidad (por ejemplo, comandos que eliminen archivos). Las políticas también pueden permitir que se ejecuten determinados comandos seguros (por ejemplo, comandos que muestran la utilización de recursos) sin necesidad de aprobación. Esta flexibilidad es fundamental para minimizar el trabajo repetitivo.
En los casos de abuso de acceso, las cuentas siguen estando 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 garantizan que todos los cambios en producción se realicen mediante automatización (sin intervención humana), se validen previamente mediante software o se hagan mediante un mecanismo de emergencia auditado.
Acceso bajo demanda
El acceso bajo demanda (AoD) permite a Google reducir los privilegios del personal sustituyendo la pertenencia permanente por la pertenencia apta.
Los miembros aptos de un rol no tienen acceso a sus privilegios. En su lugar, si un miembro de un rol apto necesita acceso, puede solicitar una membresía temporal, conocida como concesión de AoD. Si otro usuario autorizado aprueba la concesión de AoD, el solicitante se convertirá en miembro del rol durante un periodo limitado, normalmente menos de un día.
El modelo de suscripción apta permite que el personal solicite solo el subconjunto de acceso que necesita durante el tiempo que lo necesite. Conceptualmente, puedes considerar AoD como una producción limitada en el tiempo sudo, similar al comando sudo -u de Unix, que te permite ejecutar algunos comandos con los permisos elevados asociados a un usuario específico. Sin embargo, a diferencia de Unix sudo, para recibir una concesión de AoD se requiere una justificación empresarial y un MPA, y se deja un registro de auditoría. Las subvenciones de AoD también tienen un plazo limitado.
Proteger los privilegios sensibles con las suscripciones 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 conceder estos permisos.
Monitorización de solicitudes de acceso
Aunque en muchas áreas de producción de Google se usa NoPe como práctica para reducir el acceso, las concesiones de AoD son extremadamente raras en nuestros roles de producción más sensibles y solo se reservan para situaciones de emergencia. Además, cada evento activa una auditoría manual a posteriori. El objetivo de la auditoría es reducir la frecuencia de las concesiones de AoD en el futuro (por ejemplo, usando estos eventos para motivar mejoras en las APIs administrativas).
Google monitoriza continuamente las concesiones de AoD y las acciones que se llevan a cabo mientras se mantienen esas concesiones en toda la empresa. Usamos los datos de monitorización en tiempo real para detectar posibles vulneraciones e identificar áreas en las que se puede reducir aún más el acceso. Si se produce un incidente, el registro de auditoría permite responder rápidamente.
Autorización binaria para Borg
Del mismo modo que NoPe ayuda a proteger las rutas de acceso privilegiado, la autorización binaria para Borg (BAB) ayuda a proteger la cadena de suministro de software de Google. BAB ayuda a asegurarse de que el software de producción y las configuraciones de los trabajos se revisen y aprueben antes de desplegarse, sobre todo 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 la cadena de suministro para artefactos de software (SLSA).
BAB ayuda a garantizar que el personal no pueda modificar el código fuente, ejecutar archivos binarios ni configurar tareas sin una revisión por parte de otro miembro del equipo, y que cualquier artefacto binario o configuración de software se compile de forma verificable a partir de código fuente verificado y revisado por otro miembro del equipo.
Para obtener más información, consulta el artículo Autorización binaria para Borg.
Proteger las máquinas de producción
Además de reforzar las rutas de acceso privilegiado 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 concreto, implementamos lo siguiente:
Controles de acceso a shell: la mayoría del personal de Google no tiene acceso a 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 gestión de clústeres de Google. En su lugar, 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 infraestructuras de bajo nivel conservan el acceso a shell no unilateral para poder 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 varios miembros del personal autorizado. Google hace una excepción en la que se permite el acceso unilateral a la shell: para asegurarse de que Google tiene una forma de salir de situaciones de bloqueo.
Controles de acceso físico: las máquinas necesitan un mantenimiento físico periódico para que funcionen correctamente. Para asegurarse de que los técnicos de los centros de datos solo accedan a las máquinas físicas por motivos empresariales válidos, Google utiliza controles de acceso físico a lógico.
Controles de firmware y software del sistema: Google implementa un flujo de seguridad de arranque medido que se basa en una raíz de confianza de hardware. La raíz de confianza de hardware ayuda a asegurar la integridad del firmware de arranque y del 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 a Shell
SSH es una herramienta administrativa de código abierto que se usa con frecuencia para permitir un acceso amplio a servidores basados en Linux. Si no se controla el acceso SSH, las cuentas con las credenciales adecuadas pueden obtener un shell que les permita ejecutar código arbitrario de una forma difícil de auditar.
Con acceso a la shell de 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 conseguir una posición persistente en el entorno.
Para mitigar este riesgo, usamos el siguiente conjunto de controles, que sustituye el acceso SSH a las máquinas de producción por métodos alternativos seguros:
- APIs específicas: para los equipos con flujos de trabajo bien definidos que antes requerían SSH, sustituimos SSH por APIs auditables y definidas de forma específica.
- Proxies seguros para SSH: para los equipos que requieren un acceso más flexible, los proxies seguros permiten autorizar y auditar los comandos de forma individual.
- MPA: cuando los ingenieros de fiabilidad de sitios necesitan acceso SSH de emergencia a una máquina, Google requiere una justificación empresarial y que una persona autorizada apruebe el acceso. Se registran las transcripciones completas de las sesiones de shell.
- Situaciones de bloqueo: la única excepción en la que se permite el acceso SSH unilateral. Se registran las transcripciones completas de las sesiones de shell.
Estos controles equilibran la necesidad de un acceso a shell legítimo con el riesgo asociado a un acceso a shell demasiado amplio.
Información general: SSH en Google
Antes, Google usaba SSH para administrar sus máquinas. El desarrollo de Borg permitió que la mayoría del personal de Google dejara de necesitar acceso directo a las máquinas Linux que ejecutan sus archivos binarios, pero el acceso a shell persistió por varios motivos:
- A veces, el personal necesita acceso directo a una máquina para depurar errores.
- El acceso SSH es una herramienta de enseñanza valiosa para comprender las distintas capas de abstracción.
- En situaciones de recuperación tras desastres imprevistas, es posible que no haya herramientas de nivel superior disponibles.
Para encontrar el equilibrio entre estos motivos y el riesgo de seguridad que suponían, Google llevó a cabo una serie de hitos para eliminar gradualmente el riesgo de SSH y, posteriormente, su uso.
Hito de monitorización y control de acceso centralizados
Google ha invertido en un sistema central de monitorización y autorización SSH conocido como autorización de monitorización basada en la identidad del host (HIBA). HIBA proporciona visibilidad sobre cualquier uso de SSH y permite aplicar políticas de autorización estrictas. Los intentos de SSH se registran no solo en la máquina de destino, sino también en el proxy de BeyondCorp centralizado. Los comandos ejecutados por el shell se registran y se introducen en las canalizaciones de detección de comportamientos maliciosos. Sin embargo, la detección es inherentemente reactiva y vulnerable a la evasión y la ofuscación.
Eliminar el hito de acceso unilateral
En el caso de la mayoría del personal, Google ha eliminado el acceso a 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 seguir accediendo a ella en máquinas de prueba (por ejemplo, máquinas que se usan para probar hardware nuevo o software de bajo nivel, pero no para ejecutar servicios de producción).
APIs específicas
Algunos equipos de Google que históricamente dependían de SSH para ejecutar un número limitado de comandos definidos con precisión (por ejemplo, en un playbook) u obtener datos cuya estructura es predecible ahora usan APIs definidas de forma precisa que sirven para el caso de uso específico y proporcionan datos estructurados.
Las APIs específicas tienen un número reducido de métodos alineados con los recorridos de usuario habituales y abstraen los detalles de acceso de bajo nivel. Por lo tanto, son la solución preferida de Google porque ofrecen la mejor seguridad y auditabilidad. Al desarrollarlos en la infraestructura de llamadas a procedimientos remotos (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 pueden necesitar con antelación. En este caso, Google usa un daemon que ejecuta comandos y que solo acepta solicitudes de ejecución de comandos arbitrarios 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 de NoPe.
Los proxies seguros para SSH se encargan 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 empresariales y el MPA. Este proceso de autorización permite aplicar restricciones arbitrariamente precisas sobre los comandos que se pueden ejecutar siguiendo los manuales de procedimientos y las prácticas recomendadas del equipo. En caso de fallos inesperados que no se hayan registrado en los manuales de procedimientos, el personal puede ejecutar los comandos de depuración necesarios después de que otra persona autorizada los haya aprobado.
MPA para SSH
Los pocos equipos que quedan y que trabajan en la infraestructura de bajo nivel conservan 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 en la que se permite el acceso unilateral a la shell para asegurarse de que Google puede solucionar situaciones de bloqueo. Las claves SSH que se usan para este fin se generan con un proceso auditable distinto y se almacenan sin conexión en hardware resistente a manipulaciones. Cuando se usan estas claves, se registran 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 red y sistemas de control que requieren una amplia gama de funciones y habilidades para gestionarlos, mantenerlos y operarlos.
Google implementa seis capas de controles físicos y muchos controles lógicos en las propias máquinas para proteger las cargas de trabajo en el centro de datos. También protegemos el espacio entre las máquinas, al que llamamos espacio físico y lógico.
Los controles físicos a lógicos proporcionan capas de defensa adicionales mediante controles denominados protección de la máquina, control de acceso basado en tareas y autodefensa del sistema. Los controles físicos y lógicos protegen frente a un adversario que intenta aprovechar el acceso físico a una máquina y pasar a un ataque lógico en las cargas de trabajo de la máquina.
Para obtener más información, consulta Cómo protege Google el espacio físico y lógico de un centro de datos.
Controles de firmware y software del sistema
La postura de seguridad de una máquina de un centro de datos se establece en el momento del arranque. El proceso de arranque de la máquina configura el hardware de la máquina e inicializa su sistema operativo, al tiempo que mantiene la seguridad de la máquina para que se ejecute en el entorno de producción de Google.
En cada paso del proceso de arranque, Google implementa controles líderes del sector para ayudar a aplicar el estado de arranque que esperamos y proteger los datos de los clientes. Estos controles ayudan a asegurar que nuestras máquinas se inicien con el software previsto, lo que nos permite eliminar las vulnerabilidades que podrían poner en peligro la postura de seguridad inicial de la máquina.
Para obtener más información, consulta el artículo sobre cómo aplica Google la integridad del arranque en máquinas de producción.
Protección de cargas de trabajo
De acuerdo con nuestra filosofía de confianza cero, Google también ha introducido controles que ayudan a protegerse frente a las 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 denominada anillos de seguridad de cargas de trabajo (WSR). 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, al tiempo que evita que se vea afectada la utilización de los recursos. WSR agrupa las cargas de trabajo en cuatro clases de sensibilidad (básica, sensible, reforzada y no reforzada) e intenta programarlas en diferentes grupos de máquinas.
En el siguiente diagrama se muestra cómo WSR agrupa y programa las cargas de trabajo en máquinas de producción, desarrollo y fundamentales.
WSR proporciona una capa adicional de defensa frente a la apropiación de privilegios local mediante ataques de vulnerabilidad del kernel o ataques de canal lateral de la CPU. WSR ayuda a asegurar que solo las cargas de trabajo con requisitos de seguridad similares se programen conjuntamente 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 anillo de carga de trabajo.
- Distribuir las máquinas físicas en varios grupos de máquinas aislados entre sí. En otras palabras, eliminamos las rutas de movimiento lateral entre 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 reducen el riesgo de que se produzca una vulneración mediante la apropiación de privilegios local.
Por ejemplo, WSR requiere que las cargas de trabajo fundamentales se ejecuten en máquinas dedicadas y que nunca se programen conjuntamente 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 de los sistemas modernos es complejo y los investigadores de seguridad descubren periódicamente vulnerabilidades de escalada de privilegios locales, como exploits de día cero del kernel o nuevos ataques de canal lateral de la CPU. WSR, que se introdujo por primera vez en USENIX ;login:, permite a Google reducir el riesgo asociado a la colocación conjunta de cargas de trabajo y, al mismo tiempo, mantener una alta utilización de los recursos.
De forma predeterminada, Borg usa límites de procesos a nivel de SO para aislar los contenedores. Estos procesos ofrecen un límite de aislamiento más débil que las máquinas virtuales que usan la virtualización basada en hardware. Este aislamiento más débil suele ser un buen equilibrio entre eficiencia y seguridad para los entornos multiinquilino que ejecutan cargas de trabajo de confianza. Una carga de trabajo de confianza es una carga de trabajo en la que el archivo binario y la configuración se han compilado de forma verificable a partir de código revisado por pares de procedencia certificada. Las cargas de trabajo de confianza no procesan datos arbitrarios que no sean de confianza. Entre los ejemplos de tratamiento de datos no fiables se incluyen el alojamiento de código de terceros o la codificación de vídeos.
Google genera confianza en nuestros archivos binarios mediante BAB. Sin embargo, BAB no es suficiente para asegurar la integridad de las cargas de trabajo que procesan datos no fiables. Además de BAB, estas cargas de trabajo también deben ejecutarse en un sandbox. Un entorno aislado es un entorno restringido, como gVisor, que permite que un archivo binario se ejecute de forma segura. Tanto BAB como los entornos de pruebas tienen limitaciones.
BAB es un control eficaz para productos consolidados, pero puede reducir la velocidad durante las primeras fases del desarrollo de nuevos sistemas y al realizar experimentos sin datos sensibles (por ejemplo, al optimizar la codificación de datos que ya son públicos). Esta limitación implica que algunas cargas de trabajo siempre deben ejecutarse sin BAB. Estas cargas de trabajo tienen un riesgo inherente de escalada de privilegios local (por ejemplo, al aprovechar una vulnerabilidad del kernel para obtener acceso root local en una máquina).
El aislamiento en un espacio aislado de las cargas de trabajo no fiables también reduce el riesgo de seguridad, pero a costa de un mayor uso de la computación y la memoria. La eficiencia puede reducirse en un porcentaje de dos dígitos, en función de la carga de trabajo y del tipo de sandbox. Para ver un ejemplo de los efectos en el rendimiento de una carga de trabajo en un espacio aislado, consulta las comparativas detalladas en la guía de rendimiento de gVisor. WSR nos permite abordar las limitaciones de eficiencia que se derivan del aislamiento de las cargas de trabajo.
Anillos de carga de trabajo
Google define cuatro clases de cargas de trabajo según sus requisitos de seguridad: básicas, sensibles, reforzadas y no reforzadas. En la siguiente tabla se describen con más detalle.
| Workload ring | Descripción |
|---|---|
| Foundational | Cargas de trabajo críticas para la seguridad de Google, como los servicios de gestión de identidades y accesos. Las cargas de trabajo fundamentales tienen los requisitos de seguridad más exigentes y suelen sacrificar la eficiencia para aumentar la seguridad y la fiabilidad. |
| Sensible | Cargas de trabajo que pueden provocar interrupciones generalizadas o que tienen acceso a datos sensibles específicos de un producto, como datos de usuarios o clientes. |
| Servicio endurecido | Admite cargas de trabajo que no sean críticas para la seguridad, pero que hayan adoptado BAB o estén en un espacio aislado, de modo que supongan poco riesgo para las cargas de trabajo vecinas. |
| Sin endurecer | Todas las demás cargas de trabajo, incluidas las que ejecutan código que no es de confianza. |
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 los elementos fundamentales y sensibles, podemos clasificar cualquier carga de trabajo como protegida basándonos exclusivamente en los controles adoptados y en el tipo de entrada que procesa. En el caso de las cargas de trabajo reforzadas, nos preocupa principalmente su impacto en otras cargas de trabajo, por lo que las soluciones de refuerzo pueden incluir el uso de entornos de pruebas.
Grupos de máquinas
Para evitar que se programen servicios sensibles junto con cargas de trabajo que no sean de confianza (por ejemplo, las que procesan datos no fiables sin un espacio aislado), debemos ejecutarlos en grupos de máquinas aislados. El aislamiento de máquinas facilita la comprensión de las invariantes de seguridad, pero cada grupo de máquinas adicional conlleva una serie de ventajas e inconvenientes en cuanto al uso de recursos y el mantenimiento.
El aislamiento de las máquinas conlleva una menor utilización de los recursos físicos, ya que resulta más difícil asegurarse de que los grupos de máquinas se utilicen por completo a medida que añadimos más grupos. El coste de eficiencia puede ser significativo cuando hay varios grupos de máquinas grandes y aislados.
Como el uso de recursos de las cargas de trabajo fluctúa en cada grupo, el aislamiento estricto añade una sobrecarga de gestión para reequilibrar y reutilizar periódicamente las máquinas entre los grupos. Para ello, es necesario vaciar todas las cargas de trabajo de una máquina, reiniciar la máquina y llevar a cabo nuestro proceso de saneamiento de máquinas más pesado, que ayuda a asegurar la autenticidad e integridad del firmware.
Estas consideraciones implican que la implementación del aislamiento de máquinas de Google debe proporcionar formas de optimizar la utilización de los recursos físicos y, al mismo tiempo, proteger las cargas de trabajo básicas y sensibles frente a 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 centraremos en las máquinas físicas. Además, Google Cloud productos como Compute Engine ofrecen la opción de único cliente 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 varias agrupaciones aisladas que alojan cargas de trabajo básicas y sensibles, pero en este documento se presentan como una sola agrupación para simplificarlo.
Para ofrecer la protección más eficaz, aplicamos las siguientes restricciones de programación para la respuesta de seguridad de sitios web:
- Las cargas de trabajo fundamentales solo se pueden ejecutar en máquinas fundamentales.
- Las cargas de trabajo sensibles solo se pueden ejecutar en máquinas de producción.
- Las cargas de trabajo no protegidas solo se pueden ejecutar en máquinas de desarrollo.
- Las cargas de trabajo protegidas se pueden ejecutar en máquinas de producción o de desarrollo, aunque se recomienda usar 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 tanto entre grupos de máquinas como dentro de ellos. Las cargas de trabajo fundamentales son los únicos inquilinos de las máquinas fundamentales dedicadas. La autorización binaria o el aislamiento de las cargas de trabajo que se ejecutan en máquinas de producción ayudan a evitar ataques de apropiación de privilegios locales. En los ordenadores de desarrollo, existe un riesgo residual de que una carga de trabajo sin protección pueda poner en peligro otra carga de trabajo, pero el riesgo se limita a los ordenadores de desarrollo, ya que las cargas de trabajo protegidas no pueden crear nuevos trabajos.
Las cargas de trabajo endurecidas se programan en máquinas de producción o de desarrollo en función de la disponibilidad. Permitir la programación en varias agrupaciones puede parecer contradictorio, pero es esencial para aliviar la reducción de la utilización causada por las restricciones de programación. Las cargas de trabajo reforzadas cubren las lagunas que se producen al aislar los trabajos sensibles y no reforzados. Además, cuanto mayor sea la huella de recursos protegidos, más fluctuaciones en el uso de recursos de las otras dos clases se podrán acomodar sin necesidad de realizar movimientos costosos de máquinas entre anillos.
En el siguiente diagrama se muestran las restricciones de programación que se imponen a las diferentes clases de cargas de trabajo. Una carga de trabajo reforzada puede estar ubicada en una máquina de producción o en una máquina de desarrollo.
Al aislar las cargas de trabajo fundamentales en varios grupos fundamentales, Google intercambia la eficiencia de los recursos por una mayor seguridad. Por suerte, las cargas de trabajo fundamentales suelen tener un tamaño de recursos relativamente pequeño, y los pequeños grupos aislados de máquinas dedicadas tienen un impacto insignificante en el uso general. Sin embargo, aunque tengamos una automatización exhaustiva, mantener varios grupos de máquinas no es gratuito, por lo que estamos en constante evolución de nuestros diseños de máquinas para mejorar el aislamiento.
WSR ofrece una garantía sólida de que las cargas de trabajo no fundamentales nunca podrán ejecutarse en máquinas fundamentales. Las máquinas de base están protegidas contra el movimiento lateral, ya que solo las cargas de trabajo de base pueden ejecutarse en esas máquinas.
Resumen de los controles
Google utiliza una serie de controles en toda su infraestructura para proteger los servicios, las máquinas y las cargas de trabajo de producción. Entre los controles se incluyen los siguientes:
- Controles de acceso de administrador y BAB para servicios de producción
- Controles de acceso a 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
En conjunto, estos controles aplican restricciones que ayudan a proteger a los usuarios y clientes de Google, así como sus datos. En el siguiente diagrama se muestra cómo interactúan los controles para reforzar la postura de seguridad de Google.
Siguientes pasos
- Para obtener más información sobre los controles de seguridad de la infraestructura de Google, consulta la descripción general del diseño de la seguridad de la infraestructura de Google.
- Para obtener información sobre la cultura de seguridad de Google, consulta el libro Building secure and reliable systems (O'Reilly).
- Para obtener más información sobre la producción de activación automática, consulta la presentación de SREcon.