Construir una malla de datos basada en eventos

Capítulo 4. Gobernanza federada

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Las arquitecturas de malla de datos están intrínsecamente descentralizadas, y se delega una gran responsabilidad en los propietarios de los productos de datos. Una malla de datos también se beneficia de cierto grado de centralización en forma de compatibilidad de productos de datos y herramientas comunes de autoservicio. Diferentes opiniones, preferencias, requisitos empresariales, limitaciones legales, tecnologías y deuda técnica son sólo algunos de los muchos factores que influyen en la forma de trabajar juntos.

La gobernanza federada nos permite separar las decisiones que deben permanecer en el ámbito local de las que deben tomarse globalmente, para todos los dominios. Citando a Dehghani, "En última instancia, las decisiones globales tienen un propósito: crear interoperabilidad y un efecto de red compuesto mediante el descubrimiento y la composición de productos de datos". Tenemos que averiguar, hacer cumplir y apoyar los bloques de construcción y modos de funcionamiento comunes para que la malla de datos funcione para todos.

Fundar un equipo de gobierno federado es uno de los primeros pasos para descubrir un terreno común en el que trabajar para encontrar soluciones mutuamente beneficiosas. Lo que hará exactamente tu equipo de gobierno variará en función de tus propias necesidades empresariales, pero hay varias tareas comunes que trataremos en este capítulo.

La gobernanza federada consiste en encontrar un equilibrio adecuado entre la autonomía individual y el control centralizado de arriba abajo, entre la delegación de responsabilidades y la creación de normas y directrices generales para la coherencia y el orden. Como cualquier forma de gobierno eficaz, necesitamos participación, representación, debate y acción colaborativa para conseguir realmente que se hagan las cosas.

Consejo

Crear un estatuto es un primer paso importante para fundar un equipo de gobierno federado. En ella se esbozan las obligaciones y responsabilidades del grupo, como el establecimiento de normas para los formatos de los productos de datos, los niveles de calidad, la interoperabilidad, la seguridad y las tecnologías compatibles. También establece las responsabilidades del productor, el consumidor y el gestor, así como otros aspectos sociales y técnicos.

La gobernanza federada se centra principalmente en varias áreas principales:

Problemas con los datos

Se refiere a cómo se crean los datos y se utilizan dentro de una organización. En concreto, tipos de productos de datos, metadatos, esquemas, soporte, descubribilidad, linaje, calidad e interoperabilidad.

Problemas tecnológicos

Incluye lenguajes de programación, marcos de trabajo y procesos de que te gustaría incorporar a tu malla de datos. Evaluar la idoneidad de tus tecnologías existentes, así como examinar nuevas opciones, sigue siendo un componente clave de la gobernanza federada.

Cuestiones legales, empresariales y de seguridad

Pertenece al cumplimiento normativo y cuestiones de seguridad, como el manejo de datos financieros, de identificación personal y otras formas de datos sensibles. También pueden influir los requisitos empresariales, como la seguridad interna de los datos, las políticas de acceso y los requisitos de conservación.

Problemas de la plataforma de autoservicio

Facilita que tus usuarios hagan lo correcto. Los usuarios necesitan una plataforma de autoservicio fiable para crear y utilizar productos de datos. Racionalizar las herramientas, reducir la fricción y facilitar que todos hagan las cosas es la base de la malla de datos. Una plataforma de autoservicio ofrece la oportunidad de aplicar políticas normativas y de seguridad en origen, proporcionando una visión de cómo fluyen los datos a través de la organización.

Cada una de estas áreas está relacionada con las demás y ofrece una lente útil a través de la cual ver las prioridades de tu equipo de gobierno. Ten en cuenta estas cuatro áreas a medida que avancemos por el resto del capítulo, porque cada sección abordará una o más de estas preocupaciones principales.

Pero primero, ¿quién gobierna?

Formar un equipo de gobierno federado

Un equipo de gobierno necesita un mandato para ser eficaz en su trabajo. Un mandato incluye dos componentes principales. El primero es un componente institucional, en el que los "superiores" respaldan la malla de datos y el equipo de gobierno, proporcionando a los miembros cierto grado de autoridad, propiedad y responsabilidad. El segundo es un componente social, en el que los que van a utilizar la malla de datos aprecian su importancia y se la creen. La ausencia de cualquiera de los dos componentes probablemente hará fracasar la iniciativa.

El equipo de gobernanza se compone de personas de toda la organización que actúan como representantes de los equipos, productos, tecnologías y procesos relacionados con la creación y el soporte de una malla de datos bien definida. Como representantes de sus compañeros, cada miembro aporta ideas, requisitos y preocupaciones de su espacio de problemas y trabaja conjuntamente para llegar a soluciones satisfactorias.

Encontrar representantes suele ser tan sencillo como pedir un voluntario que represente al equipo durante un periodo de tiempo determinado (digamos tres meses), aunque debe conocer bien los retos a los que se enfrenta el equipo. A menudo se "ofrece" (selecciona) para este papel a técnicos de alto nivel, ya que suelen conocer mejor las necesidades del equipo, el espacio del problema y los contextos históricos, como los intentos de reforma anteriores. A menudo hay razones técnicas bastante importantes por las que los intentos de reforma pasados pueden haber fracasado, y este contexto histórico suele ayudar a guiar el debate para encontrar un camino hacia una nueva resolución satisfactoria.

El tamaño del equipo de gobierno federado variará en función del tamaño de la organización, pero debe limitarse a un tamaño que permita celebrar una reunión eficaz de una hora. Con un grupo demasiado pequeño, puedes encontrarte con que careces de representación suficiente, alienando a los compañeros de equipo y dañando la confianza y el apoyo. Con un grupo demasiado grande, puede que la gente empiece a sentir que su aportación no importa realmente o que otro miembro del grupo tomará las decisiones difíciles. Encontrar el tamaño óptimo del equipo de gobierno federado depende, quizás irónicamente, del equipo de gobierno federado. Empieza con poco y no dudes en incorporar a más miembros cuando alcances los límites de representación.

Consejo

Recoge opiniones anónimas sobre cómo cree el grupo que lo está haciendo, así como opiniones de compañeros de equipo y partes interesadas ajenas al grupo. Esto ayudará al grupo a celebrar reuniones más eficaces, a encontrar los límites adecuados para las áreas de gobierno y a establecer un tamaño y unos estatutos del grupo eficaces.

Una vez que tengas un cuerpo inicial, puedes empezar a aplicar normas para agilizar la experiencia de la malla de datos.

Aplicación de las normas

El equipo de gobierno federado es responsable de elaborar un conjunto de normas tecnológicas y de productos de datos. Piensa en las tecnologías que debe soportar tu organización como en una caja de herramientas física con espacio limitado. Si quieres añadir nuevas herramientas a la caja de herramientas, tendrás que asegurarte de que hay espacio y de que no hay otras herramientas adecuadas que puedan hacer el trabajo igual de bien. Imponer un límite razonable a la caja de herramientas garantiza que la expansión tecnológica se mantenga bajo control y que sólo se añadan herramientas que ofrezcan una mejora sustancial.

Consejo

Establecer barreras de entrada para las nuevas herramientas, lenguajes, normas y tecnologías es esencial para reducir la proliferación, cercar las opciones marginales y protegerse contra las implementaciones del sabor de la semana. Si mantienes tu caja de herramientas pequeña y reducida, te resultará mucho más fácil ofrecer un soporte de primera clase para cada herramienta de tu plataforma de malla de datos de autoservicio.

