Zero Trust-modellen - En genomgång

Zero Trust (ZT)-konceptet dyker upp i allt fler sammanhang. Dessvärre är det svårt att hitta dokumenterade erfarenheter av att arbeta med ZT. I den här artikeln gör jag ett försök att beskriva, förklara och reducera konceptet till sin absoluta essens. Jag utgår ifrån de artiklar och rapporter som beskriver riktiga försök att införliva ZT-modellen i verkligheten.

Målsättningen har varit, och fortsätter vara, en artikel som kan utgöra en grund för diskussioner om ZT och kanske även bidra med lite inspiration till eventuella försök att tillämpa principerna i verkligheten. Förhoppningsvis får jag också möjlighet att omvandla den här artikeln till en serie av artiklar, där jag i senare delar fokuserar och beskriver riktiga försök att bygga ZT-inspirerade arkitekturer.

Jag hoppas att du finner artikeln intressant och att den bidrar till ökad förståelse för ZT-konceptet och hur det eventuellt kan hjälpa dig och din verksamhet att bli mer motståndskraftiga från cyberangrepp.

Mycket nöje! / Christoffer

1. Essensen

Zero Trust innebär att du resonerar och tänker lite annorlunda kring hur användare i en verksamhet ska få åtkomst till digitala resurser (information, data, applikationer, tjänster). Det är en kombination av relativt enkla (i teorin) principer som vägleder dig i design, implementation och val av skyddsåtgärder. Det här ny-gammla synsättet kan någorlunda väl sammanfattas i följande överordnade principer:

1. Utgå ifrån att alla nätverk är osäkra , även företagsnätverket.
2. Säkerställ att användare och enheter kontrolleras och autentiseras kontinuerligt.
3. Och att alla åtkomstförsök utvärderas dynamiskt och kontinuerligt .

Lyckas du tillämpa dessa principer inom ramen för din IT-användning har du en principiellt äkta Zero Trust-arkitektur. Givetvis är det i detaljerna vi finner utmaningarna och det är sällan på den principiella nivån vi stöter på särskilt många problem.

2. Inledning

Zero Trust är just nu (2021) kanske ett av cybersäkerhetens absolut mest populära och hippa begrepp; alla (nåja, många gör det) talar om det. Ibland vill jag tro att sök & ersätt har blivit en marknadsföringsstrategi eftersom begreppet förekommer på alla möjliga ställen. Företag efter företag markadsför sina ZT-produkter och tjänster. Men som jag förklarade i essensen är ZT varken en produkt eller tjänst, det är ett sätt att tänka.

Oaktat huruvida ZT är en uppsättning produkter, tjänster eller mentala modeller verkar många vara intresserade av vad man kan göra för att bygga en Zero Trust-arkitektur. För att tillmötesgå detta upplevda behov har jag valt att kasta om avsnitten i den här artikeln och direkt efter den här kortare inledningen gå till det praktiska.

Ett varningens ord innan vi går vidare. Detta är en artikel, av en person. Självklart kommer inte jag i en artikel kunna förklara allt som behöver göras, alla problem ni kommer stöta på. Kanske främst för att jag saknar den totala erfarenhet som skulle krävas. Men jag kan förhoppningsvis ge dig en någorlunda vettig inriktning. Google påbörjade sin ZT-resa för många herrans år sedan och de har investerat massor med pengar, tid och resurser för att transformera sig själva. Och nu talar vi om Google där förutsättningarna finns för en sådan här fullständig och teknisk transformation.

Det är således kanske vettigt att sträva mot att efterleva principerna och betrakta resan mot en ZT-arkitektur som målet. Blickar vi framåt tror jag ytterst få företag kommer att nå en “äkta” ZT-arkitektur. Men jag hoppas få ha fel!

Och skulle det nu vara så att du är som jag kanske du föredrar en teoretisk introduktion? Börja då helt enkelt i det teoretiska-avsnittet och hoppa därefter tillbaka till det praktiska-avsnittet .

3. Praktiskt

Det här praktiska avsnittet är kanske inte praktiskt på det sätt du kanske skulle förvänta dig med förslag på konkreta produkter och tjänster. Nej, så blir det inte. Fokus här blir istället på de praktiska och mer konkreta typer av komponenter du kommer behöva för en ZT-arkitektur. Utmaningarna med att bygga de här fundamenten är många och det kommer ta tid. Det är tyvärr relativt enkelt för mig att skriva om de här grundkomponenterna eftersom jag inte behöver ta hänsyn till alla tusen olika situationer som kan uppstå vid ett införande.

