Ayudar a proteger la canalización de tu data lake a tu almacén de datos

Introducción

En este artículo, se analizan los controles de seguridad diseñados para ayudar a administrar el acceso a los datos y evitar el robo de datos de la canalización desde el data lake hasta el almacén de datos.

En el artículo, se usa una canalización de ejemplo para demostrar las siguientes acciones:

  • Configurar permisos de IAM para otorgar acceso a un conjunto de personas que necesitan acceder a datos almacenados en una canalización de almacén de datos a data lake.
  • Configura controles de red para administrar las rutas de acceso a tus datos y ayudar a prevenir el robo de datos.
  • Implementa políticas con el servicio de políticas de la organización e IAM para aplicar tus controles de forma forzosa.
  • Usa Cloud KMS como parte de tu estrategia de encriptación.
  • Usa la API de Cloud Data Loss Prevention como parte de la canalización para clasificar y ocultar los datos sensibles (o asignarles tokens).
  • Usa herramientas de auditoría para ver quién accedió a tus datos.

Arquitectura

En el siguiente diagrama, se muestra la arquitectura de la canalización de ejemplo.

Arquitectura de los casos prácticos del data lake

Puedes usar esta arquitectura como base para varios casos prácticos del data lake. Para ayudarte a identificar la arquitectura que mejor se adapte a tu caso práctico, consulta Compila un data lake.

El ejemplo que se encuentra en este artículo se parece a la arquitectura de Compila un data lake, con algunas diferencias. Esta arquitectura de estadísticas por lotes también hace lo siguiente:

  • Usa Cloud Data Loss Prevention (Cloud DLP). Primero, todos los datos se analizan y procesan mediante Cloud DLP para identificar los datos clasificados como sensibles y asignarles tokens antes de subirlos al data lake. Los datos pasan por una clasificación y una extracción del flujo de trabajo con el fin de limpiar los datos, definirlos mejor y hacer que estén disponibles para el consumo.
  • Usa BigQuery y Cloud Storage como el destino final de los datos procesados (es decir, como el almacén de datos).
  • Admite el uso de Cloud Data Studio y Datalab para realizar consultas de los datos almacenados en BigQuery y Cloud Storage.

Terminología

Data lake: Un repositorio que almacena datos en su formato nativo. En esta arquitectura de ejemplo, se usa Cloud Storage, que se explica en la sección Cloud Storage como el data lake de Compila un data lake.

Almacén de datos: Un repositorio central de datos integrados de una o más fuentes dispares. Un almacén de datos almacena datos históricos y actuales en un solo lugar, en el que se pueden usar para generar estadísticas. En el almacén de datos de esta arquitectura de ejemplo, se incluyen datos almacenados en Cloud Storage y en BigQuery. Estos servicios reemplazan la configuración típica de un almacén de datos tradicional. Es decir, sirven como base colectiva para todos los datos analíticos de una organización.

Personas

En la siguiente tabla, se enumeran las personas y los servicios asociados con una canalización desde el data lake hasta el almacén de datos.

Persona Actividades
Cargador de datos Una cuenta de servicio o una persona que escribe datos en el data lake de Cloud Storage

Una cuenta de servicio que ejecuta cargas automáticas.
Las personas también pueden realizar cargas ad hoc.
Visualizador de datos La persona que consume datos de tablas de informes de BigQuery a través de Cloud Data Studio y otras herramientas de informes, como SAP Business Object.
Analista de datos (sin conocimientos de SQL) La persona que prepara datos en Dataprep (por ejemplo, une tablas desnormalizadas de BigQuery) y que desarrolla informes de Google Data Studio y de otras herramientas.
Analista de datos (con conocimientos de SQL) La persona que realiza análisis ad hoc en BigQuery (mediante el uso de tablas desnormalizadas), prepara tablas de informes en BigQuery y desarrolla informes de Data Studio y de otras herramientas.
Científico de datos La persona que realiza tareas de ciencia de datos, incluidos el análisis de datos estadísticos y el desarrollo de modelos de aprendizaje automático, mediante el uso de varias soluciones.

Entre las soluciones, se pueden incluir AI Platform, Datalab, R Studio y SAS.

