Muchas organizaciones implementan almacenes de datos que almacenan datos sensibles para que puedan analizarlos con una variedad de fines comerciales. Este documento está dirigido a ingenieros de datos y administradores de seguridad que implementan y protegen almacenes de datos mediante BigQuery. Es parte de un plan que consta de lo siguiente:
- Dos repositorios de GitHub
(
terraform-google-secured-data-warehouseyterraform-google-secured-data-warehouse-onprem-ingest) que contienen opciones de configuración y secuencias de comandos de Terraform. La configuración de Terraform establece un entorno en Google Cloud que admite un almacén de datos que almacena datos confidenciales. - Una guía sobre los controles de arquitectura, diseño y seguridad de este modelo (este documento).
- Una explicación que implementa un entorno de muestra.
En este documento, se analizan los siguientes temas:
- 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 administración de datos cuando se crea, implementa y opera un almacén de datos enGoogle Cloud, incluidas las siguientes:
desidentificación de datos
manejo diferencial de datos confidenciales
encriptación a nivel de la columna
controles de acceso a nivel de columna
En este documento, se supone que ya configuraste un conjunto básico de controles de seguridad, como se describe en el plano de bases empresariales. Te ayuda a disponer por capas controles adicionales a tus controles de seguridad existentes para proteger los datos confidenciales de un almacén de datos.
Casos de uso de almacenes de datos
Este plano admite los siguientes casos de uso:
- Usa el repositorio de
terraform-google-secured-data-warehousepara importar datos de Google Cloud a un almacén de datos de BigQuery - Usa el repositorio de
terraform-google-secured-data-warehouse-onprem-ingestpara importar datos de un entorno local o de otra nube a un almacén de datos de BigQuery
Descripción general
Los almacenes de datos como BigQuery permiten que las empresas analicen sus datos empresariales para obtener estadísticas. Los analistas acceden a los datos de la empresa que se almacenan en los almacenes de datos para crear 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 de la empresa mientras están almacenados, en tránsito o en análisis. En este esquema, harás lo siguiente:
- Cuando importes datos de fuentes de datos externas, encripta los datos que se encuentran fuera de Google Cloud (por ejemplo, en un entorno local) y, luego, impórtalos a Google Cloud.
- Configurar controles que ayuden a proteger el acceso a los datos confidenciales.
- Configurar controles que ayuden a proteger la canalización de datos.
- Configurar una separación adecuada de obligaciones para diferentes arquetipos.
- Cuando importes datos de otras fuentes ubicadas en Google Cloud (también conocidas como fuentes de datos internas), configura plantillas para buscar y desidentificar datos confidenciales.
- Configurar controles y registros de seguridad adecuados para proteger los datos confidenciales.
- Usar la clasificación de datos, las etiquetas de política, el enmascaramiento de datos dinámico y la encriptación a nivel de columna para restringir el acceso a columnas específicas en el almacén de datos.
Arquitectura
Para crear un almacén de datos confidencial, debes importar los datos de forma segura y, luego, almacenarlos en un perímetro de Controles del servicio de VPC.
Arquitectura cuando se importan datos de Google Cloud
En la siguiente imagen, se muestra cómo se clasifican, desidentifican y almacenan los datos transferidos cuando importas datos de origen de Google Cloud con el
repositorio terraform-google-secured-data-warehouse. También se muestra cómo puedes reidentificar datos confidenciales bajo demanda para su análisis.
Arquitectura cuando se importan datos de fuentes externas
En la siguiente imagen, se muestra cómo se transfieren y almacenan los datos cuando se importan datos de un entorno local o de otra nube a un almacén de BigQuery con el repositorio terraform-google-secured-data-warehouse-onprem-ingest.
Servicios y funciones deGoogle Cloud
Las arquitecturas usan una combinación de los siguientes servicios y funciones de Google Cloud :
| Servicio o función | Descripción |
|---|---|
Se aplica a fuentes de datos internas y externas. Sin embargo, existen diferentes opciones de almacenamiento, como las siguientes:
BigQuery usa varios controles de seguridad para proteger el contenido, incluidos los controles de acceso, la seguridad a nivel de columna para datos confidenciales y la encriptación de datos. |
|
Cloud Key Management Service (Cloud KMS) con Cloud HSM |
Se aplica a fuentes internas y externas. Sin embargo, existe un caso de uso adicional para las fuentes de datos externas. Cloud HSM es un servicio de módulo de seguridad de hardware (HSM) basado en la nube que aloja la clave de encriptación de claves (KEK). Cuando importas datos de una fuente externa, usas Cloud HSM para generar la clave de encriptación que usas para encriptar los datos en tu red antes de enviarlos a Google Cloud. |
Se aplica a fuentes internas y externas. Cloud Logging recopila todos los registros de los servicios de Google Cloud para el almacenamiento y la recuperación mediante tus herramientas de investigación y análisis. |
|
Se aplica a fuentes internas y externas. Cloud Monitoring recopila y almacena información de rendimiento y métricas sobre los servicios de Google Cloud . |
|
Solo se aplica a fuentes de datos externas. Cloud Storage activa las funciones de Cloud Run y escribe los datos que Cloud Storage sube al bucket de transferencia en BigQuery. |
|
Se aplica a fuentes internas y externas. Cloud Storage y Pub/Sub reciben los datos de la siguiente manera:
|
|
Se aplica a fuentes internas y externas. El generador de perfiles de datos 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. |
|
Canalizaciones de Dataflow |
Se aplica a fuentes internas y externas. Sin embargo, existen diferentes canalización. Las canalizaciones de Dataflow importan datos de la siguiente manera:
|
Se aplica a fuentes internas y externas. Dataplex Universal Catalog clasifica de forma automática los datos confidenciales con metadatos, también conocidos como etiquetas de política, durante la transferencia. Dataplex Universal Catalog también usa metadatos para administrar el acceso a datos confidenciales. Para controlar el acceso a los datos dentro del almacén de datos, aplica etiquetas de política a las columnas que incluyen datos confidenciales. |
|
Solo se aplica a fuentes de datos externas. La interconexión dedicada te permite mover datos entre tu red y Google Cloud. Puedes usar otra opción de conectividad, como se describe en Elige un producto de conectividad de red. |
|
Se aplica a fuentes internas y externas. Identity and Access Management (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 privilegio mínimo. |
|
Se aplica a fuentes internas y externas. Security Command Center supervisa y revisa los resultados de seguridad de todo tu entorno de Google Clouden una ubicación central. |
|
Se aplica a fuentes internas y externas. Sin embargo, se realizan diferentes análisis. Sensitive Data Protection analiza los datos de la siguiente manera:
|
|
Se aplica a fuentes internas y externas. Sin embargo, existen diferentes perímetros. Los Controles del servicio de VPC crean perímetros de seguridad que aíslan los servicios y los recursos mediante la configuración de la autorización, los controles de acceso y el intercambio de datos seguro. Los perímetros son los siguientes:
Estos perímetros están diseñados para proteger el contenido entrante, aislar datos confidenciales mediante la configuración de controles y supervisión de acceso adicionales, y separar tu administración de los datos reales en el almacén. La administración incluye la administración de claves, la administración del catálogo de datos y el registro. |
Estructura organizativa
Agrupa los recursos de tu organización para poder administrarlos 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 arranque, común, producción, no producción (o etapa de pruebas) y desarrollo. Implementa la mayoría de los proyectos de la arquitectura en la carpeta de producción y el proyecto de administración de datos en la carpeta común que se usa para la administración.
Estructura de la organización cuando se importan datos de Google Cloud
En el siguiente diagrama, se muestra la estructura de la organización cuando se importan datos deGoogle Cloud con el repositorio terraform-google-secured-data-warehouse.
Estructura de la organización cuando se importan datos de fuentes externas
En el siguiente diagrama, se muestra la estructura de organización cuando se importan datos desde una fuente externa con el repositorio terraform-google-secured-data-warehouse-onprem-ingest.
Carpetas
Usa carpetas para aislar tu entorno de producción y los servicios de administración de tus entornos de prueba y no producción. En la siguiente tabla, se describen las carpetas del plano de bases empresariales que usa esta arquitectura.
| Carpeta | Descripción |
|---|---|
Arranque |
Contiene los recursos necesarios para implementar el plano de las bases empresariales. |
Nombre |
Contiene servicios centralizados para la organización, como el proyecto de administración de datos. |
Producción |
Contiene proyectos que tienen recursos en la nube y que se probaron y están listos para usar. En esta arquitectura, la carpeta Producción contiene el proyecto de transferencia de datos y los proyectos relacionados con los datos. |
No producción |
Contiene proyectos que tienen recursos en la nube que están en proceso de prueba y de preparación para el lanzamiento. En esta arquitectura, la carpeta No de producción contiene el proyecto de transferencia de datos y los proyectos relacionados con los datos. |
Desarrollo |
Contiene proyectos que tienen recursos en la nube que están en proceso de desarrollo. En esta arquitectura, la carpeta Desarrollo contiene el proyecto de transferencia de datos y los proyectos relacionados con los datos. |
Puedes cambiar los nombres de estas carpetas para que se alineen con la estructura de carpetas de tu organización, pero te recomendamos que mantengas una estructura similar. Para obtener más información, consulta el plano de bases empresariales.
Proyectos
Puedes aislar partes de tu entorno mediante proyectos. En la siguiente tabla, se describen los proyectos que se necesitan dentro de la organización. Crea estos proyectos cuando ejecutes el código de Terraform. Puedes cambiar los nombres de estos proyectos, pero te recomendamos que mantengas una estructura de proyecto similar.
| Proyecto | Descripción |
|---|---|
Transferencia de datos |
Es un proyecto común para fuentes internas y externas. Contiene los servicios que se requieren para recibir datos y desidentificar datos confidenciales. |
Administración de datos |
Es un proyecto común para fuentes internas y externas. Contiene servicios que proporcionan funciones de administración de claves, registro y catalogación de datos. |
Datos no confidenciales |
Proyecto solo para fuentes internas. Contiene los servicios que se requieren para almacenar datos que se desidentificaron. |
Datos confidenciales |
Proyecto solo para fuentes internas. Contiene los servicios que se requieren para almacenar y reidentificar datos confidenciales. |
Datos |
Proyecto solo para fuentes externas. Contiene los servicios que se requieren para almacenar datos. |
Además de estos proyectos, tu entorno también debe incluir un proyecto que aloje un trabajo de plantilla de Flex de Dataflow. El trabajo de plantilla de Flex es necesario para la canalización de transmisión de datos.
Asigna roles y grupos a proyectos
Debes otorgar a diferentes grupos de usuarios en tu organización acceso a los proyectos que conforman el almacén de datos confidencial. En las siguientes secciones, se describen las recomendaciones de arquitectura para los grupos de usuarios y las asignaciones de roles en los proyectos que creas. Puedes personalizar los grupos para que se adapten a la estructura existente de tu organización, pero te recomendamos que mantengas una división de tareas y una asignación de roles similares.
Grupo de analistas de datos
Los analistas de datos analizan los datos en el almacén. En el repositorio terraform-google-secured-data-warehouse-onprem-ingest, este grupo puede ver los datos después de que se cargaron en el almacén de datos y realizar las mismas operaciones que el grupo Visualizador de datos encriptados.
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 | Funciones |
|---|---|
Transferencia de datos |
Rol adicional para los analistas de datos que requieren acceso 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).
| Alcance de la tarea | Roles |
|---|---|
Proyecto de transferencia de datos |
|
Proyecto de datos |
|
Nivel de la política de datos |
Grupo de lectores de datos encriptados (solo fuentes externas)
El grupo de visor de datos encriptados en el repositorio terraform-google-secured-data-warehouse-onprem-ingest puede ver datos encriptados de las tablas de informes de BigQuery a través de Looker Studio y otras herramientas de informes, como SAP Business Objects.
El grupo de usuarios con permiso de visualización de datos encriptados no puede ver los datos de texto simple de las columnas encriptadas.
Este grupo requiere el rol de usuario de BigQuery (roles/bigquery.jobUser) en el proyecto de datos. Este grupo también requiere el rol de Lector enmascarado (roles/bigquerydatapolicy.maskedReader) a nivel de la política de datos.
Grupo de lectores de texto sin formato (solo fuentes externas)
El grupo de lectores de texto sin formato en el repositorio terraform-google-secured-data-warehouse-onprem-ingest tiene el permiso necesario para llamar a la función definida por el usuario (UDF) de desencriptación para ver los datos de texto sin formato y el permiso adicional para leer los datos sin enmascarar.
Este grupo requiere los siguientes roles en el proyecto de datos:
- Usuario de BigQuery (
roles/bigquery.user) - Usuario de BigQuery (
roles/bigquery.jobUser) - Visualizador de Cloud KMS (
roles/cloudkms.viewer)
Además, este grupo requiere el rol de Lector detallado (roles/datacatalog.categoryFineGrainedReader) a nivel de Dataplex Universal Catalog.
Grupo de ingenieros de datos
Los ingenieros de datos configuran y mantienen el almacén y la canalizació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 | Funciones |
|---|---|
Proyecto de transferencia 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.
Grupo de administradores de redes
Los administradores de redes configuran la red. Por lo general, son miembros del equipo de redes.
Los administradores de red requieren los siguientes roles a nivel de la organización:
Grupo de administradores de seguridad
Los administradores de seguridad administran los controles de seguridad como el acceso, las claves, las reglas de firewall, los Controles del servicio de VPC y Security Command Center.
Los administradores de seguridad requieren los siguientes roles a nivel de la organización:
- Administrador de Access Context Manager (
roles/accesscontextmanager.policyAdmin) - Visualizador de recursos de Cloud (
roles/cloudasset.viewer) - Administrador de Cloud KMS (
roles/cloudkms.admin) - Administrador de seguridad de Compute (
roles/compute.securityAdmin) - Administrador de Data Catalog (
roles/datacatalog.admin) - Administrador de DLP (
roles/dlp.admin) - Administrador de Logging (
roles/logging.admin) - Administrador de la organización (
roles/orgpolicy.policyAdmin) - Administrador de seguridad (
roles/iam.securityAdmin)
Grupo de analistas de seguridad
Los analistas de seguridad supervisan los incidentes de seguridad y los resultados de la Protección de datos sensibles y responden a ellos.
Los analistas de seguridad requieren los siguientes roles a nivel de la organización:
- Lector de Access Context Manager (
roles/accesscontextmanager.policyReader) - Visualizador de la red de Compute (
roles/compute.networkViewer) - Visualizador de Data Catalog (
roles/datacatalog.viewer) - Visualizador de Cloud KMS (
roles/cloudkms.viewer) - Visor de registros (
roles/logging.viewer) - Lector de políticas de la organización (
roles/orgpolicy.policyViewer) - Visualizador administrador del centro de seguridad (
roles/securitycenter.adminViewer) - Editor de hallazgos del centro de seguridad(
roles/securitycenter.findingsEditor) - Uno de los siguientes roles de Security Command Center:
- Editor para silenciar de forma masiva hallazgos del centro de seguridad (
roles/securitycenter.findingsBulkMuteEditor) - Definidor para silenciar buscadores del centro de seguridad (
roles/securitycenter.findingsMuteSetter) - Definidor de estado de hallazgos del centro de seguridad (
roles/securitycenter.findingsStateSetter)
- Editor para silenciar de forma masiva hallazgos del centro de seguridad (
Ejemplos de flujos de acceso de grupos para fuentes externas
En las siguientes secciones, se describen los flujos de acceso de dos grupos cuando se importan datos
de fuentes externas con el
repositorio terraform-google-secured-data-warehouse-onprem-ingest.
Flujo de acceso para el grupo de usuarios de datos encriptados
En el siguiente diagrama, se muestra lo que ocurre cuando un usuario del grupo de usuarios de visualización de datos encriptados intenta acceder a datos encriptados en BigQuery.
Los pasos para acceder a los datos en BigQuery son los siguientes:
El visor de datos encriptados ejecuta la siguiente consulta en BigQuery para acceder a los datos confidenciales:
SELECT ssn, pan FROM cc_card_tableBigQuery verifica el acceso de la siguiente manera:
- El usuario se autentica con credenciales Google Cloudválidas y no vencidas.
- La identidad del usuario y la dirección IP de la que se originó la solicitud forman parte de la lista de entidades permitidas en el nivel de acceso o la regla de entrada del perímetro de Controles del servicio de VPC.
- IAM verifica que el usuario tenga los roles adecuados y que esté autorizado para acceder a las columnas encriptadas seleccionadas en la tabla de BigQuery.
BigQuery muestra los datos confidenciales en formato encriptado.
Flujo 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 formato intenta acceder a datos encriptados en BigQuery.
Los pasos para acceder a los datos en BigQuery son los siguientes:
El lector de texto simple ejecuta la siguiente consulta en BigQuery para acceder a datos confidenciales en formato desencriptado:
SELECT decrypt_ssn(ssn) FROM cc_card_tableBigQuery llama a la función definida por el usuario (UDF) de desencriptación dentro de la consulta para acceder a las columnas protegidas.
El acceso se verifica de la siguiente manera:
- IAM verifica que el usuario tenga los roles adecuados y que esté autorizado para acceder a la UDF de desencriptación en BigQuery.
- La UDF recupera la clave de encriptación de datos (DEK) unida que se usó para proteger las columnas de datos sensibles.
La UDF de desencriptación llama a la clave de encriptación de claves (KEK) en Cloud HSM para separar la DEK. La UDF de desencriptación usa la función de desencriptación de AEAD de BigQuery para desencriptar las columnas de datos sensibles.
Se le otorga al usuario acceso a los datos de texto simple en las columnas de datos sensibles.
Controles de seguridad comunes
En las siguientes secciones, se describen los controles que se aplican a las fuentes internas y externas.
Controles de transferencia de datos
Para crear tu almacén de datos, debes transferir datos de otra fuente deGoogle Cloud (por ejemplo, un data lake), tu entorno local o otra nube. Puedes usar una de las siguientes opciones para transferir tus datos al almacén de datos en BigQuery:
- Un trabajo por lotes que usa Cloud Storage.
- Un trabajo de transmisión que use Pub/Sub.
Para proteger los datos durante la transferencia, puedes usar la encriptación del cliente, las reglas de firewall y las políticas de nivel de acceso. En ocasiones, el proceso de transferencia se conoce como proceso de extracción, transformación y carga (ETL).
Reglas de firewall y red
Las reglas de firewall de la nube privada virtual (VPC) controlan el flujo de datos en los perímetros. Puedes crear reglas de firewall que rechacen todas las salidas, excepto las conexiones específicas del puerto TCP 443 de los nombres de dominio especiales restricted.googleapis.com. El dominio restricted.googleapis.com tiene los siguientes beneficios:
- Ayuda a reducir la superficie de ataque de la red usando el Acceso privado a Google cuando las cargas de trabajo se comunican con los servicios y las APIs de Google.
- Garantiza que solo uses servicios que admitan los Controles del servicio de VPC.
Para obtener más información, consulta Configura el acceso privado a los servicios.
Cuando usas el repositorio terraform-google-secured-data-warehouse, debes configurar subredes independientes para cada trabajo de Dataflow. Las subredes separadas garantizan que los datos que se desidentifican se separen correctamente de los datos que se están reidentificando.
La canalización de datos requiere que abras puertos TCP en el firewall, como se define en el archivo dataflow_firewall.tf en los repositorios respectivos. Para obtener más información, consulta Configura el acceso a Internet y las reglas de firewall.
Para denegar a los recursos la capacidad de usar direcciones IP externas, la política de la organización Define IPs externas permitidas para instancias de VM (compute.vmExternalIpAccess) está configurada para rechazar todas.
Controles perimetrales
Como se muestra en el diagrama de arquitectura, debes colocar los recursos del almacén de datos en perímetros separados. Para permitir que los servicios en diferentes perímetros compartan datos, crea puentes perimetrales.
Los puentes perimetrales permiten que los servicios protegidos realicen solicitudes de recursos fuera de su perímetro. Estos puentes realizan las siguientes conexiones para el repositorio terraform-google-secured-data-warehouse:
- Conectan el proyecto de transferencia de datos al proyecto de administración para que la desidentificación se pueda realizar durante la transferencia.
- Conectan el proyecto de datos no confidenciales y el proyecto de datos confidenciales para que los datos confidenciales se puedan reidentificar cuando un analista de datos lo solicite.
- Conectan el proyecto confidencial al proyecto de administración de datos para que se pueda reidentificar cuando un analista de datos lo solicite.
Estos puentes realizan las siguientes conexiones para el repositorio terraform-google-secured-data-warehouse-onprem-ingest:
- Conectan el proyecto de transferencia de datos al proyecto de datos para que los datos se puedan transferir a BigQuery.
- Conectan el proyecto de datos al proyecto de administración de datos para que la Protección de datos sensibles pueda analizar BigQuery en busca de datos confidenciales sin protección.
- Conectan el proyecto de transferencia de datos al proyecto de administración de datos para obtener acceso a las claves de registro, supervisión y encriptación.
Además de los puentes perimetrales, debes usar reglas de salida para permitir que los recursos protegidos por los perímetros de servicio accedan a los recursos que están fuera del perímetro. En esta solución, configurarás reglas de salida para obtener los trabajos externos de la plantilla de Flex de Dataflow que se encuentran en Cloud Storage en un proyecto externo. Para obtener más información, consulta Cómo acceder a un Google Cloud recurso fuera del perímetro.
Política de acceso
Para ayudar a garantizar que solo las identidades específicas (usuario o servicio) puedan acceder a los recursos y los datos, habilita los grupos y los roles de IAM.
Para garantizar que solo fuentes específicas puedan acceder a tus proyectos, habilita una política de acceso para tu organización de Google. Te recomendamos que crees una política de acceso que especifique el rango de direcciones IP permitido para las solicitudes y que solo permita solicitudes de cuentas de servicio o usuarios 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 puede usar para ejecutar solicitudes a la API en tu nombre. Las cuentas de servicio garantizan que las identidades de usuario no tengan acceso directo a los servicios. Para permitir la separación de obligaciones, crea cuentas de servicio con diferentes roles para propósitos específicos. Estas cuentas de servicio se definen en el módulo data-ingestion y en el módulo confidential-data en cada arquitectura.
Para el repositorio terraform-google-secured-data-warehouse, las cuentas de servicio son las siguientes:
- Una cuenta de servicio del controlador de Dataflow para la canalización de Dataflow que desidentifica los datos confidenciales.
- Una cuenta de servicio del controlador de Dataflow para la canalización de Dataflow que reidentifica datos confidenciales.
- Una cuenta de servicio de Cloud Storage para transferir datos de un archivo por lotes.
- Una cuenta de servicio de Pub/Sub para transferir datos de un servicio de transmisión.
- Una cuenta de servicio de Cloud Scheduler para ejecutar el trabajo por lotes de Dataflow que crea la canalización de Dataflow.
En la siguiente tabla, se enumeran los roles que se asignan a cada cuenta de servicio:
Para 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 carga de datos por lotes al bucket de almacenamiento de transferencia.
- La cuenta de servicio de Pub/Sub habilita la transmisión de datos al servicio de Pub/Sub.
- La canalización de Dataflow usa la cuenta de servicio del controlador de Dataflow para transformar y escribir datos de Pub/Sub a BigQuery.
- La cuenta de servicio de las funciones de Cloud Run escribe datos por lotes posteriores subidos desde Cloud Storage a BigQuery.
- La cuenta de servicio de carga de almacenamiento permite que la canalización 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 que se asignan a cada cuenta de servicio:
| Nombre | Roles | Alcance de la tarea |
|---|---|---|
Cuenta de servicio del controlador de Dataflow |
|
Proyecto de transferencia de datos |
Proyecto de datos |
||
Administración de datos |
||
Cuenta de servicio de Cloud Run Functions |
Proyecto de transferencia de datos |
|
Proyecto de datos |
||
Cuenta de servicio de carga de almacenamiento |
Proyecto de transferencia de datos |
|
Cuenta de servicio de escritura de Pub/Sub |
Proyecto de transferencia de datos |
Políticas de la organización
Esta arquitectura incluye las restricciones de la política de la organización que usa el plano de bases empresariales y agrega restricciones adicionales. Para obtener más información sobre las restricciones que usa el plano de bases empresarial, consulta las restricciones de las políticas de la organización.
En la siguiente tabla, se describen las restricciones adicionales de las políticas de la organización que se definen en el módulo org_policies para los repositorios respectivos:
| Política | Nombre de la restricción | Valor recomendado |
|---|---|---|
Restringe las implementaciones de recursos a ubicaciones físicas específicas. Para obtener valores adicionales, consulta Grupos de valores. |
|
Una de las siguientes opciones:
|
|
|
|
Habilita el Acceso al SO para las VMs creadas en el proyecto. |
|
|
Restringe las reglas de reenvío nuevas para que sean solo internas, según la dirección IP. |
|
|
Define el conjunto de VPC compartida compartidas que los recursos de Compute Engine pueden usar. |
|
Reemplaza por el ID de recurso de la subred privada que deseas que use la arquitectura. |
Inhabilita el registro de salida del puerto en serie en Cloud Logging. |
|
|
Solicita protección de CMEK (solo |
|
|
Inhabilita la creación de claves de cuentas de servicio
( |
|
verdadero |
Habilita el Acceso al SO para las VMs creadas en el proyecto ( |
|
verdadero |
Inhabilita las asignaciones automáticas de roles a la cuenta de servicio predeterminada ( |
|
verdadero |
Configuración de entrada permitida (funciones de Cloud Run)
( |
|
|
Controles de seguridad para fuentes de datos externas
En las siguientes secciones, se describen los controles que se aplican a la transferencia de datos desde fuentes externas.
Conexión encriptada a Google Cloud
Cuando importas datos de fuentes externas, puedes usar Cloud VPN o Cloud Interconnect para proteger todos los datos que fluyen entre Google Cloud y tu entorno. Esta arquitectura empresarial recomienda la interconexión dedicada, ya que proporciona una conexión directa y una alta capacidad de procesamiento, lo que es importante si transmites muchos datos.
Para permitir el acceso a Google Cloud desde tu entorno, debes definir las direcciones IP incluidas en la lista de entidades permitidas en las reglas de la política de niveles de acceso.
Encriptación del cliente
Antes de transferir tus datos sensibles a Google Cloud, encripta tus datos localmente para protegerlos en reposo y en tránsito. Puedes usar la biblioteca de encriptación Tink o puedes usar otras bibliotecas de encriptación. La biblioteca de encriptación de Tink es compatible con la encriptación AEAD de BigQuery, que la arquitectura usa para desencriptar los datos encriptados a nivel de la columna después de que se importan.
La biblioteca de encriptación Tink usa las DEK que puedes generar de forma local o desde Cloud HSM. Para unir o proteger la DEK, puedes usar una KEK que se genera en Cloud HSM. La KEK es un conjunto de claves de encriptación simétricas que se almacena de forma segura en Cloud HSM y se administra mediante roles y permisos de IAM.
Durante la transferencia, la DEK unida y los datos se almacenan en BigQuery. BigQuery incluye dos tablas: una para los datos y la otra para la DEK unida. Cuando los analistas necesitan ver datos confidenciales, BigQuery puede usar la desencriptación de AEAD para unir la DEK con la KEK y desencriptar la columna protegida.
Además, la encriptación del cliente con Tink protege aún más tus datos, ya que encripta las columnas de datos sensibles en BigQuery. La arquitectura usa las siguientes claves de encriptación de Cloud HSM:
- Una clave CMEK para el proceso de transferencia que también usa Pub/Sub, la canalización de Dataflow para la transmisión, la carga por lotes de Cloud Storage y los artefactos de las funciones de Cloud Run para las cargas por lotes posteriores.
- La clave criptográfica unida por Cloud HSM para los datos encriptados en tu red mediante Tink.
- Clave CMEK para el almacén de BigQuery en el proyecto de datos.
Debes especificar la ubicación de CMEK, que determina la ubicación geográfica en la que se almacena la clave y está disponible para acceder. Debes asegurarte de que tus CMEK estén en la misma ubicación que tus recursos. De forma predeterminada, las CMEK se rotan cada 30 días.
Si las obligaciones de cumplimiento de tu organización requieren que administres tus propias claves de forma externa desde Google Cloud, puedes habilitar Cloud External Key Manager. Si usas claves externas, eres responsable de las actividades de administración de claves, incluida la rotación de claves.
Enmascaramiento dinámico de datos
Para compartir y aplicar políticas de acceso a los datos a gran escala, puedes configurar el enmascaramiento de datos dinámico. El enmascaramiento de datos dinámico permite que las consultas existentes enmasquen automáticamente los datos de la columna según los siguientes criterios:
- Las reglas de enmascaramiento que se aplican a la columna en el entorno de ejecución de la consulta
- Los roles que se asignan al usuario que ejecuta la consulta. Para acceder a los datos de las columnas sin enmascarar, el analista de datos debe tener el rol de Lector detallado.
Para definir el acceso a las columnas en 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 está disponible para todos los usuarios que tengan acceso al almacén de datos. Estos controles de acceso garantizan que, incluso después de que los datos se escriban en BigQuery, los datos en campos sensibles no se puedan leer hasta que se otorgue al usuario acceso de forma explícita.
Encriptación y desencriptación a nivel de columna
La encriptación a nivel de columna te permite encriptar datos en BigQuery a un nivel más detallado. En lugar de encriptar una tabla completa, seleccionas las columnas que contienen datos sensibles dentro de BigQuery, y solo esas columnas se encriptan. BigQuery usa funciones de encriptación y desencriptación de AEAD que crean los conjuntos de claves que contienen las claves para la encriptación y desencriptación. Luego, estas claves se usan para encriptar y desencriptar valores individuales en una tabla y rotar claves dentro de un conjunto de claves. La encriptación a nivel de columna proporciona un control de acceso doble en los datos encriptados en BigQuery, ya que el usuario debe tener permisos para la tabla y la clave de encriptación para leer datos en texto simple.
Generador de perfiles de datos para BigQuery con Protección de datos sensibles
El creador de perfiles de datos te permite identificar las ubicaciones de los datos sensibles y de alto riesgo en las tablas de BigQuery. El generador de perfiles de datos analiza automáticamente todas las tablas y columnas de BigQuery de toda la organización, incluidas todas las carpetas y proyectos. Luego, el generador de perfiles de datos genera métricas, como los infoTypes previstos, los niveles de sensibilidad y riesgo de los datos evaluados, y los metadatos sobre tus tablas. Con estas estadísticas, puedes tomar decisiones fundamentadas sobre cómo proteger, compartir y usar tus datos.
Controles de seguridad para fuentes de datos internas
En las siguientes secciones, se describen los controles que se aplican a la transferencia de datos desde fuentes deGoogle Cloud .
Administración y encriptación de claves para la transferencia
Ambas opciones de transferencia (Cloud Storage o Pub/Sub) usan Cloud HSM para administrar las CMEK. Usa las claves CMEK para proteger tus datos durante la transferencia. La Protección de datos sensibles protege aún más tus datos con la encriptación de datos confidenciales, mediante los detectores que configuras.
Para transferir datos, usa las siguientes claves de encriptación:
- Una clave CMEK para el proceso de transferencia que también usa la canalización de Dataflow y el servicio de Pub/Sub.
- La clave criptográfica unida por Cloud HSM para el proceso de desidentificación de datos con la Protección de datos sensibles.
- Dos claves de CMEK, una para el almacén de BigQuery en el proyecto de datos no confidenciales y la otra para el almacén en el proyecto de datos confidenciales. Para obtener más información, consulta Administración de claves.
Debes especificar la ubicación de CMEK, que determina la ubicación geográfica en la que se almacena la clave y está disponible para acceder. Debes asegurarte de que tus CMEK estén en la misma ubicación que tus recursos. De forma predeterminada, las CMEK se rotan cada 30 días.
Si las obligaciones de cumplimiento de tu organización requieren que administres tus propias claves de forma externa desde Google Cloud, puedes habilitar Cloud EKM. Si usas claves externas, eres responsable de las actividades de administración de claves, incluida la rotación de claves.
Desidentificación de datos
Usa la Protección de datos sensibles para desidentificar los datos estructurados y no estructurados durante la fase de transferencia. En el caso de los datos estructurados, debes usar transformaciones de registro basadas en campos para desidentificar datos. Para ver un ejemplo de este enfoque, consulta la carpeta /examples/de_identification_template/. En este ejemplo, se verifican los datos estructurados para cualquier número de tarjeta de crédito y PIN de tarjeta. En el caso de los datos no estructurados, debes usar tipos de información para desidentificar datos.
Si deseas desidentificar datos etiquetados como confidenciales, usa la Protección de datos sensibles y una canalización de Dataflow para asignarles tokens. Esta canalización toma datos de Cloud Storage, los procesa y, luego, 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 Administración de datos.
Controles de acceso a nivel de columna
Para proteger los datos confidenciales, usa 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 en BigQuery, crea etiquetas de política. Por ejemplo, el archivo taxonomy.tf en el módulo de ejemplo bigquery-confidential-data crea las siguientes etiquetas:
- Una etiqueta de política
3_Confidentialpara columnas que incluyen 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 que están etiquetadas con las etiquetas de política2_Privateo1_Sensitive. - Una etiqueta de política
2_Privatepara columnas que incluyen información de identificación personal (PII) sensible, como el nombre de una persona. Los usuarios que tienen acceso a esta etiqueta también tienen acceso a las columnas que están etiquetadas con la etiqueta de política1_Sensitive. Los usuarios no tienen acceso a las columnas que están etiquetadas con la etiqueta de política3_Confidential. - Una etiqueta de política
1_Sensitivepara 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 que están etiquetadas con las etiquetas de política2_Privateo3_Confidential.
Todo lo que no esté etiquetado está disponible para todos los usuarios que tengan acceso al almacén de datos.
Estos controles de acceso garantizan que, incluso después de que los datos se reidentifiquen, los datos aún no se puedan leer hasta que se otorgue al usuario acceso de forma explícita.
Nota: Puedes usar las definiciones predeterminadas para ejecutar los ejemplos. Si deseas obtener más prácticas recomendadas, consulta Prácticas recomendadas para usar etiquetas de política en BigQuery.
Cuentas de servicio con roles limitados
Debes limitar el acceso al proyecto de datos confidenciales para que solo los usuarios autorizados puedan ver los datos confidenciales. Para hacerlo, crea una cuenta de servicio con el rol de usuario de la cuenta de servicio (roles/iam.serviceAccountUser) en cuyo nombre deben actuar 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 las cuentas de servicio, lo que mejora la seguridad general de tu proyecto. Cuando se actúa en nombre de cuentas de servicio, se crea un token a corto plazo que pueden descargar los usuarios autorizados que tengan asignado el rol de Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator).
Encriptación y administración de claves para el almacenamiento y la reidentificación
Administra claves de CMEK independientes para tus datos confidenciales de modo que puedas reidentificar los datos. Usa Cloud HSM para proteger tus claves. Para reidentificar los datos, usa las siguientes claves:
- Una clave CMEK que la canalización de Dataflow usa para el proceso de reidentificación.
- La clave criptográfica original que la Protección de datos sensibles usa para desidentificar tus datos.
- Una clave CMEK para el almacén de BigQuery en el proyecto de datos confidenciales.
Como se mencionó en Administración y encriptación de claves para la transferencia, puedes especificar la ubicación de CMEK y los períodos de rotación. Puedes usar Cloud EKM si tu organización lo requiere.
Operaciones
Puedes habilitar el registro y las funciones de nivel Premium o Enterprise de Security Command Center, como las estadísticas del estado de seguridad y la detección de amenazas. Estos controles te ayudan a hacer lo siguiente:
- Supervisar quién accede a tus datos.
- Asegurarse de que la auditoría sea la correcta.
- Generar conclusiones para recursos de la nube mal configurados
- Admitir la capacidad de los equipos de operaciones y administración de incidentes para responder a problemas que puedan ocurrir.
Transparencia de acceso
La Transparencia de acceso te proporciona notificaciones en tiempo real cuando el personal de Google requiera acceso a tus datos. Los registros de Transparencia de acceso se generan cada vez que un humano accede al contenido y solo el personal de Google que tiene justificaciones comerciales válidas (por ejemplo, un caso de asistencia) puede obtener acceso.
Logging
Para ayudarte a cumplir con los requisitos de auditoría y obtener estadísticas sobre tus proyectos, configura Google Cloud Observability con registros de datos para los servicios de los que deseas realizar un seguimiento. El módulo centralized-logging en los repositorios configura las siguientes prácticas recomendadas:
- Crea un receptor de registros agregado en todos los proyectos.
- Almacena tus registros en la región adecuada.
- Agrega claves de CMEK al receptor de registros.
Para todos los servicios de los proyectos, los registros deben incluir información sobre operaciones de lectura y escritura de datos, e información sobre lo que leen los administradores. Para obtener prácticas recomendadas de registro adicionales, consulta Controles de detección.
Alertas y supervisión
Después de implementar la arquitectura, puedes configurar alertas para notificar a tu centro de operaciones de seguridad (SOC) que puede estar ocurriendo un incidente de seguridad. Por ejemplo, puedes usar alertas para informar a tu analista de seguridad cuando cambie un permiso de IAM. Para obtener más información sobre cómo configurar alertas de Security Command Center, consulta Configura las notificaciones de hallazgos. Para las alertas adicionales que Security Command Center no publica, puedes configurar alertas con Cloud Monitoring.
Consideraciones de seguridad adicionales
Además de los controles de seguridad que se describen en este documento, debes revisar y administrar la seguridad y el riesgo en áreas clave que se superponen e interactúan con el uso de esta solución. Se incluyen las siguientes:
- La seguridad del código que usas para configurar, implementar y ejecutar trabajos de Dataflow y funciones de Cloud Run.
- La taxonomía de clasificación de datos que usas con esta solución.
- Generación y administración de claves de encriptación
- 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, que incluye lo siguiente:
- El diseño, la segmentación y la seguridad de las redes que conectas a esta solución.
- La seguridad y la administración de los controles de IAM de tu organización.
- La configuración de autenticación y autorización de los actores a los que otorgas acceso a la infraestructura que forma parte de esta solución y que tienen acceso a los datos que se almacenan y administran en esa infraestructura.
reunir todo en un solo lugar
Para implementar la arquitectura que se describe en este documento, haz lo siguiente:
- Determina si implementarás la arquitectura con el plano de bases empresariales o por tu cuenta. Si eliges no implementar el modelo del plano de bases empresarial, asegúrate de que tu entorno tenga un modelo de referencia de seguridad similar implementado.
- Para importar datos desde fuentes externas, configura una interconexión dedicada con tu red.
- Revisa el archivo
terraform-google-secured-data-warehouseREADME oterraform-google-secured-data-warehouse-onprem-ingestREADME y asegúrate de cumplir con todos los requisitos previos. Verifica que tu identidad de usuario tenga los roles de Usuario de cuenta de servicio (
roles/iam.serviceAccountUser) y Creador de tokens de cuenta de servicio (roles/iam.serviceAccountTokenCreator) para la carpeta de desarrollo de tu organización, como se describe en Estructura de la organización. Si no tienes una carpeta para las pruebas, crea una carpeta y configura el acceso.Registra el ID de tu cuenta de facturación, el nombre visible de la organización, el ID de la carpeta de la carpeta de prueba o demostración, y las direcciones de correo electrónico de los siguientes grupos de usuarios:
- Analistas de datos
- Visor de datos encriptados
- Lector de texto sin formato
- Ingenieros de datos
- Administradores de red
- Administradores de seguridad
- Analistas de seguridad
Crea los proyectos. Para obtener una lista de las APIs que debes habilitar, consulta el archivo README.
Crea la cuenta de servicio para Terraform y asigna los roles adecuados a todos los proyectos.
Configura la política de control de acceso.
En el caso de las Google Cloud fuentes de datos que usan el repositorio
terraform-google-secured-data-warehouse, en tu entorno de pruebas, implementa la explicación para ver la solución en acción. Como parte de tu proceso de prueba, considera lo siguiente:- Agrega tus propios datos de muestra al almacén de BigQuery.
- Trabaja con un analista de datos en tu empresa para probar su acceso a los datos confidenciales y si puede interactuar con los datos desde BigQuery como esperarían.
Para las fuentes de datos externas que usan el repositorio
terraform-google-secured-data-warehouse-onprem-ingest, implementa la solución en tu entorno de pruebas:- Clona y ejecuta las secuencias de comandos de Terraform para configurar un entorno enGoogle Cloud.
Configura las credenciales predeterminadas de la aplicación para que puedas ejecutar la biblioteca de Tink en tu red.
Crea claves de encriptación con Cloud KMS.
Genera conjuntos de claves encriptados con Tink.
Encripta los datos con Tink mediante uno de los siguientes métodos:
Sube datos encriptados a BigQuery mediante cargas por lotes o transmisiones.
En el caso de las fuentes de datos externas, verifica que los usuarios autorizados puedan leer datos no encriptados de BigQuery con la función de desencriptación de AEAD de BigQuery. Por ejemplo, ejecuta la siguiente función de creación de desencriptación:
Ejecuta la consulta CREATE VIEW:
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 desde la vista:
SELECT Card_Type_Code, Issuing_Bank, Card_Number, Card_Number_Decrypted FROM `{project_id}.{bigquery_dataset}.decrypted_view`Para obtener más información sobre consultas y casos de uso, consulta Encriptación a nivel de columna con Cloud KMS.
Usa Security Command Center para analizar los proyectos recién creados según tus requisitos de cumplimiento.
Implementa la arquitectura en tu entorno de producción.
¿Qué sigue?
- Revisa el plano de bases empresariales para obtener un entorno seguro de referencia.
- Para ver los detalles de la arquitectura, lee el archivo readme de configuración de Terraform para fuentes de datos internas (repositorio
terraform-google-secured-data-warehouse) o el archivo readme de configuración de Terraform para fuentes de datos externas (repositorioterraform-google-secured-data-warehouse-onprem-ingest).