För att överhuvudtaget kunna få till en fungerande ZT-arkitektur finns det några fundamentala byggstenar som behöver finnas på plats. Och det kommer behöva byggas stegvis, över tid… lång tid. Givetvis kommer våra respektive resor mot en ZT-arkitektur variera stort, men fundamenten är fortfarande likadana.

1. Du behöver kunna tillhandahålla unika identifierare för enheter, användare och resurser.
2. Du behöver ett centralt inventarie som beskriver användares, enheters och resursers aktuella “tillstånd”.
3. Du behöver centralt kunna styra alla åtkomstförsök utifrån en kombination av användare, enhet och resurs.
4. En algoritm för tillitsberäkning och nivåer av tillit.

Tillåt mig nu ägna lite tid åt att grotta i de här byggstenarna.

3.1 Identifiera enheter och användare

De flesta verksamheter har någon form av möjlighet att identifiera och autentisera sina användare, exempelvis och vanligtvis med hjälp av ett användarnamn och lösenord. I sammanhang av ZT, eller egentligen överhuvudtaget, är detta (användarnamn/lösenord) en mycket svag metod för att autentisera en uppgiven och tilldelad identitet. Det är dock en problematik jag inte känner något större behov av att förklara närmare.

Det första steget i sammanhang av ZT-principerna skulle således vara att ta stegen mot bättre identiteter som autentiseras med hjälp av bra metoder. Den kanske vanligaste vägen till detta är att rulla ut en egen Public Key Infrastructure (PKI) för bättre identiteter. Dessa identiteter är inte endast avsedda att tilldelas en användare utan även enheter och resurser.

Efter att det finns en förmåga att skapa unika identiteter för användare, enheter och resurser blir nästa steg att etablera förmåga att autentisera identiteterna. Det finns många sätt att autentisera en identitet. I sammanhang av en PKI och certifikat handlar det om hur du väljer att hantera den privata nyckeln som “bevisar” att användaren faktiskt är “ägare” till den uppvisade identiteten.

3.2 Centralt inventarie för användare, enheter och resurser

En av principerna bakom ZT är att åtkomstförsök utvärderas dynamiskt och kontinuerligt. Anledningen till varför varje åtkomstförsök ska kontrolleras är för att tillit, alltså den nivå eller grad vi litar på något, är dynamisk och ändras över tid. Antag följande:

En användare autentiserar sig med hjälp av OTP och får tillbaka en sessionskaka som kopplas till användarens sätt att autentisera sig. Informationen om hur användaren autentiserade sig behöver lagras någonstans. Här ser vi första behovet av det auktoritära inventariet över användare.

Antag vidare att användaren är så finurlig att hen lyckas installera skadlig kod på sin dator. Den skadliga koden stjäl sessionskakan och försöker återanvända denna. Men i åtkomstförsöket (som använder den stulna sessionskakan) visar det sig att anslutningsförsöket kommer från en helt annan IP-adress helt plötsligt. Och anropen sker från Firefox istället för Google Chrome.

Antag att användaren aldrig tidigare autentiserat sig från en enhet med Firefox, det är alltid Google Chrome. Attributen som beskriver användaren innehåller exempelvis information om vilka user-agents användaren tidigare använt. Om denna helt plötsligt ändras skulle detta kunna föranleda en fråga om förnyad autentisering.

All sådan här information om användaren behöver lagras någonstans och det är precis detta som inventariet syftar till att ge dig.

Och samma sak gäller givetvis för enheter som används inom verksamheten. Du behöver veta exakt vilka enheter som används, för utan denna kunskap kan du inte uppfylla principen om att användare och enheter är autentiserade. Inventariet ska innehålla den här informationen.

Inventarierna behöver kontinuerligt uppdateras med färska data om enheterna och deras tillstånd. Inventariet kommer sedan användas för att avgöra om en enhet är betrodd, vilka grundläggande rättigheter den ska tilldelas osv. Eftersom samtliga åtkomstförsök ska kontinuerligt utvärderas är det i huvudsak access-proxyn som använder informationen från inventarierna. Mer specifikt är det komponenten för beslut om åtkomst (PDP; Policy Decision Point) och tillitsalgoritmen som använder informationen i inventarierna.

3.3 Central styrning av åtkomstförsök

