Detta är den fjärde i vår flerdelade serie om datamodellering för såväl informationssäkerhet som dataegenskaper. En enkel datamodell för en fiktiv webbplats som stöder organisationer med delat intresse (fågelskådningsklubbar etc.) har försett oss med innehåll för att utforska datamodellering ur säkerhetssynpunkt.
I Oscar Wildes pjäs Lady Windermeres fan Lord Darlington taggar en cyniker som "någon som vet priset på allt och värdet av ingenting." Tyvärr kan informationen i våra databaser omedvetet behandlas på samma sätt. Är ett kundkonto värt summan av sina inköp? Vad lider vi om vi förlorar fyra timmars marknadsföringsdata under julhandeln?
Vi datamodellerare kommer inte att göra dessa bedömningar, men vi måste lagra deras relevanta data på uppdrag av de personer som kommer att göra det. Vi måste fylla luckorna i implicit datastruktur. I den här artikeln kommer vi att se hur du lägger till detta viktiga säkerhetselement i vår databas.
Visa mig pengarna!
Hur mycket ska vi skydda varje dataobjekt? Betrakta dem i ljuset av Konfidentialitet , Integritet och Tillgänglighet — De nyckelegenskaper som avgör ett informationssystems säkerhet. Vi måste också ta hänsyn till skillnaden mellan dessa åtgärder på en "inneboende" basis och hur mycket dessa data kan påverka säkerheten.
Det finns två skäl att göra detta. För det första kommer det att hjälpa oss att se hur vi kan skydda uppgifterna i vår klubbdatabas. Bör vissa tabeller krypteras? Lägga in andra scheman? Nedströms kanske vi kommer att bifoga kontroller för virtuell privat databas? Denna information hjälper oss att välja lämpliga skyddsåtgärder.
För det andra kommer vi att begrunda data från ett rått redovisningsperspektiv:Vilket är dess totala värde? Vad kan vi förlora i händelse av datakorruption? Vad är vårt ansvar om personuppgifter lämnas ut? När vi lägger till denna information i vårt schema, lägger vi till ett kritiskt mått till vår lagrade data:dollar och cent. Detta låter människorna som betalar räkningarna avgöra vad de har råd med för säkerhet ––– och, på ett monetärt sätt, hur mycket det är värt.
Alla relationer är utskrivna
Låt oss sammanfatta tillståndet för vår modell. Från och med den senaste artikeln har datastrukturen fyllts i. Personer, klubbar, medlemskap, foton, album och innehåll finns där. Hur de knyter ihop är där. Det här schemat är redo att lagra data med relationerna explicit fångad genomgående, medan implicita relationer har eliminerats så långt som möjligt.
Tillskriva värde och känslighet
Nu ska vi ta reda på hur man lägger siffror till data. Vi kan verkligen inte bifoga en singel värde till ett dataobjekt som talar om för oss hur mycket vi ska skydda det. Men vi kan inte - och behöver inte - gå in på en samling mätvärden heller. Vi kommer att fokusera på hur mycket en databit kan tjäna för oss och hur mycket det kan kosta oss att förlora eller avslöja denna data.
Vi använder begreppen "värde" och "känslighet" för detta – ett positivt och ett negativt mått, om man så vill. Värde betraktas ofta i termer av framtida värde eller möjlighet. Känslighet är mycket defensiv; det avser risker på finansiell nivå (reglerande eller juridiska påföljder) och förlust av rykte eller goodwill.
Värdering relaterar direkt till Integritet och Tillgänglighet . Vi kommer att bedöma detta i termer av vilka fördelar data kan generera, eller hur mycket skada som kommer att ske om åtkomsten till den går förlorad. Vi tar upp känslighet främst i termer av Konfidentialitet , som måste mätas med skadan eller ansvaret om den avslöjas.
Den gemensamma strukturen för värdering och känslighet
Låt oss nu överväga värdering och känslighet mot vår databas. När vi tittar på datamodellen igen, finner vi att dessa egenskaper endast är relativa till en klubb eller en person. En klubb eller en person drar nytta av värdet av något, och de lider när något känsligt offentliggörs. Därför fångas var och en av dessa bedömningar med avseende på en klubb eller en person. När vi tittar på våra dataenheter kommer vi att säkerställa att var och en som har ett värde (fördel) också har en känslighet (risk) och vice versa. Så varje inblandad enhet kommer att ha båda, separata värderings- och känslighetsfält. De kommer att vara valfria eller förvalda i de flesta fall. Dessutom kommer båda att vägas i termer av pengar:ett valutavärde, exakt till hundradelar av en amerikansk dollar. (För tydlighetens skull använder vi bara en valuta.) Fira det eller beklaga det, pengar är vårt enda användbara mått för någon av dem. För att utnyttja denna gemensamhet kommer vi att kalla dessa "viktighet".
Som datamodellerare kan vi faktiskt inte sätta siffror på detta själva. Även som webbplats- eller databasoperatör vet vi inte tillräckligt för att tilldela dessa värden; dessutom är uppgifterna inte helt våra. För data som är specifik för en klubb måste vi låta den klubben tilldela sin egen betydelsenivåer och dess regler för användning av dessa nivåer. Sedan tillämpar vi deras regler på deras data.
Låt oss börja med vilka typer av enheter klubbar kan tilldela.
Klubbdata
Klubbens enheter är:
- Klubb
- Club_Office
- Befäl
- Medlem
- Album
- Album_Photo
- Foto
Vi lägger till Valuation och Sensitivity kolumner till var och en av dessa. Eftersom dessa kolumner är kopplade till klubben , deras namn är specifika – t.ex. club_sensitivity .
Här är vår uppsättning fokustabeller för klubben , inklusive Person :
Personliga uppgifter
Nu måste vi adressera Person entitet. Återigen, vi tilldelar inte värderingarna här – det är personens privilegium. Naturligtvis måste vi lägga till betydelsekolumner till Person . Men för att bättre stödja den personliga integriteten kommer vi att skära upp den här enheten finare. När allt kommer omkring är integritet nyckeln till datakänslighet.
Först lägger vi till en ny kolumn som heter monicker det är som ett användarnamn eller alias. Klubbmedlemmar kan använda det för identifiering snarare än deras faktiska namn. Vi kommer att tillhandahålla ett kolumnpar för värdering/känslighet för namn-monicker-föreningen. Dessa kommer att vara person_name_valuation och person_name_sensitivity . Resten av fälten styrs av dessa två par.
En Person s klubbaktivitet är lika mycket deras intresse som klubben s. Därför kommer vi att lägga till samma betydelsefält till Medlem och Officer .
Nu kunde vi lägga till person_importance fälten till Foto enhet, men titta på photo_content kolumn. Ett foto kan involvera flera personer, och detta är en del av det vi lagrar i photo_content. Därför kommer vi att lägga viktfälten på photo_content. istället för på Foto.
Den "sensibiliserade" modellen
Vi har modifierat vår datamodell för att tillskriva datavärde och datakänslighet överallt där det behövs. Följande är vårt slutliga schema.
Vi har varit noga med att undvika att förvränga det ursprungliga schemat med ytterligare relationer eller begränsningar. Detta är avgörande eftersom vi tar det schemat som en korrekt analys av verklig data med verkliga affärsregler.
Att fästa någon form av inneboende vikt vid dina data är svårt. Det är värre om du försöker applicera det på en databas utan stöd i modellen eller schemat. Den här artikeln visar en teknik för att bifoga denna information på ett sätt som inte förvränger modellens inneboende affärsdelar.
Flexibiliteten och modifierbarheten för Värde och Känslighet är viktiga mål här. När du börjar tillämpa verkliga värden på dessa attribut kommer du att upptäcka att du måste ändra dem och revidera ditt tillvägagångssätt. Det är en anledning till att individuellt koppla dessa värden till borden själva, snarare än att ha dem utanför. Nackdelen är att det blir ganska komplicerat, på grund av de många placeringarna för dessa värden. Detta kan till och med visa sig i hur modellen används. Vi kommer att ta upp den mångfacetterade frågan om att hantera komplexitet i informationssäkerhet i vår nästa artikel.
Lämna eventuella kommentarer eller kritik i vår combox.