Podejścia do bezpieczeństwa w modelowaniu danych. Część 3

Jest to trzecia z naszej wieloczęściowej serii poświęconej zastosowaniu podejścia do bezpieczeństwa informacji w modelowaniu danych. Seria wykorzystuje prosty model danych, coś do zarządzania klubami społecznościowymi i grupami zainteresowań, aby zapewnić treści, które chcemy zabezpieczyć. Później zajmiemy się modelowaniem pod kątem autoryzacji i zarządzania użytkownikami, a także innymi częściami bezpiecznej implementacji bazy danych.

W sytuacjach społecznych powszechne jest „czytanie między wierszami” – dedukowanie niewypowiedzianych założeń i twierdzeń w rozmowie. To samo dzieje się przy tworzeniu oprogramowania i przechowywaniu danych w bazie danych. Faktury są wyliczane z osadzonym identyfikatorem klienta, a ile jednostek danych używa daty i godziny jako części klucza? Trudno sobie wyobrazić dokładne udokumentowanie lub uporządkowanie wszystkiego bez jakiegoś przeoczenia. Ale w naszej ostatniej odsłonie przeszliśmy dokładnie przez to ćwiczenie. Udało nam się przypisać wrażliwość do kilku części naszej bazy danych klubu społecznościowego. Ale aby określić ilościowo i zarządzać tą wrażliwością, musimy rozszerzyć strukturę naszego modelu danych, aby dane wrażliwe i ich relacje były jasne.

Zamykanie luk w modelach danych

Modelowanie danych dla bezpieczeństwa wymaga kilku różnych odmian zmian struktury. Badamy je z kolei, używając (bardzo!) prostego modelu danych klubu społecznościowego jako bazy dla tej serii. W miarę postępów ulepszyliśmy model o więcej danych. W ostatniej części przeanalizowaliśmy model, aby przypisać wrażliwość danych tam, gdzie ją znaleźliśmy. Ta analiza również ujawniły, że istnieją miejsca, w których model danych wskazywał łącza, które nie zostały w rzeczywistości przechwycone w sposób wyraźny w kolumnach i kluczowych relacjach. Modelarz powinien tego oczekiwać w analizie bezpieczeństwa. Wychodząc od tych odkryć, uczynimy te relacje tak konkretnymi i przejrzystymi, jak to tylko możliwe, budując tabele i powiązania między nimi. Umożliwi nam to dalsze dołączenie atrybutów bezpieczeństwa.

Budowanie relacji danych w klubie

Wszystkie relacje w danych, a także same jednostki danych, muszą mieć jakąś reprezentację, aby przypisać im wartość lub wrażliwość. Aby to osiągnąć, mogą być potrzebne nowe kolumny, nowe klucze, nowe referencje, a nawet nowe tabele. Kiedy przeanalizowaliśmy tabele i ich relacje w naszym ostatnim poście, wyodrębniliśmy dwie główne tabele z danymi o wysokiej czułości:

• Person
• Photo

Ponadto mieliśmy cztery zawierające dane, które były umiarkowanie wrażliwe:

• Member
• Club
• Office
• Club_Office

Te aspekty wrażliwości są częściowo nierozerwalnie związane z każdą tabelą, ale niejednoznaczne relacje niosą ze sobą dużą wrażliwość. Aby go dołączyć, zaczynamy rejestrować relacje i nadajemy im strukturę, aby zawierała wrażliwość.

Relacje osadzone w zdjęciach

Photo zawiera wiele osadzonych relacji, które musimy uchwycić. Głównie interesuje nas relacja z Person . Aby uchwycić relację Osoba-Zdjęcie, dodaję Photo_Content tabela:

Istnieje wiele różnych aspektów, dzięki którym Person może odnosić się do Photo . Postanowiłem dodać nową tabelę, Photo_Content_Role , aby scharakteryzować związek zdjęcia z osobą. Zamiast mieć osobne tabele dla każdego rodzaju relacji, używamy pojedynczej tabeli łączącej i tabeli Photo_Content_Role. Ta tabela jest listą referencyjną ze standardowymi relacjami, takimi jak te, które już zauważyliśmy. Oto nasz początkowy zestaw danych dla Photo_Content_Role :