Las normas deben introducirse mediante una propuesta, con una explicación detallada de por qué la nueva opción es mejor que lo que ya hay en la caja de herramientas. Una nueva opción puede cubrir un caso de uso muy necesario para el que no hay nada en la caja de herramientas. O la nueva opción puede ser categóricamente mejor que algo ya en uso. El proponente debe elaborar una historia y dar ejemplos de por qué su recomendación es buena y qué efectos tendrá en la selección de herramientas y opciones.

Es muy importante probar una norma o tecnología propuesta en antes de añadirla a tu caja de herramientas sancionadas de primera clase. Asegúrate de que el ensayo pone de relieve la importancia de la tecnología, en qué es mejor que algo que ya existe, y qué compensaciones impone dadas las herramientas y el apoyo actuales.

Advertencia

Ten cuidado de que los sistemas de prueba no pasen a producción de forma "temporal" (pero en realidad permanente). Es importante probar nuevas tecnologías y marcos de trabajo en sistemas fuera de la ruta crítica, para que puedas reescribirlos o abandonarlos sin provocar retrasos en el negocio.

Repasemos algunas de las principales normas que tu equipo de gobierno deberá establecer.

Apoyo a los tipos de productos de datos multimodales

Como ya introdujimos en "Los productos de datos son multimodales", tu equipo de gobierno federado de tendrá que decidir qué tipos de productos de datos y puertos soportas y cuáles no. Los flujos de eventos constituyen el principal tipo de producto de datos tratado en este libro, pero también puedes optar por admitir otros, como los archivos Parquet calculados por lotes en un almacén de datos en la nube, como veremos con más detalle en el Capítulo 9.

Admitir varios tipos de productos de datos proporciona opciones adicionales a los propietarios de los productos de datos, pero a costa de una complejidad significativamente mayor tanto para las herramientas de gobierno como para las de autoservicio. Es importante comprender el coste de oportunidad y la cantidad de trabajo necesario para dar soporte a cada tipo de producto de datos.

Por ejemplo, tendrás que asegurarte de que se tienen en cuenta la infoseguridad, el cifrado, los controles de acceso, la interoperabilidad de los productos de datos y las integraciones de las plataformas de datos de autoservicio. Añadir un nuevo tipo de producto de datos puede suponer un trabajo considerable, y si el rendimiento de esa inversión es marginal, puede tener más sentido simplemente servir el producto de datos utilizando en su lugar un tipo existente (aunque algo subóptimo).

Si crees que merece la pena apoyar un nuevo tipo de producto de datos, debes crear una propuesta y presentarla para su consideración en la reunión de gobernanza federada. Investigaremos más sobre las propuestas en "2. Elaboración de propuestas".

El objetivo aquí no es limitar a los propietarios de productos de datos, sino garantizar que las herramientas que se pongan a disposición sean compatibles, cumplan los requisitos de gobernanza, sean fáciles de usar y cubran los casos de uso empresarial necesarios. No añadas nuevas herramientas a la caja de herramientas en aras de la variedad o la novedad, sobre todo cuando hay formas existentes y bien respaldadas de proporcionar a acceso y uso suficientes.

Esquemas de productos de datos de apoyo

Los marcos de esquemas son, en realidad, lenguajes de programación para datos. Del mismo modo que compones una aplicación con código, compones un esquema de producto de datos con su propio código. El aspecto exacto de ese código y las mejores opciones que puedes elegir se tratan con más detalle en el Capítulo 6. Por ahora, considera cuántos y qué tipo de esquemas y formatos puedes admitir. Las dos consideraciones más comunes son:

Esquemas de eventos

Apache Avro, Protocol Buffers (Protobuf) y JSON Schema suelen ser los formatos más comunes para los eventos. Cada uno de ellos tiene sus propias ventajas y desventajas, en particular en lo que se refiere al cumplimiento de los tipos, las capacidades de evolución del esquema, los valores por defecto, las enumeraciones y la documentación.

Formatos de archivo

Los archivos por lotes escritos en un cubo de almacenamiento en la nube han seguido tradicionalmente las convenciones de los archivos de big data, como CSV, JSON, Avro, Protocol Buffers, Parquet yORC, por nombrar algunos. Además, considera las nuevas tecnologías de código abierto que se asientan sobre estos formatos de archivo básicos, como Apache Iceberg, Apache Hudi y Delta Lake. Cada una de ellas proporciona funciones de tipo sistema de archivos de nivel superior, comopartición oculta, transacciones y compactación, y puede facilitar el uso de productos de datosalojados por lotes, a costa de un acoplamiento más estrecho con latecnología.

Lo mejor es estandarizar un único marco de esquema de eventos o formato de archivo para cada tipo de producto de datos. Por ejemplo, Avro para flujos y Parquet para archivos calculados por lotes guardados en tu lago de datos. Sólo amplía la compatibilidad con otros formatos si es absolutamente esencial. Los formatos únicos simplifican enormemente las herramientas y la experiencia del consumidor, al tiempo que mantienen baja la complejidad y el riesgo.

Consejo

Si debes admitir varios formatos de archivo o esquemas de eventos, asegúrate de que los propietarios de los productos de datos puedan encontrar instrucciones fáciles de seguir sobre cuál deben utilizar y por qué. No hacerlo así introducirá fricciones cuando los equipos vecinos acaben implementando sus productos de datos con marcos de esquemas completamente distintos, dificultando el consumo y el uso para susconsumidores comunes.

A continuación, veamos algunas de las preguntas e inquietudes sobre el lenguaje de programación .

Lenguajes de programación y marcos de apoyo

Un enfoque habitual para elaborar productos de datos es utilizar un lenguaje ya en uso dentro del dominio de origen. El equipo ya estaría familiarizado con él, lo que simplifica tanto la creación como el soporte del producto de datos. Otra opción es seleccionar un lenguaje (o herramienta) que se utilice en otra parte de la organización, quizá porque sea mucho más adecuado para la creación del producto de datos. En el Capítulo 8 veremos los detalles de la creación de productos de datos basados en eventos a partir de datos existentes.

A veces, los desarrolladores utilizan la creación de productos de datos como una oportunidad para probar un nuevo lenguaje esotérico, independientemente de si cuenta con soporte oficial. Esto pone a ese desarrollador en el compromiso de todo el soporte y mantenimiento hasta bien entrado el futuro y pondrá en peligro el producto si nadie más aprende el lenguaje. Con el tiempo, es probable que el desarrollador que creó el producto de datos se traslade a nuevos proyectos u oportunidades laborales, lo que aumentará aún más el riesgo.

Es importante que sólo implementes productos de datos en lenguajes bien utilizados o que cuenten con el apoyo oficial de tu organización. Si crees que un lenguaje tiene méritos para ser utilizado más ampliamente, harías bien en crear una propuesta (véase "2. Redacción de propuestas") y discutirla con el equipo de gobierno federado.

Decidir qué lenguajes (y marcos) admitir para crear productos de datos se basa en gran medida en los mismos criterios que para crear cualquier otro servicio. Dichos factores incluyen:

Factores sociales

¿Es una tecnología conocida? ¿Nuestros desarrolladores están familiarizados con ella? ¿Hay otras personas en la industria que la utilicen, y han demostrado tener éxito con ella? ¿Querrá la gente trabajar con ella? ¿Será atractiva para las nuevas contrataciones y podemos encontrar personas con estas aptitudes en el mercado?

Factores tecnológicos

¿Resuelve nuestros problemas de forma sencilla y eficaz? ¿Es una tecnología probada que seguirá actualizándose y mejorándose durante años?

Factores de integración

¿Es fácil de mantener? ¿Se integra bien con nuestros procesos existentes de desarrollo, prueba, compilación e implementación? ¿Puedes conseguir linters, depuradores, analizadores de memoria, herramientas de prueba y otras herramientas de mejora de la productividad que se integren con él?

