17. december 2024

Zero trust: Din nøgle til en sikre fremtiden i en Kubernetes-verden samt andre steder

Tænk et øjeblik over dit Kubernetes cluster. Forestil dig, at en ubuden gæst finder vej ind. Ved du præcis, hvad de kan tilgå? Eller endnu værre, hvis de har sneget sig ind i en af dine containere, hvad er så risikoen? Denne bekymring er ikke kun teoretisk; virkeligheden viser, at trusler mod vores digitale “ridderborge” vokser i takt med, at flere virksomheder flytter deres operationer online.

Læsetid: 7 minutter

Forskning afslører en voksende tendens: Flere virksomheder ser behovet for zero trust. Alligevel står mange over for betydelige udfordringer i implementeringen – næsten halvdelen af alle virksomheder ser det som en stor hurdle. Traditionelt har en solid ydre firewall været et tilstrækkeligt forsvar. En enkelt mur, en nøgle, en barriere – det var alt, vi troede, der skulle til for at holde fjenden ude. Men tiderne ændrer sig, og denne strategi holder ikke vand i længden. Vi hører oftere om virksomheder, der mister data eller bliver ramt af ransomware, fordi de indre forsvarslinjer simpelthen er for svage.

Den digitale borg

Analogien med en gammeldags ridderborg er ganske passende. Forestil dig en borg med en enkelt bro over voldgraven. Med soldater til at inspicere enhver, der krydser broen, føler man sig sikker – indtil en fjende finder vej ind. Pludselig er intet sikkert; fjenden kan frit bevæge sig rundt og plyndre alt fra små tyvekoster til kongerigets kronjuveler.
Det er her, zero trust-strategien kommer ind i billedet, en moderne tilgang, der beskytter din digitale borg langt mere effektivt. Med zero trust antager vi, at fjenden allerede kan være inden for murene. I stedet for at fokusere al sikkerhed ved porten, sikrer zero trust, at hver eneste bevægelse inden for borgen kræver ny godkendelse – ingen får lov til at bevæge sig frit uden den rette tilladelse.

Så hvad er zero trust egentlig?

Zero trust går ud på, at vi antager, at “nogen” altid kan finde en vej ind forbi vores digitale mure – vores firewalls. Fra dette udgangspunkt tager vi vores forholdsregler, så vi præcist ved, hvad der skal gøres, hvis en ubuden gæst alligevel skulle finde vej ind. Dette princip kaldes ofte for “assume breach”, hvilket betyder, at vi opererer under antagelsen om, at vores forsvar allerede er blevet brudt.

I en zero trust-model låses alt ned, og hver eneste adgangsforsøg kræver verifikation. Dette indebærer en nøje gennemgang af brugere og deres rettigheder, hvor kun de mest nødvendige privilegier tildeles. Det sikrer, at kun de rigtige personer, under de rigtige omstændigheder, får adgang til de rigtige data – intet mere, intet mindre.

Ridderborgen genopfundet

Lad os vende tilbage til vores ridderborg-analogi. Med zero trust ville vi opdele borgen i flere mindre sektioner, hver med sin egen låste dør. Kun dem med et ægte ærinde (og de nødvendige rettigheder) kan bevæge sig fra det ene område til det andet. Dette tilføjer et ekstra lag af sikkerhed, da en indtrænger ikke længere frit kan bevæge sig rundt og udnytte systemets ressourcer.

Heldigvis er implementeringen af zero trust-princippet langt mindre komplekst i IT-verdenen, end det ville være i en fysisk ridderborg. Ved at anvende moderne teknologier og strategier kan vi opbygge en digital infrastruktur, hvor sikkerheden er indbygget på hvert niveau, og hvor hver handling kræver bekræftelse af identitet og rettigheder.

Uden zero trust sikkerhed

Tillid gives ofte implicit, baseret på brugernes placering og netværkskontekst
Fokus på stærk ydre grænse med mindre fokus på intern segmentering
Bruger ofte enkeltfaktor-autentificering og tildeler brede adgangsrettigheder baseret på roller
Adgangsrettigheder er ofte foruddefinerede og kan være bredere end nødvendigt
Mindre intens overvågning, primært fokuseret på eksterne trusler
Adgang baseret på brugernes rolle og placering uden nøje kontekstuel evaluering
Kryptering implementeres måske ikke konsekvent, hvilket kan udsætte data for risiko

Med zero trust sikkerhed

Alle brugere og enheder anses som potentielle trusler, og adgang kræver kontekstuel autentificering
Mikrosegmentering isolerer og begrænser bevægelsen af trusler
Kræver multifaktor-autentificering som standard
Adgangsrettigheder er granulære og tilpasses efter mindste privilegiumsprincippet
Konstant overvågning af brugeradfærd og netværkstrafik for mistænkelig aktivitet
Adgang baseret på kontekstuelle faktorer som brugeradfærd, enhedstilstand og placering
Anvender kryptering for at beskytte data under overførsel og hvile