OK, więc to jest przynęta i zamiana. Powiedziałem Photo_Content odnosi się do ludzi do zdjęć, więc dlaczego jest coś o „przedmiotach przedstawionych”? Logicznie rzecz biorąc, będą zdjęcia, na których opiszemy treść bez identyfikowania osoby . Czy powinienem dodać do tego kolejną tabelę, z oddzielnym zestawem ról treści? Postanowiłem nie. Zamiast tego dodam pusty wiersz osoby do Person tabeli jako danych źródłowych, a zawartość nieosobowa odnosi się do tej osoby. (Tak, programiści, to trochę więcej pracy. Nie ma za co.) „Null Person” będzie miała id zero (0).

Kluczowa nauka nr 1:

Zminimalizuj tabele z danymi wrażliwymi, nakładając podobne struktury relacji w jedną tabelę.

Przewiduję, że mogą istnieć dodatkowe relacje, które zostaną odkryte w późniejszym okresie. Możliwe jest również, że klub towarzyski może mieć własne role, które można przypisać osobie w Zdjęciu . Z tego powodu użyłem „czystego” zastępczego klucza podstawowego dla Photo_Content_Role , a także dodał opcjonalny klucz obcy do Club . Umożliwi nam to wspieranie specjalnych zastosowań przez poszczególne kluby. Nazywam pole „na wyłączność”, aby wskazać, że nie powinno być dostępne dla innych klubów.

Kluczowe szkolenie nr 2:

Gdy użytkownicy końcowi mogą rozszerzyć wbudowaną listę, nadaj jej tabeli czysty klucz zastępczy, aby uniknąć kolizji danych.

Photo_Content_Role.max_per_person może być również tajemnicza. Nie widać tego na diagramie, ale Photo_Content_Role.id ma swoje własne, unikalne ograniczenie bez max_per_person . Zasadniczo, prawdziwy klucz podstawowy to po prostu id . Dodając max_per_person do id w kluczu podstawowym wymuszam, aby każda tabela referencyjna pobierała informacje, dzięki którym może (powinna!) wymusić ograniczenie sprawdzania liczności. Oto ograniczenie sprawdzania w Photo_Content .

Kluczowa nauka nr 3:

Gdy każdy wiersz tabeli ma indywidualne ograniczenia, tabele odsyłające muszą dodać nowe unikatowe ograniczenie, rozszerzając klucz naturalny o pola ograniczeń. Niech tabela potomna odwołuje się do tego klucza.

Przyjrzyjmy się dokładniej Photo_Content . Jest to przede wszystkim związek między Photo i Person , z relacją określoną przez dołączoną rolę zawartości. Jak już jednak wspomniałem, tutaj przechowujemy wszystko informacje opisowe o zdjęciu. Aby dostosować się do tego rodzaju otwartości, mamy opcjonalny content_headline i content_detailed kolumny. Rzadko będą one potrzebne do zwykłego powiązania Osoby ze Zdjęciem. Ale nagłówek taki jak „Bob Januskis odbiera nagrodę rocznych osiągnięć” jest łatwy do przewidzenia. Również jeśli nie ma osoby — „Przedmiot przedstawiony”, Osoba 0 — musimy wymagać czegoś w content_headline , na przykład „Północno-zachodnie zbocze góry Ararat”.

Ostatni brakujący związek ze zdjęciami:albumy

Jak dotąd nie dodaliśmy niczego, co dotyczy Photo s do Photo s. To wielka rzecz dla sieci społecznościowych i usług fotograficznych:Album s. I nie chciałbyś ich w przysłowiowym pudełku po butach, prawda? Wypełnijmy więc tę rażącą lukę – ale też o tym pomyślmy.

