Това е четвъртото в нашата серия от много части за моделиране на данни за информационна сигурност, както и характеристики на данните. Един прост модел на данни за измислен уебсайт, който поддържа организации със споделени интереси (клубове за наблюдение на птици и т.н.), ни предостави съдържание за изследване на моделирането на данни от гледна точка на сигурността.
В пиесата на Оскар Уайлд Вентилаторът на лейди Уиндърмиър лорд Дарлингтън маркира циника като „някой, който знае цената на всичко и стойността на нищо“. За съжаление информацията в нашите бази данни може да бъде несъзнателно третирана по същия начин. Струва ли си клиентската сметка сумата от покупките му? Какво страдаме, ако загубим четири часа маркетингови данни по време на празничния сезон на пазаруване?
Ние, разработчиците на модели на данни, няма да правим тези оценки, но трябва да съхраняваме съответните им данни от името на хората, които го правят. Ще трябва да запълним празнините на имплицитната структура на данните. В тази статия ще видим как да добавим този важен елемент за сигурност към нашата база данни.
Покажи ми парите!
Колко трябва да защитаваме всеки обект на данни? Разгледайте ги в светлината на Поверителност , Цялост и Наличност — ключовите качества, определящи сигурността на информационната система. Трябва също да вземем предвид разликата между тези мерки на „присъща“ основа и доколко тези данни могат да повлияят на сигурността.
Има две причини да направите това. Първо, това ще ни помогне да видим как да защитим данните в нашата клубна база данни. Трябва ли някои таблици да бъдат криптирани? Да се сложат други схеми? Може би надолу по веригата ще прикачим контроли за виртуална частна база данни? Тази информация ще ни помогне да изберем подходящи предпазни мерки.
Второ, ще обмислим данните от необработена счетоводна гледна точка:каква е общата им стойност? Какво можем да загубим в случай на повреда на данните? Каква е нашата отговорност, ако личните данни бъдат разкрити? Когато добавим тази информация към нашата схема, ние добавяме критичен показател към нашите съхранени данни:долари и центове. Това позволява на хората, които плащат сметките, да определят какво могат да си позволят за сигурност ––– и в парична гледна точка колко струва.
Всички връзки са описани
Нека обобщим състоянието на нашия модел. Към последната статия структурата на данните е попълнена. Лица, клубове, членство, снимки, албуми и съдържание са там. Как се връзват заедно е там. Тази схема е готова да съхранява данни с връзките, изрично уловени навсякъде, докато имплицитните връзки са елиминирани, доколкото е възможно.
Приписване на стойност и чувствителност
Сега ще разберем как да поставим числа в данните. Наистина не можем да прикачим единичен стойност на елемент от данни, който ни казва колко да го защитим. Въпреки това, ние не можем - и не е необходимо - да влезем в колекция от показатели. Ще се съсредоточим върху това колко част от данни може да спечели за нас и колко може да ни струва загубата или разкриването на тези данни.
Ние използваме термините „стойност” и „чувствителност” за това – положително и отрицателно измерване, ако желаете. Стойността често се разглежда от гледна точка на бъдеща стойност или възможност. Чувствителността е много отбранителна; той се отнася до рискове на финансово ниво (регулаторни или законови санкции) и при загуба на репутация или репутация.
Оценяването е пряко свързано с Интегритет и Наличност . Ще преценим това по отношение на това какви ползи могат да генерират данните или колко щети ще бъдат нанесени, ако достъпът до тях бъде загубен. Ние се занимаваме с чувствителността основно по отношение на Поверителност , което трябва да се измерва с щетите или отговорността, ако бъдат разкрити.
Общата структура на оценка и чувствителност
Сега нека разгледаме оценката и чувствителността спрямо нашата база данни. Когато разглеждаме отново модела на данните, откриваме, че тези качества са относителни само за клуб или човек. Клуб или човек се възползват от стойността на нещо и страдат, когато нещо чувствително се оповести публично. Следователно всяка една от тези оценки се улавя по отношение на клуб или човек. докато разглеждаме нашите обекти от данни, ще гарантираме, че всеки от тях, който има стойност (полза), също носи чувствителност (риск) и обратно. Така че всеки участващ субект ще има и двете, отделни полета за оценка и чувствителност. В повечето случаи те ще бъдат по избор или по подразбиране. Освен това и двете ще бъдат претеглени по отношение на парите:валутна стойност, точна до стотни от един щатски долар. (За по-голяма яснота ще използваме само една валута.) Празнувайте го или се оплаквайте, парите са единственият ни използваем показател за двете. За да използваме тази общност, ще ги наречем „Важност“.
Като разработчици на данни, ние всъщност не можем да поставим числа върху това сами. Дори като оператор на сайт или база данни, ние не знаем достатъчно, за да присвоим тези стойности; освен това данните не са изцяло наши. За данни, които са специфични за даден клуб, трябва да позволим на този клуб да присвои свои нива на важност и правилата за използване на тези нива. След това прилагаме техните правила към техните данни.
Нека започнем с типовете субекти, които клубовете могат да присвояват.
Клубни данни
Клубните субекти са:
- Клуб
- Club_Office
- Офицер
- Член
- Албум
- Снимка на албума
- Снимка
Ще добавим Valuation и Sensitivity колони към всяка от тях. Тъй като тези колони са прикрепени към Клуба , имената им са специфични – напр. club_sensitivity .
Ето нашия набор от фокусни таблици за Клуб , включително Лице :
Лични данни
Сега трябва да се обърнем към Person субект. Тук отново не приписваме стойностите – това е прерогатив на човека. Естествено, трябва да добавим колони за важност към Лице . Но за да подкрепим по-добре личната неприкосновеност на личния живот, ще нарежем този обект по-фино. В крайна сметка поверителността е ключът към чувствителността на данните.
Първо, ще добавим нова колона, наречена monicker това е като потребителско име или псевдоним. Членовете на клуба могат да използват това за идентификация, а не действителните си имена. Ще предоставим двойка колони оценка/чувствителност за асоциацията име-моник. Това ще бъде person_name_valuation и person_name_sensitivity . Останалите полета се контролират от тези две двойки.
Алице Клубната дейност на тях е толкова интересна, колкото и Клуба 'с. Затова ще добавим същите полета за важност към Член и Офицер .
Сега бихме могли да добавим person_importance полета към Снимка обект, но вижте photo_content колона. Една снимка може да включва няколко души и това е част от това, което съхраняваме в photo_content. Затова ще поставим полетата за важност на photo_content. вместо на снимка.
Моделът „Сенсибилизиран“
Модифицирахме нашия модел на данни, за да припишем стойност на данните и чувствителност на данните навсякъде, където е необходимо. Следва нашата окончателна схема.
Внимаваме да избегнем изкривяване на оригиналната схема с допълнителни връзки или ограничения. Това е от решаващо значение, защото ние приемаме тази схема като точен анализ на реалните данни с реални бизнес правила.
Придаването на всякакъв вид присъщо значение на вашите данни е трудно. По-лошо е, ако се опитвате да го приложите към база данни без поддръжка в модела или схемата. Тази статия демонстрира техника за прикачване на тази информация по начин, който не изкривява присъщите бизнес части на модела.
Гъвкавостта и възможността за промяна на Стойност и Чувствителност са ключовите цели тук. Когато започнете да прилагате реални стойности към тези атрибути, ще откриете, че трябва да ги модифицирате и да преразгледате подхода си. Това е една от причините индивидуално да прикачите тези стойности към самите таблици, вместо да ги държите извън борда. Недостатъкът е, че става доста сложно, поради многото места за тези стойности. Това може дори да се прояви в начина, по който се използва моделът. Ще разгледаме многостранния въпрос за управлението на сложността в информационната сигурност в следващата ни статия.
Моля, оставете всякакви коментари или критики в нашия списък.
