Nätverkssäkerhet och oberoende

Nätverkssäkerhet har varit den traditionella lynchpinen i företagets säkerhetsinsatser. Molnbaserad databehandling har dock ökat kravet på att nätverksperimeter ska vara mer porösa och många angripare har bemästrat konsten att attackera identitetssystemelement (som nästan alltid kringgår nätverkskontroller). Dessa faktorer har ökat behovet av att främst fokusera på identitetsbaserade åtkomstkontroller för att skydda resurser snarare än nätverksbaserade åtkomstkontroller.

Dessa minskar nätverkssäkerhetskontrollernas roll, men eliminerar den inte helt. Nätverkssäkerhet är inte längre det primära fokuset för att skydda molnbaserade tillgångar, men det är fortfarande högsta prioritet för den stora portföljen med äldre tillgångar (som skapades med antagandet att en nätverksbrandväggsbaserad perimeter var på plats). Många angripare använder fortfarande genomsöknings- och exploateringsmetoder i IP-intervall för offentliga molnleverantörer, vilket framgångsrikt tränger igenom försvar för dem som inte följer grundläggande nätverkssäkerhetshygien. Nätverkssäkerhetskontroller ger också ett djupgående skydd för din strategi som hjälper till att skydda, identifiera, innehålla och mata ut angripare som är på väg in i dina molndistributioner.

I kategorin nätverkssäkerhet och -inneslutning har vi följande rekommendationer för bästa praxis:

  • Justera nätverkssegmentering med övergripande strategi

  • Centralisera nätverkshantering och säkerhet

  • Skapa en strategi för nätverkshantering

  • Definiera en internet edge-strategi

Centralisera nätverkshantering och säkerhet

Centralisera organisationsansvaret för hantering och säkerhet för kärnnätverksfunktioner som korslokala länkar, virtuella nätverk, undernät och IP-adressscheman samt nätverkssäkerhetselement som virtuella nätverksinstallationer, kryptering av molnbaserad virtuell nätverksaktivitet och trafik mellan platser, nätverksbaserade åtkomstkontroller och andra traditionella nätverkssäkerhetskomponenter.

När du centraliserar nätverkshantering och säkerhet minskar du risken för inkonsekventa strategier som kan skapa potentiella sårbarhetsrisker för angripare. Eftersom alla avdelningar inom IT- och utvecklingsorganisationer inte har samma nivå av nätverkshantering och säkerhetskunskaper och sofistikering drar organisationer nytta av att utnyttja ett centraliserat nätverksteams expertis och verktyg.

Microsoft Defender för molnet kan användas för att centralisera hanteringen av nätverkssäkerhet.

Justera nätverkssegmenteringen efter företagets segmenteringsstrategi

Justera din nätverkssegmenteringsmodell med företagssegmenteringsmodellen för din organisation (definierad i avsnittet Styrning, Risk och Efterlevnad).

Detta minskar förvirringen och resulterande utmaningar med olika tekniska team (nätverk, identitet, program osv.) som var och en utvecklar sina egna segmenterings- och delegeringsmodeller som inte överensstämmer med varandra. Detta leder till en enkel och enhetlig säkerhetsstrategi som hjälper till att minska antalet fel på grund av mänskliga fel och oförmåga att öka tillförlitligheten genom automatisering.

Jämför avbildningar i Nätverkssäkerhet och -inneslutning.

image showing hybrid cloud infrastructure-network architecture

Utveckla säkerhet bortom nätverkskontroller

Se till att tekniska kontroller effektivt kan förhindra, identifiera och reagera på hot utanför de nätverk som du kontrollerar.

När organisationer övergår till moderna arkitekturer kommer många tjänster och komponenter som krävs för program att nås via Internet eller i molnleverantörsnätverk, ofta av mobila och andra enheter utanför nätverket. Traditionella nätverkskontroller baserade på en "betrodd intranät" -metod kan inte effektivt ge säkerhetsgarantier för dessa program. Detta skiftande landskap fångas väl av principer som dokumenteras av Jericho Forum och "Zero Trust" metoder.

