Il s'agit du quatrième de notre série en plusieurs parties sur la modélisation des données pour la sécurité de l'information ainsi que sur les caractéristiques des données. Un modèle de données simple pour un site Web fictif qui prend en charge des organisations d'intérêt partagé (clubs d'observation des oiseaux, etc.) nous a fourni un contenu pour explorer la modélisation des données du point de vue de la sécurité.
Dans la pièce d'Oscar Wilde L'éventail de Lady Windermere , Lord Darlington qualifie un cynique de "quelqu'un qui connaît le prix de tout et la valeur de rien". Malheureusement, les informations contenues dans nos bases de données peuvent être inconsciemment traitées de la même manière. Un compte client vaut-il la somme de ses achats ? De quoi souffrons-nous si nous perdons quatre heures de données marketing pendant la période des fêtes ?
Nous, les modélisateurs de données, ne ferons pas ces évaluations, mais nous devons stocker leurs données pertinentes au nom des personnes qui le feront. Nous devrons combler les lacunes de la structure de données implicite. Dans cet article, nous verrons comment ajouter cet élément de sécurité important à notre base de données.
Montrez-moi l'argent !
Dans quelle mesure devons-nous protéger chaque objet de données ? Considérez-les à la lumière de la confidentialité , Intégrité , et Disponibilité — les qualités clés déterminant la sécurité d'un système d'information. Nous devons également tenir compte de la différence entre ces mesures sur une base « intrinsèque » et dans quelle mesure ces données peuvent affecter la sécurité.
Il y a deux raisons de le faire. Tout d'abord, cela nous aidera à voir comment protéger les données de notre base de données de club. Certaines tables doivent-elles être chiffrées ? Mettre d'autres schémas ? Peut-être qu'en aval, nous attacherons des contrôles de base de données privée virtuelle ? Ces informations nous aideront à choisir les garanties appropriées.
Deuxièmement, nous réfléchirons aux données d'un point de vue comptable brut :quelle est sa valeur totale ? Que pourrions-nous perdre en cas de corruption de données ? Quelle est notre responsabilité si des données personnelles sont divulguées ? Lorsque nous ajoutons ces informations à notre schéma, nous ajoutons une métrique critique à nos données stockées :dollars et cents. Cela permet aux personnes qui paient les factures de déterminer ce qu'elles peuvent se permettre pour la sécurité ––– et, d'une manière monétaire, combien cela vaut.
Toutes les relations sont énoncées
Récapitulons l'état de notre modèle. Depuis le dernier article, la structure des données a été remplie. Les personnes, les clubs, les adhésions, les photos, les albums et le contenu sont tous là. Comment ils se lient ensemble est là. Ce schéma est prêt à stocker des données avec les relations explicitement capturées tout au long, tandis que les relations implicites ont été éliminées dans la mesure du possible.
Attribution de valeur et de sensibilité
Nous allons maintenant découvrir comment associer des nombres à des données. Nous ne pouvons vraiment pas joindre un single valeur à un élément de données nous indiquant combien le protéger. Cependant, nous ne pouvons pas – et n'avons pas besoin – d'entrer dans une collection de mesures non plus. Nous nous concentrerons sur ce qu'une donnée peut nous rapporter, et sur ce que la perte ou la divulgation de cette donnée peut nous coûter.
Nous utilisons les termes « valeur » et « sensibilité » pour cela - une mesure positive et une mesure négative, si vous voulez. La valeur est souvent considérée en termes de valeur future ou d'opportunité. La sensibilité est très défensive; il porte sur des risques sur le plan financier (sanctions réglementaires ou judiciaires) et en perte de réputation ou de clientèle.
L'évaluation est directement liée à Intégrité et Disponibilité . Nous jugerons cela en fonction des avantages que les données peuvent générer ou des dommages qui seront causés si l'accès à celles-ci est perdu. Nous abordons la sensibilité principalement en termes de Confidentialité , qui doit être mesuré par le dommage ou la responsabilité s'il est révélé.
La structure commune d'évaluation et de sensibilité
Considérons maintenant l'évaluation et la sensibilité par rapport à notre base de données. En examinant à nouveau le modèle de données, nous constatons que ces qualités ne sont relatives qu'à un club ou à une personne. Un club ou une personne bénéficie de la valeur de quelque chose, et ils souffrent quand quelque chose de sensible est rendu public. Par conséquent, chacune de ces évaluations est capturée par rapport à un club ou à une personne. en examinant nos entités de données, nous veillerons à ce que chacune d'entre elles ait une valeur (avantage) comporte également une sensibilité (risque), et vice-versa. Ainsi, chaque entité impliquée aura à la fois des champs d'évaluation et de sensibilité distincts. Ils seront facultatifs ou par défaut dans la plupart des cas. De plus, les deux seront pesés en termes d'argent :une valeur monétaire, précise au centième de dollar américain. (Par souci de clarté, nous n'utiliserons qu'une seule devise.) Célébrez-le ou déplorez-le, l'argent est notre seule mesure utilisable pour l'un ou l'autre. Pour tirer parti de ces points communs, nous les appellerons "Importance".
En tant que modélisateurs de données, nous ne pouvons pas chiffrer cela nous-mêmes. Même en tant qu'opérateur de site ou de base de données, nous n'en savons pas assez pour attribuer ces valeurs ; de plus, les données ne nous appartiennent pas entièrement. Pour les données spécifiques à un club, nous devons laisser ce club attribuer les siennes niveaux d'importance et ses règles d'utilisation de ces niveaux. Ensuite, nous appliquons leurs règles à leurs données.
Commençons par les types d'entités que les clubs peuvent attribuer.
Données des clubs
Les entités du Club sont :
- Club
- Club_Office
- Officier
- Membre
- Album
- Album_Photo
- Photo
Nous ajouterons Valuation et Sensitivity colonnes à chacun d'eux. Parce que ces colonnes sont rattachées au Club , leurs noms sont spécifiques – par ex. club_sensitivity .
Voici notre ensemble de tableaux de focus pour Club , y compris Personne :
Données personnelles
Nous devons maintenant nous adresser à la Person entité. Encore une fois, nous n'attribuons pas les valeurs ici - c'est la prérogative de la personne. Naturellement, nous devons ajouter des colonnes d'importance à Personne . Mais pour mieux soutenir la vie privée, nous allons découper cette entité plus finement. Après tout, la confidentialité est la clé de la sensibilité des données.
Tout d'abord, nous allons ajouter une nouvelle colonne appelée monicker c'est comme un nom d'utilisateur ou un alias. Les membres du club peuvent l'utiliser pour l'identification plutôt que leurs noms réels. Nous fournirons une paire de colonnes évaluation/sensibilité pour l'association nom-surnom. Ce seront person_name_valuation et person_name_sensitivity . Le reste des champs est contrôlé par ces deux paires.
Une personne l'activité du club est autant leur intérêt que le Club 's. Par conséquent, nous ajouterons les mêmes champs d'importance à Membre et Officier .
Maintenant, nous pourrions ajouter person_importance champs à la Photo entité, mais regardez le photo_content colonne. Une photo peut impliquer plusieurs personnes, et cela fait partie de ce que nous stockons dans photo_content. Par conséquent, nous mettrons les champs d'importance sur photo_content. au lieu de sur Photo.
Le modèle "sensibilisé"
Nous avons modifié notre modèle de données pour attribuer une valeur et une sensibilité aux données partout où cela est nécessaire. Voici notre schéma final.
Nous avons pris soin d'éviter de déformer le schéma d'origine avec des relations ou des contraintes supplémentaires. Ceci est essentiel car nous considérons ce schéma comme une analyse précise des données réelles avec de vraies règles métier.
Il est difficile d'attacher une quelconque importance inhérente à vos données. C'est pire si vous essayez de l'appliquer à une base de données sans prise en charge dans le modèle ou le schéma. Cet article présente une technique pour joindre ces informations d'une manière qui ne déforme pas les parties métier intrinsèques du modèle.
La flexibilité et la possibilité de modification de Valeur et sensibilité sont des objectifs clés ici. Au fur et à mesure que vous commencerez à appliquer des valeurs réelles à ces attributs, vous constaterez que vous devez les modifier et revoir votre approche. C'est l'une des raisons pour attacher individuellement ces valeurs aux tables elles-mêmes, plutôt que de les avoir hors-bord. L'inconvénient est que cela devient assez compliqué, en raison des nombreux emplacements pour ces valeurs. Cela peut même apparaître dans la façon dont le modèle est utilisé. Nous aborderons la problématique multiforme de la gestion de la complexité en sécurité de l'information dans notre prochain article.
S'il vous plaît laissez vos commentaires ou critiques dans notre combox.