Los científicos de datos pueden realizar actividades ad hoc y desarrollar modelos.
Ingeniero de datos La persona que desarrolla canalizaciones para trasladar datos a Cloud Storage y a BigQuery. Crea tablas en BigQuery e implementa modelos de AA y canalizaciones desarrolladas por científicos de datos. Usa soluciones como Dataflow, Dataproc, Cloud Composer y Dataprep by Trifacta, además de otras soluciones de ciencia de datos.
Operaciones La persona que implementa el trabajo de desarrollo, que realizan los ingenieros de datos, mediante el uso de la organización, CI/CD y otras herramientas durante la producción.
Proporcionan entornos para el uso de los ingenieros y los científicos de datos, y compilan imágenes de VM para el uso de soluciones de ciencia de datos de terceros, como R Studio y Anaconda. Configuran estructuras de depósitos de Cloud Storage para el data lake y el almacén de datos y crean los conjuntos de datos de BigQuery.
Identidades operativas Las cuentas de servicio que se usan para ejecutar canalizaciones.

En la siguiente tabla, se enumeran las actividades y las funciones de trabajo del cliente y cómo estas se asignan a las personas de la tabla anterior en la arquitectura de ejemplo de este artículo.

Función de trabajo del cliente Actividades Personas
Cargador de datos ad hoc Sube los datos directamente a Cloud Storage. Cargador de datos
Ingeniero de datos Desarrolla canalizaciones para trasladar datos a Cloud Storage y a BigQuery, crea tablas de Cloud Storage en BigQuery y pone en funcionamiento las canalizaciones. Ingeniero de datos,
operaciones
Analista de negocios del almacén de datos (DW-BA) Visualiza sus propios datos después de que se hayan cargado en el almacén de datos. Analista de datos,
visualizador de datos
Analista de negocios transversal (CS-BA)
Analista de marketing
Visualiza un conjunto predefinido de datos después de que se hayan cargado en el almacén de datos. (Es el equivalente al acceso de varios DW-BA). Analista de datos,
visualizador de datos
Superanalista de negocios Visualiza todos los datos del data lake y del almacén de datos y usa herramientas como Dataprep en el data lake. Analista de datos,
visualizador de datos

A menudo, las funciones de trabajo del cliente no se asignan directamente a las personas de la tabla anterior. Es posible que existan funciones de trabajo que combinen personas individuales. La clave es asignar a una persona las habilidades que necesita para realizar las actividades.

Prácticas recomendadas para el control de acceso

Se recomienda respetar el principio de privilegio mínimo. En esta sección, se analizan las opciones de control de acceso en IAM, BigQuery y Cloud Storage.

Define políticas que otorguen acceso con IAM

Usa IAM para otorgar permisos a los recursos de Google Cloud que conforman la arquitectura. Antes de otorgar permisos, debes comprender con exactitud qué actividades realizan las personas en la canalización. Esto te ayudará a determinar los niveles de acceso que requiere cada función de trabajo.

Sigue las prácticas recomendadas de IAM para definir tus políticas de control de acceso de IAM.

En el siguiente diagrama, se muestra cómo interactúan las funciones de trabajo de la arquitectura de ejemplo con los datos y los servicios y en qué lugares se producen esas interacciones.

Interacciones de la arquitectura de las funciones de trabajo

Sube datos

Los datos se suben al data lake mediante un proceso automatizado y, en ocasiones, mediante un proceso ad hoc. Mediante el proceso automatizado, solo se pueden agregar datos al data lake (es decir, no se pueden leer, borrar o modificar datos en el data lake).

La cuenta de servicio que ejecuta el proceso de carga automatizada y cualquier cargador de datos ad hoc, debe tener la siguiente función de IAM para trabajar con los recursos que necesita.

Función Recursos Miembros Permisos

storage.objectCreator
Depósitos de Cloud Storage La cuenta de servicio para ejecutar cargas automatizadas

El cargador de datos ad hoc
(El superanalista de negocios)
Permite que la aplicación del cargador cree objetos (pero no que los visualice, los borre ni los reemplace).

