Importar datos en un almacén de datos de BigQuery seguro

Last reviewed 2025-06-15 UTC

Muchas organizaciones implementan almacenes de datos que almacenan datos sensibles para poder analizarlos con diversos fines empresariales. Este documento está dirigido a ingenieros de datos y administradores de seguridad que implementan y protegen almacenes de datos con BigQuery. Forma parte de un plan que se compone de lo siguiente:

En este documento se trata lo siguiente:

  • La arquitectura y los Google Cloud servicios que puedes usar para proteger un almacén de datos en un entorno de producción.
  • Prácticas recomendadas para importar datos a BigQuery desde una red externa, como un entorno local.

  • Prácticas recomendadas para la gobernanza de datos al crear, implementar y operar un almacén de datos enGoogle Cloud, entre las que se incluyen las siguientes:

    • datos de desidentificación

    • tratamiento diferencial de datos confidenciales

    • cifrado a nivel de columna

    • controles de acceso a nivel de columna

En este documento se da por hecho que ya has configurado un conjunto básico de controles de seguridad, tal como se describe en el plan de bases de la empresa. Te ayuda a añadir controles adicionales a los controles de seguridad que ya tienes para proteger los datos confidenciales de un almacén de datos.

Casos prácticos de almacenes de datos

El plan admite los siguientes casos prácticos:

Información general

Los almacenes de datos, como BigQuery, permiten a las empresas analizar sus datos empresariales para obtener información valiosa. Los analistas acceden a los datos empresariales almacenados en los almacenes de datos para obtener estadísticas. Si tu almacén de datos incluye datos confidenciales, debes tomar medidas para preservar la seguridad, la confidencialidad, la integridad y la disponibilidad de los datos empresariales mientras están almacenados, en tránsito o en proceso de análisis. En este plan, harás lo siguiente:

  • Cuando importe datos de fuentes de datos externas, cifre los datos que se encuentren fuera de Google Cloud (por ejemplo, en un entorno local) e impórtelos a Google Cloud.
  • Configura controles que ayuden a proteger el acceso a datos confidenciales.
  • Configurar controles que ayuden a proteger la canalización de datos.
  • Configura una separación de tareas adecuada para los distintos perfiles.
  • Cuando importe datos de otras fuentes ubicadas en Google Cloud (también conocidas como fuentes de datos internas), configure plantillas para buscar y anonimizar datos confidenciales.
  • Configura los controles de seguridad y el registro adecuados para proteger los datos confidenciales.
  • Usa la clasificación de datos, las etiquetas de políticas, el enmascaramiento dinámico de datos y el cifrado a nivel de columna para restringir el acceso a columnas específicas del almacén de datos.

Arquitectura

Para crear un almacén de datos confidenciales, debe importar los datos de forma segura y, a continuación, almacenarlos en un perímetro de Controles de Servicio de VPC.

Arquitectura al importar datos de Google Cloud

En la siguiente imagen se muestra cómo se categorizan, anonimizan y almacenan los datos ingeridos cuando se importan datos de origen de Google Cloud mediante el repositorio terraform-google-secured-data-warehouse. También se muestra cómo puedes volver a identificar datos confidenciales bajo demanda para analizarlos.

Arquitectura del almacén de datos sensibles para fuentes internas.

Arquitectura al importar datos de fuentes externas

En la siguiente imagen se muestra cómo se ingieren y almacenan los datos cuando se importan datos de un entorno local u otra nube a un almacén de BigQuery mediante el repositorio terraform-google-secured-data-warehouse-onprem-ingest.

Arquitectura del almacén de datos sensibles para redes externas.

Servicios y funciones deGoogle Cloud

Las arquitecturas usan una combinación de los siguientes Google Cloud servicios y funciones:

Servicio o función Descripción

BigQuery

Se aplica tanto a las fuentes de datos internas como a las externas. Sin embargo, existen diferentes opciones de almacenamiento, como las siguientes:

  • Al importar datos de Google Cloud, BigQuery almacena los datos confidenciales en el perímetro de datos confidenciales.
  • Cuando se importan datos de una fuente externa, BigQuery almacena los datos cifrados y la clave de cifrado envuelta en tablas independientes.

BigQuery usa varios controles de seguridad para proteger el contenido, como controles de acceso, seguridad a nivel de columna para datos confidenciales y cifrado de datos.

Cloud Key Management Service (Cloud KMS) con Cloud HSM

Se aplica tanto a fuentes internas como externas. Sin embargo, las fuentes de datos externas tienen otro caso práctico.

Cloud HSM es un servicio de módulo de seguridad de hardware (HSM) basado en la nube que aloja la clave de encriptado de claves (KEK). Cuando importa datos de una fuente externa, usa Cloud HSM para generar la clave de cifrado que utiliza para cifrar los datos de su red antes de enviarlos a Google Cloud.

Cloud Logging

Se aplica tanto a fuentes internas como externas.

Cloud Logging recoge todos los registros de los Google Cloud servicios para almacenarlos y recuperarlos con tus herramientas de análisis e investigación.

Cloud Monitoring

Se aplica tanto a fuentes internas como externas.

Cloud Monitoring recoge y almacena información sobre el rendimiento y métricas de los Google Cloud servicios.

Cloud Run Functions

Solo se aplica a fuentes de datos externas.

Las funciones de Cloud Run se activan mediante Cloud Storage y escriben los datos que Cloud Storage sube al segmento de ingestión en BigQuery.

Cloud Storage y Pub/Sub

Se aplica tanto a fuentes internas como externas.

Cloud Storage y Pub/Sub reciben datos de la siguiente manera:

  • Cloud Storage: recibe y almacena datos por lotes. De forma predeterminada, Cloud Storage usa TLS para encriptar los datos en tránsito y AES-256 para encriptar los datos almacenados. La clave de cifrado es una clave de cifrado gestionada por el cliente (CMEK). Para obtener más información sobre el cifrado, consulta las opciones de cifrado de datos.

    Puedes proteger el acceso a los segmentos de Cloud Storage mediante controles de seguridad, como Gestión de Identidades y Accesos, listas de control de acceso (LCAs) y documentos de políticas. Para obtener más información sobre los controles de acceso admitidos, consulta Descripción general del control de acceso.

