Nollförtroende Övergången från arv till moln-native

Företag som verkar i den traditionella monolitiska miljön kan ha strikta organisatoriska strukturer. Som ett resultat kan kravet på säkerhet hindra dem från att gå över till en hybrid- eller moln-native applikationsinstallationsmodell.

Trots de uppenbara svårigheterna vill majoriteten av företagen dra nytta av molnfödda kapaciteter. Idag överväger eller utvärderar de flesta enheter moln för att förbättra sin kundupplevelse. I vissa fall är det förmågan att göra rikare kundmarknadsanalyser eller tillhandahålla operationell excellens.

Cloud-native är en nyckelstrategisk agenda som gör det möjligt för kunder att dra nytta av många nya funktioner och ramverk. Det gör det möjligt för organisationer att bygga och utvecklas framöver för att få en fördel över sina konkurrenter.

Ansökningarna utvecklas

Låt möta det! Ansökningarna utvecklas mycket snabbt. Traditionella applikationer kompletteras nu med ytterligare cloud-native funktioner. Vi har traditionella applikationer som arbetar med de nya containermodulerade front-end- eller backend-tjänsterna.

Kärnapplikationen är fortfarande en 3-lags monolit, men de molnbaserade tjänsterna skruvas fast för att skicka data tillbaka till det privata datacenters kärnapplikation.

Övergången mål

Idealt kommer företag att ha en säkerhetsställning som de är nöjda med. De har brandväggar, IDS / IPS, WAF och segmentering: tillvägagångssätt som fungerar perfekt.

När vi börjar med molnbaserade tjänster måste vi lägga till ytterligare ett lager av säkerhet. Företag måste se till att de har lika eller bättre säkerhetsförmåga än tidigare.

Detta skapar ett gap som måste fyllas. Övergången innebär förmågan att upprätthålla täckning, synlighet och kontroll i traditionella miljöer, samtidigt som man utnyttjar molntjänsttjänster. Allt gjort med en säkerhetsställning med noll förtroende för standardnekande.

Den komplexa miljön

Objektivt, inom de traditionella miljöerna, finns det en mängd olika datacenterarkitekturer som fungerar i offentliga, privata, hybrid- och multi-cloud-implementeringsmodeller. Formellt var det bara privat och offentligt men nu är hybrid och multimoln de konventionella normerna.

Det finns en vektorövergång som sker över den fysiska, moln- och applikationsmiljön. Denna övergång är mycket dynamisk och heterogen. Under en framtida tid kommer vi sannolikt att ha hybridanslutning. 

Säkerhet och hybridmoln

Ett av huvudfokuserna för hybridanslutning är på interaktioner. Det är vanligt att stora företag har lite av allt. Det kommer att finnas applikationer i molnet, lokalerna, mikroservicen och monoliterna. Alla dessa enheter lever och verkar i silon.

Man behöver god täckning av varje interaktion mellan komponenter inom olika arkitekturer. För effektiv säkerhet bör man övervaka för oväntat beteende under interaktionerna. Om denna täckning förbises, är dörren öppen för kompromiss eftersom dessa komponenter kommunicerar med andra. Säkerhet kommer att vara den svagaste länken.

Det traditionella nätverket

Den traditionella nätverksstrategin är vad alla känner till och det är hur majoriteten av säkerheten implementeras idag. Det är också den minst flexibla arkitekturen, eftersom säkerhet är kopplad till en IP-adress, VLAN eller traditionell 5-tuple. Den traditionella metoden är ett ineffektivt sätt att fastställa säkerhetspolitik.

Dessutom är nätverk leverantörsspecifikt. Hur du implementerar en ACL eller VLAN kommer att utgöra olika konfigurationer per leverantör och i vissa fall finns det också skillnader inom samma leverantör. Vissa har utvecklats till Chef eller Puppet men majoriteten av leverantörerna gör fortfarande CLI vilket är manuellt och felaktig.

Hypervisorn

För applikationen finns det en attackyta som omfattar allt på hypervisorn. Det är mycket omfattande när du tänker på hur många VM som kan placeras på en hypervisor. Ju mer VM: er, desto större är sprängradie.

Därför finns det möjligheten till VM-flykt, där kompromissen med en VM kan resultera i att en dålig aktör får åtkomst till alla andra VM: er på den hypervisorn. I huvudsak kan en hypervisor oavsiktligt förstora attackytan.

Värdbaserade brandväggar

På senare tid har värdbaserade brandväggar gjort vissa förbättringar av säkerheten genom att förhindra åtkomst till oönskad inkommande trafik genom portnumret. Följaktligen är attackytan och kontrollen nu placerad nere på arbetsbelastningsnivån. Men vi står fortfarande inför problemet att policyn genomförs på ett distribuerat sätt.

Verktygen som beskrivs ovan beskriver en mängd olika säkerhetsstrategier, som alla implementeras i dag. De är alla nödvändiga lösningar som tar dig från en grov till en finkornig säkerhetsmodell. Men övergången till hybrid och cloud-native kräver en ännu mer finkornig strategi, som kallas noll förtroende.