En la arquitectura de ejemplo, los datos se suben a depósitos especificados. La ubicación del depósito se define cuando invocas el proceso del cargador. Puedes crear grupos separados de cargadores (y cuentas de servicio, si es necesario) para segregar aún más quién puede acceder a cada depósito.

Antes de subir los datos al data lake, es posible que debas ocultar los datos sensibles o asignarles tokens. Puedes hacer esto mediante la API de Cloud DLP, lo cual se explica más adelante en este artículo.

Procesamiento de datos

Debido a que el data lake almacena los datos en un formato sin procesar, a menudo los datos se deben procesar antes de que puedas cargarlos al almacén de datos. Por ejemplo, puede que el procesamiento incluya la limpieza, la transformación y la anulación de duplicación de los datos. Entre las herramientas de Google Cloud para el procesamiento de datos se incluyen Cloud Composer, Dataproc, Dataflow, BigQuery y Dataprep.

Los ingenieros de datos y la cuenta de servicio que ejecuta los trabajos de Cloud Composer deben tener las siguientes funciones de IAM para trabajar con los recursos que necesitan.

Función Recursos Miembros Permisos

roles/composer.admin
proyecto Ingeniero de datos Otorga a un ingeniero de datos el control total de los recursos de Cloud Composer. Esta función no otorga acceso directo a los datos de los depósitos.

roles/composer.worker
proyecto Cuenta de servicio para ejecutar Cloud Composer Otorga a una cuenta de servicio los permisos necesarios para ejecutar un entorno de Cloud Composer en la VM con la que está asociado.

Los ingenieros de datos pueden acceder a la interfaz web de Cloud Composer a través de Identity-Aware Proxy (IAP). Cloud Composer es un servicio de organización de flujos de trabajo compilado en Apache Airflow que realiza llamadas a más API, por ejemplo, para iniciar un clúster de Dataproc. La cuenta de servicio asociada con tu entorno de Cloud Composer necesita permisos para poder usar esos recursos. Como mínimo, la cuenta de servicio debe tener los permisos roles/composer.worker.

La cuenta de servicio de Dataflow debe tener las siguientes funciones de IAM para trabajar con los recursos que necesita.

Función Recursos Miembros Permisos

dataflow.worker
organización Cuenta de servicio para ejecutar unidades de trabajo de Dataflow Otorga a una cuenta de servicio permiso para ejecutar unidades de trabajo de una canalización de Dataflow.

Mediante Dataprep, puedes explorar y transformar de forma visual los datos sin procesar de los conjuntos de datos grandes y dispares. Debes usar Dataprep por separado del proceso automatizado que usan Dataflow y Cloud Composer.

La cuenta de servicio de Dataprep y el analista de negocios deben tener las siguientes funciones de IAM para poder trabajar con los recursos que necesitan.

Función Recursos Miembros Permisos

dataprep.ServiceAgent
proyecto Cuenta de servicio de Dataprep Otorga a la cuenta de servicio de Dataprep permiso para acceder a los conjuntos de datos y al almacenamiento y modificarlos, y para ejecutar y administrar trabajos de Dataprep dentro de un proyecto.

dataprep.user
proyecto Analistas de datos Permite que una persona ejecute la aplicación de Dataprep.

Almacén de datos

En la situación de ejemplo, hay diferentes analistas de datos que tienen diferentes niveles de acceso a los datos del almacén de datos.

Analista de negocios

El analista de negocios del almacén de datos (DW-BA) tiene una vista de sus datos después de que se hayan cargado en el almacén de datos.

El DW-BA tiene las siguientes funciones de IAM para trabajar con los recursos que necesita.

Función Recursos Miembros Permisos


bigquery.user

proyecto DW-BA Permite que el DW-BA ejecute consultas en conjuntos de datos definidos por los permisos que se otorgan en la función bigquery.dataviewer.

bigquery.dataviewer
Conjuntos de datos de BigQuery DW-BA Permite que los DW-BA que tengan la función bigquery.user en el proyecto ejecuten consultas en los datos del conjunto de datos especificado.

storage.objectviewer
depósito DW-BA Otorga permiso para ver la fuente de datos federada (ya que los datos del almacén de datos se almacenan en Cloud Storage y en BigQuery).