Skapa en strategi för riskkontroll baserat på en kombination av nätverkskontroller och program, identitet och andra kontrolltyper.

  • Se till att resursgruppering och administrativa privilegier överensstämmer med segmenteringsmodellen (se bild XXXX)

  • Se till att du utformar säkerhetskontroller som identifierar och tillåter förväntad trafik, åtkomstbegäranden och annan programkommunikation mellan segment. Övervaka kommunikationen mellan segment för att identifiera eventuell oväntad kommunikation så att du kan undersöka om du vill ange aviseringar eller blockera trafik för att minska risken för att angripare korsar segmenteringsgränser.

Skapa en strategi för säkerhetskontroll

Skapa en riskkontrollstrategi som blandar beprövade metoder, inklusive:

  • Befintliga nätverkssäkerhetskontroller och -metoder

  • Interna säkerhetskontroller som är tillgängliga i Azure

  • Metoder för noll förtroende

Inneslutning av attackvektorer i en miljö är viktigt. Men för att vara effektiva i molnmiljöer kan traditionella metoder visa sig otillräckliga och säkerhetsorganisationer behöver utveckla sina metoder.

  • Konsekvens för kontroller i lokal infrastruktur och molninfrastruktur är viktigt, men skydd är mer effektivt och hanterbart när du använder interna funktioner som tillhandahålls av en molntjänstleverantör, jit-metoder (dynamisk just-in-time) och integrerade identitets- och lösenordskontroller, till exempel de som rekommenderas av noll förtroende/kontinuerlig validering.

  • En metod för nätverkssäkerhet är att se till att det finns nätverksåtkomstkontroller mellan nätverkskonstruktioner. Dessa konstruktioner kan representera virtuella nätverk eller undernät i dessa virtuella nätverk. Detta fungerar för att skydda och innehålla East-West trafik i din molnnätverksinfrastruktur.

  • Ett viktigt designbeslut för nätverkssäkerhet är att använda eller inte använda värdbaserade brandväggar. Värdbaserade brandväggar stöder en omfattande strategi för skydd på djupet. Men för att vara mest använda kräver de betydande hanteringskostnader. Om din organisation har funnit dem effektiva för att hjälpa dig att skydda och upptäcka hot tidigare kan du överväga att använda dem för dina molnbaserade tillgångar. Om du upptäcker att de inte har tillfört något betydande värde kan du sluta använda dem och utforska interna lösningar på molntjänstleverantörens plattform som ger liknande värde.

En framväxande rekommendation för bästa praxis är att anta en Noll förtroende-strategi baserat på användar-, enhets- och programidentiteter. Till skillnad från nätverksåtkomstkontroller som baseras på element som käll- och mål-IP-adress, protokoll och portnummer, framtvingar och validerar Zero Trust åtkomstkontroll vid "åtkomsttid". Detta undviker behovet av att spela ett förutsägelsespel för en hel distribution, ett nätverk eller ett undernät – endast målresursen behöver tillhandahålla nödvändiga åtkomstkontroller.

  • Azure-nätverkssäkerhetsgrupper kan användas för grundläggande layer 3 & 4-åtkomstkontroller mellan virtuella Azure-nätverk, deras undernät och Internet.

  • Azure Web Application Firewall och Azure Firewall kan användas för mer avancerade nätverksåtkomstkontroller som kräver stöd för programnivå.

  • Lokal lösning för administratörslösenord (LAPS) eller en privilegierad åtkomsthantering från tredje part kan ange starka lokala administratörslösenord och just-in-time-åtkomst till dem

Dessutom erbjuder tredje part mikrosegmenteringsmetoder som kan förbättra dina nätverkskontroller genom att tillämpa noll förtroendeprinciper på nätverk som du kontrollerar med äldre tillgångar på dem.

Definiera en internet edge-strategi

Välj om du vill använda interna molntjänstproviderkontroller eller virtuella nätverksinstallationer för internet edge-säkerhet.

