Descripción general del diseño de seguridad de la infraestructura de Google

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.

Introducción

En este documento, se ofrece una descripción general de cómo se diseña la seguridad en la infraestructura técnica de Google. Está dirigido a ejecutivos de seguridad, arquitectos de seguridad y auditores.

En este documento, se describe lo siguiente:

  • La infraestructura técnica global de Google, que está diseñada para proporcionar seguridad en todo el ciclo de vida de procesamiento de la información en Google. Esta infraestructura ayuda a proporcionar lo siguiente:
    • Implementación segura de los servicios
    • Almacenamiento seguro de datos con protecciones de privacidad de usuarios finales
    • Comunicación segura entre servicios
    • Comunicación segura y privada con clientes a través de Internet
    • Operaciones seguras por parte de los ingenieros de Google
  • Cómo usamos esta infraestructura para crear servicios de Internet, incluidos servicios para consumidores (como la Búsqueda de Google, Gmail y Google Fotos) y servicios empresariales (como Google Workspace y Google Cloud)
  • Los productos y servicios de seguridad que son el resultado de las innovaciones que implementamos de manera interna para satisfacer nuestras necesidades de seguridad. Por ejemplo, BeyondCorp es el resultado directo de nuestra implementación interna del modelo de seguridad de confianza cero.

  • Cómo se diseña la seguridad de la infraestructura en capas progresivas. Estas capas incluyen lo siguiente:

En las secciones restantes de este documento, se describen las capas de seguridad.

Infraestructura de bajo nivel segura

En esta sección, se describe cómo protegemos las instalaciones físicas de nuestros centros de datos, el hardware en nuestros centros de datos y la pila de software que se ejecuta en el hardware.

Seguridad de las instalaciones físicas

Diseñamos y creamos nuestros propios centros de datos, que incorporan múltiples capas de seguridad física. El acceso a estos centros de datos está muy controlado. Usamos múltiples capas de seguridad física para proteger los pisos de nuestro centro de datos. Usamos identificación biométrica, detección de metales, cámaras, barreras para vehículos y sistemas de detección de intrusiones con láser. Para obtener más información, consulta Seguridad del centro de datos.

Dentro del centro de datos, implementamos controles adicionales para garantizar que se proteja y supervise el acceso físico a los servidores. Para obtener más información, consulta Cómo Google protege el espacio físico-lógico en un centro de datos.

También alojamos algunos servidores en centros de datos de terceros. En estos centros de datos, nos alineamos con los mismos estándares regulatorios que usamos en nuestros propios centros de datos. Nos aseguramos de que haya medidas de seguridad física controladas por Google y conectividad controlada por Google, además de las capas de seguridad que proporciona el operador del centro de datos. Por ejemplo, operamos sistemas de identificación biométrica, cámaras y detectores de metales que son independientes de las capas de seguridad que proporciona el operador del centro de datos.

A menos que se indique específicamente, los controles de seguridad de este documento se aplican a los centros de datos de Google y de terceros.

Diseño y origen del hardware

Los centros de datos de Google se componen de miles de servidores conectados a una red local. Diseñamos las placas de servidor y los equipos de herramientas de redes. Evaluamos a los distribuidores de componentes con los que trabajamos y seleccionamos los componentes cuidadosamente. Trabajamos con proveedores para auditar y validar las propiedades de seguridad que proporcionan los componentes. También diseñamos chips personalizados, incluido un chip de seguridad de hardware (llamado Titan), que implementamos en servidores, dispositivos y periféricos. Estos chips nos permiten identificar y autenticar los dispositivos legítimos de Google en el nivel del hardware y sirven como raíces de confianza del hardware.

Identidad de las máquinas y pila de arranque seguro

Los servidores de Google usan varias tecnologías para garantizar que inicien la pila de software correcta. 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.

Nos esforzamos por mejorar nuestros servidores de manera continua con cada generación sucesiva de hardware y para llevar estas mejoras al resto de la industria a través de la participación en procesos de estándares con Trusted Computing Group y DMTF.