Data Profiler para BigQuery

Se aplica tanto a fuentes internas como externas.

Data Profiler para BigQuery busca automáticamente datos sensibles en todas las tablas y columnas de BigQuery de toda la organización, incluidas todas las carpetas y proyectos.

Pipelines de Dataflow

Se aplica tanto a fuentes internas como externas. Sin embargo, existen diferentes pipelines.

Los flujos de procesamiento de Dataflow importan datos de la siguiente manera:

  • Al importar datos de Google Cloud, dos canalizaciones de Dataflow desidentifican y vuelven a identificar los datos confidenciales. La primera canalización anonimiza los datos confidenciales mediante la seudonimización. La segunda canalización vuelve a identificar los datos confidenciales cuando los usuarios autorizados necesitan acceder a ellos.
  • Al importar datos de una fuente externa, una canalización de Dataflow escribe datos de streaming en BigQuery.

Dataplex Universal Catalog

Se aplica tanto a fuentes internas como externas.

Dataplex Universal Catalog categoriza automáticamente los datos confidenciales con metadatos, también conocidos como etiquetas de política, durante la ingestión. Dataplex Universal Catalog también usa metadatos para gestionar el acceso a datos confidenciales. Para controlar el acceso a los datos de un almacén de datos, aplica etiquetas de política a las columnas que incluyan datos confidenciales.

Interconexión dedicada

Solo se aplica a fuentes de datos externas.

Dedicated Interconnect te permite mover datos entre tu red y Google Cloud. Puedes usar otra opción de conectividad, como se describe en el artículo Elegir un producto de conectividad de red.

Gestión de identidades y accesos y Administrador de recursos

Se aplica tanto a fuentes internas como externas.

Gestión de Identidades y Accesos (IAM) y Resource Manager restringen el acceso y segmentan los recursos. Los controles de acceso y la jerarquía de recursos siguen el principio de mínimos accesos.

Security Command Center

Se aplica tanto a fuentes internas como externas.

Security Command Center monitoriza y revisa los resultados de seguridad de todo tu Google Cloud entorno desde una ubicación central.

Protección de Datos Sensibles

Se aplica tanto a fuentes internas como externas, pero se realizan análisis diferentes.

Protección de Datos Sensibles analiza los datos de la siguiente manera:

  • Al importar datos de Google Cloud, Protección de Datos Sensibles desidentifica los datos confidenciales durante la ingestión. Protección de Datos Sensibles desidentifica los datos estructurados y no estructurados en función de los infoTypes o los registros que se detecten.
  • Al importar datos de una fuente externa, Protección de Datos Sensibles analiza los datos almacenados en BigQuery para buscar datos sensibles que no estén protegidos. Para obtener más información, consulta el artículo sobre cómo usar Protección de Datos Sensibles para analizar datos de BigQuery.

Controles de Servicio de VPC

Se aplica a fuentes internas y externas, pero con diferentes perímetros.

Controles de Servicio de VPC crea perímetros de seguridad que aíslan los servicios y los recursos configurando la autorización, los controles de acceso y el intercambio de datos seguro. Los perímetros son los siguientes:

  • Un perímetro de ingestión de datos acepta los datos entrantes (por lotes o en tiempo real) y los anonimiza. Una zona de aterrizaje independiente ayuda a proteger el resto de tus cargas de trabajo de los datos entrantes.
  • Al importar datos de Google Cloud, un perímetro de datos confidenciales puede volver a identificar los datos confidenciales y almacenarlos en un área restringida.
  • Al importar datos externos, un perímetro de datos aísla los datos de cifrado de otras cargas de trabajo.
  • Un perímetro de control almacena las claves de cifrado y define qué se considera datos confidenciales.

Estos perímetros se han diseñado para proteger el contenido entrante, aislar los datos confidenciales configurando controles de acceso y monitorización adicionales, y separar la gobernanza de los datos reales del almacén. Tu gobernanza incluye la gestión de claves, la gestión del catálogo de datos y el registro.

Estructura de la organización

Agrupa los recursos de tu organización para poder gestionarlos y separar los entornos de prueba del entorno de producción. Resource Manager te permite agrupar recursos de forma lógica por proyecto, carpeta y organización.

En los siguientes diagramas se muestra una jerarquía de recursos con carpetas que representan diferentes entornos, como bootstrap, common, producción, no producción (o staging) y desarrollo. La mayoría de los proyectos de la arquitectura se implementan en la carpeta de producción, y el proyecto de gobierno de datos en la carpeta común, que se usa para el gobierno.

Estructura de la organización al importar datos de Google Cloud

En el siguiente diagrama se muestra la estructura de la organización al importar datos deGoogle Cloud mediante el repositorio terraform-google-secured-data-warehouse.

La jerarquía de recursos de un almacén de datos sensibles de fuentes internas.

Estructura de la organización al importar datos de fuentes externas

En el siguiente diagrama se muestra la estructura de la organización al importar datos de una fuente externa mediante el repositorio terraform-google-secured-data-warehouse-onprem-ingest.

La jerarquía de recursos de un almacén de datos sensibles de fuentes externas.

Carpetas

Usa carpetas para aislar tu entorno de producción y tus servicios de gobernanza de tus entornos de prueba y no de producción. En la siguiente tabla se describen las carpetas del blueprint de las bases de la empresa que utiliza esta arquitectura.

Carpeta Descripción

Bootstrap

Contiene los recursos necesarios para desplegar el blueprint de las bases de la empresa.

Común

Contiene servicios centralizados para la organización, como el proyecto de gobernanza de datos.

Producción

Contiene proyectos con recursos en la nube que se han probado y están listos para usarse. En esta arquitectura, la carpeta Production contiene el proyecto DataIngestion y los proyectos relacionados con los datos.

Fuera de producción

Contiene proyectos que tienen recursos en la nube que se están probando y preparando para su lanzamiento. En esta arquitectura, la carpeta Non-production contiene el proyecto de ingestión de datos y los proyectos relacionados con los datos.

Desarrollo