El DW-BA puede iniciar clústeres de Dataproc y ejecutar consultas de Hive en sus datos mediante una cuenta de servicio administrada por el usuario. La cuenta de servicio debe tener las siguientes funciones de IAM para trabajar con los recursos que necesita.

Función Recursos Miembros Permisos


dataproc.editor

proyecto DW-BA Otorga permisos para iniciar clústeres de Dataproc y ejecutar trabajos, lo cual es necesario si deseas ejecutar consultas de Hive en los datos almacenados en Cloud Storage.

El DW-BA no necesita tener la capacidad de subir archivos a Cloud Storage, debido a que los archivos ya se subieron.

El DW-BA debe tener las siguientes funciones de IAM para poder ver el resultado de los trabajos en el depósito especificado.

Función Recursos Miembros Permisos

storage.objectviewer
depósito DW-BA Otorga permiso para ver la fuente de datos federada.

Debes seguir la práctica recomendada que consiste en usar una cuenta de servicio administrada por el usuario para iniciar clústeres de Dataproc. De esta manera, los trabajos de larga duración pueden continuar después de que se rescinda el acceso del usuario que los inició en un principio. También puedes crear controles y accesos detallados para los clústeres.

La cuenta de servicio administrada por el usuario debe tener la siguiente función de IAM para poder trabajar con los recursos que necesita.

Función Recursos Miembros Permisos

dataproc.worker
proyecto Cuenta de servicio de Dataproc Permite que la cuenta de servicio inicie y ejecute clústeres de Dataproc.

Para lograr un mayor nivel de detalle con tus permisos, consulta IAM detallada de Dataproc.

Analista de negocios transversales

En esta situación, el analista de negocios de transversales (CS-BA) o el analista de marketing puede ver un conjunto predefinido de datos después de que se hayan cargado en el almacén de datos. El acceso es el equivalente a varias vistas de DW-BA.

En nuestro ejemplo, los conjuntos de datos y los depósitos de Cloud Storage que el CS-BA puede ver se encuentran en el mismo proyecto.

El CS-BA debe tener las siguientes funciones de IAM para poder trabajar con los recursos que necesita.

Función Recursos Miembros Permisos

bigquery.user
proyecto CS-BA Permite que el CS-BA ejecute consultas en los conjuntos de datos en los que tiene la función bigquery.dataviewer.

bigquery.dataviewer
proyecto CS-BA Permite que el CS-BA enumere todos los conjuntos de datos del proyecto, lea los metadatos, enumere las tablas de estos y lea los datos y los metadatos de estas tablas.

storage.objectviewer
proyecto CS-BA Otorga permiso para ver la fuente de datos federada.

Si trabajas con una cantidad administrable de conjuntos de datos y depósitos federados, el uso de la configuración del DW-BA es suficiente. Debes otorgar los permisos adecuados en cada depósito y en cada conjunto de datos, en lugar de otorgar permisos a nivel de proyecto.

Superanalista de negocios

En esta situación, el superanalista de negocios (S-BA) puede ver todos los datos del data lake después de que se hayan cargado en el almacén de datos.

El S-BA debe tener las siguientes funciones de IAM para poder trabajar con los recursos que necesita.

Función Recursos Miembros Permisos

bigquery.user
organización S-BA Permite que el S-BA ejecute consultas en los conjuntos de datos en los que tiene la función bigquery.dataviewer.

La función bigquery.user no otorga permiso a los usuarios para consultar datos, ver datos de tablas o ver detalles de esquemas de tablas en los conjuntos de datos que el usuario no creó.

Función Recursos Miembros Permisos

bigquery.dataviewer
organización S-BA Permite que los S-BA enumeren todos los conjuntos de datos del proyecto, lean los metadatos y enumeren las tablas de estos y lean los datos y los metadatos de estas tablas.

storage.objectviewer
organización S-BA Otorga permiso para ver la fuente de datos federada.

El S-BA también puede usar Dataprep para transformar los datos que se cargarán en el almacén de datos.

Visualizador de datos

