Approches de sécurité dans la modélisation des données. Partie 3

Il s'agit de la troisième de notre série en plusieurs parties sur l'application des approches de sécurité de l'information à la modélisation des données. La série utilise un modèle de données simple, quelque chose pour gérer les clubs sociaux et les groupes d'intérêt, pour fournir le contenu que nous cherchons à sécuriser. Plus tard, nous aborderons la modélisation pour la gestion des autorisations et des utilisateurs, ainsi que d'autres parties de l'implémentation d'une base de données sécurisée.

Dans les situations sociales, il est courant de "lire entre les lignes" - en déduisant les hypothèses et les affirmations tacites dans une conversation. Il en va de même pour la création de logiciels et le stockage de données dans une base de données. Les factures sont énumérées avec l'ID client intégré, et combien d'entités de données utilisent une date-heure dans le cadre de la clé ? Il est difficile d'imaginer tout documenter ou structurer en profondeur sans une sorte d'omission. Mais dans notre dernier épisode, nous avons fait exactement cet exercice. Nous avons pu attribuer une sensibilité à plusieurs parties de la base de données de notre club social. Mais pour quantifier et gérer cette sensibilité, nous devons augmenter la structure de notre modèle de données afin de clarifier les données sensibles et leurs relations.

Combler les lacunes du modèle de données

La modélisation des données pour la sécurité nécessite plusieurs variétés distinctes de changements de structure. Nous les explorons tour à tour, en utilisant un modèle de données de club social (très !) simple comme base pour cette série. Au fur et à mesure que nous avancions, nous avons amélioré le modèle avec plus de données. Dans le dernier volet, nous avons analysé le modèle pour attribuer la sensibilité des données là où nous l'avons trouvée. Cette analyse aussi a révélé qu'il y avait des endroits où le modèle de données indiquait des liens qui n'étaient pas réellement capturés explicitement dans les colonnes et les relations clés. Le modélisateur doit s'y attendre dans une analyse de sécurité. À partir de ces découvertes, nous rendrons ces relations aussi concrètes et claires que possible en construisant les tableaux et les liens entre eux. Cela nous permettra d'attacher des attributs de sécurité plus loin.

Construire les relations de données dans le club

Toutes les relations dans les données, ainsi que les entités de données elles-mêmes, doivent avoir une certaine représentation afin de leur attribuer une valeur ou une sensibilité. De nouvelles colonnes, de nouvelles clés, de nouvelles références, voire de nouvelles tables peuvent être nécessaires pour y parvenir. Lorsque nous avons analysé les tableaux et leurs relations dans notre dernier article, nous avons isolé deux tableaux principaux avec des données à haute sensibilité :

• Person
• Photo

De plus, nous en avions quatre contenant des données modérément sensibles :

• Member
• Club
• Office
• Club_Office

Ces aspects de sensibilité sont en partie intrinsèques à chaque tableau, mais les relations non explicites portent une grande partie de la sensibilité. Pour l'attacher, nous commençons à enregistrer les relations et leur donnons une structure pour contenir la sensibilité.

Relations intégrées dans les photos

Photo contient de nombreuses relations intégrées que nous devons capturer. Nous nous intéressons principalement à la relation avec Person . Pour capturer la relation Personne-Photo, j'ajoute le Photo_Content tableau :

Il y a beaucoup d'aspects différents par lesquels une Person peut se rapporter à une Photo . J'ai décidé d'ajouter un nouveau tableau, Photo_Content_Role , pour caractériser la relation d'une Photo à une Personne. Plutôt que d'avoir des tables séparées pour chaque type de relation, nous utilisons une seule table de connexion et la table Photo_Content_Role. Ce tableau est une liste de référence avec des relations standard comme ce que nous avons déjà noté. Voici notre ensemble initial de données pour Photo_Content_Role :

OK, donc c'est un appât et un interrupteur. J'ai dit Photo_Content mettrait en relation les gens aux photos, alors pourquoi y a-t-il quelque chose à propos de "l'objet représenté" ? Logiquement, il y aura des photos où l'on décrirait le contenu sans identifier une Personne . Dois-je ajouter une autre table pour cela, avec un ensemble distinct de rôles de contenu ? J'ai décidé que non. Au lieu de cela, j'ajouterai une ligne de personne nulle au Person table en tant que données de base et dont le contenu non personnel fait référence à cette personne. (Oui, programmeurs, c'est un peu plus de travail. De rien.) La "Personne nulle" aura id zéro (0).

Clé d'apprentissage n°1 :

Réduire les tableaux contenant des données sensibles en superposant des structures de relations similaires dans un seul tableau.

Je prévois qu'il peut y avoir des relations supplémentaires qui seront découvertes en aval. Et il est également possible qu'un club social ait ses propres rôles à attribuer à une Personne dans une photo . Pour cette raison, j'ai utilisé une clé primaire de substitution "pure" pour Photo_Content_Role , et a également ajouté une clé étrangère facultative à Club . Cela nous permettra de soutenir des utilisations spéciales par des clubs individuels. J'appelle le champ "exclusif" pour indiquer qu'il ne devrait pas être disponible pour les autres clubs.

Clé d'apprentissage n°2 :

Lorsque les utilisateurs finaux peuvent étendre une liste intégrée, attribuez à sa table une clé de substitution pure pour éviter les collisions de données.

