Beskyt dine applikationer med Zero Trust i Azure

22. august 2024

SÅDAN KOMMER DU I GANG MED ZERO TRUST-SIKKERHED I AZURE - Sikkerhed bliver vigtigere og vigtigere, og her er Zero Trust Architecture et essentielt element. Alle de store tech-leverandører, inklusiv Microsoft, snakker om Zero Trust. Men hvad kan Azure out-of-the-box? Og hvad er du selv nødt til at konfigurere?

It-sikkerhed kan inddeles i at beskytte brugere, devices og applikationer. Dette blogindlæg handler om beskyttelse af den sidste af de tre: Applikationerne.

Af Jesper Kristensen, Senior Lead Software Engineer

‘Never trust, always verify’

Hvad betyder Zero Trust helt præcist, hvorfor er det smart og hvordan kommer du godt i gang med at styrke din it-sikkerhed?

Alt sammen vil du blive meget klogere på med dette blogindlæg.

Hvad er Zero Trust?

Zero Trust er en it-sikkerhedsmodel, der skal sikre følsomme data og forbedre virksomhedens evne til at forsvare sig mod cyberangreb. Zero Trust er ikke en softwareløsning eller et enkeltstående system, men skal ses som et strategisk initiativ, der bygges ovenpå virksomhedens eksisterende it-arkitektur, uden at erstatte eksisterende teknologi.

Zero Trust er forankret i princippet ‘Never trust, always verify’.

Microsoft formulerer Zero Trust som tre sikkerhedsprincipper:

1. Verificér adgange eksplicit

2. Tildel mindst mulig adgang

3. Antag brud på sikkerheden

Hvad det betyder og hvordan principperne skal implementeres vil blive uddybet nedenfor.

1. Verificér adgange eksplicit

Første trin er at centralisere styringen af identiteter og adgange for både brugere, applikationer og devices. Her ser vi ofte virksomheder gå i faldgruber, såsom:  

Medarbejdere har adgang til systemer, bare fordi de er koblet på et bestemt netværk eller har en bestemt IP-adresse

Hver applikation har sin egen liste over brugere, som skal vedligeholdes manuelt, når en medarbejder starter, stopper eller skifter rolle

API-nøgler, der bliver sendt mellem applikations-teams over e-mail

På dette punkt har Microsoft med Entra ID en stærk løsning på markedet til at styre adgang til brugere, applikationer (workload identities) og devices (conditional access). 

Men når det kommer til at bruge Entra ID i resten af Azure, bliver det lidt mere komplekst. Der sker hele tiden forbedringer i Azure, så de fleste Azure services nu understøtter Entra ID. Men det er ikke alle Azure services, hvor det er muligt at slå de mindre sikre Shared Keys fra, og hvor alle klientbibliotekerne understøtter andet end shared keys. Eksempelvis hvis du skal udstille et API skal du bruge en App Registration, og her er det kun muligt at undgå en Shared Key hvis applikationen hostes uden for Azure. 

Det er bare en af mange snubletråde, man støder på, når man prøver at bruge Entra ID i Azure, og her snakker vi ikke engang multi-cloud eller hybrid-cloud, hvor det bliver endnu sværere. 

Azures store afhængighed af Shared Keys gør det vigtigt at håndtere disse keys. Dog arbejder Microsoft kontinuerligt på at forbedre situationen. En relativt ny feature i Azure ved navn Workload Identity Federation er en game-changer i cloud-sikkerhed. Funktionen kan dog indtil videre ikke bruges i Azure til Azure-integrationer, men kun i tredjeparter til Azure-integrationer, som vist i eksemplet med App Registrations oven for. 

2. Tildel mindst mulig adgang

Andet trin er at have de rigtige processer for at tildele og fratage rettighederne i det centrale directory. Enra ID er et komplekst værktøj med en stejl indlæringskurve. Man skal sætte sig grundigt ind i, hvad Entra ID kan for at kunne praktisere ’least privilege’ – altså mindst mulig adgang. 

Det er essentielt med effektive processer for tildeling af rettigheder, løbende review, overvågning og fratagelse af rettigheder, når de ikke længere er nødvendige. Her dækker understøttelsen i Entra ID sjældent hele behovet, men man kan bruge tredjepartsværktøjer sammen med Entra ID. 

Rettigheder handler ikke kun om brugere og standardsystemer. En integration mellem to systemer skal ikke give det ene system adgang til det andet systems database. 

Systemerne skal udstille eksplicitte interfaces med rettighedsstyring, der kun udstiller de dele af systemet, som integrationen har brug for, og det skal verificeres via Entra ID, om API’et bliver kaldt af den rette applikation. 

Hvis en angriber lykkes med at kompromittere et system, skal de eksplicitte interfaces sikre, at angriberen ikke kan bruge integrationen til at hoppe videre og inficere de integrerede systemer, hvilket leder os videre til tredje trin. 

3. Antag brud på sikkerheden

Tredje trin er at gå fra at beskytte netværket som helhed, og stole på alt hvad der er inden for netværket til at beskytte hver enkelt app og device under antagelse af, at angriberne allerede er inde på netværket og i nogle af vores applikationer.

Figuren illustrerer, hvordan vi bør gå fra at have tillid mellem interne applikationer til at have beskyttelse omkring hver enkelt applikation. 

Kryptering