Contiene proyectos que tienen recursos en la nube que se están desarrollando. En esta arquitectura, la carpeta Development contiene el proyecto DataIngestion y otros proyectos relacionados con los datos.

Puede cambiar los nombres de estas carpetas para que se ajusten a la estructura de carpetas de su organización, pero le recomendamos que mantenga una estructura similar. Para obtener más información, consulta el plan de fundamentos empresariales.

Proyectos

Puedes aislar partes de tu entorno mediante proyectos. En la siguiente tabla se describen los proyectos que se necesitan en la organización. Estos proyectos se crean al ejecutar el código de Terraform. Puedes cambiar los nombres de estos proyectos, pero te recomendamos que mantengas una estructura similar.

Proyecto Descripción

Ingestión de datos

Proyecto común para fuentes internas y externas.

Contiene servicios que son necesarios para recibir datos y desidentificar datos confidenciales.

Gobierno de datos

Proyecto común para fuentes internas y externas.

Contiene servicios que proporcionan funciones de gestión de claves, registro y catalogación de datos.

Datos no confidenciales

Proyecto solo para fuentes internas.

Contiene servicios que son necesarios para almacenar datos anonimizados.

Datos confidenciales

Proyecto solo para fuentes internas.

Contiene los servicios necesarios para almacenar y volver a identificar datos confidenciales.

Datos

Proyecto solo para fuentes externas.

Contiene los servicios necesarios para almacenar datos.

Además de estos proyectos, tu entorno también debe incluir un proyecto que aloje una tarea de plantilla flexible de Dataflow. La tarea de plantilla flexible es obligatoria para la canalización de datos de streaming.

Asignar roles y grupos a proyectos

Debes dar acceso a los distintos grupos de usuarios de tu organización a los proyectos que componen el almacén de datos confidenciales. En las siguientes secciones se describen las recomendaciones de arquitectura para los grupos de usuarios y las asignaciones de roles en los proyectos que crees. Puedes personalizar los grupos para que se adapten a la estructura de tu organización, pero te recomendamos que mantengas una segregación de funciones y una asignación de roles similares.

Grupo de analistas de datos

Los analistas de datos analizan los datos del almacén. En el repositorio terraform-google-secured-data-warehouse-onprem-ingest, este grupo puede ver los datos una vez que se hayan cargado en el almacén de datos y realizar las mismas operaciones que el grupo Visor de datos cifrados.

En la siguiente tabla se describen los roles del grupo en diferentes proyectos del repositorio terraform-google-secured-data-warehouse (solo fuentes de datos internas).

Asignación de proyectos Roles

Ingestión de datos

Rol adicional para los analistas de datos que necesiten acceder a datos confidenciales:

Datos confidenciales

Datos no confidenciales

En la siguiente tabla se describen los roles del grupo en diferentes proyectos del repositorio terraform-google-secured-data-warehouse-onprem-ingest (solo fuentes de datos externas).

Ámbito de la tarea Roles

Proyecto de ingestión de datos

Proyecto de datos

Nivel de la política de datos

Masked Reader (roles/bigquerydatapolicy.maskedReader)

Grupo de lectores de datos cifrados (solo fuentes externas)

El grupo Encrypted data viewer (Lector de datos cifrados) del repositorio terraform-google-secured-data-warehouse-onprem-ingest puede ver datos cifrados de las tablas de informes de BigQuery a través de Looker Studio y otras herramientas de creación de informes, como SAP Business Objects. El grupo de lectores de datos cifrados no puede ver datos en texto sin cifrar de columnas cifradas.

Este grupo requiere el rol Usuario de BigQuery (roles/bigquery.jobUser) en el proyecto de datos. Este grupo también requiere el rol Lector enmascarado (roles/bigquerydatapolicy.maskedReader) a nivel de política de datos.

Grupo de lectura de texto sin formato (solo fuentes externas)

El grupo de lectores de texto sin formato del repositorio terraform-google-secured-data-warehouse-onprem-ingest tiene el permiso necesario para llamar a la función definida por el usuario (UDF) de descifrado para ver los datos de texto sin formato y el permiso adicional para leer los datos sin máscara.

Este grupo requiere los siguientes roles en el proyecto de datos:

Además, este grupo requiere el rol Lector detallado (roles/datacatalog.categoryFineGrainedReader) a nivel de Dataplex Universal Catalog.

Grupo de ingenieros de datos

Los ingenieros de datos configuran y mantienen el flujo de procesamiento de datos y el almacén de datos.

En la siguiente tabla se describen los roles del grupo en diferentes proyectos del repositorio terraform-google-secured-data-warehouse.

Puntuación de la tarea Roles

Proyecto de ingestión de datos

Proyecto de datos confidenciales

Proyecto de datos no confidenciales

En la siguiente tabla se describen los roles del grupo en diferentes proyectos del repositorio terraform-google-secured-data-warehouse-onprem-ingest.

Ámbito de la tarea Roles

Proyecto de ingestión de datos

Proyecto de datos

Grupo de administradores de red

Los administradores de red configuran la red. Normalmente, son miembros del equipo de redes.

Los administradores de redes necesitan los siguientes roles a nivel de organización:

Grupo de administradores de seguridad

Los administradores de seguridad gestionan los controles de seguridad, como el acceso, las claves, las reglas de cortafuegos, los controles de servicio de VPC y Security Command Center.

Los administradores de seguridad necesitan los siguientes roles a nivel de organización:

Grupo de analistas de seguridad

Los analistas de seguridad monitorizan los incidentes de seguridad y las detecciones de protección de datos sensibles, y responden a ellos.

Los analistas de seguridad necesitan los siguientes roles a nivel de organización:

Ejemplos de flujos de acceso a grupos para fuentes externas

En las siguientes secciones se describen los flujos de acceso de dos grupos al importar datos de fuentes externas mediante el repositorio terraform-google-secured-data-warehouse-onprem-ingest.

Flujo de acceso para el grupo de lectores de datos cifrados

En el siguiente diagrama se muestra lo que ocurre cuando un usuario del grupo de lectores de datos cifrados intenta acceder a datos cifrados en BigQuery.

El flujo del grupo de lectores de datos cifrados.

