Подходи за сигурност в моделирането на данни. част 3

Това е третата от нашата серия от много части за прилагане на подходи за информационна сигурност към моделиране на данни. Серията използва прост модел на данни, нещо за управление на социални клубове и групи по интереси, за да предостави съдържанието, което се стремим да осигурим. По-късно ще разгледаме моделирането за оторизация и управление на потребителите, както и други части от внедряването на защитена база данни.

В социални ситуации е обичайно да се „чете между редовете“ – извеждане на неизказаните предположения и твърдения в разговор. Същото се случва при създаването на софтуер и съхраняването на данни в база данни. Фактурите се изброяват с вграден идентификатор на клиента и колко обекта на данни използват дата-час като част от ключа? Трудно е да си представим задълбочено документиране или структуриране на всичко без някакъв вид пропуск. Но в последната ни част преминахме точно през това упражнение. Успяхме да припишем чувствителност на няколко части от нашата база данни на социалните клубове. Но за да определим количествено и управляваме тази чувствителност, трябва да увеличим структурата на нашия модел на данни, за да направим чувствителните данни и техните взаимоотношения ясни.

Затваряне на пропуските в модела на данни

Моделирането на данни за сигурност изисква няколко различни разновидности на промени в структурата. Ние ги изследваме на свой ред, като използваме (много!) прост модел на данни за социални клубове като наша база за тази серия. Докато продължихме, подобрихме модела с повече данни. В последната част анализирахме модела, за да припишем чувствителността на данните там, където го намерихме. Този анализ също разкри, че има места, където моделът на данни показва връзки, които всъщност не са били уловени изрично в колони и ключови връзки. Разработчикът на модели трябва да очаква това при анализ на сигурността. Продължавайки напред от тези открития, ние ще направим тези връзки възможно най-конкретни и ясни, като изградим таблиците и връзките между тях. Това ще ни позволи да прикачим по-нататък атрибути за сигурност.

Изграждане на връзките с данни в клуба

Всички връзки в данните, както и самите обекти на данни, трябва да имат някакво представяне, за да им се припише стойност или чувствителност. Може да са необходими нови колони, нови ключове, нови препратки, дори нови таблици, за да се постигне това. Когато анализирахме таблиците и техните връзки в последната ни публикация, изолирахме две основни таблици с данни с висока чувствителност:

• Person
• Photo

Освен това имахме четири, съдържащи данни, които бяха умерено чувствителни:

• Member
• Club
• Office
• Club_Office

Тези аспекти на чувствителността са отчасти присъщи на всяка таблица, но неявните връзки носят голяма част от чувствителността. За да го прикачим, започваме да записваме връзките и им даваме структура, която да съдържа чувствителността.

Взаимоотношения, вградени в снимки

Photo съдържа много вградени връзки, които трябва да уловим. Най-вече ни интересуват отношенията с Person . За да заснема връзката човек-снимка, добавям Photo_Content таблица:

Има много различни аспекти, чрез които Person може да се отнася до Photo . Реших да добавя нова таблица, Photo_Content_Role , за да характеризира връзката на снимка с човек. Вместо да имаме отделни таблици за всеки вид връзка, ние използваме една свързваща таблица и таблицата Photo_Content_Role. Тази таблица е референтен списък със стандартни връзки като това, което вече отбелязахме. Ето нашия първоначален набор от данни за Photo_Content_Role :

Добре, значи това е примамка и превключване. Казах Photo_Content ще се свърже с хора към снимки, така че защо има нещо за „изобразен обект“? Логично ще има снимки, на които ще опишем съдържанието, без да идентифицираме Лице . Трябва ли да добавя друга таблица за това, с отделен набор от роли на съдържанието? Реших не. Вместо това ще добавя нулев ред с лице към Person таблица като начални данни и имат съдържание, което не е лице, отнасящо се до това лице. (Да, програмисти, това е малко повече работа. Добре дошъл.) „null Person“ ще има id нула (0).

Ключово обучение № 1:

Намалете таблиците с чувствителни данни чрез наслагване на подобни структури на връзки в една таблица.

Предполагам, че може да има допълнителни връзки, които ще бъдат открити надолу по веригата. Освен това е възможно социалният клуб да има свои собствени роли, които да приписва на Лице в снимка . Поради тази причина използвах „чист“ сурогатен първичен ключ за Photo_Content_Role , а също така добави незадължителен външен ключ към Club . Това ще ни позволи да поддържаме специални употреби от отделни клубове. Наричам полето „изключително“, за да покажа, че не трябва да е достъпно за други клубове.

Ключово обучение № 2:

Когато крайните потребители могат да разширят вграден списък, дайте на неговата таблица чист сурогатен ключ, за да избегнете сблъсъци на данни.