Cada servidor del centro de datos tiene su propia identidad única. Esta identidad se puede vincular a las raíces de confianza de hardware y al software que inicia la máquina. Esta identidad se usa para autenticar llamadas a la API desde los servicios de administración de bajo nivel de la máquina y hacia ellos. Esta identidad también se usa para la autenticación mutua del servidor y la encriptación de transporte. Desarrollamos el sistema de Seguridad de transporte de la capa de la aplicación (ALTS) para proteger las comunicaciones de llamadas de procedimiento remoto (RPC) dentro de nuestra infraestructura. Estas identidades de máquina se pueden revocar de forma centralizada para responder a un incidente de seguridad. Además, sus certificados y claves se rotan con regularidad y se revocan los antiguos.

Desarrollamos sistemas automatizados para hacer lo siguiente:

  • Asegurarnos de que los servidores ejecutan versiones actualizadas de sus pilas de software (incluidos los parches de seguridad).
  • Detectar y diagnosticar problemas de hardware y software.
  • Garantizar la integridad de las máquinas y los periféricos con inicio verificado y certificación
  • Asegurarnos de que solo las máquinas que ejecutan el software y el firmware deseados puedan acceder a las credenciales que les permiten comunicarse en la red de producción.
  • Quitar o reparar las máquinas si no pasan la verificación de integridad o cuando ya no son necesarias

Para obtener más información sobre cómo protegemos nuestra pila de arranque y la integridad de la máquina, consulta Cómo Google aplica la integridad de inicio en las máquinas de producción y Certificación remota de máquinas desagregadas.

Implementación segura de servicios

Los servicios de Google son los objetos binarios de la aplicación que nuestros desarrolladores escriben y ejecutan en nuestra infraestructura. Algunos ejemplos de servicios de Google son servidores de Gmail, bases de datos de Spanner, servidores de Cloud Storage, transcodificadores de video de YouTube y VMs de Compute Engine que ejecutan aplicaciones de clientes. Para manejar la escala requerida de la carga de trabajo, miles de máquinas pueden ejecutar objetos binarios del mismo servicio. Un servicio de organización de clústeres, llamado Borg, controla los servicios que se ejecutan directamente en la infraestructura.

La infraestructura no supone ninguna confianza entre los servicios que se ejecutan en la infraestructura. Este modelo de confianza se conoce como un modelo de seguridad de confianza cero. Un modelo de seguridad de confianza cero significa que ningún dispositivo o usuario es de confianza de forma predeterminada, sin importar si está dentro o fuera de la red.

Debido a que la infraestructura está diseñada para ser de multiusuarios, los datos de nuestros clientes (consumidores, empresas y hasta nuestros propios datos) se distribuyen en la infraestructura compartida. Esta infraestructura está compuesta por decenas de miles de máquinas homogéneas. La infraestructura no segrega los datos del cliente en una sola máquina o conjunto de máquinas, excepto en circunstancias específicas, como cuando usas Google Cloud para aprovisionar VMs en nodos de usuario único para Compute Engine.

Google Cloud y Google Workspace cumplen con los requisitos reglamentarios sobre la residencia de datos. Para obtener más información sobre la residencia de los datos y Google Cloud, consulta Implementa requisitos de residencia de datos y soberanía. Para obtener más información sobre la residencia de los datos y Google Workspace, consulta Regiones de datos: Elige una ubicación geográfica para tus datos.

Integridad, identidad y aislamiento de los servicios

Para habilitar la comunicación entre servicios, las aplicaciones usan la autenticación y autorización criptográficas. La autenticación y la autorización proporcionan un control de acceso sólido a nivel de abstracción, además de un nivel de detalle que los administradores y los servicios pueden comprender.

Los servicios no dependen de la segmentación de red interna ni del firewall como mecanismo de seguridad principal. El filtrado de entrada y salida en varios puntos de nuestra red ayuda a evitar la falsificación de las identidades de IP. Este enfoque nos ayuda a maximizar el rendimiento y la disponibilidad de nuestra red. Para Google Cloud, puedes agregar mecanismos de seguridad adicionales, como los Controles del servicio de VPC y Cloud Interconnect.