Sikkerhed

Det handler ikke kun om, hvordan man kommer ind, men hvad der sker, når man er kommet ind. Med zero trust sættes der firewall på alt, så det kun åbner for præcist det, der er brug for.

Generelt er sikkerhed blevet meget komplekst, og zero trust hjælper med at simplificere sikkerhed med en strategisk proces og automatiserede værktøjer, der verificerer alle aktiviteter, arbejder med kun at give adgang til det nødvendige og benytter avanceret undersøgelse og reaktion på trusler.

KvalitetsIT’s arbejde

I stedet for at man selv skal ændre alle individuelle steder via en brugergrænseflade, benytter vi en konfigurationsfil (Configuration-as-Code (CaC)), der automatisk bliver rullet ud og gør sig gældende alle de rigtige steder.

Typisk etablerer vi lidt a la nedenstående:

Firewall mellem alle services, så man eksplicit skal åbne for adgang.
Auth mellem alle services, så vi kun giver adgang til de rigtige brugere med de rigtige roller.
TLS internt til f.eks. Kafka og Postgres, så kommunikationen til køer og databaser også er sikret.
TLSv1.3 fra www til public services (vi tillader også TLSv1.2, det kommer dog an på kunden).
Wireguard kryptering af netværk mellem alle VMer.
Kryptering af data på disk.

Som det fremgår, så er der faktisk mange lag af låse i forhold til eksemplet med borgen.

Endnu mere konkret, så gør KvalitetsIT typisk som følger:

Vi installerer og konfigurerer en firewall mellem alle services. Default er, at intet er åbent. Typisk er det Calico vi bruger til dette.
Vi åbner for services og ikke porte.
Vi autentificerer alle kald af services. Det kan være på roller eller endnu mere fingranuleret, hvis der er brug for det. Typisk anvender vi Keycloak og OIDC til dette.
Alt kommunikation er TLS v1.3 beskyttet – også den interne, hvor det er muligt.
Alt netværkstrafik mellem VM’er er krypteret med Wireguard.
Data på diske er krypteret, hvis det er relevant.
Automatisering af hele opsætningen af alt det ovenstående er nøglen til at få det til at fungere i praksis, så det hele ligger i konfigurationsstyringen og er under versionskontrol. Typisk Github.

Network policy

Et eksempel på en konfiguration, som vi sidder med, er konfigurationen af firewall (network policy). Den beskriver, at der må komme trafik ind fra internettet (ingress-nginx) og infrastrukturer til opsamlingen af metrics, og trafik ud til at lave DNS-opslag og beskedkø (Kafka). Resten er der ikke åbnet for.

netpol:
    ingress:
      ingress-nginx:
        namespaceSelector:
          kubernetes.io/metadata.name: kube-system
        podSelector:
          app.kubernetes.io/instance: rke2-ingress-nginx
        ports:
          8080: TCP
      metrics:
        namespaceSelector:
          kubernetes.io/metadata.name: infrastructure
        ports:
          8081: TCP
    egress:
      dns:
        ipBlock: 10.43.0.10/32
        ports:
          53: UDP
      kafka:
        namespaceSelector:
          kubernetes.io/metadata.name: message-streaming-services
        podSelector:
          strimzi.io/cluster: test2
          strimzi.io/kind: Kafka
        ports:
          9093: TCP

Når man ser på ovenstående eksempel, er det klart, at automatiseringen ikke må undervurderes. Der er rigtig mange komponenter, der hver især skal åbnes for, for at det samlede system fungerer. Hvis man skal gøre det i hånden og ikke mindst vedligeholde det i hånden, så bliver det en kæmpestor opgave og risikoen for manuelle fejl er høj. Og laver man en fejl, er det faktisk rigtig rart blot at kunne gå tilbage til den tidligere version med et klik, frem for at skulle rode med Word-dokumenter og backup filer for at genskabe en tidligere version. Man kan gå tilbage til den tidligere version på et par minutter, frem for timer.

Vi implementerer zero trust med Kubernetes, der bruger container-baserede applikationer, der gør det nemmere at styre og overvåge.

Vi har sat Zero trust op for kommuner, regioner, små og store private virksomheder, og vi har sat det op inden for forskellige brancher herunder blandt andet healthcare.

Det er ikke nemt at holde styr på sikkerheden, og nogle gange kan man tage sig selv i at gøre alt arbejdet manuelt, fordi det virker mindre kompliceret end at lave et system, der gør det for dig. Derfor kan du overlade den generelle opsætning til os, mens du selv fokuserer på det forretningsnære.

Er du klar til at tage sikkerheden til det næste niveau og sikre dit Kubernetes cluster mod ubudne gæster? Kontakt KvalitetsIT på telefon 51148767 for en uforpligtende snak om, hvordan vi kan implementere en zero trust-arkitektur i din organisation. Sikkerhed er en rejse, ikke en destination, og med zero trust er du et skridt foran truslerne.

Forfatter

Headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Headline