Photo_Content_Role.max_per_person може също да е мистериозен. Не можете да го видите на диаграмата, но Photo_Content_Role.id носи свое собствено уникално ограничение без max_per_person . По същество истинският първичен ключ е просто id . Като добавите max_per_person към id в първичния ключ принуждавам всяка препращаща таблица да приема информация, чрез която може (трябва!) да наложи ограничение за проверка на мощността. Ето ограничението за проверка в Photo_Content .

Ключово обучение № 3:

Когато всеки ред от таблица има индивидуални ограничения, препращащите таблици трябва да добавят ново уникално ограничение, разширявайки естествен ключ с полетата за ограничения. Нека дъщерната таблица се отнася към този ключ.

Нека разгледаме още Photo_Content . Това е преди всичко връзка между Photo и Person , с връзката, посочена от прикачената роля за съдържание. Както отбелязах преди обаче, тук съхраняваме всички описателна информация за снимката. За да посрещнем този вид отвореност, имаме незадължителния content_headline и content_detailed колони. Те рядко ще са необходими за обикновена асоциация между Човек и Снимка. Но заглавие като „Боб Янускис получава годишната награда за постижения“ е лесно да се предвиди. Също така, ако няма лице — „Изобразен обект“, Лице 0 — трябва да изискваме нещо в content_headline , като например „Северозападен склон на връх Арарат.“

Последната липсваща снимка:Албуми

Досега не сме добавили нищо, свързано с Photo s към Photo с. Това е голямо нещо за социалните мрежи и фото услугите:Album с. И не бихте ги искали в пословичната кутия за обувки, нали? Така че нека запълним тази крещяща празнина – но нека помислим и за нея.

Album прикачва Photo е по различен начин от другите взаимоотношения, които сме обхванали. Photo s може да бъде свързан със същия клуб, подобна дата, близки GPS координати, един и същ фотограф и т.н. Въпреки това, Album ясно показва, че приложената Photo са част от една тема или история. Като такива, свързани със сигурността аспекти на една Photo може да бъде изведен от друг в Album . Освен това подреждането може да засили или намали тези изводи. Така че не мислете само за Album като безобидна колекция. Свързана Photo s е всичко друго, но не.

Въпреки че не е безобиден от гледна точка на сигурността, Album е ясен обект с чист Id сурогатен ключ, собственост на Club (не е Person ). Album_Photo ни дава набор от Photo с последователност от Photo_Order . Ще забележите, че направих Album id и order първичния ключ. Връзката наистина е между Photo и Album , така че защо да не ги направим първичен ключ? Тъй като странни случаи изискват Photo за повторение в Album със сигурност са възможни. Затова поставих Photo_Order в първичния ключ и след известно мислене реших да добавим алтернативен уникален ключ с албум и снимка, за да предотвратим Photo от повторение в Album . Ако достатъчно викове за повтаряне на Photo в Album ако възникне, уникален ключ е по-лесен за премахване, отколкото първичен ключ.

Ключово обучение № 4:

За първичен ключ изберете кандидат-ключ с най-малък риск да бъде изхвърлен по-късно.

Метаданни за снимки

Последната потенциално чувствителна информация за добавяне са метаданните (обикновено създадени от каквото и устройство да е направило снимките). Тези данни не част от една връзка, но е присъща на снимката. Основната дефиниция на информацията, която камерата съхранява със снимка е EXIF, индустриален стандарт от Япония (JEITA). EXIF е разширяем и може да поддържа десетки или стотици полета, нито едно от които не може да се изисква от нашите качени изображения. Това незадължително състояние е, защото тези полета не са общи за всички формати на снимки и могат да бъдат изтрити преди качване. Изградих Photo с много често използвани полета, включително:

• camera_mfr
• модел_камера
• camera_software_version
• image_x_resolution
• image_y_resolution
• единица_резолюция_изображение
• image_exposure_time
• camera_aperture_f
• GPSLLatitude
• GPSLдължина
• GPSA надморска височина

GPS полетата, естествено, са тези, които добавят най-висока чувствителност към Photo .

Нашият модел с дефинирани всички чувствителни и ценни данни

Завършваме тази фаза на осигуряване на клубната база данни с тези промени. Налице са всички необходими връзки и допълнителни данни, както е показано по-долу. Направих Photo информация червено и Album светло тюркоазено, за да предам идеята си за логически групировки. Увеличаването на елементите от данни е реално, но много сведено до минимум.

Заключение

Поставянето на всеки модел на данни на добра основа за сигурност изисква подредено и систематично прилагане на принципите за сигурност, както и практика на релационна база данни. В тази част прегледахме модела на данни и внимателно попълнихме липсващата структура, която се подразбираше, но не беше изразена в схемата. Не бихме могли да присвоим стойност или да осигурим защита на съществуващите данни, без да добавим данните, които ги попълват и правилно ги свързват заедно. След като това е налице, ще продължим да прикрепяме елементите за оценка на данните и чувствителността на данните, които ще ни позволят да видим ясно всички данни от пълна гледна точка на сигурността. Но това е в следващата ни статия.