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

Toto je třetí z naší vícedílné série o aplikaci přístupů k informační bezpečnosti při modelování dat. Série používá jednoduchý datový model, něco ke správě sociálních klubů a zájmových skupin, k poskytování obsahu, který chceme zabezpečit. Později se budeme zabývat modelováním pro autorizaci a správu uživatelů a také dalšími částmi implementace zabezpečené databáze.

V sociálních situacích je běžné „číst mezi řádky“ – vyvozovat nevyřčené domněnky a tvrzení v rozhovoru. Totéž se děje při vytváření softwaru a ukládání dat do databáze. Faktury jsou vyčísleny s vloženým ID zákazníka a kolik datových entit používá datum a čas jako součást klíče? Je těžké si představit důkladné zdokumentování nebo strukturování všeho bez nějakého typu opomenutí. Ale v našem posledním díle jsme prošli přesně tímto cvičením. Podařilo se nám připsat citlivost několika částem naší databáze sociálních klubů. Abychom však tuto citlivost kvantifikovali a řídili, musíme rozšířit strukturu našeho datového modelu, aby byla citlivá data a jejich vztahy jasné.

Uzavření mezer v datovém modelu

Datové modelování pro zabezpečení vyžaduje několik různých typů změn struktury. Postupně je zkoumáme pomocí (velmi!) jednoduchého datového modelu sociálního klubu jako našeho základu pro tuto sérii. Jak jsme postupovali, vylepšili jsme model o další data. V minulém díle jsme analyzovali model, abychom připsali citlivost dat tam, kde jsme ji našli. Tato analýza také odhalil, že existovala místa, kde datový model indikoval odkazy, které ve skutečnosti nebyly explicitně zachyceny ve sloupcích a klíčových vztazích. Modelář by to měl očekávat v bezpečnostní analýze. Pokročíme-li vpřed od těchto objevů, uděláme tyto vztahy co nejkonkrétnější a nejjasnější tím, že vytvoříme tabulky a propojení mezi nimi. To nám umožní dále připojit bezpečnostní atributy.

Vytváření datových vztahů v klubu

Všechny vztahy v datech, stejně jako samotné datové entity, musí mít nějakou reprezentaci, aby jim byla připsána hodnota nebo citlivost. K tomu mohou být potřeba nové sloupce, nové klíče, nové odkazy, dokonce i nové tabulky. Když jsme analyzovali tabulky a jejich vztahy v našem posledním příspěvku, izolovali jsme dvě hlavní tabulky s vysoce citlivými daty:

• Person
• Photo

Kromě toho jsme měli čtyři obsahující data, která byla středně citlivá:

• Member
• Club
• Office
• Club_Office

Tyto aspekty citlivosti jsou částečně vlastní každé tabulce, ale neexplicitní vztahy nesou velkou část citlivosti. Abychom to připojili, začneme zaznamenávat vztahy a dáme jim strukturu, která obsahuje citlivost.

Vztahy vložené do fotografií

Photo obsahuje spoustu vložených vztahů, které musíme zachytit. Nás zajímá především vztah s Person . Abych zachytil vztah mezi osobou a fotografií, přidávám Photo_Content tabulka:

Existuje mnoho různých aspektů, podle kterých Person může souviset s Photo . Rozhodl jsem se přidat novou tabulku Photo_Content_Role , charakterizovat vztah fotografie k osobě. Namísto samostatných tabulek pro každý druh vztahu používáme jednu spojovací tabulku a tabulku Photo_Content_Role. Tato tabulka je referenční seznam se standardními vztahy, jako jsme si již poznamenali. Zde je naše počáteční sada dat pro Photo_Content_Role :

Dobře, takže tohle je návnada a vypínač. Řekl jsem Photo_Content by se týkala lidí k fotkám, tak proč je tam něco o „objektu zobrazeném“? Logicky se objeví fotografie, kde bychom obsah popsali bez identifikace Osoby . Mám k tomu přidat další tabulku, se samostatnou sadou obsahových rolí? Rozhodl jsem se, že ne. Místo toho přidám do Person tabulky jako výchozí data a obsah, který není osobou, odkazuje na tuto osobu. (Ano, programátoři, je to trochu více práce. Nemáte zač.) ‚Nulová osoba‘ bude mít id nula (0).

Klíčové učení č. 1:

Minimalizujte tabulky s citlivými daty překrytím podobných struktur vztahů do jediné tabulky.

Předpokládám, že mohou existovat další vztahy, které budou objeveny po proudu. A je také možné, že společenský klub může mít své vlastní role, které přisoudí osobě na fotce . Z tohoto důvodu jsem pro Photo_Content_Role a také přidal volitelný cizí klíč do Club . To nám umožní podporovat speciální využití jednotlivými kluby. Pole nazývám „exkluzivní“, abych naznačil, že by nemělo být dostupné jiným klubům.

Klíčové učení č. 2:

Když koncoví uživatelé mohou rozšířit vestavěný seznam, dejte jeho tabulce čistě náhradní klíč, abyste předešli kolizím dat.

Photo_Content_Role.max_per_person může být také tajemný. Na diagramu to není vidět, ale Photo_Content_Role.id má své vlastní jedinečné omezení bez max_per_person . V podstatě je skutečný primární klíč pouze id . Přidáním max_per_person na id v primárním klíči nutím každou odkazující tabulku, aby přijala informace, pomocí kterých může (měla by!) vynutit omezení kontroly mohutnosti. Zde je kontrolní omezení v Photo_Content .