Al kommunikation på netværket skal krypteres. Både udadtil og internt mellem applikationer. Det er nemt i Azure. Næsten alle Azure-services krypterer storage og understøtter HTTPS, og langt de fleste Azure-services understøtter efterhånden managed-certifikater. 

Der er dog stadig enkelte Azure-services, som f.eks. Application Gateway, hvor man skal håndtere certifikater delvist manuelt med den dertilhørende øgede risiko for fejl. 

Identity Aware Proxy

Vi skal væk fra en firewall baseret på manuelt konfigurerede lister over tilladte IP-adresser og portnumre, og i stedet bruge identiteter. I public clouds siger en IP-adresse ikke længere, hvem man er, da man typisk deler den med de andre kunder hos cloud-udbyderen. 

Betyder det, at man bare skal fjerne firewallen? Nej, man skal erstatte den med noget bedre. 

Google, som var de første til at benytte Zero Trust, kalder det for Identity Aware Proxy. Det går ud på at lægge en ny slags firewall uden om interne applikationer, som kontrollerer brugernes identitet og sikrer, at kun brugere (og andre applikationer) med adgang til applikationen kommer ind. Applikationen selv har sin egen kontrol af brugerens identitet, som kan være mere finkornet og sikre, at brugerne kun ser de data, de har adgang til. 

Identity Aware Proxy kan bygges ensartet omkring hundredvis af forskellige forretningsapplikationer. Den indeholder ikke forretningsmæssig kompleksitet, hvilket reducerer risikoen for fejl.  

Man kan lave automatiserede skanninger på tværs af sin infrastruktur for at sikre, at proxyen er konfigureret korrekt alle steder, hvilket ikke er muligt i samme skala, hvis man skal ind og studere koden i hver enkelt applikation. 

Hvis en applikation har en sårbarhed i rettighedslogikken, har vi begrænset skaden, så kun andre legitime brugere af applikationen kan udnytte hullet. 

Løsninger til Identity Aware Proxy i Azure

Google er ikke de eneste, der kan dette, f.eks. har Cloudflare et tilsvarende produkt ved navn Cloudflare Access, og Azure har flere løsninger. Se tabel.  

Det fragmenterede billede i Azure gør det sværere at danne sig et overblik over den samlede beskyttelse på tværs af systemer, og i nogle situationer er man nødt til at anvende tredjeparts-produkter som f.eks. Cloudflare Access. 

Det betyder også, at de fleste organisationer bør droppe den traditionelle firewall og VPN, når der er en Identity Aware Proxy. Ofte tager administrationen af en traditionel firewall og VPN så mange ressourcer fra it-sikkerhedsafdelingen, at de ikke har tid til vigtigere tiltag som Zero Trust. Legacy-systemer, der ikke overholder Zero Trust-principperne, vil eksistere i mange år endnu. Hvis man kan flytte så mange sikrede systemer uden for samme firewall som legacy-systemerne, mindsker man angrebsfladen mod legacy-systemerne. 

Men hvis man flytter interne systemer uden for firewallen uden at flytte dem ind bag en Identity Aware Proxy, så er det bare en simpel reduktion af sikkerheden og har intet med Zero Trust at gøre. 

Centraliseret logging

Hvis en applikation bliver kompromitteret, dur det ikke, hvis angriberen samtidigt kan manipulere logs og slette sine spor. Logs skal overføres i nær realtid til en centraliseret løsning, som applikationerne ikke kan slette fra, hvorfra man kan analysere og overvåge alle logs. Azure Monitor er et godt værktøj til dette. Azure Monitor har ikke den bedste UX i forhold til mere specialiserede tredjepartsløsninger, men det er integreret i alle Azure-services og understøtter alle de centrale dele, herunder metrics, logs og distributed traces, så man er fri for at have mange forskellige værktøjer for at få de samme features. 

Hold tæt øje med udviklingen

Azure har mange features til at understøtte en Zero Trust-arkitektur, men der er stadig mangler, som kræver custom udvikling eller tredjeparts-løsninger. Men udviklingen går stærkt, og Microsoft tilføjer hele tiden ny funktionalitet, så det er vigtigt hele tiden at følge med, da man ellers nemt ikke får brugt de indbyggede sikkerhedsfeatures i Azure. 

Opsummering

Som opsummering på, hvordan du kommer i gang med Zero Trust i Azure skal du igennem tre sikkerhedsprincipper.

Verificér adgange eksplicit: Brug et centralt directory over brugere, applikationer og devices (Entra ID)

Tildel mindst mulig adgang: Formuler gennemsigtige rettighedsprocesser

Antag brud på sikkerheden: Anvend HTTPS, en identity aware proxy og centraliseret logging (Azure Monitor)

Om Jesper Kristensen

Jesper er Senior Lead Software Engineer og har været en del af Immeo siden 2017. Han har masser af erfaring med at bygge cloud-løsninger i Azure. Han både designer og koder løsninger og elsker ny teknologi, og at se når systemerne skaber værdi.

Jesper har været med til at implementere blandt andet en integrationsplatform, en betalingsapp til mobil, en platform til at lave revisionsrapporter, og flere webshops.

Jesper er i øvrigt ivrig sejler og skiløber – og så var hans navn indgraveret i Firefox Monument på et gadehjørne i San Francisco indtil Firefox flyttede for nyligt.

M: jkr@immeo.dk | T: +45 2222 0257

Andre blogindlæg

It-sikkerhed: Har du husket at rulle dine nøgler?

Læs mere

Kan Azure Functions virkelig det?

Læs mere