Enkelt förklarat så är det i Googles BeyondCorp access-proxyn som står för kontroll av alla åtkomstförsök mot någon av alla tillgängliga applikationer och tjänster. Detta är den absolut mest komplexa delen av att realisera en ZT-arkitektur för det omfattar teknologi som sträcker sig över hela stacken; från hur du lagrar och hanterar certifikat på enskilda enheter, till hur enskilda applikationer ska konstrueras och tillgängliggöras genom access-proxyn.

Först och främst måste applikationer standardiseras och konstrueras på ett sätt.

3.4 Tillitsalgoritm och tillitsnivåer

Sist men absolut inte minst är den centrala delen av hur du ska räkna ut tillit. Någonstans behöver du kombinera allt du känner till om en användare, enhet och resurs. Kombinationen resulterar i en form av tillitsvärde, hur mycket du kan lita på ett åtkomstförsök och huruvida det ska tillåtas.

Google har valt att införa ett antal tillitsnivåer för enheter. De har även ett system (Trust Inferer) som dynamiskt och kontinuerligt sätter den högsta tillitsnivån för en enhet. Därefter sätter de upp vilken tillitsnivå som är minimum för att komma åt en given resurs. Här kommer du behöva lägga mycket tid på att utforma ett språk för åtkomstkontroll (ACL), hur de olika komponenterna ska samverka.

Men tyvärr kan jag inte skriva så mycket mer om trust-algoritmen för den finns inte beskriven någonstans

4. Teoretiskt

Välkommen till det teoretiska avsnittet. Här kommer jag fokusera betydligt mer på bakgrunden till ZT, och utmaningarna med att skriva en sådan här artikel. Min yttersta målsättning är att komma åt essensen kring ZT och sedan försöka se hur en “modern” arkitektur kan manifesteras utifrån essensen. För mig är det således viktigt att försöka hitta några mer överordnade principer som ramar in ZT-begreppet. Utöver dessa principer skulle jag vilja identifiera och beskriva grundkomponenter som rimligen behöver finnas med i en ZT-inspirerad arkitektur.

Och så kommer vi till det här med verklighetsförankring. I något så hett som ZT kan det vara rätt svårt att skilja på vad som är fluff, rappakalja eller eventuellt vettigt. En av de faktorer som gör att vi kan särskilja mellan dessa kategorier av källor är huruvida de faktiskt är rotade i verkligheten. Finns det några indikationer på att det som beskrivs har implementerats? Finns produkterna, tjänsterna eller resonemangen i en verklig arkitektur?

Antag att du skulle springa ett maratonlopp. Skulle du lyssna till någon som har skrivit om att springa ett maraton men som faktiskt inte har gjort det, eller skulle du lyssna till någon som har sprungit ett maraton men som inte har skrivt om det?

Retorisk fälla. Det finns ju bara ett svar där givetvis. Vi lyssnar på dom som har gjort det på riktigt. Och vad innebär det då för den här artikeln? Jag har ju inte byggt en ZT-arkitektur, få har gjort det. Men vi kan försöka sammanställa informationen från de som har (återigen, de är få).

4.1 Utgångspunkten är företag med riktig erfarenhet

Jag känner till ETT företag, kanske två, som dokumenterat delar av sina respektive resor mot en arkitektur inspirerad och baserad på ZT-principer. Det första företaget är Google genom sitt BeyondCorp och så verkar faktiskt Microsoft ha gjort en resa. Microsoft-dokumentation är dock mer säljig än vad Googles är. Läser du artiklarna Google har publicerat om BeyondCorp framgår det ganska snabbt (anser jag) att deras resa har varit enormt omfattande och komplicerad. Det har krävts rejäla teknologiska och utvecklingsmässiga insatser för att nå målet.

Och då talar vi om Google där det känns som att de flesta anställda doktorerade redan i förskolan efter att de först uppfunnit ett nytt programmeringsspråk och frilansat som hjärnforskare. Detta ungefär samtidigt som jag själv fick diplom för att jag kunde knyta skorna. Hur som helst. En förflyttning till en “äkta” ZT-arkitektur kräver enorma insatser och även idag har få företag musklerna som krävs för detta.

Oaktat nödvändiga muskler behöver jag formulera några kriterier för vilken information jag utgår ifrån i en diskussion om ZT. En endast teoretisk beskrivning är kanske i sig intressant, men jag har valt att i huvudsak prioritera information och data från källor där det finns en koppling till äkta ZT-erfarenhet. Källor där det finns förståelse för utmaningarna och komplexiteten.