Internet edge-trafik (kallas ibland "nord-syd"-trafik) representerar nätverksanslutning mellan dina tillgångar i molnet och Internet. Äldre arbetsbelastningar kräver skydd från Internetslutpunkter eftersom de skapades med antagandet att en Internetbrandvägg skyddade dem mot dessa attacker. En Internet edge-strategi är avsedd att minimera så många attacker från Internet som är rimligt att identifiera eller blockera.

Det finns två primära alternativ som kan ge Internet edge-säkerhetskontroller och övervakning:

  • Interna kontroller för molntjänstleverantörer (Azure Firewall + [Web Application Firewall (WAF)]/azure/application-gateway/waf-overview))

  • Partner virtual network appliances (brandväggs- och WAF-leverantörer som är tillgängliga på Azure Marketplace)

  • Interna kontroller för molntjänstleverantörer erbjuder vanligtvis grundläggande säkerhet som är tillräckligt bra för vanliga attacker, till exempel OWASP Top 10.

  • Däremot ger partnerfunktioner för molntjänstleverantörer ofta mycket mer avancerade funktioner som kan skydda mot avancerade (men ofta ovanliga) attacker. Partnerlösningar kostar konsekvent mer än interna kontroller. Dessutom kan konfigurationen av partnerlösningar vara mycket komplex och bräckligare än interna kontroller eftersom de inte integreras med molnets infrastrukturkontrollanter.

Beslutet att använda interna kontroller kontra partnerkontroller bör baseras på organisationens erfarenhet och krav. Om funktionerna i de avancerade brandväggslösningarna inte ger tillräcklig avkastning på investeringen kan du överväga att använda de inbyggda funktionerna som är utformade för att vara enkla att konfigurera och skala.

Avbryta äldre nätverkssäkerhetsteknik

Sluta använda signaturbaserade NIDS/NIPS-system (Network Intrusion Detection/Network Intrusion Prevention) och DLP (Network Data Leakage/Loss Prevention).

De större 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 kringgås 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 avslutas och sedan återupprättar krypterade nätverksanslutningar. SSL-bryggningsmetoden har fallit 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 organisationsupplevelse är att dessa tekniker har haft en påtaglig inverkan på att förhindra och upptäcka verkliga attacker, kan du överväga att portera dem till din molnmiljö.

Utforma säkerhet för virtuellt nätverk undernät

Utforma virtuella nätverk och undernät för tillväxt.

De flesta organisationer lägger till fler resurser i sina nätverk än de ursprungligen planerade för. När detta inträffar måste IP-adresserings- och undernätsscheman omstruktureras för att hantera de extra resurserna. Det här är en arbetsintensiv process. Det finns ett begränsat säkerhetsvärde för att skapa ett mycket stort antal små undernät och sedan försöka mappa nätverksåtkomstkontroller (till exempel säkerhetsgrupper) till var och en av dem.

Vi rekommenderar att du planerar dina undernät baserat på vanliga roller och funktioner som använder vanliga protokoll för dessa roller och funktioner. På så sätt kan du lägga till resurser i undernätet utan att behöva göra ändringar i säkerhetsgrupper som tillämpar åtkomstkontroller på nätverksnivå.

Använd inte "alla öppna" regler för inkommande och utgående trafik till och från undernät. Använd en nätverksmetod med "lägsta behörighet" och tillåt endast relevanta protokoll. Detta minskar den totala nätverksangreppsytan i undernätet.

Alla öppna regler (tillåter inkommande/utgående trafik till och från 0.0.0.0-255.255.255.255) ger en falsk känsla av säkerhet eftersom en sådan regel inte kräver någon säkerhet alls.

Undantaget är dock om du bara vill använda säkerhetsgrupper för nätverksloggning. Vi rekommenderar inte detta, men det är ett alternativ om du har en annan lösning för nätverksåtkomstkontroll på plats.

Azure Virtual Network-undernät kan utformas på det här sättet.

Minimera DDoS-attacker