Klíčové učení č. 3:

Pokud má každý řádek tabulky individuální omezení, musí odkazující tabulky přidat nové jedinečné omezení, které rozšiřuje přirozený klíč o pole omezení. Nechte podřízenou tabulku odkazovat na tento klíč.

Podívejme se více na Photo_Content . Jde především o vztah mezi Photo a Person , se vztahem určeným připojenou rolí obsahu. Jak jsem však poznamenal dříve, zde ukládáme vše popisné informace o fotografii. Abychom vyhověli tomuto druhu otevřenosti, máme volitelný content_headline a content_detailed sloupců. Ty budou zřídkakdy potřeba pro běžné spojení mezi osobou a fotografií. Ale titulek jako „Bob Januskis dostává výroční cenu za úspěch“ lze snadno předvídat. Také v případě, že neexistuje žádná osoba – „Object Depiced“, Osoba 0 — musíme vyžadovat něco v content_headline , jako například ‚Severozápadní svah hory Ararat.‘

Vztah poslední chybějící fotografie:Alba

Zatím jsme nepřidali nic, co by se týkalo Photo s na Photo s. Pro sociální sítě a fotografické služby je to velká věc:Album s. A v příslovečném botníku byste je nechtěli, že? Pojďme tedy vyplnit tuto do očí bijící mezeru – ale zamysleme se nad tím také.

Album přikládá Photo jsou jiným způsobem než ostatní vztahy, které jsme probrali. Photo s mohou být spojeny stejným klubem, podobným datem, blízkými GPS souřadnicemi, stejným fotografem a tak dále. Nicméně Album jasně označuje, že přiložená Photo s jsou součástí jednoho tématu nebo příběhu. Bezpečnostní aspekty jedné Photo může být odvozeno z jiného v Album . Také řazení může tyto závěry zesílit nebo zmenšit. Nemyslete tedy jen na Album jako neškodná sbírka. Související Photo s je cokoliv jiného než.

Ačkoli z hlediska zabezpečení není neškodné, Album je přímočará entita s čistým Id náhradní klíč vlastněný Club (nikoli Person ). Album_Photo nám poskytuje sadu Photo s sekvenováno podle Photo_Order . Všimnete si, že jsem vytvořil Album id a order primární klíč. Vztah je skutečně mezi Photo a Album , tak proč z nich neudělat primární klíč? Protože zvláštní případy vyžadují Photo opakovat v Album jsou jistě možné. Vložil jsem tedy Photo_Order do primárního klíče a po chvíli přemýšlení se rozhodl přidat alternativní jedinečný klíč s albem a fotografií, aby se zabránilo Photo z opakování v Album . Pokud dost pláče pro opakování Photo v Album jedinečný klíč je snazší odstranit než primární klíč.

Klíčové učení č. 4:

Pro primární klíč vyberte kandidátský klíč s nejmenším rizikem, že bude později vyhozen.

Metadata fotek

Poslední potenciálně citlivou informací, kterou je třeba přidat, jsou metadata (obvykle vytvořená jakýmkoli zařízením, které fotografie pořídilo). Tato data nejsou součástí vztahu, ale je vlastní fotografii. Primární definice informací, které fotoaparát ukládá s fotografií, je EXIF, průmyslový standard z Japonska (JEITA). EXIF je rozšiřitelný a může podporovat desítky nebo stovky polí, z nichž žádné nelze vyžadovat od našich nahraných obrázků. Tento stav není povinný, protože tato pole nejsou společná pro všechny formáty fotografií a lze je před odesláním vymazat. Vytvořil jsem Photo s mnoha běžně používanými poli, včetně:

• camera_mfr
• model_fotoaparátu
• verze_softwaru_fotoaparátu
• image_x_resolution
• image_y_resolution
• image_resolution_unit
• image_exposure_time
• camera_aperture_f
• GPSLatitude
• GPSL délka
• Výška GPS

Pole GPS jsou přirozeně ta, která dodávají Photo .

Náš model s definovanými všemi citlivými a cennými daty

Těmito změnami završujeme tuto fázi zabezpečení klubové databáze. Jsou k dispozici všechna potřebná připojení a další údaje, jak je znázorněno níže. Vytvořil jsem Photo informační červená a Album světle tyrkysová pro vyjádření mé představy o logických seskupení. Rozšíření datových prvků je skutečné, ale velmi minimalizované.

Závěr

Postavení jakéhokoli datového modelu na dobrý bezpečnostní základ vyžaduje řádnou a systematickou aplikaci bezpečnostních principů a také praxi relačních databází. V tomto díle jsme zkontrolovali datový model a pečlivě doplnili chybějící strukturu, která byla implikována, ale nebyla vyjádřena ve schématu. Nebylo možné přiřadit hodnotu nebo poskytnout ochranu existujícím datům, aniž bychom přidali data, která je vyplňují a správně je spojují. S tímto na místě přistoupíme k připojení prvků hodnocení dat a citlivosti dat, které nám umožní jasně vidět všechna data z úplného bezpečnostního hlediska. Ale to je v našem dalším článku.