Skydda nätverk med Nolltillit
Stordata ger nya möjligheter att få nya insikter och få en konkurrensfördel. Vi är på väg bort från en tid då nätverken var tydligt definierade och vanligtvis specifika för en viss plats. Molnet, mobila enheter och andra slutpunkter utökar gränserna och ändrar paradigmet. Nu finns det inte nödvändigtvis ett inneslutet/definierat nätverk att skydda. I stället finns det en omfattande portfölj med enheter och nätverk som alla är länkade av molnet.
I stället för att tro att allt bakom företagets brandvägg är säkert, förutsätter en heltäckande Nolltillit strategi att överträdelser är oundvikliga. Det innebär att du måste verifiera varje begäran som om den kommer från ett okontrollerat nätverk – identitetshantering spelar en avgörande roll i detta.
I den Nolltillit modellen finns det tre viktiga mål när det gäller att skydda dina nätverk:
Var redo att hantera attacker innan de inträffar.
Minimera skadans omfattning och hur snabbt den sprids.
Öka svårigheten att kompromettera ditt molnavtryck.
För att göra detta följer vi tre Nolltillit principer:
Verifiera explicit. Autentisera och auktorisera alltid baserat på alla tillgängliga datapunkter, inklusive användaridentitet, plats, enhetens hälsa, tjänst eller arbetsbelastning, dataklassificering och avvikelser.
Använd åtkomst med minst privilegier. Begränsa användaråtkomst med just-in-time och just-enough-access (JIT/JEA), riskbaserade adaptiva principer och dataskydd för att skydda både data och produktivitet.
Anta intrång. Minimera explosionsradien för intrång och förhindra lateral förflyttning genom att segmentera åtkomsten efter nätverk, användare, enheter och programmedvetenhet. Kontrollera att alla sessioner är krypterade från slutpunkt till slutpunkt. Använd analys för att få synlighet, driva hotidentifiering och förbättra skyddet.
Distributionsmål för nätverk Nolltillit
Innan de flesta organisationer börjar sin Nolltillit resa har de nätverkssäkerhet som kännetecknas av följande:
-
Få nätverkssäkerhetsperimeter och öppna, platta nätverk.
-
Minimalt skydd mot hot och statisk trafikfiltrering.
-
Okrypterad intern trafik.
|
När du implementerar ett Nolltillit ramverk från slutpunkt till slutpunkt för att skydda nätverk rekommenderar vi att du först fokuserar på dessa inledande distributionsmål: |
|
|
|
I. Nätverkssegmentering: Många ingress-/utgående molnmikroperimeter med viss mikrosegmentering. II. Skydd mot hot: Molnbaserad filtrering och skydd för kända hot. III. Kryptering: Intern trafik från användare till app krypteras. |
|
När dessa har slutförts fokuserar du på dessa ytterligare distributionsmål: |
|
|
|
V. Skydd mot hot: Maskininlärningsbaserat skydd mot hot och filtrering med kontextbaserade signaler. |
Distributionsguide för nätverk Nolltillit
Den här guiden beskriver de steg som krävs för att skydda dina nätverk enligt principerna i ett Nolltillit säkerhetsramverk.
|
|
Initiala distributionsmål |
I. Nätverkssegmentering: Många ingress-/utgående molnmikroperimeter med viss mikrosegmentering
Organisationer bör inte bara ha ett enda, stort rör in och ut ur sitt nätverk. I en Nolltillit metod segmenteras nätverken i stället till mindre öar där specifika arbetsbelastningar finns. Varje segment har sina egna ingress- och utgående kontroller för att minimera "blast radius" för obehörig åtkomst till data. Genom att implementera programvarudefinierade perimeterr med detaljerade kontroller kan du öka svårigheten för obehöriga aktörer att spridas i hela nätverket och därmed minska den laterala förflyttningen av hot.
Det finns ingen arkitekturdesign som passar alla organisationers behov. Du kan välja mellan några vanliga designmönster för segmentering av nätverket enligt Nolltillit modell.
I den här distributionsguiden går vi igenom stegen för att uppnå en av dessa mönster: Mikrosegmentering.
Med mikrosegmentering kan organisationer gå längre än enkla centraliserade nätverksbaserade perimeterr till omfattande och distribuerad segmentering med hjälp av programvarudefinierade mikroperimeter.
Program partitioneras till olika virtuella Azure-nätverk (VNet) och ansluts med hjälp av en hub-spoke-modell
Följ de här stegen:
Skapa dedikerade virtuella nätverk för olika program och/eller programkomponenter.
Skapa ett centralt virtuellt nätverk för att konfigurera säkerhetsstatusen för anslutning mellan appar och ansluta de virtuella appnätverken i en hubb- och ekerarkitektur.
Distribuera Azure Firewall i det virtuella hubbnätverket för att inspektera och styra trafiken mellan de virtuella nätverken.
II. Skydd mot hot: Molnbaserad filtrering och skydd för kända hot
Molnprogram som har öppnat slutpunkter för externa miljöer, till exempel Internet eller ditt lokala fotavtryck, riskerar att attacker kommer in från dessa miljöer. Det är därför absolut nödvändigt att du söker igenom trafiken efter skadliga nyttolaster eller logik.
Dessa typer av hot delas in i två breda kategorier:
Kända attacker. Hot som har identifierats av programvaruleverantören eller den större communityn. I sådana fall är attacksignaturen tillgänglig och du måste se till att varje begäran kontrolleras mot dessa signaturer. Nyckeln är att snabbt kunna uppdatera identifieringsmotorn med eventuella nyligen identifierade attacker.
Okända attacker. Det här är hot som inte riktigt matchar någon känd signatur. Dessa typer av hot omfattar nolldagars sårbarheter och ovanliga mönster i begärandetrafik. Förmågan att identifiera sådana attacker beror på hur väl ditt försvar vet vad som är normalt och vad som inte är det. Ditt försvar bör ständigt lära sig och uppdatera sådana mönster när din verksamhet (och tillhörande trafik) utvecklas.
Vidta dessa åtgärder för att skydda mot kända hot:
För slutpunkter med HTTP/S-trafik skyddar du med Azure Web Application Firewall (WAF) genom att:
Aktivera standardregeluppsättningen eller OWASP:s översta 10 skyddsregeluppsättning för att skydda mot kända attacker på webbnivå
Aktivera regeluppsättningen för robotskydd för att förhindra att skadliga robotar skrapar information, utför autentiseringsuppgifter osv.
Lägga till anpassade regler för att skydda mot hot som är specifika för ditt företag.
Du kan använda något av två alternativ:
För alla slutpunkter (HTTP eller inte), front med Azure Firewall för hotinformationsbaserad filtrering på Layer 4:
III. Kryptering: Intern trafik från användare till app krypteras
Det tredje första målet att fokusera på är att lägga till kryptering för att säkerställa att intern trafik från användare till app krypteras.
Följ de här stegen:
Framtvinga https-endast kommunikation för internetuppkopplade webbprogram genom att omdirigera HTTP-trafik till HTTPS med Azure Front Door.
Ansluta fjärranslutna anställda/partner till Microsoft Azure med hjälp av Azure VPN Gateway.
- Aktivera kryptering för punkt-till-plats-trafik i Azure VPN Gateway-tjänsten.
Få säker åtkomst till dina virtuella Azure-datorer med krypterad kommunikation via Azure Bastion.
Dricks
Lär dig mer om att implementera en Nolltillit strategi från slutpunkt till slutpunkt för program.
|
|
Ytterligare distributionsmål |
IV. Nätverkssegmentering: Fullständigt distribuerade mikroperimeter för inkommande/utgående moln och djupare mikrosegmentering
När du har uppnått de tre första målen är nästa steg att segmentera nätverket ytterligare.
Partitionering av appkomponenter till olika undernät
Följ de här stegen:
I det virtuella nätverket lägger du till undernät för virtuella nätverk så att diskreta komponenter i ett program kan ha egna perimeterr.
Tillämpa regler för nätverkssäkerhetsgrupp för att endast tillåta trafik från de undernät som har en appunderkomponent identifierad som en legitim kommunikationsmotsvarighet.
Segmentera och framtvinga de yttre gränserna
Följ dessa steg beroende på typen av gräns:
Internetgräns
Om internetanslutning krävs för ditt program som måste dirigeras via det virtuella hubbnätverket uppdaterar du reglerna för nätverkssäkerhetsgruppen i det virtuella hubbnätverket så att internetanslutningen tillåts.
Aktivera Azure DDoS Protection Standard för att skydda det virtuella hubbnätverket mot volymtriska nätverkslagerattacker.
Om ditt program använder HTTP/S-protokoll aktiverar du Azure Web Application Firewall för att skydda mot Layer 7-hot.
Lokal gräns
Om din app behöver anslutning till ditt lokala datacenter använder du Azure ExpressRoute för Azure VPN för anslutning till ditt virtuella hubbnätverk.
Konfigurera Azure Firewall i det virtuella hubbnätverket för att inspektera och styra trafik.
Gräns för PaaS-tjänster
- När du använder Azure-tillhandahållna PaaS-tjänster (t.ex. Azure Storage, Azure Cosmos DB eller Azure Web App använder du alternativet PrivateLink-anslutning för att säkerställa att alla datautbyten sker över det privata IP-utrymmet och att trafiken aldrig lämnar Microsoft-nätverket.
Dricks
Lär dig mer om att implementera en Nolltillit strategi för data från slutpunkt till slutpunkt.
V. Hotskydd: Maskininlärningsbaserat skydd mot hot och filtrering med kontextbaserade signaler
Om du vill ha ytterligare skydd mot hot aktiverar du Azure DDoS Protection Standard för att ständigt övervaka din Azure-värdbaserade programtrafik, använda ML-baserade ramverk för att baslinje och identifiera volymtriska trafiköversvämningar och tillämpa automatiska åtgärder.
Följ de här stegen:
Konfigurera och hantera Azure DDoS Protection Standard.
Konfigurera aviseringar för DDoS-skyddsmått.
VI. Kryptering: All trafik krypteras
Slutligen slutför du nätverksskyddet genom att se till att all trafik är krypterad.
Följ de här stegen:
Kryptera programserverdelstrafik mellan virtuella nätverk.
Kryptera trafik mellan lokalt och moln:
Konfigurera ett plats-till-plats-VPN via ExpressRoute Microsoft-peering.
Konfigurera IPsec-transportläge för privat ExpressRoute-peering.
VII. Avbryta äldre nätverkssäkerhetsteknik
Avbryt användningen av signaturbaserade NIDS/NIPS-system (Network Intrusion Detection/Network Intrusion Prevention) och DLP (Network Data Leakage/Loss Prevention).
De stora molntjänstleverantörerna filtrerar redan efter felaktiga paket och vanliga nätverksnivåattacker, så det finns inget behov av en NIDS/NIPS-lösning för att identifiera dem. Dessutom drivs traditionella NIDS/NIPS-lösningar vanligtvis av signaturbaserade metoder (som anses vara inaktuella) och undviks enkelt av angripare och ger vanligtvis en hög frekvens av falska positiva identifieringar.
Nätverksbaserad DLP är mindre effektivt för att identifiera både oavsiktlig och avsiktlig dataförlust. Anledningen till detta är att de flesta moderna protokoll och angripare använder kryptering på nätverksnivå för inkommande och utgående kommunikation. Den enda möjliga lösningen för detta är "SSL-bridging" som tillhandahåller en "auktoriserad man-in-the-middle" som avslutar och sedan återupprättar krypterade nätverksanslutningar. SSL-bryggningsmetoden har hamnat i onåd på grund av den förtroendenivå som krävs för den partner som kör lösningen och de tekniker som används.
Baserat på den här logiken erbjuder vi en all-up-rekommendation om att du slutar använda dessa äldre nätverkssäkerhetstekniker. Men om din organisations upplevelse är att dessa tekniker har haft en påtaglig inverkan på att förhindra och identifiera verkliga attacker kan du överväga att portera dem till din molnmiljö.
Produkter som beskrivs i den här guiden
Microsoft Azure
Virtuella nätverk och undernät
Nätverkssäkerhetsgrupper och programsäkerhetsgrupper
Azure Web Application Firewall
Slutsats
Att skydda nätverk är centralt för en framgångsrik Nolltillit strategi. Om du vill ha mer information eller hjälp med implementeringen kontaktar du ditt kundframgångsteam eller fortsätter att läsa igenom de andra kapitlen i den här guiden, som omfattar alla Nolltillit pelare.
Distributionsguideserien för Nolltillit