Para acceder a los datos de BigQuery, sigue estos pasos:

  1. El visor de datos cifrados ejecuta la siguiente consulta en BigQuery para acceder a los datos confidenciales:

    SELECT ssn, pan FROM cc_card_table

  2. BigQuery verifica el acceso de la siguiente manera:

    • El usuario se autentica con credenciales de Google Cloudválidas y no caducadas.
    • La identidad del usuario y la dirección IP desde la que se ha originado la solicitud forman parte de la lista de permitidos del nivel de acceso o de la regla de entrada del perímetro de Controles de Servicio de VPC.
    • Gestión de identidades y accesos verifica que el usuario tiene los roles adecuados y está autorizado para acceder a las columnas cifradas seleccionadas de la tabla de BigQuery.

BigQuery devuelve los datos confidenciales en formato cifrado.

Proceso de acceso para el grupo de lectores de texto sin formato

En el siguiente diagrama se muestra lo que ocurre cuando un usuario del grupo de lectores de texto sin cifrar intenta acceder a datos cifrados en BigQuery.

El flujo del grupo de lectores de texto sin formato.

Para acceder a los datos de BigQuery, sigue estos pasos:

  1. El lector de texto sin formato ejecuta la siguiente consulta en BigQuery para acceder a los datos confidenciales en formato descifrado:

    SELECT decrypt_ssn(ssn) FROM cc_card_table

  2. BigQuery llama a la función definida por el usuario (UDF) de descifrado en la consulta para acceder a las columnas protegidas.

  3. El acceso se verifica de la siguiente manera:

    • Gestión de identidades y accesos verifica que el usuario tiene los roles adecuados y está autorizado para acceder a la función definida por el usuario de descifrado en BigQuery.
    • La función definida por el usuario recupera la clave de cifrado de datos (DEK) envuelta que se ha usado para proteger las columnas de datos sensibles.

  4. La UDF de descifrado llama a la clave de cifrado de claves (KEK) de Cloud HSM para envolver la DEK. La función definida por el usuario de descifrado usa la función de descifrado AEAD de BigQuery para descifrar las columnas de datos sensibles.

  5. Se concede al usuario acceso a los datos en texto sin formato de las columnas de datos sensibles.

Controles de seguridad comunes

En las siguientes secciones se describen los controles que se aplican tanto a las fuentes internas como a las externas.

Controles de ingestión de datos

Para crear su almacén de datos, debe transferir datos de otra fuente (por ejemplo, un data lake), de su entorno local o de otra nube.Google Cloud Puede usar una de las siguientes opciones para transferir sus datos al almacén de datos de BigQuery:

  • Un trabajo por lotes que usa Cloud Storage.
  • Un trabajo de streaming que usa Pub/Sub.

Para proteger los datos durante la ingestión, puedes usar el cifrado del lado del cliente, reglas de firewall y políticas de nivel de acceso. El proceso de ingestión a veces se denomina proceso de extracción, transformación y carga (ETL).

Reglas de red y de cortafuegos

Las reglas de cortafuegos de la nube privada virtual (VPC) controlan el flujo de datos hacia los perímetros. Crea reglas de cortafuegos que denieguen todo el tráfico de salida, excepto las conexiones específicas del puerto TCP 443 de los nombres de dominio especiales restricted.googleapis.com. El dominio restricted.googleapis.com tiene las siguientes ventajas:

  • Ayuda a reducir la superficie de ataque de tu red mediante el acceso privado a Google cuando las cargas de trabajo se comunican con las APIs y los servicios de Google.
  • De esta forma, solo usas servicios que admiten Controles de Servicio de VPC.

Para obtener más información, consulta el artículo sobre cómo configurar Acceso privado a Google.

Cuando se usa el repositorio terraform-google-secured-data-warehouse, debe configurar subredes independientes para cada tarea de Dataflow. Las subredes independientes aseguran que los datos anonimizados estén separados correctamente de los datos que se están identificando de nuevo.

La canalización de datos requiere que abras puertos TCP en el cortafuegos, tal como se define en el archivo dataflow_firewall.tf de los repositorios correspondientes. Para obtener más información, consulta el artículo sobre cómo configurar el acceso a Internet y las reglas de cortafuegos.

Para denegar a los recursos la capacidad de usar direcciones IP externas, la política de organización Define allowed external IPs for VM instances (compute.vmExternalIpAccess) (Definir IPs externas permitidas para instancias de VM) se establece en "Deny all" (Denegar todo).

Controles perimetrales

Como se muestra en el diagrama de arquitectura, los recursos del almacén de datos se colocan en perímetros independientes. Para permitir que los servicios de diferentes perímetros compartan datos, debes crear puentes de perímetro.

Los perímetros puente permiten que los servicios protegidos hagan solicitudes de recursos fuera de su perímetro. Estos puentes establecen las siguientes conexiones para el repositorio terraform-google-secured-data-warehouse:

  • Conectan el proyecto de ingestión de datos con el proyecto de gobernanza para que la anonimización se pueda llevar a cabo durante la ingestión.
  • Conectan el proyecto de datos no confidenciales y el proyecto de datos confidenciales para que los datos confidenciales se puedan volver a identificar cuando lo solicite un analista de datos.
  • Conectan el proyecto confidencial al proyecto de gobernanza de datos para que se pueda volver a identificar a los usuarios cuando lo solicite un analista de datos.

Estos puentes establecen las siguientes conexiones para el repositorio terraform-google-secured-data-warehouse-onprem-ingest:

  • Conectan el proyecto de ingestión de datos con el proyecto de datos para que los datos se puedan ingerir en BigQuery.
  • Conectan el proyecto de datos al proyecto de gestión de datos para que Protección de Datos Sensibles pueda analizar BigQuery en busca de datos confidenciales sin protección.
  • Conectan el proyecto de ingestión de datos con el proyecto de gestión de datos para acceder a los registros, la monitorización y las claves de cifrado.

