sql >> Databáze >  >> RDS >> Database

Bezpečnostní přístupy v datovém modelování. Část 4

Toto je čtvrtá z naší vícedílné série o datovém modelování pro informační bezpečnost a datové charakteristiky. Jednoduchý datový model pro fiktivní web, který podporuje organizace se sdíleným zájmem (kluby pro pozorování ptáků atd.), nám poskytl obsah pro zkoumání datového modelování z hlediska bezpečnosti.

Ve hře Oscara Wilda Vějíř lady Windermere Lord Darlington označil cynika za „někoho, kdo zná cenu všeho a hodnotu ničeho“. Je smutné, že s informacemi v našich databázích lze nevědomky zacházet stejným způsobem. Stojí zákaznický účet za součet jeho nákupů? Co trpíme, když během vánoční nákupní sezóny ztratíme čtyři hodiny marketingových dat?

My datoví modeláři nebudeme provádět tato hodnocení, ale musíme ukládat jejich relevantní data jménem lidí, kteří tak učiní. Budeme muset vyplnit mezery v implicitní datové struktuře. V tomto článku uvidíme, jak přidat tento důležitý bezpečnostní prvek do naší databáze.

Ukaž mi peníze!

Jak moc bychom měli chránit každý datový objekt? Zvažte je ve světle Důvěrnosti , Integrita a Dostupnost — klíčové vlastnosti určující bezpečnost informačního systému. Musíme také počítat s rozdílem mezi těmito opatřeními na „vnitřní“ bázi a tím, do jaké míry mohou tato data ovlivnit bezpečnost.

Existují dva důvody, proč to udělat. Nejprve nám to pomůže zjistit, jak chránit data v naší klubové databázi. Měly by být některé tabulky šifrované? Vložit jiná schémata? Možná následně připojíme ovládací prvky virtuální soukromé databáze? Tyto informace nám pomohou vybrat vhodná ochranná opatření.

Zadruhé se zamyslíme nad daty z nezpracovaného účetního pohledu:Jaká je jejich celková hodnota? Co můžeme ztratit v případě poškození dat? Jaká je naše odpovědnost v případě zveřejnění osobních údajů? Když tyto informace přidáme do našeho schématu, přidáme k našim uloženým datům kritickou metriku:dolary a centy. To umožňuje lidem, kteří platí účty, určit, co si mohou dovolit za bezpečnost – – a v peněžním vyjádření, jakou cenu to má.

Všechny vztahy jsou vysvětleny

Pojďme si zrekapitulovat stav našeho modelu. Od posledního článku je datová struktura vyplněna. Jsou tam osoby, kluby, členství, fotky, alba a obsah. Jak se spojují, je tam. Toto schéma je připraveno ukládat data se vztahy explicitně zachycenými v celém textu, zatímco implicitní vztahy byly co nejvíce eliminovány.



Přiřazení hodnoty a citlivosti

Nyní zjistíme, jak vložit čísla do dat. Opravdu nemůžeme připojit jediný hodnotu datové položky, která nám říká, jak moc ji máme chránit. Nemůžeme – a ani nemusíme – jít do sbírky metrik. Zaměříme se na to, kolik nám může část dat vydělat a kolik nás může stát ztráta nebo zveřejnění těchto dat.

Používáme pro to termíny „hodnota“ a „citlivost“ – pozitivní a negativní měření, chcete-li. Hodnota je často zvažována z hlediska budoucí hodnoty nebo příležitosti. Citlivost je velmi obranná; týká se rizik na finanční úrovni (regulační nebo právní sankce) a ztráty pověsti nebo dobrého jména.

Ocenění přímo souvisí s integritou a Dostupnost . Budeme to posuzovat z hlediska toho, jaké výhody mohou data generovat nebo jak velká škoda bude způsobena v případě ztráty přístupu k nim. Citlivost řešíme především z hlediska Důvěrnosti , která musí být měřena škodou nebo odpovědností, pokud je odhalena.

Společná struktura oceňování a citlivosti