Jag har svårt att inkludera information och material från leverantörer som inte själva förklarar hur de gjorde sin egen resa till en ZT-arkitektur. För låt oss vara ärliga här, de flesta produkt- och tjänsteleverantörer som säljer något med marknadsföringstaggen “ZT” har högst sannolikt inte själva gjort resan till en “äkta” ZT-arkitektur. Nej, jag har inga belägg för det. Men jag baserar det på Googles berättelse om resan, och min personliga erfarenhet av IT och då främst cybersäkerhet. Det är en tuff resa helt enkelt.

4.2 Historik och bakgrund

Essensen av ZT tänker jag hävda egentligen inte är något nytt. Principerna har rötter som går tillbaka till 1960-talet när det talades om saker som reference monitor, och segmentering av arbetsminnet i en dator.

Reference monitor-konceptet beskriver en central komponent i ett operativsystem som utvärderar samtliga anrop som sker i ett operativsystem mellan processer och operativsystemets tillgängliga resurser. ZT-inspirerade arkitekturer ska ha en centralt bestämmande och beslutande komponent som avgör om en begäran från ett subjekt mot en resurs ska tillåtas eller inte.

Segmentering av arbetsminne handlade om hur tillgängligt arbetsminne i en dator skulle kunna delas av flera samtidigt exekverande processer (program). Segmenteringen ville avgränsa och förhindra att en process skulle kunna läsa eller skriva till en annan process minne. Ursprunligen handlade det faktiskt om hur information av olika klassificering (secret, top-secret osv.) skulle kunna behandlas i samma minne.

I en ZT-inspirerad arkitektur vill vi endast tillåta att kommunikation kan ske mellan en användare/enhet och begärd resurs, och inget annat. En användare och dennes dator ska endast kunna nå exakt de resurser som den har rättigheter att nå, ingenting annat. Och varje försök till åtkomst ska utvärderas och godkännas. Detta kan vi uppnå genom exempelvis mikrosegmentering, dynamiska E2E-tunnlar osv.

I sammanhang av ZT brukar det ofta dyka upp referenser till Forrester och deras John Kindervag som 2010 skrev en serie av rapporter om ett nytt paradigm för informationssäkerhet. Den rapport¹ som John skrev gör han vissa observationer kring tillståndet i informationssäkerhetsbranschen.

1. Hotbilden är förändrad, aktörerna finnas många gånger redan på insidan.
2. Modellen för tillit (trust) är trasig. Vi borde verifiera och därefter lita på, men många börjar med att lita på mjukvaror, leverantörer, tjänster och påståenden. Trust but verify har blivit… trust and sometimes verify.

Rapporten är överlag tämligen “nätverks”-centrisk och fokuserar mycket på hur trasiga nätverk är med massa paket som susar runt på nätverken utan att egentligen kunna identifieras och autentiseras utöver vilken IP-adress de kommer ifrån. Vi kan inte längre lita på våra nätverk och ska därför betrakta alla nätverk är osäkra .

Så vilka är då principerna bakom Zero Trust och vad innebär dom för oss dödliga?

4.3 Principerna bakom Zero Trust

Målsättningen med en ZT-inspirerad arkitektur är att göra cyberangrepp avsevärt mycket mer svåra att genomföra. Samtidigt ska angreppen bli enklare att upptäcka genom att avvikelser från normalbilden blir tydligare.

Visionen är att uppnå en tillvaro där varje begäran från ett subjekt (användare, process, server osv.) till en resurs (information, applikation osv.) utvärderas varje gång med utgångspunkt i ett antal attribut som troligen förändras över tid.

Vi skulle kunna säga att det finns tre huvudsakliga principer i en ZT-inspirerad arkitektur:

1. Utgå ifrån att alla nätverk är osäkra , även ditt företagsnätverk.
2. Säkerställ att användare och enheter kontrolleras och autentiseras kontinuerligt.
3. Alla åtkomstförsök utvärderas dynamiskt och kontinuerligt.

4.3.1 Princip 1 - Alla nätverk är osäkra

Det första mentala skiftet du måste göra är att börja betrakta ditt företagsnätverk som osäkert. Du ska inte implicit tilldela enheter som befinner sig på “insidan” som mer säkra, eller mer pålitliga än en enhet som ansluter från internet.

Länge har företagsnätverk konstruerats utifrån antagandet att om du befinner dig på insidan av nätäverket är du hyffsat pålitlig. I en ZT-arkitektur är istället utgångspunkten att du bör betrakta företagsnätverket som vilket nätverk som helst. Det ska helt enkelt inte spela någon roll om var du befinner dig.

