Beveiligingsbenaderingen in gegevensmodellering. Deel 3

Dit is de derde van onze meerdelige serie over het toepassen van informatiebeveiligingsbenaderingen op gegevensmodellering. De serie gebruikt een eenvoudig gegevensmodel, iets om sociale clubs en belangengroepen te beheren, om de inhoud te bieden die we willen beveiligen. Later zullen we ingaan op modellering voor autorisatie en gebruikersbeheer, evenals op andere delen van een veilige database-implementatie.

In sociale situaties is het gebruikelijk om "tussen de regels door te lezen" - de onuitgesproken aannames en beweringen in een gesprek af te leiden. Hetzelfde gebeurt bij het maken van software en het opslaan van gegevens in een database. Facturen worden geteld met de klant-ID ingesloten, en hoeveel gegevensentiteiten gebruiken een datum-tijd als onderdeel van de sleutel? Het is moeilijk voor te stellen alles grondig te documenteren of te structureren zonder enige vorm van weglating. Maar in onze laatste aflevering hebben we precies die oefening doorgemaakt. We waren in staat om gevoeligheid toe te schrijven aan verschillende delen van onze sociale clubdatabase. Maar om die gevoeligheid te kwantificeren en te beheersen, moeten we de structuur van ons datamodel vergroten om de gevoelige data en de relaties ervan duidelijk te maken.

Hiaten in gegevensmodel dichten

Gegevensmodellering voor beveiliging vereist verschillende verschillende soorten structuurveranderingen. We onderzoeken deze achtereenvolgens, met behulp van een (zeer!) eenvoudig gegevensmodel voor sociale clubs als basis voor deze serie. Naarmate we verder gingen, hebben we het model uitgebreid met meer gegevens. In de laatste aflevering hebben we het model geanalyseerd om gegevensgevoeligheid toe te schrijven waar we het vonden. Deze analyse ook onthulde dat er plaatsen waren waar het datamodel koppelingen aangaf die niet echt expliciet in kolommen en sleutelrelaties waren vastgelegd. De modelleur mag dit verwachten bij een beveiligingsanalyse. Vanuit deze ontdekkingen zullen we deze relaties zo concreet en duidelijk mogelijk maken door de tabellen en de verbanden daartussen uit te bouwen. Hierdoor kunnen we verderop beveiligingskenmerken toevoegen.

De gegevensrelaties in de club uitbouwen

Alle relaties in de gegevens, evenals de gegevensentiteiten zelf, moeten enige representatie hebben om er waarde of gevoeligheid aan toe te kennen. Nieuwe kolommen, nieuwe sleutels, nieuwe verwijzingen, zelfs nieuwe tabellen kunnen nodig zijn om dit te bereiken. Toen we de tabellen en hun relaties in ons laatste bericht analyseerden, hebben we twee hoofdtabellen geïsoleerd met zeer gevoelige gegevens:

• Person
• Photo

Daarnaast hadden we er vier met gegevens die redelijk gevoelig waren:

• Member
• Club
• Office
• Club_Office

Deze aspecten van gevoeligheid zijn deels intrinsiek aan elke tabel, maar niet-expliciete relaties dragen een groot deel van de gevoeligheid. Om het toe te voegen, beginnen we de relaties vast te leggen en ze een structuur te geven om de gevoeligheid te bevatten.

Relaties ingebed in foto's

Photo bevat veel ingebedde relaties die we moeten vastleggen. We zijn voornamelijk geïnteresseerd in de relatie met Person . Om de relatie tussen persoon en foto vast te leggen, voeg ik de Photo_Content tafel:

Er zijn veel verschillende aspecten waarmee een Person kan betrekking hebben op een Photo . Ik besloot een nieuwe tabel toe te voegen, Photo_Content_Role , om de relatie van een foto tot een persoon te karakteriseren. In plaats van aparte tabellen te hebben voor elk soort relatie, gebruiken we een enkele verbindingstabel en de Photo_Content_Role tabel. Deze tabel is een referentielijst met standaardrelaties zoals we al hebben opgemerkt. Dit is onze eerste set gegevens voor Photo_Content_Role :

