Kort svar
Zero Trust afviser idéen om, at noget er betroet bare fordi det er på "det interne netværk". Hver forbindelse skal autentificeres og autoriseres uafhængigt af, hvor den kommer fra. mTLS er den primære mekanisme på netværkslaget: ved at kræve at begge parter beviser deres identitet med et certifikat på hver eneste forbindelse, fjerner du netværksplacering som tillidsgrundlag. Identitet bliver kryptografisk, ikke topologisk.
Det gamle "castle and moat" og hvorfor det fejlede
Den klassiske model var en hård perimeter (firewall, VPN) og et blødt indre, hvor alt på det interne net implicit stolede på hinanden. Problemet: så snart en angriber kommer indenfor — via phishing, en sårbar service eller en kompromitteret leverandør — kan de bevæge sig frit sidelæns. "Internt netværk" blev forvekslet med "betroet".
Zero Trust vender det om: der findes ingen betroet zone. En forbindelse fra nabo-poden behandles med samme skepsis som en fra internettet.
Hvordan mTLS realiserer principperne
| Zero Trust-princip | Hvordan mTLS leverer det |
|---|---|
| Verificér eksplicit | Hver forbindelse kræver et gyldigt klientcertifikat — ingen anonyme kald |
| Stol ikke på netværket | Identitet kommer fra certifikatet, ikke fra IP eller netværkszone |
| Mindste privilegie | Certifikat-identiteten kortlægges til præcise rettigheder per service |
| Antag brud | Kortlivede certifikater begrænser vinduet hvis en nøgle lækker |
Workload-identitet: kernen i det hele
I Zero Trust skal hver workload have en verificerbar identitet. mTLS-certifikatet er den identitet. I moderne miljøer bindes identiteten ofte til en SPIFFE ID i certifikatets SAN — se mTLS i Kubernetes for hvordan SPIFFE/SPIRE udsteder dem. Pointen er, at identiteten ikke kan forfalskes uden den private nøgle, og at den følger workloaden uanset hvor den kører.
Identitet er ikke autorisation
Et almindeligt fejltrin: at tro, at "har et gyldigt certifikat" er nok. mTLS svarer på hvem er du, ikke hvad må du. En komplet Zero Trust-politik kortlægger certifikat-identiteten til konkrete tilladelser. I et service mesh udtrykkes det som en autorisationspolitik:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: payments-allow-checkout
namespace: payments
spec:
action: ALLOW
rules:
- from:
- source:
# kun checkout-servicens identitet maa kalde payments
principals: ["cluster.local/ns/shop/sa/checkout"]
to:
- operation:
methods: ["POST"]
paths: ["/charge"]
Her er principals den mTLS-verificerede identitet. Uden denne politik ville enhver gyldig identitet kunne kalde alt — det er autentificering uden autorisation, og det er ikke Zero Trust.
Den hårde del er ikke kryptografien — det er certifikaterne
Den dybe ironi ved Zero Trust er, at det udskifter ét tillidsproblem (netværket) med et nyt driftsproblem (en eksplosion af certifikater). Hver workload, hver service og hver intern CA har nu et certifikat med en udløbsdato. Et enkelt udløbet certifikat på det forkerte sted kan tage et helt forretningsflow ned, og fordi disse certifikater er interne og maskine-til-maskine, advarer ingen browser om dem.
Sådan holder du Zero Trust i live
En Zero Trust-arkitektur er kun så pålidelig som de certifikater, den hviler på. CertControl opdager og overvåger certifikater på tværs af hele jeres miljø — offentlige, interne, server- og klientcertifikater — sporer hver udløbsdato, validerer at kæderne er komplette, og advarer i god tid. Så bliver identitetslaget i jeres Zero Trust ikke det, der pludselig fejler. Start med hvad er mTLS og se gateway-til-backend-mønstret.
Ofte stillede spørgsmål
Er mTLS det samme som Zero Trust?
Nej. Zero Trust er et arkitekturprincip; mTLS er en teknik der hjælper med at realisere det på netværkslaget. Zero Trust omfatter også identitet for brugere, device posture og fingradet autorisation — mTLS dækker maskine-til-maskine-identiteten.
Kan jeg lave Zero Trust uden mTLS?
Du kan implementere dele af det med andre midler (fx token-baseret service-identitet), men mTLS er den mest direkte måde at få kryptografisk verificeret identitet på hver netværksforbindelse. De fleste Zero Trust-implementeringer på netværkslaget bruger mTLS.
Erstatter mTLS min firewall eller VPN?
Ikke direkte, men det reducerer afhængigheden af dem som tillidsgrænse. I en ren Zero Trust-model er netværksplacering irrelevant for tillid, så firewall/VPN bliver til segmentering frem for autentificering.
Hvorfor bruger Zero Trust kortlivede certifikater?
Fordi princippet "antag brud" tilsiger at begrænse skaden hvis en nøgle lækker. Et certifikat der kun lever 24 timer, er værdiløst for en angriber dagen efter. Det kræver til gengæld automatisk udstedelse og rotation.
Hvad er workload-identitet?
En verificerbar identitet knyttet til en kørende service eller proces — ikke til en bruger eller en IP. I mTLS-sammenhæng er det certifikatet, ofte med en SPIFFE ID, der entydigt identificerer workloaden.