Enfoques de seguridad en el modelado de datos. parte 3

Esta es la tercera de nuestra serie de varias partes sobre la aplicación de enfoques de seguridad de la información al modelado de datos. La serie utiliza un modelo de datos simple, algo para administrar clubes sociales y grupos de interés, para proporcionar el contenido que buscamos asegurar. Más adelante abordaremos el modelado para autorización y gestión de usuarios, así como otras partes de la implementación de una base de datos segura.

En situaciones sociales, es común "leer entre líneas", deduciendo las suposiciones y afirmaciones tácitas en una conversación. Lo mismo ocurre al crear software y almacenar datos en una base de datos. Las facturas se enumeran con la identificación del cliente incrustada, y ¿cuántas entidades de datos usan una fecha y hora como parte de la clave? Es difícil imaginar documentar o estructurar todo a fondo sin algún tipo de omisión. Pero en nuestra última entrega, hicimos exactamente ese ejercicio. Pudimos atribuir sensibilidad a varias partes de la base de datos de nuestro club social. Pero para cuantificar y administrar esa sensibilidad, debemos aumentar la estructura de nuestro modelo de datos para que los datos confidenciales y sus relaciones sean claros.

Cerrar las brechas del modelo de datos

El modelado de datos para la seguridad requiere varias variedades distintas de cambios de estructura. Estamos explorando estos a su vez, utilizando un modelo de datos de club social (¡muy!) simple como base para esta serie. A medida que avanzamos, hemos mejorado el modelo con más datos. En la última entrega, analizamos el modelo para atribuir la sensibilidad de los datos donde la encontramos. Este análisis también reveló que había lugares donde el modelo de datos indicaba enlaces que en realidad no estaban capturados explícitamente en columnas y relaciones clave. El modelador debe esperar esto en un análisis de seguridad. Avanzando a partir de estos descubrimientos, haremos que estas relaciones sean lo más concretas y claras posible construyendo las tablas y las conexiones entre ellas. Esto nos permitirá adjuntar atributos de seguridad más adelante.

Desarrollar las relaciones de datos en el club

Todas las relaciones en los datos, así como las propias entidades de datos, deben tener alguna representación para atribuirles valor o sensibilidad. Es posible que se necesiten nuevas columnas, nuevas claves, nuevas referencias e incluso nuevas tablas para lograr esto. Cuando analizamos las tablas y sus relaciones en nuestra última publicación, aislamos dos tablas principales con datos de alta sensibilidad:

• Person
• Photo

Además, teníamos cuatro que contenían datos moderadamente confidenciales:

• Member
• Club
• Office
• Club_Office

Estos aspectos de la sensibilidad son en parte intrínsecos a cada mesa, pero las relaciones no explícitas conllevan gran parte de la sensibilidad. Para adjuntarlo, comenzamos a registrar las relaciones y darles una estructura para contener la sensibilidad.

Relaciones incrustadas en fotos

Photo contiene muchas relaciones incrustadas que necesitamos capturar. Principalmente, nos interesa la relación con Person . Para capturar la relación Persona-Foto, agrego el Photo_Content tabla:

Hay muchos aspectos diferentes por los cuales una Person puede relacionarse con una Photo . Decidí agregar una nueva tabla, Photo_Content_Role , para caracterizar la relación de una Foto con una Persona. En lugar de tener tablas separadas para cada tipo de relación, usamos una sola tabla de conexión y la tabla Photo_Content_Role. Esta tabla es una lista de referencia con relaciones estándar como las que ya hemos señalado. Este es nuestro conjunto inicial de datos para Photo_Content_Role :

OK, entonces esto es un cebo y un cambio. Dije Photo_Content relacionaría personas a las fotos, entonces, ¿por qué hay algo sobre "objeto representado"? Lógicamente habrá fotos donde describamos el contenido sin identificar a una Persona . ¿Debería agregar otra tabla para esto, con un conjunto separado de roles de contenido? Decidí que no. En su lugar, agregaré una fila de persona nula a Person table como datos semilla, y tener contenido no personal que se refiera a esa persona. (Sí, programadores, es un poco más de trabajo. De nada). La 'Persona nula' tendrá id cero (0).

Aprendizaje clave n.º 1:

Minimice las tablas con datos confidenciales superponiendo estructuras de relaciones similares en una sola tabla.

Anticipo que puede haber relaciones adicionales que se descubrirán aguas abajo. Y también es posible que un club social pueda tener sus propios roles para atribuir a una Persona en una Foto . Por esa razón, he usado una clave principal sustituta 'pura' para Photo_Content_Role , y también agregó una clave externa opcional a Club . Esto nos permitirá apoyar usos especiales por parte de clubes individuales. Llamo al campo "exclusivo" para indicar que no debería estar disponible para otros clubes.

Aprendizaje clave n.º 2:

Cuando los usuarios finales puedan extender una lista integrada, asigne a su tabla una clave sustituta pura para evitar colisiones de datos.