Además de los perímetros puente, puedes usar reglas de salida para permitir que los recursos protegidos por perímetros de servicio accedan a recursos que estén fuera del perímetro. En esta solución, se configuran reglas de salida para obtener las tareas de plantilla Flex de Dataflow externas que se encuentran en Cloud Storage en un proyecto externo. Para obtener más información, consulta Acceder a un recurso Google Cloud fuera del perímetro.

Política accedida

Para asegurarte de que solo identidades específicas (usuarios o servicios) puedan acceder a recursos y datos, habilita grupos y roles de gestión de identidades y accesos.

Para asegurarse de que solo fuentes específicas puedan acceder a sus proyectos, habilite una política de acceso para su organización de Google. Te recomendamos que crees una política de acceso que especifique el intervalo de direcciones IP permitidas para las solicitudes y que solo permita las solicitudes de usuarios o cuentas de servicio específicos. Para obtener más información, consulta Atributos de nivel de acceso.

Cuentas de servicio y controles de acceso

Las cuentas de servicio son identidades que Google Cloud pueden usar para ejecutar solicitudes de API en tu nombre. Las cuentas de servicio aseguran que las identidades de los usuarios no tengan acceso directo a los servicios. Para permitir la separación de tareas, crea cuentas de servicio con diferentes roles para fines específicos. Estas cuentas de servicio se definen en el módulo data-ingestion y en el módulo confidential-data de cada arquitectura.

En el repositorio de terraform-google-secured-data-warehouse, las cuentas de servicio son las siguientes:

  • Una cuenta de servicio de controlador de Dataflow para el flujo de procesamiento de Dataflow que desidentifica los datos confidenciales.
  • Una cuenta de servicio de controlador de Dataflow para la pipeline de Dataflow que vuelve a identificar los datos confidenciales.
  • Una cuenta de servicio de Cloud Storage para ingerir datos de un archivo por lotes.
  • Una cuenta de servicio de Pub/Sub para ingerir datos de un servicio de streaming.
  • Una cuenta de servicio de Cloud Scheduler para ejecutar la tarea de Dataflow por lotes que crea el flujo de procesamiento de Dataflow.

En la siguiente tabla se enumeran los roles asignados a cada cuenta de servicio:

Cuenta de servicio Nombre Proyecto Roles

Controlador de Dataflow

Esta cuenta se usa para anonimizar los datos.

sa-dataflow-controller

Ingestión de datos

Controlador de Dataflow

Esta cuenta se usa para reidentificar.

sa-dataflow-controller-reid

Datos confidenciales

Cloud Storage

sa-storage-writer

Ingestión de datos

Pub/Sub

sa-pubsub-writer

Ingestión de datos

Cloud Scheduler

sa-scheduler-controller

Ingestión de datos

En el repositorio terraform-google-secured-data-warehouse-onprem-ingest, las cuentas de servicio son las siguientes:

  • La cuenta de servicio de Cloud Storage ejecuta el proceso automatizado de subida de datos por lotes al segmento de almacenamiento de ingestión.
  • La cuenta de servicio de Pub/Sub permite transmitir datos al servicio Pub/Sub.
  • La cuenta de servicio del controlador de Dataflow se usa en la canalización de Dataflow para transformar y escribir datos de Pub/Sub en BigQuery.
  • La cuenta de servicio de Cloud Run Functions escribe los datos de lote posteriores que se suben de Cloud Storage a BigQuery.
  • La cuenta de servicio de subida de almacenamiento permite que el flujo de procesamiento de ETL cree objetos.
  • La cuenta de servicio de escritura de Pub/Sub permite que la canalización de ETL escriba datos en Pub/Sub.

En la siguiente tabla se enumeran los roles asignados a cada cuenta de servicio:

Nombre Roles Ámbito de la asignación

Cuenta de servicio del controlador de Dataflow

Proyecto de ingestión de datos

Proyecto de datos

Gobierno de datos

Cuenta de servicio de Cloud Run Functions

Proyecto de ingestión de datos

Proyecto de datos

Cuenta de servicio de subida de Storage

Proyecto de ingestión de datos

Cuenta de servicio de escritura de Pub/Sub

Proyecto de ingestión de datos

Políticas de organización

Esta arquitectura incluye las restricciones de la política de la organización que usa el blueprint de las bases de la empresa y añade otras restricciones. Para obtener más información sobre las restricciones que usa el plan de empresa, consulta Restricciones de la política de la organización.

En la siguiente tabla se describen las restricciones de la política de la organización adicionales que se definen en el módulo org_policies para los respectivos repositorios:

Política Nombre de la restricción Valor recomendado

Restringe las implementaciones de recursos a ubicaciones físicas específicas. Para ver más valores, consulta Grupos de valores.

gcp.resourceLocations

Una de las siguientes opciones:

in:us-locations

in:eu-locations

in:asia-locations

Inhabilitar la creación de cuentas de servicio

iam.disableServiceAccountCreation

true

Habilita OS Login en las VMs creadas en el proyecto.

compute.requireOsLogin

true

Restringir las nuevas reglas de reenvío para que sean solo internas en función de la dirección IP.

compute.restrictProtocolForwardingCreationForTypes

INTERNAL

Define el conjunto de subredes de VPC compartidas que pueden usar los recursos de Compute Engine.

compute.restrictSharedVpcSubnetworks

projects//regions//s ubnetworks/.

Sustitúyalo por el ID de recurso de la subred privada que quiera que use la arquitectura.

Inhabilita el registro de salida del puerto serie en Cloud Logging.

compute.disableSerialPortLogging

true

Requerir protección con CMEK (terraform-google-secured-data-warehouse-onprem-ingest solo)

gcp.restrictNonCmekServices

bigquery.googleapis.com

Inhabilitar la creación de claves de cuenta de servicio (terraform-google-secured-data-warehouse-onprem-ingest only)

disableServiceAccountKeyCreation

true

Habilitar OS Login en las VMs creadas en el proyecto (terraform-google-secured-data-warehouse-onprem-ingest only)

compute.requireOsLogin

true

Inhabilitar las concesiones automáticas de roles a la cuenta de servicio predeterminada (terraform-google-secured-data-warehouse-onprem-ingest only)

automaticIamGrantsForDefaultServiceAccounts

true