Los analistas de negocios también pueden usar informes que generan Data Studio y Datalab. Datalab usa la cuenta de servicio de la VM de Datalab. Antes de poder ejecutar el notebook para generar el informe, debes otorgar al analista de negocios y a la cuenta de servicio las siguientes funciones de IAM.

Función Recursos Miembros Permisos

iam.serviceAccountUser
cuenta de servicio Analista de negocios Otorga al analista de negocios acceso para conectarse a la instancia de Datalab. Debe tener la función serviceAccountUser en la cuenta de servicio que inició la instancia de Datalab.

Datalab requiere que se otorgue acceso a una sola instancia a los usuarios individuales.

Debes otorgar acceso a BigQuery, Cloud Storage y Dataflow a la cuenta de servicio que se use para iniciar la instancia de Datalab. La cuenta de servicio debe tener las siguientes funciones de IAM para trabajar con los recursos que necesita.

Función Recursos Miembros Permisos

bigquery.user
organización cuenta de servicio Permite que la cuenta de servicio de Datalab ejecute consultas en los conjuntos de datos en los que tiene la función bigquery.dataviewer.

bigquery.dataviewer
organización cuenta de servicio Permite que la cuenta de servicio enumere todos los conjuntos de datos del proyecto, lea los metadatos, enumere las tablas del conjunto de datos y lea los datos y los metadatos de las tablas.

storage.objectviewer
organización cuenta de servicio Otorga permiso para ver la fuente de datos federada.

Data Studio debe tener las credenciales de la fuente de datos adecuada para acceder a los conjuntos de datos de BigQuery. Para obtener información, consulta Credenciales de la fuente de datos.

Configura un control de acceso detallado mediante BigQuery

Puedes administrar el control de acceso detallado de las vistas de los datos en BigQuery, por ejemplo, cuando tienes varios analistas de negocios que necesitan diferentes niveles de acceso. A continuación, se muestra una situación:

  • El analista de negocios del almacén de datos (DW-BA) tiene una vista de sus datos.
  • El analista de negocios transversales (CS-BA) o el analista de marketing tiene una vista de un conjunto predefinido de datos después de que se hayan cargado en el almacén de datos. El acceso requerido es el equivalente a varias vistas de DW-BA.
  • El superanalista de negocios (S-BA) tiene una vista de todos los datos que se encuentren en el data lake o después de que se hayan cargado en el almacén de datos.

Además de los permisos de IAM, debes configurar las vistas autorizadas.

Las vistas autorizadas te permiten compartir resultados de las consultas con usuarios y grupos específicos sin otorgarles acceso a las tablas subyacentes. En la situación de ejemplo, puedes proporcionar las vistas seleccionadas al DW-BA y al CS-BA. La vista se crea en un conjunto de datos que es independiente de los datos de origen que consulta la vista. Debes otorgar al analista de negocios acceso al conjunto de datos en función de la vista.

Para obtener asesoramiento sobre cómo implementar el acceso restringido en los conjuntos de datos de BigQuery, consulta Caso práctico de las cargas de trabajo de datos seguros: Limita el acceso de identidades específicas a los datos.

En esta situación, no necesitas configurar los permisos de nivel de fila. Sin embargo, puedes mostrar distintas filas a distintos usuarios, si tu situación lo requiere. Debes agregar otro campo a tus tablas que contenga el usuario que tiene permiso para ver la fila. Luego, debes crear una vista en la que se use la función SESSION_USER(). La función SESSION_USER() muestra el usuario actual (la dirección de correo electrónico con la que se autentica en Google Cloud). Si SESSION_USER() muestra un usuario que está contenido en el campo que agregaste, este podrá ver los datos de esa fila.

Otorga acceso a objetos específicos en Cloud Storage

Por lo general, IAM es la opción correcta para la administración del acceso a los depósitos y los objetos que contienen, que es el enfoque que se muestra en la canalización. Sin embargo, Cloud Storage tiene otros mecanismos de control de acceso, que puedes usar en una canalización cuando desees otorgar acceso a un objeto específico dentro de un depósito. Para ello, debes usar listas de control de acceso o URL firmadas.

Políticas de la organización

