En este documento se presentan decisiones de seguridad importantes y opciones recomendadas que se deben tener en cuenta al diseñar una zona de aterrizaje de Google Cloud . Forma parte de una serie sobre landing zones y está dirigida a especialistas en seguridad, CISOs y arquitectos que quieran saber qué decisiones deben tomar al diseñar una landing zone en Google Cloud.
En este documento, se da por hecho que un equipo central, como el de seguridad o el de plataforma, aplica estos controles de seguridad de la zona de aterrizaje. Como este documento se centra en el diseño de entornos a nivel de empresa, algunas de las estrategias que describe pueden ser menos relevantes para equipos pequeños.
Puntos de decisión para proteger tu Google Cloud zona de aterrizaje
Para elegir el mejor diseño de seguridad para tu organización, debes tomar las siguientes decisiones:
Cómo limitar las credenciales persistentes de las cuentas de servicio
Cómo mitigar la filtración externa de datos a través de las APIs de Google
Cómo monitorizar continuamente las configuraciones no seguras y las amenazas
Cómo cumplir los requisitos de cumplimiento para el cifrado en reposo
Cómo cumplir los requisitos de cumplimiento para el cifrado en tránsito
Diagrama de la arquitectura
La arquitectura de ejemplo que se describe en este documento usa patrones de diseño de seguridad habituales. Los controles específicos pueden variar en función de factores como el sector de tu organización, las cargas de trabajo de destino o los requisitos de cumplimiento adicionales. En el siguiente diagrama se muestra la arquitectura de los controles de seguridad que se aplican en la zona de aterrizaje cuando se siguen las recomendaciones de este documento.
En el diagrama anterior se muestra lo siguiente:
- La gestión de claves de cuentas de servicio ayuda a mitigar el riesgo de las credenciales de cuentas de servicio de larga duración.
- Controles de Servicio de VPC define un perímetro alrededor de los recursos sensibles que ayuda a restringir el acceso desde fuera del perímetro.
- Security Command Center monitoriza el entorno en busca de configuraciones no seguras y amenazas.
- Un sumidero de registro centralizado recoge los registros de auditoría de todos los proyectos.
- El cifrado predeterminado en reposo de Google cifra todos los datos que se conservan en el disco.
- El cifrado predeterminado de Google en tránsito se aplica a las rutas de red de las capas 3 y 4.
- Transparencia de acceso te ofrece visibilidad y control sobre cómo puede acceder Google a tu entorno.
Decidir cómo limitar las credenciales persistentes de las cuentas de servicio
Las cuentas de servicio son identidades de máquina que se usan para asignar roles de gestión de identidades y accesos a cargas de trabajo y permitir que estas accedan a las APIs de Google Cloud . Una clave de cuenta de servicio es una credencial persistente y cualquier credencial persistente supone un riesgo potencialmente alto. No te recomendamos que permitas que los desarrolladores creen claves de cuentas de servicio libremente.
Por ejemplo, si un desarrollador confirma por error la clave de la cuenta de servicio en un repositorio de Git público, un atacante externo puede autenticarse con esas credenciales. Otro ejemplo: si la clave de la cuenta de servicio se almacena en un repositorio interno, un empleado malintencionado que pueda leer la clave podría usar las credenciales para aumentar sus privilegios. Google Cloud
Para definir una estrategia que permita gestionar estas credenciales persistentes, debe proporcionar alternativas viables, limitar la proliferación de credenciales persistentes y gestionar cómo se usan. Para obtener información sobre alternativas a las claves de cuentas de servicio, consulta Elegir el método de autenticación adecuado para tu caso práctico.
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 prácticos. Las otras opciones que se describen en las secciones siguientes son alternativas que puedes tener en cuenta si la opción 1 no se aplica a tu organización.
Todas las organizaciones creadas después del 23 de mayo del 2024 tienen Google Cloud restricciones de seguridad de referencia aplicadas cuando se crea el recurso de organización por primera vez. Con este cambio, la opción 1 se convierte en la opción predeterminada.
Opción 1: Restringir el uso de claves de cuentas de servicio persistentes
Te recomendamos que no permitas que ningún usuario descargue claves de cuentas de servicio, ya que las claves expuestas son un vector de ataque habitual. Restringir el uso de claves de cuentas de servicio persistentes es una opción que puede ayudar a reducir el riesgo y la sobrecarga de gestionar manualmente las claves de cuentas de servicio.
Para implementar esta opción, tenga 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. - Informa a tus equipos sobre las alternativas más seguras a las claves de cuentas de servicio. Por ejemplo, cuando los usuarios y las aplicaciones que no pertenecen a tu entorno deGoogle Cloud necesitan usar una cuenta de servicio, pueden autenticarse con la suplantación de identidad de cuenta de servicio o la federación de identidades de carga de trabajo en lugar de con una clave de cuenta de servicio.
- Diseña un proceso para que los equipos soliciten una excepción a esta política cuando descargar una clave de cuenta de servicio sea la única opción viable. Por ejemplo, un producto 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 si ya tienes herramientas para generar credenciales de API de corta duración para cuentas de servicio.
Para obtener más información, consulta las siguientes secciones:
- Restricciones de las políticas de organización en el Google Cloud plano de aspectos básicos de las empresas
- Prácticas recomendadas para trabajar con cuentas de servicio
Opción 2: Usar herramientas de gestión de acceso adicionales para generar credenciales de corta duración
Como alternativa a Restringir el uso de claves de cuenta de servicio persistentes, puedes generar credenciales de duración reducida para cuentas de servicio. Las credenciales de corta duración suponen menos riesgos que las credenciales persistentes, como las claves de cuentas 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 si ya has invertido en una herramienta de terceros para generar credenciales de corta duración para el control de acceso o si tienes presupuesto y capacidad suficientes para desarrollar tu propia solución.
Evita usar esta opción si no tienes herramientas para conceder credenciales de corta duración o si no tienes capacidad para crear tu propia solución.
Para obtener más información, consulta el artículo Crear credenciales de cuenta de servicio de duración reducida.
Decidir cómo mitigar la filtración externa de datos a través de las APIs de Google
Las APIs de Google tienen endpoints públicos que están disponibles para todos los clientes. Aunque todos los recursos de la API de tu entorno están sujetos a controles de acceso de gestión de identidades y accesos, existe el riesgo de que se acceda a los datos mediante credenciales robadas, que se filtren por agentes internos malintencionados o código vulnerado, o que se expongan a través de una política de gestión de identidades y accesos mal configurada. Google Cloud
Controles de Servicio de VPC es una solución que aborda estos riesgos. Sin embargo, Controles de Servicio de VPC también añade complejidad a tu modelo de acceso, por lo que debes diseñar Controles de Servicio de VPC para que se adapte a tu entorno y caso de uso únicos.
En las siguientes secciones se describen las opciones para mitigar la exfiltración de datos a través de las APIs de Google. Recomendamos la opción 1 para la mayoría de los casos prácticos. Las otras opciones que se describen en las siguientes secciones son alternativas que puedes tener en cuenta si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Configurar Controles de Servicio de VPC en todo el entorno
Te recomendamos que diseñes tu entorno en uno o varios perímetros de Controles de Servicio de VPC que restrinjan todas las APIs admitidas. Configura excepciones al perímetro con niveles de acceso o políticas de entrada para que los desarrolladores puedan acceder a los servicios que necesiten, incluido el acceso a la consola cuando sea necesario.
Usa esta opción cuando se cumplan las siguientes condiciones:
- Los servicios que quieres usar admiten Controles de Servicio de VPC y tus cargas de trabajo no requieren acceso a Internet sin restricciones.
- Almacenas datos sensibles en Google Cloud , lo que podría suponer una pérdida importante si se exfiltraran.
- Tienes atributos coherentes para el acceso de 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 si tus cargas de trabajo requieren acceso a Internet sin restricciones o servicios que no sean compatibles con Controles de Servicio de VPC.
Para obtener más información, consulta las siguientes secciones:
- Prácticas recomendadas para habilitar Controles de Servicio de VPC
- Productos admitidos y limitaciones de Controles de Servicio de VPC
- Diseñar y definir los perímetros de servicio
Opción 2: Configurar Controles de Servicio de VPC para un subconjunto de tu entorno
En lugar de configurar Controles de Servicio de VPC de forma general en todo tu entorno, puedes configurarlos solo en el subconjunto de proyectos que contengan datos sensibles y cargas de trabajo internas. Esta opción te permite usar un diseño y un funcionamiento más sencillos en la mayoría de los proyectos, sin dejar de priorizar la protección de datos en los proyectos que contengan datos sensibles.
Por ejemplo, puede plantearse esta alternativa cuando un número limitado de proyectos contenga conjuntos de datos de BigQuery con datos sensibles. Puedes definir un perímetro de servicio solo para estos proyectos y definir reglas de entrada y salida para permitir excepciones específicas a los analistas que necesiten usar estos conjuntos de datos.
Por ejemplo, en una aplicación con una arquitectura de tres niveles, algunos componentes pueden estar fuera del perímetro. El nivel de presentación que permite el acceso del tráfico de usuarios puede ser un proyecto fuera del perímetro, mientras que el nivel de aplicación y el nivel de datos que contienen datos sensibles pueden ser proyectos independientes dentro del perímetro de servicio. Defines reglas de entrada y salida para el perímetro de forma que los niveles puedan comunicarse entre sí a través del perímetro con un acceso granular.
Usa esta opción cuando se cumplan las siguientes condiciones:
- 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 otras requieren acceso público a Internet o tienen dependencias de servicios que no son compatibles con los controles de servicio de VPC.
- Configurar Controles de Servicio de VPC en todos los proyectos genera demasiada sobrecarga o requiere demasiadas soluciones alternativas
Evita esta opción cuando muchos proyectos puedan contener datos sensibles.
Para obtener más información, consulta las prácticas recomendadas para habilitar Controles de Servicio de VPC.
Opción 3: No configurar Controles de Servicio de VPC
Otra alternativa a configurar Controles de Servicio de VPC en todo tu entorno es no usar este servicio, sobre todo si la carga operativa supera el valor de Controles de Servicio de VPC.
Por ejemplo, es posible que tu organización no tenga un patrón coherente de acceso de desarrolladores que pueda constituir la base de una política de entrada. Puede que tus operaciones de TI estén subcontratadas a varios terceros, por lo que los desarrolladores no tienen dispositivos gestionados ni acceso desde direcciones IP coherentes. En este caso, es posible que no puedas definir reglas de entrada para permitir las excepciones al perímetro que necesitan los desarrolladores para completar sus operaciones diarias.
Usa esta opción cuando:
- Utilizas servicios que no admiten Controles de Servicio de VPC.
- Las cargas de trabajo están orientadas a Internet y no contienen datos sensibles.
- No tienes atributos coherentes de acceso de desarrollador, como dispositivos gestionados o intervalos de IP conocidos.
Evita esta opción si tienes datos sensibles en tu entorno de Google Cloud.
Decidir cómo monitorizar continuamente las configuraciones no seguras y las amenazas
La adopción de servicios en la nube plantea nuevos retos y amenazas en comparación con el uso de servicios locales. Es posible que las herramientas que ya tengas para monitorizar servidores de larga duración no sean adecuadas para los servicios efímeros o con escalado automático, y que no monitoricen los recursos sin servidor. Por lo tanto, debes evaluar las herramientas de seguridad que funcionen con toda la gama de servicios en la nube que puedas adoptar. También debes monitorizar continuamente los estándares de la nube, como el CIS Benchmark for Google Cloud.
En las siguientes secciones se describen las opciones de monitorización continua. Recomendamos la opción 1 para la mayoría de los casos prácticos. Las otras opciones que se describen en las siguientes secciones son alternativas que puedes tener en cuenta si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Usar Security Command Center
Te recomendamos que actives Security Command Center a nivel de organización, lo que te ayudará a reforzar tu posición de seguridad haciendo lo siguiente:
- Evaluar la superficie de ataque contra la seguridad y los datos
- Proporcionar inventario y descubrimiento de recursos
- Identificar errores de configuración, vulnerabilidades y amenazas
- Te ayudamos a mitigar y solucionar los riesgos
Si habilitas Security Command Center al principio de la creación de tu zona de aterrizaje, el equipo de seguridad de tu organización tendrá visibilidad casi en tiempo real de las configuraciones no seguras, las amenazas y las opciones de corrección. Esta visibilidad ayuda a tu equipo de seguridad a evaluar si la zona de aterrizaje cumple sus requisitos y si está lista para que los desarrolladores empiecen a implementar aplicaciones.
Usa esta opción cuando se cumplan las siguientes condiciones:
- Quieres una herramienta de gestión de la postura de seguridad y detección de amenazas que esté integrada con todos los servicios Google Cloud sin necesidad de realizar integraciones adicionales.
- Quieres usar la misma inteligencia frente a amenazas, el mismo aprendizaje automático y otros métodos avanzados que Google utiliza para proteger sus propios servicios.
- Tu centro de operaciones de seguridad (SOC) no tiene las habilidades ni la capacidad necesarias para generar información valiosa sobre las amenazas a partir de un gran volumen de registros de la nube.
Evita esta opción si tus herramientas de seguridad actuales pueden abordar por completo los recursos de nube efímeros o sin servidor, monitorizar las configuraciones no seguras e identificar amenazas a gran escala en un entorno de nube.
Opción 2: Usar las herramientas de seguridad que ya tienes para gestionar la postura de seguridad en la nube y detectar amenazas
Como alternativa a Security Command Center, puedes usar otras herramientas de gestión de la postura de seguridad en la nube. Hay varias herramientas de terceros que tienen funciones similares a Security Command Center, y es posible que ya hayas invertido en herramientas nativas de la nube centradas en entornos multicloud.
También puedes usar Security Command Center y herramientas de terceros conjuntamente. Por ejemplo, puedes ingerir las notificaciones de detecciones de Security Command Center en otra herramienta o añadir un servicio de seguridad de terceros al panel de control de Security Command Center. Otro ejemplo: puede que tengas que almacenar registros en un sistema SIEM para que el equipo del SOC analice las amenazas. Puedes configurar tu SIEM para que ingiera solo las notificaciones de resultados que genera Security Command Center, en lugar de ingerir un gran volumen de registros y esperar que un equipo de SOC analice los registros sin procesar para obtener información valiosa.
Usa esta opción cuando tus herramientas de seguridad puedan abordar por completo los recursos en la nube efímeros o sin servidor, monitorizar las configuraciones no seguras e identificar amenazas a gran escala en un entorno de nube.
Evita esta opción si se cumple lo siguiente:
- Tu SOC no tiene las habilidades ni la capacidad necesarias para generar información valiosa sobre amenazas a partir del gran volumen de registros de la nube.
- Integrar varias herramientas de terceros con varios servicios Google Cloud introduce más complejidad que valor.
Para obtener más información, consulta las siguientes secciones:
- Habilitar la búsqueda de notificaciones de Pub/Sub
- Gestionar fuentes de seguridad con la API de Security Command Center
- Añadir un servicio de seguridad de terceros
Decidir cómo agregar de forma centralizada los registros necesarios
La mayoría de los registros de auditoría se almacenan en el Google Cloud proyecto que los generó. A medida que tu entorno crece, puede ser insostenible para un auditor comprobar los registros de cada proyecto. Por lo tanto, debes decidir cómo se centralizarán y agregarán los registros para ayudar a tus operaciones de auditoría interna 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 prácticos. Las otras opciones que se describen en las siguientes secciones son alternativas que puedes tener en cuenta si la opción 1 no se aplica a tu caso práctico específico.
Opción 1: Conservar los registros en Google Cloud mediante 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 necesite tu equipo de seguridad. Puedes consultar la herramienta de definición del ámbito de los registros para identificar los registros que necesita tu equipo de seguridad y si estos tipos de registros requieren que se habiliten explícitamente.
Por ejemplo, el equipo de seguridad espera un registro central de todos los recursos que creen tus usuarios para poder monitorizar e investigar los cambios sospechosos. El equipo de seguridad también necesita un registro inmutable del acceso a los datos de determinadas cargas de trabajo altamente sensibles. Por lo tanto, el equipo de seguridad configura un receptor de registros para agregar los registros de auditoría de la actividad de los administradores de todos los proyectos en un contenedor de Analíticas de registros de un proyecto central que pueden consultar para realizar investigaciones improvisadas. A continuación, configuran un segundo sumidero de registros para los registros de auditoría de acceso a datos de proyectos con cargas de trabajo sensibles en un segmento de Cloud Storage para conservarlos a largo plazo.
Usa esta opción cuando se cumplan las siguientes condiciones:
- Tu equipo de seguridad necesita un registro central de todos los registros de auditoría u otros tipos de registros específicos.
- Tu equipo de seguridad necesita almacenar los registros en un entorno con acceso restringido, fuera del control de la carga de trabajo o de los equipos que hayan generado el registro.
Evita esta opción si se cumple lo siguiente:
- Tu organización no tiene un requisito central para registros de auditoría coherentes en todas las cargas de trabajo.
- Los propietarios de proyectos individuales tienen la responsabilidad total de gestionar sus propios registros de auditoría.
Para obtener más información, consulta las siguientes secciones:
- Controles de detección en el plano de los aspectos básicos de las empresas
- Prácticas recomendadas de Registros de auditoría de Cloud
- Configurar sumideros agregados
- Herramienta de definición del ámbito de los registros
- Políticas de retención y bloqueos de políticas de retención
Opción 2: Exportar los registros de auditoría necesarios a un almacenamiento externo a Google Cloud
Como alternativa a almacenar registros solo en Google Cloud , considera la posibilidad de exportar registros de auditoría fuera de Google Cloud. Después de centralizar los tipos de registro necesarios en un sumidero de registro agregado en Google Cloud, ingiere el contenido de ese sumidero en otra plataforma fuera deGoogle Cloud para almacenar y analizar los registros.
Por ejemplo, puede usar un SIEM de terceros para agregar y analizar registros de auditoría de varios proveedores de la nube. Esta herramienta tiene las funciones suficientes para trabajar con recursos de nube sin servidor, y tu equipo del SOC tiene las habilidades y la capacidad para generar información valiosa a partir de este gran volumen de registros.
Esta opción puede ser muy cara debido al coste de salida de la red en Google Cloud, así como al coste y la capacidad de almacenamiento en el otro entorno. En lugar de exportar todos los registros disponibles, te recomendamos que selecciones los que necesites en el entorno externo.
Utilice esta opción cuando necesite almacenar registros de todos los entornos y proveedores de servicios en la nube en una única ubicación central.
Evita esta opción si se cumple lo siguiente:
- Tus sistemas no tienen la capacidad ni el presupuesto necesarios para ingerir un gran volumen de registros de nube adicionales.
- Tus sistemas actuales requieren esfuerzos de integración para cada tipo y formato de registro.
- Estás recogiendo registros sin un objetivo claro de cómo se van a usar.
Para obtener más información, consulta los controles de detección en el plano técnico de las bases de la empresa.
Decidir cómo cumplir los requisitos de cumplimiento para el cifrado en reposo
Google Cloud encripta automáticamente todo el contenido almacenado en reposo mediante uno o varios mecanismos de cifrado. En función de tus requisitos de cumplimiento, es posible que tengas la obligación de gestionar las claves de cifrado.
En las siguientes secciones se describen las opciones de cifrado en reposo. Recomendamos la opción 1 para la mayoría de los casos prácticos. Las otras opciones que se describen en las siguientes secciones son alternativas que puedes tener en cuenta si la opción 1 no se aplica a tu caso de uso específico.
Opción 1: Aceptar el uso del encriptado en reposo predeterminado
El cifrado predeterminado en reposo es suficiente para muchos casos prácticos que no tienen requisitos de cumplimiento específicos en cuanto a la gestión de claves de cifrado.
Por ejemplo, el equipo de seguridad de una empresa de juegos online requiere que todos los datos de los clientes estén cifrados en reposo. No tienen requisitos normativos sobre la gestión de claves y, tras revisar el cifrado predeterminado en reposo de Google, consideran que es un control suficiente para sus necesidades.
Usa esta opción cuando se cumplan las siguientes condiciones:
- No tienes requisitos específicos sobre cómo encriptar los datos o cómo se gestionan las claves de encriptado.
- Prefieres un servicio gestionado en lugar del coste y la sobrecarga operativa que supone gestionar tus propias claves de cifrado.
No uses esta opción si tienes requisitos de cumplimiento que gestionar tus propias claves de cifrado.
Para obtener más información, consulta Cifrado en reposo en Google Cloud.
Opción 2: Gestionar las claves de cifrado con Cloud KMS
Además del cifrado en reposo predeterminado, es posible que necesites más control sobre las claves usadas para cifrar los datos en reposo de un proyecto de Google Cloud . Cloud Key Management Service (Cloud KMS) ofrece la posibilidad de proteger tus datos mediante claves de cifrado gestionadas por el cliente (CMEK). Por ejemplo, en el sector de los servicios financieros, es posible que tengas que informar a tus auditores externos sobre cómo gestionas tus propias claves de cifrado para datos sensibles.
Para añadir más capas de control, puedes configurar módulos de seguridad de hardware (HSM) o gestión de claves externa (EKM) con CMEK. No se recomiendan las claves de cifrado proporcionadas por el cliente (CSEK). Los casos prácticos que se abordaban con CSEK ahora se gestionan mejor con Cloud External Key Manager (Cloud EKM), ya que Cloud EKM es compatible con más servicios y tiene una mayor disponibilidad.
Con esta opción, los desarrolladores de aplicaciones tienen la responsabilidad de seguir la gestión de claves que exija tu equipo de seguridad. El equipo de seguridad puede aplicar el requisito bloqueando la creación de recursos que no cumplan los requisitos con políticas de organización de CMEK.
Usa esta opción si se cumple una o varias de las siguientes condiciones:
- Tienes que gestionar el ciclo de vida de tus propias claves.
- Tienes que generar material de clave criptográfica con un HSM que tenga la certificación FIPS 140-2 de nivel 3.
- Tienes que almacenar material de claves criptográficas fuera deGoogle Cloud con Cloud EKM.
Evita esta opción si se cumple lo siguiente:
- No tienes requisitos específicos sobre cómo cifrar los datos o cómo se gestionan las claves de cifrado.
- Prefieres un servicio gestionado en lugar del coste y la sobrecarga operativa que supone gestionar tus propias claves de cifrado.
Para obtener más información, consulta las siguientes secciones:
- Gestionar claves de cifrado con Cloud Key Management Service en el blueprint de bases de la empresa
- Claves de encriptado gestionadas por el cliente (CMEK)
- Cloud HSM
- Cloud External Key Manager
- Políticas de organización de CMEK
Opción 3: Tokenizar los datos en la capa de aplicación antes de conservarlos en el almacenamiento
Además del cifrado predeterminado que ofrece Google, también puedes desarrollar tu propia solución para tokenizar los datos antes de almacenarlos en Google Cloud.
Por ejemplo, un científico de datos debe analizar un conjunto de datos con información personal identificable, 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, puedes desarrollar una canalización de ingestión con Protección de Datos Sensibles para ingerir y tokenizar datos sensibles, y, a continuación, conservar los datos tokenizados en BigQuery.
La tokenización de datos no es un control que puedas aplicar de forma centralizada en la zona de aterrizaje. En su lugar, esta opción transfiere la responsabilidad a los desarrolladores de aplicaciones para que configuren su propio cifrado o a un equipo de plataforma que desarrolle un canal de cifrado como servicio compartido para que lo usen los desarrolladores de aplicaciones.
Usa esta opción cuando determinadas cargas de trabajo tengan datos especialmente sensibles que no se deban usar en su formato sin procesar.
Evita esta opción cuando Cloud KMS sea suficiente para cumplir tus requisitos, tal como se describe en Gestionar claves de encriptado con Cloud KMS. Mover datos a través de canalizaciones de cifrado y descifrado adicionales aumenta el coste, la latencia y la complejidad de las aplicaciones.
Para obtener más información, consulta la descripción general de la protección de datos sensibles.
Decidir cómo cumplir los requisitos de cumplimiento para el cifrado en tránsito
Google Cloud cuenta con varias medidas de seguridad para preservar la autenticidad, la integridad y la privacidad de los datos en tránsito. En función de tus requisitos de seguridad y cumplimiento, también puedes configurar el cifrado de la capa de aplicación.
En las siguientes secciones se describen las opciones de cifrado en tránsito. Recomendamos la opción 1 para la mayoría de los casos prácticos. Las otras opciones que se describen en las secciones siguientes son funciones adicionales que puedes tener en cuenta si la opción 1 no es suficiente para tu caso práctico específico.
Opción 1: Evalúa si el Google Cloud cifrado en tránsito es suficiente
Muchos patrones de tráfico de tu zona de aterrizaje se benefician del Google Cloud cifrado en tránsito predeterminado.
- Las conexiones entre máquinas virtuales dentro de las redes de VPC y las redes de VPC emparejadas que se encuentran dentro de la red de producción de Google están protegidas con integridad y encriptadas.
El tráfico de Internet a los servicios de Google y el tráfico de tu red VPC a los servicios de Google finalizan en el frontend de Google (GFE). GFE también hace lo siguiente:
- Proporciona contramedidas contra ataques DDoS
- Encamina y balancea el tráfico a los servicios de Google Cloud .
La infraestructura de Google usa ALTS para la autenticación, la integridad y el encriptado de las conexiones desde el GFE a un Google Cloud servicio y de unGoogle Cloud servicio a otro Google Cloud servicio.
Utiliza esta opción cuando el cifrado en tránsito predeterminado sea suficiente para tus cargas de trabajo internas. Google Cloud
Añade protección adicional cuando se cumplan las siguientes condiciones:
- Permites el tráfico de entrada de Internet en tu red de VPC.
- Te estás conectando a tu entorno local.
En estos casos, debe configurar controles adicionales, tal como se explica en la opción 2: Requerir que las aplicaciones configuren el cifrado de capa 7 en tránsito y en la opción 3: Configurar cifrado adicional en su entorno local.
Para obtener más información sobre el Google Cloud cifrado predeterminado en tránsito, consulta el artículo Cifrado en tránsito en Google Cloud.
Opción 2: Configurar un cifrado adicional para el tráfico hacia o desde las aplicaciones de tus clientes
Además del cifrado predeterminado en tránsito, puedes configurar el cifrado de capa 7 para el tráfico de aplicaciones a tus aplicaciones de cliente.Google Cloud proporciona servicios gestionados para admitir aplicaciones que necesiten cifrado de capa de aplicación en tránsito, incluidos los certificados gestionados y Cloud Service Mesh.
Por ejemplo, un desarrollador está creando una aplicación nueva que acepta tráfico de entrada de Internet. Usan un balanceador de carga de aplicaciones externo con certificados SSL gestionados por Google para ejecutar y escalar servicios con una sola dirección IP.
El cifrado de la capa de aplicación no es un control que puedas aplicar de forma centralizada en la zona de aterrizaje. En su lugar, esta opción delega en los desarrolladores de aplicaciones la responsabilidad de configurar el cifrado en tránsito.
Usa esta opción cuando las aplicaciones requieran tráfico HTTPS o SSL entre componentes.
Considera la posibilidad de permitir una excepción limitada a esta opción cuando migres cargas de trabajo de computación a la nube que no requerían cifrado en tránsito para el tráfico interno cuando las aplicaciones estaban en las instalaciones. Durante una migración a gran escala, obligar a modernizar las aplicaciones antiguas antes de la migración puede provocar un retraso inaceptable en el programa.
Para obtener más información, consulta las siguientes secciones:
- Usar certificados SSL gestionados por Google
- Usar certificados SSL autogestionados
- Cloud Service Mesh
Opción 3: Configurar un cifrado adicional en tu entorno local
Si necesitas una conexión de Google Cloud a tu entorno on-premise, puedes configurar Cloud Interconnect, que establece una conexión física directa entre Google Cloud y tus centros de datos. Cuando se usa Cloud Interconnect, el tráfico de tu entorno on-premise a Google Cloudno se cifra de forma predeterminada durante la transmisión. Por lo tanto, si usas Cloud Interconnect, te recomendamos que habilites MACsec para Cloud Interconnect como parte de tu zona de aterrizaje.
Si usas una VPN de alta disponibilidad para conectar el tráfico privado entre Google Cloud y tus centros de datos, el tráfico usará el cifrado IPsec de forma predeterminada.
Para obtener más información, consulta Elegir un producto de Network Connectivity Center.
Decide qué controles adicionales son necesarios para gestionar el acceso de los proveedores de servicios en la nube
La necesidad de auditar el acceso de los proveedores de servicios en la nube (CSP) puede ser un problema durante la adopción de la nube. Google Cloud proporciona varias capas de control que permiten verificar el acceso de los proveedores de la nube.
En las siguientes secciones se describen las opciones para gestionar el acceso de los proveedores de servicios de cifrado. Recomendamos la opción 1 para la mayoría de los casos prácticos. La otra opción que se describe en las secciones siguientes es una función adicional que puedes tener en cuenta si la opción 1 no es suficiente para tu caso práctico específico.
Opción 1: Habilitar los registros de Transparencia de acceso
Los registros de Transparencia de acceso registran las acciones que lleva a cabo el personal de Google Cloud en tu entorno, como cuando soluciona un problema de asistencia.
Por ejemplo, tu desarrollador plantea un problema de solución de errores al equipo de Asistencia de Google Cloud y pide al agente que le ayude a solucionar los problemas de su entorno. Se genera un registro de Transparencia de acceso para mostrar las acciones que ha llevado a cabo el personal de Asistencia, incluido el número de caso que las justifica.
Usa esta opción cuando se cumplan las siguientes condiciones:
- Tienes que verificar que el personal Google Cloud accede a tu contenido únicamente por motivos comerciales válidos, como solucionar una interrupción o atender tus solicitudes de asistencia.
- Tienes que cumplir un requisito para monitorizar el acceso a datos sensibles.
Opción 2: Habilitar los registros de Transparencia de acceso y la gestión de acceso del proveedor
Si tu empresa tiene un requisito de cumplimiento que exige que se conceda una aprobación explícita antes de que un proveedor de servicios en la nube pueda acceder a tu entorno, además de la opción 1, puedes usar Transparencia de acceso con otros controles que te permitan aprobar o denegar explícitamente el acceso a tus datos.
Aprobación de acceso es una solución manual que asegura que el equipo de Atención al Cliente y el equipo de Ingeniería de Google necesiten tu aprobación explícita (por correo o mediante un webhook) siempre que necesiten acceder a tu contenido.
Justificaciones de Acceso a Claves es una solución programática que añade un campo de justificación a cualquier solicitud de claves de cifrado configuradas con Cloud EKM.
Usa esta opción cuando se cumplan las siguientes condiciones:
- Quieres que un equipo central gestione directamente el acceso al contenido por parte del personal de Google.
- En el caso de Aprobación de acceso, puedes aceptar el riesgo de que la capacidad central para aprobar o rechazar cada solicitud de acceso sea más importante que la contrapartida operativa, que podría ser una resolución más lenta de los casos de asistencia.
- En el caso de las justificaciones de acceso a claves, tu empresa ya utiliza Cloud External Key Manager como parte de su estrategia de cifrado y quiere tener control programático sobre todos los tipos de acceso a los datos cifrados (no solo el acceso del personal de Google a los datos).
Evita esta opción si se cumple lo siguiente:
- El retraso operativo que puede producirse cuando un equipo central con autoridad de aprobación de acceso debe responder es un riesgo inaceptable para las cargas de trabajo que requieren una alta disponibilidad y una respuesta rápida del equipo de Atención al Cliente.
Para obtener más información, consulta las siguientes secciones:
Prácticas recomendadas de seguridad para las Google Cloud zonas de aterrizaje
Además de las decisiones que se han introducido en este documento, tenga en cuenta las siguientes prácticas recomendadas de seguridad:
- Aprovisiona las identidades en tu entorno. Para obtener más información, consulta Decidir cómo incorporar identidades a Google Cloud.
- Diseña una red que se ajuste a los casos prácticos de tu organización. Para obtener más información, consulta Decide el diseño de red de tu zona de aterrizaje de Google Cloud .
- Implementa las restricciones de política de organización que se definen en el plano de aspectos básicos de las empresas. Estas restricciones ayudan a evitar problemas de seguridad habituales, como la creación de direcciones IP externas innecesarias o la asignación del rol Editor a todas las cuentas de servicio.
- Consulta la lista completa de restricciones de políticas de la organización para evaluar si otros controles se ajustan a tus requisitos. Todas las organizaciones creadas después del 23 de mayo del 2024 tienen Google Cloud restricciones de seguridad de referencia aplicadas cuando se crea el recurso de organización por primera vez. Con este cambio, la opción 1 se convierte en la opción predeterminada.
Siguientes pasos
- Consulta el plano de los fundamentos de Google Cloud para empresas.
- Consulta más prácticas recomendadas de seguridad en el Google Cloud framework Well-Architected.