Muchas organizaciones implementan almacenes de datos en la nube a fin de almacenar información sensible para que puedan analizarlos con una variedad de fines comerciales. En este documento, se describe cómo implementar el framework de controles clave de Cloud Data Management Capabilities (CDMC), que administra el Consejo de Administración de Datos Empresariales, en un almacén de datos de BigQuery.
El framework de controles de claves de CDMC se publicó principalmente para los proveedores de servicios en la nube y los proveedores de tecnología. En el framework, se describen 14 controles clave que los proveedores pueden implementar para permitir que sus clientes administren y administren datos sensibles en la nube de forma eficaz. Los controles fueron escritos por el grupo de trabajo de CDMC, con más de 300 profesionales provenientes de más de 100 empresas. Cuando se escribió el framework, el grupo de trabajo de CDMC consideró muchos de los requisitos legales y normativos que existen.
Esta arquitectura de referencia de BigQuery y Data Catalog se evaluó y certificó con respecto al framework de controles clave de CDMC como una solución de Cloud certificada para CDMC. En la arquitectura de referencia, se usan varios servicios y funciones de Google Cloud, así como bibliotecas públicas para implementar los controles clave de CDMC y la automatización recomendada. En este documento, se explica cómo puedes implementar los controles clave para proteger los datos sensibles en un almacén de datos de BigQuery.
Arquitectura
La siguiente arquitectura de referencia de Google Cloud se alinea con las especificaciones de prueba del framework de controles clave de CDMC v1.1.1. Los números en el diagrama representan los controles clave que se abordan con los servicios de Google Cloud.
La arquitectura de referencia se basa en el plano del almacén de datos seguro, que proporciona una arquitectura que te ayuda a proteger un almacén de datos de BigQuery que incluye información sensible. En el diagrama anterior, los proyectos en la parte superior del diagrama (en gris) son parte del plano del almacén de datos seguro, y el proyecto de administración de datos (en azul) incluye los servicios que se agregan para cumplir con los requisitos del framework de controles clave de CDMC. Para implementar el framework de controles clave de CDMC, la arquitectura extiende el proyecto de administración de datos. El proyecto de administración de datos proporciona controles como la clasificación, la administración del ciclo de vida y la administración de la calidad de los datos. El proyecto también proporciona una forma de auditar la arquitectura y de informar sobre los resultados.
Para obtener más información sobre cómo implementar esta arquitectura de referencia, consulta la Arquitectura de referencia de CDMC de Google Cloud en GitHub.
Descripción general del framework de controles clave de CDMC
En la siguiente tabla, se resume el framework de controles clave de CDMC.
| # | Control clave CDMC | Requisito del control de CDMC |
|---|---|---|
| 1 | Cumplimiento del control de datos | Los casos empresariales de administración de datos en la nube están definidos y controlados. Todos los recursos de datos que contienen datos sensibles deben supervisarse para garantizar el cumplimiento de los controles clave de CDMC, mediante métricas y notificaciones automatizadas. |
| 2 | Se establece la propiedad de los datos migrados y generados por la nube | El campo Propiedad en un catálogo de datos debe propagarse para todos los datos sensibles o informarse a un flujo de trabajo definido. |
| 3 | La automatización y la obtención y el consumo de datos se rigen por la automatización. | Se debe propagar un registro de fuentes de datos autorizadas y puntos de aprovisionamiento para todos los recursos de datos que contienen datos sensibles o, de lo contrario, se debe informar a un flujo de trabajo definido. |
| 4 | Se administra la soberanía de los datos y el movimiento de datos entre límites | La soberanía de los datos y el movimiento transversal de datos sensibles se deben registrar, auditar y controlar según la política definida. |
| 5 | Se implementan, usan e interoperan los catálogos de datos | El catálogo debe estar automatizado para todos los datos en el momento de creación o transferencia, con coherencia en todos los entornos. |
| 6 | Las clasificaciones de datos están definidas y se usan | La clasificación debe estar automatizada para todos los datos en el momento de la creación o la transferencia y siempre debe estar activada. La clasificación está automatizada para los siguientes casos:
|
| 7 | Los derechos de datos se administran y se aplican, y se hace un seguimiento de ellas | Este control requiere lo siguiente:
|
| 8 | Se administra el acceso, el uso y los resultados éticos de los datos | El propósito del consumo de datos debe proporcionarse para todos los acuerdos de uso compartido de datos que involucren datos sensibles. El propósito debe especificar el tipo de datos requeridos y, para las organizaciones globales, el alcance de la entidad legal o el país. |
| 9 | Se protegen los datos y se evidencian los controles | Este control requiere lo siguiente:
|
| 10 | Hay un marco de trabajo de privacidad de datos definido y operativo | Las evaluaciones del impacto de la protección de datos (DPIA) deben activarse de forma automática para todos los datos personales según su jurisdicción. |
| 11 | El ciclo de vida de los datos está planificado y administrado | La retención, el archivado y la eliminación permanente de datos se deben administrar de acuerdo con un programa de retención definido. |
| 12 | Se administra la calidad de los datos | Se debe habilitar la medición de calidad de los datos sensibles con métricas distribuidas cuando estén disponibles. |
| 13 | Se establecen y aplican principios de administración de costos | Se establecen y aplican principios de diseño técnico. Las métricas de costos asociadas directamente con el uso, el almacenamiento y el movimiento de los datos deben estar disponibles en el catálogo. |
| 14 | Se comprende el linaje y la procedencia de los datos | La información de linaje de datos debe estar disponible para todos los datos sensibles. Esta información debe incluir, como mínimo, la fuente desde la que se transfirieron los datos o en los que se crearon en un entorno de nube. |
1. Cumplimiento del control de datos
Este control requiere que puedas verificar que todos los datos sensibles se supervisen para cumplir con este framework mediante las métricas.
La arquitectura usa métricas que muestran hasta qué punto cada uno de los controles clave está operativo. La arquitectura también incluye paneles que indican cuándo las métricas no cumplen con los límites definidos.
La arquitectura incluye detectores que publican resultados y recomendaciones de soluciones cuando los recursos de datos no cumplen con un control clave. Estos hallazgos y recomendaciones están en formato JSON y se publican en un tema de Pub/Sub para su distribución a los suscriptores. Puedes integrar tu centro de servicios interno o tus herramientas de administración de servicios en el tema de Pub/Sub para que los incidentes se creen de forma automática en tu sistema de tickets.
La arquitectura usa Dataflow para crear un suscriptor de ejemplo de los eventos de resultados, que luego se almacenan en una instancia de BigQuery que se ejecuta en el proyecto de administración de datos. Mediante las vistas proporcionadas, puedes consultar los datos con BigQuery Studio en la consola de Google Cloud. También puedes crear informes con Looker Studio u otras herramientas de inteligencia empresarial compatibles con BigQuery. Los informes que puedes ver incluyen los siguientes:
- Resumen de los resultados de la última ejecución
- Detalle de los resultados de la última ejecución
- Metadatos de la última ejecución
- Recursos de datos de la última ejecución dentro del permiso
- Estadísticas de la última ejecución del conjunto de datos
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Pub/Sub publica los resultados.
- Dataflow carga los resultados en una instancia de BigQuery.
- BigQuery almacena los datos de los resultados y proporciona vistas resumidas.
- Looker Studio proporciona informes y paneles.
En la siguiente captura de pantalla, se muestra un panel de resumen de muestra de Looker Studio.
En la siguiente captura de pantalla, se muestra una vista de muestra de los resultados por recurso de datos.
2. Se establece la propiedad de los datos migrados y generados por la nube
Para cumplir con los requisitos de este control, la arquitectura revisa de forma automática los datos en el almacén de datos de BigQuery y agrega etiquetas de clasificación de datos que indican que los propietarios están identificados para todos los datos sensibles.
Data Catalog, que es una característica de Dataplex, maneja dos tipos de metadatos: metadatos técnicos y metadatos empresariales. Para un proyecto determinado, Data Catalog cataloga automáticamente las tablas, las vistas y los conjuntos de datos de BigQuery, y propaga los metadatos técnicos. La sincronización entre el catálogo y los recursos de datos se mantiene casi en tiempo real.
La arquitectura usa Tag Engine para agregar las siguientes etiquetas de metadatos empresariales a una plantilla de etiqueta CDMC controls en Data Catalog:
is_sensitive: Si el recurso de datos contiene datos sensibles (consulta Control 6 para la clasificación de datos)owner_name: El propietario de los datosowner_email: La dirección de correo electrónico del propietario
Las etiquetas se propagan mediante valores predeterminados que se almacenan en una tabla de BigQuery de referencia en el proyecto de administración de datos.
De forma predeterminada, la arquitectura establece los metadatos de propiedad a nivel de tabla, pero puedes cambiarla para que los metadatos se establezcan a nivel de columna. Para obtener más información, consulta Etiquetas de Data Catalog y plantillas de etiquetas.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro, los valores predeterminados para la propiedad del recurso de datos.
- Data Catalog almacena los metadatos de la propiedad a través de plantillas de etiquetas.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura verifica si se asigna una etiqueta de nombre del propietario a los datos sensibles.
3. La automatización y la obtención y el consumo de datos se rigen por la automatización.
Este control requiere la clasificación de los recursos de datos y un registro de datos de las fuentes autorizadas y los distribuidores autorizados. La arquitectura usa Data Catalog para agregar la etiqueta is_authoritative a la plantilla de etiqueta CDMC
controls. Esta etiqueta define si el recurso de datos es confiable.
Data Catalog cataloga las tablas, vistas y conjuntos de datos de BigQuery con metadatos técnicos y de negocios. Los metadatos técnicos se propagan automáticamente y, además, incluyen la URL del recurso, que es la ubicación del punto de aprovisionamiento. Los metadatos empresariales se definen en el archivo de configuración de Tag Engine y, además, incluyen la etiqueta is_authoritative.
Durante la siguiente ejecución programada, Tag Engine propaga la etiqueta is_authoritative en la plantilla de etiqueta CDMC controls a partir de los valores predeterminados almacenados en una tabla de referencia en BigQuery.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro, los valores predeterminados para la propiedad del recurso de datos.
- Data Catalog almacena los metadatos de fuentes autorizadas a través de etiquetas.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura verifica si se asigna a los datos sensibles una etiqueta de fuente autorizada.
4. Se administra la soberanía de los datos y el movimiento de datos entre límites
Este control requiere que la arquitectura inspeccione el registro de datos en busca de requisitos de almacenamiento específicos de la región y aplicar reglas de uso. En un informe, se describe la ubicación geográfica de los recursos de datos.
La arquitectura usa Data Catalog para agregar la etiqueta approved_storage_location a la plantilla de etiqueta CDMC controls. Esta etiqueta define la ubicación geográfica en la que se puede almacenar el recurso de datos.
La ubicación real de los datos se almacena como metadatos técnicos en los detalles de la tabla de BigQuery. BigQuery no permite que los administradores cambien la ubicación de un conjunto de datos o una tabla. En cambio, si los administradores desean cambiar la ubicación de los datos, deben copiar el conjunto de datos.
La restricción de la política de la organización de las ubicaciones del recurso define las regiones de Google Cloud en las que puedes almacenar datos. De forma predeterminada, la arquitectura establece la restricción en el proyecto de datos confidenciales, pero puedes establecerla en un nivel de organización o carpeta si lo prefieres. Tag Engine replica las ubicaciones permitidas en la plantilla de etiqueta de Data Catalog y almacena la ubicación en la etiqueta approved_storage_location. Si activas el nivel Premium de Security Command Center y alguien actualiza la restricción del servicio de políticas de la organización de las ubicaciones del recurso, Security Command Center genera resultados de vulnerabilidades para los recursos almacenados fuera la política actualizada.
Access Context Manager define la ubicación geográfica en la que los usuarios deben estar para poder acceder a los recursos de datos. Mediante los niveles de acceso, puedes especificar de qué regiones pueden provenir las solicitudes. Luego, agrega la política de acceso al perímetro de los Controles del servicio de VPC para el proyecto de datos confidenciales.
A fin de realizar un seguimiento del movimiento de datos, BigQuery mantiene un registro de auditoría completo para cada trabajo y consulta cada conjunto de datos. El registro de auditoría se almacena en la vista Trabajos de esquema de información de BigQuery.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- El Servicio de políticas de la organización define y aplica la restricción de ubicaciones de recursos.
- Access Context Manager define las ubicaciones desde las que los usuarios pueden acceder a los datos.
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro aloja una función remota que se usa para inspeccionar la política de ubicación.
- Data Catalog almacena las ubicaciones de almacenamiento aprobadas como etiquetas.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
- Cloud Logging escribe los registros de auditoría.
- Security Command Center informa sobre cualquier resultado relacionado con la ubicación de los recursos o el acceso a los datos.
Para detectar problemas relacionados con este control, la arquitectura incluye un resultado sobre si la etiqueta de ubicaciones aprobada incluye la ubicación de los datos sensibles.
5. Se implementan, usan e interoperan los catálogos de datos
Este control requiere que exista un catálogo de datos y que la arquitectura pueda analizar elementos nuevos y actualizados para agregar metadatos según sea necesario.
Para cumplir con los requisitos de este control, la arquitectura usa Data Catalog. Data Catalog registra de forma automática los recursos de Google Cloud, incluidos los conjuntos de datos, las tablas y las vistas de BigQuery. Cuando creas una tabla nueva en BigQuery, Data Catalog registra de forma automática los metadatos técnicos y el esquema de la nueva tabla. Cuando actualizas una tabla en BigQuery, Data Catalog actualiza sus entradas casi al instante.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro, los datos no confidenciales.
- Data Catalog almacena los metadatos técnicos para las tablas y los campos.
De forma predeterminada, en esta arquitectura, Data Catalog almacena metadatos técnicos de BigQuery. Si es necesario, puedes integrar Data Catalog a otras fuentes de datos.
6. Las clasificaciones de datos están definidas y se usan
Esta evaluación requiere que los datos se puedan clasificar en función de su sensibilidad, como si son PII, identifican clientes o cumplen con otro estándar que define tu organización. Para cumplir con los requisitos de este control, la arquitectura crea un informe de los recursos de datos y su sensibilidad. Puedes usar este informe para verificar si la configuración de sensibilidad es correcta. Además, cada recurso de datos nuevo o cambio a un recurso de datos existente da como resultado una actualización del catálogo de datos.
Las clasificaciones se almacenan en la etiqueta sensitive_category en la plantilla de etiqueta de Data Catalog a nivel de tabla y a nivel de columna. Una tabla de referencia de clasificación te permite clasificar los tipos de información de la Protección de datos sensibles disponibles (Infotipos) con clasificaciones más altas para el contenido más sensible.
Para cumplir con los requisitos de este control, la arquitectura usa la Protección de datos sensibles, Data Catalog y Tag Engine para agregar las siguientes etiquetas a columnas sensibles en las tablas de BigQuery:
is_sensitive: Si el recurso de datos contiene información sensiblesensitive_category: Es la categoría de datos. Uno de los siguientes:- Información de identificación personal sensible
- Información de identificación personal
- Información personal sensible
- Información personal
- Información pública
Puedes cambiar las categorías de datos para cumplir con tus requisitos. Por ejemplo, puedes agregar la clasificación de información material no pública (MNPI).
Después de que la protección de datos sensibles inspecciona los datos, Tag Engine lee las tablas DLP results por elemento para compilar los resultados. Si una tabla contiene columnas con uno o más Infotipos sensibles, se determina el Infotipo más notable y las columnas sensibles y toda la tabla se etiquetan como la categoría que tiene la clasificación más alta. Tag Engine también asigna una etiqueta de política correspondiente a la columna y asigna la etiqueta booleana is_sensitive a la tabla.
Puedes usar Cloud Scheduler para automatizar la inspección de la Protección de datos sensibles.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Cuatro almacenes de datos de BigQuery almacenan la siguiente información:
- Datos confidenciales
- Información de resultados de la Protección de datos sensibles
- Datos de referencia de clasificación de datos
- Información de exportación de etiquetas
- Data Catalog almacena las etiquetas de clasificación.
- La Protección de datos sensibles inspecciona los elementos en busca de Infotipos sensibles.
- Compute Engine ejecuta la secuencia de comandos Inspect Datasets, que activa un trabajo de Protección de datos sensibles para cada conjunto de datos de BigQuery.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura incluye los siguientes resultados:
- Si se asigna una etiqueta de categoría sensible a los datos sensibles.
- Indica si a los datos sensibles se les asignó una etiqueta de tipo de sensibilidad a nivel de columna.
7. Los derechos de datos se administran y se aplican, y se hace un seguimiento de ellas
Según la configuración predeterminada, solo los creadores y propietarios que tienen derechos y acceso a datos sensibles. Además, este control requiere que la arquitectura realice un seguimiento de todo el acceso a los datos sensibles.
Para cumplir con los requisitos de este control, la arquitectura usa la taxonomía de etiquetas de política cdmc
sensitive data classification en BigQuery a fin de controlar el acceso a las columnas que contienen datos confidenciales en las tablas de BigQuery. La taxonomía incluye las siguientes etiquetas de política:
- Información de identificación personal sensible
- Información de identificación personal
- Información personal sensible
- Información personal
Las etiquetas de política te permiten controlar quién puede ver columnas sensibles en las tablas de BigQuery. La arquitectura asigna estas etiquetas de política a clasificaciones de sensibilidad que derivan de los Infotipos de la Protección de datos sensibles. Por ejemplo, la etiqueta de política sensitive_personal_identifiable_information y la categoría sensible se asignan a Infotipos como AGE, DATE_OF_BIRTH, PHONE_NUMBER y EMAIL_ADDRESS.
La arquitectura usa Identity and Access Management (IAM) para administrar los grupos, los usuarios y las cuentas de servicio que requieren acceso a los datos. Los permisos de IAM se otorgan a un recurso determinado para el acceso a nivel de tabla. Además, el acceso a nivel de columna basado en etiquetas de política permite un acceso detallado a los recursos de datos sensibles. De forma predeterminada, los usuarios no tienen acceso a las columnas que tienen etiquetas de política definidas.
Para garantizar que solo los usuarios autenticados puedan acceder a los datos, Google Cloud usa Cloud Identity, que puedes federar con tus proveedores de identidad existentes a fin de autenticar usuarios.
Este control también requiere que la arquitectura verifique regularmente para recursos de datos que no tengan derechos definidos. El detector, que administra Cloud Scheduler, verifica las siguientes situaciones:
- Un recurso de datos incluye una categoría sensible, pero no hay una etiqueta de política relacionada.
- Una categoría no coincide con la etiqueta de política.
Cuando ocurren estas situaciones, el detector genera resultados que Pub/Sub publica y, luego, escribe en la tabla events en BigQuery mediante Dataflow. Luego, puedes distribuir los resultados a tu herramienta de solución, como se describe en 1. Cumplimiento del control de datos.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Un almacén de datos de BigQuery almacena los datos confidenciales y las vinculaciones de etiquetas de política para controles de acceso detallados.
- IAM administra el acceso.
- Data Catalog almacena las etiquetas a nivel de tabla y de columna para la categoría sensible.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
Para detectar problemas relacionados con este control, la arquitectura verifica si los datos sensibles tienen una etiqueta de política correspondiente.
8. Se administra el acceso, el uso y los resultados éticos de los datos
Este control requiere que la arquitectura almacene acuerdos de uso compartido de datos del proveedor y del consumidor de datos, incluida una lista de propósitos de consumo aprobados. El propósito de consumo para los datos sensibles se asigna a los derechos almacenados en BigQuery mediante etiquetas de consulta.
Cuando un consumidor consulta datos sensibles en BigQuery, debe especificar un propósito válido que coincida con su derecho (por ejemplo, SET @@query_label = “use:3”;).
La arquitectura usa Data Catalog para agregar las siguientes etiquetas a la plantilla de etiqueta CDMC controls. Estas etiquetas representan el acuerdo de uso compartido de datos con el proveedor de datos:
approved_use: El uso aprobado o los usuarios del recurso de datossharing_scope_geography: Es la lista de ubicaciones geográficas en las que se puede compartir el recurso de datossharing_scope_legal_entity: Es la lista de entidades acordadas que pueden compartir el recurso de datos
Un almacén de datos de BigQuery independiente incluye el conjunto de datos entitlement_management con las siguientes tablas:
provider_agreement: El acuerdo de uso compartido de datos con el proveedor de datos, incluida la entidad legal acordada y el alcance geográfico. Estos datos son los predeterminados para las etiquetasshared_scope_geographyysharing_scope_legal_entity.consumer_agreement: El acuerdo de uso compartido de datos con el consumidor de datos, incluida la entidad legal acordada y el alcance geográfico. Cada acuerdo está asociado con una vinculación de IAM para el recurso de datos.use_purpose: El propósito de consumo, como la descripción del uso y las operaciones permitidas para el recurso de datosdata_asset: Información sobre el recurso de datos, como el nombre del elemento y detalles sobre el propietario de los datos.
A fin de auditar los acuerdos de uso compartido de datos, BigQuery mantiene un registro de auditoría completo para cada trabajo y consulta en cada conjunto de datos. El registro de auditoría se almacena en la vista Trabajos de esquema de información de BigQuery. Después de asociar una etiqueta de consulta con una sesión y ejecutar consultas dentro de la sesión, puedes recopilar registros de auditoría para las consultas con esa etiqueta de consulta. Si deseas obtener más información, consulta la referencia del registro de auditoría para BigQuery.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro almacena los datos de derechos, que incluyen los acuerdos de uso compartido de datos de proveedores y consumidores, y el propósito de uso aprobado.
- Data Catalog almacena la información del acuerdo de uso compartido de datos del proveedor como etiquetas.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura incluye los siguientes resultados:
- Indica si hay una entrada para un recurso de datos en el conjunto de datos
entitlement_management. - Indica si una operación se realiza en una tabla sensible con un caso de uso vencido (por ejemplo, se aprobó la
valid_until_dateenconsumer_agreement table). - Indica si una operación se realiza en una tabla sensible con una clave de etiqueta incorrecta.
- Indica si una operación se realiza en una tabla sensible con un valor de etiqueta de caso de uso en blanco o no aprobado.
- Si una tabla sensible se consulta con un método de operación no aprobado (por ejemplo,
SELECToINSERT). - Indica si el propósito registrado que el consumidor especificó cuando consulta los datos sensibles coincide con el acuerdo de uso compartido de datos.
9. Se protegen los datos y se verifican los controles
Este control requiere la implementación de la encriptación y la desidentificación de datos para ayudar a proteger los datos sensibles y proporcionar un registro de estos controles.
Esta arquitectura se basa en la seguridad predeterminada de Google, que incluye la encriptación en reposo. Además, la arquitectura te permite administrar tus propias claves mediante claves de encriptación administradas por el cliente (CMEK). Cloud KMS te permite encriptar los datos con claves de encriptación respaldadas por software o módulos de seguridad de hardware (HSM) validados en función del nivel 3 del estándar FIPS 140-2.
La arquitectura usa el enmascaramiento de datos dinámico a nivel de columna configurado mediante etiquetas de política y almacena datos confidenciales dentro de un perímetro de Controles del servicio de VPC independiente. También puedes agregar la desidentificación a nivel de aplicación, que puedes implementar de forma local o como parte de la canalización de transferencia de datos.
De forma predeterminada, la arquitectura implementa la encriptación de CMEK con HSM, pero también admite Cloud External Key Manager (Cloud EKM).
En la siguiente tabla, se describe la política de seguridad de ejemplo que la arquitectura implementa para la región us-central1. Puedes adaptar la política a fin de cumplir con tus requisitos, incluso si agregas diferentes políticas para diferentes regiones.
| Sensibilidad de los datos | Método de encriptación predeterminado | Otros métodos de encriptación permitidos | Método de desidentificación predeterminado | Otros métodos de desidentificación permitidos |
|---|---|---|---|---|
| Información pública | Encriptación predeterminada | Cualquiera | Ninguna | Cualquiera |
| Información de identificación personal sensible | CMEK con HSM | EKM | Anular | Hash o valor predeterminado de enmascaramiento SHA-256 |
| Información de identificación personal | CMEK con HSM | EKM | Hash SHA-256 | Nulo o valor de enmascaramiento predeterminado |
| Información personal sensible | CMEK con HSM | EKM | Valor de enmascaramiento predeterminado | Hash o Nullify de SHA-256 |
| Información personal | CMEK con HSM | EKM | Valor de enmascaramiento predeterminado | Hash o Nullify de SHA-256 |
La arquitectura usa Data Catalog para agregar la etiqueta encryption_method a la plantilla de etiqueta CDMC controls a nivel de tabla. El encryption_method define el método de encriptación que usa el recurso de datos.
Además, la arquitectura crea una etiqueta security policy template para identificar qué método de desidentificación se aplica a un campo en particular. La arquitectura usa el platform_deid_method, que se aplica mediante el enmascaramiento de datos dinámico. Puedes agregar app_deid_method y propagarlo con las canalizaciones de transferencia de datos de Dataflow y Protección de datos sensibles que se incluyen en el plano del almacén de datos seguro.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos instancias opcionales de Dataflow, una realiza la desidentificación a nivel de la aplicación y la otra realiza la reidentificación.
- Tres almacenes de datos de BigQuery: uno almacena los datos confidenciales, otro almacena los datos no confidenciales y el tercero almacena la política de seguridad.
- Data Catalog almacena las plantillas de etiquetas de encriptación y desidentificación.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Resultados publicados de Pub/Sub.
Para detectar problemas relacionados con este control, la arquitectura incluye los siguientes resultados:
- El valor de la etiqueta del método de encriptación no coincide con los métodos de encriptación permitidos para la sensibilidad y la ubicación especificadas.
- Una tabla contiene columnas sensibles, pero la etiqueta de la plantilla de políticas de seguridad contiene un método de desidentificación a nivel de la plataforma no válido.
- Una tabla contiene columnas sensibles, pero falta la etiqueta de la plantilla de política de seguridad.
10. Hay un marco de trabajo de privacidad de datos definido y operativo
Este control requiere que la arquitectura inspeccione el catálogo de datos y las clasificaciones para determinar si debes crear un informe de evaluación del impacto de la protección de datos (DPIA) o un informe de evaluación del impacto de la privacidad (PIA). Las evaluaciones de privacidad varían significativamente entre las ubicaciones geográficas y los reguladores. Para determinar si se requiere una evaluación de impacto, la arquitectura debe considerar la residencia de los datos y la residencia del sujeto de datos.
La arquitectura usa Data Catalog para agregar las siguientes etiquetas a la plantilla de etiqueta Impact assessment:
subject_locations: La ubicación de los sujetos a los que se hace referencia en los datos de este elemento.is_dpia: Si se completó una evaluación de impacto de la privacidad de los datos (DPIA) para este elemento.is_pia: Si se completó una evaluación de impacto de la privacidad (PIA) para este elemento.impact_assessment_reports: el vínculo externo a la ubicación donde se almacena el informe de la evaluación del impacto.most_recent_assessment: la fecha de la evaluación de impacto más reciente.oldest_assessment: la fecha de la primera evaluación de impacto.
Tag Engine agrega estas etiquetas a cada recurso de datos sensibles, como se define en el control 6. El detector valida estas etiquetas en una tabla de políticas en BigQuery, que incluye combinaciones válidas de residencia de datos, ubicación del sujeto, sensibilidad de los datos (por ejemplo, si es PII) y qué tipo de evaluación de impacto se requiere (PIA o DPIA).
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Cuatro almacenes de datos de BigQuery almacenan la siguiente información:
- Datos confidenciales
- Datos no confidenciales
- Marca de tiempo de la política de evaluación del impacto y autorizaciones
- Exportaciones de etiquetas que se usan en el panel
- Data Catalog almacena los detalles de la evaluación del impacto en etiquetas dentro de plantillas de etiquetas.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura incluye los siguientes resultados:
- Los datos sensibles existen sin una plantilla de evaluación de impacto.
- Los datos sensibles existen sin un vínculo a un informe de DPIA o PIA.
- Las etiquetas no cumplen con los requisitos de la tabla de políticas.
- La evaluación de impacto es más antigua que la autorización aprobada más reciente para el recurso de datos en la tabla de acuerdo del consumidor.
11. El ciclo de vida de los datos está planificado y administrado
Este control requiere la capacidad de inspeccionar todos los recursos de datos para determinar si existe una política del ciclo de vida de los datos y si se cumple.
La arquitectura usa Data Catalog para agregar las siguientes etiquetas a la plantilla de etiqueta CDMC controls:
retention_period: el tiempo, en días, que se debe conservar la tablaexpiration_action: indica si se debe archivar o borrar definitivamente la tabla cuando finaliza el período de retención
De forma predeterminada, la arquitectura usa el siguiente período de retención y la siguiente acción de vencimiento:
| Categoría de datos | Período de retención en días | Acción de vencimiento |
|---|---|---|
| Información de identificación personal sensible | 60 | Borrar definitivamente |
| Información de identificación personal | 90 | Archive |
| Información personal sensible | 180 | Archive |
| Información personal | 180 | Archive |
El Administrador de registros, un recurso de código abierto para BigQuery, automatiza la eliminación y el archivo definitivamente de las tablas de BigQuery según los valores de etiqueta anteriores y un archivo de configuración. El procedimiento de eliminación definitiva establece una fecha de vencimiento en una tabla y crea una tabla de instantánea con una hora de vencimiento que se define en la configuración del Administrador de registros. De forma predeterminada, el vencimiento es de 30 días. Durante el período de eliminación no definitiva, puedes recuperar la tabla. El procedimiento de archivo crea una tabla externa para cada tabla de BigQuery que pasa su período de retención. La tabla se almacena en Cloud Storage en formato Parquet y se actualiza a una tabla de BigLake que permite etiquetar el archivo externo con metadatos en Data Catalog.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro, la política de retención de datos.
- Dos instancias de Cloud Storage, una proporciona almacenamiento de archivos y la otra almacena registros.
- Data Catalog almacena el período de retención y la acción en las plantillas de etiquetas y las etiquetas.
- Dos instancias de Cloud Run, una ejecuta el Administrador de registros y la otra implementa los detectores.
- Tres instancias de Cloud Run, como se indica a continuación:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Otra instancia ejecuta el Administrador de registros, que automatiza la eliminación definitiva y el archivo de tablas de BigQuery.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura incluye los siguientes resultados:
- En el caso de los elementos sensibles, asegúrate de que el método de retención esté alineado con la política para la ubicación del recurso.
- En el caso de los elementos sensibles, asegúrate de que el período de retención esté alineado con la política para la ubicación del recurso.
12. Se administra la calidad de los datos
Este control requiere la capacidad de medir la calidad de los datos según la generación de perfiles de datos o las métricas definidas por el usuario.
La arquitectura incluye la capacidad de definir reglas de calidad de los datos para un valor individual o agregado y asignar límites a una columna de tabla específica. Incluye plantillas de etiquetas para la precisión y la integridad. Data Catalog agrega las siguientes etiquetas a cada plantilla de etiqueta:
column_name: el nombre de la columna a la que se aplica la métricametric: el nombre de la métrica o regla de calidadrows_validated: la cantidad de filas validadassuccess_percentage: el porcentaje de valores que satisfacen esta métricaacceptable_threshold: el umbral aceptable para esta métricameets_threshold: indica si el nivel de calidad (el valorsuccess_percentage) cumple con el umbral aceptablemost_recent_run: la hora más reciente en la que se ejecutó la métrica o la regla de calidad
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Tres almacenes de datos de BigQuery: uno almacena los datos sensibles, otro almacena los datos no sensibles y el tercero almacena las métricas de las reglas de calidad.
- Data Catalog almacena los resultados de calidad de los datos en plantillas y etiquetas de etiquetas.
- Cloud Scheduler define cuándo se ejecuta Cloud Data Quality Engine.
- Tres instancias de Cloud Run, como se indica a continuación:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- La tercera instancia ejecuta Cloud Data Quality Engine.
- Cloud Data Quality Engine define las reglas de calidad de los datos y programa verificaciones de calidad de los datos para las tablas y las columnas.
- Pub/Sub publica los resultados.
Un panel de Looker Studio muestra los informes de calidad de los datos para los niveles de tabla y de columna.
Para detectar problemas relacionados con este control, la arquitectura incluye los siguientes resultados:
- Los datos son sensibles, pero no se aplican plantillas de etiqueta de calidad de los datos (precisión e integridad).
- Los datos son sensibles, pero la etiqueta de calidad de los datos no se aplica a la columna sensible.
- Los datos son sensibles, pero los resultados de calidad de los datos no se encuentran dentro del umbral establecido en la regla.
- Los datos no son sensibles y los resultados de la calidad de los datos no se encuentran dentro del límite que estableció la regla.
Como alternativa al Cloud Data Quality Engine, puede configurar las tareas de calidad de los datos de Dataplex.
13. Se establecen y aplican principios de administración de costos
Este control requiere la capacidad de inspeccionar los recursos de datos para confirmar el uso de los costos, según los requisitos de las políticas y la arquitectura de datos. Las métricas de costos deben ser integrales y no solo se limitan al uso y el movimiento del almacenamiento.
La arquitectura usa Data Catalog para agregar la siguiente plantilla de etiqueta cost_metrics:
total_query_bytes_billed: la cantidad total de bytes de consulta que se facturaron para este recurso de datos desde el comienzo del mes actual.total_storage_bytes_billed: la cantidad total de bytes de almacenamiento que se facturaron para este recurso de datos desde el comienzo del mes actual.total_bytes_transferred: la suma de bytes transferidos entre regiones a este recurso de datos.estimated_query_cost: el costo estimado de la consulta, en dólares estadounidenses, por el recurso de datos del mes actual.estimated_storage_cost: el costo de almacenamiento estimado, en dólares estadounidenses, para el recurso de datos del mes actual.estimated_egress_cost: la salida estimada en dólares estadounidenses para el mes actual en el que el recurso de datos se usó como una tabla de destino.
La arquitectura exporta la información de precios de la Facturación de Cloud a una tabla de BigQuery llamada cloud_pricing_export.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Cloud Billing proporciona datos de facturación.
- Data Catalog almacena la información de costos en etiquetas y plantillas de etiquetas.
- BigQuery almacena la información de precios exportada y la información histórica del trabajo de consulta a través de su vista integrada INFORMATION_SCHEMA.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura verifica si existen recursos de datos sensibles sin tener métricas de costos asociadas.
14. Se comprende el linaje y la procedencia de los datos
Este control requiere la capacidad de inspeccionar la trazabilidad del recurso de datos desde su fuente y cualquier cambio en el linaje de recursos de datos.
Para mantener la información sobre la procedencia de los datos y el linaje, la arquitectura usa las funciones integradas de linaje de datos en Data Catalog. Además, las secuencias de comandos de transferencia de datos definen la fuente final y agregan la fuente como un nodo adicional al grafo de linaje de datos.
Para cumplir con los requisitos de este control, la arquitectura usa Data Catalog a fin de agregar la etiqueta ultimate_source a la plantilla de etiqueta CDMC
controls. La etiqueta ultimate_source define la fuente de este recurso de datos.
En el siguiente diagrama, se muestran los servicios que se aplican a este control.
Para cumplir con los requisitos de este control, la arquitectura usa los siguientes servicios:
- Dos almacenes de datos de BigQuery: uno almacena los datos confidenciales y el otro almacena los datos fuente finales.
- Data Catalog almacena la fuente final en las etiquetas y las plantillas de etiquetas.
- Las secuencias de comandos de transferencia de datos cargan los datos desde Cloud Storage, definen la fuente final y agregan la fuente al grafo de linaje de datos.
- Dos instancias de Cloud Run, de la siguiente manera:
- Una instancia ejecuta el motor de informes, que verifica si se aplicaron etiquetas y publica los resultados.
- Otra instancia ejecuta Tag Engine, que etiqueta los datos en el almacén de datos seguro.
- Pub/Sub publica los resultados.
Para detectar problemas relacionados con este control, la arquitectura incluye las siguientes verificaciones:
- Los datos sensibles se identifican sin una etiqueta de origen final.
- El grafo de linaje no se propaga para los recursos de datos sensibles.
Referencia de la etiqueta
En esta sección, se describen las etiquetas y plantillas de etiqueta que esta arquitectura usa para cumplir con los requisitos de los controles de claves de CDMC.
Plantillas de etiquetas de control de CDMC a nivel de tabla
En la siguiente tabla, se enumeran las etiquetas que forman parte de la plantilla de etiqueta de control de CDMC y que se aplican a las tablas.
| Etiqueta | ID de la etiqueta | Control clave aplicable |
|---|---|---|
| Ubicación de almacenamiento aprobada | approved_storage_location |
4 |
| Uso aprobado | approved_use |
8 |
| Correo electrónico del propietario de datos | data_owner_email |
2 |
| Nombre del propietario de los datos | data_owner_name |
2 |
| Método de encriptación | encryption_method |
9 |
| Acción de vencimiento | expiration_action |
11 |
| Está autorizada | is_authoritative |
3 |
| Es sensible | is_sensitive |
6 |
| Categoría sensible | sensitive_category |
6 |
| Comparte la geografía del alcance | sharing_scope_geography |
8 |
| Entidad legal de alcance de uso compartido | sharing_scope_legal_entity |
8 |
| Período de retención | retention_period |
11 |
| Fuente final | ultimate_source |
14 |
Plantilla de etiqueta de evaluación del impacto
En la siguiente tabla, se enumeran las etiquetas que forman parte de la plantilla de etiqueta de la evaluación de impacto y que se aplican a las tablas.
| Etiqueta | ID de la etiqueta | Control clave aplicable |
|---|---|---|
| Ubicaciones de los sujetos | subject_locations |
10 |
| Es evaluación del impacto DPIA | is_dpia |
10 |
| Es evaluación del impacto PIA | is_pia |
10 |
| Informes de la evaluación del impacto | impact_assessment_reports |
10 |
| Evaluación de impacto más reciente | most_recent_assessment |
10 |
| Evaluación de impacto más antigua | oldest_assessment |
10 |
Plantilla de etiqueta de métricas de costos
En la siguiente tabla, se enumeran las etiquetas que forman parte de la plantilla de etiquetas de métricas de costos y que se aplican a las tablas.
| Etiqueta | ID de la pestaña | Control clave aplicable |
|---|---|---|
| Costo estimado de consulta | estimated_query_cost |
13 |
| Costo estimado de almacenamiento | estimated_storage_cost |
13 |
| Costo estimado de salida | estimated_egress_cost |
13 |
| Total de bytes de consulta facturados | total_query_bytes_billed |
13 |
| Total de bytes de almacenamiento facturados | total_storage_bytes_billed |
13 |
| Total de bytes transferidos | total_bytes_transferred |
13 |
Plantilla de etiqueta de sensibilidad de datos
En la siguiente tabla, se enumeran las etiquetas que forman parte de la plantilla de etiquetas de sensibilidad de datos y que se aplican a los campos.
| Etiqueta | ID de la etiqueta | Control clave aplicable |
|---|---|---|
| Campo sensible | sensitive_field |
6 |
| Tipo sensible | sensitive_category |
6 |
Plantilla de etiqueta de política de seguridad
En la siguiente tabla, se enumeran las etiquetas que forman parte de la plantilla de etiquetas de la política de seguridad y que se aplican a los campos.
| Etiqueta | ID de la etiqueta | Control clave aplicable |
|---|---|---|
| Método de desidentificación de aplicaciones | app_deid_method |
9 |
| Método de desidentificación de la plataforma | platform_deid_method |
9 |
Plantillas de etiquetas de calidad de los datos
En la siguiente tabla, se enumeran las etiquetas que forman parte de las plantillas de etiquetas de calidad de los datos y la integridad y que se aplican a los campos.
| Etiqueta | ID de la etiqueta | Control clave aplicable |
|---|---|---|
| Umbral aceptable | acceptable_threshold |
12 |
| Nombre de la columna | column_name |
12 |
| Satisface el umbral | meets_threshold |
12 |
| Métrica | metric |
12 |
| Ejecución más reciente | most_recent_run |
12 |
| Filas validadas | rows_validated |
12 |
| Porcentaje de éxito | success_percentage |
12 |
Etiquetas de política de CDMC a nivel de campo
En la siguiente tabla, se enumeran las etiquetas de política que forman parte de la taxonomía de etiquetas de política de clasificación de datos sensibles de CDMC y que se aplican a los campos. Estas etiquetas de política restringen el acceso a nivel de campo y habilitan la desidentificación de datos a nivel de la plataforma.
| Clasificación de datos | Nombre de la etiqueta | Control clave aplicable |
|---|---|---|
| Información de identificación personal | personal_identifiable_information |
7 |
| Información personal | personal_information |
7 |
| Información de identificación personal sensible | sensitive_personal_identifiable_information |
7 |
| Información personal sensible | sensitive_personal_data |
7 |
Metadatos técnicos prepropagados
En la tabla siguiente, se enumeran los metadatos técnicos que se sincronizan de forma predeterminada en Data Catalog para todos los recursos de datos de BigQuery.
| Metadatos | Control clave aplicable |
|---|---|
| Tipo de recurso | — |
| Fecha/hora de creación | — |
| Fecha de vencimiento | 11 |
| Ubicación | 4 |
| URL del recurso | 3 |
¿Qué sigue?
- Obtén más información sobre CDMC.
- Lee sobre los controles de seguridad que usa el plano de almacén de datos seguro.
- Descubre Data Catalog.
- Más información sobre Dataplex.
- Más información sobre Tag Engine.
- Implementa esta solución con la arquitectura de referencia de CDMC de Google Cloud en GitHub.