Clientes del corredor de eventos

¿Tiene tu corredor de eventos clientes de alto rendimiento escritos en el lenguaje que elijas? ¿Podrás producir y consumir eventos con la suficiente rapidez?

Herramientas de apoyo

¿Tu lenguaje y tu marco de trabajo funcionan bien con tus esquemas de eventos(Capítulo 6)? ¿Son compatibles con los generadores de código? ¿Puedes generar eventos de prueba para comprobar las entradas y salidas de tus productos de datos?

Decidir qué idiomas admitir, y con qué amplitud, dependerá de tu organización y de tu equipo de gobierno. Elige idiomas con los que tu organización esté familiarizada y que admita corredores de eventos.

Normas y requisitos de los metadatos

Una buena malla de datos requiere metadatos bien definidos para cada producto de datos. Los usuarios de la malla de datos deben poder descubrir e identificar en los productos de datos que necesitan para sus casos de uso empresarial. El propietario de un producto de datos debe proporcionar todos los metadatos necesarios durante el registro del producto de datos para que se le permita publicarlo en la malla. Hacer cumplir los requisitos de metadatos es esencial para garantizar que sólo se pongan a disposición de los demás productos de datos bien definidos y respaldados, no sea que repitamos los errores de anteriores estrategias de datos, como se expone en "Malos datos: Los costes de la inacción".

Hay varios campos que son esenciales para una malla de datos saludable. En esta sección, cubriremos cada uno de ellos y te proporcionaremos algunos ejemplos básicos para que tu propio equipo de gobierno los tenga en cuenta.

Dominio y propietario

En primer lugar está la propiedad. ¿A quién pertenece el producto de datos? ¿Y de dónde procede? Estos metadatos incluyen el espacio de nombres del dominio y el nombre del propietario del producto de datos. El nombre del propietario del producto de datos es una persona individual, que representa el producto de datos de ese dominio.

Niveles de servicio escalonados

Un producto de datos requiere soporte y garantías de tiempo de actividad. Pero, ¿hasta qué punto? Si el producto de datos sufre un fallo, ¿qué es el curso de acción adecuado? Muchas empresas ya organizan sus aplicaciones en un sistema escalonado, en el que el nivel más alto tiene turnos de guardia de 24 horas y el nivel más bajo tiene un simple soporte de mejor esfuerzo. Deberías aplicar el mismo sistema de niveles a los productos de datos y ofrecer la misma asistencia y garantías que ofrecerías a cualquier otro servicio o producto del mismo nivel. El siguiente es un ejemplo de un sistema de cuatro niveles:

Nivel 1

Productos de datos que son críticos para el funcionamiento de tu empresa, donde una interrupción o fallo tendrá un impacto significativo en el cliente o en las finanzas de la empresa. Los productos de datos que alimentan aplicaciones operativas en tiempo real suelen entrar en esta categoría.

Nivel 2

Productos de datos que son importantes para el negocio, pero menos críticos que el Nivel 1. Un fallo en este nivel puede degradar la experiencia del cliente, pero no impide por completo que los clientes interactúen con tu sistema. Los productos de datos de este nivel también suelen alimentar aplicaciones operativas en tiempo real.

Nivel 3

Productos de datos que pueden afectar a tareas y operaciones de fondo en la empresa, pero que probablemente no sean visibles para los consumidores ni les afecten significativamente. Sin embargo, un fallo en este nivel puede requerir una intervención si el producto de datos alimenta casos de uso sensibles al tiempo.

Nivel 4

Productos de datos que tienen el mayor margen de tiempo para su recuperación. No es imprescindible tener una rotación de guardia para dar soporte a estos productos de datos; pueden esperar hasta el siguiente día laborable para resolverse.

El tiempo de actividad y la disponibilidad no son las únicas consideraciones del nivel de servicio de un producto de datos. También tendrás que monitorizar tus productos de datos para asegurarte de que cumplen sus SLA, algo que trataremos con un poco más de profundidad en "Monitorización y alertas".

Clasificaciones de la calidad de los datos

La calidad de los datos proporcionados por el producto de datos también debe clasificarse, de forma similar al enfoque del sistema de niveles de SLA. Una opción es aprovechar las clasificaciones de medallón de bronce, plata y oro que se utilizan habitualmente en las arquitecturas de los lagos de datos. Veamos cada clasificación:

Bronce

Datos no estructurados y sin procesar que no se han transformado a partir del formato de la fuente original. Pueden estar fuertemente acoplados al modelo de datos interno del sistema fuente, y también pueden contener campos que necesiten ser saneados o depurados. También pueden incluir datos bien estructurados y definidos, pero cuya calidad es intermitente o los propietarios de los datos simplemente no pueden ofrecer una garantía superior.

Plata

Datos bien estructurados con una fuerte tipificación y normalmente saneados y normalizados. Suelen estar desnormalizados para que sean lo suficientemente útiles tal cual, habiéndose unido y resuelto las relaciones de clave ajena más comunes para facilitar su uso a los consumidores. Se han aplicado comprobaciones de tipo y restricciones para garantizar una calidad mínima de los datos (por ejemplo, el 99,99% de los sucesos superan las comprobaciones de calidad). El contexto del evento está claramente definido y documentado, al igual que las comprobaciones de tipo y las restricciones. Si un consumidor desea imponer sus propias restricciones, más estrictas, a los datos, lo mejor sería que se comunicara con el propietario del producto de datos para evaluar las opciones.

Oro

El más alto nivel de calidad. A menudo se refiere a los productos de datos con el nivel de calidad oro como "fidedignos", para que se pueda confiar en ellos sin reservas. Los productos de datos se comprueban y monitorean rigurosamente, con comprobaciones de tipo y restricciones que superan las del nivel de calidad plata (por ejemplo, el 99,9999% de los eventos superan las comprobaciones de calidad). Los productos de datos oro suelen ser más complejos, construidos mediante agregaciones y transformaciones significativas que ofrecen un valor importante, y que serían bastante difíciles de reproducir por los consumidores por sí mismos.

Nota

La clasificación de la calidad de los datos es independiente de las alineaciones de los productos de datos (alineados con la fuente, alineados con el agregado y alineados con el consumidor), y sólo se ocupa de la calidad de los datos.

Eres libre de seleccionar los modelos de clasificación alternativos que creas convenientes. Lo importante es que los usuarios de tu malla de datos puedan comprender y aplicar fácilmente el modelado a sus propios productos de datos, preservando un entendimiento común entre productores y consumidores de datos.

Privacidad, finanzas y etiquetado personalizado

Junto con los representantes de seguridad y financieros de la información, el equipo de gobernanza puede idear etiquetas para aplicar a los productos de datos y ayudar a automatizar el tratamiento especializado. Por ejemplo, puedes optar por incluir un sistema escalonado de clasificaciones de seguridad similar al de los SLA. También puedes optar por utilizar etiquetas que pertenezcan al tipo de datos incluidos en el flujo de eventos, como etiquetas financieras, PII o basadas en la región.

Admitir etiquetas en los productos de datos facilita la aplicación de normas de gobernanza, ya que pueden aplicarse en función de cada etiqueta. Por ejemplo, un consumidor que quiera utilizar un producto de datos con una etiqueta financiera tendrá que demostrar que cumple los requisitos de tratamiento de datos financieros de su organización. Las etiquetas también facilitan la auditoría del uso de los datos por consumidor.

Dependencias de metadatos ascendentes

Los servicios y productos de datos ascendentes tienen cada uno sus propios SLA, niveles de calidad de los datos y otras garantías. Cualquier servicio o producto de datos que dependa de servicios o productos de datos ascendentes debe tener en cuenta estas dependencias al especificar sus propias garantías. Por ejemplo, un servicio no puede ofrecer soporte de Nivel 1 cuando depende de productos de datos con garantías de Nivel 4. Más adelante en este capítulo, en "Linaje de productos de datos", hablaremos más sobre el linaje .

