Skydda nätverk med Nulta pouzdanost

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 Nulta pouzdanost 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 Nulta pouzdanost 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 Nulta pouzdanost 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 Nulta pouzdanost

Distributionsguide för nätverk Nulta pouzdanost

Den här guiden beskriver de steg som krävs för att skydda dina nätverk enligt principerna i ett Nulta pouzdanost säkerhetsramverk.

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 Nulta pouzdanost-metod delas nätverk i stället in på 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 Nulta pouzdanost modellen.

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:

1. Skapa dedikerade virtuella nätverk för olika program och/eller programkomponenter.

2. 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.

3. 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:

1. För slutpunkter med HTTP/S-trafik skyddar du med Azure Web Application Firewall (WAF) genom att:

   1. Aktivera standardregeluppsättningen eller OWASP:s översta 10 skyddsregeluppsättning för att skydda mot kända attacker på webbnivå

   2. Aktivera regeluppsättningen för robotskydd för att förhindra att skadliga robotar skrapar information, utför autentiseringsuppgifter osv.

   3. 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:

   • Azure Front Door

     1. Skapa en brandväggsprincip för webbprogram i Azure Front Door.

     2. Konfigurera robotskydd för brandväggen för webbaserade program.

     3. Anpassade regler för brandväggen för webbaserade program.

   • Azure Application Gateway

     1. Skapa en programgateway med en brandvägg för webbprogram.

     2. Konfigurera robotskydd för brandväggen för webbaserade program.

     3. Skapa och använd anpassade regler för Web Application Firewall v2..

2. För alla slutpunkter (HTTP eller inte), front med Azure Firewall för hotinformationsbaserad filtrering på Layer 4:

   1. Distribuera och konfigurera Azure Firewall via Azure Portal.

   2. Aktivera hotinformationsbaserad filtrering för din trafik.

   Dricks

   Lär dig mer om att implementera en Nulta pouzdanost strategi för slutpunkter från slutpunkt till slutpunkt.

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:

1. Framtvinga https-endast kommunikation för internetuppkopplade webbprogram genom att omdirigera HTTP-trafik till HTTPS med Azure Front Door.

2. Ansluta fjärranslutna anställda/partner till Microsoft Azure med hjälp av Azure VPN Gateway.

   1. Aktivera kryptering för punkt-till-plats-trafik i Azure VPN Gateway-tjänsten.

3. Få säker åtkomst till dina virtuella Azure-datorer med krypterad kommunikation via Azure Bastion.

   1. Anslut med hjälp av SSH till en virtuell Linux-dator.

   2. Anslut med RDP till en virtuell Windows-dator.

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:

1. 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.

2. 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

1. 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.

2. Aktivera Azure DDoS Protection Standard för att skydda det virtuella hubbnätverket mot volymtriska nätverkslagerattacker.

3. 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

1. 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.

2. 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.

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:

1. Konfigurera och hantera Azure DDoS Protection Standard.

2. 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:

1. Kryptera programserverdelstrafik mellan virtuella nätverk.

2. Kryptera trafik mellan lokalt och moln:

   1. Konfigurera ett plats-till-plats-VPN via ExpressRoute Microsoft-peering.

   2. 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

Azure-nätverk

Virtuella nätverk och undernät

Nätverkssäkerhetsgrupper och programsäkerhetsgrupper

Azure Firewall

Azure DDoS-skydd

Azure Web Application Firewall

Azure VPN Gateway

Azure ExpressRoute

Azure Network Watcher

Slutsats

Att skydda nätverk är centralt för en framgångsrik Nulta pouzdanost 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 Nulta pouzdanost pelare.

Distributionsguideserien för Nulta pouzdanost