Oavsett vilket nätverk en användare är ansluten till så ska inte nätverket i sig ge användaren mer eller mindre åtkomst till ett system hen försöker använda. Alla nätverk ska betraktas som osäkra nätverk och det gäller således även företagsnätverket.

4.3.2 Princip 2 - Autentiserad enhet och identitet

Kärnan i en ZT-arkitektur och huruvida ett åtkomstförsök ska godkännas eller nekas handlar om huruvida begäran görs från en autentiserad enhet och en autentiserad identitet.

Autentiserad identitet är något de flesta är avsevärt mycket mer bekväma med idag än vad vi är med att autentisera enheter. Vi är vana vid att hantera identiteter och hur olika metoder kan användas för att autentisera en identitet. Lösenord, certifikat eller andra former av OTP-lösningar.

Tillämpningen av principen innebär således att vi först och främst identifierar och autentiserar våra användare på starkast möjliga sätt. Vi ska vara så trygga vi kan vara med att en användare som begär en resurs faktiskt är användaren vi tror det är. Vår tillit till en korrekt identifiering och autentisering ska uppdatera vårt inventarie av användare. Vi måste någonstans placera en “poäng” på användarens autentisering. Endast lösenord? Då får du endast åtkomst till de här resurserna.

4.3.3 Princip 3 - Dynamisk åtkomstkontroll

Den andra förändringen i en ZT-arkitektur är att du kontinuerligt ska utvärdera och godkänna åtkomstförsök för en kombination av användare, enhet, plats, tid, begärd resurs, uppdateringsstatus osv. Dynamiskt innebär att du har flertalet attribut som uppdateras löpande och som sedan används i en tillits-algoritm för att avgöra om huruvida ett åtkomstförsök ska godkännas eller nekas.

Detta betyder att åtkomstförsök utvärderas dynamiskt och kontinuerligt. Bara för att en användare har en given roll, tidigare har kunnat anropa en resurs betyder inte detta att nästa anrop ska accepteras bara för att ett tidigare gjorde det. Kanske har ett, eller flera, attribut förändrats. Nya förutsättningar kanske kräver förnyad autentisering, eller nekat försök till begärd resurs.

I en ZT-arkitektur behöver vi även säkerställa att enheter autentiseras mot en access-proxy innan ett åtkomstförsök kan beviljas. Denna utvärdering görs utifrån en uppsättning attribut. Dessa attribut kan beskriva saker som vilken metod en användare använde för att autentisera sig (lösenord, MFA), från vilken geografisk plats, vid vilken tid, eller vilken resurs hen försöker använda. Alla dessa attribut kan ändras; de är dynamiska.

Åtkomstförsöken utvärderas genom attributen och en uppsättning regler (policys). Inom Zero Trust kallas komponentent som ansvarar för att efterleva reglerna Policy Enforcement Point (PEP). Reglerna och sjäva kontrollen är en annan komponent som kallas för Policy Decision Point (PDP).

Den dynamiska åtkomstkontrollen behöver kommunicera med ett antal viktiga datakällor som t.ex. inventering av enheter och användare, men kanske även tjänster för sårbarhetshantering osv. Den dynamiska åtkomstkontrollen kan vara den komponent av en ZTA som innebär mest komplexitet och störst kostnad. Det har tagit Google flera år av utveckling att bygga sin access-proxy och det skulle jag tolka som en relativt tydlig indikation på hur svårt det är.

4.3.4 Nutida tillämpning av historiska principer

Det nya med Zero Trust skulle jag således vilja förklara som att gamla principer tillämpas i ett nytt sammanhang. Från det tidigare ha varit en dator med sina användare, processer och resurser expanderar vi området till att vara företaget, verksamheten eller organisationen. Vi talar fortfarande om användare, men nu också nätverkade resurser som klienter, servrar, molntjänster och andra “öar” som tillhandahåller en tjänst eller information vi vill nå.

Zero Trust är den mentala modell vi ska ha i huvudet när vi funderar över hur användare och enheter ska kopplas ihop med en resurs.

5. Arikitekturella grundkomponenter

Börjar du gräva i ZT kommer du snabbt förstå hur otroligt omfattande det är. Det är verkligen ingen enskild produkt eller tjänst som ger dig ZT. Det är en fundamental mental förflyttning i hur ni resonerar om cybersäkerhet i verksamheten. Jag kommer inte kunna ge dig en fullständig bild av hur allting hänger ihop, men jag hoppas att kunna ge dig en känsla för omfattningen.

