Dette er flersidevisningen av denne seksjonen. Klikk her for å skrive ut.
En sikker løsning begynner med et godt design! Mye av grunnlaget for å vurdere om en løsning er sikker, kommer fra designfasen hvor det må gjøres viktige avveininger mellom kost, nytte og risiko.
Artikklene du finner under temaet Designe på denne siden vil fokusere på designprosessen. Selv om denne kan inkludere mye mer enn vi har listet opp, dekker vi det viktigste i form av god dokumentasjon på det som skal bygges, viktige avklaringer og behovet for kontekst.
Noen krav er implisitte, som eksempelvis bruk av HTTPS/TLS, mens andre vil være eksplisitte og definert av lovverk, kunde eller tredjepart. Dersom kunden ikke har noen spesifikke krav er det likevel viktig at leveranseteamet lager en kravliste slik at rammene for prosjektet er dokumentert.
De fleste prosjekter må forholde seg til ulike krav fra Bouvet, kunden og eksterne parter. Alle utviklingsteam må ha kontroll på hvilke krav som stilles til leveransen:
Av lovpålagte krav kan en ha generelle krav eksempelvis knyttet til personvern, men mange bransjer opererer med mer spesifikke forskrifter som stiller andre krav som vil gjelde i tillegg.
I mange tilfeller er det klart både for Bouvet og kunde hva som gjelder, men det er viktig at teamet verifiserer dette før en begynner å utvikle løsningen, slik at kostbare og tidkrevende overraskelser kan unngås. Uavhengig av hva som er definert hvor, bør teamet uansett dokumentere hvilke krav en forholder seg til slik at dette er bevart for ettertiden.
Dersom leveransen mangler andre krav, kan sjekklisten være til god hjelp. Denne dekker de store linjene, og de fleste punktene kan gjennomføres av teamet selv. Gjennom å bruke sjekklista får teamet et overblikk over tilstanden til leveransen - og mulige svakheter og sårbarheter.
Dersom denne ikke er nok, og teamet eller kunden ønsker noe mer omfattende kan OWASPs Application Verification Standard (ASVS) brukes. Denne er en mer dyptgående sjekkliste som tilbyr tre nivåer med testing:
Dersom løsningen inneholder eller er avhengig av kunstig intelligens (KI), kreves tilleggskrav utover standard sikkerhetskrav. AI-systemer introduserer egne risikodimensjoner som må håndteres på kravnivå.
Sikkerhetskravene for AI-systemer bør dekke:
For detaljerte råd om sikker implementering av KI i utvikling, se Bruk av kunstig intelligens.
Riktig nettverkskonfigurasjon er viktig i sky, hybrid og on-prem. Denne siden er ment som et kort oppslag for sikker nettverkspraksis i prosjektarbeid.
Zero trust innebærer at man ikke stoler blindt på intern eller ekstern trafikk. Bruk prinsippet som standard: verifiser eksplisitt, gi minst mulig tilgang, og anta kompromittering.
Ha kontroll på hvilke IP-adresser og porter du eksponerer, og hvilke tjenester som lytter på portene. Undersøk brannmurregler, se i logger og skann egne systemer med nmap.
Hold en oppdatert oversikt over:
Skann jevnlig for å bekrefte faktisk eksponering. nmap er et etablert FOSS-verktøy for å oppdage åpne porter og tjenester.
Bruk av skannerverktøy som nmap skal alltid avklares med eiere av infrastruktur og nettverk. Dersom du sitter på
et Bouvet-kontor og skanner Azure-miljøet til en kunde, kan du lett trigge alarmer hos både Bouvet og kunden, samt ISP.
Bruk brannmur til å begrense trafikk innad i systemer og mellom systemer og Internett. Bruk allowlist hvis mulig. Filtrer trafikk i applikasjonslaget hvis nødvendig.
Praktiske hovedregler:
For AI-løsninger bør valg av driftsmodell vurderes opp mot krav til kontroll på ingress og egress.
Minimumsvurderinger for begge modeller:
Konfigurasjon av nettverk bør automatiseres så langt det lar seg gjøre, helst via CI/CD og infrastruktur som kode.
Når vi bygger løsninger setter vi ofte opp flere miljø, ofte for dev, test og prod slik at vi kan utvikle samtidig som at produkteier tester ny funksjonalitet og sluttbrukere bruker systemet i prod. Det er viktig at vi skiller mellom disse miljøene, slik at vi unngår å komme i situasjoner der endringer i ett miljø påvirker bruken av et annet.
Separate kontoer/abonnement/prosjekter per miljø gir et naturlig sikkerhetsskille fordi miljøene er isolert fra hverandre med mindre du eksplisitt oppretter tilganger mellom dem. Dette medfører noe mer overhead i administrasjon, men gir til gjengjeld sterkere isolasjon enn de andre mønstrene. For de fleste prosjekter av en viss størrelse, eller der det stilles krav til sikkerhet, er dette det anbefalte utgangspunktet. Selv i mindre prosjekter er det verdt å vurdere — kostnaden ved å separere tidlig er langt lavere enn å migrere senere når behovet oppstår.
Azure, AWS og Google Cloud tilbyr ulike mekanismer for dette, men prinsippene er de samme: separer der konsekvensen er høy, åpne kun eksplisitt mellom miljøer, og dokumenter hvilke unntak som finnes.
Det finnes andre tilnærminger på dette også, men uansett hvilken løsning teamet går for er det viktig å se det totale bildet med kost/nytte opp mot kravene en må forholde seg til.
For løsninger som inneholder kunstig intelligens eller maskinlæring, holder det ikke alltid å segregere kun infrastruktur. Teamet må også ha et bevisst forhold til hvordan data, modeller og utrulling holdes adskilt mellom miljøene.
Data brukt til trening, evaluering og produksjon bør holdes tydelig adskilt. Dette reduserer risikoen for at modeller valideres på feil grunnlag, eller at test- og utviklingsarbeid påvirker produksjonsnære data.
Modeller, vekter og tilhørende konfigurasjon bør versjoneres og knyttes tydelig til riktig miljø. Produksjonsmodellen bør ikke kunne overskrives av eksperimentering i dev eller test.
Når nye modeller eller større endringer skal innføres, bør teamet vurdere mekanismer som feature flags, kontrollert utrulling eller andre teknikker som gjør det mulig å teste endringer på en avgrenset måte før full produksjonssetting.
Autentisering og autorisering er viktig i alle utviklingsprosjekter. Kort fortalt går autentisering ut på at en skal validere at en bruker representerer den identiteten den hevder å representere, typisk gjennom å sjekke brukernavn og tilhørende passord. Autorisering går ut på å sjekke at brukeren har lov til å gjøre det den prøver på. Disse er ofte forkortet til authn for autentisering og authz for autorisering.
Når en skal validere en bruker, er det viktigste at en ikke lager en egen autentiseringsløsning! Å sikre at slike løsninger faktisk er sikre er en kjempejobb, og man bør istedet benytte seg av etablerte løsninger for dette!
Single sign-on er en vanlig løsning for å unngå at enkelttjenester må håndtere autentisering i bedriftsmiljø. Bruker autentiseres via en sentralt styrt tjeneste eller operativsystemet, hver applikasjon brukeren så åpner gjenbruker denne konteksten slik at en unngår å måtte logge på manuelt. Brukeropplevelsen strømlinjeformes, og brukerne ’trenes’ opp til at applikasjoner ikke skal be om brukernavn og passord. Dersom en angriper forsøker å phishe slik informasjon vil det oppfattes som unormalt og suspekt.
Vanlige tilnærminger for å håndtere autentisering kan være bruk av tredjepartstjenester, eller protokoller som håndterer autentisering mot kundens AD/Entra. I mange tilfeller ønsker vi å benytte Single-Sign-On(SSO) for å unngå at brukeren må taste inn brukernavn og passord, spesielt for interne forretningsapplikasjoner.
Vanlige løsninger for å håndtere pålogging er å benytte seg av biblioteker som tar seg av hele flyten, som eksempelvis Microsoft.Identity.Web. Andre alternativer kan være bruk av
Her er det viktig at en setter seg inn i behovene til løsningen og hvilke autentiseringsmetoder som er tilgjengelige og eventuelt ønskelige.
Skillet mellom autentisering og autorisering ligger i at autentiseringen bekrefter hvem du er, mens man i autoriseringen sjekker at du har lov til å utføre en handling.
I likhet med autentisering finnes det flere tilnærminger for hvordan autorisering håndteres, og man er nødt til å sette seg inn i beste praksiser for språk og rammeverk som benyttes.
Det finnes likevel noen hovedprinsipper en alltid skal ta med seg inn i utviklingsforløpet:
Dette er også kjent som default deny eller principle of least privilege, og brukes for å sikre at eksempelvis en uautorisert bruker ikke har tilgang til noe utover det som er eksplisitt tillatt.
Dersom en bruker forsøker å utføre en handling, skal det alltid sjekkes hvorvidt brukeren faktisk har tilgang til dette. Husk at denne sjekken må skje mot den autoritative kilden for tilganger, og aldri mot data brukeren kan manipulere!
Også kjent som principle of least privilege. En bruker skal aldri få mer tilgang enn det som trengs for å utføre en spesifikk oppgave. Dette gjøres for å redusere angrepsflaten dersom en bruker kompromitteres, slik at skadeomfanget kan begrenses.
Bruk av roller, role based access control (RBAC) er en vanlig tilnærming for å gi brukertilgang. Målet er å definere standardroller for en applikasjon, slik at tilgang kan baseres på disse. En vanlig måte å håndtere dette på eksempelvis med Entra eller AD er å ha
Dette gir en bedre oversikt over hvem som har tilgang til hva sammenliknet med brukere som har individuelle tilganger.
For løsninger med AI-agenter holder det ikke bare å styre sluttbrukertilgang. Agenten selv opptrer ofte som en egen identitet med tilgang til modeller, data, API-er og verktøy. Disse tilgangene må behandles som høyrisiko dersom de blir for brede.
Praktiske prinsipper:
Når en agent får tilgang til eksterne verktøy eller API-er, bør en også styre hvilke kommandoer, endepunkter og dataoperasjoner som er tillatt. Da reduseres risikoen for at feil, misbruk eller kompromittering gir stor effekt i drift.
For MCP-baserte integrasjoner (Model Context Protocol) gjelder de samme prinsippene, men med ekstra krav til avgrensning:
Tilgangsstyring påvirker også operasjonell risiko: For brede agenttilganger gjør hendelser vanskeligere å oppdage og konsekvensene større. Derfor bør tilgangsendringer for agenter logges og følges opp sammen med øvrig driftsovervåking, se Logging og monitorering.
Dette er en kort introduksjon til trusselmodellering. Metoder og verktøy nevnes kort, med lenker for fordypning.
Du har nok allerede gjort en enkel trusselmodellering uten at du selv er klar over det. Har du for eksempel tenkt på hvorfor brukerne av systemet du lager må logge seg inn med brukernavn og passord?
Når disse valgene ble tatt så har du automatisk gjort en enkel trusselmodellering. Du ønsker jo selvfølgelig ikke at uvedkommende skal kunne få tilgang til data i systemet ditt og du ønsker ikke at hvem som helst skal se data som overføres mellom brukerne dine og nettstedet ditt.
Hele poenget med trusselmodellering er å tenke som en angriper.
Det finnes flere måter å identifisere trusler mot et system. I praksis er det viktigste å samle de riktige rollene, beskrive hva som skal beskyttes, og systematisk gå gjennom hvordan løsningen kan angripes eller misbrukes. Noen trusler er kanskje allerede håndtert, mens andre krever nye tiltak. Prosessen gjentas når løsning, dataflyt eller bruksmønster endres.
En enkel arbeidsflyt er:
Trusselmodellering er viktigere enn hvilken metode du velger. Velg en tilnærming som teamet faktisk klarer å bruke jevnlig.
For løsninger med KI holder det ofte ikke å se på applikasjonskoden alene. Trusselmodellen må også dekke modell, promptflyt, datakilder, evalueringsgrunnlag og hvordan systemet brukes i drift.
Typiske spørsmål er:
Noen KI-spesifikke trusler som bør vurderes eksplisitt er:
For KI-løsninger er det også viktig å beskrive misbruksscenarier, ikke bare direkte angrep. En modell kan for eksempel være teknisk tilgjengelig og fungerende, men likevel utgjøre høy risiko dersom den brukes til beslutningsstøtte uten tilstrekkelige menneskelige kontrollpunkter.
En trusselmodell har liten verdi dersom den bare lages én gang og legges bort. Funnene må brukes til å formulere konkrete sikkerhetskrav, testbehov og kontroller i drift.
For eksempel kan en identifisert trussel føre til behov for:
For KI-systemer bør trusselmodellen også brukes når man vurderer endringer i modell, datakilder, promptmaler, evalueringssett og overvåking. Endringer her kan gi nye trusler selv om applikasjonskoden ellers er uendret.
Trusselmodellen må versjoneres og holdes oppdatert. Når en har identifisert trusler må mottiltak beskrives og effekten av disse vurderes. En vanlige tilnærming er å gi trusselen en verdi som indikerer alvorlighetsgrad, eksempelvis 1-10 der 10 er verst. Mottiltak vurderes tilsvarende, men med motsatt skala der 1 er liten effekt og 10 (eller opp til kritikalitet) er høyest effekt. Summen av disse gir en residuell risiko som sier noe om hva en sitter igjen med:
Identifiserte trusler Kritikalitet Mottiltak Gjenstående risiko
Trussel 1 8 8 0
Trussel 2 2 0 2
Trussel 3 4 3 1
Total 14 11 3
Når en har identifisert en risiko, er det viktig at den som eier denne risikoen involveres, da det er denne som har ansvaret for å påse at prosjektet leverer kvalitet i tråd med forventninger og krav.
Det er viktig at mottiltak valideres for at dette skal ha noen hensikt. Trusselmodellen bør hentes frem med jevne mellomrom for å se hvordan situasjonen har endret seg. Dersom total kritikalitet eller residuell risiko overstiger en grense, bør en vurdere nye tiltak.
For systemer i aktiv drift bør trusselmodellen også brukes når man vurderer hvilke hendelser som skal logges, hva som skal overvåkes og hvilke avvik som skal gi alarm. Dette gjelder særlig for KI-systemer, der misbruk, degradering eller uventet modellatferd kan utvikle seg gradvis over tid.
Når vi designer en løsning, er det viktig med gode og oversiktlige skisser og diagrammer som viser designet slik at det planlagt. Dette gjøres allerede av mange utviklerteam uten at det nødvendigvis stilles krav til det, men det er likevel greit å nevne her.
Systemskissene bør gi nok informasjon til at en i etterkant kan
Selv om det er mye som kan dokumenteres her, fokuserer vi bare på det viktigste her:
Dersom løsningen inneholder kunstig intelligens eller maskinlæring-modeller, må disse være eksplisitt dokumentert i systemdokumentasjonen:
Uten denne informasjonen er det vanskelig å få oversikt over risiko, dataflyt og compliance rundt AI-komponenter.
Under finner du eksempler på punktene listet ovenfor. Diagrammene du produserer trenger ikke å være like, det viktigste er at de inneholder nok informasjon til at de kan brukes for det tiltenkte formålet og at de er forståelige for teamet.
For enkelt å komme igang med design av diagrammer og skisser kan verktøy som Miro eller Draw.io brukes. Sistnevnte er gratis og tilbyr lagring av tegniner i nettleser, lokalt på maskinen som XML og mye annet.
Diagrammene trenger ikke å være perfekte, eller inneholde alle tenkelige detaljer. Vurder behovet og jobb med gradvise forbedringer over tid.
Den overordnede systemskissen viser de viktigste komponentene, og hvordan disse forholder seg til hverandre. Viktige avhengigheter merkes, slik at det er lett å få et overblikk over systemene.
Målet med nettverksdiagrammet er å vise topologien, med alle virtuelle nettverk, subnett og ressurser og åpninger mellom disse. Et godt nettverksdiagram viser flyten mellom tjenester og enheter, slik at andre involverte kan danne seg et bilde av hvordan data flyter fra punkt til punkt.
Nettverksdiagram bør lages for alle miljø, slik at en får nødvendig informasjon på alle ressurser i alle miljø, samt forbindelser mellom disse.
Dataflytdiagrammet fokuserer primært på datakildene, og viser hvordan data flyter gjennom systemet. En kan også inkludere overordnet informasjon om hvordan data transformeres eller modifiseres, slik at det er enklere å gå opp eventuelle avvik i etterkant.
Et IAM-diagram beskriver hvor brukerne kommer ifra, og hvilke roller som tildeles brukere og eventuelt tjenester eller enheter på de ulike ressursene.
Dette kan tegnes som et diagram, men kan like gjerne være i form av en enkel liste. Denne oversikten bør beskrive alle direkte avhengigheter for prosjektet, med et kort sammendrag av hvordan den brukes og hvorfor.