OK, dus dit is een aas-and-switch. Ik zei Photo_Content zou betrekking hebben op mensen naar foto's, dus waarom is er iets over "object afgebeeld"? Logischerwijs zullen er foto's zijn waarop we de inhoud zouden beschrijven zonder een Persoon te identificeren . Moet ik hier nog een tabel voor toevoegen, met een aparte set inhoudsrollen? Ik besloot van niet. In plaats daarvan zal ik een rij met null personen toevoegen aan de Person tabel als seed-gegevens, en hebben niet-persoonsinhoud verwijzen naar die persoon. (Ja, programmeurs, het is wat meer werk. Graag gedaan.) De 'nul Persoon' heeft id nul (0).

Sleutel leren nr. 1:

Minimaliseer tabellen met gevoelige gegevens door vergelijkbare relatiestructuren in één tabel te leggen.

Ik verwacht dat er mogelijk nog meer relaties zijn die stroomafwaarts zullen worden ontdekt. En het is ook mogelijk dat een sociale club zijn eigen rollen heeft om toe te kennen aan een Persoon in een Foto . Om die reden heb ik een 'pure' surrogaat-primaire sleutel gebruikt voor Photo_Content_Role , en voegde ook een optionele externe sleutel toe aan Club . Dit stelt ons in staat om speciale toepassingen door individuele clubs te ondersteunen. Ik noem het veld 'exclusief' om aan te geven dat het niet beschikbaar zou moeten zijn voor andere clubs.

Sleutel leren nr. 2:

Als eindgebruikers een ingebouwde lijst kunnen uitbreiden, geef dan de tabel een zuivere surrogaatsleutel om gegevensbotsingen te voorkomen.

Photo_Content_Role.max_per_person kan ook mysterieus zijn. Je kunt het niet zien in het diagram, maar Photo_Content_Role.id heeft zijn eigen unieke beperking zonder max_per_person . In wezen is de echte primaire sleutel gewoon id . Door max_per_person . toe te voegen naar id in de primaire sleutel dwing ik elke verwijzende tabel om informatie op te nemen waarmee het een kardinaliteitscontrolebeperking kan (moeten!) afdwingen. Hier is de controlebeperking in Photo_Content .

Sleutel leren nr. 3:

Als elke rij van een tabel individuele beperkingen heeft, moeten verwijzende tabellen een nieuwe unieke beperking toevoegen, waarbij een natuurlijke sleutel wordt uitgebreid met de beperkingsvelden. Laat de onderliggende tabel naar die sleutel verwijzen.

Laten we nog eens kijken naar Photo_Content . Dit is voornamelijk een relatie tussen Photo en Person , met de relatie gespecificeerd door de bijgevoegde inhoudsrol. Zoals ik al eerder opmerkte, is dit echter waar we alles opslaan beschrijvende informatie over de foto. Om aan dit soort open einde tegemoet te komen, hebben we de optionele content_headline en content_detailed kolommen. Deze zullen zelden nodig zijn voor een gewone associatie tussen een Persoon en een Foto. Maar een kop als 'Bob Januskis ontvangt de jaarlijkse prestatieprijs' is gemakkelijk te anticiperen. Ook als er geen Persoon is — 'Afgebeeld object', Persoon 0 — we moeten iets vereisen in de content_headline , zoals 'Noordwestelijke helling van de berg Ararat.'

De laatst ontbrekende fotorelatie:albums

Tot nu toe hebben we niets toegevoegd dat betrekking heeft op Photo s naar Photo s. Het is belangrijk voor sociale netwerken en fotoservices:Album s. En die wil je toch niet in de spreekwoordelijke schoenendoos? Dus laten we deze flagrante leemte opvullen - maar laten we er ook over nadenken.