Men självklart finns det ju aspekter i det som blir tekniska. I en ZT-inspirerad arkitektur kommer det behöva finnas ett antal komponenter som samverkar för att realisera principerna i ZT.

1. En algoritm för tillitsberäkning
2. Regeluppsättnign och konfiguration. (PDP)
3. Proxy för tvingad åtkomstkontroll (PEP)

Dessa “komponenter” är någorlunda unika för ZT, men givetvis finns det fler. Du behöver ha lösningar för autentisering, inventering av enheter och användare, produkter/tjänster för sårbarhetshantering. Men dessa är mer datakällor som kan bidra med underlag för att beräkna vilken tillitsnivå kan ges till en användare/enhet/resurs-kombination.

Jag tänkte försöka ge en övergripande förklaring till de mer centrala komponenterna.

5.1 Trust-algorithm

Jag skulle kunna argumentera för att tillits-algoritmen är absolut central för en ZT-arkitektur. Det är genom algoritmen du får ett beslut om huruvida en åtkomstbegäran ska tillåtas eller inte. Och för att algoritmen ska kunna fungera behöver den attribut att basera sina uträkning på. Detta ger oss att [[dynamiska åtkomstförsök baseras på olika unika attribut]]. Föreställ dig något i stil med följande.

Det behöver finnas en databas med information om varje användare, enhet och resurs som finns. Kopplat till varje objekt som finns i den här databasen kopplar vi ett antal attribut. För en användare kan det handla om vilken metod för autentisering som använts, eller från vilken plats och enhet autentiseringen genomfördes. Enheter kan innehålla attribut som förklarar senaste patchning, vilka program som finns installerade på enheten osv.

Allt detta, alla dessa attribut används sedan för att beräkna ett aktuellt tillitsvärde som sedan används i beslutsmotorn. Det behöver inte nödvändigtvis vara ett kvantitativt värde utan det kan vara en matris av påståenden om tilliten som är nödvändig för ett givet anrop. Ska en användare få åtkomst till en resurs kanske resursägaren säger att användaren måste uppnå vissa krav för att kunna få åtkomst. Autentiserad med hjälp av OTP, en viss typ av enhet, och att användaren måste ha en viss roll.

5.2 Regeluppsättning och konfiguration, Policy Decision Point (PDP)

En annan väsentlig del av en ZT-arkitektur är hur och var du ska bestämma vilka regler som gäller för åtkomstkontrollen. I sammanhang av ZT kallas den här delen Policy Decision Point (PDP) och består egentligen av två delar: Policy Engine och Policy Administrator. Microsoft förespråkar exempelvis användandet av Azure AD som PDP och således där du skulle administrera regler för åtkomst osv.

5.3 Proxy för tvingad åtkomstkontroll, Policy Enforcement Point (PEP)

Slutligen behöver det även finnas en (eller flera) platser genom vilka åtkomstkontroller genomförs, och det gör vi i PEP:en. Den här komponenten styrs av reglerna i din PDP och ansvarar för att säkerställa att endast rätt åtkomst ges.

Det finns många sätt att realisera den här komponenten. Exempelvis skulle det kunna innebära att end-to-end tunnlar upprättas mellan access-proxyn och bakomliggande resurs, eller användandet av mikrosegmentering.

Oaktat vad måste alla åtkomstförsök tvingas igenom en proxy som verifierar allt. Och som du säkert förstår blir access-proxyn mycket känslig för angrepp och behöver vara extremt robust. Skulle proxyn sluta fungerar slutar allt att fungera.

6. Avslutning och sammanfattande tankar

Detta konkluderar således min första artikel om Zero Trust. Har den varit användbar? Något du tycker var bra eller något du saknar?

Själv längtar jag till att få publicera uppföljande artiklar med fokus på verksamheter som försöker göra resan. Där jag kan få möjlighet att grotta ner mig i utmaningarna som ofrånkomligen kommer att dyka upp. Jag skulle därför väldigt gärna komma i kontakt med dig om du jobbar på ett företag som börjat resan, gjort resan eller funderar på resan mot en ZT-inspirerad arkitektur.

Kontakta mig! Min tanke är då att vi träffas och diskuterar utmaningarna. Vi kan göra det anonymt om det skulle kännas bättre? Oavsett vill jag väldigt gärna höra av dig och dina erfarenheter av att arbeta med ZT-principerna och gärna de främsta utmaningarna du haft med att försöka införliva principerna i verkligheten.