Configuración de entrada permitida (Cloud Run Functions) (terraform-google-secured-data-warehouse-onprem-ingest only)

cloudfunctions.allowedIngressSettings

ALLOW_INTERNAL_AND_GCLB

Controles de seguridad de fuentes de datos externas

En las siguientes secciones se describen los controles que se aplican a la ingestión de datos de fuentes externas.

Conexión cifrada a Google Cloud

Cuando importes datos de fuentes externas, puedes usar Cloud VPN o Cloud Interconnect para proteger todos los datos que fluyan entre Google Cloudy tu entorno. Esta arquitectura empresarial recomienda Dedicated Interconnect porque proporciona una conexión directa y un alto rendimiento, lo que es importante si vas a transmitir muchos datos.

Para permitir el acceso a Google Cloud desde tu entorno, debes definir direcciones IP incluidas en la lista de permitidas en las reglas de la política de niveles de acceso.

Encriptación por parte del cliente

Antes de mover tus datos sensibles a Google Cloud, encripta tus datos de forma local para protegerlos mientras están en reposo y en tránsito. Puedes usar la biblioteca de cifrado Tink u otras bibliotecas de cifrado. La biblioteca de cifrado Tink es compatible con el cifrado AEAD de BigQuery, que es el que usa la arquitectura para descifrar los datos cifrados a nivel de columna después de importarlos.

La biblioteca de cifrado Tink usa DEKs que puedes generar de forma local o desde Cloud HSM. Para envolver o proteger la DEK, puedes usar una KEK que se genere en Cloud HSM. La KEK es un conjunto de claves de encriptado simétricas CMEK que se almacena de forma segura en Cloud HSM y se gestiona mediante roles y permisos de IAM.

Durante la ingestión, tanto la DEK envuelta como los datos se almacenan en BigQuery. BigQuery incluye dos tablas: una para los datos y otra para la DEK envuelta. Cuando los analistas necesitan ver datos confidenciales, BigQuery puede usar el descifrado AEAD para extraer la DEK con la KEK y descifrar la columna protegida.

Además, el cifrado del lado del cliente con Tink protege aún más tus datos cifrando las columnas de datos sensibles en BigQuery. La arquitectura usa las siguientes claves de cifrado de Cloud HSM:

  • Una clave CMEK para el proceso de ingestión que también utilizan Pub/Sub, el flujo de procesamiento de Dataflow para la transmisión, la subida por lotes de Cloud Storage y los artefactos de las funciones de Cloud Run para las subidas por lotes posteriores.
  • La clave criptográfica encapsulada por Cloud HSM para los datos cifrados en tu red con Tink.
  • Clave CMEK del almacén de BigQuery del proyecto de datos.

Usted especifica la ubicación de CMEK, que determina la ubicación geográfica en la que se almacena la clave y se pone a disposición para el acceso. Debe asegurarse de que su CMEK esté en la misma ubicación que sus recursos. De forma predeterminada, la CMEK se rota cada 30 días.

Si las obligaciones de cumplimiento de tu organización requieren que gestiones tus propias claves de forma externa a Google Cloud, puedes habilitar Cloud External Key Manager. Si usas claves externas, eres responsable de las actividades de gestión de claves, incluida la rotación de claves.

Enmascaramiento de datos dinámico

Para compartir y aplicar políticas de acceso a datos a gran escala, puedes configurar el enmascaramiento dinámico de datos. El enmascaramiento dinámico de datos permite que las consultas enmascaren automáticamente los datos de las columnas según los siguientes criterios:

  • Las reglas de enmascaramiento que se aplican a la columna en el tiempo de ejecución de la consulta.
  • Los roles asignados al usuario que ejecuta la consulta. Para acceder a los datos de las columnas sin máscara, el analista de datos debe tener el rol Lector detallado.

Para definir el acceso a las columnas de BigQuery, crea etiquetas de política. Por ejemplo, la taxonomía creada en el ejemplo independiente crea la etiqueta de política 1_Sensitive para las columnas que incluyen datos que no se pueden hacer públicos, como el límite de crédito. La regla de enmascaramiento de datos predeterminada se aplica a estas columnas para ocultar el valor de la columna.

Todo lo que no esté etiquetado estará disponible para todos los usuarios que tengan acceso al almacén de datos. Estos controles de acceso aseguran que, aunque los datos se escriban en BigQuery, los datos de los campos sensibles no se puedan leer hasta que se conceda acceso explícitamente al usuario.

Cifrado y descifrado a nivel de columna

El cifrado a nivel de columna te permite cifrar datos en BigQuery a un nivel más granular. En lugar de cifrar una tabla completa, selecciona las columnas que contengan datos sensibles en BigQuery y solo se cifrarán esas columnas. BigQuery usa funciones de cifrado y descifrado AEAD que crean los conjuntos de claves que contienen las claves de cifrado y descifrado. Estas claves se usan para cifrar y descifrar valores individuales de una tabla, así como para rotar claves en un conjunto de claves. El cifrado a nivel de columna proporciona un control de acceso dual a los datos cifrados de BigQuery, ya que el usuario debe tener permisos para acceder tanto a la tabla como a la clave de cifrado para leer los datos en texto sin cifrar.

Generador de perfiles de datos de BigQuery con Protección de Datos Sensibles

Profiler de datos te permite identificar las ubicaciones de los datos sensibles y de alto riesgo en las tablas de BigQuery. Data Profiler analiza y busca automáticamente todas las tablas y columnas de BigQuery de toda la organización, incluidas todas las carpetas y proyectos. A continuación, el creador de perfiles de datos genera métricas como los infoTypes predichos, los niveles de riesgo y sensibilidad de los datos evaluados, y metadatos sobre tus tablas. Con estos datos, puedes tomar decisiones fundamentadas sobre cómo proteger, compartir y usar tus datos.

Controles de seguridad de fuentes de datos internas

En las siguientes secciones se describen los controles que se aplican a la ingestión de datos de fuentes deGoogle Cloud .

Gestión de claves y cifrado para la ingesta

Ambas opciones de ingesta (Cloud Storage o Pub/Sub) usan Cloud HSM para gestionar la CMEK. Usas las claves CMEK para proteger tus datos durante la ingestión. La protección de datos sensibles protege aún más tus datos cifrando los datos confidenciales con los detectores que configures.