Como parte de tus requisitos de gobernanza, puedes optar por establecer unos requisitos mínimos previos de calidad de datos y SLA para alimentar tus aplicaciones de producción, ya sean operativas, analíticas, de servicios o de productos de datos. Una convención común es permitir sólo servicios que tengan garantías de SLA de nivel 1 o 2 en producción.

Los requisitos de calidad de los datos ascendentes no son tan estrictos: es totalmente posible que puedas alimentar un producto de datos de nivel 1 oro con un producto de datos de nivel 1 bronce. De hecho, así es como suelen transformarse los datos de nivel bronce en un producto de datos de nivel oro de alta calidad.

Puedes aplicar comprobaciones previas durante la creación de un producto de datos, como veremos en el Capítulo 5.

Ejemplo de recapitulación de metadatos

La Figura 4-1 muestra un ejemplo de lo que puede ver un usuario al buscar información sobre un producto de datos. Aunque vamos a explorar más a fondo la catalogación de metadatos en el Capítulo 5, de momento puedes pensar en ella como una base de datos de sólo lectura en la que puedes consultar los productos de datos disponibles y sus propiedades.

El nombre del producto de datos, el dominio y el usuario son piezas obligatorias de metadatos creadas en el momento de la publicación. También se incluye un campo de descripción para describir el contexto y desambiguar el producto de datos de otros similares. También hay metadatos sobre el servicio, la calidad y los niveles de seguridad, así como etiquetas que describen la información de identificación personal, financiera y regional.

Figura 4-1. Un ejemplo de metadatos de productos de datos que puedes esperar ver como usuario de la malla de datos

El campo de esquema de los metadatos se extrae del registro de esquemas, que es un componente que almacena y gestiona esquemas para flujos de eventos y es una pieza esencial de la plataforma de datos de autoservicio. Trataremos esto con más detalle en "El Registro de Esquemas". El nombre del intermediario y el nombre del tema también se obtienen para proporcionar la dirección digital del producto de datos.

Los metadatos nos ayudan a tomar decisiones informadas sobre qué productos de datos están disponibles para nuestros casos de uso. La compatibilidad entre productos de datos es esencial para permitirnos fusionar datos de distintas fuentes y es el tema de la siguiente sección.

Garantizar la compatibilidade interoperabilidad de los productos de datos entre dominios

Hay muchos factores que conforman agregando, fusionando y comparando productos de datos entre dominios. Como parte de las preocupaciones sobre los datos expuestas al principio de este capítulo, la interoperabilidad y la facilidad de uso siguen siendo dos de las principales preocupaciones de la gobernanza federada. Las normas y directrices sobre entidades comunes, zonas horarias, límites de agregación y los detalles técnicos de los mapeos de eventos, las particiones y los tamaños de los flujos son competencia del equipo de gobierno. Echemos ahora un vistazo a estas áreas.

Definir y utilizar entidades comunes

Uno de los primeros pasos importantes es definir en las entidades mínimas que se utilizan en muchas áreas de tu empresa. Veamos primero un ejemplo.

Una empresa de comercio electrónico define una entidad común Item que contiene dos campos: long id y long upc_code. Se espera que los propietarios de los productos de datos utilicen la entidad Item en cualquier producto de datos que haga referencia a sus artículos de comercio electrónico, ya sea Order, Inventory entrada o Return. Cada una de estas entidades relacionadas utiliza una versión común y normalizada de Item, lo que elimina la necesidad de que los consumidores interpreten representaciones similares pero diferentes de los mismos datos.

Las entidades comunes no te impiden añadir más información sobre esa entidad a tu producto de datos. Eres libre de ampliar tus productos de datos para incluir otra información sobre Item, como size y color en el caso de un artículo de ropa o weight y serving_size en el caso de un artículo de comida. Piensa en una entidad común como un punto de unión entre productos de datos de otros dominios y como una base ampliable para el modelo de datos de la entidad.

Partición y codificación de flujos de eventos

La interoperabilidad de los productos de datos de flujo de eventos se ve afectada por el recuento de particiones del flujo, la clave del evento y el algoritmo de asignación de particiones (ver Capítulo 3). Un flujo de eventos contiene una o más particiones, y cada evento se asigna a una partición en función del algoritmo de asignación de particiones, la clave del evento y el número de particiones. Aquí tienes algunos consejos útiles sobre interoperabilidad:

Recuento de particiones

Unir y agregar datos productos de múltiples flujos puede hacerse mucho menos intensivo computacionalmente si los recuentos de particiones de eventos son del mismo tamaño. Aunque los procesadores de flujos de eventos como Kafka Streams y Flink pueden reparticionar automáticamente los flujos de eventos según sea necesario, esto requiere más potencia de procesamiento y puede suponer mayores costes. Intenta utilizar un enfoque de dimensionamiento de camisetas para estandarizar los recuentos de particiones, como x-small=1, small=4, medium=8, large=16, x-large=32, xx-large=64, jumbo=256. Como parte de tu plataforma de autoservicio (que trataremos en el próximo capítulo), puedes proporcionar a los usuarios de la malla de datos instrucciones para elegir el recuento de particiones en función del espacio clave, el volumen de eventos y las necesidades de reprocesamiento del consumidor.

Consejo

Si vas a crear un producto de datos basado en una entidad común, comprueba el recuento de particiones de otros productos de datos basados también en esaentidad: si todos utilizan el mismo recuento de particiones, harías bien en utilizarlo tú también.

Clave del evento

La clave del evento se sirve mejor de utilizando un valor primitivo, como string, int o long. El ID único de la entidad común es su mejor opción para la interoperabilidad.

Algoritmo de asignación de particiones

Este algoritmo toma la clave del evento como entrada y devuelve el ID de la partición en la que escribir el evento. Los clientes productores de eventos de diferentes lenguajes de programación y marcos de trabajo pueden utilizar algoritmos incompatibles, lo que da lugar a flujos de eventos que no son compatibles entre sí, a pesar de utilizar la misma clave de evento y el mismo recuento de particiones. Aunque utilizar un único marco como Kafka Streams garantizará que la asignación de particiones sea coherente, tendrás que investigar un poco para evaluar otros marcos como parte de tu plataforma de autoservicio.

Advertencia

Ten cuidado con las particiones calientes, en las que se asigna un número desproporcionado de eventos a una sola partición. Por ejemplo, el 99% de todos los eventos pueden asignarse a una sola partición, mientras que las particiones restantes sólo reciben el 1% de los datos. Aunque esto suele deberse a un espacio de claves extremadamente estrecho, también puede deberse a un algoritmo de asignación de particiones inadecuado.

Es importante pensar en la creación de claves y particiones para la compatibilidad desde el principio, ya que muchos de los productos de datos que crees permanecerán durante un tiempo. Cambiar las particiones es posible, pero a menudo requiere reescribir los datos en un nuevo flujo de eventos y migrar los consumidores. Limítate a utilizar tamaños de camisetas, elabora algunas recomendaciones para seleccionar los recuentos de particiones en función de las necesidades de los consumidores (por ejemplo, reprocesamiento, paralelización), y define un algoritmo común de asignación de particiones basado en tus marcos de clientes disponibles en .

Hora y husos horarios

Los productos de datos pueden estar asociados a una ventana o periodo de tiempo de . Por ejemplo, un producto de datos alineado con una agregación puede representar datos de un periodo de tiempo, como una agregación horaria o diaria. Como parte de una norma para garantizar la interoperabilidad, establece una zona horaria primaria, como UTC-0, para todos los productos de datos basados en el tiempo. Los consumidores tendrán una experiencia mucho más sencilla combinando distintos productos de datos basados en la hora si no tienen que lidiar con la conversión de husos horarios y el horario de verano.