Album dołącza Photo w inny sposób niż inne relacje, które omówiliśmy. Photo s mogą być powiązane z tym samym klubem, podobną datą, pobliskimi współrzędnymi GPS, tym samym fotografem i tak dalej. Jednak Album wyraźnie wskazuje, że załączone Photo są częścią jednego tematu lub historii. W związku z tym aspekty związane z bezpieczeństwem jednego Photo można wywnioskować z innego w Album . Również kolejność może wzmacniać lub zmniejszać te wnioski. Więc nie myśl tylko o Album jako nieszkodliwa kolekcja. Powiązane Photo s jest niczym innym.

Chociaż nie jest nieszkodliwy z punktu widzenia bezpieczeństwa, Album jest prosta encja z czystym Id klucz zastępczy należący do Club (nie Person ). Album_Photo daje nam zestaw Photo s sekwencjonowane według Photo_Order . Zauważysz, że stworzyłem Album id i order klucz podstawowy. Związek jest naprawdę między Photo i Album , więc dlaczego nie ustawić ich jako klucza podstawowego? Ponieważ dziwne przypadki wymagające Photo powtarzać w Album są z pewnością możliwe. Więc umieszczam Photo_Order do klucza podstawowego i po pewnym namyśle zdecydowałem się dodać alternatywny klucz unikalny z albumem i zdjęciem, aby zapobiec Photo przed powtarzaniem w Album . Jeśli wystarczająco dużo płacze, aby powtórzyć Photo w Album powstają, unikalny klucz jest łatwiejszy do usunięcia niż klucz podstawowy.

Kluczowa nauka nr 4:

Dla klucza podstawowego wybierz klucz kandydujący o najmniejszym ryzyku późniejszego odrzucenia.

Metadane zdjęć

Ostatnią potencjalnie wrażliwą informacją do dodania są metadane (zwykle tworzone przez urządzenie, które wykonało zdjęcia). Te dane nie częścią związku, ale jest nieodłączną częścią zdjęcia. Podstawową definicją informacji, które aparat przechowuje ze zdjęciem, jest EXIF, standard branżowy z Japonii (JEITA). EXIF jest rozszerzalny i może obsługiwać dziesiątki lub setki pól, z których żadne nie może być wymagane w przesłanych przez nas obrazach. Ten status nie jest wymagany, ponieważ te pola nie są wspólne dla wszystkich formatów zdjęć i można je usunąć przed przesłaniem. Zbudowałem Photo z wieloma powszechnie używanymi polami, w tym:

• kamera_mfr
• model_kamery
• wersja_oprogramowania_kamery
• obraz_x_rozdzielczość
• obraz_y_rozdzielczość
• jednostka_rozdzielczości_obrazu
• image_exposure_time
• przysłona_kamery_f
• GPSLatitude
• GPS długość geograficzna
• Wysokość GPS

Pola GPS to oczywiście te, które dodają najwyższą czułość Photo .

Nasz model ze zdefiniowanymi wszystkimi wrażliwymi i cennymi danymi

Zakończyliśmy ten etap zabezpieczania bazy klubowej tymi zmianami. Wszystkie połączenia i potrzebne dodatkowe dane są obecne, jak pokazano poniżej. Zrobiłem Photo czerwone informacje i Album jasny turkus, aby przekazać moją ideę logicznych grupowań. Powiększanie elementów danych jest rzeczywiste, ale bardzo zminimalizowane.

Wniosek

Postawienie dowolnego modelu danych na dobrej stopie bezpieczeństwa wymaga uporządkowanego i systematycznego stosowania zasad bezpieczeństwa oraz praktyki w zakresie relacyjnych baz danych. W tej części przejrzeliśmy model danych i starannie uzupełniliśmy brakującą strukturę, która została dorozumiana, ale nie wyrażona w schemacie. Nie moglibyśmy przypisać wartości lub zapewnić ochrony istniejących danych bez dodania danych, które je wypełniają i poprawnie łączą. Mając to na uwadze, przystąpimy do dołączania elementów wyceny danych i wrażliwości danych, które pozwolą nam wyraźnie zobaczyć wszystkie dane z pełnego punktu widzenia bezpieczeństwa. Ale to jest w naszym następnym artykule.