Puedes usar la política de la organización para configurar restricciones en los recursos compatibles. Debes configurar restricciones en los recursos compatibles. Las restricciones que se aplican a la canalización de muestra son las siguientes:

  • Uso compartido restringido al dominio: Restringe el conjunto de usuarios que se pueden agregar a las políticas de IAM en la organización en la que se configuró la canalización. En la lista de usuarios permitidos o rechazados, se deben especificar uno o más ID de clientes de G Suite o Cloud Identity.

    Para usar Cloud Composer, debes inhabilitar la restricción de la política antes de crear un entorno, de forma que Cloud Composer pueda aplicar las LCA necesarias en el depósito de Cloud Storage de tu entorno. Puedes volver a habilitar la restricción de la política después de crear el entorno.

    Para obtener asesoramiento sobre cómo implementar el uso compartido restringido al dominio, consulta Casos prácticos de las cargas de trabajo de datos seguros: Evita el acceso de identidades que no sean del dominio.

  • Inhabilita la creación de claves de cuentas de servicio: Impide la creación de claves externas de cuentas de servicio mediante la configuración esta restricción como TRUE.

  • Aplica de forma forzosa solo la política del depósito: Inhabilita la evaluación de las LCA asignadas a los objetos de Cloud Storage del depósito, de forma que solo las políticas de IAM puedan otorgar acceso a los objetos de estos depósitos.

Realiza verificaciones de identidad y de autorización mediante IAP

Identity-Aware Proxy (IAP) establece una capa central de autorización para las aplicaciones alojadas en Google Cloud a las que se accede mediante HTTPS. Cuando una aplicación o un recurso están protegidos por IAP, solo los usuarios que tengan la función de IAM correcta pueden acceder a ellos a través del proxy. Cuando un usuario intenta acceder a un recurso protegido por IAP, IAP realiza verificaciones de autenticación y de autorización. En la canalización de ejemplo, IAP se usa para acceder a la interfaz web de Cloud Composer.

Define un perímetro de seguridad mediante VPC

Si configuras los controles del servicio de VPC, puedes definir un perímetro de seguridad en torno a los recursos de Google Cloud, como los depósitos de Cloud Storage y los conjuntos de datos de BigQuery. De esta forma, limitas los datos dentro de una nube privada virtual (VPC), lo que ayuda a mitigar los riesgos de robo de datos.

El acceso privado a Google para las instalaciones locales permite a los hosts locales acceder a los servicios y las API de Google a través de una conexión de Cloud VPN o Cloud Interconnect desde tu centro de datos hacia Google Cloud. Los hosts locales no necesitan direcciones IP externas, sino que usan direcciones IP RFC 1918 internas.

La siguiente arquitectura de muestra restringe el acceso a los proyectos que contienen el data lake y el almacén de datos complementando los controles de IAM con Acceso privado a Google y los Controles del servicio de VPC. El acceso de emergencia para los operadores y los ingenieros de datos se implementa en el caso de que no esté disponible la comunicación privada entre las instalaciones locales y Google Cloud. También se configuran los controles de acceso adaptado al contexto.

Esta configuración se ilustra en el siguiente diagrama de la arquitectura:

Arquitectura en la que los ingenieros de datos tienen acceso de emergencia

Si deseas obtener asesoramiento sobre la implementación de los controles del servicio de VPC a fin de mitigar el robo de datos, consulta Mitiga el robo de datos para las apps y Mitiga el robo de datos para las personas.

Para obtener asesoramiento sobre la implementación del acceso administrado a las API de Google Cloud, consulta Acceso administrado a las API de Google Cloud.

Audita quién, dónde y cuándo

Los registros de auditoría de Cloud constan de tres transmisiones de registros de auditoría para cada proyecto, carpeta y organización:

  • Actividad del administrador
  • Evento del sistema
  • Acceso a los datos

Los servicios de Google Cloud escriben entradas de registro de auditoría en estos registros para ayudarte a responder las preguntas “¿Quién hizo qué, dónde y cuándo?” dentro de tus proyectos de Google Cloud.