Photo_Content_Role.max_per_person también puede ser misterioso. No puede verlo en el diagrama, pero Photo_Content_Role.id lleva su propia restricción única sin max_per_person . En esencia, la clave principal real es solo id . Agregando max_per_person a id en la clave principal, obligo a cada tabla de referencia a tomar información mediante la cual puede (¡debería!) hacer cumplir una restricción de verificación de cardinalidad. Esta es la restricción de verificación en Photo_Content .

Aprendizaje clave n.º 3:

Cuando cada fila de una tabla tiene restricciones individuales, las tablas de referencia deben agregar una nueva restricción única, extendiendo una clave natural con los campos de restricción. Haga que la tabla secundaria se refiera a esa clave.

Veamos un poco más Photo_Content . Esta es principalmente una relación entre Photo y Person , con la relación especificada por el rol de contenido adjunto. Sin embargo, como señalé antes, aquí es donde almacenamos todos Información descriptiva sobre la foto. Para dar cabida a este tipo de final abierto, tenemos el content_headline opcional y content_detailed columnas Estos raramente serán necesarios para una asociación ordinaria entre una Persona y una Foto. Pero un titular como "Bob Januskis recibe el premio anual al logro" es fácil de anticipar. Además, si no hay Persona:'Objeto representado', Persona 0:debemos solicitar algo en el content_headline , como "Ladera noroeste del monte Ararat".

La relación de la última foto perdida:Álbumes

Hasta ahora, no hemos agregado nada relacionado con Photo s a Photo s. Es algo importante para las redes sociales y los servicios de fotos:Album s. Y no los querrías en la proverbial caja de zapatos, ¿verdad? Entonces, llenemos este vacío evidente, pero también pensemos en ello.

Album adjunta Photo s de una manera diferente a las otras relaciones que hemos cubierto. Photo Los s pueden estar asociados por el mismo club, una fecha similar, coordenadas GPS cercanas, el mismo fotógrafo, etc. Sin embargo, Album indica claramente que la Photo s son parte de un solo tema o historia. Como tal, los aspectos relevantes para la seguridad de una Photo puede deducirse de otro en el Album . Además, el ordenamiento puede amplificar o disminuir esas inferencias. Así que no pienses solo en Album como una colección inocua. Relacionando Photo s es todo lo contrario.

Aunque no es inocuo desde el punto de vista de la seguridad, Album es una entidad sencilla con un Id puro clave sustituta propiedad de un Club (no una Person ). Album_Photo nos da un conjunto de Photo s secuenciados por Photo_Order . Notarás que hice el Album id y order la clave primaria. La relación es realmente entre la Photo y el Album , entonces, ¿por qué no convertirlos en la clave principal? Porque casos extraños que requieren una Photo para repetir en un Album ciertamente son posibles. Así que puse Photo_Order en la clave principal, y después de pensarlo un poco, decidió agregar una clave única alternativa con álbum y foto para evitar una Photo de repetirse en un Album . Si basta de llantos por repetir una Photo en un Album surgir, una clave única es más fácil de eliminar que una clave principal.

Aprendizaje clave n.º 4:

Para la clave principal, seleccione una clave candidata con el menor riesgo de ser descartada más tarde.

Metadatos de fotos

La última información potencialmente confidencial que se agrega son los metadatos (generalmente creados por cualquier dispositivo que haya tomado las fotos). Estos datos no parte de una relación, pero es intrínseco a la foto. La definición principal de información que almacena una cámara con una foto es EXIF, un estándar de la industria de Japón (JEITA). EXIF es extensible y puede admitir docenas o cientos de campos, ninguno de los cuales puede requerirse de nuestras imágenes cargadas. Este estado no obligatorio se debe a que estos campos no son comunes a todos los formatos de fotos y se pueden borrar antes de cargarlos. He construido Photo con muchos campos de uso común, incluidos:

• cámara_mfr
• modelo_de_cámara
• versión_software_de_la_cámara
• imagen_x_resolución
• imagen_y_resolución
• unidad_de_resolución_de_imagen
• tiempo_de_exposición_de_la_imagen
• apertura_de_la_cámara_f
• Latitud GPS
• GPSLongitud
• Altitud GPS

Los campos GPS son, naturalmente, los que añaden la mayor sensibilidad a una Photo .

Nuestro modelo, con todos los datos sensibles y valiosos definidos

Completamos esta fase de asegurar la base de datos del club con estos cambios. Todas las conexiones y los datos adicionales necesarios están presentes, como se muestra a continuación. He hecho Photo información en rojo y Album turquesa claro para transmitir mi idea de agrupaciones lógicas. El aumento de elementos de datos es real, pero muy minimizado.

Conclusión

Poner cualquier modelo de datos en una buena base de seguridad requiere una aplicación ordenada y sistemática de los principios de seguridad, así como la práctica de la base de datos relacional. En esta entrega, revisamos el modelo de datos y completamos cuidadosamente la estructura faltante que estaba implícita, pero no expresada en el esquema. No podríamos asignar valor ni brindar protección a los datos existentes sin agregar los datos que los completan y los vinculan correctamente. Con esto en su lugar, procederemos a adjuntar los elementos de valoración de datos y sensibilidad de datos que nos permitirán ver claramente todos los datos desde una perspectiva de seguridad completa. Pero eso es en nuestro próximo artículo.