Cada servicio que se ejecuta en la infraestructura tiene una identidad de cuenta de servicio asociada. Un servicio se proporciona con credenciales criptográficas que puede usar para demostrar su identidad a otros servicios cuando realiza o recibe RPC. Estas identidades se usan en las políticas de seguridad. Las políticas de seguridad garantizan que los clientes se comuniquen con el servidor deseado y que los servidores limiten los métodos y los datos a los que pueden acceder algunos clientes en particular.

Usamos varias técnicas de aislamiento y de zona de pruebas para proteger un servicio de otros servicios que se ejecutan en la misma máquina. Estas técnicas incluyen la separación de usuarios de Linux, las zonas de pruebas basadas en lenguajes (como la API de Sandboxed ) y basadas en kernel, el kernel de la aplicación para contenedores (como gVisor) y la virtualización basada en hardware. En general, usamos más capas de aislamiento para las cargas de trabajo con mayor riesgo. Las cargas de trabajo más riesgosas incluyen cargas de trabajo que procesan entradas no limpias de Internet. Por ejemplo, las cargas de trabajo más riesgosas incluyen ejecutar convertidores de archivos complejos en entradas no confiables o ejecutar código arbitrario como servicio para productos como Compute Engine.

Para obtener seguridad adicional, los servicios sensibles, como el servicio de organización de clústeres y algunos servicios de administración de claves, se ejecutan de forma exclusiva en máquinas dedicadas.

En Google Cloud, para proporcionar un aislamiento criptográfico más sólido para tus cargas de trabajo y proteger los datos en uso, admitimos los servicios de Confidential Computing para las instancias de máquina virtual (VM) de Compute Engine y nodos de Google Kubernetes Engine (GKE).

Administración de accesos entre servicios

El propietario de un servicio puede administrar el acceso a través de la creación de una lista de otros servicios que pueden comunicarse con él. La infraestructura de Google proporciona esta función de administración de acceso. Por ejemplo, un servicio puede restringir las RPC entrantes solo a una lista permitida de otros servicios. El propietario también puede configurar el servicio con una lista permitida de identidades de servicio, que la infraestructura aplica de forma automática. La aplicación incluye el registro de auditoría, las justificaciones y la restricción de acceso unilateral (por ejemplo, para las solicitudes de ingeniero).

También se proporcionan identidades individuales a los ingenieros de Google que necesitan acceso a los servicios. Los servicios se pueden configurar para permitir o denegar su acceso según sus identidades. Todas estas identidades (máquina, servicio y empleado) se encuentran en un espacio de nombres global que mantiene la infraestructura.

Para administrar estas identidades, la infraestructura proporciona un sistema de flujo de trabajo que incluye cadenas de aprobación, registros y notificaciones. Por ejemplo, la política de seguridad puede aplicar la autorización de varias partes. Este sistema usa la regla de dos personas para garantizar que un ingeniero que actúa solo pueda realizar operaciones sensibles sin antes obtener la aprobación de otro ingeniero autorizado. Este sistema permite que los procesos de administración de acceso seguros escalen a miles de servicios que se ejecutan en la infraestructura.

La infraestructura también proporciona servicios con el servicio canónico para la administración de usuarios, grupos y membresías a fin de que puedan implementar control de acceso personalizado y detallado cuando sea necesario.

Las identidades de usuarios finales se administran por separado, como se describe en Administración de acceso de los datos del usuario final en Google Workspace.

Encriptación de la comunicación entre cargas de trabajo

La infraestructura proporciona integridad y confidencialidad de los datos de RPC en la red. Se encriptará todo el tráfico de las redes virtuales de Google Cloud. La comunicación entre las cargas de trabajo de infraestructura de Google Cloud está encriptada, con exenciones que se otorgan solo para cargas de trabajo de alto rendimiento en las que el tráfico no cruza las varias capas de seguridad física en el perímetro de un centro de datos de Google. La comunicación entre los servicios de infraestructura de Google Cloud tiene protección de la integridad criptográfica.