Nästa utvecklingsfas

Vi anländer just till en fas där lösningarna för virtualiserade miljöer baserade på VM: s i de offentliga och privata molnen börjar mogna. Därför, när vi når denna fas, börjar vi redan bevittna nästa utveckling.

Nästa steg i utvecklingen av DevOps-ledda miljöer är baserat på containrar och orkestreringsramar. Detta ger en annan storleksordning till miljöens komplexitet när det gäller datoranvändning och nätverk.

De befintliga virtualiserade miljöerna baserade på VM: er kommer inte att kunna hantera komplexiteten som de containeriserade miljöerna har. Så vad är rätt väg framåt?

Nätverk och applikationsoberoende

Ramen för säkerhet och efterlevnad måste vara oberoende av nätverket. På ett sätt bör de fungera som två fartyg som passerar på natten. Dessutom borde de vara identitetsbaserade.

Den viktigaste fördelen med en identitetsbaserad lösning är att du får synlighet i kommunikation mellan tjänster och tjänster, som blir byggstenarna för autentisering och åtkomstkontroll.

Enhetlig säkerhetspolicy och adaptiv skalning

Du behöver förmågan att täcka en mängd olika kombinationer. Det handlar inte bara om att täcka olika typer av infrastrukturer, du måste också täcka interaktioner mellan dem, som kan implementeras i mycket komplexa miljöer.

I den moderna världen har vi orkestrering, containrar, flyktiga och dynamiska tjänster som ändrar funktionalitet med förmågan att skala upp och skala ner. Därför bör säkerhetslösningen vara anpassningsbar med de underliggande tjänsterna, oavsett om den skalar eller utvecklas.

Kryptera data automatiskt i rörelse (mTLS)

Eftersom våra applikationer spänner över både hybrid- och multi-cloud-implementeringsmodeller blir kryptering komplicerad med public key infrastruktur (PKI) -system och hantering av tokens.

Om du har en lösning som utvidgar applikations-, fysiska och molnmiljöer kommer du att ha en elastisk och genomgripande strategi. Så småningom gör det möjligt för dig att kryptera data i rörelse utan omkostnader för att hantera komplexa PKI-system.

Nollförtroende

Alla användare, mikroservice, port eller API kan introducera sårbarheter. Detta ger oss tillbaka till nollförtroende - ”aldrig lita på, alltid verifiera”. Idén att flytta omkretsen för att skydda de interna tillgångarna är ett mandat för säkerhetsmodellen nollförtroende. Perimeter ökar i antal, blir mer kornig och närmare arbetsbelastningen. Identiteten blir den nya omkretsen.

Men alla tillgångar som du behövde skydda, när du enbart fokuserade på utgående tjänster, är mer komplexa när det gäller storlek när du nu måste skydda de interna tillgångarna. De nuvarande lösningarna kommer helt enkelt inte att skala för att tillfredsställa denna nivå. Vi har en storleksordning som är större i skala än den miljö du behöver skydda.

Därför är det obligatoriskt att ha en lösning på plats som är utformad grundad, för att vara lika skalbar som datacentret och beräknad miljö. Nollförtroende blir ännu viktigare under övergångsperioden eftersom du har mer tvärsamtal mellan tjänster och arbetsbelastningar som distribueras i olika miljöer. Dessutom kan mediet mellan miljöerna ha en varierande nivå av förtroende.

Därför är beslutet att anta nollförtroendemetoden ett kritiskt element för att upprätthålla en effektiv säkerhetsställning under övergångsfasen. Om du inte litar på din omkrets är det enda sättet att säkra dig genom att kryptera all kommunikation mellan tjänsterna.

Exempel på lösningssammanfattning

Helst måste lösningen erbjuda en unik säkerhetsplattform på applikationsnivå. En lager 7-lösning gör det möjligt för administratörerna att förstå "vem" och "när". Dessutom hjälper det att ta reda på vilka tjänster som används samtidigt som applikationsnivån kan utnyttja NLP.

Ett nätverk som är oberoende och en applikationscentrerad säkerhetslösning är förslaget till basvärde. Det täcker ett brett utbud av virtuella miljöer och nätverksmiljöer med fokus på övergången till cloud-native med ett nollförtroendemetod.

Arbetsbelastning centrerad, inte nätverk-centrerad, är det som gör lösningen mer stabil, läsbar och hanterbar. Det dämpar användningen av automatisering för att hämta den minst privilegierade policyn från den observerade aktiviteten.

Detta ger en full cirkel strategi för visualisering, aktivitet, policy och skillnaderna mellan dem. Arbetsbelastning centrerad policy varnar när en aktivitet bryter mot policyn och där policyn kan vara för lös med tanke på den observerade aktiviteten. Politik bör anges med logiska attribut, inte fysiska attribut.

Säkerhetsplattformen säkerställer att du vet exakt vad som händer, medan du genomgår övergången från arv till moln-native applikationsmiljöer. Det konstaterar framgångsrikt och fyller luckan för en säker och smidig migration.

Gå med i nätverkets världssamhällen på Facebook och LinkedIn för att kommentera ämnen som är övertygade.