sql >> Base de Datos >  >> RDS >> Database

Enfoques de seguridad en el modelado de datos. parte 4

Esta es la cuarta de nuestra serie de varias partes sobre el modelado de datos para la seguridad de la información, así como las características de los datos. Un modelo de datos simple para un sitio web ficticio que admite organizaciones de intereses compartidos (clubes de observación de aves, etc.) nos ha proporcionado contenido para explorar el modelado de datos desde el punto de vista de la seguridad.

En la obra de Oscar Wilde El abanico de Lady Windermere , Lord Darlington etiqueta a un cínico como "alguien que conoce el precio de todo y el valor de nada". Lamentablemente, la información en nuestras bases de datos puede ser tratada inconscientemente de la misma manera. ¿La cuenta de un cliente vale la suma de sus compras? ¿Qué sufrimos si perdemos cuatro horas de datos de marketing durante la temporada de compras navideñas?

Nosotros, los modeladores de datos, no haremos esas evaluaciones, pero debemos almacenar sus datos relevantes en nombre de las personas que sí lo harán. Tendremos que llenar los vacíos de la estructura de datos implícita. En este artículo, veremos cómo agregar este importante elemento de seguridad a nuestra base de datos.

¡Muéstrame el dinero!

¿Cuánto debemos proteger cada objeto de datos? Considérelos a la luz de la Confidencialidad , Integridad y Disponibilidad — las cualidades clave que determinan la seguridad de un sistema de información. También debemos permitir la diferencia entre estas medidas sobre una base "intrínseca" y cuánto pueden afectar estos datos a la seguridad.

Hay dos razones para hacer esto. Primero, nos ayudará a ver cómo proteger los datos en la base de datos de nuestro club. ¿Deberían cifrarse algunas tablas? ¿Poner en otros esquemas? ¿Quizás aguas abajo adjuntaremos controles de base de datos privada virtual? Esta información nos ayudará a elegir las medidas de seguridad adecuadas.

En segundo lugar, reflexionaremos sobre los datos desde una perspectiva contable sin procesar:¿Cuál es su valor total? ¿Qué podríamos perder en caso de corrupción de datos? ¿Cuál es nuestra responsabilidad si se revelan datos personales? Cuando agregamos esta información a nuestro esquema, agregamos una métrica crítica a nuestros datos almacenados:dólares y centavos. Esto permite que las personas que pagan las facturas determinen cuánto pueden pagar por seguridad y, de manera monetaria, cuánto vale.

Todas las relaciones están detalladas

Recapitulemos el estado de nuestro modelo. A partir del último artículo, la estructura de datos se completó. Las personas, los clubes, la membresía, las fotos, los álbumes y el contenido están todos allí. Cómo se unen está ahí. Este esquema está listo para almacenar datos con las relaciones capturadas explícitamente en todo momento, mientras que las relaciones implícitas se han eliminado en la medida de lo posible.



Atribución de valor y sensibilidad

Ahora descubriremos cómo poner números a los datos. Realmente no podemos adjuntar un sencillo valor a un elemento de datos que nos dice cuánto protegerlo. Sin embargo, tampoco podemos, y no necesitamos, entrar en una colección de métricas. Nos centraremos en cuánto puede ganarnos una parte de los datos y cuánto nos puede costar perder o divulgar esos datos.

Usamos los términos "valor" y "sensibilidad" para esto:una medida positiva y negativa, por así decirlo. El valor a menudo se considera en términos de valor futuro u oportunidad. La sensibilidad es muy defensiva; se relaciona con riesgos a nivel financiero (sanciones regulatorias o legales) y de pérdida de reputación o de fondo de comercio.

La valoración se relaciona directamente con la integridad y Disponibilidad . Juzgaremos esto en términos de los beneficios que pueden generar los datos, o cuánto daño se hará si se pierde el acceso a ellos. Abordamos la sensibilidad principalmente en términos de Confidencialidad , que debe medirse por el daño o la responsabilidad si se revela.

La estructura común de valoración y sensibilidad