La infraestructura proporciona de forma automática y eficiente (con la ayuda de la descarga de hardware) encriptación de extremo a extremo para el tráfico de RPC de la infraestructura que pasa por la red entre los centros de datos.

Administración del acceso a los datos del usuario final en Google Workspace

Por lo general, los servicios de Google Workspace tienen una función para el usuario final. Por ejemplo, un usuario final puede almacenar su correo electrónico en Gmail. La interacción del usuario final con una aplicación como Gmail podría abarcar otros servicios dentro de la infraestructura. Por ejemplo, Gmail puede llamar a una API de People para acceder a la libreta de direcciones del usuario final.

En la sección Encriptación de la comunicación entre servicios, se describe cómo un servicio (como Contactos de Google) está diseñado para proteger las solicitudes de RPC de otro servicio (como Gmail). Sin embargo, este nivel de control de acceso sigue siendo un conjunto amplio de permisos porque Gmail puede solicitar los contactos de cualquier usuario en cualquier momento.

Cuando Gmail realiza una solicitud de RPC a los Contactos de Google en nombre de un usuario final, la infraestructura permite que Gmail presente un ticket de permiso del usuario final en la solicitud de RPC. Este ticket demuestra que Gmail realiza la solicitud de RPC en nombre de ese usuario final específico. El ticket permite que los Contactos de Google implementen una protección con el fin de que solo muestre los datos para el usuario final que se nombra en el ticket.

La infraestructura proporciona un servicio central de identidad de usuarios que envía estos tickets de contexto del usuario final. El servicio de identidad verifica el acceso del usuario final y, luego, emite una credencial de usuario, como una cookie o un token de OAuth, al dispositivo del usuario. Cada solicitud posterior que se realiza desde el dispositivo hasta nuestra infraestructura debe presentar esa credencial de usuario final.

Cuando un servicio recibe una credencial de usuario final, pasa la credencial al servicio de identidad para que la verifique. Si se verifica la credencial del usuario final, el servicio de identidad muestra un ticket de contexto de usuario final de corta duración que se puede usar para RPC relacionadas con la solicitud del usuario. En nuestro ejemplo, el servicio que obtiene el ticket de contexto del usuario final es Gmail, que pasa el ticket a los Contactos de Google. A partir de ese momento, para cualquier llamada en cascada, el servicio de llamadas puede enviar el ticket de contexto del usuario final al destinatario como parte de la RPC.

En el siguiente diagrama, se muestra cómo se comunican el servicio A y el servicio B. La infraestructura proporciona identidad de servicio, autenticación mutua automática, comunicación encriptada entre servicios y aplicación de las políticas de acceso que el propietario del servicio define. Cada servicio tiene una configuración de servicio que su propietario crea. Para la comunicación encriptada entre servicios, la autenticación mutua automática usa identidades de emisores y destinatarios. La comunicación solo es posible cuando la configuración de una regla de acceso lo permite.

Diagrama que muestra cómo se comunican el servicio A y el servicio B

Para obtener información sobre la administración de acceso en Google Cloud, consulta Descripción general de IAM.

Administración del acceso a los datos del usuario final en Google Cloud

Al igual que la administración de acceso de los datos del usuario final en Google Workspace, la infraestructura proporciona un servicio central de identidad de usuarios que autentica las cuentas de servicio y emite tickets de contexto del usuario final después de que se autentica una cuenta de servicio. La administración de acceso entre los servicios de Google Cloud suele realizarse con agentes de servicios en lugar de usar tickets de contexto de usuario final.

Google Cloud usa la administración de identidades y accesos (IAM) y productos contextuales, como Identity-Aware Proxy, para que puedas administrar el acceso a los recursos en tu organización de Google Cloud. Las solicitudes a los servicios de Google Cloud pasan por IAM para verificar los permisos.

El proceso de administración de acceso es el siguiente:

  1. Se recibe una solicitud a través del servicio de Google Front End o el servicio de Cloud Front End para las VMs de clientes.
  2. La solicitud se enruta al servicio central de identidad del usuario que completa la verificación de autenticación y emite los tickets de contexto del usuario final.
  3. La solicitud también se enruta para verificar elementos como los siguientes:
  4. Después de pasar todas estas verificaciones, se llaman a los servicios de backend de Google Cloud.