Album voegt Photo s op een andere manier dan de andere relaties die we hebben behandeld. Photo s kunnen worden geassocieerd met dezelfde club, een vergelijkbare datum, GPS-coördinaten in de buurt, dezelfde fotograaf, enzovoort. Echter, Album geeft duidelijk aan dat de bijgevoegde Photo s maken deel uit van een enkel onderwerp of verhaal. Als zodanig zijn de veiligheidsrelevante aspecten van één Photo kan worden afgeleid uit een ander in het Album . Ook kan de volgorde die gevolgtrekkingen versterken of verminderen. Denk dus niet alleen aan Album als een onschuldige verzameling. Betreffende Photo s is allesbehalve.

Hoewel het vanuit veiligheidsoogpunt niet onschuldig is, Album is een rechttoe rechtaan entiteit met een zuivere Id surrogaatsleutel die eigendom is van een Club (geen Person ). Album_Photo geeft ons een set Photo s gesequenced door Photo_Order . Je zult zien dat ik het Album id en order de primaire sleutel. De relatie is echt tussen de Photo en het Album , dus waarom zou u die niet de primaire sleutel maken? Omdat oneven gevallen een Photo herhalen in een Album zijn zeker mogelijk. Dus plaatste ik Photo_Order in de primaire sleutel, en na enig nadenken besloten om een ​​alternatieve unieke sleutel toe te voegen met album en foto om een ​​Photo van herhalen in een Album . Als er genoeg geschreeuw is voor het herhalen van een Photo in een Album ontstaan, is een unieke sleutel gemakkelijker te verwijderen dan een primaire sleutel.

Sleutel leren nr. 4:

Selecteer voor de primaire sleutel een kandidaat-sleutel met het minste risico dat deze later wordt weggegooid.

Fotometadata

De laatste potentieel gevoelige informatie die moet worden toegevoegd, zijn de metadata (meestal gemaakt door het apparaat dat de foto's heeft gemaakt). Deze gegevens zijn niet onderdeel van een relatie, maar het is inherent aan de foto. De primaire definitie van informatie die een camera bij een foto opslaat, is EXIF, een industriestandaard uit Japan (JEITA). EXIF is uitbreidbaar en kan tientallen of honderden velden ondersteunen, waarvan geen enkele vereist kan zijn van onze geüploade afbeeldingen. Deze niet-vereiste status is omdat deze velden niet voor alle foto-indelingen gelden en kunnen worden gewist voordat ze worden geüpload. Ik heb Photo met veel veelgebruikte velden, waaronder:

• camera_mfr
• camera_model
• camera_software_version
• image_x_resolution
• image_y_resolution
• image_resolution_unit
• image_exposure_time
• camera_aperture_f
• GPSLatitude
• GPS-lengtegraad
• GPSAltitude

De GPS-velden zijn natuurlijk degenen die de hoogste gevoeligheid toevoegen aan een Photo .

Ons model, met alle gevoelige en waardevolle gegevens gedefinieerd

Met deze wijzigingen ronden we deze fase van het beveiligen van de clubdatabase af. Alle aansluitingen en de benodigde aanvullende gegevens zijn aanwezig, zoals hieronder afgebeeld. Ik heb Photo informatie rood, en Album licht turkoois om mijn idee van logische groeperingen over te brengen. De vergroting van data-elementen is reëel, maar zeer geminimaliseerd.

Conclusie

Om elk datamodel op een goede beveiligingsbasis te krijgen, is een ordelijke en systematische toepassing van beveiligingsprincipes en relationele databasepraktijken vereist. In deze aflevering hebben we het datamodel beoordeeld en zorgvuldig de ontbrekende structuur ingevuld die geïmpliceerd was, maar niet tot uitdrukking kwam in het schema. We zouden geen waarde kunnen toekennen of bescherming bieden aan de bestaande gegevens zonder de gegevens toe te voegen die ze invullen en correct met elkaar verbinden. Als dit op zijn plaats is, zullen we doorgaan met het toevoegen van de elementen van gegevenswaardering en gegevensgevoeligheid waarmee we alle gegevens duidelijk kunnen zien vanuit een volledig beveiligingsperspectief. Maar dat staat in ons volgende artikel.