Dit is de vierde in onze meerdelige serie over datamodellering voor informatiebeveiliging en datakenmerken. Een eenvoudig gegevensmodel voor een fictieve website die organisaties met gedeelde belangen ondersteunt (vogelclubs, enz.) heeft ons inhoud opgeleverd voor het verkennen van gegevensmodellering vanuit veiligheidsoogpunt.
In het toneelstuk van Oscar Wilde Lady Windermere's Fan , noemt Lord Darlington een cynicus "iemand die de prijs van alles kent, en de waarde van niets." Helaas kan de informatie in onze databases onbewust op dezelfde manier worden behandeld. Is een klantenaccount de som van zijn aankopen waard? Wat hebben we te lijden als we vier uur aan marketinggegevens verliezen tijdens het winkelseizoen voor de feestdagen?
Wij datamodelleurs zullen die beoordelingen niet maken, maar we moeten hun relevante gegevens opslaan namens de mensen die dat wel doen. We zullen de gaten in de impliciete gegevensstructuur moeten opvullen. In dit artikel zullen we zien hoe we dit belangrijke beveiligingselement aan onze database kunnen toevoegen.
Laat me het geld zien!
Hoeveel moeten we elk dataobject beschermen? Beschouw ze in het licht van Vertrouwelijkheid , Integriteit , en Beschikbaarheid — de kernkwaliteiten die de beveiliging van een informatiesysteem bepalen. We moeten ook rekening houden met het verschil tussen deze maatregelen op "intrinsieke" basis en hoeveel deze gegevens de beveiliging kunnen beïnvloeden.
Er zijn twee redenen om dit te doen. Ten eerste helpt het ons om te zien hoe we de gegevens in onze clubdatabase kunnen beschermen. Moeten sommige tabellen worden versleuteld? Andere schema's plaatsen? Misschien zullen we stroomafwaarts Virtual Private Database-besturingselementen toevoegen? Deze informatie helpt ons bij het kiezen van passende waarborgen.
Ten tweede zullen we de gegevens bekijken vanuit een onbewerkt boekhoudkundig perspectief:wat is de totale waarde ervan? Wat kunnen we verliezen in het geval van datacorruptie? Wat is onze aansprakelijkheid als persoonsgegevens worden verstrekt? Wanneer we deze informatie aan ons schema toevoegen, voegen we een kritische statistiek toe aan onze opgeslagen gegevens:dollars en centen. Hierdoor kunnen de mensen die de rekeningen betalen bepalen wat ze zich kunnen veroorloven voor veiligheid ––– en, in geldelijke zin, hoeveel het waard is.
Alle relaties zijn beschreven
Laten we de staat van ons model samenvatten. Vanaf het laatste artikel is de datastructuur ingevuld. Personen, clubs, lidmaatschap, foto's, albums en inhoud zijn er allemaal. Hoe ze aan elkaar knopen is daar. Dit schema is klaar om gegevens op te slaan waarin de relaties expliciet zijn vastgelegd, terwijl impliciete relaties zoveel mogelijk zijn geëlimineerd.
Waarde en gevoeligheid toekennen
Nu gaan we uitzoeken hoe we getallen aan gegevens kunnen toevoegen. We kunnen echt geen enkele . bijvoegen waarde toe aan een gegevensitem dat ons vertelt hoeveel het moet worden beschermd. We kunnen echter ook niet - en hoeven ook niet - in te gaan op een verzameling statistieken. We richten ons op hoeveel een stukje gegevens voor ons kan opleveren en hoeveel het ons kan kosten als we die gegevens kwijtraken of openbaar maken.
We gebruiken hiervoor de termen 'waarde' en 'gevoeligheid', een positieve en een negatieve meting, zo u wilt. Waarde wordt vaak beschouwd in termen van toekomstige waarde of kans. Gevoeligheid is erg defensief; het heeft betrekking op risico's op financieel vlak (regelgevende of wettelijke sancties) en op reputatie- of goodwillverlies.
Waardering heeft direct betrekking op Integriteit en Beschikbaarheid . We zullen dit beoordelen in termen van welke voordelen de gegevens kunnen opleveren, of hoeveel schade zal worden aangericht als de toegang ertoe verloren gaat. We pakken gevoeligheid voornamelijk aan in termen van Vertrouwelijkheid , die moet worden gemeten aan de hand van de schade of aansprakelijkheid als deze wordt onthuld.
De gemeenschappelijke structuur van waardering en gevoeligheid
Laten we nu eens kijken naar waardering en gevoeligheid ten opzichte van onze database. Als we het datamodel opnieuw bekijken, zien we dat deze eigenschappen alleen relatief zijn voor een club of een persoon. Een club of een persoon profiteert van de waarde van iets, en zij lijden als iets gevoeligs openbaar wordt gemaakt. Daarom wordt elk van deze beoordelingen vastgelegd met betrekking tot een club of een persoon. als we naar onze data-entiteiten kijken, zullen we ervoor zorgen dat elke entiteit die een waarde (voordeel) heeft, ook een gevoeligheid (risico) met zich meebrengt, en vice versa. Elke betrokken entiteit heeft dus afzonderlijke velden Waardering en Gevoeligheid. Ze zijn in de meeste gevallen optioneel of standaard. Beide zullen ook worden gewogen in termen van geld:een valutawaarde, nauwkeurig tot honderdsten van een Amerikaanse dollar. (Voor de duidelijkheid gebruiken we slechts één valuta.) Vier het of betreur het, geld is voor beide onze enige bruikbare maatstaf. Om deze gemeenschappelijkheid te benutten, zullen we deze "Belang" noemen.
Als datamodelleurs kunnen we hier zelf geen cijfers op plakken. Zelfs als de site- of database-operator weten we niet genoeg om deze waarden toe te kennen; bovendien zijn de gegevens niet helemaal van ons. Voor gegevens die specifiek zijn voor een club, moeten we die club zijn eigen laten toewijzen belangrijkheidsniveaus en de regels voor het gebruik van die niveaus. Dan passen we hun regels toe op hun gegevens.
Laten we beginnen met de soorten entiteiten die clubs kunnen toewijzen.
Clubgegevens
De Club-entiteiten zijn:
- Club
- Club_Office
- Officier
- Lid
- Album
- Album_Photo
- Foto
We voegen Valuation . toe en Sensitivity kolommen voor elk van deze. Omdat deze kolommen zijn gekoppeld aan de Club , hun namen zijn specifiek - b.v. club_sensitivity .
Hier is onze set focustabellen voor Club , inclusief Persoon :
Persoonlijke gegevens
Nu moeten we de Person aanspreken entiteit. Nogmaals, we kennen de waarden hier niet toe - dat is het voorrecht van de persoon. Natuurlijk moeten we kolommen Belang toevoegen aan Persoon . Maar om de persoonlijke privacy beter te ondersteunen, gaan we deze entiteit fijner snijden. Privacy is immers de sleutel tot gegevensgevoeligheid.
Eerst zullen we een nieuwe kolom toevoegen met de naam monicker dat is als een gebruikersnaam of alias. Clubleden kunnen dat gebruiken voor identificatie in plaats van hun echte naam. We zullen een waarderings-/gevoeligheidskolompaar leveren voor de naam-monicker-associatie. Dit zijn person_name_valuation en person_name_sensitivity . De rest van de velden worden bestuurd door deze twee paren.
Een Persoon ’s clubactiviteit is evenzeer hun interesse als de Club 's. Daarom zullen we dezelfde Belang-velden toevoegen aan Lid en Officier .
Nu kunnen we person_importance add toevoegen velden naar de Foto entiteit, maar kijk naar de photo_content kolom. Bij een foto kunnen meerdere personen betrokken zijn, en dit is onderdeel van wat we opslaan in photo_content. Daarom plaatsen we de belangrijkheidsvelden op photo_content. in plaats van op foto.
Het 'gevoelige' model
We hebben ons datamodel aangepast om overal waar nodig datawaarde en datagevoeligheid toe te kennen. Het volgende is ons definitieve schema.
We hebben ervoor gezorgd dat we het oorspronkelijke schema niet vervormden met extra relaties of beperkingen. Dit is van cruciaal belang omdat we dat schema nemen als een nauwkeurige analyse van de echte gegevens met echte bedrijfsregels.
Het is moeilijk om enige vorm van inherent belang aan uw gegevens te hechten. Het is nog erger als u het op een database probeert toe te passen zonder ondersteuning in het model of schema. Dit artikel demonstreert een techniek om deze informatie toe te voegen op een manier die de intrinsieke zakelijke onderdelen van het model niet vervormt.
De flexibiliteit en aanpasbaarheid van Value en Gevoeligheid zijn hierbij belangrijke doelen. Als u echte waarden op deze attributen gaat toepassen, zult u merken dat u ze moet aanpassen en uw aanpak moet herzien. Dat is een reden om deze waarden afzonderlijk aan de tabellen zelf te koppelen, in plaats van ze buitenboord te zetten. Het nadeel is dat het behoorlijk ingewikkeld wordt vanwege de vele locaties voor deze waarden. Dit kan zelfs tot uiting komen in de manier waarop het model wordt gebruikt. We zullen in ons volgende artikel ingaan op de veelzijdige kwestie van het managen van complexiteit in informatiebeveiliging.
Laat eventuele opmerkingen of kritieken achter in onze combox.