Ahora consideremos la valoración y la sensibilidad frente a nuestra base de datos. Cuando volvemos a ver el modelo de datos, encontramos que estas cualidades son relativas solo a un club o una persona. Un club o una persona se benefician del valor de algo, y sufren cuando algo sensible se hace público. Por lo tanto, cada una de estas valoraciones se capturan con respecto a un club o una persona. a medida que observamos nuestras entidades de datos, nos aseguraremos de que cada una que tenga un valor (beneficio) también conlleve una sensibilidad (riesgo), y viceversa. Por lo tanto, cada entidad involucrada tendrá campos separados de Valoración y Sensibilidad. Serán opcionales o predeterminados en la mayoría de los casos. Además, ambos se pesarán en términos de dinero:un valor de moneda, preciso en centésimas de dólar estadounidense. (En aras de la claridad, usaremos solo una moneda). Celébrelo o laméntelo, el dinero es nuestra única métrica utilizable para cualquiera de los dos. Para aprovechar esta similitud, los llamaremos "Importancia".

Como modeladores de datos, no podemos ponerle números a esto nosotros mismos. Incluso como operador del sitio o de la base de datos, no sabemos lo suficiente como para asignar estos valores; además, los datos no son completamente nuestros. Para los datos que son específicos de un club, debemos permitir que ese club asigne los suyos propios niveles de importancia y sus reglas para usar esos niveles. Luego aplicamos sus reglas a sus datos.

Comencemos con los tipos de entidades que los clubes pueden asignar.

Datos del club

Las entidades del Club son:

  • Club
  • Oficina_del_club
  • Oficial
  • Miembro
  • Álbum
  • Foto_álbum
  • Foto

Agregaremos Valuation y Sensitivity columnas a cada uno de ellos. Porque estas columnas están unidas al Club , sus nombres son específicos, p. club_sensitivity .

Aquí está nuestro conjunto de tablas de enfoque para Club , incluida Persona :



Datos personales

Ahora necesitamos dirigirnos a la Person entidad. Nuevamente, no asignamos los valores aquí, esa es la prerrogativa de la persona. Naturalmente, necesitamos agregar columnas de Importancia a Persona . Pero para apoyar mejor la privacidad personal, vamos a dividir esta entidad más finamente. Después de todo, la privacidad es clave para la sensibilidad de los datos.

Primero, agregaremos una nueva columna llamada monicker eso es como un nombre de usuario o alias. Los miembros del club pueden usar eso para identificarse en lugar de sus nombres reales. Proporcionaremos un par de columnas de valoración/sensibilidad para la asociación de nombre y apodo. Estos serán person_name_valuation y person_name_sensitivity . El resto de los campos están controlados por estos dos pares.

Una Persona La actividad del club es de su interés tanto como el Club 's. Por lo tanto, agregaremos los mismos campos de Importancia a Miembro y oficial .

Ahora podríamos agregar person_importance campos a la Foto entidad, pero mira el photo_content columna. Una foto puede involucrar a varias personas, y esto es parte de lo que almacenamos en photo_content. Por lo tanto, colocaremos los campos de importancia en photo_content. en lugar de en la foto.

El Modelo “Sensibilizado”

Hemos modificado nuestro modelo de datos para atribuir el valor y la sensibilidad de los datos en todos los lugares donde se necesitan. El siguiente es nuestro esquema final.

Hemos tenido cuidado de evitar distorsionar el esquema original con relaciones o restricciones adicionales. Esto es fundamental porque estamos tomando ese esquema como un análisis preciso de los datos reales con reglas comerciales reales.




Adjuntar cualquier tipo de importancia inherente a sus datos es difícil. Es peor si está tratando de aplicarlo a una base de datos sin soporte en el modelo o esquema. Este artículo demuestra una técnica para adjuntar esta información de manera que no distorsione las partes comerciales intrínsecas del modelo.

La flexibilidad y modificabilidad de Value y Sensibilidad son objetivos clave aquí. A medida que comience a aplicar valores reales a estos atributos, encontrará que necesita modificarlos y revisar su enfoque. Esa es una de las razones para adjuntar individualmente estos valores a las tablas en sí, en lugar de tenerlos fuera de borda. La desventaja es que se vuelve bastante complicado, debido a la gran cantidad de ubicaciones para estos valores. Esto puede incluso mostrarse en cómo se usa el modelo. Abordaremos el tema multifacético de la gestión de la complejidad en la seguridad de la información en nuestro próximo artículo.

Por favor, deje cualquier comentario o crítica en nuestro combox.