Una plataforma de gestión y analíticas de datos empresariales proporciona un enclave en el que puedes almacenar, analizar y manipular información sensible sin renunciar a los controles de seguridad. Puede usar la arquitectura de malla de datos empresariales para implementar una plataforma en Google Cloud para la gestión y las analíticas de datos. La arquitectura está diseñada para funcionar en un entorno híbrido, donde los Google Cloud componentes Google Cloud interactúan con los componentes y los procesos operativos locales.
La arquitectura de malla de datos empresariales incluye lo siguiente:
- Un repositorio de GitHub
que contiene un conjunto de configuraciones, secuencias de comandos y código de Terraform para crear lo siguiente:
- Un proyecto de gobernanza que te permite usar la implementación de Google del marco de controles de claves de las funciones de gestión de datos en la nube (CDMS).
- Ejemplo de una plataforma de datos que admite flujos de trabajo interactivos y de producción.
- Un entorno de productor en la plataforma de datos que admite varios dominios de datos. Los dominios de datos son agrupaciones lógicas de elementos de datos.
- Un entorno de consumidor en la plataforma de datos que admite varios proyectos de consumidor.
- Un servicio de transferencia de datos que usa la federación de identidades de carga de trabajo y la biblioteca de cifrado Tink para ayudarte a transferir datos a Google Cloud de forma segura.
- Ejemplo de dominio de datos que contiene proyectos de ingestión, no confidenciales y confidenciales.
- Un ejemplo de sistema de acceso a datos que permite a los consumidores de datos solicitar acceso a conjuntos de datos y a los propietarios de datos conceder acceso a esos conjuntos de datos. El ejemplo también incluye un gestor de flujo de trabajo que cambia los permisos de gestión de identidades y accesos de esos conjuntos de datos en consecuencia.
- Una guía sobre la arquitectura, el diseño, los controles de seguridad y los procesos operativos que se utilizan para implementar esta arquitectura (este documento).
La arquitectura de malla de datos empresarial se ha diseñado para que sea compatible con el blueprint de las bases empresariales. El blueprint de bases empresariales proporciona una serie de servicios básicos en los que se basa esta arquitectura, como las redes de VPC y el registro. Puedes implementar esta arquitectura sin implementar el blueprint de las bases empresariales si tu entorno deGoogle Cloud proporciona las funciones necesarias.
Este documento está dirigido a arquitectos de la nube, científicos de datos, ingenieros de datos y arquitectos de seguridad que pueden usar la arquitectura para crear e implementar servicios de datos integrales en Google Cloud. En este documento se presupone que conoces los conceptos de mallas de datos, Google Cloudservicios de datos y la Google Cloud implementación del marco de CDMC.
Arquitectura
La arquitectura de malla de datos empresarial adopta un enfoque por capas para proporcionar las funciones que permiten la ingestión, el procesamiento y la gobernanza de los datos. La arquitectura se ha diseñado para que se despliegue y controle mediante un flujo de trabajo de CI/CD. En el siguiente diagrama se muestra cómo se relaciona la capa de datos implementada por esta arquitectura con otras capas de su entorno.
Este diagrama incluye lo siguiente:
- La Google Cloud infraestructura proporciona funciones de seguridad como el cifrado en reposo y el cifrado en tránsito, así como componentes básicos como la computación y el almacenamiento.
- La base empresarial proporciona un conjunto de recursos, como sistemas de identidad, redes, registro, monitorización e implementación, que te permiten adoptar Google Cloud para tus cargas de trabajo de datos.
- La capa de datos ofrece varias funciones, como la ingestión, el almacenamiento, el control de acceso, la gobernanza, la monitorización y el uso compartido de datos.
- La capa de aplicación representa varias aplicaciones diferentes que usan los recursos de la capa de datos.
- La CI/CD proporciona las herramientas para automatizar el aprovisionamiento, la configuración, la gestión y el despliegue de la infraestructura, los flujos de trabajo y los componentes de software. Estos componentes te ayudan a asegurar implementaciones coherentes, fiables y auditables, a minimizar los errores manuales y a acelerar el ciclo de desarrollo en general.
Para mostrar cómo se usa el entorno de datos, la arquitectura incluye un flujo de trabajo de datos de ejemplo. El flujo de trabajo de datos de muestra te guía por los siguientes procesos: gobernanza de datos, ingestión de datos, tratamiento de datos, uso compartido de datos y consumo de datos.
Decisiones arquitectónicas clave
En la siguiente tabla se resumen las decisiones de alto nivel de la arquitectura.
| Área de decisión | Decisión |
|---|---|
| Google Cloud arquitectura | |
Jerarquía de recursos |
La arquitectura usa la jerarquía de recursos del plano técnico de aspectos básicos de seguridad para empresas. |
Redes |
La arquitectura incluye un servicio de transferencia de datos de ejemplo que usa Federación de Identidades de Cargas de Trabajo y una biblioteca de Tink. |
Roles y permisos de gestión de identidades y accesos |
La arquitectura incluye roles de productor de datos segmentados, roles de consumidor de datos, roles de gobierno de datos y roles de plataforma de datos. |
| Servicios de datos comunes | |
Metadatos |
La arquitectura usa Data Catalog para gestionar los metadatos. |
Gestión centralizada de políticas |
Para gestionar las políticas, la arquitectura usa la implementación del marco de CDMC de Google Cloud. |
Gestión del acceso a datos |
Para controlar el acceso a los datos, la arquitectura incluye un proceso independiente que requiere que los consumidores de datos soliciten acceso a los recursos de datos al propietario de los datos. |
Calidad de los datos |
La arquitectura usa Cloud Data Quality Engine para definir y ejecutar reglas de calidad de los datos en las columnas de las tablas especificadas, así como para medir la calidad de los datos en función de métricas como la exactitud y la integridad. |
Seguridad de los datos |
La arquitectura usa el etiquetado, el cifrado, el enmascaramiento, la tokenización y los controles de gestión de identidades y accesos para proporcionar seguridad a los datos. |
| Dominio de datos | |
Entornos de datos |
La arquitectura incluye tres entornos. Dos entornos (de no producción y de producción) son entornos operativos que se rigen por las canalizaciones. Un entorno (desarrollo) es un entorno interactivo. |
Propietarios de los datos |
Los propietarios de los datos ingieren, tratan, exponen y conceden acceso a los recursos de datos. |
Consumidores de datos |
Los consumidores de datos solicitan acceso a los recursos de datos. |
| Incorporación y operaciones | |
Flujos de procesamiento |
La arquitectura usa las siguientes canalizaciones para implementar recursos:
|
Repositorios |
Cada canal usa un repositorio independiente para permitir la segregación de responsabilidades. |
Flujo de proceso |
El proceso requiere que los cambios en el entorno de producción incluyan un remitente y un aprobador. |
| Operaciones en la nube | |
Tarjetas de resultados de productos de datos |
El Report Engine genera tarjetas de puntuación de productos de datos. |
Cloud Logging |
La arquitectura usa la infraestructura de registro del plano de aspectos básicos de las empresas. |
Cloud Monitoring |
La arquitectura usa la infraestructura de monitorización del plano técnico de las bases de la empresa. |
Identidad: asignación de roles a grupos
La malla de datos aprovecha la arquitectura de gestión del ciclo de vida de la identidad, autorización y autenticación de la plantilla de bases de la empresa. Los usuarios no tienen roles asignados directamente, sino que los grupos son el método principal para asignar roles y permisos en la gestión de identidades y accesos. Los roles y permisos de gestión de identidades y accesos se asignan durante la creación del proyecto a través de la canalización de la base.
La malla de datos asocia grupos con una de las cuatro áreas clave: infraestructura, gobernanza de datos, productores de datos basados en dominios y consumidores basados en dominios.
Los ámbitos de permisos de estos grupos son los siguientes:
- El ámbito de los permisos del grupo de infraestructura es la malla de datos en su conjunto.
- El ámbito de permisos de los grupos de gobierno de datos es el proyecto de gobierno de datos.
- Los permisos de productores y consumidores basados en dominios se limitan a su dominio de datos.
En las siguientes tablas se muestran los distintos roles que se usan en esta implementación de malla de datos y los permisos asociados.
Infraestructura
| Grupo | Descripción | Roles |
|---|---|---|
|
Administradores generales de la malla de datos |
|
Gobierno de datos
| Grupo | Descripción | Roles |
|---|---|---|
|
Administradores del proyecto de gobierno de datos |
|
|
Desarrolladores que crean y mantienen los componentes de gobierno de datos |
Varios roles en el proyecto de gobierno de datos, incluidos los roles de |
|
Lectores de información sobre el gobierno de datos |
|
|
Administradores de seguridad del proyecto de gobernanza |
|
|
Grupo con permiso para usar plantillas de etiquetas |
|
|
Grupo con permiso para usar plantillas de etiquetas y añadir etiquetas |
|
|
Grupo de cuentas de servicio para las notificaciones de Security Command Center |
Ninguno Se trata de un grupo de pertenencia y se crea una cuenta de servicio con este nombre, que tiene los permisos necesarios. |
Productores de datos basados en dominios
| Grupo | Descripción | Roles |
|---|---|---|
|
Administradores de un dominio de datos específico |
|
|
Desarrolladores que crean y mantienen productos de datos en un dominio de datos |
Varios roles en el proyecto de dominio de datos, incluidos los roles de |
|
Lectores de la información del dominio de datos |
|
|
Editores de entradas de Data Catalog |
Roles para editar entradas de Data Catalog |
|
Responsables de los datos del dominio de datos |
Roles para gestionar los metadatos y los aspectos del gobierno de datos |
Consumidores de datos basados en dominios
| Grupo | Descripción | Roles |
|---|---|---|
|
Administradores de un proyecto de consumidor específico |
|
|
Desarrolladores que trabajan en un proyecto de consumidor |
Varios roles en el proyecto de consumidor, incluidos los roles de |
|
Lectores de la información del proyecto del consumidor |
|
Estructura de la organización
Para diferenciar entre las operaciones de producción y los datos de producción, la arquitectura usa diferentes entornos para desarrollar y lanzar flujos de trabajo. Las operaciones de producción incluyen la gobernanza, la trazabilidad y la repetibilidad de un flujo de trabajo, así como la auditabilidad de los resultados del flujo de trabajo. Los datos de producción hacen referencia a los datos posiblemente sensibles que necesitas para gestionar tu organización. Todos los entornos están diseñados para tener controles de seguridad que te permitan ingerir y operar tus datos.
Para ayudar a los científicos e ingenieros de datos, la arquitectura incluye un entorno interactivo, donde los desarrolladores pueden trabajar directamente con el entorno y añadir servicios a través de un catálogo de soluciones seleccionadas. Los entornos operativos se gestionan mediante pipelines, que tienen una arquitectura y una configuración codificadas.
Esta arquitectura usa la estructura organizativa del plano técnico de las bases de la empresa como base para implementar cargas de trabajo de datos. En el siguiente diagrama se muestran las carpetas y los proyectos de nivel superior que se usan en la arquitectura de malla de datos de la empresa.
En la siguiente tabla se describen las carpetas y los proyectos de nivel superior que forman parte de la arquitectura.
| Carpeta | Componente | Descripción |
|---|---|---|
|
|
Contiene la canalización de implementación que se usa para crear los artefactos de código de la arquitectura. |
|
Contiene la infraestructura que usa el catálogo de servicios para desplegar recursos en el entorno interactivo. |
|
|
Contiene todos los recursos utilizados por la implementación de Google Cloud del marco de CDMC. |
|
|
|
Contiene los proyectos y los recursos de la plataforma de datos para desarrollar casos prácticos en modo interactivo. |
|
|
Contiene los proyectos y recursos de la plataforma de datos para las pruebas de los casos de uso que quieras implementar en un entorno operativo. |
|
|
Contiene los proyectos y los recursos de la plataforma de datos para la implementación en producción. |
Carpeta de plataforma de datos
La carpeta de la plataforma de datos contiene todos los componentes del plano de datos y algunos de los recursos de CDMC. Además, la carpeta de la plataforma de datos y el proyecto de gestión de datos contienen los recursos de CDMC. En el siguiente diagrama se muestran las carpetas y los proyectos que se implementan en la carpeta de la plataforma de datos.
Cada carpeta de plataforma de datos incluye una carpeta de entorno (producción, no producción y desarrollo). En la siguiente tabla se describen las carpetas de cada carpeta de plataforma de datos.
| Carpetas | Descripción |
|---|---|
Productores |
Contiene los dominios de datos. |
Consumidores |
Contiene los proyectos de consumidor. |
Dominio de datos |
Contiene los proyectos asociados a un dominio concreto. |
Carpeta de productores
Cada carpeta de productores incluye uno o varios dominios de datos. Un dominio de datos es una agrupación lógica de elementos de datos que comparten un significado, un propósito o un contexto empresarial comunes. Los dominios de datos te permiten categorizar y organizar los recursos de datos de una organización. En el siguiente diagrama se muestra la estructura de un dominio de datos. La arquitectura implementa proyectos en la carpeta de la plataforma de datos de cada entorno.
En la siguiente tabla se describen los proyectos que se implementan en la carpeta data platform de cada entorno.
| Proyecto | Descripción |
|---|---|
Ingestión |
El proyecto de ingestión ingiere datos en el dominio de datos. La arquitectura proporciona ejemplos de cómo puedes transmitir datos a BigQuery, Cloud Storage y Pub/Sub. El proyecto de ingesta también contiene ejemplos de Dataflow y Cloud Composer que puedes usar para orquestar la transformación y el movimiento de los datos ingeridos. |
No confidencial |
El proyecto no confidencial contiene datos anonimizados. Puedes enmascarar, contener, cifrar, tokenizar u ofuscar datos. Usa etiquetas de política para controlar cómo se presentan los datos. |
Confidencial |
El proyecto confidencial contiene datos sin cifrar. Puedes controlar el acceso mediante permisos de gestión de identidades y accesos. |
Carpeta de consumidor
La carpeta de consumidor contiene proyectos de consumidor. Los proyectos de consumidor proporcionan un mecanismo para segmentar a los usuarios de datos en función del límite de confianza que necesiten. Cada proyecto se asigna a un grupo de usuarios independiente y el grupo tiene acceso a los recursos de datos necesarios en función del proyecto. Puedes usar el proyecto de consumidor para recoger, analizar y aumentar los datos del grupo.
Carpeta común
La carpeta común contiene los servicios que utilizan diferentes entornos y proyectos. En esta sección se describen las funciones que se añaden a la carpeta común para habilitar la malla de datos de la empresa.
Arquitectura de CDMC
La arquitectura usa la arquitectura de CDMC para el gobierno de datos. Las funciones de gobierno de datos se encuentran en el proyecto de gobierno de datos de la carpeta común. En el siguiente diagrama se muestran los componentes de la arquitectura de CDMC. Los números del diagrama representan los controles de claves que se abordan con los servicios de Google Cloud.
En la siguiente tabla se describen los componentes de la arquitectura de CDMC que utiliza la arquitectura de malla de datos empresarial.
| Componente CDMC | ServicioGoogle Cloud | Descripción |
|---|---|---|
| Componentes de acceso y ciclo de vida | ||
Gestión de claves |
Cloud KMS |
Un servicio que gestiona de forma segura las claves de cifrado que protegen los datos sensibles. |
Gestor de registros |
Cloud Run |
Aplicación que mantiene registros completos de las actividades de tratamiento de datos, lo que permite a las organizaciones hacer un seguimiento y auditar el uso de los datos. |
Política de archivado |
BigQuery |
Una tabla de BigQuery que contiene la política de almacenamiento de datos. |
Derechos |
BigQuery |
Una tabla de BigQuery que almacena información sobre quién puede acceder a datos sensibles. Esta tabla asegura que solo los usuarios autorizados puedan acceder a datos específicos en función de sus roles y privilegios. |
| Componentes de análisis | ||
Pérdida de los datos |
Protección de datos sensibles |
Servicio usado para inspeccionar recursos en busca de datos sensibles. |
Resultados de DLP |
BigQuery |
Una tabla de BigQuery que cataloga las clasificaciones de datos en la plataforma de datos. |
Políticas |
BigQuery |
Una tabla de BigQuery que contenga prácticas de gobernanza de datos coherentes (por ejemplo, tipos de acceso a datos). |
Exportación de la facturación |
BigQuery |
Tabla que almacena información sobre los costes exportada desde Facturación de Cloud para analizar las métricas de costes asociadas a los recursos de datos. |
Cloud Data Quality Engine |
Cloud Run |
Aplicación que ejecuta comprobaciones de calidad de los datos de tablas y columnas. |
Resultados de la calidad de los datos |
BigQuery |
Tabla de BigQuery que registra las discrepancias identificadas entre las reglas de calidad de los datos definidas y la calidad real de los activos de datos. |
| Componentes de los informes | ||
Programador |
Cloud Scheduler |
Servicio que controla cuándo se ejecuta Cloud Data Quality Engine y cuándo se realiza la inspección de Protección de Datos Sensibles. |
Report Engine |
Cloud Run |
Aplicación que genera informes para ayudar a monitorizar y medir el cumplimiento de los controles del marco de CDMC. |
Resultados y recursos |
BigQuery y Pub/Sub |
Un informe de BigQuery sobre discrepancias o incoherencias en los controles de gestión de datos, como etiquetas que faltan, clasificaciones incorrectas o ubicaciones de almacenamiento no conformes. |
Exportaciones de etiquetas |
BigQuery |
Una tabla de BigQuery que contiene información de etiquetas extraída de Data Catalog. |
| Otros componentes | ||
Gestión de políticas |
Servicio de política de organización |
Un servicio que define y aplica restricciones sobre dónde se pueden almacenar los datos geográficamente. |
Políticas de acceso basadas en atributos |
Administrador de contextos de acceso |
Servicio que define y aplica políticas de acceso detalladas basadas en atributos para que solo los usuarios autorizados desde ubicaciones y dispositivos permitidos puedan acceder a información sensible. |
Metadatos |
Data Catalog |
Servicio que almacena información de metadatos sobre las tablas que se usan en la malla de datos. |
Tag Engine |
Cloud Run |
Aplicación que añade etiquetas a los datos de las tablas de BigQuery. |
Informes de CDMC |
Looker Studio |
Paneles que permiten a sus analistas ver informes generados por los motores de la arquitectura de CDMC. |
Implementación de CDMC
En la siguiente tabla se describe cómo implementa la arquitectura los controles clave del marco de CDMC.
| Requisito de control de CDMC | Implementación |
|---|---|
Report Engine detecta los recursos de datos que no cumplen las normas y publica los resultados en un tema de Pub/Sub. Estos resultados también se cargan en BigQuery para generar informes con Looker Studio. |
|
Se establece la propiedad de los datos migrados y de los generados en la nube |
Data Catalog captura automáticamente los metadatos técnicos de BigQuery. Tag Engine aplica etiquetas de metadatos empresariales, como el nombre del propietario y el nivel de sensibilidad, de una tabla de referencia, lo que ayuda a asegurar que todos los datos sensibles se etiqueten con la información del propietario para cumplir los requisitos. Este proceso de etiquetado automático ayuda a proporcionar gobierno y cumplimiento de los datos, ya que identifica y etiqueta los datos sensibles con la información del propietario correspondiente. |
La automatización rige y respalda la obtención y el consumo de datos |
Data Catalog clasifica los recursos de datos etiquetándolos con una |
Se gestionan la soberanía de los datos y la transferencia transfronteriza de datos |
El servicio de políticas de la organización define las regiones de almacenamiento permitidas para los recursos de datos, mientras que Gestor de contexto de acceso restringe el acceso en función de la ubicación del usuario. Data Catalog almacena las ubicaciones de almacenamiento aprobadas como etiquetas de metadatos. Report Engine compara estas etiquetas con la ubicación real de los recursos de datos en BigQuery y publica las discrepancias como resultados mediante Pub/Sub. Security Command Center proporciona una capa de monitorización adicional generando hallazgos de vulnerabilidades si los datos se almacenan o se accede a ellos fuera de las políticas definidas. |
Los catálogos de datos se implementan, se usan y son interoperables |
Data Catalog almacena y actualiza los metadatos técnicos de todos los recursos de datos de BigQuery, lo que crea un catálogo de datos sincronizado continuamente. Data Catalog se asegura de que las tablas y las vistas nuevas o modificadas se añadan inmediatamente al catálogo, lo que permite mantener un inventario actualizado de los recursos de datos. |
Protección de Datos Sensibles inspecciona los datos de BigQuery e identifica los tipos de información sensible. A continuación, se clasifican en función de una tabla de referencia de clasificación y se asigna el nivel de sensibilidad más alto como etiqueta en Data Catalog a nivel de columna y de tabla. Tag Engine gestiona este proceso actualizando el catálogo de datos con etiquetas de confidencialidad cada vez que se añaden nuevos recursos de datos o se modifican los que ya hay. Este proceso asegura una clasificación de los datos basada en la sensibilidad que se actualiza constantemente, que puede monitorizar y sobre la que puede generar informes mediante Pub/Sub y herramientas de informes integradas. |
|
Los derechos de datos se gestionan, se aplican y se monitorizan |
Las etiquetas de política de BigQuery controlan el acceso a los datos sensibles a nivel de columna, lo que garantiza que solo los usuarios autorizados puedan acceder a datos específicos en función de la etiqueta de política que tengan asignada. IAM gestiona el acceso general al almacén de datos, mientras que Data Catalog almacena las clasificaciones de sensibilidad. Se realizan comprobaciones periódicas para asegurarse de que todos los datos sensibles tengan las etiquetas de política correspondientes. Las discrepancias se notifican mediante Pub/Sub para que se corrijan. |
Se gestionan el acceso, el uso y los resultados éticos de los datos |
Los acuerdos de compartición de datos de proveedores y consumidores se almacenan en un almacén de datos de BigQuery específico para controlar los fines de consumo. Data Catalog etiqueta los recursos de datos con la información del contrato del proveedor, mientras que los contratos de consumidor se vinculan a las vinculaciones de gestión de identidades y accesos para controlar el acceso. Las etiquetas de consulta aplican los fines de consumo, lo que requiere que los consumidores especifiquen un fin válido al consultar datos sensibles, que se valida en función de sus derechos en BigQuery. Un registro de auditoría de BigQuery monitoriza todo el acceso a los datos y asegura el cumplimiento de los acuerdos de uso compartido de datos. |
El cifrado predeterminado de Google en reposo ayuda a proteger los datos almacenados en el disco. Cloud KMS admite claves de encriptado gestionadas por el cliente (CMEK) para mejorar la gestión de claves. BigQuery implementa el enmascaramiento dinámico de datos a nivel de columna para la desidentificación y admite la desidentificación a nivel de aplicación durante la ingestión de datos. Data Catalog almacena etiquetas de metadatos de técnicas de cifrado y desidentificación que se aplican a los recursos de datos. Las comprobaciones automatizadas aseguran que los métodos de cifrado y anonimización se ajusten a las políticas de seguridad predefinidas. Las discrepancias se notifican como resultados mediante Pub/Sub. |
|
Data Catalog etiqueta los recursos de datos sensibles con información relevante para la evaluación del impacto, como la ubicación del sujeto y los enlaces a los informes de evaluación. Tag Engine aplica estas etiquetas en función de la sensibilidad de los datos y de una tabla de políticas de BigQuery, que define los requisitos de evaluación en función de la residencia de los datos y del sujeto. Este proceso de etiquetado automatizado permite monitorizar y registrar continuamente el cumplimiento de los requisitos de la evaluación de impacto, lo que asegura que se lleven a cabo evaluaciones de impacto relativas a la protección de datos (EIPDs) o evaluaciones de impacto de la protección (EIPs) cuando sea necesario. |
|
Data Catalog etiqueta los recursos de datos con políticas de conservación, especificando los periodos de conservación y las acciones de vencimiento (como archivar o eliminar). Record Manager automatiza la aplicación de estas políticas purgando o archivando tablas de BigQuery en función de las etiquetas definidas. Esta medida asegura el cumplimiento de las políticas de ciclo de vida de los datos y de los requisitos de conservación de datos. Además, se detectan y se notifican las discrepancias mediante Pub/Sub. |
|
Cloud Data Quality Engine define y ejecuta reglas de calidad de los datos en las columnas de tabla especificadas, midiendo la calidad de los datos en función de métricas como la corrección y la integridad. Los resultados de estas comprobaciones, incluidos los porcentajes y los umbrales de éxito, se almacenan como etiquetas en Data Catalog. Almacenar estos resultados permite monitorizar y generar informes de forma continua sobre la calidad de los datos. Si se detectan problemas o desviaciones de los umbrales aceptables, se publican como resultados mediante Pub/Sub. |
|
Se han establecido y aplicado principios de gestión de costes |
Data Catalog almacena métricas relacionadas con los costes de los recursos de datos, como los costes de las consultas, los costes de almacenamiento y los costes de salida de datos, que se calculan mediante la información de facturación exportada de Facturación de Cloud a BigQuery. Almacenar métricas relacionadas con los costes permite hacer un seguimiento y un análisis exhaustivos de los costes, lo que asegura el cumplimiento de las políticas de costes y el uso eficiente de los recursos. Además, las anomalías se notifican mediante Pub/Sub. |
Las funciones de linaje de datos integradas de Data Catalog registran la procedencia y el linaje de los recursos de datos, lo que permite representar visualmente el flujo de datos. Además, las secuencias de comandos de ingestión de datos identifican y etiquetan la fuente original de los datos en Data Catalog, lo que mejora la trazabilidad de los datos hasta su origen. |
Gestión del acceso a datos
El acceso de la arquitectura a los datos se controla mediante un proceso independiente que separa el control operativo (por ejemplo, la ejecución de trabajos de Dataflow) del control de acceso a los datos. El acceso de un usuario a un Google Cloud servicio se define en función de un problema ambiental u operativo, y lo proporciona y aprueba un grupo de ingeniería de la nube. El acceso de un usuario a los recursos de datos (por ejemplo, una tabla de BigQuery) es un problema de privacidad, normativo o de gobernanza, y está sujeto a un acuerdo de acceso entre las partes productoras y consumidoras, así como controlado mediante los siguientes procesos. Google Cloud En el siguiente diagrama se muestra cómo se proporciona el acceso a los datos a través de la interacción de diferentes componentes de software.
Como se muestra en el diagrama anterior, la incorporación de accesos a datos se gestiona mediante los siguientes procesos:
- Data Catalog recoge y registra los recursos de datos en la nube.
- El gestor de flujo de trabajo recupera los recursos de datos de Data Catalog.
- Los propietarios de los datos se incorporan al gestor de flujos de trabajo.
El funcionamiento de la gestión del acceso a datos es el siguiente:
- Un consumidor de datos envía una solicitud de un recurso específico.
- Se avisa al propietario de los datos del recurso sobre la solicitud.
- El propietario de los datos aprueba o rechaza la solicitud.
- Si se aprueba la solicitud, el gestor de flujo de trabajo pasa el grupo, el recurso y la etiqueta asociada al asignador de IAM.
- El asignador de IAM traduce las etiquetas del gestor de flujo de trabajo en permisos de IAM y concede al grupo especificado permisos de IAM para el recurso de datos.
- Cuando un usuario quiere acceder al recurso de datos, IAM evalúa el acceso al Google Cloud recurso en función de los permisos del grupo.
- Si se permite, el usuario accede al recurso de datos.
Redes
El proceso de seguridad de los datos se inicia en la aplicación de origen, que puede residir on-premise o en otro entorno externo alGoogle Cloud proyecto de destino. Antes de que se produzca cualquier transferencia de red, esta aplicación usa la federación de identidades de carga de trabajo para autenticarse de forma segura en las APIs de Google Cloud. Con estas credenciales, interactúa con Cloud KMS para obtener o encapsular las claves necesarias y, a continuación, utiliza la biblioteca Tink para realizar el cifrado inicial y la desidentificación de la carga útil de datos sensibles según las plantillas predefinidas.
Una vez protegida la carga útil de datos, esta debe transferirse de forma segura al Google Cloud proyecto de ingesta. En el caso de las aplicaciones on-premise, puedes usar Cloud Interconnect o Cloud VPN. En la Google Cloud red, usa Private Service Connect para enrutar los datos hacia el punto final de ingestión de la red de VPC del proyecto de destino. Private Service Connect permite que la aplicación de origen se conecte a las APIs de Google mediante direcciones IP privadas, lo que asegura que el tráfico no se exponga a Internet.
Toda la ruta de red y los servicios de ingestión de destino (Cloud Storage, BigQuery y Pub/Sub) del proyecto de ingestión están protegidos por un perímetro de Controles de Servicio de VPC. Este perímetro aplica un límite de seguridad, lo que asegura que los datos protegidos procedentes de la fuente solo se puedan ingerir en losGoogle Cloud servicios autorizados de ese proyecto concreto.
Almacenamiento de registros
Esta arquitectura usa las funciones de Cloud Logging que proporciona el blueprint de aspectos básicos de seguridad para empresas.
Flujos de procesamiento
La arquitectura de malla de datos empresarial usa una serie de flujos de procesamiento para aprovisionar la infraestructura, la orquestación, los conjuntos de datos, los flujos de procesamiento de datos y los componentes de la aplicación. Las canalizaciones de despliegue de recursos de la arquitectura usan Terraform como herramienta de infraestructura como código (IaC) y Cloud Build como servicio de CI/CD para desplegar las configuraciones de Terraform en el entorno de la arquitectura. En el siguiente diagrama se muestra la relación entre las canalizaciones.
El flujo de procesamiento de la base y el flujo de procesamiento de la infraestructura forman parte del plano de aspectos básicos de las empresas. En la siguiente tabla se describe la finalidad de las canalizaciones y los recursos que aprovisionan.
| Flujo de procesamiento | Aprovisionado por | Recursos |
|---|---|---|
Flujo de procesamiento de Foundation |
Bootstrap |
|
Pipeline de infraestructura |
Flujo de procesamiento de Foundation |
|
Canalización del catálogo de servicios |
Pipeline de infraestructura |
|
Flujos de procesamiento de artefactos |
Pipeline de infraestructura |
Las canalizaciones de artefactos producen los distintos contenedores y otros componentes de la base de código que utiliza la malla de datos. |
Cada canalización tiene su propio conjunto de repositorios desde los que extrae código y archivos de configuración. Cada repositorio tiene una separación de tareas en la que los remitentes y las aprobaciones de las implementaciones de código operativo son responsabilidad de diferentes grupos.
Despliegue interactivo a través del catálogo de servicios
Los entornos interactivos son el entorno de desarrollo de la arquitectura y se encuentran en la carpeta de desarrollo. La interfaz principal del entorno interactivo es el catálogo de servicios, que permite a los desarrolladores usar plantillas preconfiguradas para crear instancias de servicios de Google. Estas plantillas preconfiguradas se denominan plantillas de servicio. Las plantillas de servicio te ayudan a aplicar tu postura de seguridad, como hacer que el cifrado con CMEK sea obligatorio, y también impiden que tus usuarios tengan acceso directo a las APIs de Google.
En el siguiente diagrama se muestran los componentes del entorno interactivo y cómo implementan recursos los científicos de datos.
Para desplegar recursos mediante el catálogo de servicios, se siguen estos pasos:
- El ingeniero de MLOps coloca una plantilla de recursos de Terraform para Google Cloud en un repositorio de Git.
- El comando Git Commit activa una canalización de Cloud Build.
- Cloud Build copia la plantilla y los archivos de configuración asociados en Cloud Storage.
- El ingeniero de MLOps configura manualmente las soluciones del catálogo de servicios. A continuación, el ingeniero comparte el catálogo de servicios con un proyecto de servicio en el entorno interactivo.
- El científico de datos selecciona un recurso del catálogo de servicios.
- Service Catalog implementa la plantilla en el entorno interactivo.
- El recurso extrae las secuencias de comandos de configuración necesarias.
- El científico de datos interactúa con los recursos.
Flujos de procesamiento de artefactos
El proceso de ingestión de datos usa Cloud Composer y Dataflow para orquestar el movimiento y la transformación de los datos en el dominio de datos. La canalización de artefactos crea todos los recursos necesarios para la ingestión de datos y los mueve a la ubicación adecuada para que los servicios puedan acceder a ellos. La canalización de artefactos crea los artefactos de contenedor que usa el orquestador.
Controles de seguridad
La arquitectura de malla de datos empresariales usa un modelo de seguridad de defensa en profundidad por capas que incluye Google Cloud funciones Google Cloud, servicios y funciones de seguridad predeterminados que se configuran mediante el plano técnico de las bases empresariales. En el siguiente diagrama se muestra la superposición de los distintos controles de seguridad de la arquitectura.
En la siguiente tabla se describen los controles de seguridad asociados a los recursos de cada capa.
| Layer | Recurso | Control de seguridad |
|---|---|---|
Marco de CDMC |
Implementación deGoogle Cloud CDMC |
Proporciona un marco de gobernanza que ayuda a proteger, gestionar y controlar tus recursos de datos. Para obtener más información, consulta el marco de controles clave de CDMC. |
Implementación |
Pipeline de infraestructura |
Proporciona una serie de flujos de procesamiento que despliegan infraestructura, crean contenedores y crean flujos de procesamiento de datos. El uso de las canalizaciones permite la auditabilidad, la trazabilidad y la repetibilidad. |
Flujo de procesamiento de artefactos |
Implementa varios componentes que no se implementan mediante la infraestructura de la canalización. |
|
Plantillas de Terraform |
Desarrolla la infraestructura del sistema. |
|
Open Policy Agent |
Ayuda a asegurar que la plataforma se ajusta a las políticas seleccionadas. |
|
Red |
Private Service Connect |
Proporciona protecciones contra la filtración de datos en torno a los recursos de la arquitectura en la capa de API y en la capa de IP. Te permite comunicarte con las APIs de Google Cloud mediante direcciones IP privadas para evitar exponer el tráfico a Internet. |
Red de VPC con direcciones IP privadas |
Ayuda a eliminar la exposición a amenazas orientadas a Internet. |
|
Controles de Servicio de VPC |
Ayuda a proteger los recursos sensibles contra la filtración externa de datos. |
|
Cortafuegos |
Ayuda a proteger la red de VPC frente a accesos no autorizados. |
|
Gestión de accesos |
Administrador de contextos de acceso |
Controla quién puede acceder a qué recursos y ayuda a evitar el uso no autorizado de tus recursos. |
Federación de identidades de cargas de trabajo |
Elimina la necesidad de usar credenciales externas para transferir datos a la plataforma desde entornos locales. |
|
Data Catalog |
Proporciona un índice de los recursos disponibles para los usuarios. |
|
Gestión de identidades y accesos |
Proporciona acceso pormenorizado. |
|
Cifrado |
Cloud KMS |
Te permite gestionar tus claves de cifrado y secretos, así como proteger tus datos mediante el cifrado en reposo y en tránsito. |
Secrets Manager |
Proporciona un almacén de secretos para las canalizaciones controladas por IAM. |
|
Encriptado en reposo |
De forma predeterminada, Google Cloud cifra los datos en reposo. |
|
Encriptado en tránsito |
De forma predeterminada, Google Cloud cifra los datos en tránsito. |
|
De detección |
Security Command Center |
Te ayuda a detectar fallos en las configuraciones y actividades maliciosas en tu organización de Google Cloud. |
Arquitectura continua |
Comprueba continuamente tu Google Cloud organización con una serie de políticas de OPA que hayas definido. |
|
Recomendador de IAM |
Analiza los permisos de los usuarios y ofrece sugerencias sobre cómo reducir los permisos para aplicar el principio de mínimos accesos. |
|
Firewall Insights |
Analiza las reglas de cortafuegos, identifica las que son demasiado permisivas y sugiere cortafuegos más restrictivos para reforzar tu postura de seguridad general. |
|
Cloud Logging |
Ofrece visibilidad sobre la actividad del sistema y ayuda a detectar anomalías y actividades maliciosas. |
|
Cloud Monitoring |
Monitoriza las señales y los eventos clave que pueden ayudar a identificar actividad sospechosa. |
|
Preventivo |
Política de organización |
Te permite controlar y restringir las acciones en tu organización de Google Cloud. |
Flujos de trabajo
En las siguientes secciones se describe el flujo de trabajo del productor de datos y el del consumidor de datos, lo que garantiza que se apliquen los controles de acceso adecuados en función de la sensibilidad de los datos y los roles de los usuarios.
Flujo de trabajo del productor de datos
En el siguiente diagrama se muestra cómo se protegen los datos cuando se transfieren a BigQuery.
El flujo de trabajo para la transferencia de datos es el siguiente:
- Una aplicación integrada con la federación de identidades de cargas de trabajo usa Cloud KMS para descifrar una clave de cifrado encapsulada.
- La aplicación usa la biblioteca Tink para desidentificar o cifrar los datos mediante una plantilla.
- La aplicación transfiere datos al proyecto de ingestión en Google Cloud.
- Los datos llegan a Cloud Storage, BigQuery o Pub/Sub.
- En el proyecto de ingestión, los datos se descifran o se vuelven a identificar mediante una plantilla.
- Los datos descifrados se cifran o se enmascaran en función de otra plantilla de desidentificación y, a continuación, se colocan en el proyecto no confidencial. El motor de etiquetado aplica las etiquetas según corresponda.
- Los datos del proyecto no confidencial se transfieren al proyecto confidencial y se vuelven a identificar.
Se permite el acceso a los siguientes datos:
- Los usuarios que tengan acceso al proyecto confidencial podrán acceder a todos los datos sin cifrar.
- Los usuarios que tengan acceso al proyecto no confidencial podrán acceder a los datos anonimizados, tokenizados o cifrados en función de las etiquetas asociadas a los datos y de sus permisos.
Flujo de trabajo del consumidor de datos
En los pasos que se indican a continuación se describe cómo puede acceder un consumidor a los datos almacenados en BigQuery.
- El consumidor de datos busca recursos de datos con Data Catalog.
- Una vez que el consumidor encuentra los recursos que busca, solicita acceso a ellos.
- El propietario de los datos decide si proporciona acceso a los recursos.
- Si el consumidor obtiene acceso, puede usar un cuaderno y el catálogo de soluciones para crear un entorno en el que pueda analizar y transformar los recursos de datos.
Resumen
El repositorio de GitHub te proporciona instrucciones detalladas sobre cómo implementar la malla de datos en Google Cloud después de haber implementado la base de la empresa. El proceso para implementar la arquitectura implica modificar los repositorios de infraestructura actuales e implementar nuevos componentes específicos de la malla de datos.
Haz lo siguiente:
- Cumple todos los requisitos previos, incluidos los siguientes:
- Instala Google Cloud CLI, Terraform, Tink, Java y Go.
- Implementa el plano de aspectos básicos de las empresas (v4.1).
- Mantén los siguientes repositorios locales:
gcp-data-mesh-foundationsgcp-bootstrapgcp-environmentsgcp-networksgcp-orggcp-projects
- Modifica el plano técnico de la base y, a continuación, implementa las aplicaciones de la malla de datos. En cada elemento, haz lo siguiente:
- En el repositorio de destino, extrae la rama
Plan. - Para añadir componentes de malla de datos, copia los archivos y directorios correspondientes de
gcp-data-mesh-foundationsen el directorio de base adecuado. Sobrescribe los archivos cuando sea necesario. - Actualiza las variables, los roles y la configuración de la malla de datos en los archivos de Terraform (por ejemplo,
*.tfvarsy*.tf). Define los tokens de GitHub como variables de entorno. - Realiza las operaciones de inicialización, planificación y aplicación de Terraform en cada repositorio.
- Confirma los cambios, envía el código al repositorio remoto, crea solicitudes de extracción y combínalas con los entornos de desarrollo, no producción y producción.
- En el repositorio de destino, extrae la rama
Siguientes pasos
- Consulta información sobre la arquitectura y las funciones de una malla de datos.
- Importar datos de Google Cloud a un almacén de datos de BigQuery seguro.
- Implementa el marco de controles clave de CDMC en un almacén de datos de BigQuery.
- Consulta el plan de las bases de la empresa.