Para ingerir datos, se usan las siguientes claves de cifrado:

  • Una clave CMEK para el proceso de ingestión que también utiliza la canalización de Dataflow y el servicio Pub/Sub.
  • La clave criptográfica envuelta por Cloud HSM para el proceso de desidentificación de datos mediante Protección de Datos Sensibles.
  • Dos claves CMEK: una para el almacén de BigQuery del proyecto de datos no confidenciales y otra para el almacén del proyecto de datos confidenciales. Para obtener más información, consulta Gestión de claves.

Especifica la ubicación de CMEK, que determina la ubicación geográfica en la que se almacena la clave y se pone a disposición para el acceso. Debe asegurarse de que su CMEK esté en la misma ubicación que sus recursos. De forma predeterminada, la CMEK se rota cada 30 días.

Si las obligaciones de cumplimiento de tu organización requieren que gestiones tus propias claves fuera de Google Cloud, puedes habilitar Cloud EKM. Si usas claves externas, eres responsable de las actividades de gestión de claves, incluida la rotación de claves.

Desidentificación de datos

Utilizas Protección de Datos Sensibles para desidentificar tus datos estructurados y no estructurados durante la fase de ingestión. En el caso de los datos estructurados, se usan transformaciones de registros basadas en campos para anonimizar los datos. Para ver un ejemplo de este enfoque, consulta la carpeta /examples/de_identification_template/. En este ejemplo se comprueban los datos estructurados para detectar números de tarjetas de crédito y números PIN de tarjetas. En el caso de los datos no estructurados, se utilizan tipos de información para desidentificar los datos.

Para desidentificar los datos etiquetados como confidenciales, utiliza Protección de datos sensibles y una canalización de Dataflow para tokenizarlos. Esta canalización toma datos de Cloud Storage, los procesa y, a continuación, los envía al almacén de datos de BigQuery.

Para obtener más información sobre el proceso de desidentificación de datos, consulta Gobernanza de datos.

Controles de acceso a nivel de columna

Para proteger los datos confidenciales, puedes usar controles de acceso para columnas específicas en el almacén de BigQuery. Para acceder a los datos de estas columnas, un analista de datos debe tener el rol Lector detallado.

Para definir el acceso a las columnas de BigQuery, crea etiquetas de política. Por ejemplo, el archivo taxonomy.tf del módulo de ejemplo bigquery-confidential-data crea las siguientes etiquetas:

  • Una etiqueta de 3_Confidentialpolítica para las columnas que incluyan información muy sensible, como números de tarjetas de crédito. Los usuarios que tienen acceso a esta etiqueta también tienen acceso a las columnas etiquetadas con las etiquetas de política 2_Private o 1_Sensitive.
  • Una etiqueta de política 2_Private para las columnas que incluyen información personal sensible, como el nombre de una persona. Los usuarios que tienen acceso a esta etiqueta también tienen acceso a las columnas etiquetadas con la etiqueta de política 1_Sensitive. Los usuarios no tienen acceso a las columnas que están etiquetadas con la etiqueta de política 3_Confidential.
  • Una etiqueta de política 1_Sensitive para las columnas que incluyen datos que no se pueden hacer públicos, como el límite de crédito. Los usuarios que tienen acceso a esta etiqueta no tienen acceso a las columnas etiquetadas con las etiquetas de política 2_Private o 3_Confidential.

Todo lo que no esté etiquetado estará disponible para todos los usuarios que tengan acceso al almacén de datos.

Estos controles de acceso aseguran que, incluso después de que se vuelvan a identificar los datos, estos no se puedan leer hasta que se conceda acceso explícitamente al usuario.

Nota: Puedes usar las definiciones predeterminadas para ejecutar los ejemplos. Para consultar más prácticas recomendadas, consulte Prácticas recomendadas para usar etiquetas de política en BigQuery.

Cuentas de servicio con roles limitados

Debe limitar el acceso al proyecto de datos confidenciales para que solo los usuarios autorizados puedan verlos. Para ello, crea una cuenta de servicio con el rol Usuario de cuenta de servicio (roles/iam.serviceAccountUser) que deben suplantar los usuarios autorizados. La suplantación de identidad de cuenta de servicio ayuda a los usuarios a usar cuentas de servicio sin descargar las claves de la cuenta de servicio, lo que mejora la seguridad general de tu proyecto. La suplantación crea un token de corta duración que pueden descargar los usuarios autorizados que tengan el rol Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).

Gestión de claves y cifrado para el almacenamiento y la reidentificación

Gestionas claves CMEK independientes para tus datos confidenciales, de forma que puedes volver a identificar los datos. Usas Cloud HSM para proteger tus claves. Para volver a identificar tus datos, usa las siguientes claves:

  • Una clave CMEK que usa la canalización de Dataflow para el proceso de reidentificación.
  • La clave criptográfica original que usa Protección de Datos Sensibles para anonimizar tus datos.
  • Una clave CMEK para el almacén de BigQuery del proyecto de datos confidenciales.

Como se indica en Gestión de claves y cifrado para la ingesta, puedes especificar la ubicación de la CMEK y los periodos de rotación. Puedes usar Cloud EKM si tu organización lo requiere.

Operaciones

Puedes habilitar el registro y las funciones del nivel Premium o Enterprise de Security Command Center, como Security Health Analytics y Event Threat Detection. Estos controles te permiten hacer lo siguiente:

  • Monitoriza quién accede a tus datos.
  • Asegúrate de que se implemente una auditoría adecuada.
  • Generar resultados de recursos en la nube mal configurados
  • Ayuda a tus equipos de gestión de incidentes y operaciones a responder a los problemas que puedan surgir.

Transparencia de acceso

Transparencia de acceso te proporciona notificaciones en tiempo real cuando el personal de Google necesita acceder a tus datos. Los registros de Transparencia de acceso se generan cada vez que una persona accede al contenido, y solo el personal de Google con justificaciones empresariales válidas (por ejemplo, un caso de asistencia) puede obtener acceso.

Almacenamiento de registros

