Dette er den fjerde i vores flerdelte serie om datamodellering til informationssikkerhed såvel som datakarakteristika. En simpel datamodel for et fiktivt websted, der understøtter organisationer med fælles interesse (fuglekigningsklubber osv.) har givet os indhold til at udforske datamodellering fra et sikkerhedssynspunkt.
I Oscar Wildes skuespil Lady Windermere's Fan , tagger Lord Darlington en kyniker som "nogen, der kender prisen på alting og værdien af ingenting." Desværre kan oplysningerne i vores databaser ubevidst behandles på samme måde. Er en kundekonto værdien af summen af sine køb? Hvad lider vi, hvis vi mister fire timers marketingdata i løbet af julehandlesæsonen?
Vi datamodelbyggere vil ikke foretage disse vurderinger, men vi skal gemme deres relevante data på vegne af de mennesker, der vil. Vi bliver nødt til at udfylde hullerne i implicit datastruktur. I denne artikel vil vi se, hvordan du tilføjer dette vigtige sikkerhedselement til vores database.
Vis mig pengene!
Hvor meget skal vi beskytte hvert dataobjekt? Overvej dem i lyset af Fortrolighed , Integritet og Tilgængelighed — de nøgleegenskaber, der bestemmer et informationssystems sikkerhed. Vi skal også tage højde for forskellen mellem disse foranstaltninger på et "iboende" grundlag, og hvor meget disse data kan påvirke sikkerheden.
Der er to grunde til at gøre dette. For det første vil det hjælpe os med at se, hvordan vi beskytter dataene i vores klubdatabase. Skal nogle tabeller krypteres? Indsætte andre skemaer? Måske nedstrøms vil vi vedhæfte Virtual Private Database-kontroller? Disse oplysninger vil hjælpe os med at vælge passende sikkerhedsforanstaltninger.
For det andet vil vi overveje dataene fra et råt regnskabsperspektiv:Hvad er dets samlede værdi? Hvad kan vi miste i tilfælde af datakorruption? Hvad er vores ansvar, hvis personlige data videregives? Når vi tilføjer disse oplysninger til vores skema, tilføjer vi en kritisk metrik til vores lagrede data:dollars og cents. Dette lader folk, der betaler regninger, bestemme, hvad de har råd til for sikkerhed ––– og, på en økonomisk måde, hvor meget det er værd.
Alle relationer er stavet ud
Lad os opsummere tilstanden af vores model. Fra sidste artikel er datastrukturen udfyldt. Personer, klubber, medlemskab, billeder, album og indhold er der alt sammen. Hvordan de hænger sammen er der. Dette skema er klar til at gemme data med relationerne eksplicit indfanget hele vejen igennem, mens implicitte relationer er blevet elimineret så vidt muligt.
Tilskrivning af værdi og følsomhed
Nu finder vi ud af, hvordan man sætter tal til data. Vi kan virkelig ikke vedhæfte en enkelt værdi for et dataelement, der fortæller os, hvor meget vi skal beskytte det. Vi kan dog heller ikke - og behøver - ikke gå ind i en samling af målinger. Vi vil fokusere på, hvor meget et stykke data kan tjene for os, og hvor meget det kan koste os at miste eller afsløre disse data.
Vi bruger begreberne "værdi" og "følsomhed" til dette – en positiv og en negativ måling, om man vil. Værdi betragtes ofte i form af fremtidig værdi eller mulighed. Følsomhed er meget defensiv; den vedrører risici på finansielt plan (lovgivningsmæssige eller juridiske sanktioner) og tab af omdømme eller goodwill.
Værdiansættelse relaterer direkte til Integritet og Tilgængelighed . Vi vil vurdere dette i forhold til, hvilke fordele dataene kan generere, eller hvor meget skade der vil ske, hvis adgangen til dem mistes. Vi adresserer følsomhed hovedsageligt i form af Fortrolighed , som skal måles på skaden eller ansvaret, hvis den afsløres.
Den fælles struktur for værdiansættelse og følsomhed
Lad os nu overveje værdiansættelse og følsomhed i forhold til vores database. Når vi ser datamodellen igen, finder vi ud af, at disse kvaliteter kun er relative til en klub eller en person. En klub eller en person nyder godt af værdien af noget, og de lider, når noget følsomt bliver offentliggjort. Derfor er hver af disse vurderinger fanget med hensyn til en klub eller en person. Når vi ser på vores dataenheder, vil vi sikre, at hver af dem, der har en værdi (fordel), også har en følsomhed (risiko) og omvendt. Så hver involveret enhed vil have begge separate værdiansættelses- og følsomhedsfelter. De vil være valgfri eller standard i de fleste tilfælde. Begge vil også blive vejet i form af penge:en valutaværdi, præcis til hundrededele af en amerikansk dollar. (For overskuelighedens skyld bruger vi kun én valuta.) Fejr det eller beklage det, penge er vores eneste brugbare målestok for begge. For at udnytte dette fællestræk vil vi kalde disse "Vigtigt".
Som datamodellere kan vi faktisk ikke selv sætte tal på dette. Selv som webstedet eller databaseoperatøren ved vi ikke nok til at tildele disse værdier; desuden er dataene ikke helt vores. For data, der er specifikke for en klub, skal vi lade den klub tildele sin egen vigtighedsniveauer og dets regler for brug af disse niveauer. Så anvender vi deres regler på deres data.
Lad os starte med de typer enheder, klubber kan tildele.
Klubdata
Klubbens enheder er:
- Klub
- Club_Office
- Betjent
- Medlem
- Album
- Album_Photo
- Foto
Vi tilføjer Valuation og Sensitivity kolonner til hver af disse. Fordi disse kolonner er knyttet til klubben , deres navne er specifikke – f.eks. club_sensitivity .
Her er vores sæt fokustabeller for Club , herunder Person :
Personlige data
Nu skal vi adressere Person enhed. Igen, vi tildeler ikke værdierne her – det er personens privilegium. Naturligvis skal vi tilføje betydningskolonner til Person . Men for bedre at understøtte det personlige privatliv vil vi skære denne enhed finere. Privatliv er trods alt nøglen til datafølsomhed.
Først vil vi tilføje en ny kolonne kaldet monicker det er ligesom et brugernavn eller alias. Klubmedlemmer kan bruge det til identifikation i stedet for deres faktiske navne. Vi vil give et værdiansættelse/følsomhed kolonnepar for navn-monicker-foreningen. Disse vil være person_name_valuation og person_name_sensitivity . Resten af felterne styres af disse to par.
En Person s klubaktivitet er lige så meget deres interesse som klubben ’s. Derfor tilføjer vi de samme betydningsfelter til Medlem og Betjent .
Nu kunne vi tilføje person_importance felter til Foto enhed, men se på photo_content kolonne. Et billede kan involvere flere personer, og dette er en del af det, vi gemmer i photo_content. Derfor vil vi placere vigtighedsfelterne på photo_content. i stedet for på Foto.
Den "sensibiliserede" model
Vi har ændret vores datamodel til at tilskrive dataværdi og datafølsomhed overalt, hvor det er nødvendigt. Det følgende er vores endelige skema.
Vi har været omhyggelige med at undgå at forvrænge det originale skema med yderligere relationer eller begrænsninger. Dette er kritisk, fordi vi tager det skema som en nøjagtig analyse af de rigtige data med rigtige forretningsregler.
Det er svært at tillægge dine data nogen form for iboende betydning. Det er værre, hvis du forsøger at anvende det på en database uden understøttelse i modellen eller skemaet. Denne artikel demonstrerer en teknik til at vedhæfte disse oplysninger på en måde, der ikke forvrænger de iboende forretningsdele af modellen.
Fleksibiliteten og modificerbarheden af Værdi og Sensitivitet er centrale mål her. Når du begynder at anvende reelle værdier på disse attributter, vil du opdage, at du skal ændre dem og revidere din tilgang. Det er en grund til individuelt at knytte disse værdier til selve bordene i stedet for at have dem udenfor. Ulempen er, at det bliver ret kompliceret, på grund af de mange placeringer for disse værdier. Dette kan endda vise sig i, hvordan modellen bruges. Vi vil tage det mangefacetterede spørgsmål om håndtering af kompleksitet i informationssikkerhed op i vores næste artikel.
Efterlad venligst kommentarer eller kritik i vores combox.