Aktivera DDoS-åtgärder (Distributed Denial of Service) för alla affärskritiska webbprogram och tjänster.

DDoS-attacker är vanliga och utförs enkelt av osofistikerade angripare. Det finns till och med alternativ för "DDoS som en tjänst" på det mörka nätet. DDoS-attacker kan vara mycket försvagande och helt blockera åtkomsten till dina tjänster och till och med ta ned tjänsterna, beroende på typen av DDoS-attack.

De stora molntjänstleverantörerna erbjuder DDoS-skydd av tjänster med varierande effektivitet och kapacitet. Molntjänstleverantörerna tillhandahåller vanligtvis två DDoS-skyddsalternativ:

  • DDoS-skydd på infrastrukturnivå för molnnätverk – alla kunder hos molntjänstleverantören drar nytta av dessa skydd. Skyddet fokuseras vanligtvis på nätverksnivå (lager 3).

  • DDoS-skydd på högre nivåer som profilerar dina tjänster – den här typen av skydd kommer att baslinje dina distributioner och sedan använda maskininlärningstekniker för att identifiera avvikande trafik och proaktivt skydda baserat på deras skydd innan tjänsten försämras

Vi rekommenderar att du inför ett avancerat skydd för alla tjänster där driftstopp kommer att ha en negativ inverkan på verksamheten.

Ett exempel på avancerat DDoS-skydd är Azure DDoS Protection Service.

Besluta om en princip för ingress/utgående internet

Välj att dirigera trafik till Internet via lokala säkerhetsenheter eller tillåta Internetanslutning via molnbaserade nätverkssäkerhetsenheter.

Routning av Internettrafik via lokala nätverkssäkerhetsenheter kallas även för "tvingad tunneltrafik". I ett scenario med tvingad tunneltrafik tvingas all anslutning till Internet tillbaka till lokala nätverkssäkerhetsenheter via en WAN-länk mellan flera platser. Målet är att ge nätverkssäkerhetsteamen bättre säkerhet och synlighet för Internettrafik. Även när dina resurser i molnet försöker svara på inkommande begäranden från Internet tvingas svaren via lokala nätverkssäkerhetsenheter.

Alternativt passar tvingad tunneltrafik ett paradigm för "datacenterexpansion" och kan fungera bra för ett snabbt koncepttest, men skalas dåligt på grund av den ökade trafikbelastningen, svarstiden och kostnaden.

Den rekommenderade metoden för företagsproduktion är att tillåta att molnresurser initierar och svarar på Internetbegäran direkt via molnnätverkssäkerhetsenheter som definieras av din Internet Edge-strategi.

Den direkta Internetmetoden passar in i Nth-datacenterparadigmet (till exempel är Azure-datacenter en naturlig del av mitt företag). Den här metoden skalas mycket bättre för en företagsdistribution eftersom den tar bort hopp som lägger till belastning, svarstid och kostnad.

Vi rekommenderar att du undviker tvingad tunneltrafik av de orsaker som anges ovan.

Aktivera förbättrad nätverkssynlighet

Du bör aktivera förbättrad nätverkssynlighet genom att integrera nätverksloggar i en SIEM (Security Information and Event Management) som Microsoft Sentinel eller en tredje partnerlösning som Splunk, QRadar eller ArcSight ESM.

Genom att integrera loggar från dina nätverksenheter, och även rå nätverkstrafik, får du bättre insyn i potentiella säkerhetshot som flödar över kabeln. Den här logginformationen kan integreras i avancerade SIEM-lösningar eller andra analysplattformar. De moderna maskininlärningsbaserade analysplattformarna stöder inmatning av extremt stora mängder information och kan analysera stora datamängder mycket snabbt. Dessutom kan dessa lösningar finjusteras för att avsevärt minska falska positiva aviseringar.

Exempel på nätverksloggar som ger synlighet är:

Nästa steg

Ytterligare säkerhetsvägledning från Microsoft finns i Microsofts säkerhetsdokumentation.