Consejo

Cuando proceda, debes incluir el periodo de agregación y la información relacionada con la zona horaria como parte de los metadatos del producto de datos. Esta información ayudará a tus consumidores a decidir qué procesamiento adicional, en su caso, deben realizar para fusionarlo con sus otros productos de datos.

Ahora que hemos cubierto las formas de proporcionar compatibilidad con el producto de datos , es hora de adentrarnos un poco más en el aspecto social. ¿Cómo tomamos decisiones eficaces sobre las normas y requisitos de nuestra malla de datos?

¿Cómo es una reunión de gobernanza?

Cubrir la totalidad de una reunión eficaz va más allá del alcance de este libro, pero hay algunas indicaciones que deberían ayudarte a empezar. En primer lugar, asegúrate de que sigues las buenas prácticas comunes a todas las reuniones técnicas. En segundo lugar, envía una invitación con suficiente antelación y proporciona un orden del día para la reunión. En tercer lugar, asegúrate de que tienes un presidente y alguien que tome notas y registre las acciones, y asegúrate de que todo el mundo sabe lo que hay que hacer para la siguiente reunión. Es habitual rotar las responsabilidades y los deberes para garantizar una representación equitativa.

Es muy importante reunir en la misma sala de reuniones a las personas que trabajan en sistemas operativos con las que trabajan en sistemas analíticos. Quizá te sorprenda, o simplemente te decepcione, lo poco que esto ocurre. El aislamiento de los "equipos de datos" de los "equipos de ingeniería" lleva mucho tiempo asolando el espacio informático, como ya comentamos en "Malos datos: Los costes de la inacción".

Advertencia

Como en cualquier reunión, las personas con una personalidad fuerte o una voz alta pueden intentar dominar la conversación. Asegúrate de que haya un presidente que dirija la reunión y que todos tengan la oportunidad de hablar sin interrupciones. Si la reunión se caldea y empieza a ser improductiva, haz un receso de 5 minutos o levanta la sesión.

Debes esperar reunirte con frecuencia durante las fases iniciales de la transformación de tu malla de datos. Tendrás muchas cosas que discutir, resolver, apoyar y normalizar. A medida que pase el tiempo, puedes esperar reunirte con menos frecuencia.

Pero, ¿cuáles son las principales tareas en las que debe centrarse el equipo de gobierno? Repasemos cinco áreas principales y discutamos su relación con la malla de datos.

1. Identificar los problemas existentes

La primera tarea del equipo de gobernanza es identificar dónde están los problemas. Tu equipo debe estar compuesto por personas de toda la organización con una buena visión del panorama tecnológico y de los datos. Un enfoque de base, de abajo arriba, para informar de los problemas y cuestiones suele funcionar mejor. Pide a tus colegas que identifiquen las áreas en las que tienen problemas, las barreras y obstrucciones a las que se enfrentan, y qué es lo que les gustaría poder hacer, ya sea en términos de requisitos empresariales o de simplificación de la complejidad operativa.

Consejo

Pide a todos que hagan una lista de sus principales problemas y cuestiones utilizando tarjetas o notas adhesivas. A continuación, puedes agrupar los problemas similares, de modo que puedas encontrar las áreas de mejora que pueden tener un mayor impacto.

Identificar los problemas es el primer paso para mejorar la malla de datos para todos. Los problemas más comunes pueden ser la falta de herramientas de autoservicio, la incoherencia de los datos en los productos existentes y la falta de políticas relativas a la duplicidad de datos, la infoseguridad, la PII y la información financiera. Una vez identificados los problemas, puedes priorizar cuáles son los más importantes y dedicar recursos a resolverlos.

2. Redacción de propuestas

El siguiente paso es crear una propuesta que enmarque el problema, explique por qué es importante resolverlo, articule los retos y las oportunidades e identifique una posible solución. Una propuesta es muy parecida a un proyecto de ley tal y como se presenta en las cámaras, senados y parlamentos de muchos sistemas democráticos. Propone cambios, proporciona detalles y especifica el alcance, todo ello empaquetado en una única unidad debatible.

No sólo el equipo de gobierno puede crear propuestas para su revisión: cualquier persona de la organización puede crear una. De hecho, obtendrás los mejores resultados si te pones en contacto con las personas que han identificado los problemas: normalmente tienen alguna idea sobre cómo mejorar las cosas y sólo necesitan que alguien organice y promueva el trabajo necesario. Las propuestas deben centrarse en resolver problemas específicamente identificados que tengan un impacto en el mundo real para los usuarios de la malla de datos.

Algunos ejemplos de propuestas podrían ser

• Introducir la encriptación a nivel de campo para restringir el acceso a cierta información sensible en un producto de datos

• Implementar normativas para manejar productos de datos que abarquen múltiples implementaciones en la nube.

• Añade etiquetas personalizadas a los metadatos de los productos de datos para mejorar la funcionalidad de búsqueda

• Añade namespacing a los productos de datos para permitir el acceso de seguridad a nivel de espacio de nombres

• Introducir un servicio centralizado de autenticación y autorización para unificar la gestión de identidades de cada servicio en la nube en la plataforma de autoservicio.

Aunque las propuestas pueden abarcar un amplio abanico de preocupaciones, la mayoría de las veces deben conducir a una mejora de las herramientas y plataformas de autoservicio a disposición de los usuarios de la malla de datos. Exigir un nuevo proceso está muy bien, pero si no se incorpora a las herramientas y servicios que los usuarios de la malla de datos utilizan a diario, es muy probable que no se siga ni se utilice.

Consejo

Las propuestas deben ilustrar cómo sería una resolución satisfactoria del problema. Prototipar una solución para mostrar con precisión cómo funcionará mantiene las ideas ancladas en el ámbito práctico y no en el teórico. Idea experimentos, realiza pruebas, asigna investigaciones, investiga opciones y crea prototipos de soluciones tecnológicas antes de lanzarlas para uso general.

3. Revisión de las propuestas

El equipo de gobierno federado revisa las propuestas para determinar la viabilidad de la solución y los recursos de implantación necesarios. La forma de revisar estas propuestas variará de un equipo a otro, sobre todo si se tienen en cuenta el trabajo a distancia, las zonas horarias y otros factores de distribución. Una opción que funciona bien es hacer que los miembros del equipo de gobierno federado revisen individualmente las propuestas, tomando notas o marcando cualquier duda, antes de reunirse en un grupo más grande. Si puedes reunir a todos en una sala, digital o física, te resultará más fácil hacer preguntas, debatir las opciones y llegar a un plan unificado. También podríais reuniros de forma asíncrona, y decidir juntaros sólo si hay suficiente desacuerdo o confusión.

Consejo

Mantén las revisiones abiertas e inclusivas. Invita a personas de toda tu organización que creas que pueden ayudar aportando contexto e información adicionales. Puede que tengas que buscarlas e invitarlas explícitamente, ya que la mayoría de la gente suele estar bastante ocupada. Asegúrate de no confiar en las mismas personas para revisar cada propuesta, no sea que des la idea de que nadie más es bienvenido para contribuir a la gobernanza federada.

El objetivo principal de la revisión debe ser validar la solución propuesta, examinar cualquier prototipo, identificar cualquier consideración que se haya pasado por alto y evaluar los límites del trabajo implicado. La revisión puede dar lugar a que se rechace la propuesta, ya sea devolviéndola al creador para que realice trabajo adicional o rechazándola de plano debido a otros problemas insalvables. Una revisión aceptada requerirá un último paso: planificar y ejecutar el trabajo de implementación.