Nyní se podívejme na ocenění a citlivost vůči naší databázi. Když se znovu podíváme na datový model, zjistíme, že tyto vlastnosti jsou relativní pouze ke klubu nebo osobě. Klub nebo člověk těží z hodnoty něčeho a trpí, když se něco citlivého dostane na veřejnost. Proto je každé z těchto hodnocení zachyceno s ohledem na klub nebo osobu. když se podíváme na naše datové entity, zajistíme, že každá, která má hodnotu (přínos), s sebou nese také citlivost (riziko) a naopak. Takže každá zúčastněná entita bude mít obě, samostatná pole Ocenění a Citlivost. Ve většině případů budou volitelné nebo výchozí. Obojí bude také váženo v penězích:v hodnotě měny s přesností na setiny amerického dolaru. (V zájmu srozumitelnosti budeme používat pouze jednu měnu.) Oslavte to nebo naříkejte, peníze jsou naší jedinou použitelnou metrikou pro obě. Abychom využili této společné vlastnosti, budeme je nazývat „Důležitost“.

Jako datoví modeláři na to ve skutečnosti nemůžeme sami dát čísla. Ani jako provozovatel webu nebo databáze nevíme dost, abychom tyto hodnoty přiřadili; kromě toho data nejsou úplně naše. U dat, která jsou specifická pro klub, musíme nechat tento klub přiřadit své vlastní úrovně důležitosti a její pravidla pro používání těchto úrovní. Poté aplikujeme jejich pravidla na jejich data.

Začněme s typy entit, které mohou kluby přiřadit.

Klubová data

Subjekty klubu jsou:

  • Klub
  • Klubová_kancelář
  • Důstojník
  • Člen
  • Album
  • Album_Photo
  • Fotografie

Přidáme Valuation a Sensitivity sloupců ke každému z nich. Protože tyto sloupce jsou připojeny ke klubu , jejich názvy jsou specifické – např. club_sensitivity .

Zde je naše sada tabulek pro klub , včetně Osoba :



Osobní údaje

Nyní musíme oslovit Person entita. Opět zde hodnoty nepřiřazujeme – to je výsada člověka. Do pole Osoba samozřejmě musíme přidat sloupce Důležitost . Ale abychom lépe podpořili osobní soukromí, nakrájíme tuto entitu jemněji. Koneckonců, soukromí je klíčem k citlivosti dat.

Nejprve přidáme nový sloupec s názvem monicker to je jako uživatelské jméno nebo alias. Členové klubu to mohou použít k identifikaci spíše než jejich skutečná jména. Poskytneme pár sloupců ocenění/citlivost pro asociaci jméno-přezdívka. Budou to person_name_valuation a person_name_sensitivity . Zbytek polí je řízen těmito dvěma páry.

Osoba klubová činnost je jejich zájmem stejně jako klub s. Proto do pole Člen přidáme stejná pole Důležitost a Důstojník .

Nyní bychom mohli přidat person_importance polí do Fotografie entity, ale podívejte se na obsah_fotky sloupec. Fotografie může zahrnovat více osob a to je součástí toho, co ukládáme do photo_content. Proto vložíme pole důležitosti na photo_content. místo na fotografii.

Model „Senzibilizace“

Upravili jsme náš datový model, abychom připisovali hodnotu dat a citlivost dat všude, kde je to potřeba. Toto je naše konečné schéma.

Dávali jsme pozor, abychom předešli zkreslení původního schématu dalšími vztahy nebo omezeními. To je zásadní, protože toto schéma bereme jako přesnou analýzu skutečných dat se skutečnými obchodními pravidly.




Přiřadit vašim datům jakýkoli druh přirozené důležitosti je obtížné. Horší je, když se jej pokoušíte aplikovat na databázi bez podpory v modelu nebo schématu. Tento článek demonstruje techniku ​​připojení těchto informací způsobem, který nezkresluje vnitřní obchodní části modelu.

Flexibilita a modifikovatelnost Hodnoty a Citlivost jsou zde klíčové cíle. Jakmile začnete na tyto atributy aplikovat skutečné hodnoty, zjistíte, že je potřebujete upravit a přehodnotit svůj přístup. To je jeden z důvodů, proč tyto hodnoty jednotlivě připojovat k samotným tabulkám, spíše než je mít mimo palubu. Nevýhodou je, že se to docela komplikuje kvůli mnoha umístěním pro tyto hodnoty. To se může projevit i v tom, jak se model používá. Mnohostranné problematice řízení složitosti v informační bezpečnosti se budeme věnovat v našem dalším článku.

Zanechte prosím jakékoli komentáře nebo kritiku v našem comboxu.


  1. Salesforce SOQL ze serveru SQL Server

  2. T-SQL:Výběr sloupce na základě MAX (jiný sloupec)

  3. Rozbalovací nabídka přístupu TreeView ImageCombo

  4. Jak odesílat e-maily pomocí Oracle 10 g Forms