Para obtener información sobre la administración de acceso en Google Cloud, consulta Descripción general de IAM.

Almacenamiento seguro de datos

En esta sección, se describe cómo implementamos la seguridad para los datos almacenados en la infraestructura.

Encriptación en reposo

La infraestructura de Google proporciona varios servicios de almacenamiento y sistemas de archivos distribuidos (por ejemplo, Spanner y Colossus), y un servicio central de administración de claves. Las aplicaciones de Google acceden al almacenamiento físico a través de una infraestructura de almacenamiento. Usamos varias capas de encriptación para proteger los datos en reposo. De forma predeterminada, la infraestructura de almacenamiento encripta todos los datos del usuario antes de que se escriban en el almacenamiento físico.

La infraestructura realiza la encriptación en la capa de infraestructura de aplicación o almacenamiento. Google administra y posee las claves para esta encriptación. La encriptación permite que la infraestructura se aísle a sí misma de las posibles amenazas en los niveles inferiores de almacenamiento, como el firmware de disco malicioso. Cuando corresponde, también habilitamos la compatibilidad con la encriptación de hardware en nuestros discos duros y SSD, y hacemos un seguimiento meticuloso de cada unidad durante su ciclo de vida. Antes de que un dispositivo de almacenamiento encriptado en desuso pueda abandonar físicamente nuestra custodia, se borra con un proceso de varios pasos que incluye dos verificaciones independientes. Los dispositivos que no pasan por este proceso de limpieza se destruyen físicamente (es decir, se trituran) dentro de las instalaciones.

Además de la encriptación que realiza la infraestructura con claves administradas por Google y que son propiedad de Google, Google Cloud y Google Workspace proporcionan servicios de administración de claves para claves que puedes poseer y administrar. Para Google Cloud, Cloud KMS es un servicio de nube que te permite crear tus propias claves criptográficas, incluidas las claves certificadas con FIPS 140-3 L3 basadas en hardware. Estas claves son específicas para ti, no para el servicio de Google Cloud, y puedes administrarlas según tus políticas y procedimientos. Para Google Workspace, puedes usar la encriptación del cliente. Para obtener más información, consulta Encriptación del cliente y colaboración mejorada en Google Workspace.

Eliminación de datos

Por lo general, la eliminación del material o los datos criptográficos comienza con la marcación de claves o datos específicos como programados para la eliminación. El proceso para marcar datos para su eliminación tiene en cuenta las políticas específicas del servicio y del cliente.

Cuando se programan los datos para la eliminación o la inhabilitación de las claves primero, podemos recuperarnos de las eliminaciones accidentales, ya sea que las eliminaciones se inicien por parte del cliente, se deban a un error o sean el resultado de un error interno del proceso.

Cuando un usuario final borra su cuenta, la infraestructura notifica a los servicios que controlan los datos del usuario final sobre la eliminación de la cuenta. Entonces, los servicios pueden programar la eliminación de los datos asociados con la cuenta de usuario final borrada. Esta característica permite que un usuario final controle sus propios datos.

Para obtener más información, consulta Eliminación de datos en Google Cloud. Si deseas obtener información sobre cómo usar Cloud Key Management Service para inhabilitar tus propias claves, consulta Destruye y restablece versiones de claves.

Comunicación segura en Internet

En esta sección, se describe cómo protegemos la comunicación entre Internet y los servicios que se ejecutan en la infraestructura de Google.

Como se explicó en Diseño y procedencia del hardware, la infraestructura consta de muchas máquinas físicas interconectadas en la LAN y WAN. La seguridad de la comunicación entre servicios no depende de la seguridad de la red. Sin embargo, aislamos nuestra infraestructura de Internet en un espacio de direcciones IP privadas. Solo exponemos un subconjunto de las máquinas directamente al tráfico externo de Internet para poder implementar protecciones adicionales, como las defensas contra los ataques de denegación del servicio (DoS).

