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