Para ayudarte a cumplir los requisitos de auditoría y obtener información valiosa sobre tus proyectos, configura Google Cloud Observability con registros de datos de los servicios que quieras monitorizar. El módulo centralized-logging de la configuración de los repositorios configura las siguientes prácticas recomendadas:

En todos los servicios de los proyectos, los registros deben incluir información sobre las lecturas y escrituras de datos, así como sobre lo que leen los administradores. Para ver más prácticas recomendadas sobre el registro, consulta Controles de detección.

Alertas y monitorización

Una vez que hayas implementado la arquitectura, puedes configurar alertas para notificar a tu centro de operaciones de seguridad (SOC) que puede haber un incidente de seguridad. Por ejemplo, puedes usar alertas para informar a tu analista de seguridad cuando se haya cambiado un permiso de gestión de identidades y accesos. Para obtener más información sobre cómo configurar alertas de Security Command Center, consulta el artículo Configurar notificaciones de detecciones. Para recibir alertas adicionales que no publique Security Command Center, puedes configurar alertas con Cloud Monitoring.

Consideraciones de seguridad adicionales

Además de los controles de seguridad descritos en este documento, debe revisar y gestionar la seguridad y los riesgos en las áreas clave que se solapan e interactúan con su uso de esta solución. Entre ellas, se incluyen las siguientes:

  • La seguridad del código que usas para configurar, desplegar y ejecutar tareas de Dataflow y funciones de Cloud Run.
  • La taxonomía de clasificación de datos que utiliza con esta solución.
  • Generación y gestión de claves de cifrado.
  • El contenido, la calidad y la seguridad de los conjuntos de datos que almacenas y analizas en el almacén de datos.
  • El entorno general en el que implementas la solución, incluidos los siguientes elementos:
    • El diseño, la segmentación y la seguridad de las redes a las que te conectes con esta solución.
    • La seguridad y la gobernanza de los controles de gestión de identidades y accesos de tu organización.
    • Los ajustes de autenticación y autorización de los actores a los que concedas acceso a la infraestructura que forma parte de esta solución y que tienen acceso a los datos almacenados y gestionados en esa infraestructura.

Resumen

Para implementar la arquitectura descrita en este documento, sigue estos pasos:

  1. Determina si vas a implementar la arquitectura con el blueprint de bases de la empresa o por tu cuenta. Si decide no implementar el blueprint de bases empresariales, asegúrese de que su entorno tenga una base de seguridad similar.
  2. Para importar datos de fuentes externas, configura una conexión Interconnect dedicada con tu red.
  3. Consulta el archivo terraform-google-secured-data-warehouse README o terraform-google-secured-data-warehouse-onprem-ingest README y asegúrate de que cumples todos los requisitos previos.

  4. Verifica que tu identidad de usuario tenga los roles Usuario de cuenta de servicio (roles/iam.serviceAccountUser) y Creador de tokens de cuenta de servicio Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) en la carpeta de desarrollo de tu organización, tal como se describe en Estructura de la organización. Si no tienes ninguna carpeta que puedas usar para hacer pruebas, crea una y configura el acceso.

  5. Anota el ID de tu cuenta de facturación, el nombre visible de tu organización, el ID de la carpeta de prueba o de demostración y las direcciones de correo de los siguientes grupos de usuarios:

    • Analistas de datos
    • Visor de datos cifrados
    • Lector de texto sin formato
    • Ingenieros de datos
    • Administradores de red
    • Administradores de seguridad
    • Analistas de seguridad

  6. Crea los proyectos. Para ver una lista de las APIs que debes habilitar, consulta el archivo README.

  7. Crea la cuenta de servicio de Terraform y asigna los roles adecuados a todos los proyectos.

  8. Configura la política de control de acceso.

  9. En el caso de las Google Cloud fuentes de datos que usan el repositorio terraform-google-secured-data-warehouse, implementa la guía en tu entorno de pruebas para ver la solución en acción. Como parte del proceso de prueba, ten en cuenta lo siguiente:

    1. Añade tus propios datos de muestra al almacén de BigQuery.
    2. Colabora con un analista de datos de tu empresa para probar su acceso a los datos confidenciales y si puede interactuar con los datos de BigQuery de la forma que espera.

  10. En el caso de las fuentes de datos externas que usen el repositorio terraform-google-secured-data-warehouse-onprem-ingest, implementa la solución en tu entorno de pruebas:

    1. Clona y ejecuta las secuencias de comandos de Terraform para configurar un entorno enGoogle Cloud.

    2. Instala la biblioteca de cifrado Tink en tu red.

    3. Configura las credenciales predeterminadas de la aplicación para poder ejecutar la biblioteca Tink en tu red.

    4. Crea claves de encriptado con Cloud KMS.

    5. Generar conjuntos de claves cifrados con Tink.

    6. Cifra los datos con Tink mediante uno de los siguientes métodos:

    7. Sube datos cifrados a BigQuery mediante cargas en streaming o por lotes.

  11. En el caso de las fuentes de datos externas, compruebe que los usuarios autorizados puedan leer datos sin cifrar de BigQuery mediante la función de descifrado AEAD de BigQuery. Por ejemplo, ejecuta la siguiente función de creación de descifrado:

    Ejecuta la consulta para crear la vista:

    CREATE OR REPLACE VIEW `{project_id}.{bigquery_dataset}.decryption_view` AS

SELECT
 Card_Type_Code,
 Issuing_Bank,
 Card_Number,
 `bigquery_dataset.decrypt`(Card_Number) AS Card_Number_Decrypted
FROM `project_id.dataset.table_name`

    Ejecuta la consulta de selección de la vista:

    SELECT
  Card_Type_Code,
  Issuing_Bank,
  Card_Number,
  Card_Number_Decrypted
FROM
`{project_id}.{bigquery_dataset}.decrypted_view`

    Para ver más consultas y casos prácticos, consulta Encriptación a nivel de columna con Cloud KMS.

  12. Usa Security Command Center para analizar los proyectos recién creados en función de tus requisitos de cumplimiento.

  13. Despliega la arquitectura en tu entorno de producción.

Siguientes pasos