Domenedrevet design for sikkerhet










Hvorfor trenger vi en domenemodell for sikkerhet? Argumentet lyder at hvis vi vet nøyaktig hva systemet skal gjøre , så vet vi også hva det ikke skal gjøre .







Bagasjesystemet ved den nye flyplassen i Denver på begynnelsen av nittitallet var i utgangspunktet markedsført som det mest avanserte i verden, men ble raskt kjent som en av de verste eksemplene på hvordan et prosjekt kan feile. Opprinnelig var det planlagt å automatisere håndteringen av bagasje gjennom hele flyplassen, men det viste seg fort at systemet var langt mer komplekst enn noen hadde forestilt seg. Problemene relatert til implementeringen av systemet medførte at hele den ferdige flyplassen ble stående ubrukt i over et år, mens ingeniørene slet med å få bagasjesystemet til å fungere.



Etter det som ble rapportert i dagspressen, omfattet faktorer som bidro til problemene følgende:




Underestimering av kompleksitet
Kompleks arkitektur
Endringer i krav
Underestimering av tidsplan og budsjett
Råd fra eksperter ble avfeid 
Det ble ikke bygget inn noen resevekapasitet eller gjenopprettingsprosess for å håndtere situasjoner hvor deler av systemet feilet
Systemets tilsynelatende entusiasme for å spise folks bagasje.

Krav til en domenemodell



Et domene er en del av den virkelige verden hvor det skjer ting, f.eks. domenet “bagasjehåndtering”. En domenemodell er en destillert versjon av domenet hvor hvert konsept har en bestemt mening. Kode (eller programkode) er en representasjon av domenemodellen, skrevet i et programmeringsspråk.



For at en domenemodell skal være effektiv, så må den:




Være enkel – fokusere på de viktige tingene
Være streng slik at den kan være et fundament for å skrive kode

Fange dyp forståelse for å gjøre systemet virkelig nyttig og hjelpsomt
Være det beste valget fra et pragmatisk synspunkt
Gi oss et språk vi kan bruke nårsomhelst vi snakker om systemet

Det finnes alltid en kritisk kompleksitet – vær bevisst om det er et teknisk aspekt, eller om det har med domenet å gjøre.



En modell er den konseptuelle forståelsen av det som vi anser som essensielt i vår modelleringsøvelse. Dette betyr også at en modell er en forenkling av virkeligheten – men en forenkling som vi fortsatt aksepterer som en gyldig representasjon av den virkelige tingen.



Når vi zoomer ut fra et enkelt system til inntegrasjonsnivået, gir DDD oss verktøyene avgrenset kontekst ( bounded contexts ) og kontekstavbildninger( context mappings ). Disse gir oss bedre muligheter til å sikre at integrasjonen mellom systemer er “tett”, slik at det blir lettere å ivareta sikkerhet på tvers av flere systemer.



La oss bruke modelljernbane som et eksempel på en modell. Følgende attributer til modellen sammenfaller med virkeligheten:



Farge – Vi synes at en modell av et spesifikt tog burde ha de same fargene som det virkelige toget



Relativ størrelse – Vi forventer at proporsjonene skal bevares. Hvis dørene er dobbelt så høye som de er brede i virkeligheten, forventer vi samme størrelsesforholdet på modelltoget.



Form – Vi forventer at modelltoget og dets detaljer har den same formen som i virkeligheten, som f.eks. kurvaturen til frontruten.



Bevegelse – Vi forventer at modelltoget beveger seg langs skinner på same måten som et virkelig tog.



Det vil også være noen attributter til modellen som skiller seg fra virkeligheten, hvor vi ikke bryr oss om avviket:



Materiale – Det er OK at modelltoget er laget i plast eller blikk, selv om originalen er bygget med helt andre materialer.



Absolutt størrelse – Hvis de virkelige vognene var 30 meter lange, har vi ingen innvendinger mot at vognene er mye mindre i modellen.



Vekt – Modellen er mye lettere, noe som er OK.



