Dette har dukket opp som et fornuftig sikkerhetskonsept i skyen, fordi alt mulig rart av tjenester og objekter surrer rundt og kan i prinsippet ta kontakt med hverandre. Dette prinsippet erstatter eller supplerer nettverkssegmentering med brannmurer. Det er altså ikke lenger nok at vi stoler på alt som har kommet innenfor denne muren, men vi stoler ikke på noen. Aldri.
Enheter
Sikring med Endpoint Protection, MDM, sertifikater og registrering.
Nettverk (TCP/IP)
Segmentering, VPN, TLS, brannmurer og IDS/IPS styrer hvem som får tilgang og på hvilken måte.
Programvareforsyningskjeden (software supply chain)
Sikring av alt fra biblioteker til containere, gjennom dependency-scanning, CI/CD-sikring og signering.
Interne tjenester (APIer)
Autentisering (MFA, SSO, token), autorisasjon, logging og overvåkning.
Åpne tjenester (APIer, banker, nettsider)
MFA, token, autorisasjon, samtykke, sikker tilkobling og overvåkning. Sikring både internt (egen organisasjon kan sperre) og eksternt.
Fysisk lokasjon (kontor, firma, land)
Sikkerhetskontroll og geopolitisk risiko kan påvirke tilgang.
Zero Trust-konseptet omfatter flere praktiske nivåer, men det er lett å dra det for langt når alle disse lagene skal kontrolleres og sikres. Resultat er byråkrati, ineffektivitet, dårlig samhandling, mistrivsel og lite innovasjon. Sikkerhetsopplæring er ofte bedre enn overdreven sperring, da lærer medarbeidere å ta fornuftige vurderinger. Hvis Zero Trust betyr mistillit fra ledelsen, mister ansatte tilliten til ledelsen.
Fra mine erfaringer som utvikler legges det for mye vekt på detaljert tilgangskontroll og minste privilegiums-prinsipp. Det fører ofte til unødvendige blokkeringer og tidstyver, som når lokal utvikling krever tilgang til sperrede nettsteder.
Å holde biblioteker oppdatert høres enkelt ut, men krever god DevSecOps for å fungere i praksis. Vi bruker mye tid på oppdateringer for sikkerhetshull som kanskje ikke berører oss. Samarbeidet mellom sikkerhet og utvikling fungerer sjelden godt; begge parter forstår for lite av hverandres hverdag.
Minste privilegium og Zero Trust krever en svært oppegående organisasjon for å administrere tilgang. Hvis ikke risikerer vi et dårligere og dyrere system. Et eget plattformteam med sikkerhetsfokus kan hjelpe, med noen få forhåndsdefinerte tilgangspakker for utviklere.
God sikkerhet koster mer og må planlegges inn fra starten sammen med testing. Risikoanalyse bør gjøres slik at innsatsen settes inn der det teller.
Sikkerhetskravene må tilpasses miljøet de gjelder for:
Skal utviklere ha rot-tilgang på egen maskin? Uten rottilgang kan utviklingstid gå tapt. Oppdateringer droppes lettere, noe som svekker sikkerheten. Risiko for misbruk ofte er nesten like stor uten rot tilgang. Lås uansett maskinen, så kan ikke angriper gjøre ugang via den lokale maskinen.
Men det er en kostnad før produksjonssetting og en større kostnad når noe går alvorlig galt.
Det to alvorligste sikkerhetsrisikoene er:
Årsak til ikke nåbart system kan være svikt i sikkerhets- og drifts-rutiner som kan gi overbelastning, nettverksfeil, hackerangrep, feil med tilgangskontroll eller utgåtte sertifikater. Merk at altfor rigide sikkerhetsregler noen ganger kan føre til utestengelser.
Skjulte alvorlige feil kan skyldes feildesign eller dårlig kode, som kan utnyttes av en angriper. Utviklere bør ha sikkerhetsopplæring med fokus på OWASP og Zero Trust. Det å være klar over ulike injection pattern er essensielt, samt grundig QA, testing og logging. Dette er mye viktigere enn Zero Trust rettet mot utviklere i form av blokkeringer.
God sikkerhet handler ikke bare om teknologi, men også om mennesker, tillit og samarbeid.