En este documento, se presentan decisiones de seguridad importantes y opciones recomendadas que debes tener en cuenta cuando diseñas una zona de destino de Google Cloud. Forma parte de una serie sobrezonas de destino y está dirigido a especialistas en seguridad, directores de seguridad de la información y arquitectos que desean comprender las decisiones que deben tomar cuando diseñan una zona de destino en Google Cloud.
En este documento, se supone que un equipo central, como el equipo de seguridad o de plataforma, aplica estos controles de seguridad de la zona de destino. Debido a que el enfoque de este documento es el diseño de entornos a escala empresarial, algunas estrategias que describe pueden ser menos relevantes para equipos pequeños.
Puntos de decisión para proteger tu zona de destino de Google Cloud
Si deseas elegir el mejor diseño de seguridad para tu organización, debes tomar las siguientes decisiones:
Cómo limitar las credenciales persistentes para las cuentas de servicio
Cómo supervisar continuamente las configuraciones no seguras y las amenazas
Cómo agregar de manera centralizada los registros necesarios
Cómo cumplir con los requisitos de cumplimiento para la encriptación en reposo
Cómo cumplir con los requisitos de cumplimiento para la encriptación en tránsito
Diagrama de arquitectura
En la arquitectura de ejemplo descrita en este documento, se usan patrones de diseño de seguridad comunes. Los controles específicos pueden variar según factores, como la industria, las cargas de trabajo de destino o los requisitos de cumplimiento adicionales de la organización. En el siguiente diagrama, se muestra la arquitectura de controles de seguridad que aplicas en tu zona de destino cuando sigues las recomendaciones de este documento.
En el diagrama anterior, se muestra lo siguiente:
- La administración de claves de cuenta de servicio ayuda a mitigar el riesgo de credenciales de cuentas de servicio de larga duración.
- Los Controles del servicio de VPC definen un perímetro alrededor de recursos sensibles que ayudan a restringir el acceso desde fuera del perímetro.
- Security Command Center supervisa el entorno para detectar configuraciones no seguras y amenazas.
- Un receptor de registros centralizado recopila los registros de auditoría de todos los proyectos.
- La encriptación en reposo predeterminada de Google encripta todos los datos que persisten en el disco.
- La encriptación en tránsito predeterminada de Google se aplica a las rutas de red de capa 3 y capa 4.
- La Transparencia de acceso te brinda visibilidad y control sobre cómo Google puede acceder a tu entorno.
Decide cómo limitar las credenciales persistentes para las cuentas de servicio
Las cuentas de servicio son identidades de máquinas que usas para otorgar roles de IAM a las cargas de trabajo y permitir que la carga de trabajo acceda a las APIs de Google Cloud. Una clave de cuenta de servicio es una credencial persistente, y cualquier credencial persistente es un riesgo potencialmente alto. No recomendamos que permitas que los desarrolladores creen claves de cuenta de servicio con libertad.
Por ejemplo, si un desarrollador confirma de manera accidental la clave de cuenta de servicio en un repositorio público de Git, un atacante externo puede autenticarse con esas credenciales. Otro ejemplo, si la clave de cuenta de servicio se almacena en un repositorio interno, un usuario malintencionado con información privilegiada que puede leer la clave podría usar las credenciales para escalar sus propios privilegios de Google Cloud.
Para definir una estrategia a fin de administrar estas credenciales persistentes, debes proporcionar alternativas viables, limitar la proliferación de credenciales persistentes y administrar cómo se usan. Si deseas obtener información sobre las alternativas a las claves de cuenta de servicio, consulta Elige el mejor método de autenticación para tu caso de uso.
En las siguientes secciones, se describen las opciones para limitar las credenciales persistentes. Recomendamos la opción 1 para la mayoría de los casos de uso. Las otras opciones que se analizan en las siguientes secciones son alternativas que puedes considerar si la opción 1 no se aplica a tu organización específica.
Todas las organizaciones creadas después del 23 de mayo de 2024 tienen políticas de la organización seguras de forma predeterminada que se aplican cuando se crea el recurso de la organización por primera vez. Este cambio hace que la opción 1 sea la opción predeterminada.
Opción 1: Restringe el uso de claves de cuenta de servicio persistentes
Recomendamos que no permitas que ningún usuario descargue claves de cuenta de servicio, ya que las claves expuestas son un vector de ataque común. La restricción del uso de claves de cuenta de servicio persistentes es una opción que puede ayudar a reducir el riesgo y la sobrecarga de administrar de manera manual las claves de cuenta de servicio.
Para implementar esta opción, ten en cuenta lo siguiente:
- Para evitar que los desarrolladores creen y descarguen credenciales
persistentes, configura la
restricción de la política de la organización
constraints/iam.disableServiceAccountKeyCreation. - Capacita a tus equipos sobre alternativas más seguras para las claves de cuentas de servicio. Por ejemplo, cuando los usuarios y las aplicaciones que están fuera del entorno de Google Cloud necesitan usar una cuenta de servicio, pueden autenticarse mediante el uso de la identidad de una cuenta de servicio o la federación de identidades para cargas de trabajo en lugar de una clave de cuenta de servicio.
- Diseñar un proceso para que los equipos soliciten una excepción a esta política cuando descarguen una clave de cuenta de servicio es la única opción viable. Por ejemplo, un producto de SaaS de terceros puede requerir una clave de cuenta de servicio para leer los registros de tu entorno de Google Cloud.
Evita esta opción cuando ya tengas herramientas que generen credenciales de API de corta duración para las cuentas de servicio.
Para obtener más información, consulta lo siguiente:
- Restricciones de las políticas de la organización en el plano de bases empresariales de Google Cloud
- Prácticas recomendadas para trabajar con cuentas de servicio
Opción 2: Usa herramientas de administración de acceso adicionales para generar credenciales de corta duración
Como alternativa a Restringe el uso de claves de cuenta de servicio persistentes, puedes generar credenciales de corta duración para cuentas de servicio. Las credenciales de corta duración crean menos riesgo que las credenciales persistentes como las claves de cuenta de servicio. Puedes desarrollar tus propias herramientas o usar soluciones de terceros, como Hashicorp Vault, para generar credenciales de acceso de corta duración.
Usa esta opción cuando ya hayas invertido en una herramienta de terceros a fin de generar credenciales de corta duración para el control de acceso, o tengas suficiente presupuesto y capacidad para desarrollar tu propia solución.
Evita usar esta opción cuando no tengas herramientas existentes para otorgar credenciales de corta duración o no tengas la capacidad de compilar tu propia solución.
A fin de obtener más información, consulta Crea credenciales de cuenta de servicio de corta duración.
Decide cómo mitigar el robo de datos a través de las API de Google
Las API de Google tienen extremos públicos que están disponibles para todos los clientes. Si bien cada recurso de API en tu entorno de Google Cloud está sujeto a los controles de acceso de IAM, existe el riesgo de que se acceda a los datos con credenciales robadas, extraídas por usuarios maliciosos con información privilegiada o un código vulnerado, o expuesto a través de una política de IAM mal configurada.
Los Controles del servicio de VPC son una solución que aborda estos riesgos. Sin embargo, los Controles del servicio de VPC también presentan complejidad en tu modelo de acceso, por lo que debes diseñarlos para cumplir con tu entorno único y tu caso de uso.
En las siguientes secciones, se describen las opciones para mitigar el robo de datos a través de las API de Google. Recomendamos la opción 1 para la mayoría de los casos de uso. Las otras opciones que se analizan en las siguientes secciones son alternativas que puedes considerar si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Configura los Controles del servicio de VPC de forma amplia en tu entorno
Te recomendamos que diseñes tu entorno dentro de uno o más perímetros de los Controles del servicio de VPC que restringen todas las API compatibles. Configura excepciones al perímetro con niveles de acceso o políticas de entrada para que los desarrolladores puedan acceder a los servicios que necesitan, incluido el acceso a la consola cuando sea necesario.
Usa esta opción cuando se cumpla lo siguiente:
- Los servicios que quieres usar admiten los Controles del servicio de VPC, y tus cargas de trabajo no requieren acceso ilimitado a Internet.
- Almacenas datos sensibles en Google Cloud que podrían ser una pérdida significativa si te robaron.
- Tienes atributos coherentes para el acceso de los desarrolladores que se pueden configurar como excepciones al perímetro, lo que permite a los usuarios acceder a los datos que necesitan.
Evita esta opción cuando tus cargas de trabajo requieran acceso ilimitado a Internet o servicios que no sean compatibles con los Controles del servicio de VPC.
Para obtener más información, consulta lo siguiente:
- Prácticas recomendadas para habilitar los Controles del servicio de VPC
- Productos admitidos y limitaciones de los Controles del servicio de VPC
- Diseña perímetros de servicio
Opción 2: Configura los Controles del servicio de VPC para un subconjunto de tu entorno
En lugar de configurar los Controles del servicio de VPC de forma amplia en todo tu entorno, puedes configurarlos solo en el subconjunto de proyectos que contienen datos sensibles y cargas de trabajo solo internas. Esta opción te permite usar un diseño y una operación más simples para la mayoría de los proyectos y, al mismo tiempo, priorizar la protección de datos para proyectos con datos sensibles.
Por ejemplo, puedes considerar esta alternativa cuando una cantidad limitada de proyectos contenga conjuntos de datos de BigQuery con datos sensibles. Puedes definir un perímetro de servicio alrededor de estos proyectos y definir reglas de entrada y salida para permitir excepciones estrechas a los analistas que necesitan usar estos conjuntos de datos.
Para otro ejemplo, en una aplicación con arquitectura de tres niveles, algunos componentes pueden estar fuera del perímetro. El nivel de presentación que permite la entrada del tráfico de los usuarios puede ser un proyecto fuera del perímetro, y el nivel de aplicación y el nivel de datos que contienen datos sensibles pueden ser proyectos separados dentro del perímetro de servicio. Debes definir reglas de entrada y salida para el perímetro, de modo que los niveles puedan comunicarse a través del perímetro con acceso detallado.
Usa esta opción cuando se cumpla lo siguiente:
- Solo los proyectos limitados y bien definidos contienen datos sensibles. Otros proyectos contienen datos de menor riesgo.
- Algunas cargas de trabajo son solo internas, pero algunas requieren acceso público a Internet o tienen dependencias en servicios que no son compatibles con los Controles del servicio de VPC.
- Configurar los Controles del servicio de VPC en todos los proyectos crea demasiada sobrecarga o requiere demasiadas soluciones
Evita esta opción cuando muchos proyectos puedan contener datos sensibles.
Para obtener más información, consulta Prácticas recomendadas para habilitar los Controles del servicio de VPC.
Opción 3: No configures los Controles del servicio de VPC
Como alternativa a la configuración de los Controles del servicio de VPC de forma amplia en todo tu entorno, puedes optar por no usar los Controles del servicio de VPC, en especial si la sobrecarga operativa supera el valor los Controles del servicio de VPC.
Por ejemplo, es posible que tu organización no tenga un patrón coherente de acceso de los desarrolladores que pueda formar la base de una política de entrada. Quizás tus operaciones de TI se subcontratan a varios terceros, por lo que los desarrolladores no tienen dispositivos administrados ni acceso desde direcciones IP coherentes. En esta situaciones, es posible que no puedas definir reglas de entrada para permitir excepciones al perímetro que los desarrolladores necesitan para completar sus operaciones diarias.
Usa esta opción en los siguientes casos:
- Si usas servicios que no son compatibles con los Controles del servicio de VPC.
- Las cargas de trabajo están orientadas a Internet y no contienen datos sensibles.
- No tienes atributos coherentes de acceso de desarrolladores, como dispositivos administrados o rangos de IP conocidos.
Evita esta opción cuando tengas datos sensibles en tu entorno de Google Cloud.
Decide cómo supervisar de forma continua las amenazas y las configuraciones no seguras
Adoptar servicios en la nube presenta desafíos y amenazas nuevos en comparación con el uso de servicios locales. Es posible que las herramientas existentes que supervisan los servidores de larga duración no sean apropiadas para el ajuste de escala automático o los servicios efímeros, y que tampoco supervisen los recursos sin servidores. Por lo tanto, debes evaluar las herramientas de seguridad que funcionan con la gama completa de servicios en la nube que podrías adoptar. También debes supervisar de forma continua los estándares de nube, como las comparativas de CIS para Google Cloud.
En las siguientes secciones, se describen las opciones para la supervisión continua. Recomendamos la opción 1 para la mayoría de los casos de uso. Las otras opciones que se analizan en las siguientes secciones son alternativas que puedes considerar si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Usa Security Command Center
Te recomendamos activar Security Command Center a nivel de la organización, lo que te ayuda a fortalecer tu postura de seguridad mediante las siguientes acciones:
- Evaluar la superficie de ataque de datos y tu seguridad.
- Proporcionar inventario de activos y funciones de detección
- Identificar configuraciones incorrectas, vulnerabilidades y amenazas
- Ayudar a mitigar y solucionar riesgos
Cuando habilitas Security Command Center al comienzo de la compilación de la zona de destino, el equipo de seguridad de tu organización tiene visibilidad casi en tiempo real sobre las configuraciones no seguras, las amenazas y las opciones de soluciones. Esta visibilidad ayuda a tu equipo de seguridad a evaluar si la zona de destino cumple con sus requisitos y si está lista para que los desarrolladores comiencen a implementar aplicaciones.
Usa esta opción cuando se cumpla lo siguiente:
- Quieres una herramienta de administración de postura de seguridad y detección de amenazas que esté integrada en todos los servicios de Google Cloud sin esfuerzo de integración adicional.
- Deseas usar la misma inteligencia de amenazas, el aprendizaje automático y otros métodos avanzados que Google usa para proteger sus propios servicios.
- Tu centro de operaciones de seguridad (SOC) existente no tiene las habilidades ni la capacidad para generar estadísticas de amenazas a partir de un gran volumen de registros en la nube.
Evita esta opción cuando tus herramientas de seguridad existentes puedan abordar por completo los recursos en la nube efímeros o sin servidores, supervisar las configuraciones inseguras y, además, identificar amenazas a gran escala en un entorno de nube.
Opción 2: Usa las herramientas de seguridad existentes para administrar las posiciones de seguridad en la nube y la detección de amenazas
Como alternativa a Usa Security Command Center, puedes considerar otras herramientas de administración de posturas de seguridad en la nube. Existen varias herramientas de terceros que tienen funciones similares a las de Security Command Center, y es posible que ya hayas invertido en herramientas nativas de la nube que se enfocan en entornos de múltiples nubes.
También puedes usar Security Command Center y herramientas de terceros en conjunto. Por ejemplo, puedes transferir las notificaciones de resultados desde Security Command Center a otra herramienta, o puedes agregar un servicio de seguridad de terceros al panel de Security Command Center. Otro ejemplo, es posible que debas almacenar registros en un sistema SIEM existente para que el equipo de SOC analice las amenazas. Puedes configurar tu SIEM existente para transferir solo las notificaciones de resultados que produce Security Command Center, en lugar de transferir un gran volumen de registros y esperar que un equipo de SOC analice los registros sin procesar para obtener estadísticas.
Usa esta opción cuando tus herramientas de seguridad existentes puedan abordar por completo los recursos en la nube efímeros o sin servidores, supervisar las configuraciones inseguras y, además, identificar amenazas a gran escala en un entorno de nube.
Evita esta opción cuando se cumplan las siguientes condiciones:
- Tu SOC existente no tiene las habilidades ni la capacidad para generar estadísticas de amenazas a partir del gran volumen de registros en la nube.
- La integración de varias herramientas de terceros con varios servicios de Google Cloud presenta más complejidad que valor.
Para obtener más información, consulta lo siguiente:
Decide cómo agregar de forma centralizada los registros necesarios
La mayoría de los registros de auditoría se almacenan en el proyecto de Google Cloud que los generó. A medida que tu entorno crece, puede ser insostenible que un auditor verifique registros en cada proyecto individual. Por lo tanto, debes tomar una decisión sobre cómo se centralizarán y agregarán los registros para ayudar a tus operaciones internas de auditoría y seguridad.
En las siguientes secciones, se describen las opciones para agregar registros. Recomendamos la opción 1 para la mayoría de los casos de uso. Las otras opciones que se analizan en las siguientes secciones son alternativas que puedes considerar si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Retener registros en Google Cloud con receptores de registros agregados
Te recomendamos que configures un receptor de registros centralizado en toda la organización para los registros de auditoría y otros registros que requiere el equipo de seguridad. Puedes hacer referencia a la herramienta de alcance de registro para identificar los registros que requiere tu equipo de seguridad y si estos tipos de registros requieren habilitación explícita.
Por ejemplo, el equipo de seguridad espera un registro central de cualquier recurso que creen los usuarios para poder supervisar y, luego, investigar los cambios sospechosos. El equipo de seguridad también requiere un registro inmutable de acceso a los datos para ciertas cargas de trabajo altamente sensibles. Por lo tanto, el equipo de seguridad configura un receptor de registros para agregar registros de auditoría de actividad del administrador de todos los proyectos a un bucket de análisis de registros en un proyecto central que el equipo puede ver de las investigaciones inesperadas. Luego, el equipo configura un segundo receptor de registros para los registros de auditoría de acceso a los datos de proyectos con cargas de trabajo sensibles en un bucket de Cloud Storage para la retención a largo plazo.
Usa esta opción cuando se cumpla lo siguiente:
- Tu equipo de seguridad espera un registro central de todos los registros de auditoría o de otros tipos de registros específicos.
- Tu equipo de seguridad debe almacenar registros en un entorno con acceso restringido, fuera del control de la carga de trabajo o los equipos que produjeron el registro.
Evita esta opción cuando se cumplan las siguientes condiciones:
- Tu organización no tiene un requisito central para los registros de auditoría coherentes en las cargas de trabajo.
- Los propietarios de proyectos individuales tienen la responsabilidad total de administrar sus propios registros de auditoría.
Para obtener más información, consulta lo siguiente:
- Controles de detección en el plano de bases empresariales
- Prácticas recomendadas para los registros de auditoría de Cloud
- Configurar receptores agregados
- Herramienta de alcance de registros
- Políticas de retención y bloqueos de las políticas de retención
Opción 2: Exporta los registros de auditoría necesarios al almacenamiento fuera de Google Cloud
Como alternativa a almacenar registros solo en Google Cloud, considera exportar registros de auditoría fuera de Google Cloud. Después de centralizar los tipos de registro necesarios en un receptor de registros agregado en Google Cloud, transfiere el contenido de ese receptor a otra plataforma fuera de Google Cloud para almacenar y analizar registros.
Por ejemplo, puedes usar una herramienta SIEM de terceros para agregar y analizar registros de auditoría en varios proveedores de servicios en la nube. Esta herramienta tiene suficientes capacidades para trabajar con recursos en la nube sin servidores, y tu equipo de SOC tiene las habilidades y la capacidad para generar estadísticas a partir de este gran volumen de registros.
Esta opción puede ser muy costosa debido al costo de salida de red en Google Cloud, así como el costo de almacenamiento y la capacidad en el otro entorno. En lugar de exportar todos los registros disponibles, te recomendamos que seas selectivo con respecto a qué registros son necesarios en el entorno externo.
Usa esta opción cuando debas almacenar registros de todos los entornos y proveedores de servicios en la nube en una sola ubicación central.
Evita esta opción cuando se cumplan las siguientes condiciones:
- Tus sistemas existentes no tienen la capacidad ni el presupuesto para transferir un gran volumen de registros de nube adicionales.
- Tus sistemas existentes requieren esfuerzos de integración para cada tipo de registro y formato.
- Está recopilando registros sin un objetivo claro de cómo se usarán.
Para obtener más información, consulta Controles de detección en el plano de bases empresariales.
Decide cómo cumplir con los requisitos de cumplimiento para la encriptación en reposo
Google Cloud encripta de forma automática todo el contenido almacenado en reposo mediante uno o más mecanismos de encriptación. Según tus requisitos de cumplimiento, es posible que tengas la obligación de administrar las claves de encriptación tú mismo.
En las siguientes secciones, se describen las opciones de encriptación en reposo. Recomendamos la opción 1 para la mayoría de los casos de uso. Las otras opciones que se analizan en las siguientes secciones son alternativas que puedes considerar si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Acepta el uso de la encriptación en reposo predeterminada
La encriptación en reposo predeterminada es suficiente para muchos casos de uso que no tienen requisitos de cumplimiento particulares en relación con la administración de claves de encriptación.
Por ejemplo, el equipo de seguridad de una empresa de videojuegos en línea requiere que todos los datos de clientes se encripten en reposo. El equipo no tiene requisitos regulatorios sobre la administración de claves y, después de revisar la encriptación en reposo predeterminada de Google, está satisfecho de que sea un control suficiente para sus necesidades.
Usa esta opción cuando se cumpla lo siguiente:
- No tienes requisitos particulares sobre cómo encriptar datos o cómo se administran las claves de encriptación.
- Prefieres un servicio administrado en lugar del costo y la sobrecarga operativa de administrar tus propias claves de encriptación.
Evita esta opción cuando tengas requisitos de cumplimiento para administrar tus propias claves de encriptación.
Para obtener más información, consulta Encriptación en reposo en Google Cloud.
Opción 2: Administra las claves de encriptación con Cloud KMS
Además de la encriptación en reposo predeterminada, es posible que necesites más control sobre las claves usadas para encriptar datos en reposo dentro de un proyecto de Google Cloud. Cloud Key Management Service (Cloud KMS) ofrece la capacidad de proteger tus datos con claves de encriptación administradas por el cliente (CMEK). Por ejemplo, en la industria de servicios financieros, es posible que debas informar a tus auditores externos cómo administras tus propias claves de encriptación para datos sensibles.
Para obtener capas adicionales de control, puedes configurar módulos de seguridad de hardware (HSM) o administración de claves externas (EKM) con CMEK. No se recomiendan las claves de encriptación proporcionadas por el cliente (CSEK). Las situaciones que históricamente se abordaron con CSEK ahora se abordan mejor con Cloud External Key Manager (Cloud EKM), ya que Cloud EKM es compatible con más servicios y tiene mayor disponibilidad.
Con esta opción, se cambia la responsabilidad de los desarrolladores de aplicaciones para seguir la administración de claves que exige tu equipo de seguridad. El equipo de seguridad puede aplicar el requisito mediante el bloqueo de la creación de recursos que no cumplen con las políticas de la organización de CMEK.
Usa esta opción cuando una o más de las siguientes condiciones sea verdadera:
- Debes administrar el ciclo de vida de tus propias claves.
- Debes generar material de clave criptográfica con un HSM certificado con el nivel 3 del estándar FIPS 140-2.
- Debes almacenar el material de claves criptográficas fuera de Google Cloud mediante Cloud EKM.
Evita esta opción cuando se cumplan las siguientes condiciones:
- No tienes requisitos particulares sobre cómo encriptar datos o cómo se administran las claves de encriptación.
- Prefieres un servicio administrado en lugar del costo y la sobrecarga operativa de administrar tus propias claves de encriptación.
Para obtener más información, consulta lo siguiente:
- Administra las claves de encriptación con Cloud Key Management Service en el plano de bases empresariales
Opción 3: Asignación de tokens a los datos en la capa de aplicación antes de almacenarlos
Además de la encriptación predeterminada que proporciona Google, también puedes desarrollar tu propia solución para asignar tokens a los datos antes de almacenarlos en Google Cloud.
Por ejemplo, un científico de datos debe analizar un conjunto de datos con información de PII, pero no debería tener acceso para leer los datos sin procesar de algunos campos sensibles. Para limitar el acceso de control a los datos sin procesar, podrías desarrollar una canalización de transferencia con Sensitive Data Protection para transferir datos sensibles y asignarles tokens y, a continuación, conservar los datos con asignación de token en BigQuery.
La asignación de token de datos no es un control que puedas aplicar de forma centralizada en la zona de destino. En cambio, esta opción cambia la responsabilidad de los desarrolladores de aplicaciones para configurar su propia encriptación, o a un equipo de la plataforma que desarrolla una canalización de encriptación como un servicio compartido para que lo usen los desarrolladores de aplicaciones.
Usa esta opción cuando las cargas de trabajo particulares tengan datos altamente sensibles que no se deban usar en su forma sin procesar.
Evita esta opción cuando Cloud KMS sea suficiente para cumplir con tus requisitos, como se describe en Administra las claves de encriptación con Cloud KMS. El movimiento de datos a través de canalizaciones de encriptación y desencriptación adicionales agrega costo, latencia y complejidad a las aplicaciones.
Para obtener más información, consulta lo siguiente:
- Descripción general de Protección de datos sensibles
- Toma el control de tus datos: cómo la asignación de token hace que los datos se puedan usar sin sacrificar la privacidad
Decide cómo cumplir con los requisitos de cumpliiento para la encriptación en tránsito
Google Cloud tiene varias medidas de seguridad para garantizar la autenticidad, la integridad y la privacidad de los datos en tránsito. Según tus requisitos de seguridad y cumplimiento, también puedes configurar la encriptación de la capa de la aplicación.
En las siguientes secciones, se describen las opciones de encriptación en tránsito. Recomendamos la opción 1 para la mayoría de los casos de uso. La otra opción que se analiza en las siguientes secciones es una característica adicional que puedes considerar si la opción 1 no es suficiente para tu caso de uso específico.
Opción 1: Evalúa si la encriptación en tránsito predeterminada es suficiente
Muchos patrones de tráfico en tu zona de destino se benefician de la encriptación en tránsito predeterminada de Google.
- Todo el tráfico de VM a VM dentro de una red de VPC y redes de VPC conectadas se encripta en la capa 3 o la capa 4.
El tráfico de Internet a los servicios de Google finaliza en Google Front End (GFE). GFE también hace lo siguiente:
- Finaliza el tráfico para el tráfico entrante de proxy TLS, HTTP(S) y TCP
- Proporciona contramedidas para aplacar los ataques de DSD
- Enruta y balancea las cargas del tráfico a los servicios de Google Cloud
Un patrón de tráfico que requiere configuración es Cloud Interconnect, ya que el tráfico de tu entorno local a Google Cloud no está encriptado en tránsito de forma predeterminada. Si usas Cloud Interconnect, te recomendamos que habilites MACsec para Cloud Interconnect como parte de tu zona de aterrizaje.
Usa esta opción cuando la encriptación en tránsito predeterminada de Google sea suficiente para tus cargas de trabajo internas.
Evita esta opción cuando se cumplan las siguientes condiciones:
- Permite el tráfico de entrada de Internet en la red de VPC.
- Necesitas la encriptación en tránsito de la capa 7 entre todos los recursos de procesamiento internos.
En estos casos, debes configurar controles adicionales, como se explica en la Opción 2: Exige que las aplicaciones configuren la encriptación en tránsito de la capa 7.
Para obtener más información, consulta Encriptación en tránsito en Google Cloud.
Opción 2: Exige que las aplicaciones configuren la encriptación en tránsito de la capa 7
Además de la encriptación en tránsito predeterminada, puedes configurar la encriptación de la capa 7 para el tráfico de la aplicación. Google Cloud proporciona servicios administrados para admitir aplicaciones que necesitan encriptación en tránsito de la capa de la aplicación, incluidos los certificados administrados, Cloud Service Mesh y Cloud Service Mesh.
Por ejemplo, un desarrollador compila una aplicación nueva que acepta tráfico de entrada desde Internet. El desarrollador usa un balanceador de cargas de aplicaciones externo con certificados SSL administrados por Google para ejecutar y escalar servicios detrás de una sola dirección IP.
La encriptación de la capa de la aplicación no es un control que puedas aplicar de forma centralizada en la zona de destino. En cambio, esta opción cambia algunas responsabilidades de los desarrolladores de aplicaciones para configurar la encriptación en tránsito.
Usa esta opción cuando las aplicaciones requieran tráfico HTTPS o SSL entre componentes.
Considera permitir una excepción limitada a esta opción cuando migres cargas de trabajo de procesamiento a la nube que antes no requería una encriptación en tránsito interno cuando las aplicaciones eran locales. Durante una migración a gran escala, forzar la modernización de las aplicaciones heredadas antes de la migración puede causar una demora inaceptable del programa.
Para obtener más información, consulta lo siguiente:
Decide qué controles adicionales son necesarios para administrar el acceso del proveedor de servicios en la nube
La necesidad de auditar el acceso del proveedor de servicios en la nube (CSP) puede ser una preocupación durante la adopción de la nube. Google Cloud proporciona varias capas de control que pueden habilitar la verificación del acceso de los proveedores de servicios en la nube.
En las siguientes secciones, se describen las opciones para administrar el acceso a CSP. Recomendamos la opción 1 para la mayoría de los casos de uso. La otra opción que se analiza en las siguientes secciones es una característica adicional que puedes considerar si la opción 1 no es suficiente para tu caso de uso específico.
Opción 1: Habilita los registros de Transparencia de acceso
Los registros de Transparencia de acceso registran las acciones que realizan los empleados de Google Cloud en tu entorno, como cuando solucionan problemas de un caso de asistencia.
Por ejemplo, tu desarrollador genera una solución de problemas para Atención al cliente de Cloud y le pide al agente de atención al cliente que ayude a solucionar el entorno. Se genera un registro de Transparencia de acceso para mostrar qué acciones realizó el personal de asistencia, incluido el número de caso de asistencia que lo justificó.
Usa esta opción cuando se cumpla lo siguiente:
- Debes verificar que el personal de Google Cloud acceda a tu contenido solo por motivos comerciales válidos, como solucionar una interrupción o responder a tus solicitudes de asistencia.
- Tienes un requisito de cumplimiento para hacer un seguimiento del acceso a datos sensibles.
Opción 2: Habilita los registros de Transparencia de acceso y la administración de accesos de los proveedores
Si tu empresa tiene un requisito de cumplimiento para otorgar la aprobación explícita antes de que un CSP pueda acceder a tu entorno, además de la opción 1, puedes usar la Transparencia de acceso con otros controles que te permitan aprobar o rechazar de forma explícita el acceso a tus datos.
La aprobación de acceso es una solución manual que garantiza que Atención al cliente y la ingeniería de Google requieran tu aprobación explícita (por correo electrónico o a través de un webhook) cada vez que necesiten acceder a tu contenido.
Key Access Justifications es una solución programática que agrega un campo de justificación a cualquier solicitud de claves de encriptación que se configure con Cloud EKM.
Usa esta opción cuando se cumpla lo siguiente:
- Quieres que un equipo central administre directamente el acceso a tu contenido por parte del personal de Google.
- Para la Aprobación de acceso, puedes aceptar el riesgo de que la capacidad central de aprobar o rechazar cada solicitud de acceso sea más importante que la compensación operativa, que podría ser una resolución más lenta de los casos de asistencia.
- Para Key Access Justifications, tu empresa ya usa Cloud External Key Manager como parte de tu estrategia de encriptación y desea tener control programático sobre todos los tipos de acceso a los datos encriptados (no solo el acceso del personal de Google a los datos).
Evita esta opción cuando se cumplan las siguientes condiciones:
- La demora operativa que puede generarse cuando un equipo central con autoridad de aprobación de acceso debe responder es un riesgo inaceptable para las cargas de trabajo que requieren alta disponibilidad y una respuesta rápida de Atención al cliente.
Para obtener más información, consulta lo siguiente:
Prácticas recomendadas de seguridad para las zonas de destino de Google Cloud
Además de las decisiones que se presentan en este documento, considera las siguientes prácticas recomendadas de seguridad:
- Aprovisiona las identidades en tu entorno. Para obtener más información, consulta Decide cómo integrar identidades a Google Cloud.
- Diseña una red que se adapte a los casos de uso de tu organización. Para obtener más información, consulta Decide el diseño de red de la zona de destino de Google Cloud.
- Implementa las restricciones de las políticas de la organización que se definen en el plano de bases empresariales. Estas restricciones ayudan a evitar problemas comunes de seguridad, como crear direcciones IP externas innecesarias u otorgar el rol de editor a todas las cuentas de servicio.
- Revisa la lista completa de restricciones de las políticas de la organización para evaluar si otros controles son relevantes para tus requisitos. Todas las organizaciones creadas después del 23 de mayo de 2024 tienen políticas de la organización seguras de forma predeterminada que se aplican cuando se crea el recurso de la organización por primera vez. Este cambio hace que la opción 1 sea la opción predeterminada.
¿Qué sigue?
- Revisa el plano de bases empresariales.
- Obtén más información sobre las prácticas recomendadas de seguridad en el framework de la arquitectura de Google Cloud.
- Lee los planos y los informes técnicos disponibles en el centro de prácticas recomendadas para la seguridad de Google Cloud.