4. Ejecución de las propuestas

A continuación, una propuesta aceptada debe convertirse en elementos de trabajo detallados. Divide la propuesta en pasos incrementales para construir, probar, implementar y validar tus cambios en la malla de datos. Utiliza tu sistema actual de fichas de trabajo para detallar cada elemento de trabajo, incluyendo una descripción del trabajo a realizar, cómo debe ser el éxito y una estimación de cuánto tiempo y esfuerzo llevará completarlo.

Consejo

Implementar una propuesta es idéntico al proceso de implementación de características de cualquier otro producto. Aunque puedas evitar tener un gestor de producto de plataforma de datos de autoservicio al principio de tu viaje por la malla de datos, llegarás a descubrir que es un papel esencial para hacer las cosas.

¡También vas a necesitar que alguien haga el trabajo! Dependiendo de tu organización, es posible que hayas optado por asignar a una o varias personas la implementación de las entradas de la plataforma de malla de datos. Alternativamente, puedes solicitar que el creador de la propuesta proporcione las horas-persona para realizar el trabajo, dado que es probable que sean los más familiarizados con la solución.

Elijas lo que elijas para poner en práctica el trabajo, céntrate en conseguir mejoras iterativas en un plazo de tiempo razonable. Como cualquier otro producto, tu malla de datos debe ayudar a tus colegas a resolver sus problemas de acceso, uso y publicación de datos. Si no consigues generar confianza en tu plataforma de malla de datos, la gente simplemente no la utilizará y recurrirá en su lugar a sus propios mecanismos ad hoc de acceso a los datos. En este caso, tu malla de datos no será más que una pérdida de tiempo.

5. Archivar propuestas

Guarda todas tus propuestas aceptadas y rechazadas, junto con las notas (o vídeos grabados) sobre su discusión en un lugar de acceso común, como una unidad de archivos en la nube. La gente debe poder consultar las propuestas para ver su estado, así como cuáles han sido aceptadas o rechazadas, y por qué. La transparencia es esencial porque deja constancia de por qué seadoptó o no una tecnología o una decisión.

Las propuestas archivadas también eliminan cierta complejidad operativa. Puedes buscar en las propuestas existentes para ver si ya se ha propuesto algo similar antes y, en caso afirmativo, cuáles fueron los resultados. Es posible que los motivos originales para no adoptar algo ya no sean válidos, por lo que merece la pena volver a plantearlo con una nueva propuesta.

En la siguiente sección, echaremos un vistazo a los controles de seguridad y acceso. Ambos son esenciales para establecer un marco fiable de propiedad y seguridad y también para protegerse del acceso no autorizado a y de la modificación accidental de los productos de datos de cada uno.

Políticas de acceso y seguridad de datos

Las prácticas de seguridad y acceso de tu malla de datos dependen en gran medida de los requisitos legales y empresariales de tu negocio. Por ejemplo, un banco tendrá unos requisitos de seguridad y control de acceso mucho más estrictos que un sitio web de un tablón de anuncios anónimo. Como éste es un campo de estudio muy amplio, vamos a suponer que sigues "buenas prácticas de seguridad", y en su lugar nos centraremos en unos cuantos conceptos y técnicas importantes, específicos para crear y utilizar productos de datos basados en eventos.

Consejo

La defensa en profundidad debe ser tu principio rector en cuando te ocupes de la seguridad y los controles de acceso. No hay una sola cosa que mantenga tus datos a salvo de un uso no autorizado, ya sea de un colega bienintencionado pero no autorizado o de un intruso externo. La limitación del acceso por defecto, la autenticación obligatoria de usuarios y servicios, y la protección y encriptación de la información privada, financiera y otra información sensible ayudan a reducir el radio de explosión y a mitigar las consecuencias.

La gestión de identidades es un componente fundamental de la seguridad de los datos, ya que todos los permisos de usuarios y servicios estarán vinculados a ella. Trataremos este tema con más detalle en el próximo capítulo, en "Identidades de servicio y de usuario". Por ahora, investiguemos algunos de los principios de seguridad más importantes que tu equipo de gobierno puede decidir implantar y apoyar en tu malla de datos.

Desactivar el acceso a productos de datos por defecto

Los productos de datos sólo deben estar disponibles para su uso en por consumidores registrados. Si no estás registrado como consumidor del producto de datos, no puedes leerlo. Aunque este principio introduce un obstáculo, en comparación con permitir que un producto de datos sea de sólo lectura para cualquiera que lo desee, obliga a los usuarios y servicios a registrarse como consumidores explícitos. Necesitamos saber quién lee qué, para que los cambios y las solicitudes puedan comunicarse eficazmente tanto en sentido ascendente como descendente.

Considera la encriptación de extremo a extremo

Dependiendo de los requisitos de infoseguridad, es posible que necesites encriptar los datos de tu producto antes de publicarlos en el corredor de eventos. Los datos permanecen encriptados en el corredor de eventos, impidiendo cualquier acceso no autorizado por la puerta trasera a los datos en disco. Un consumidor registrado con las claves de descifrado asignadas puede consumir y descifrar los datos localmente para su propio uso.

Consejo

Agilizar el cifrado y descifrado de datos es una función de la plataforma de autoservicio. Sin embargo, corresponde al equipo de gobierno determinar los requisitos y los casos de uso admitidos.

La encriptación de extremo a extremo suele ser necesaria para manejar datos sensibles. Cifrar los datos en el lado del productor proporciona seguridad adicional durante las comunicaciones de redy el almacenamiento de datos del evento, y garantiza que el proveedor en la nube del corredor de eventosno pueda leerde algún modo (o filtrar) los datos no cifrados. Además, el cifrado de extremo a extremo actúa como defensa en profundidad: es posible que alguien pueda acceder a leer los datos de tu evento, pero sin las claves de descifrado, no podrá descifrar y utilizar los datos originales.

La Figura 4-2 muestra a un productor y a un cliente consumidor que utilizan la encriptación de extremo a extremo. El productor ha cifrado los datos antes de escribirlos en el flujo de eventos y ha publicado la clave en un servicio de gestión de claves (KMS). Un consumidor que quiera leer el producto de datos debe obtener acceso a las claves de descifrado del KMS y luego aplicarlas a cada evento leído del flujo.

Figura 4-2. Encriptación de extremo a extremo en un producto de datos servido como flujo de eventos

Un KMS te proporciona un mecanismo para crear, compartir, almacenar y rotar tus claves de forma segura. Aunque puedes empezar sin ningún soporte formal de plataforma de datos de autoservicio, lo más probable es que tengas que invertir en agilizar este proceso si acabas utilizando mucho cifrado.

Puede que no siempre necesites encriptar todo el evento ; a veces encriptar sólo los campos sensibles es más que suficiente. Echemos un vistazo.

Cifrado a nivel de campo

La encriptación a nivel de campo ofrece la posibilidad de que el propietario de un producto de datos encripte campos específicos, de modo que sólo los consumidores seleccionados puedan acceder a los datos. La información financiera, de cuentas y de identificación personal son casos de uso común para la encriptación a nivel de campo. Por ejemplo, al modelar una transferencia bancaria, puedes utilizar el cifrado a nivel de campo en los campos user y account, pero dejar sin cifrar los campos amount y datetime. Los consumidores con permisos de descifrado pueden acceder a la información descifrada para liquidar los saldos de las cuentas, mientras que un sistema analítico sin permisos de descifrado puede seguir haciendo un seguimiento de cuánto dinero se mueve durante un periodo de tiempo, todo ello a partir del mismo producto de datos. La Tabla 4-1 muestra la encriptación de los campos email, user, y account de un evento.