Servicio de Google Frontend

Cuando se quiere publicar un servicio en Internet para que esté disponible, puede registrarse con un servicio de infraestructura llamado Google Front End (GFE). GFE garantiza que todas las conexiones de TLS se cierren con los certificados correctos y según las recomendaciones, como cumplir con la confidencialidad directa perfecta. GFE también aplica protecciones contra los ataques de DoS. Luego, GFE reenvía las solicitudes del servicio con el protocolo de seguridad de RPC que se explica en Administración de acceso a los datos del usuario final en Google Workspace.

En efecto, cualquier servicio interno que debe publicarse de forma externa usa GFE como un frontend de proxy inverso inteligente. GFE proporciona hosting de direcciones IP públicas de su nombre de DNS público, protección contra DoS y finalización de TLS. GFE se ejecuta en la infraestructura como cualquier otro servicio y puede escalar para coincidir con los volúmenes de solicitudes entrantes.

Cuando las VMs de los clientes en las redes de VPC de Google Cloud acceden a las APIs y los servicios de Google alojados directamente en Borg, las VMs de los clientes se comunican con los GFE específicos llamados Cloud Front Ends. Para minimizar la latencia, los Cloud Front Ends se ubican dentro de la misma región de la nube que la VM del cliente. El enrutamiento de red entre las VMs del cliente y los Cloud Front Ends no requiere que las VMs del cliente tengan direcciones IP externas. Cuando el Acceso privado a Google está habilitado, las VMs de clientes solo con direcciones IP internas pueden comunicarse con las direcciones IP externas de los servicios y las APIs de Google a través de los Cloud Front Ends. Todo el enrutamiento de red entre las VMs de cliente, las APIs de Google y los servicios depende de los siguientes saltos dentro de la red de producción de Google, incluso para las VMs de clientes que tienen direcciones IP externas.

Protección contra DoS

El escalamiento de nuestra infraestructura le permite absorber muchos ataques de DoS. Para reducir aún más el riesgo de impacto de DoS en los servicios, tenemos protecciones contra DoS de varios niveles y capas.

Cuando la red troncal de fibra óptica entrega una conexión externa a uno de nuestros centros de datos, la conexión pasa por varias capas de balanceadores de cargas de hardware y software. Estos balanceadores de cargas entregan información sobre el tráfico de entrada a un servicio central de DoS que se ejecuta en la infraestructura. Cuando el servicio central de DoS detecta un ataque de DoS, el servicio puede configurar los balanceadores de cargas para que detengan o aceleren el tráfico asociado con el ataque.

Las instancias de GFE también notifican información sobre las solicitudes que reciben al servicio central de DoS, incluida la información sobre la capa de la aplicación a la que los balanceadores de cargas no tienen acceso. Luego, el servicio central de DoS puede configurar las instancias de GFE para que detengan o aceleren el tráfico del ataque.

Autenticación de usuarios

Después de la protección contra DoS, la siguiente capa de defensa para la comunicación segura proviene del servicio central de identidad. Los usuarios finales interactúan con este servicio a través de la página de acceso de Google. El servicio solicita un nombre de usuario y una contraseña, y también puede desafiar a los usuarios para obtener información adicional según los factores de riesgo. Los factores de riesgo de ejemplo incluyen si los usuarios accedieron desde el mismo dispositivo o desde una ubicación similar en el pasado. Después de autenticar al usuario, el servicio de identidad envía credenciales, como cookies y tokens de OAuth, que se pueden usar en las llamadas siguientes.

Cuando los usuarios acceden, pueden usar segundos factores, como OTP o llaves de seguridad resistentes a la suplantación de identidad (phishing), como la llave de seguridad Titan. La llave de seguridad Titan es un token físico que admite el FIDO Universal 2nd Factor (U2F). Ayudamos a desarrollar el estándar abierto de U2F con la FIDO Alliance. La mayoría de las plataformas y los navegadores web adoptaron este estándar de autenticación abierto.

Seguridad operativa