Fremdriftsmekanisme – Modellen har ikke en dieselmotor, den går på strøm.



Skinnekurvatur – Kurvene i modellen er mye krappere enn i virkeligheten, noe som vi aksepterer.



En modell er mindre rik, men mer eksakt/presis (streng) enn virkeligheten. Advarsel: Mange nesten-synonymer som beskriver det samme konseptet er ofte et tegn på at modellen ikke er særlig streng.



Hensikten med domenemodellen



Domenemodellen bør representere et språk som brukes overalt, alltid, av alle, for å fremelske klarhet og felles forståelse. Dette medfører du bør insistere at ordene fra domenemodellen brukes i alle kravdokumenter. Hvis det er noe som er vanskelig å uttrykke i terminologien til domenemodellen, betyr det sannsynligvis at det er vanskelig å implementere i programvare – og det kan bety at domenemodellen må arbeides mer med.



Avgrenset kontekst – en konstruksjon for sikkerhet



Et begrep eller et konsept kan ha samme navn i forskjellige deler av virksomheten, men hvert sted det brukes kan det ha forskjellig mening. Et eksempel kan være konseptet “pakke”. Det kan være en TCP/IP-pakke, en fysisk pakke med gråpapir rundt, en samling programvare (“Office-pakke”), osv.



Så lenge betydningen av begreper, operasjoner og konsepter forblir den samme, holder modellen. Så snart semantikken endrer seg, bryter modellen sammen – og dermed har man funnet avgrensningen for konteksten. Den semantiske avgrensningen av en kontekst er interessant fra et sikkerhetsperspektiv – bare tenk på tvetydighetsanalyse i McGraws definisjon av arkitekturanalyse!



Eksempel på avgrenset kontekst



Vi ser på to avdelinger (virksomhetsområder) i et firma som selger produkter til kunder. Den ene er transportavdelingen (shipping), den andre er regnskapsavdelingen (finans). I begge avdelingene finnes begrepet “ordre”, men med små nyanseforskjeller. I transportavdelingen er en ordre noe som identifiserer et antall pakker, og hver av disse har ett eller flere produkter. I regnskapsavdelingen er en ordre noe som har betalingsinformasjon, betalingsfrist, og mottatt beløp. Så lenge vi holer oss innenfor den samme konteksten, er dette ikke noe problem. Utfordringen kommer når vi må kommunisere på tvers av kontekster, og krysse grensen mellom dem.



Når data krysser en grense, arver de implisitt semantikken til den mottagende kontekstens språk og modell. Hvis man ikke eksplisitt tar hensyn til dette, risikerer man at man introduserer et sikkerhetsproblem. Det betyr også at hvis man prøver å representere begge virksomhetsområdene i samme modell, så ber man om problemer.



Litt forenklet kan vi forklare gangen i prosessen med å behandle bestilling og leveranse i de to avdelingene som følger:




Regnskapsavdelingen mottar en bestilling (ordre)
Den totale verdien av ordren reserveres på kontoen som er spesifisert av betalingsinformasjonen
Regnskapsavdelingen sender ordren til transportavdelingen for prosessering
Transportavdelingen prosesserer ordren, og sender den
Transportavdelingen oppdaterer regnskapsavdelingen med en oppdatert status
Regnskapsavdelingen ferdigstiller den finansielle transaksjonen.

Basert på denne beskrivelsen er det lett å lage et kontekstkart og identifisere at transportkonteksten er “nedstrøms” av regnskapskonteksten, og at når man krysser grensen, må en regnskapsordre eksplisitt oversettes til en transportordre, og omvendt når man krysser tilbake. Dette betyr også at dersom de forskjellige delene av systemet som implementerer dette utvikles av forskjellige grupper, så er det avgjørende at utviklerne kommuniserer med hverandre!



Denne artikkelen lener seg tungt på boken Secure by Design av Johnsson, Deogun og Sawano



Photo by Jarod Lovekamp from Pexels

Top News