Tabla 4-1. Utilizar la encriptación a nivel de campo para encriptar parcialmente un suceso

Nombre del campo	Evento original	Evento parcialmente encriptado
correo electrónico	[e-mail]	n2Zl@p987NhB4.L0P
usuario	abellemare	9ajkpZp2kH
cuenta	VD8675309	0PlwW81Mx
importe	$777.77	$777.77
fecha-hora	2022-02-22:22:22:22	2022-02-22:22:22:22

También puedes optar por utilizar la encriptación de preservación de formato para mantener el formato de los datos del evento. En este caso, utilizamos la encriptación de preservación de formato para los campos email, user, y account -los mismos caracteres alfanuméricos, espaciado y recuento de caracteres de los campos originales, pero sin exponer ninguna de las IIP a usuarios sin permisos de desencriptación.

Consejo

Una de las ventajas de utilizar el cifrado a nivel de campo es que permite controles de acceso más precisos para los consumidores. Tus consumidores pueden solicitar claves de descifrado sólo para los datos que necesitan, en lugar de para toda la carga útil, lo que reduce la posibilidad de que se filtre información inadvertidamente.

El cifrado que preserva el formato es especialmente útil para aplicar el cifrado a los datos a posteriori, porque no necesitas renegociar los esquemas con los consumidores posteriores. Por el contrario, utilizar una encriptación que no preserve el formato suele dar lugar a malformaciones, como convertir un identificador de cuenta bancaria long en un string de 64 caracteres o encriptar un objeto anidado complejo en una matriz de bytes con hash.

La encriptación de datos sensibles, ya sea de extremo a extremo o a nivel de campo, también puede ayudarnos con otro requisito importante de gobernanza: el derecho a ser olvidado y a que se eliminen nuestros datos.

Privacidad de datos, derecho al olvido y criptodestrucción

El Reglamento General de Protección de Datos (RGPD) es (entre otras cosas) una ley que exige el tratamiento, almacenamiento y eliminación cuidadosos de los datos. Es un excelente ejemplo de una restricción legal a la que tu organización puede tener que adherirse para mantenerse en el lado correcto de la ley. Y si pretendes crear una malla de productos de datos útiles, es muy probable que acabes tratando con información personal, de cuentas y financiera que puede requerir que tomes medidas y precauciones adicionales para protegerla.

El artículo 17 del GDPR exige que las personas tengan la posibilidad de solicitar que se eliminen todos sus datos personales, sin demoras indebidas. A primera vista, esta estipulación puede parecer directamente opuesta a los principios de una malla de datos: publicar productos de datos bien definidos para que otros equipos y servicios los utilicen como consideren oportuno. Los productos de datos basados en eventos pueden parecer que agravan aún más el problema, ya que los consumidores leen los datos en sus propios almacenes y cachés de datos locales.

La criptodestrucción es una técnica que puedes utilizar para garantizar que los datos queden inutilizables sobrescribiendo o borrando las claves de encriptación. En pocas palabras, permites al usuario final el control total sobre cuándo quiere borrar sus claves, haciendo que sus datos queden criptográficamente inutilizables una vez borradas las claves. Puedes utilizar la criptodestrucción con cualquier forma de encriptación, incluida la de extremo a extremo y la de nivel de campo.

Mientras tanto, los consumidores de los productos de datos encriptados simplemente se ponen en contacto con el KMS central y solicitan acceso a las claves de desencriptación. Siempre que el consumidor tenga los permisos correctos, se le devuelven las claves de descifrado y puede descifrar y procesar los datos según sus necesidades.

¿Por qué hacerlo así? ¿No podemos simplemente clasificar los datos en el producto de datos y eliminarlos directamente? ¿No sería mucho más seguro?

Borrar los datos del producto sigue siendo una opción razonable; sin embargo, hay varias complicaciones que hacen que la encriptación y la criptodestrucción sean unaconsideración importante:

Grandes cantidades de datos

Grandes cantidades de datos pueden estar almacenados en copias de seguridad, unidades de cinta, almacenamiento en la nube fría y otros medios caros y lentos de acceder. Puede resultar muy caro y llevar mucho tiempo leer todos los datos históricos, eliminar registros selectivamente y volver a escribirlos en el almacenamiento. La criptodestrucción te permite evitar tener que buscar en todos y cada uno de los datos antiguos de tu organización.

Los datos parcialmente encriptados siguen siendo útiles

Borrar sólo la IIP de un usuario suele ser suficiente para cumplir los requisitos del artículo 17 del RGPD. Los datos restantes pueden seguir siendo útiles para determinados casos de uso por parte del consumidor, como la creación de agregaciones analíticas. Podemos dejar los datos restantes en su lugar y seguir obteniendo un beneficio limitado de ellos.

Datos en varios sistemas

Borrar las claves de descifrado invalida simultáneamente todo acceso a los datos en todos los servicios de consumo. No tenemos que preocuparnos de cuándo se borran los datos, especialmente en el caso de los sistemas que tardan en borrar sus datos.

Más defensa en profundidad

La criptodestrucción proporciona una capa adicional de seguridad para prevenir incidentes de seguridad de datos. La filtración de datos cifrados es mucho menos perjudicial que la de datos sin cifrar, y ayuda a reducir tanto el riesgo como el impacto de una violación de la seguridad de los datos.

La criptodestrucción no te protege de los consumidores que almacenan negligentemente los datos descifrados o las claves de descifrado. Puedes contrarrestar esto asegurándote de que los consumidores tienen políticas de infoseguridad claras y sencillas que seguir, como conservar las claves de descifrado sólo durante 10 minutos, antes de borrarlas y tener que volver a solicitarlas al KMS. También puedes utilizar la lista de control de acceso para hacer un seguimiento de los servicios que solicitan acceso para el descifrado de datos, de modo que tu equipo de infoseguridad pueda auditarlos para comprobarsu cumplimiento.

Las normas y reglamentos para asegurar y manejar los datos son un componente importante de las responsabilidades del equipo de gobierno. Estas cuestiones son fundamentales para la viabilidad y supervivencia de una organización y no pueden dejarse en manos de los propietarios individuales de productos de datos para que las apliquen ad hoc. Asegúrate de que tú y tu equipo de gobierno federado tenéis un sólido conocimiento de los requisitos legales y empresariales para manejar tus datos, de modo que podáis orientar los requisitos de seguridad de la plataforma de datos de autoservicio.

El siguiente componente relacionado es el linaje del producto de datos. Aunque los controles de acceso y el cifrado ayudan a cumplir los requisitos legales de tratamiento de datos, es importante conocer todas las dependencias ascendentes y descendentes de un producto de datos. Echemos un vistazo más de cerca al linaje para ver cómo puede mejorar nuestra malla de datos.

Línea de productos de datos

El linaje nos permite rastrear qué servicios de están leyendo y escribiendo un producto de datos, incluyendo si el cliente consumidor está leyendo activamente el flujo. Los permisos básicos de lectura/escritura, junto con las identidades de los clientes, nos proporcionan una imagen bastante buena que podemos utilizar para rastrear las dependencias y el linaje. Podemos determinar qué sistemas y usuarios tienen o no acceso a datos sensibles, así como las rutas y caminos que toman los datos cuando viajan de un cliente y producto al siguiente.

Para una malla de datos basada en eventos respaldada por Apache Kafka de código abierto, los controles de acceso se establecen en el propio corredor de eventos. Muchos proveedores de SaaS también proporcionan una funcionalidad de orden superior en forma de controles de acceso basados en roles (RBAC), que te permiten componer roles basados en reglas y personas. En cualquier caso, los permisos son esenciales para realizar un seguimiento y construir linajes.