En esta sección, se describe cómo desarrollamos el software de infraestructura, protegemos las credenciales y las máquinas de nuestros empleados, y defendemos contra las amenazas a la infraestructura por parte de actores internos y externos.

Desarrollo de software seguro

Además de las protecciones de control de código fuente y el proceso de revisión de dos partes que se describió antes, usamos bibliotecas que evitan que los desarrolladores incorporen ciertas clases de errores de seguridad. Por ejemplo, tenemos bibliotecas y marcos de trabajo que eliminan vulnerabilidades de XSS en aplicaciones web. También usamos herramientas automatizadas como pruebas de fuzzing, herramientas de análisis estático y escáneres de seguridad web para detectar de forma automática los errores de seguridad.

A modo de verificación final, usamos revisiones de seguridad manuales que varían desde las evaluaciones rápidas para las características con menor riesgo hasta las revisiones exhaustivas de diseño y de implementación para las características con mayor riesgo. El equipo que realiza estas revisiones incluye expertos en seguridad web, criptografía y seguridad de sistemas operativos. Estas revisiones pueden provocar el desarrollo de nuevas funciones de biblioteca de seguridad y nuevas pruebas de fuzzing que podemos usar para productos futuros.

Además, tenemos un programa de recompensas de vulnerabilidad que recompensa a cualquier persona que descubra errores en nuestra infraestructura o en nuestras aplicaciones, y nos informe al respecto. Para obtener más información sobre este programa, incluidas las recompensas que otorgamos, consulta Estadísticas clave de búsqueda de errores.

También invertimos en descubrimientos explotaciones de cero días y otros problemas de seguridad en el software de código abierto que usamos. Ejecutamos Project Zero, que es un equipo de investigadores de Google que se encargan de investigar las vulnerabilidades de cero días, incluidas Spectre y Meltdown. Además, enviamos la mayor cantidad de CVE y de correcciones de errores de seguridad para el hipervisor KVM de Linux.

Protecciones de código fuente

Nuestro código fuente se almacena en repositorios con integridad y administración de origen incorporadas, en las que se pueden auditar las versiones actuales y anteriores del servicio. La infraestructura requiere que los objetos binarios de un servicio se compilen a partir de un código fuente específico, después de revisarse, registrarse y probarse. La autorización binaria para Borg (BAB) es una verificación de aplicación interna que se produce cuando se implementa un servicio. BAB realiza lo siguiente:

  • Garantiza que el software de producción y la configuración que se implementa en Google se revisen y autoricen, en especial cuando ese código puede acceder a los datos del usuario.
  • Garantiza que las implementaciones de código y configuración cumplan con determinados estándares mínimos.
  • Limita la capacidad de un usuario infiltrado o de un miembro de la competencia para hacer modificaciones maliciosas en el código fuente y también proporcionan un rastro forense desde un servicio hacia su origen.

Protección continua de los dispositivos y credenciales de los empleados

Implementamos protecciones para proteger los dispositivos y las credenciales de nuestros empleados contra los riesgos. Para ayudar a proteger a nuestros empleados contra intentos de suplantación de identidad (phishing) sofisticados, reemplazamos la autenticación de dos factores de OTP por el uso obligatorio de llaves de seguridad compatibles con U2F.

Supervisamos los dispositivos cliente que usan nuestros empleados para operar la infraestructura. Nos aseguramos de que las imágenes de sistema operativo de estos dispositivos estén actualizadas con los parches de seguridad y controlamos las aplicaciones que los empleados pueden instalar en sus dispositivos. También tenemos sistemas que analizan las aplicaciones instaladas por el usuario, las descargas, las extensiones del navegador y el contenido del navegador web para determinar si son adecuadas para dispositivos corporativos.

La conexión a la LAN corporativa no es nuestro mecanismo principal para otorgar privilegios de acceso. En su lugar, utilizamos seguridad de confianza cero para proteger el acceso de los empleados a nuestros recursos. Los controles de administración de acceso a nivel de la aplicación exponen las aplicaciones internas a los empleados solo cuando estos usan un dispositivo administrado y se conectan desde las redes y las ubicaciones geográficas esperadas. Un dispositivo cliente es de confianza y se basa en un certificado que se emite a la máquina individual y en aserciones sobre su configuración (como el software actualizado). Para obtener más información, consulta BeyondCorp.