Los registros de actividad del administrador contienen entradas de registro de llamadas a la API o algunas otras acciones administrativas que modifican la configuración o los metadatos de los recursos. Los registros de actividad del administrador siempre están habilitados. No se aplican cargos por los registros de auditoría de la actividad del administrador. Además, estos se conservan durante 13 meses (400 días).

Los registros de acceso a los datos registran las llamadas a la API que crean, modifican o leen los datos proporcionados por el usuario. Los registros de auditoría de acceso a los datos se encuentran inhabilitados de forma predeterminada, excepto en BigQuery, ya que pueden aumentar de tamaño y volverse grandes.

Los registros de los eventos del sistema contienen entradas de registros de los momentos en que Compute Engine realiza un evento del sistema. Por ejemplo, cada migración en vivo se registra como un evento del sistema. No se te cobrará por los registros de auditoría de los eventos del sistema.

En la canalización de ejemplo, debes auditar los registros del administrador y de acceso a los datos. Los siguientes servicios tienen registros de auditoría de acceso a los datos configurados para la arquitectura de ejemplo:

Las funciones de IAM del registro de auditoría están configuradas para restringir el acceso a los registros. Las exportaciones de registros (que no se muestran) también están configuradas para proporcionar una forma de recopilar y retener los registros durante más tiempo de lo que dura el período de retención predeterminado. Consulta Diseña patrones para exportar Cloud Logging a fin de obtener ejemplos de situaciones y de cómo configurar una estrategia de exportación de Logging.

Protege los datos de PII

La información de identificación personal, o PII, es cualquier información relacionada con la identificación de una persona específica.

Google Cloud encripta los datos del cliente almacenados en reposo de forma predeterminada, sin que debas realizar ninguna acción adicional.

Los datos en Google Cloud se dividen en fragmentos de subarchivos para el almacenamiento. Cada fragmento se encripta a nivel de almacenamiento con una clave de encriptación individual. La clave que se usa para encriptar los datos de un fragmento se denomina clave de encriptación de datos (DEK). Debido a la gran cantidad de claves que se usan en Google y a la necesidad de contar con una latencia baja y una disponibilidad alta, estas claves se almacenan cerca de los datos que encriptan. Las DEK se encriptan (o “se unen”) mediante una clave de encriptación de claves (KEK). Los clientes pueden elegir qué solución de administración de claves prefieren para la administración de las KEK que protegen las DEK, que, a su vez, protegen sus datos.

En las operaciones sensibles, es posible que debas generar y administrar tus propias claves de encriptación de claves mediante el uso de claves de encriptación proporcionadas por el cliente (CSEK) o puedes administrar las claves de encriptación mediante Cloud KMS.

En nuestra canalización de ejemplo, tenemos un requisito para la administración de claves mediante Cloud KMS cuando se usa Cloud DLP a fin de asignar tokens a los datos sensibles.

La API de Prevención de pérdida de datos de Cloud (DLP) proporciona acceso programático a una potente plataforma de inspección, clasificación y desidentificación de datos sensibles.

La API de DLP procesa los datos. Luego, los datos procesados se pueden escribir en un receptor.

Arquitectura de los procesos de canalización de datos

Si se te solicita, por motivos de políticas o de cumplimiento, identificar los elementos de los datos sensibles y asignarles tokens antes de escribir los datos en el data lake, puedes usar la API de DLP junto con Cloud KMS. La API de DLP se puede usar para asignar tokens a los elementos de los datos sensibles como parte del proceso de carga. Si también necesitas anular la asignación de tokens (es decir, revelar el elemento original de los datos sin procesar), puedes usar la clave de KMS y el hash criptográfico que se usaron, en un principio, para asignar los tokens a los elementos de los datos.

Arquitectura de la identificación de los elementos de los datos sensibles y su asignación de tokens

Para obtener detalles sobre cómo implementar el proceso de asignación de tokens y de anulación de la asignación, consulta Desidentifica los datos sensibles de un texto.

En la arquitectura de la canalización de muestra, se usa Cloud DLP en la etapa de transferencia para clasificar los datos cuando se suben al data lake. A todos los datos sensibles detectados se les asignan tokens mediante el uso de la clave administrada por Cloud KMS.

Próximos pasos