Hay dos tipos principales de linaje de datos que debes tener en cuenta para tus propias implementaciones. El primero es el linaje basado en la topología, que muestra las dependencias entre servicios y productos de datos en un momento dado. El segundo es el linaje basado en registros, que sigue la propagación de un registro a través de los servicios. Echemos un vistazo a cada uno de ellos.

Linaje basado en la topología

El linaje basado en la topología muestra las dependencias entre los productos de datos y sus consumidores como un gráfico, con flechas que apuntan del producto de datos a los consumidores registrados. Los nuevos productos de datos aparecen como nodos en el gráfico, al igual que los consumidores de productos de datos. El gráfico puede mostrar qué clientes están consumiendo activamente eventos, a qué ritmo, si están actualizados o si están reproduciendo datos históricos. También es posible añadir información y metadatos de servicios y productos de datos a la topología, proporcionando un modo alternativo de descubrimiento para tus posibles usuarios de la malla de datos.

El linaje basado en la topología es relativamente fácil de obtener, dado que los permisos y las identidades de los clientes ya son esenciales para la infoseguridad y, francamente, no son más que buenas prácticas en general. Incluso podrías construir el tuyo propio volcando tus identidades y permisos de cliente en un archivo y reconstruyéndolos en un grafo utilizando el marco de grafos que elijas.

Una mayoría significativa de las herramientas de linaje actuales se centran en el linaje basado en la topología, normalmente con un gráfico atractivo e interactivo en el que puedes hacer clic para ver información adicional, como las dependencias ascendentes y descendentes. Aunque muchas sólo pueden darte la topología tal y como es en este momento, otras han empezado a desplegar el linaje puntual, con el que puedes examinar y descargar el linaje en un momento concreto.

El linaje basado en la topología es útil para rastrear qué consumidores han accedido a qué productos de datos. En caso de datos erróneos en un producto, también puedes detectar qué consumidores posteriores pueden haberse visto afectados, de modo que puedan iniciarse acciones compensatorias. Por último, el propietario de un producto de datos puede consultar simplemente el gráfico de linaje para ver quién consume sus productos de datos y coordinarse con ellos en los próximos cambios.

Linaje basado en registros

El linaje basado en registros se centra en el seguimiento de un único registro a lo largo de su historia, registrando a dónde va, qué sistemas lo procesan y cualquier evento derivado con el que pueda estar relacionado. El linaje basado en registros debe proporcionar al auditor un historial completo del ciclo de vida del evento, de forma que sea posible una investigación posterior. El linaje basado en registros es mucho más complejo de implementar porque hay que tener en cuenta muchos casos extremos. El linaje basado en registros puede utilizarse junto con el linaje basado en topología, aunque tiende a ser el menos implementado de los dos.

Una opción de implementación sencilla es registrar el progreso de un evento a lo largo de su viaje, desde el producto de datos hasta el consumidor. En cada etapa de su viaje, se adjunta al registro, normalmente en la cabecera, un ID de servicio único, el tiempo de procesamiento y cualquier otro metadato necesario. Sin embargo, el linaje basado en registros suele ser mucho más difícil de conseguir a escala, ya que hay varios factores complicados importantes:

Múltiples consumidores de los mismos eventos

Un registro puede ser consumido por muchos usuarios distintos, lo que da lugar a múltiples copias del mismo evento, cada una con su propio linaje.

No todos los consumidores emiten eventos

Algunos consumidores no emiten eventos y, en su lugar, pueden servir el acceso a los datos a través de una API REST. Tendrían que tomar medidas adicionales para crear un registro de los registros que han ingerido y asegurarse de que los datos están disponibles para su consulta.

Agregar y unir eventos

Una agregación puede estar compuesta por un gran número de eventos, por lo que no resulta práctico hacer un seguimiento de todos los registros asociados a su composición. Lo mismo ocurre con las uniones, aunque en la práctica las uniones tienden a abarcar sólo una pequeña cantidad de eventos.

Transformaciones complejas

Los consumidores pueden tener casos de uso bastante complejos en los que los eventos de entrada no se corresponden fácilmente con los de salida.

Una alternativa al almacenamiento del linaje del registro es utilizar en su lugar una base de datos externa. Cada servicio debe informar al punto final de los eventos que ha consumido, procesado y emitido. Esta opción facilita el seguimiento del uso del registro cuando varios servicios han consumido y utilizado el producto de datos, incluidos aquellos en los que no se emiten nuevos eventos tras su uso.

Sin embargo, no resuelve los problemas relacionados con las uniones, agregaciones y transformaciones complejas, dejando un vacío potencial en el linaje a nivel de registro. Además, también tendrás que invertir en herramientas de cliente que informen automáticamente del estado de cada registro al servicio central, incluida la contabilidad de escalado, interrupciones y compatibilidad con el idioma del cliente.

Es importante que consideres por qué quieres linaje y qué problemas pretende ayudar a resolver. No existe una solución única para el linaje. Un banco tendrá requisitos de linaje mucho mayores que una tienda que venda calcetines, por lo que tendrás que asegurarte de que tu equipo de gobierno tiene una buena idea de los verdaderos requisitos de su propia organización. Hay soluciones de linaje que pueden resolver los problemas que hemos tratado en esta sección, pero requieren tiempo y esfuerzo para llevarlas a cabo, tiempo y esfuerzo que puede invertirse mejor en otra cosa.

Si no entiendes bien qué problemas pretende resolver tu solución de linaje, corres el riesgo de construir algo completamente irrelevante. Debes averiguar qué auditorías necesitas y cuáles son los riesgos para tus sistemas, y luego presentar una propuesta detallada sobre cómo una solución de linaje puede ayudarte a satisfacer tus necesidades.

Resumen

La gobernanza federada abarca un amplio territorio.

La malla de datos requiere un equipo de gobierno que ayude a poner orden en las variadas tecnologías, dominios, modelos de datos y casos de uso de la organización. Gobernar es un compromiso intensamente social para trabajar junto con tus compañeros e idear soluciones eficaces para los obstáculos de la implantación de la malla de datos. Como parte del equipo de gobierno, te centrarás en identificar normas, marcos, lenguajes y herramientas comunes que ayuden a respaldar los casos de uso de la malla de datos.

El equipo de gobernanza trabaja junto con los expertos técnicos del dominio para identificar áreas de mejora en la plataforma de autoservicio. Si quieres que todos los miembros de tu organización se adhieran a las políticas de encriptación de datos, es mucho más fácil asegurarse de que estén integradas por defecto en la plataforma de productos de datos y no dejar que cada equipo las aplique por sí mismo. Del mismo modo, el equipo de gobernanza se asegura de que se escuche a quienes utilizan la malla de datos, se atiendan sus quejas y se compartan y ejemplifiquen las historias de éxito.

La gobernanza federada también tiene que ver con el seguimiento del uso de los datos, asegurándose de que cumple los requisitos legales y las buenas prácticas de infoseguridad. Necesitarás fuertes controles de acceso para asegurarte de saber qué sistemas y personas tienen acceso a qué datos, pero tendrás que equilibrarlo con la garantía de que tus equipos puedan acceder a la mayoría de los datos cuando los necesiten. También puede ser necesario cifrar los datos, parcial o totalmente, y archivarlos indefinidamente, de nuevo en función de tusrequisitos de tratamiento de datos.

Por último, la gobernanza también consiste en orientar la implantación de la plataforma de autoservicio. El equipo de gobierno, junto con sus expertos técnicos, debe codificar y racionalizar la funcionalidad de la plataforma de autoservicio, de modo que sea fácil para los usuarios hacer lo correcto y difícil para ellos hacer lo incorrecto. Veremos esto con más detalle en el próximo capítulo.