Reducción del riesgo de infiltración

El riesgo relacionado con usuarios con información privilegiada es el potencial de un empleado, contratista o algún otro socio comercial actual o anterior que tiene o tuvo acceso autorizado a nuestra red, sistema o datos para usar de forma inadecuada ese acceso y socavar la confidencialidad, integridad o disponibilidad de nuestros sistemas de información o información.

Para ayudar a reducir el riesgo con respecto a los usuarios con información privilegiada, limitamos y supervisamos de forma activa las actividades de los empleados que tienen acceso de administrador a la infraestructura. Trabajamos de forma continua a fin de eliminar la necesidad de acceso privilegiado para tareas particulares mediante la automatización que puede realizar las mismas tareas de manera segura y controlada. Expón APIs limitadas que permiten la depuración sin exponer datos sensibles y necesitamos aprobaciones de dos partes para ciertas acciones sensibles que realizan los operadores humanos.

El acceso a la información de los usuarios finales por parte de los empleados de Google se puede registrar mediante hooks de infraestructura de bajo nivel. Nuestro equipo de seguridad supervisa los patrones de acceso y también investiga los eventos inusuales. Para obtener más información, consulta Administración de acceso privilegiado en Google Cloud (PDF).

Usamos la autorización binaria para Borg a fin de proteger la cadena de suministro contra el riesgo de tener usuarios con información privilegiada. Además, nuestra inversión en BeyondProd ayuda a proteger los datos del usuario en la infraestructura de Google y a establecer confianza en nuestros servicios.

En Google Cloud, puedes supervisar el acceso a tus datos con la Transparencia de acceso. Los registros de Transparencia de acceso te permiten verificar que el personal de Google acceda a tu contenido solo por motivos comerciales válidos, como solucionar una interrupción o responder a tus solicitudes de asistencia. La aprobación de acceso garantiza que la ingeniería y el servicio de Atención al cliente de Cloud requieran tu aprobación explícita cada vez que necesiten acceder a tus datos. La aprobación se verifica de manera criptográfica para garantizar la integridad de la aprobación de acceso.

Para obtener más información sobre las protecciones de servicios de producción, consulta Cómo protege Google sus servicios de producción.

Supervisión de amenazas

El grupo de análisis de amenazas de Google supervisa a las actores de las amenazas y la evolución de sus tácticas y técnicas. Los objetivos de este grupo son ayudar a mejorar la seguridad y la protección de los productos de Google y compartir esta inteligencia para el beneficio de la comunidad en línea.

En el caso de Google Cloud, puedes usar Google Cloud Threat Intelligence for Google Security Operations y VirusTotal a fin de supervisar muchos tipos de software malicioso y responder a ellos. Google Cloud Threat Intelligence for Google Security Operations es un equipo de investigadores de amenazas que desarrolla inteligencia de amenazas para usarla con Google Security Operations. VirusTotal es una solución de visualización y base de datos de software malicioso que puedes usar para comprender mejor cómo funciona el software malicioso en tu empresa.

Para obtener más información sobre nuestras actividades de supervisión de amenazas, consulta el informe Threat Horizons.

Detección de intrusiones

Usamos canalizaciones sofisticadas de procesamiento de datos a fin de integrar indicadores basados en el host en dispositivos individuales, indicadores basados en la red desde varios puntos de supervisión en la infraestructura e indicadores desde los servicios de la infraestructura. Las reglas y la inteligencia artificial creadas a partir de estas canalizaciones envían advertencias a los ingenieros de seguridad operacional sobre los posibles incidentes. Nuestros equipos de investigación y de respuesta ante incidentes evalúan e investigan estos posibles incidentes, y responden a ellos, las 24 horas del día, los 365 días del año. Realizamos ejercicios de Red Team para medir y mejorar la eficacia de nuestros mecanismos de detección y respuesta.

¿Qué sigue?