GitLabs bud på Zero Trust Networking: »Vi stoler ikke på nogen overhovedet«
Zero Trust Networking (ZTN) er et begreb og en tilgang til it-sikkerhed, som har fået stigende opmærksomhed de seneste år.
Begrebet Zero Trust og de grundlæggende koncepter menes at være etableret af den tidligere Forrester-analytiker John Kindervag i 2010, men som vi vender tilbage til, begyndte diskussionerne allerede flere år før.
Google er nok den aktør, der har fået størst opmærksomhed for sin implementering af Zero Trust. Dette skete som et resultat af ‘Operation Aurora’, det kinesiske cyberangreb, som ramte Google og andre i slutningen af 2009.
Googles implementering hedder BeyondCorp. Hensigten var fra starten at gøre det muligt for alle Google-ansatte at arbejde fra usikre net uden at bruge VPN (Virtual Private Network).
GitLab
Et andet selskab, som har valgt at implementere Zero Trust, er GitLab. Selskabet omtaler sig selv som leverandør af en åben kildekode-baseret, end-to-end DevOps-platform til softwareudvikling. Selskabet blev etableret i 2011 og er en konkurrent til Microsoft-ejede GitHub. GitLab-platformen har millioner af brugere, hvoraf mere end 800.000 betaler for tjenesterne.
GitLab havde i begyndelsen af februar 1.175 ansatte fordelt på 66 lande. GitLabs it-systemer befinder sig i skyen, og selskabet omtaler sig selv som et 100 procent ‘remote-work’ selskab. Det har ingen kontorer.
Mark Loveless er senior-sikkerhedsforsker i GitLab. Han har en baggrund som hacker med forskellige farver på hatten, har dyb indsigt i GitLabs Zero Trust-arbejde og har både skrevet og holdt foredrag om dette emne.
Mange forskellige tolkninger
I et e-mailinterview med Digi.no fortæller Mark Loveless om de erfaringer, GitLab indtil nu har fået gennem denne proces, som dog ikke er fuldført.
Digi.no indledte interviewet med at bede ham give sin tolkning af, hvad Zero Trust Networking er. Loveless har nemlig tidligere udtalt, at alle leverandører, som tilbyder ZTN-løsninger, har deres egen tolkning.
»Min tolkning er centreret om det følgende: Bekræft, at brugeren er den, de siger, de er, bekræft, at enheden, som brugeren benytter, ikke bare er en kendt enhed, men at den er tilstrækkeligt sikret og sikkert konfigureret. Identificér de data, brugeren og enheden forsøger at få adgang til, kontroller, om adgangen er tilladt, tilføj alle krav specifikt for de data, der tilgås (sted, tidspunkt, etc.), tillad kun adgang til dataene, hvis samtlige krav er opfyldt. Det er det hele,« fortæller Loveless.
»For nogle er dette en ganske bred tolkning, men i virkeligheden er den mere kompleks, end den ser ud til at være, uden at specificere indlysende ting som firewalls, betroede netværk og VPN. Jeg nævnte heller ikke autentificering. Dette er implicit, idet jeg skal kunne bekræfte brugerens identitet, men noget af adgangen til data sker efter den første autentificering, så ZTN skal tage hensyn til dette,« skriver Mark Loveless.
Hvilke problemer er det meningen, at ZTN skal løse?
»Hovedproblemet, der skal løses, er at give adgang i situationer, hvor du ikke kan stole på det netværk, som brugeren kommer ind med, eller hvor du kun har en vag anelse om, hvor brugeren er, men har brug for at give adgang. Dette problem blev diskuteret i akademiske kredse og under konferencer så tidligt som i 2002, og jeg deltog aktivt i nogle af disse diskussioner. Strukturen for firewalls med VPN løste ikke problemet. Faktisk gav det en slags falskt håb, fordi administratorer troede, at de havde sikret deres omgivelser, men fortsat oplevede brud på sikkerheden.«
Er det nogle forventninger til ZTN, som det ikke kan indfri?
»Det her er ikke løsning, hvor du gør ting én gang, og så er du færdig. Du kan ikke implementere den og derefter bare glemme den. Løsningen er nødt til at være en del af en løbende proces.«
Hvem bør, og hvem (hvis nogen) bør ikke overveje at implementere ZTN?
»Hvis du har et frakoblet (‘air-gapped’) netværk uden forbindelser til den ydre verden med fuldstændig tillid til alle, der har adgang til netværket, er der ikke behov for ZTN. Men hvis du arbejder i et miljø, hvor du har mobile brugere eller du tillader adgang via en eller anden kanal (web, e-mail etc.), bør du overveje ZTN.«
Ingen færdig pakkeløsning
Mark Loveless har under foredrag sagt, at uanset hvad leverandørerne fortæller dig, så er der ingen, der har en komplet ZTN-løsning.
Betyder dette, at man som organisation skal lave sin egen pakke, som er tilpasset egne behov?
»Det betyder, at du ikke kan basere dig på kun én leverandør for at løse ZTN-spørgsmålet. Det fungerer ikke sådan, at du kan købe en løsning fra én enkelt leverandør, og så vil den dække alle og alt. Selv i Googles BeyondCorp-løsninger har Google ikke implementeret det hele, og de er nødt til at bygge dele af det,« skriver Loveless.
»Vi ser på løsninger, som kan dække et stort territorium, og som kan snakke med andre løsninger, eller i det mindste at vi kan få alle loggene i samme format og på samme sted. Der er åbenbart nogle huller, og vi regner med at samle nogle af de løse ender med selvudviklede løsninger. Dette er for mange it-organisationer ikke usædvanligt. Det at udfylde hullerne med skræddersyet kode er noget, som sker, og man må forvente, at dette også vil være tilfældet med ZTN.«
Andre fordele
De fleste vil overveje at benytte ZTN af sikkerhedsgrunde, men er der også økonomiske fordele?
»Det bedste eksempel, jeg kan give, inkluderer provisioning/deprovisioning. Vi bruger Okta og har forbundet dette til vores HR-system og mange andre SaaS-tjenester. Personaleafdelingen kan oprette en ny bruger og tildele denne en titel. Dette importeres til Okta, som kan ‘provisionere’ brugere i bogstaveligt talt dusinvis af SaaS-systemer via API’er. En proces, som tidligere tog to-tre uger at gennemføre, tager nu et par minutter,« fortæller Mark Loveless.
»Det samme gælder i forbindelse med ‘deprovisioning’. Vi kan fjerne en brugers profil i løbet af minutter på tværs af systemerne, når f.eks. en ansat forlader virksomheden. Dette er en sidegevinst set fra vores ZTN-standpunkt, men med besparelsen i arbejdstid og den forbedrede produktivitet vil denne type implementering bidrage betydeligt til bundlinjen.«
»Efterhånden som man arbejder videre med ZTN, åbner det for mere kontrol over dataene og adgangene, hvilket ofte er kernen i compliance. Som selskab kan vi se på, hvilke krav et marked har, fra et revisions- eller compliance-perspektiv, og nemmere implementere politikker, som giver os mulighed for at gå ind i disse markeder. For at gøre det enkelt kan vi vælge de strengeste krav og tage disse politikker i brug globalt. I mange tilfælde lever vi let op til revisions- og compliance-kravene på nye brancher eller markeder. Den rigtige tilgang til adgangskontrol gør dette muligt, og ZTN har en stærk adgangskontrolkomponent.«
Er ZTN som tilgang kompatibel med de fleste cloudtjenester?
»Fuldstændig. Vi er 100 procent cloud, og vi er i stand til at implementere ting uden problemer.«
Kategorisering af data
Er ZTN kompatibel med ‘Bring Your Own Device’?
»Det afhænger af dine politikker. Hos GitLab er der dele af vores organisation, som er fuldstændig åbne, inklusive vores kernesoftware og manual. Da disse data er offentlige, tillader vi adgang til dem uden begrænsninger og opmuntrer til BYOD på dette område. Denne arena er ikke kun for ansatte. Den er for alle på internettet, som ønsker at bidrage,« fortæller Loveless.
»Vores data er kategoriseret fra rødt (de mest sensitive), via orange og gult til grønt (offentlige). Vi mener, at der er områder, hvor vi kan aftale, at ansatte med BYOD-enheder får adgang til nogle dele af vores data, og vi forsøger at arbejde på måder, som imødekommer disse behov. Normalt er det ikke noget problem, at BYOD-enheder får adgang til grønne data, og sandsynligvis også visse gule data. Mobiltelefoner er en særlig interessant forhindring, der skal overkommes,« tilføjer han
»Orange og specielt røde data bør kun kunne tilgås af betroede enheder, så der er BYOD udelukket. Vi arbejder fortsat på at håndtere BYOD – det gør alle virksomheder – men fordi det er denne virksomhedskultur, vi er startet med, forsøger vi at bygge videre på det i stedet for at rive eksisterende metoder ned. Det er en interessant linje, vi følger, hvor vi forsøger at møde brugernes, kundernes, revisorernes og ledelsens behov. Vi har nogle ideer om, hvor vi potentielt kan bruge BYOD, og hvor vi ville foretrække det, men det er et arbejde, som fortsat er i gang,« skriver Mark Loveless.
Udfordringer
Baseret på din erfaring, hvad mener du så er de mest almindelige og de vigtigste udfordringer under planlægnings- og implementeringsfaserne?
»Den største udfordring er kommunikation. I visse tilfælde indebærer dette store ændringer for slutbrugerne, og en sikkerhedsperson, som udtaler sig med sikkerhedsbegreber, giver meget lidt eller ingen mening for dem i salgsafdelingen for eksempel. Alt skal være på et sprog, som alle kan forstå. Vi fandt ud af, at det at involvere slutbrugerne er afgørende for at opnå succes,« fortæller Mark Loveless.
Hos GitLab har I arbejdet med implementeringen af ZTN i et stykke tid. Hvor langt er I kommet, og vil I på et tidspunkt kunne sige, at implementeringsfasen er forbi?
»For hver nye implementering af teknologi skal du integrere gammelt med nyt. Implementering er en udvidet proces. Lige nu har vi fået gennemført det meste af brugerautentificeringen, dataklassificeringen er stort set gennemarbejdet, og vi ser ud til at have fået styr på provisioning og deprovisioning. Sikkerheden i de forskellige systemer var allerede temmelig god – det handlede bare om at integrere det mere formelt i en ZTN-proces.«
Vanskeligt problem
»Vores næste store forhindring er at behandle automatiserede processer, akkurat ligesom vi behandler brugere, ved at de kræver et eller andet autorisationsniveau, før kørsel,« skriver Mark Loveless.
Han omtaler dette som et af de virkelig vanskelige problemer, særligt hvis man har en bruger, der opretter en proces, som køres periodisk og kræver autentificering og nøgler.
»Hvad nu, hvis brugeren får nye opgaver eller til og med ny arbejdsgiver? Skal den automatiske proces stoppes? Flytter du den til en anden bruger? Hvad nu, hvis den er kritisk? Det er store spørgsmål, især hvis du forsøger at knytte delene sammen, som i vores tilfælde med Okta-autentificering, dataklassificering og nu denne automatiserede kodedel.«
»Dette alene gør, at jeg ikke kan forestille mig, at vi nogensinde bliver færdige. Vi ændrer os konstant, så jeg vil forvente, at enhver ZTN-løsning vil være en kontinuerlig proces,« skriver Mark Loveless
Kan ZTN skabe nye udfordringer eller problemer for den daglige drift, som vil være enklere at løse uden ZTN?
»Hvis vi støder ind i noget af den slags, vil det ikke blive implementeret. Vi forsøger meget at undgå dette allerede i planlægningsprocessen.«
Betydning for brugerne
Hvad med brugerne i alt det her? Hvordan påvirker ZTN brugernes mulighed for at udføre deres daglige opgaver?
»Målet med enhver ZTN-implementering, eller enhver anden sikkerhedsløsning for den sags skyld, bør være at gøre brugernes liv enklere. Det sker på to måder – de bør kunne føle sig sikrere, og ting bør være nemmere for dem. Det sidste er kritisk, for hvis du gør tingene for komplekse, vil brugerne gøre alt, hvad de kan, for at omgå dette. Hvis du gør det enklere for slutbrugeren, vil de indrette sig. Hvis du kan demonstrere, at noget har fordele, som kan øge produktiviteten, selv om det indebærer et ekstra trin, er det guld værd for dem,« afslutter Mark Loveless.
Artiklen stammer fra Digi.no.

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.