Photo_Content_Role.max_per_person peut aussi être mystérieux. Vous ne pouvez pas le voir dans le diagramme, mais Photo_Content_Role.id porte sa propre contrainte unique sans max_per_person . Essentiellement, la vraie clé primaire est juste id . En ajoutant max_per_person à id dans la clé primaire, je force chaque table de référence à absorber les informations par lesquelles elle peut (devrait !) appliquer une contrainte de contrôle de cardinalité. Voici la contrainte de vérification dans Photo_Content .

Apprentissage clé n° 3 :

Lorsque chaque ligne d'une table a des restrictions individuelles, les tables de référence doivent ajouter une nouvelle contrainte unique, en étendant une clé naturelle avec les champs de contrainte. Faites en sorte que la table enfant fasse référence à cette clé.

Regardons un peu plus Photo_Content . Il s'agit principalement d'une relation entre Photo et Person , avec la relation spécifiée par le rôle de contenu attaché. Comme je l'ai déjà noté, cependant, c'est ici que nous stockons tous informations descriptives sur la photo. Pour s'adapter à ce type d'ouverture, nous avons l'option content_headline et content_detailed Colonnes. Ceux-ci seront rarement nécessaires pour une association ordinaire entre une Personne et une Photo. Mais un titre comme "Bob Januskis reçoit le prix d'excellence annuel" est facile à anticiper. De plus, s'il n'y a pas de personne - "Objet représenté", Personne 0 - nous devons exiger quelque chose dans le content_headline , comme "Pente nord-ouest du mont Ararat".

La dernière relation photo manquante :albums

Jusqu'à présent, nous n'avons rien ajouté qui concerne Photo s à Photo s. C'est un gros truc pour les réseaux sociaux et les services photo :Album s. Et vous ne les voudriez pas dans la boîte à chaussures proverbiale, n'est-ce pas ? Alors comblons cette lacune flagrante – mais réfléchissons-y aussi.

Album joint Photo s d'une manière différente des autres relations que nous avons couvertes. Photo s peuvent être associés par un même club, une date similaire, des coordonnées GPS proches, un même photographe, etc. Cependant, Album indique clairement que la Photo s font partie d'un sujet ou d'une histoire unique. Ainsi, les aspects liés à la sécurité d'une Photo peut être déduit d'un autre dans l'Album . De plus, l'ordonnancement peut amplifier ou diminuer ces inférences. Ne pensez donc pas qu'à Album comme une collection anodine. Photo s est tout sauf.

Bien qu'il ne soit pas anodin du point de vue de la sécurité, Album est une entité simple avec un Id pur clé de substitution détenue par un Club (pas une Person ). Album_Photo nous donne un ensemble de Photo s séquencé par Photo_Order . Vous remarquerez que j'ai créé l'Album id et order la clé primaire. La relation est vraiment entre la Photo et l'Album , alors pourquoi ne pas en faire la clé primaire ? Parce que les cas impairs nécessitant une Photo à répéter dans un Album sont certainement possibles. J'ai donc mis Photo_Order dans la clé primaire, et après réflexion, a décidé d'ajouter une autre clé unique avec album et photo pour éviter une Photo de se répéter dans un Album . Si assez de cris pour répéter une Photo dans un Album surviennent, une clé unique est plus facile à supprimer qu'une clé primaire.

Apprentissage clé n° 4 :

Pour la clé primaire, sélectionnez une clé candidate présentant le moins de risque d'être rejetée ultérieurement.

Métadonnées des photos

Les dernières informations potentiellement sensibles à ajouter sont les métadonnées (généralement créées par l'appareil qui a pris les photos). Ces données ne sont pas partie d'une relation, mais elle est intrinsèque à la photo. La principale définition des informations qu'un appareil photo stocke avec une photo est EXIF, une norme industrielle japonaise (JEITA). EXIF est extensible et peut prendre en charge des dizaines ou des centaines de champs, dont aucun ne peut être requis à partir de nos images téléchargées. Ce statut non requis est dû au fait que ces champs ne sont pas communs à tous les formats de photos et peuvent être effacés avant le téléchargement. J'ai construit Photo avec de nombreux champs couramment utilisés, notamment :

• camera_mfr
• camera_model
• camera_software_version
• image_x_résolution
• image_y_resolution
• unité_résolution_image
• image_exposure_time
• camera_aperture_f
• GPSLatitude
• GPS Longitude
• Altitude GPS

Les champs GPS sont, bien entendu, ceux qui ajoutent la plus grande sensibilité à une Photo .

Notre modèle, avec toutes les données sensibles et précieuses définies

Nous terminons cette phase de sécurisation de la base de données des clubs avec ces modifications. Toutes les connexions et les données supplémentaires nécessaires sont présentes, comme illustré ci-dessous. J'ai fait Photo informations en rouge et Album turquoise clair pour transmettre mon idée de regroupements logiques. L'augmentation des éléments de données est réelle, mais très minimisée.

Conclusion

La mise en place d'un modèle de données sur une bonne base de sécurité nécessite une application ordonnée et systématique des principes de sécurité ainsi qu'une pratique des bases de données relationnelles. Dans cet article, nous avons examiné le modèle de données et soigneusement rempli la structure manquante qui était implicite, mais non exprimée dans le schéma. Nous ne pourrions pas attribuer de valeur ou assurer la protection des données existantes sans ajouter les données qui les complètent et les relient correctement. Une fois cela en place, nous allons procéder à la fixation des éléments d'évaluation des données et de sensibilité des données qui nous permettront de voir clairement toutes les données d'un point de vue de sécurité complet. Mais c'est dans notre prochain article.