Dela via

Nätverkssäkerhet

Nätverkssäkerhet skyddar molnarbetsbelastningar från hot som obehörig åtkomst, dataintrång och tjänststörningar genom att styra trafik vid flera gränser. Till skillnad från traditionella perimeterfokuserade skydd kräver moderna molnmiljöer djupgående strategier för skydd med segmentering, privat anslutning och gränsskydd för att hantera dynamiska attackytor, inklusive exponerade tjänster, laterala rörelsevägar och kommando- och kontrollkanaler. Organisationer som implementerar omfattande nätverkskontroller upprätthåller säkra miljöer som standard, medan de som försummar dessa kontroller utsätts för obegränsad lateral förflyttning och långvarig exponering för hot.

Här är de tre grundpelarna i nätverkssäkerhetsdomänen.

Säkra nätverksgränser: Framtvinga strikta kontroller vid nätverkskanter och mellan segment via djupskydd i flera nivåer som innehåller brandväggar, DDoS-skydd, brandväggar för webbprogram och privat anslutning, enligt principen om minsta behörighet att neka obehörig trafik som standard.

Relaterade kontroller:

Använd nätverksisolering: Dela upp nätverk i isolerade segment i linje med företagets segmenteringsstrategi och risknivåer för att begränsa hotspridningen, minska attackytan och förhindra obehörig lateral förflyttning.

Relaterade kontroller:

Övervaka och svara: Upprätthålla kontinuerlig insyn i nätverksaktiviteten genom omfattande övervakning, intrångsidentifiering och protokollsäkerhet för att snabbt identifiera misstänkt beteende, principöverträdelser och aktiva hot.

Relaterade kontroller:

NS-1: Upprätta gränser för nätverkssegmentering

Azure Policy: Se Inbyggda principdefinitioner i Azure: NS-1.

Säkerhetsprincip

Nätverkssegmentering innebär att dela upp ett nätverk i mindre, isolerade segment för att styra och begränsa trafikflödet mellan molnresurser för att minska explosionsradien.

Utforma nätverkssegmenteringen för att säkerställa att distributionen av det virtuella nätverket överensstämmer med företagets segmenteringsstrategi och olika risknivåer. Gemensam segmenteringsstrategi omfattar:

  • Avgränsa Corpnet med applikationsnätverk
  • Separata programnätverk
  • Avgränsa nätverk för produktions- och testmiljö

Mer information om viktiga strategier för nätverkssegmentering finns i Azure Well-Architected Framework:

Risk att mildra

Utan gränser för nätverkssegmentering står organisationer inför obegränsad lateral förflyttning som gör det möjligt för angripare att korsa nätverksinfrastrukturer och kompromettera värdefulla tillgångar.

  • Exponering av platt nätverk: Avsaknad av segmentering möjliggör obegränsad lateral förflyttning, vilket gör det möjligt för angripare att kompromettera värdefulla tillgångar genom att gå igenom en icke-partitionerad nätverkstopologi.
  • Eskaleringsvägar för privilegier: Otillräckliga gränser tillåter obehöriga åtkomstvektorer, vilket underlättar eskalering av användarbehörigheter genom åtkomst till känsliga undernät och arbetsbelastningar.
  • Spridning av skadlig kod: Otillräcklig segmentering möjliggör snabb spridning av skadlig kod, till exempel utpressningstrojaner över sammankopplade noder, vilket förstärker attackytan och driftspåverkan.
  • Trafikblindhet mellan öst och väst: Obegränsad trafik mellan segment hindrar avvikelseidentifiering och incidenthantering, vilket minskar insynen i interna hotrörelser och komplicerar kriminalteknisk analys.

MITRE ATT&CK

  • Initial Access (TA0001): obehörig åtkomst till nätverk och exponerade tjänster (t.ex. T1190 – Exploit Public-Facing Application).
  • Lateral Movement (TA0008): attackspivotering via VNets och obegränsad trafik mellan undergrupper (t.ex. T1021 - Fjärrtjänster).
  • Exfiltrering (TA0010): dataexfiltrering av icke-begränsad utgående trafik för obehöriga dataöverföringar till externa servrar (t.ex. T1041 – Exfiltrering via C2-kanalen).
  • Kommando och kontroll (TA0011): spridning av skadlig kod genom kommunikation med skadliga IP-adresser eller domäner via brandväggsregler och hotinformation (t.ex. T1071 – Application Layer Protocol).

NS-1.1: Skapa segmentering med VNet och undernät

Isolering av virtuellt nätverk upprättar grundläggande säkerhetsgränser i molnmiljöer, vilket gör det möjligt för organisationer att separera arbetsbelastningar efter förtroendenivå, organisationsenhet eller programgruppering. Den här metoden förhindrar obegränsad lateral förflyttning och minskar explosionsradien när intrång inträffar, vilket justerar nätverksarkitekturen med strategier för företagssegmentering och principer för noll förtroende.

Implementera segmentering av virtuella nätverk genom att skapa isolerade nätverksgränser och underavdelningar:

  • Utforma VNet-topologi baserat på segmenteringsstrategi: Skapa virtuella nätverk i linje med förtroendezoner, organisationsenheter eller programgrupper som definierats i din strategi för företagssegmentering, vilket säkerställer att varje virtuellt nätverk representerar en distinkt säkerhetsgräns.

  • Isolera högriskarbetsbelastningar: Identifiera arbetsbelastningar som kräver strikt isolering (t.ex. produktionsdatabaser, betalningsbearbetningssystem) och distribuera dem till dedikerade, isolerade virtuella nätverk för att minimera exponeringen och förhindra korskontaminering.

  • Skapa undernät för detaljerad segmentering: I varje virtuellt nätverk skapar du distinkta icke-överlappande undernät för att ytterligare segmentera nätverket baserat på programnivåer (t.ex. webbnivå, programnivå, databasnivå) eller funktionskrav, vilket möjliggör mer exakt trafikkontroll och mikrosegmentering.

NS-1.2: Begränsa nätverkstrafiken med hjälp av NSG

Nätverkssäkerhetsgrupper framtvingar trafikfiltrering på undernäts- och nätverksgränssnittsnivå, vilket ger exakt kontroll över kommunikationsflöden mellan nätverkssegment och externa nätverk. Genom att implementera principer som nekar som standard med explicita tillåtna regler ser organisationer till att endast auktoriserad trafik passerar nätverksgränser, förhindrar obehörig åtkomst och minskar attackytan.

Implementera begränsning av nätverkstrafik med hjälp av NSG-regler:

  • Identifiera kommunikationskrav: Analysera resurser i varje virtuellt nätverk för att förstå deras trafikkommunikationsbehov i nord-syd (extern) och öst-väst (intern) och dokumentera nödvändiga portar, protokoll, källadresser och måladresser för legitima affärsfunktioner.

  • Definiera explicita regler för att tillåta och neka: För väldefinierade program (t.ex. arkitekturer på tre nivåer) använder du metoden "neka som standard, tillåt som undantag" för att skapa NSG-regler baserat på port, protokoll, käll-IP-adress och mål-IP-adress, vilket uttryckligen endast tillåter nödvändig trafik samtidigt som all annan kommunikation nekas.

  • Använd programsäkerhetsgrupper för komplexa scenarier: När många program och slutpunkter interagerar förenklar du hanteringen av NSG-regler med hjälp av programsäkerhetsgrupper (ASG) för att gruppera resurser logiskt (t.ex. webbservrar, databasservrar) och definierar sedan NSG-regler baserat på dessa grupper i stället för explicita IP-adresser, vilket förbättrar underhållsbarheten och minskar konfigurationskomplexiteten.

  • Övervaka och optimera med flödesloggar: Aktivera flödesloggning för virtuellt nätverk för att övervaka trafik som tillåts eller nekas av NSG-regler, identifiera ofta nekad trafik som kan tyda på felkonfiguration eller ofta tillåten trafik som kan ligga till grund för regeloptimering och minska loggningsbruset.

Exempel på implementering

En organisation behövde säkra en flernivåapplikation med separata miljöer för produktion, utveckling och testning, samtidigt som obehöriga sidorörelser och extern åtkomst förhindras.

Utmaning: Organisationen hade ett program med tre nivåer (webb, program, databas) med alla resurser i ett enda stort nätverkssegment, vilket möjliggjorde obegränsad kommunikation mellan alla nivåer och miljöer. Detta skapade betydande säkerhetsrisker, inklusive potentiell lateral förflyttning mellan produktion och icke-produktion, obegränsad Internetåtkomst från databasservrar och oförmåga att isolera högriskarbetsbelastningar.

Lösningsmetod:

  • VNet-segmentering efter miljö: Skapade separata virtuella nätverk för produktion (10.0.0.0/16), utvecklingsmiljöer (10.1.0.0/16) och testning (10.2.0.0/16) och upprättade gränser för nätverksisolering som förhindrar åtkomst mellan miljöer och begränsar explosionsradien för potentiella överträdelser.
  • Segmentering av undernät efter nivå: I det virtuella produktionsnätverket skapade du distinkta icke-överlappande undernät för varje programnivå – webbnivå (10.0.1.0/24), programnivå (10.0.2.0/24) och databasnivå (10.0.3.0/24) – vilket möjliggör detaljerad trafikkontroll mellan nivåer.
  • NSG-regler för trafikkontroll mellan nord och syd: Konfigurerade NSG-regler för att neka all inkommande trafik från Internet (0.0.0.0/0) till interna undernät och begränsa utgående Internetåtkomst till endast betrodda mål, med specifika regler som endast tillåter nödvändiga externa anslutningar för webbnivån samtidigt som all Internetåtkomst blockeras från databasnivån.
  • NSG-regler för trafikkontroll mellan öst och väst: Implementerade principer som nekar som standard med explicita tillåtna regler mellan nivåer – webbnivån tillåts endast utgående till programnivå på nödvändiga portar, programnivån tillåts endast utgående till databasnivå på port 1433 (SQL) och databasnivån nekade all annan inkommande trafik förutom från undernätet på programnivå.
  • Fjärrhanteringsåtkomst: Begränsade fjärrhanteringsportar (RDP 3389/TCP, SSH 22/TCP) för att endast acceptera anslutningar från betrodda bastionsvärdundernät (10.0.0.0/26), vilket eliminerar direkt internetåtkomst till hanteringsgränssnitt.

Utfall: Organisationen eliminerade obegränsad lateral förflyttning mellan programnivåer och miljöer, avsevärt minskad attackyta genom att ta bort direkt Internetåtkomst från serverdelssystem och etablerade framtvingande nätverksgränser i linje med principer för noll förtroende. Flödesloggar aktiverade kontinuerlig övervakning av tillåten och nekad trafik för kontinuerlig validering av optimering och säkerhetsstatus.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-7, SC-32, AC-4, CM-7
  • PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1
  • CIS-kontroller v8.1: 12.1, 12.2, 12.6
  • NIST CSF v2.0: PR. IR-01, PR. AC-05
  • ISO 27001:2022: A.8.20, A.8.21
  • SOC 2: CC6.1, CC6.6

NS-2: Skydda molnbaserade tjänster med nätverkskontroller

Azure Policy: Se Inbyggda principdefinitioner i Azure: NS-2.

Säkerhetsprincip

Använd inbyggda funktioner i tjänsten för att skydda nätverksåtkomsten till resurserna för att undvika och minska exponeringen av resurserna för det ej betrodda nätverket. Dessa funktioner omfattar bland annat:

  • Upprätta privata åtkomstpunkter för resurser för att undvika exponering av nätverkstrafik som går via det offentliga nätverket.
  • Distribuera resursen till virtuella nätverk där du kan begränsa det virtuella nätverket för att upprätta en privat åtkomstpunkt för tjänsten.
  • Konfigurera inbyggda brandväggar för tjänsten för att begränsa inkommande trafik eller inaktivera åtkomsten till det offentliga nätverket.

Obs! Förutom den grundläggande nätverksåtkomstkontrollen och trafikfiltreringen bör du även använda funktioner för hotidentifiering för att övervaka tjänster som DNS (NS-10) för att identifiera eventuell dataexfiltrering.

Risk att mildra

Hotaktörer utnyttjar offentligt exponerade molntjänster för att utföra dataexfiltrering, programnivåattacker och trafikavlyssning.

  • Dataexfiltrering via offentliga slutpunkter: Angripare utnyttjar offentligt tillgängliga lagringskonton, databaser eller API:er för att exfiltera känsliga data genom att upprätta obehöriga anslutningar till exponerade slutpunkter, kringgå kontroller för nätverkssegmentering och aktivera storskalig datastöld.
  • Programnivåattacker mot offentliga slutpunkter: DDoS-attacker (Distributed Denial of Service), SQL-inmatning och andra programexploateringar riktar sig mot offentligt exponerade webbtjänster, API:er och databaser, överväldigande resurser eller sårbarheter för att orsaka avbrott i tjänsten eller dataintrång.
  • Man-in-the-middle-attacker: Angripare fångar upp trafik som flödar över offentliga nätverk till offentligt exponerade tjänster, samlar in autentiseringsuppgifter, sessionstoken eller känsliga data som överförs utan tillräcklig kryptering eller privat anslutning, vilket möjliggör kontoövertagande eller datastöld.

MITRE ATT&CK

  • Initial Åtkomst (TA0001): obehörig åtkomst genom offentlig internetexponering av molntjänster (t.ex. molnlagringstjänster, databastjänster), utnyttjande av offentliga slutpunkter (t.ex. T1190 – Exploit Public-Facing Application).
  • Exfiltrering (TA0010): dataexfiltrering genom att dirigera trafik via privata virtuella nätverksanslutningar, vilket minskar risken för dataläckage till externa servrar (t.ex. T1041 – Exfiltrering via C2-kanalen).
  • Lateral förflyttning (TA0008): pivoteringstjänster för angripare i virtuella nätverk, obehörig åtkomst mellan molnresurser (t.ex. T1021 – Fjärrtjänster).

Privat anslutning eliminerar offentlig Internetexponering för molntjänster genom att upprätta direkta nätverkssökvägar i din virtuella infrastruktur. Private Link skapar privata slutpunkter med dedikerade IP-adresser i dina virtuella nätverk, vilket säkerställer att trafik till molntjänster aldrig passerar det offentliga Internet samtidigt som DNS-baserade åtkomstmönster upprätthålls. Den här metoden minskar angreppsytan avsevärt och förhindrar dataexfiltrering via offentligt tillgängliga slutpunkter.

Implementera privat anslutning för molntjänster genom följande steg:

  • Distribuera privata slutpunkter för tjänster som stöds: Skapa privata slutpunkter i ditt virtuella nätverk för Azure-resurser som stöder Private Link (t.ex. Azure Storage, Azure SQL Database, Azure Key Vault) och upprätta privata IP-adresser (t.ex. 10.0.2.4) som endast är tillgängliga från ditt virtuella nätverk.

  • Konfigurera privata DNS-zoner: Skapa privata DNS-zoner i Azure för att åsidosätta offentlig DNS-matchning, vilket säkerställer att fullständigt kvalificerade domännamn (FQDN) som mystorageaccount1.blob.core.windows.net matcha privata IP-adresser i ditt virtuella nätverk i stället för offentliga slutpunkter, vilket upprätthåller sömlös anslutning för program med FQDN-baserad åtkomst.

  • Inaktivera offentlig åtkomst: Konfigurera inställningar på tjänstnivå för att inaktivera åtkomst till offentliga nätverk helt när privata slutpunkter har distribuerats, vilket säkerställer att all trafik flödar uteslutande via privat anslutning utan återställning till offentliga slutpunkter.

Not: Vissa Azure-tjänster kan också tillåta privat kommunikation via tjänstens slutpunktsfunktion , även om Azure Private Link rekommenderas för säker och privat åtkomst till tjänster som finns på Azure-plattformen. För distributioner, till exempel webbtjänster som finns på virtuella Azure-datorer, bör du undvika att tilldela offentliga IP-adresser direkt till virtuella datorer om det inte är starkt motiverat. Använd i stället Azure Application Gateway eller Azure Load Balancer som klientdel för tjänståtkomst.

NS-2.2 Distribuera tjänsten till VNet

Integrering av virtuella nätverk gör det möjligt för molntjänster att fungera inom gränserna för privata nätverk, vilket upprättar direkt anslutning till VNet-värdbaserade resurser utan offentlig Internetexponering. Genom att distribuera tjänster till virtuella nätverk får organisationer detaljerad kontroll över nätverkstrafiken via säkerhetsgrupper och routningstabeller samtidigt som tjänstisolering upprätthålls från externa hot.

Distribuera tjänster med VNet-integrering där det stöds:

  • Distribuera tjänster till virtuella nätverk: För tjänster som stöder VNet-integrering (t.ex. Azure App Service, Azure Functions, Azure Container Instances) konfigurerar du distributionen till nya eller befintliga virtuella nätverk, anger lämpliga undernät i linje med segmenteringsstrategin och aktiverar privat kommunikation med andra VNet-resurser.

  • Konfigurera nätverkssäkerhetskontroller: Tillämpa regler för nätverkssäkerhetsgrupp (NSG) på tjänstens undernät för att begränsa inkommande och utgående trafik, implementera åtkomst med minsta möjliga behörighet genom att endast tillåta nödvändig kommunikation till specifika mål (t.ex. databasundernät, lagringsslutpunkter) samtidigt som all annan trafik nekas.

NS-2.3 Konfigurera tjänstens interna brandvägg

Brandväggar på servicenivå ger skydd på djupet genom att begränsa nätverksåtkomsten på resursnivå och komplettera kontroller på nätverksnivå med programspecifika säkerhetsgränser. Dessa inbyggda brandväggsfunktioner gör det möjligt för organisationer att begränsa exponeringen för specifika IP-intervall eller virtuella nätverk samtidigt som offentlig åtkomst inaktiveras helt när det är lämpligt, vilket minskar attackytan utan att kräva komplexa ändringar i nätverkstopologin.

Konfigurera tjänstbrandväggar för att begränsa åtkomsten:

  • Aktivera tjänstens brandväggsfunktioner: För tjänster som stöder inbyggda brandväggar (t.ex. Azure Storage, Azure SQL Database, Azure Key Vault) aktiverar du brandväggsfunktioner antingen när resurser skapas eller på befintliga resurser för att styra vilka nätverk som kan komma åt tjänsten.

  • Definiera IP-baserade eller VNet-baserade regler: Konfigurera brandväggsregler för att endast tillåta åtkomst från specifika offentliga IP-intervall (t.ex. företagskontorsnätverk) eller specifika undernät för virtuella Azure-nätverk, implementera åtkomst med minsta möjliga behörighet genom att neka alla andra källor.

  • Inaktivera offentlig åtkomst när det är möjligt: När tjänster endast kräver åtkomst från privata nätverk använder du växlingsalternativet för att helt inaktivera åtkomst till offentliga nätverk, vilket säkerställer att tjänsten inte kan nås från Internet oavsett IP-baserade regler.

NS-2.4 Använd nätverkssäkerhetsperimeter för PaaS-resursisolering

Nätverkssäkerhetsperimeter upprättar en logisk nätverksgräns runt flera PaaS-resurser, vilket möjliggör säker tjänst-till-tjänst-kommunikation inom en explicit betrodd perimeter samtidigt som obehörig dataexfiltrering förhindras. Till skillnad från kontroller per resurs tillhandahåller Nätverkssäkerhetsperimeter en enhetlig säkerhetsgräns som tillåter kommunikation inom perimeterområdet utan enskilda åtkomstregler samtidigt som extern åtkomst blockeras som standard.

Implementera nätverkssäkerhetsperimeter för att skydda PaaS-resurser:

  • Skapa och associera resurser: Upprätta en nätverkssäkerhetsperimeter och lägg till PaaS-resurser som stöds (Azure Storage, SQL Database, Key Vault, Event Hubs, Cosmos DB) via resursassociationer, vilket möjliggör kommunikation inom perimeterområdet där associerade resurser fritt kan kommunicera.

  • Konfigurera åtkomstlägen och regler: Börja med övergångsläget för att förstå åtkomstmönster innan du övergår till framtvingat läge för maximalt skydd. Definiera explicita regler för inkommande och utgående åtkomst med hjälp av IP-adresser, prenumerationer eller FQDN:er för att styra trafik utanför perimetern och bibehålla en standardhållning för avslag.

  • Aktivera övervakning och Private Link-integrering: Konfigurera diagnostikloggar för att samla in åtkomstförsök och principöverträdelser. Privat slutpunktstrafik tillåts automatiskt i perimetern, vilket kompletterar VNet-till-PaaS-anslutning med dataexfiltreringskontroller på perimeternivå.

Exempel på implementering

En organisation behövde skydda backend-databasen och lagringsresurser medan den möjliggjorde åtkomst från programtjänster utan att exponera resurser för offentliga internet.

Utmaning: Organisationen hade Azure SQL Database- och Azure Storage-konton med offentliga standardslutpunkter, vilket gjorde dem tillgängliga från Internet och skapade betydande dataexfiltreringsrisker. Programtjänster distribuerades med offentliga IP-adresser och saknade VNet-integrering, vilket förhindrade privata nätverksbaserade åtkomstkontroller. Brandväggar på tjänstnivå har inte konfigurerats, vilket ger obegränsad åtkomst från alla källor när autentiseringen har slutförts.

Lösningsmetod:

  • Private Link-slutpunkter för PaaS-tjänster: Distribuerade privata slutpunkter för Azure SQL Database (tilldelad privat IP 10.0.2.4) och Azure Storage-konto (tilldelad privat IP 10.0.2.5) i ett dedikerat privat slutpunktsundernät (10.0.2.0/24), upprätta privat anslutning som dirigerar trafik över Azure-stamnätverket utan internetexponering.
  • Privata DNS-zoner för namnmatchning: Azure Private DNS-zoner skapades för att åsidosätta offentlig DNS-matchning, vilket säkerställer att FQDN för program (t.ex. mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) matchar privata IP-adresser i det virtuella nätverket i stället för offentliga slutpunkter, vilket upprätthåller sömlös anslutning för program som använder FQDN-baserad åtkomst.
  • VNet-integrering för programtjänster: Konfigurerad VNet-integrering för Azure App Service, distribuera programmet till ett programundernät (10.0.1.0/24) för att aktivera direkt kommunikation med privata slutpunkter utan att kräva offentliga IP-adresser eller Internetroutning.
  • Inbyggda brandväggar för tjänsten: Aktiverade brandväggar på tjänstnivå i Azure Storage för att begränsa åtkomsten till specifika VNet-undernät (programundernät 10.0.1.0/24) och betrodda Microsoft-tjänster, samtidigt som åtkomsten till det offentliga nätverket helt inaktiverades på tjänstnivå för Azure SQL Database för att framtvinga privat anslutning.
  • NSG-regler för djupskydd: Tillämpade NSG-regler på programundernätet som endast tillåter utgående trafik till det privata slutpunktsundernätet (10.0.2.0/24) på nödvändiga portar (443 för Storage, 1433 för SQL) och implementerar åtkomstkontroll med minst privilegier som kompletterar skydd på servicenivå.

Utfall: Organisationen eliminerade offentlig internetexponering för serverdelsresurser, vilket avsevärt minskade risken för dataexfiltrering och attackytan. Den privata anslutningen säkerställde att all trafik mellan program och datatjänster fanns kvar i Azures stamnätverk utan att passera det offentliga Internet, medan kontroller i lager (Private Link, DNS-zoner, tjänstbrandväggar, NSG:er) gav skydd på djupet i linje med principer för noll förtroende.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-7(4), SC-7(5), AC-4(21)
  • PCI-DSS v4: 1.3.1, 1.3.2, 1.4.2
  • CIS-kontroller v8.1: 12.4, 12.7
  • NIST CSF v2.0: PR. AC-05, PR. DS-05
  • ISO 27001:2022: A.8.20, A.8.22
  • SOC 2: CC6.1, CC6.6

NS-3: Distribuera brandväggen i utkanten av företagsnätverket

Azure Policy: Se Inbyggda principdefinitioner i Azure: NS-3.

Säkerhetsprincip

Använd brandväggen vid nätverksgränsen för att utföra avancerad filtrering av nätverkstrafik till och från externa nätverk, till exempel Internet, och mellan interna nätverkssegment.

Brandväggsprincipen bör minst innehålla:

  • Blockera kända felaktiga IP-adresser och webbplatser.
  • Begränsa högriskprotokoll, till exempel fjärrhanteringsprotokoll och intranätprotokoll i gränsnätverk för att förhindra obehörig åtkomst eller lateral förflyttning.
  • Tillämpa applikationsregler för att endast tillåta godkända externa mål och blockera obehöriga eller riskfyllda webbplatser.

Risk att mildra

Angripare utnyttjar sårbarheter som exponeras för offentliga eller obetrodda nätverk via tillgängliga protokoll, skadliga domäner och svaga nätverkskontroller.

  • Obehörig åtkomst via exponerade protokoll: Offentligt tillgängliga protokoll som RDP (TCP 3389) eller SMB (TCP 445) gör det möjligt för angripare att få obehörig åtkomst, vilket äventyrar systemintegriteten genom sårbarheter som råstyrkeattacker eller CVE-riktade attacker.
  • Skadlig kod och nätfiske via skadliga domäner/IP-adresser: Skadliga domäner och IP-adresser underlättar leverans av skadlig kod eller nätfiskekampanjer, vilket äventyrar slutpunkter och känsliga data genom kommando- och kontrollattacker eller sociala tekniska attacker.
  • Dataexfiltrering via obegränsad utgående trafik: Okontrollerad utgående trafik till ej godkända destinationer gör det möjligt för angripare att exfiltrera känsliga data, vilket riskerar överträdelser och efterlevnadsbrott via hemliga kanaler som HTTPS POST-förfrågningar.
  • Lateral rörelse på grund av dålig segmentering: Otillräcklig nätverkssegmentering gör att angripare kan pivotera internt och utnyttja trafik mellan segment (t.ex. SMB, Kerberos) för att spridas från komprometterade system.
  • Sårbarheter från ej betrodda program/URL:er: Åtkomst till riskfyllda eller ej betrodda URL:er och program ökar exponeringen för sårbarheter, ökar incidentriskerna och bristande efterlevnad av regelstandarder.

MITRE ATT&CK

  • Initial åtkomst (TA0001): obehörig åtkomst till högriskprotokoll (t.ex. RDP/TCP 3389, SSH/TCP 22) eller skadliga domäner (t.ex. T1190 – Exploit Public-Facing Application).
  • Kommando och kontroll (TA0011): skadlig kod som ansluter till skadliga IP-adresser/domäner (t.ex. T1071 – Application Layer Protocol).
  • Exfiltrering (TA0010): obehöriga dataöverföringar via utgående trafik till ej godkända mål (t.ex. T1041 – exfiltrering via C2-kanalen).
  • Sidledsrörelse (TA0008): hämmar intern förflyttning genom ofiltrerad segmentöverskridande trafik (t.ex. SMB/TCP 445, Kerberos/TCP 88) (t.ex. T1021 – Fjärrtjänster).

NS-3.1 Förbered för Azure Firewall-distribution

Azure Firewall-distributionen kräver korrekt nätverkstopologi som möjliggör centraliserad trafikkontroll över nätverksgränser. Hub-and-spoke-arkitekturer placerar brandväggen i nätverkskärnan och dirigerar all spoke-trafik via en central inspektionsplats medan användardefinierade vägar säkerställer att trafikflödet följer avsedda vägar. Den här förberedelsen etablerar grunden för omfattande gränsskydd och filtrering mellan segment.

Förbereda nätverksinfrastrukturen för Azure Firewall-distribution:

  • Konfigurera topologi för virtuellt nav/ekesnätverk: Distribuera Azure Firewall i ett virtellt hubbnätverk för att centralt hantera och skydda trafik över flera ekesnätverk som är värdar för programarbetsbelastningar och upprättar en enkel verkställighetspunkt för nätverkssäkerhetsprinciper.

  • Ansluta till virtuella ekernätverk: Använd VNet-peering för att ansluta varje eker-VNet till det virtuella hubbnätverket där Azure Firewall distribueras, vilket möjliggör kommunikation mellan ekrar via hubben samtidigt som nätverksisolering upprätthålls.

  • Konfigurera användardefinierade vägar (UDR): Skapa routetabeller som dirigerar nätverkstrafik från spoke-VNet via Azure Firewall i hubbnätverket, inklusive vägar för utgående internet (0.0.0.0/0) och eventuellt spoke-trafik om spoke-till-spoke-kommunikation kräver inspektion.

NS-3.2 Distribuera Azure Firewall med lämpliga principer

Azure Firewall tillhandahåller tillståndskänslig trafikfiltrering på programnivå med centraliserad principhantering i företagsnätverkssegment. Genom att kombinera nätverksregler, programregler och hotinformation inspekterar brandväggar trafikflöden i flera lager medan URL-filtrering och TLS-inspektion möjliggör detaljerad kontroll över HTTP/HTTPS-kommunikation. Korrekt principdesign balanserar säkerhetskrav med driftbehov via strukturerade regelhierarkier och kategoribaserad filtrering.

Distribuera och konfigurera Azure Firewall med omfattande principer:

  • Distribuera Azure Firewall i det virtuella hubbnätverket: Distribuera Azure Firewall (Standard- eller Premium-nivå baserat på de funktioner som behövs) i det virtuella hubbnätverket, och tilldela både offentliga IP-adresser för trafik ut mot internet samt privata IP-adresser för intern routing från spoke-VNet.

  • Skapa brandväggsprinciper med filtreringsregler: Definiera Azure Firewall-principer som innehåller nätverksregler (IP-/portbaserad filtrering), programregler (FQDN-baserad filtrering) och hotinformationsregler, organisera regler i samlingar baserat på säkerhetskrav (t.ex. tillåta affärskritiska tjänster, blockera skadliga IP-adresser, neka riskfyllda kategorier).

  • Konfigurera URL-filtrering för HTTP/HTTPS-trafik: Implementera FQDN-baserade programregler för att tillåta eller neka specifika domäner (t.ex. tillåta *.microsoft.com, neka *.torrent) och konfigurera kategoribaserad filtrering för att blockera hela webbplatskategorier (t.ex. hackning, sociala medier) samtidigt som arbetsrelaterade kategorier tillåts.

  • Aktivera TLS-inspektion för avancerad filtrering: För distributioner på Premium-nivå aktiverar du TLS-inspektion genom att ladda upp certifikat till Azure Key Vault, så att brandväggen kan dekryptera, inspektera och omkryptera HTTPS-trafik för djupare URL-filtrering och hotidentifiering utöver SNI-baserad inspektion.

Exempel på implementering

En organisation med flera applikationsarbetsbelastningar i olika spoke-VNet behövde centraliserad nätverkssäkerhetsinspektion för all internettrafik och kommunikation mellan de olika spokar, samtidigt som åtkomst till skadliga domäner och obehöriga webbkategorier förhindrades.

Utmaning: Organisationen hade arbetslaster distribuerade i separata spoke-VNet:er med direkt tillgång till internet, vilket skapade inkonsekventa säkerhetsprinciper och utan möjlighet att inspektera trafiken centralt. Varje eker hade sina egna NSG-regler, vilket ledde till policyavvikelser och säkerhetsluckor. Det fanns ingen insyn i utgående anslutningar till potentiellt skadliga domäner, ingen möjlighet att blockera riskfyllda webbplatskategorier (sociala medier, fildelning) och ingen inspektion av HTTPS-trafikinnehåll. Trafik mellan ekrar flödade fritt utan inspektion, vilket möjliggjorde potentiell lateral förflyttning efter kompromiss.

Lösningsmetod:

  • Topologi med nav och eker med centraliserad brandvägg: Distribuerade Azure Firewall Premium i ett virtuellt hubbnätverk (10.0.0.0/16) med dedikerade AzureFirewallSubnet (10.0.1.0/26, brandväggens privata IP 10.0.1.4) och upprättade en enda tvingande punkt för all nätverkstrafikkontroll och principhantering.
  • VNet-peering för ekeranslutning: Använde VNet-peering för att ansluta programekers-VNet (10.1.0.0/16) och databasers-VNet (10.2.0.0/16) till det virtuella hubbnätverket, vilket möjliggör centraliserad trafikroutning genom brandväggen.
  • Användardefinierade vägar för trafikstyrning: Skapade routningstabeller i varje virtuellt ekernätverk som omdirigerar all internetbunden trafik (0.0.0.0/0) och trafik mellan ekrar till den privata IP-adressen för Azure Firewall (10.0.1.4), vilket tvingar alla utgående trafik genom den centrala inspektionspunkten.
  • Brandväggsprinciper med filtrering i flera lager: Definierade omfattande Azure Firewall-principer , inklusive nätverksregler (tillåt DNS UDP/53 till Azure DNS, neka alla andra protokoll som standard), programregler (tillåt affärskritiska FQDN:er som *.microsoft.com, neka fildelningsdomäner som *.torrent) och hotinformationsregler (blockera kända skadliga IP-adresser från Hotflöden i Microsoft Defender).
  • URL-filtrering och kategoribaserad blockering: Implementerade FQDN-baserade programregler för exakt domänkontroll och kategoribaserad filtrering för att blockera hela webbplatskategorier (hackning, sociala medier, hasardspel) samtidigt som arbetsrelaterade kategorier (Företag/ekonomi, teknik/Internet) framtvingade godtagbara användningsprinciper vid nätverksgränsen.
  • TLS-inspektion för HTTPS-trafik: Aktiverad TLS-inspektion med certifikat som lagras i Azure Key Vault, vilket gör att brandväggen kan dekryptera, inspektera och omkryptera HTTPS-trafik för djupare URL-filtrering och hotidentifiering utöver SNI-baserad inspektion, samtidigt som känsliga bankdomäner undantas från dekryptering enligt efterlevnadskrav.

Utfall: Organisationen etablerade centraliserad synlighet och kontroll över all internetbunden och inter-spoke-trafik, vilket eliminerar principavvikelser och säkerhetsblinda fläckar. TLS-inspektion aktiverade identifiering av hot dolda i krypterad HTTPS-trafik, medan kategoribaserad filtrering avsevärt minskade exponeringen för riskabelt webbinnehåll. Hub-and-spoke-arkitekturen gav en skalbar och konsekvent säkerhetsstatus för alla arbetsbelastningar med enhetlig principhantering och omfattande skydd mot hot.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-7, SC-7(5), AC-4, SI-4(4)
  • PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
  • CIS-kontroller v8.1: 9.2, 9.3, 13.1
  • NIST CSF v2.0: PR. AC-05, PR. PT-04, DE. CM-01
  • ISO 27001:2022: A.8.20, A.8.22
  • SOC 2: CC6.1, CC6.6, CC7.2

NS-4: Distribuera system för intrångsidentifiering/intrångsskydd (IDS/IPS)

Säkerhetsprincip

Använd system för identifiering av nätverksintrång och intrångsskydd (IDS/IPS) för att inspektera nätverket och nyttolasttrafik till och från din arbetsbelastning eller dina virtuella nätverk. Se till att IDS/IPS alltid är justerat för att tillhandahålla högkvalitativa aviseringar till SIEM-lösningen.

För mer djupgående identifiering och förebyggande på värdnivå, använd värdbaserade IDS/IPS eller en värdbaserad lösning för slutpunktsskydd (EDR) tillsammans med nätverksbaserade IDS/IPS.

Risk att mildra

Angripare utnyttjar sårbarheter i protokoll, program och intern trafik för att köra skadliga aktiviteter.

  • Protokollexploateringar: Sårbarheter i protokoll som RDP (TCP 3389) eller HTTP/HTTPS (TCP 80/443) möjliggör obehörig åtkomst eller systemkompromettering genom sårbarheter som CVE-riktade attacker.
  • Kommunikation med kommando och kontroll (C2): Skadliga servrar etablerar kontroll över komprometterade enheter via DNS-frågor eller IP-baserade återanrop, vilket underlättar beständig exploatering eller spridning av skadlig kod.
  • Programexploateringar: Attacker som SQL-inmatning, XSS (cross-site scripting) eller buffertspill riktar sig mot programsårbarheter för att stjäla data eller köra godtycklig kod.
  • Lateral förflyttning: Avvikande intern trafik, till exempel SMB-uppräkning (TCP 445) eller Kerberos-biljettmissbruk (TCP 88), signalerar angripares pivotering i nätverket.
  • Dataexfiltrering: Obehöriga dataöverföringar sker via krypterade kanaler (t.ex. HTTPS POST) eller stora mängder utgående trafik, med hjälp av döljande för att undvika upptäckt.

MITRE ATT&CK

  • Initial Åtkomst (TA0001): Obehöriga intrång via utnyttjande av sårbarheter i nätverket (t.ex. T1190 – Utnyttja exponerade applikationer).
  • Körning (TA0002): körning av skadlig kod från sårbarhetsexploateringar eller C2-nyttolaster (t.ex. T1059 – kommando- och skripttolk).
  • Kommando och kontroll (TA0011): C2-kommunikation med skadlig kod genom att använda DNS-frågor eller IP-baserade motringningar (t.ex. T1071 – Application Layer Protocol).
  • Lateral förflyttning (TA0008): avvikande intern trafik (t.ex. SMB-uppräkning) som indikerar omdirigering (t.ex. T1021 – Fjärrtjänster).
  • Exfiltrering (TA0010): obehöriga dataöverföringar via krypterade eller fördunklade kanaler (t.ex. T1041 – exfiltrering via C2-kanalen).

NS-4.1 Distribuera Azure Firewall Premium för IDPS

System för intrångsidentifiering och skydd ger signaturbaserad hotidentifiering genom att matcha nätverkstrafikmönster mot kända attacksignaturer, vilket möjliggör blockering i realtid av exploateringsförsök och skadlig kommunikation. Azure Firewall Premiums IDPS-funktion erbjuder kontinuerligt uppdaterade signaturbibliotek som omfattar exploateringar, skadlig kod, kommandostyrning och kategorier som nätfiske samtidigt som både endast varning och förebyggande lägen stöds. Korrekt signaturval och justering säkerställer detektion med hög precision samtidigt som falska positiva resultat minimeras.

Distribuera och konfigurera IDPS via Azure Firewall Premium:

  • Distribuera Azure Firewall Premium: Distribuera Azure Firewall Premium med Premium Policy i ditt virtuella hubbnätverk för att aktivera IDPS-funktioner tillsammans med andra avancerade funktioner som TLS-inspektion och URL-filtrering.

  • Välj IDPS-signaturregler: Välj IDPS-signaturregler från signaturbiblioteket baserat på hotprioriteringar, från och med signaturer med hög allvarlighetsgrad i kritiska kategorier som "Malware", "Exploits" och "Phishing" som överensstämmer med organisationens hotprofil och risktolerans.

  • Konfigurera IDPS-läge: Ställ in IDPS-läget på Aviseringsläge först för testning och justering för att observera signaturmatchningar utan att blockera trafik, och övergå sedan till aviserings- och neka-läge för produktionsmiljöer för att aktivt förhindra identifierade hot samtidigt som aviseringar för säkerhetsövervakning upprätthålls.

  • Finjustera signaturer: Justera enskilda signaturregler baserat på driftserfarenhet, inaktivera eller sänka prioriteten för signaturer som genererar för höga falska positiva identifieringar samtidigt som högprioriterade signaturer förblir aktiva, vilket optimerar signal-till-brus-förhållandet för säkerhetsåtgärdsteam.

Exempel på implementering

En organisation som behövs för att skydda kritisk infrastruktur från kända kryphål och nolldagarsattacker samtidigt som man behåller insynen i hotaktiviteten utan att störa legitima affärsverksamheter.

Utmaning: Organisationen drev ett webbprogram med flera nivåer som bearbetar finansiella transaktioner utan signaturbaserad hotidentifiering utöver grundläggande brandväggsregler. Säkerhetsteamen saknade insyn i försök att utnyttja programservrar, hade ingen förmåga att identifiera kommunikation med kommando och kontroll och upplevde falska positiva aviseringar från generiska IDS-lösningar som krävde omfattande justering.

Solution:

  • Azure Firewall Premium med IDPS: Distribuerade Azure Firewall Premium i hub-VNet och aktiverade IDPS-funktioner tillsammans med TLS-inspektion och URL-filtrering, och etablerade centraliserad signaturbaserad hotidentifiering för all spoke-VNet-trafik.

  • Val av signaturregel: Valda IDPS-signaturer med hög allvarlighetsgrad från kritiska kategorier, inklusive skadlig kod (Cobalt Strike, Metasploit, Ransomware C2), Exploits (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), Nätfiske (skörd av autentiseringsuppgifter) och kommando- och kontrollmönster.

  • Aviseringsläge och justering: Konfigurerade IDPS i aviseringsläge för inledande testning för att observera signaturmatchningar utan att blockera trafik, analysera aviseringar för att identifiera falska positiva identifieringar från legitima DevOps-verktyg och partner-API-anrop och skapade sedan signaturfel för kända scenarier samtidigt som högprioriterade CVE-signaturer var aktiva.

  • Övergång till förebyggande läge: IDPS övergick till aviserings- och neka-läge för produktion efter validering och blockerade aktivt identifierade hot, inklusive PaperCut-exploateringsförsök, Log4Shell-attacker och C2-kommunikation.

  • Sentinel-integrering: Konfigurerade diagnostikloggar till Log Analytics, skapade Sentinel-analysregler som korrelerar IDPS-identifieringar med autentiseringshändelser och etablerade automatisk incidentskapande för aviseringar med hög allvarlighetsgrad.

Utfall: Exploateringsförsök har blockerats för att förhindra fjärrkörning av kod. Kritisk sårbarhetsexploatering eliminerades innan en kompromiss inträffade. Frekvensen av falska positiva resultat minskade avsevärt samtidigt som den omfattande CVE-täckningen bibehölls. Säkerhetsteamen uppnådde snabb aviseringsgranskning och incidenthantering och upprättade kontinuerlig synlighet för hot med användbar intelligens för proaktivt skydd.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
  • PCI-DSS v4: 11.4.1, 11.4.2, 1.4.1
  • CIS-kontroller v8.1: 13.2, 13.6, 13.7
  • NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. CM-07
  • ISO 27001:2022: A.8.16, A.8.22, A.5.24
  • SOC 2: CC6.1, CC7.2

NS-5: Distribuera DDOS-skydd

Azure Policy: Se Inbyggda principdefinitioner i Azure: NS-5.

Säkerhetsprincip

Distribuera DDoS-skydd på olika nivåer för att effektivt minimera attacker mot olika tjänster och protokoll i både nätverks- och programskikten.

Risk att mildra

Hotaktörer attackerar nätverk, servrar eller program som använder överväldigande skadlig trafik för att orsaka avbrott i tjänsten.

  • Volymriska attacker (nätverkssvädringar): Angripare översvämmar nätverksgränssnitt med enorma trafikvolymer (t.ex. miljontals paket per sekund) för att avga bandbredden, routerbearbetningskapaciteten eller lastbalanserarens resurser, vilket gör att tjänsten inte är tillgänglig. Exempel är UDP-översvämningar, ICMP-översvämningar eller förstärkta DNS-reflektionsattacker som utnyttjar protokoll som NTP eller SSDP.
  • Protokollattacker (tillståndsöverbelastning): Angripare utnyttjar layer 3/4-protokollsårbarheter för att tömma tillståndskänsliga resurser, till exempel TCP-anslutningstabeller eller brandväggssessionstillstånd. Vanliga tekniker är TCP SYN-översvämningar, som överbelastar servrar med halvöppna anslutningar eller ACK-översvämningar som riktar sig mot tillståndskänsliga enheter.
  • Resursnivåattacker (programöverlagring): Begränsade Layer 7-attacker, till exempel HTTP GET/POST-översvämningar, målprogramresurser (t.ex. CPU-, minnes- eller databasanslutningar) för att överbelasta webbservrar eller API:er. Dessa attacker syftar till att uttömma beräkningsresurser, vilket orsakar svarstidstoppar eller avbrott.
  • Förstärkningsattacker: Angripare utnyttjar felkonfigurerade servrar (t.ex. DNS-, NTP- eller Plex Media-servrar på UDP 32414) för att förstärka trafiken och skicka små frågor som genererar stora svar riktade mot målet, vilket överbelastar nätverkskapaciteten. Exempel är DNS-förstärkning eller SSDP-reflektionsattacker.

MITRE ATT&CK

  • Effekt (TA0040): stör tjänstens tillgänglighet genom volymöversvämningar (t.ex. UDP/ICMP) eller resursöverbelastningar (t.ex. HTTP-översvämningar) för att neka åtkomst (t.ex. T1498 – Network Denial of Service).
  • Resursutveckling (TA0042): utnyttjar komprometterade system för förstärkningsattacker (t.ex. DNS/NTP-reflektion) för att skala attackpåverkan (t.ex. T1584 – Kompromettera infrastruktur).

NS-5.1 Implementera DDOS-skydd på lämplig nätverksnivå

Distribuera DDoS-skydd på både nätverks- och programlager för att skydda mot volymtriska och programspecifika attacker. Azure tillhandahåller flera skyddsnivåer: DDoS Network Protection för omfattande VNet-täckning med snabb svarssupport, DDoS IP Protection för kostnadseffektivt skydd av enskilda IP-adresser och skydd på programnivå via WAF. Konfigurera övervakning och aviseringar för att verifiera skyddets effektivitet och säkerställa programresiliens vid attacker:

  • Distribuera DDoS-skydd på nätverksnivå: Välj mellan DDoS Network Protection för arbetsbelastningsdistributioner som kräver omfattande VNet-täckning och stöd för snabba svar för attackundersökning och analys efter attack, eller DDoS IP-skydd för kostnadseffektivt skydd av ett begränsat antal IP-adresser utan stöd för snabba svar.

  • Distribuera DDoS-skydd på programnivå: Aktivera DDoS-skydd i Azure Web Application Firewall (WAF), Application Gateway eller Azure Front Door för att skydda mot programnivåattacker (Layer 7).

  • Konfigurera övervakning och aviseringar: Konfigurera aviseringar och övervaka mått och loggar från DDoS-skyddstjänsten och dina program för att säkerställa skyddseffektivitet, programresiliens och önskad prestanda under och efter attacker.

Anmärkning

Även utan att använda ovanstående DDoS-skyddstjänst erbjuder Azure DDoS-infrastrukturskydd, ett standardskydd på plattformsnivå på nätverksinfrastrukturnivå. Det här skyddet tillhandahålls kostnadsfritt och kräver ingen konfiguration eller aktivering.

Exempel på implementering

En e-handelsorganisation behövde omfattande DDoS-skydd för kundinriktade program med ökande volym- och programnivåattacker under högsäsong.

Utmaning: Organisationen drev en global e-handelsplattform med offentliga webbprogram, API:er och infrastruktur för innehållsleverans som exponerats för Internet. Under topphändelser upplevde plattformen flera DDoS-attacker, inklusive UDP-översvämningar, TCP SYN-översvämningar som uttömmer anslutningstabeller för lastbalanserare, HTTP-översvämningar som riktar sig mot utchecknings-API:er och DNS-förstärkningsattacker. Utan dedikerat DDoS-skydd orsakade dessa attacker tjänstavbrott, vilket resulterade i förlorade intäkter och kundens missnöje.

Solution:

  • DDoS-nätverksskydd:Aktiverat Azure DDoS Network Protection i virtuella produktionsnätverk som är värdar för kundinriktade program, vilket ger omfattande skydd på VNet-nivå med anpassningsbar justering, automatisk attackidentifiering i Lager 3 och 4 och realtidsreducering.

  • Skydd på programnivå: Distribuerade Azure Application Gateway med WAF för regionala program och Azure Front Door med WAF för global gränsleverans, vilket möjliggör Layer 7 DDoS-skydd med hastighetsbegränsning, HTTP-översvämningsidentifiering och botskyddsregler.

  • Skyddspolicykonfiguration: En DDoS-skyddsplan skapades för att associera alla produktions-VNets. Trafikmönster för adaptiv justering konfigurerades som lärandebaslinje, alltid på-slaget för trafikövervakning aktiverades, och skyddsprinciper definierades för att täcka UDP-översvämningar, TCP SYN-översvämningar, ICMP-översvämningar och protokollattacker.

  • Övervakning och avisering: Konfigurerade DDoS-diagnostikloggar som skickar attacktelemetri till Log Analytics-arbetsytan, skapade Azure Monitor-aviseringar som utlöser omedelbara meddelanden när attacker identifieras, upprättad Sentinel-arbetsbok som korrelerar DDoS-attacker med programprestandamått och konfigurerade Application Insights-övervakning av programmets hälsa under minskning.

  • Snabbinsats: Aktiverad DDoS Rapid Response ger direkt åtkomst till DDoS-skyddsexperter under aktiva attacker för attackanalys i realtid, utveckling av anpassad åtgärdsstrategi och kriminalteknik efter attack.

Utfall: DDoS-attacker under hög shoppingsäsong har åtgärdats utan avbrott i tjänsten. Volymöversvämmningar, SYN-översvämningar och HTTP-översvämningar blockerades automatiskt, vilket upprätthåller plattformens tillgänglighet. Rapid Response tillhandahöll expertanalys för avancerade attacker. Kritiska shoppingperioder bibehöll hög drifttid utan fördröjning i svarstid för kundtransaktioner under åtgärdsmoment.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
  • PCI-DSS v4: 6.4.2, 11.4.7
  • CIS-kontroller v8.1: 13.3
  • NIST CSF v2.0: PR. PT-05, DE. CM-01
  • ISO 27001:2022: A.8.13, A.8.24
  • SOC 2: CC6.1, CC7.2

NS-6: Distribuera brandvägg för webbprogram

Azure Policy: Se Inbyggda principdefinitioner i Azure: NS-6.

Säkerhetsprincip

Distribuera en brandvägg för webbprogram (WAF) och konfigurera regler för att skydda webbprogram och API:er från programspecifika attacker genom att inspektera, identifiera och filtrera skadlig HTTP/HTTPS-trafik.

Risk att mildra

Angripare utnyttjar sårbarheter i webbprogram för att få obehörig åtkomst, köra skadlig kod, stjäla autentiseringsuppgifter eller exfiltera data.

  • Inmatningsattacker (t.ex. SQL-inmatning, kommandoinmatning): Angripare utnyttjar sårbarheter för indataverifiering för att mata in skadlig kod i webbprogramfrågor eller -kommandon, vilket möjliggör obehörig databasåtkomst, dataexfiltrering eller systemintrång. SQL-inmatning (SQLi) manipulerar serverdelsfrågor (t.ex. lägger till OR '1'='1 till ett inloggningsformulär), medan kommandoinmatningen kör godtyckliga OS-kommandon (t.ex. ; rm -rf / via ett formulärfält).
  • HTTP-protokollöverträdelser och felaktiga begäranden: Angripare skickar felaktiga HTTP-begäranden (t.ex. ogiltiga huvuden, överdimensionerade nyttolaster eller icke-standardmetoder som TRACE) för att utnyttja sårbarheter i webbservrar eller program, vilket kan orsaka krascher eller obehörig åtkomst. Dessa attacker riktar sig mot felkonfigurerade servrar eller okopplade ramverk.
  • Robotdrivna attacker (t.ex. fyllning av autentiseringsuppgifter, skrapning): Automatiserade robotar startar autentiseringsattacker (t.ex. råtvingande inloggningsslutpunkter med stulna autentiseringsuppgifter) eller skrapar känsligt innehåll (t.ex. prisdata), överbelastar servrar eller komprometterar användarkonton. Dessa attacker utnyttjar svag autentisering eller oskyddade API:er.
  • Programspecifika kryphål (t.ex. fjärrfilinkludering, lokal filinkludering): Angripare utnyttjar sårbarheter för att inkludera skadliga filer (t.ex. inkludera 'http://evil.com/shell.php') eller komma åt lokala serverfiler (t.ex. .. /.. /etc/passwd) via manipulerade URL-parametrar eller formulärindata, vilket möjliggör kodkörning eller dataexponering.

MITRE ATT&CK

  • Inledande åtkomst (TA0001): Utnyttjar SQL-inmatning, XSS eller fjärrfilinkludering för att få tillträde (t.ex. T1190 – Exploit Public-Facing Application).
  • Körning (TA0002): Kör skadlig kod via kommandoinmatning, RFI eller XSS (t.ex. T1059 – kommando- och skripttolk).
  • Åtkomst till autentiseringsuppgifter (TA0006): Stjäl autentiseringsuppgifter via XSS eller credential stuffing (t.ex. T1539 – Stjäla webbsessionscookie, T1110 – Brute Force).
  • Samling (TA0009): Samlar in data via SQL-inmatning eller skrapning (t.ex. T1213 – Data från informationslagringsplatser).

NS-6.1 Konfigurera Azure WAF med lämpliga regler

Aktivera waf-funktioner (Web Application Firewall) i Azure Application Gateway, Azure Front Door eller Azure Content Delivery Network (CDN) för att skydda program och API:er från webbaserade attacker. Välj lämplig tjänst baserat på programkrav, konfigurera WAF-principer med inbyggda och anpassade regler, ange principläget baserat på säkerhetsstatus och associera principen med tjänstslutpunkten:

  • Välj lämplig WAF-tjänst: Välj Azure Application Gateway för VNet-värdbaserade program, Azure Front Door för global gränsleverans eller Azure CDN för innehållsintensiva arbetsbelastningar baserat på programkrav och arkitektur.

  • Konfigurera WAF-principer med inbyggda och anpassade regler: Börja med vanliga inbyggda regeluppsättningar som OWASP Core Rule Set (CRS 3.2) och botskyddsregler (Microsoft Bot Manager). Lägg till anpassade regler (t.ex. hastighetsbegränsning för >100 begäranden/min) och undantag för att minska falska positiva identifieringar baserat på hotlandskap och programsäkerhetsprofil.

  • Ange WAF-principläge: Använd identifieringsläget från början eller för icke-kritiska program för att undvika att störa legitim trafik under installationen och regeloptimeringen. Växla till förebyggande läge för kritiska program när reglerna har verifierats för att blockera skadliga begäranden.

  • Associera WAF-princip med tjänstslutpunkt: Associera WAF-principen med Application Gateway-, Front Door- eller CDN-slutpunkten för att säkerställa att all HTTP/HTTPS-trafik dirigeras via WAF för inspektion.

Exempel på implementering

En organisation som behövs för att skydda kundriktade webbprogram och API:er från SQL-inmatning, XSS-attacker och robotdriven autentiseringsfyllning och samtidigt upprätthålla prestanda för legitima användare.

Utmaning: Organisationen hade webbprogram distribuerade globalt utan skydd mot OWASP Top 10 sårbarheter, vilket resulterade i flera SQL-inmatningsförsök, robotdrivna attacker som överväldigade inloggningsslutpunkter och ingen insyn i skadliga trafikmönster. Programmen saknade begränsande kontroller, vilket möjliggjorde missbruk av API:er och autentiseringsuppgiftsangrepp, och det fanns ingen mekanism för att skilja legitima användare från skadliga robotar.

Lösningsmetod:

  • Val av WAF-tjänst: Distribuerade Azure Application Gateway med WAF för VNet-värdbaserade program och Azure Front Door med WAF för globalt distribuerade program som kräver gränsskydd och åtkomst med låg latens.
  • Inbyggda skyddsregeluppsättningar: Aktiverad OWASP Core Rule Set (CRS) 3.2 för att skydda mot SQL-inmatning, XSS (cross-site scripting), fjärrfilinkludering och andra vanliga webbsårbarheter och aktiverade Microsoft Bot Manager-regler för att identifiera och blockera skadliga robotar samtidigt som legitima sökrobotar och övervakningstjänster tillåts.
  • Anpassade regler för specifika hot: Implementerade hastighetsbegränsningsregler som blockerar klienter som överskrider 100 begäranden per minut för att förhindra API-missbruk och autentiseringsuppgifter, geofiltreringsregler som blockerar trafik från högriskregioner där tjänster inte är tillgängliga och IP-ryktesbaserade regler som blockerar begäranden från kända skadliga IP-intervall som identifieras via hotinformationsflöden.
  • Undantagshantering: Skapade riktade undantag för legitima affärsscenarier som /checkout-slutpunkter med komplexa formulärindata som utlöste falska positiva identifieringar i OWASP-regler, /upload-slutpunkter som hanterar stora filöverföringar och /api-slutpunkter med ovanliga men giltiga rubrikmönster från mobila program.
  • Identifiering till förebyggande övergång: Startade WAF i identifieringsläge i två veckor för att identifiera falska positiva identifieringar, förfinade regler och undantag baserat på legitima trafikmönster och övergick sedan till förebyggande läge för produktionsprogram för att aktivt blockera hot samtidigt som affärskontinuitet bibehålls.

Utfall: Organisationen eliminerade SQL-inmatnings- och XSS-exploateringsförsök, avsevärt minskade robotdrivna attacker via bot manager-regler och etablerade omfattande insyn i hot mot webbprogram. Hastighetsbegränsningskontroller förhindrade API-missbruk och credential stuffing, medan den successiva övergången från identifieringsläge till förebyggandeläge säkerställde att legitima användare inte upplevde några tjänsteavbrott.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
  • PCI-DSS v4: 6.4.1, 6.4.2, 11.4.7
  • CIS-kontroller v8.1: 13.2, 13.9
  • NIST CSF v2.0: PR. AC-05, PR. PT-05, DE. CM-04
  • ISO 27001:2022: A.8.20, A.8.22, A.8.25
  • SOC 2: CC6.1, CC6.6, CC7.2

NS-7: Hantera nätverkssäkerhet centralt och effektivt

Säkerhetsprincip

Om du vill minska driftrisken och felkonfigurationen i komplex och fragmenterad nätverksmiljö använder du molnbaserade nätverkshanteringsfunktioner för att centralisera, förenkla och tillämpa konsekventa nätverkssäkerhetskonfigurationer.

Risk att mildra

Brist på centraliserad kontroll resulterar i förbisedda eller inaktuella säkerhetsinställningar, vilket ökar risken för utnyttjande.

  • Inkonsekvent principframtvingande och felkonfigurationer: Decentraliserad hantering leder ofta till fragmenterade regeluppsättningar och principluckor, vilket gör det lättare för angripare att identifiera och utnyttja svaga punkter. Felkonfigurationer är mer sannolika, vilket ökar risken för oavsiktlig exponering eller oavsiktlig åtkomst.
  • Nedsatt synlighet och fördröjt svar: Utan en enhetlig hanteringsmetod blir övervakning och incidenthantering långsammare och mindre effektiva. Detta kan fördröja identifieringen av skadlig aktivitet, vilket ger angripare mer tid att eskalera attacker eller exfiltera data.
  • Problem med att upprätthålla efterlevnad: Otillräcklig central förvaltning komplicerar ansträngningarna att konsekvent uppfylla regel- och branschstandarder, vilket riskerar bristande efterlevnad och potentiella påföljder.

MITRE ATT&CK

  • Inledande åtkomst (TA0001): Utnyttjande av felkonfigurationer eller inaktuella säkerhetsinställningar för att få obehörig åtkomst (t.ex. T1190 – Exploit Public-Facing Application, T1133 – External Remote Services).
  • Defense Evasion (TA0005): Dra nytta av fragmenterade regeluppsättningar och brist på centraliserad övervakning för att undvika identifiering (t.ex. T1562 – Försämra försvar).
  • Lateral rörelse (TA0008): Flytta i sidled genom nätverket genom att utnyttja policyluckor eller föråldrad segmentering (t.ex. T1021 – Fjärrtjänster).
  • Kommando och kontroll (TA0011): Använda oövervakade eller felkonfigurerade nätverkssökvägar för att upprätta och underhålla C2-kanaler (t.ex. T1071 – Application Layer Protocol).

NS-7.1 Hantera nätverkssäkerhet centralt och effektivt

Använd Azures centraliserade verktyg och standardiserade metoder för att förenkla och skala nätverkssäkerhetshantering, säkerställa konsekvent tillämpning, minska felkonfigurationen och förbättra övervakningen. Implementera centraliserad principframtvingande, standardisera brandväggs- och routningshantering, aktivera omfattande övervakning och analys samt upprätthålla resurskonsekvens genom styrningsmetoder:

  • Implementera centraliserad principframtvingande: Använd Azure Virtual Network Manager (AVNM) för att definiera säkerhetsadministratörsregler som tillämpas konsekvent i prenumerationer och regioner. Behåll NSG:er för mikrosegmentering på arbetsbelastningsnivå. Tillämpa principer via nätverksgrupper (t.ex. efter miljö: prod, icke-prod).

  • Standardisera brandväggs- och routningshantering: Hantera Azure Firewall-regler via Firewall Manager med brandväggsprincipobjekt. Standardisera på IP-grupper och tjänsttaggar i stället för råa IP-adresser. Använd Azure Firewall Premium där TLS-inspektion, IDPS och URL-filtrering krävs. Föredra virtuella WAN-säkra hubbar eller en delad hub-and-spoke-topologi för att tillämpa routningsavsikten konsekvent.

  • Aktivera omfattande övervakning och analys: Använd virtuella nätverksflödesloggar v2 (för att ersätta NSG-flödesloggar). Aktivera Diagnostikloggar för Azure Firewall och integrera med Traffic Analytics, Log Analytics och Microsoft Sentinel. Använd brandväggsprincip-analys och regelträffräknare för att eliminera oanvända eller duplicerade regler.

  • Underhåll resurskonsekvens och styrning: Tillämpa CAF-namngivningskonventioner och obligatoriska resurstaggar på alla virtuella nätverk, NSG:er, brandväggsregler och grupper. Använd Defender för molnets adaptiva nätverkshärdning för att förfina övergivna regler.

Exempel på implementering

Användningsfall: Betalningsplattform för flera regioner konsoliderar nätverkssäkerheten i stor skala

Sammanhang: En medelstor betalningsprocessor som arbetar i östra USA och västra Europa med 4 prenumerationer (Prod, Non-prod, Delade tjänster, SecOps) under en hyresgäst behöver PCI-DSS-segmentering, färre incidenter på grund av regelavvikelser och centraliserad övervakning.

Centraliserad principframtvingande med Azure Virtual Network Manager:

  • Design: Skapa AVNM på hanteringsgruppsnivå. Definiera två nätverksgrupper: ng-prod och ng-nonprod med dynamiskt medlemskap efter subscriptionId-tagg. Skapa säkerhetsadministratörsregler (SAR) för att framtvinga organisationsskydd som utvärderas före NSG:er: Neka inkommande internet-till-ekrar (blockerar oönskad inkommande från Internet till alla ekerundernät), Allow-Hub-Infra (tillåter hubbtjänster – Brandvägg/Bastion – till ekrar), TillåtPlatform-DNS (tillåter DNS från hubblösare till ekrar).
  • Gränser för appteamet: Arbetslaster behåller NSG:er för mikrosegmentering (t.ex. webb till api :443, api till db :1433) inom varje tagg. NSG-ändringar ägs av appteam. SAR:er ägs av plattformssäkerhetsteamet.
  • Resultat: Skyddsräcken är konsekventa i båda regionerna. appteam kan inte oavsiktligt skapa direkt internetåtkomst även om en NSG är felkonfigurerad.

Brandväggs- och routningshantering med Firewall Manager och Virtual WAN:

  • Design: Distribuera virtuella WAN-säkra hubbar i varje region (USA, östra, Europa, västra). Koppla ekrar till närmaste hubb och aktivera routningsavsikt så att all Internetutgång inspekteras. Använd Firewall Manager med en global Firewall-policy (nivå: Premium) och två underordnade policies (Prod/Non-Prod) för överstyrningar av miljön.
  • Principstruktur: Basprincipen (global) innehåller Hotinformation inställd på Avisering + Neka, TLS-inspektion aktiverad för utgående HTTPS, IDPS i balanserat läge och utgående tillåtna regler med hjälp av tjänsttaggar (Lagring, KeyVault, AzureMonitor) och IP-grupper för partnerslutpunkter. Prod-underordnad princip har striktare URL-filtrering (blockera okategoriserad) och tillåt lista för betalningsgatewayer via IP-grupper. Policyn för icke-produktionsmiljö har bredare åtkomst till verktyg för utveckling via tjänsttaggar (AzureDevOps, AzureContainerRegistry).
  • Resultat: En enda fönsterruta för att hantera regler med ändringar som sprids till båda hubbarna. Routningen är konsekvent och alla utgående objekt inspekteras med TLS-dekryptering där det är tillåtet.

Övervakning och analys med Flow Logs v2 och Sentinel:

  • Konfiguration av telemetri: Aktivera virtuella nätverksflödesloggar v2 på alla virtuella nätverk och skicka till en central Log Analytics-arbetsyta i SecOps-prenumerationen. Konfigurera diagnostikloggar för Azure Firewall (Application, Nätverk, DNS, ThreatIntel, IDPS) till samma arbetsyta. Aktivera Traffic Analytics mot arbetsytan.
  • Optimeringsloop: Aktivera brandväggspolicyanalys och granska antalet träffar per månad. Skapa en Sentinel-arbetsbok som korrelerar flödesloggar (nord-syd och öst-väst), tillåt/neka brandväggsträffar och utlösa IDPS-signaturer. Automatisera en ändringsbegäran om en regel har 0 träffar på 45 dagar (kan tas bort) eller om en regel som nekar utlöses av ett produktionsundernät (eventuell felriktning).
  • Resultat: Efter två granskningscykler tas 18% av brandväggsregler och 22 inaktuella NSG-regler bort, vilket minskar svarstiden för regelutvärdering och ändringsrisk.

Resurskonsekvens och styrning med CAF och Defender för molnet:

  • Standarder: Använd CAF-namngivning (t.ex. vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) och obligatoriska taggar: env, owner, dataClass, costCenter.
  • Tillämpning: Använd Azure Policy-initiativ för att kräva NSG för varje undernät, kräva diagnostikinställningar på virtuella nätverk och brandvägg till den centrala LA-arbetsytan och neka skapande utan obligatoriska taggar. Aktivera Defender för molnet – Adaptiv nätverkshärdning på alla spokes med veckovisa åtgärder som granskas av SecOps CAB.
  • Resultat: Plattformsdriften uppmärksammas snabbt; överdrivet tillåtande regler skärps med hjälp av Defenders datadrivna rekommendationer.

Distributionssekvens- och acceptanskriterier:

  • Ställ upp vWAN-säkra hubbar, koppla ekrar, aktivera routningssyfte (endast pilot-ekrar). Godkännandekriterier: Pilot-spokes utgående via brandvägg; inga offentliga IP-adresser är direkt åtkomliga.
  • Distribuera AVNM SAR:erna till ng-nonprod, verifiera inga avbrott och sedan till ng-prod. Acceptanskriterier: Syntetiska testsökningar bekräftar att hubbtjänsterna (DNS/Bastion) fortfarande når ekrarna; inkommande Internetåtkomst nekas fortfarande.
  • Aktivera vNet Flow Logs v2 och all brandväggsdiagnostik; starta Sentinel-arbetsbok. Kriterier för godkännande: Instrumentpaneler visar flöden, blockeringar, IDPS-träffar per region.
  • Tillämpa principinitiativ; åtgärda icke-kompatibla objekt. aktivera adaptiv härdning. Godkännandevillkor: Efterlevnaden når 95%, en backlogg av punkter för NSG-/brandväggsåtstramning har skapats.
  • Första principanalysgranskning; ta bort oanvända regler via ändringsfönstret. Godkännandekriterier: Regelantalet minskade med 15% utan kundpåverkan.

Exempel på operativa runbooks:

  • Azure Virtual Network Manager SAR: Neka inkommande internet till ekrar (Prioritet 100), Tillåt hubbinfrastruktur till ekrar (Prioritet 200: src 10.0.0.0/16 hubbintervall)
  • Brandväggsprincipstruktur: azfw-policy-global-01 (Premium) med regelsamlingarna Allow-Azure-Platform-ST (Service Tags) och Allow-Partners-IPs (IP Groups: ipg-payment-gws), plus underordnade principer azfw-policy-prd-01 och azfw-policy-npd-01
  • Diagnostik: Mål: law-secops-01, Kategorier: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: CM-2, CM-3, CM-6, CA-7, SI-4
  • PCI-DSS v4: 1.4.5, 11.5.1, 12.4.1
  • CIS-kontroller v8.1: 4.1, 4.2, 12.4, 13.6
  • NIST CSF v2.0: PR.IP-01, DE.CM-01, DE.CM-07
  • ISO 27001:2022: A.8.9, A.8.32, A.5.37
  • SOC 2: CC6.6, CC7.2, CC8.1

NS-8: Identifiera och inaktivera osäkra tjänster och protokoll

Azure Policy: Se Inbyggda principdefinitioner i Azure: NS-8.

Säkerhetsprincip

Identifiera och inaktivera osäkra tjänster och protokoll i operativsystemet, programmet eller programvarupaketlagret. Distribuera kompenserande kontroller om det inte går att inaktivera osäkra tjänster och protokoll.

Risk att mildra

Hotaktörer utnyttjar osäkra och sårbara tjänster och protokoll för att kompromettera system och data.

  • Utnyttjande av kryptografisk svaghet: SSL/TLSv1 och svaga chiffer (t.ex. RC4, DES) är sårbara för MITM-attacker (t.ex. POODLE, BEAST), vilket gör det möjligt för angripare att dekryptera känsliga data som sessionstoken via utfyllnadsorakel eller valda chiffertextattacker.
  • Obehörig åtkomst via protokollexploateringar: SSHv1- och SMBv1-sårbarheter (t.ex. CVE-2001-1473, CVE-2017-0144/EternalBlue) tillåter fjärrkörning av kod eller oautentiserad åtkomst, vilket aktiverar inledande fotfästen.
  • Stöld av autentiseringsuppgifter: LM/NTLMv1 och wDigest lagrar svaga hashar eller autentiseringsuppgifter i klartext, sårbara för pass-the-hash- eller minnesskrap (t.ex. Mimikatz-extrahering av LSASS-data).
  • Lateral förflyttning: SMBv1:s okrypterade sessioner och kryphål (t.ex. EternalBlue) möjliggör spridning av skadlig kod eller relä för autentiseringsuppgifter över nätverk.

MITRE ATT&CK

  • Inledande åtkomst (TA0001): Utnyttjande av osäkra protokoll som SSL/TLSv1 eller SSHv1, som är sårbara för protokollnedgraderingsattacker eller kända kryphål som blockerar obehöriga inmatningar (t.ex. T1190 – Exploit Public-Facing Application).
  • Åtkomst till autentiseringsuppgifter (TA0006): Stöld av autentiseringsuppgifter genom att utnyttja LM/NTLMv1 och wDigest, som lagrar autentiseringsuppgifter i reversibla format eller svaga hashar, omintetgör pass-the-hash eller minnesskrapning (t.ex. T1003 - OS Credential Dumping).
  • Lateral rörelse (TA0008): Förhindrar angripares pivotering av SMBv1 som är sårbar för kryphål som EternalBlue, vilket förhindrar spridning över nätverk (t.ex. T1021 – Fjärrtjänster).

NS-8.1 Identifiera och inaktivera osäkra tjänster och protokoll

Använd Microsoft Sentinels inbyggda arbetsbok för osäkert protokoll för att identifiera och minimera osäkra tjänster och protokoll i din Azure-miljö. Den här arbetsboken identifierar användning av protokoll och tjänster som inte uppfyller lämpliga säkerhetsstandarder, till exempel SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, svaga chiffer i Kerberos och osignerade LDAP-bindningar. Inaktivera dessa osäkra protokoll och tjänster efter identifieringen. När det inte är möjligt att inaktivera kan du implementera kompenserande kontroller för att minska attackytan.

Identifiera osäkra protokoll: Använd Microsoft Sentinels arbetsbok för osäkert protokoll för att identifiera användningen av SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, svaga Kerberos-chiffer och osignerade LDAP-bindningar i din miljö.

Inaktivera osäkra tjänster och protokoll: Inaktivera identifierade osäkra tjänster och protokoll som inte uppfyller lämpliga säkerhetsstandarder för att eliminera sårbarheter.

Implementera kompenserande kontroller: Om det inte går att inaktivera osäkra tjänster eller protokoll på grund av affärskrav eller tekniska begränsningar kan du använda kompenserande kontroller som att blockera åtkomst till resurser via nätverkssäkerhetsgrupper, Azure Firewall eller Azure Web Application Firewall för att minska attackytan.

Exempel på implementering

En sjukvårdsorganisation behövde eliminera osäkra protokoll i sin Azure-miljö för att uppfylla HIPAA-efterlevnadskrav och minska attackytan för skyddad hälsoinformation.

Utmaning: Organisationen drev en hybridinfrastruktur med äldre program som kräver anslutning till Azure-värdbaserade resurser. Säkerhetsbedömning avslöjade utbredd användning av osäkra protokoll, inklusive SSL/TLSv1.0 på webbservrar som betjänar patientportaler, SMBv1 aktiverat på filservrar för äldre programvara för medicinsk avbildning, LM/NTLMv1-autentisering på domänkontrollanter och programservrar, wDigest-autentisering som lagrar autentiseringsuppgifter i reversibelt format, osignerade LDAP-bindningar på Active Directory-kontrollanter och svag Kerberos-kryptering på tjänstkonton. Organisationen saknade insyn i protokollanvändningen och drabbades av potentiella överträdelser av HIPAA-efterlevnaden.

Solution:

  • Distribution av sentinel-arbetsbok med osäkert protokoll: Distribuerade Microsoft Sentinel och installerade arbetsboken Osäkert protokoll från innehållshubben, anslutna datakällor, inklusive Händelseloggar för Windows-säkerhet, Azure Monitor-loggar, Active Directory-loggar och nätverksflödesloggar, vilket upprättar en omfattande baslinje för osäker protokollanvändning i hybridmiljön.

  • Protokollidentifiering: Använde osäker protokollarbetsbok för att identifiera SSL/TLSv1.0-användning på webbservrar, SMBv1-trafik från äldre medicinska avbildningsarbetsstationer, LM/NTLMv1-autentiseringsmönster, wDigest aktiverat på Windows-servrar, osignerade LDAP-bindningar från äldre program och svag RC4 Kerberos-kryptering på tjänstkonton.

  • Systematisk inaktivering av protokoll: En stegvis reparationsplan har skapats som verifierats via ändringsrekommendationsnämnden, inaktiverat TLSv1.0/1.1 på webbservrar efter att ha bekräftat att användare av patientportalen drev moderna webbläsare med stöd för TLS 1.2+, inaktiverade SMBv1 efter samordning med programvaruuppgraderingar för medicinsk avbildningsleverantör, övergick domänkontrollanter från NTLMv1 till NTLMv2-autentisering, inaktiverade wDigest via grupprincip, framtvingade LDAP-signering på domänkontrollanter och uppgraderade tjänstkontot Kerberos-kryptering till AES256.

  • Kompenserande kontroller för undantag: Implementerade nätverksbaserade kompenserande kontroller för system som kräver tillfälligt stöd för osäkert protokoll, inklusive isolerat VLAN för äldre medicinska avbildningsarbetsstationer som kräver SMBv1, NSG-regler som begränsar SMBv1-trafik exklusivt till isolerad VLAN, Azure Firewall nekar utgående SMBv1 från produktionsundernät, dedikerad jump-värd för äldre HR-program och förbättrad övervakning via Defender for Endpoint flagga protokollanvändning utanför godkända undantagsundernät.

  • Kontinuerlig övervakning: Upprättade löpande protokollhygien via Microsoft Sentinel-analysregler som utlöser aviseringar för nya osäkra protokollanslutningar utanför godkända undantag, Azure Policy nekar distribution utan minimikrav för TLS 1.2 och veckovisa granskningar av osäker protokollarbetsbok som spårar reparationsförloppet.

Utfall: Svaga TLS-anslutningar eliminerades från patientportalerna. SMBv1 inaktiverades efter uppgraderingar av medicinsk avbildning, vilket eliminerade EternalBlue-sårbarheten och uppnådde HIPAA-efterlevnad. NTLMv1 övergick till NTLMv2, vilket förhindrar pass-the-hash-attacker. wDigest inaktiverad minimerad stöld av autentiseringsuppgifter. LDAP-signering blockerade osignerade frågor. Kerberos har uppgraderats till AES256, vilket minskar risken för Kerberoasting-attacker. Kompenserande kontroller innehöll äldre system utan lateral förflyttning. Fullständig HIPAA-efterlevnad uppnås.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-8, SC-8(1), SC-13, IA-5(1)
  • PCI-DSS v4: 2.2.4, 4.2.1, 6.2.4
  • CIS-kontroller v8.1: 4.8, 9.3, 13.4
  • NIST CSF v2.0: PR. DS-02, PR. IP-01, DE. CM-04
  • ISO 27001:2022: A.8.24, A.8.26, A.5.14
  • SOC 2: CC6.1, CC6.7, CC7.1

NS-9: Anslut lokalt eller molnbaserat nätverk privat

Säkerhetsprincip

Använd privata anslutningar för säker kommunikation mellan olika nätverk, till exempel datacenter för molntjänstleverantörer och lokal infrastruktur i en samlokaliseringsmiljö.

Risk att mildra

När data överförs via offentliga nätverk är de sårbara för avlyssning, obehörig åtkomst och manipulering.

  • Dataavlyssning: När data överförs via offentliga nätverk som Internet passerar de genom flera routrar, växlar och tjänsteleverantörer, av vilka någon kan komprometteras eller övervakas av skadliga aktörer. Angripare kan distribuera verktyg för paketsniffning (t.ex. Wireshark) för att samla in datapaket. Om data är okrypterade eller svagt krypterade kan känslig information , till exempel inloggningsuppgifter, ekonomisk information eller upphovsrättsskyddade affärsdata, exponeras.
  • MitM-attacker (Man-in-the-Middle): I en MitM-attack fångar en angripare i hemlighet upp och ändrar eventuellt kommunikationen mellan två parter som tror att de kommunicerar direkt med varandra. Detta utgör ett allvarligt hot mot känsliga åtgärder som finansiella transaktioner eller autentiseringsprocesser.
  • Obehörig åtkomst: Offentliga eller otillräckligt skyddade nätverk ökar sannolikheten för att obehöriga användare får åtkomst till eller manipulerar privata system eller resurser. Angripare kan utnyttja nätverksbrister för att nå intern infrastruktur som ska förbli otillgänglig utifrån.

MITRE ATT&CK

  • Inledande åtkomst (TA0001): Utnyttjande av okrypterade eller svagt krypterade protokoll (t.ex. HTTP- eller inaktuella TLS-versioner) som är sårbara för paketsniffning eller MitM-attacker, vilket möjliggör obehörigt inträde i system (t.ex. T1190 – Exploit Public-Facing Application).
  • Åtkomst till autentiseringsuppgifter (TA0006): Stöld av autentiseringsuppgifter via avlyssnad nätverkstrafik, utnyttjande av cleartext-protokoll (t.ex. Telnet eller FTP) eller svag kryptering som är känslig för dekryptering, vilket underlättar obehörig åtkomst (t.ex. T1040 – Nätverkssniffning).
  • Lateral rörelse (TA0008): Spridning i nätverk genom att utnyttja felkonfigurerade eller exponerade tjänster (t.ex. oskickad RDP eller SMB), vilket gör att angripare kan pivotera med stulna autentiseringsuppgifter eller sårbarheter (t.ex. T1021 – Fjärrtjänster).

NS-9.1 Använd azure virtual private network (VPN) för enkel plats-till-plats- eller punkt-till-plats-anslutning

Använd azure virtual private network (VPN) för att skapa säkra, krypterade anslutningar mellan lokala platser eller slutanvändarenheter och virtuella Azure-nätverk för enkla anslutningsscenarier. Azure VPN tillhandahåller en kostnadseffektiv lösning för plats-till-plats-anslutning (ansluta hela nätverk) eller punkt-till-plats-anslutning (ansluta enskilda enheter) utan att kräva dedikerad infrastruktur:

  • Distribuera plats-till-plats-VPN: Använd plats-till-plats-VPN för att på ett säkert sätt ansluta ditt lokala nätverk till det virtuella Azure-nätverket, vilket möjliggör sömlös kommunikation mellan lokala resurser och Azure-arbetsbelastningar.

  • Distribuera punkt-till-plats-VPN: Använd punkt-till-plats-VPN för att aktivera enskilda slutanvändarenheter (bärbara datorer, arbetsstationer) för att på ett säkert sätt ansluta till ett virtuellt Azure-nätverk från fjärrplatser.

NS-9.2 Använd Azure ExpressRoute (eller Virtual WAN) för anslutningar med höga prestanda på företagsnivå

Använd Azure ExpressRoute eller Azure Virtual WAN för att upprätta privata anslutningar med höga prestanda och låg latens mellan Azure-datacenter och lokal infrastruktur i samlokaliseringsmiljöer. Dessa lösningar i företagsklass kringgår det offentliga Internet, vilket ger dedikerad bandbredd, förutsägbar prestanda och förbättrad säkerhet för verksamhetskritiska arbetsbelastningar som kräver konsekvent anslutning:

  • Distribuera ExpressRoute för dedikerad privat anslutning: Använd Azure ExpressRoute för att skapa en privat anslutning mellan din lokala infrastruktur och Azure-datacenter via en anslutningsleverantör, vilket säkerställer dedikerad bandbredd och förutsägbar svarstid för företagsarbetsbelastningar.

  • Distribuera Virtual WAN för global anslutning: Använd Azure Virtual WAN för att skapa ett globalt nätverk som ansluter flera platser, grenar och Azure-regioner via en enhetlig hub-and-spoke-arkitektur med integrerade säkerhets- och routningsfunktioner.

NS-9.3 Använd VNet- eller undernätspeering för att ansluta till virtuella nätverk

Använd virtuellt nätverkspeering eller undernätspeering för att upprätta privata anslutningar mellan virtuella Azure-nätverk utan att dirigera trafik via det offentliga internet. Nätverkstrafik mellan peer-kopplade virtuella nätverk finns kvar i Azures stamnätverk, vilket ger anslutningar med låg svarstid och hög bandbredd utan krypteringskostnader. Välj peering för undernät när fullständig anslutning till virtuella nätverk är onödig, vilket begränsar exponeringen för endast specifika undernät:

  • Distribuera peering för virtuella nätverk: Använd peering för virtuella nätverk för att koppla samman hela Azure-nätverk, så att resurser i olika VNets kan kommunicera privat som om de var i samma nätverk.

Exempel på implementering

En multinationell organisation för finansiella tjänster behövde säker, högpresterande anslutning mellan lokala datacenter, avdelningskontor och Azure-molnresurser samtidigt som den offentliga internetexponeringen för känsliga finansiella transaktioner elimineras.

Utmaning: Organisationen drev flera lokala datacenter med avdelningskontor globalt, vilket krävde anslutning till Azure-värdbaserade program som bearbetar finansiella transaktioner och kunddata. Den första arkitekturen använde plats-till-plats-VPN via Internet, med oförutsägbara svarstider, bandbreddsbegränsningar under tider med hög handelstid, säkerhetsproblem om finansiella data som passerar offentligt Internet trots kryptering och efterlevnadskrav som kräver privat anslutning för PCI-DSS och GDPR. Fjärranställda som ansluter via punkt-till-plats-VPN har haft inkonsekventa prestanda- och autentiseringsproblem. Program i olika Azure-regioner krävde kommunikation mellan regioner med låg fördröjning utan routning via lokala hubbar.

Solution:

  • ExpressRoute för den primära datacenteranslutningen: Distribuerade Azure ExpressRoute-kretsar i primära datacenter via samlokaliseringsanläggningar med ExpressRoute-anslutningsleverantörer, upprättande av privat Layer 3-anslutning till Azure-stamnätverk med konsekvent låg svarstid, konfigurerad ExpressRoute med Microsoft-peering för Azure PaaS-tjänster och privat peering för VNet-värdbaserade resurser, implementerad BGP-routning med aktiv-aktiv konfiguration för hög tillgänglighet och automatisk redundans.

  • Plats-till-plats-VPN för avdelningskontorsanslutning: Distribuerad plats-till-plats-VPN för avdelningskontor som saknar åtkomst till samlokaliseringsfaciliteten, skapar VPN Gateway i hubb-VNet med aktiv-aktiv konfiguration för hög tillgänglighet, konfigurerade IPsec/IKE-tunnlar med stark kryptografi som uppfyller säkerhetsstandarder för finanssektorn, implementerad BGP-routning för dynamisk vägval som gör det möjligt för grenar att ansluta till närmaste regionala hubb, etablerade redundanta tunnlar som säkerställer anslutningen under underhållsperioder.

  • Punkt-till-plats-VPN för fjärranställda: Konfigurerad punkt-till-plats-VPN med Azure Active Directory-autentisering för fjärranställda som kräver säker åtkomst till Azure-värdbaserade program, aktiverad certifikatbaserad autentisering som reserv för scenarier utan Internetåtkomst till Azure AD, tilldelade klient-IP-adresser från dedikerad pool som dirigeras till Azure VNet-resurser via användardefinierade vägar, implementerat OpenVPN-protokoll för macOS/Linux-klienter och IKEv2/SSTP för Windows-klienter som ger bred enhetskompatibilitet. konfigurerad delade tunnlar som tillåter direkt Internetåtkomst för icke-företagstrafik vid routning av Azure-bunden trafik via VPN-tunnel som optimerar bandbredden.

  • Virtual WAN för global mesh-anslutning: Distribuerade Azure Virtual WAN med säkra hubbar i flera regioner som tillhandahåller global transitarkitektur, anslutna ExpressRoute-kretsar till Virtual WAN-hubbar som möjliggör alla-till-alla-anslutningar mellan datacenter och Azure-regioner utan routning via lokala hubbar, integrerade VPN-anslutningar från avdelningskontor till närmaste Virtual WAN-hubb med automatisk routningsoptimering, aktiverad Azure Firewall i varje Virtual WAN som tillhandahåller centraliserad säkerhetsinspektion för trafik mellan grenar, datacenter och virtuella Azure-nätverk, konfigurerade routningsprinciper som implementerar global transitroutning så att avdelningskontor kan kommunicera med lokala datacenter via Azure-stamnät.

  • VNet-peering för Azure-anslutning mellan regioner: Implementerad virtuell nätverkspeering som ansluter anslutande virtuella nätverk till virtuella WAN-hubbnätverk i varje region, aktiverad global VNet-peering för programanslutning mellan regioner som ger låg svarstid över Azures stamnät, konfigurerad gatewayöverföring som möjliggör för anslutande virtuella nätverk att använda Virtual WAN Hub VPN/ExpressRoute-gatewayer utan att behöva distribuera ytterligare gatewayer, vilket minskar kostnaden och komplexiteten, implementerade nätverkssäkerhetsgrupper på anslutande undernät som styr trafikflödet mellan peerkopplade virtuella nätverk med åtkomst enligt principen om minsta rättighet.

  • Trafikoptimering och övervakning: Konfigurerade ExpressRoute-kretsar med QoS-markeringar som prioriterar ekonomisk transaktionstrafik framför massdataöverföringar, aktiverad svarstid för spårning av anslutningsövervakare , paketförlust och tillgänglighet för ExpressRoute-kretsar och VPN-anslutningar med aviseringar för försämring, implementerade Azure Monitor-arbetsböcker som visualiserar global anslutningstopologi som visar aktiva anslutningar, bandbreddsanvändning och redundanshändelser, etablerade baslinjer för acceptabel prestanda med automatiserade aviseringar för tröskelvärdesöverträdelser.

Utfall: Privat anslutning uppnåddes för alla finansiella transaktioner som uppfyllde PCI-DSS krav. ExpressRoute gav konsekvent låg svarstid för realtidshandel. Virtual WAN har avsevärt minskat svarstiden för förgrening till datacenter. Fjärranställda har anslutits via punkt-till-plats-VPN med förbättrad autentisering. Global VNet-peering möjliggjorde effektiv katastrofåterställning över regioner. Kostnadsoptimering som uppnås via Virtual WAN-konsolidering.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-7, SC-7(4), SC-8
  • PCI-DSS v4: 1.2.1, 2.2.7, 4.2.1
  • CIS-kontroller v8.1: 12.8, 13.8
  • NIST CSF v2.0: PR. AC-05, PR. DS-02
  • ISO 27001:2022: A.8.21, A.8.22, A.5.14
  • SOC 2: CC6.6, CC6.7

NS-10: Säkerställ säkerheten för domännamnssystem (DNS)

Säkerhetsprincip

Se till att DNS-säkerhetskonfigurationen (Domain Name System) skyddar mot kända risker:

  • Använd betrodda auktoritativa och rekursiva DNS-tjänster i din molnmiljö för att säkerställa att klienten (till exempel operativsystem och program) får rätt lösningsresultat.
  • Separera den offentliga och privata DNS-matchningen så att DNS-matchningsprocessen för det privata nätverket kan isoleras från det offentliga nätverket.
  • Se till att DNS-säkerhetsstrategin även innehåller åtgärder mot vanliga attacker, till exempel dangling DNS, DNS-förstärkningsattacker, DNS-förgiftning och förfalskning och så vidare.

Risk att mildra

Hotaktörer attackerar DNS-tjänster eller utnyttjar sårbara DNS-tjänster för att kompromettera program och omdirigera trafik.

  • DNS-förfalskning/förgiftning: Angripare förfalskar DNS-svar eller skadade matchningscacheminnen (t.ex. Kaminsky-attack) för att omdirigera klienter till skadliga servrar, vilket möjliggör nätfiske eller dataavlyssning.
  • DNS-förstärkningsattacker: Angripare utnyttjar felkonfigurerade DNS-servrar för att förstärka DDoS-trafik (t.ex. 60 byte-fråga som ger svar på 4 000 byte), överväldigande målnätverk.
  • Danglande DNS-exploatering: Danglande poster (t.ex. föråldrade CNAME-poster) gör det möjligt för angripare att ta över avvecklade resurser och omdirigera trafik till skadliga slutpunkter för nätfiske eller spridning av skadlig kod.
  • Dataexfiltrering via DNS-tunnlar: Skadliga aktörer kodar data i DNS-frågor (t.ex. data.exfil.evil.com) för att i hemlighet exfiltera känslig information och kringgå brandväggar.
  • Leverans av nätfiske/skadlig kod: Komprometterade resolvers omdirigerar legitima domäner till angriparkontrollerade IP-adresser, vilket försörjer nätfiskesidor eller skadlig kod till intet ont anande klienter.

MITRE ATT&CK

  • Kommando och kontroll (TA0011): Använd DNS-tunneling för att koda C2-kommandon i frågor (t.ex. data.exfil.evil.com) eller förfalska upplösningar för att ansluta till skadliga servrar (t.ex. T1071.004 – Application Layer Protocol: DNS).
  • Samling (TA0009): Samla in data genom att förfalska DNS för att omdirigera användare till nätfiskewebbplatser eller exfiltratera data via tunneltrafik (t.ex. T1040 – Nätverkssniffning).
  • Effekt (TA0040): DNS-förstärkningsattacker, skicka små frågor för att generera stora svar, störa tjänstens tillgänglighet (t.ex. T1498.002 – Network Denial of Service: Reflection Amplification).
  • Inledande åtkomst (TA0001): Utnyttja hängande DNS-poster eller förfalskade lösningar för att leverera skadlig kod/nätfiske och få åtkomst till system (t.ex. T1190 – Exploit Public-Facing Application).

NS-10.1 Använd betrodd DNS-tjänst

Använd betrodda DNS-tjänster för att säkerställa att klienterna får rätt matchningsresultat och skyddar mot DNS-baserade attacker. Azure tillhandahåller den rekursiva DNS-tjänsten på 168.63.129.16 (vanligtvis tilldelad via DHCP eller förkonfigurerad) för DNS-matchning för arbetsbelastning på operativsystem- eller programnivå. Du kan också använda betrodda externa DNS-servrar. För organisationer som är värdar för sina egna domäner tillhandahåller Azure DNS tillförlitlig auktoritativ DNS-värd. Organisationer som skapar anpassade DNS-servrar bör följa NIST SP 800-81 Rev. 3 riktlinjer för säker distribution:

  • Använd Rekursiv DNS i Azure eller betrodd extern DNS: Konfigurera arbetsbelastningar så att de använder Rekursiv DNS i Azure (168.63.129.16) eller betrodda externa DNS-servrar i VM-operativsystem eller DNS-inställningar för program för att säkerställa tillförlitlig namnmatchning.

  • Tillåt Azure DNS i brandväggsregler: Lägg till 168.63.129.16 i brandväggs- och NSG-tillåtna listor för att säkerställa rätt DNS-funktioner för Azure-resurser.

  • Värddomäner i Azure DNS: Använd Azure DNS som värd för domänmatchning för auktoritativa DNS-behov, vilket ger tillförlitlig och skalbar DNS-värd (obs! Azure DNS tillhandahåller inte någon domänregistreringstjänst).

  • Följ riktlinjerna för säker DNS-distribution: Om du bygger anpassade DNS-servrar, följ NIST SP 800-81 Rev. 3 Deploymentsguiden för Secure Domain Name System (DNS) för att implementera säkerhetsmässig bästa praxis.

NS-10.2 Använd privat DNS i virtuellt nätverk

Använd Azure Private DNS för att upprätta privata DNS-zoner där DNS-upplösning förblir inom det virtuella nätverket, vilket hindrar DNS-frågor från att passera offentliga nätverk. Detta är viktigt för konfigurationer av privata slutpunkter, där privata DNS-zoner åsidosätter offentlig DNS-matchning för att dirigera trafik privat till Azure-tjänster. Anpassade DNS-lösningar kan ytterligare begränsa matchningen till endast betrodda källor, vilket ökar säkerheten för privata arbetsbelastningar:

  • Distribuera Azure Private DNS för privat lösning: Använd Privat DNS i Azure för att skapa privata DNS-zoner som håller DNS-matchning inom det virtuella nätverket, vilket säkerställer att frågor aldrig lämnar nätverksgränsen.

  • Konfigurera privat DNS för privata slutpunkter: Konfigurera privata DNS-zoner för privata slutpunkter för att åsidosätta offentlig DNS-matchning och se till att klienterna löser privata slutpunkts-FQDN:er till privata IP-adresser i det virtuella nätverket.

  • Implementera anpassad DNS för begränsad matchning: Använd anpassade DNS-servrar för att begränsa DNS-matchning för att endast tillåta betrodda lösningskällor för dina klienter, vilket ger ytterligare kontroll över namnmatchningssäkerhet.

NS-10.3 Använd Defender för DNS för avancerat skydd

Använd Microsoft Defender för DNS för att identifiera och varna för avancerade DNS-baserade säkerhetshot, inklusive dataexfiltrering via DNS-tunnlar, kommando- och kontrollkommunikation, skadliga domäninteraktioner (nätfiske, kryptoutvinning) och DNS-attacker som involverar skadliga matchare. Defender för DNS-skydd ingår nu i Defender för servrar-planen. Använd dessutom Microsoft Defender för App Service för att identifiera dinglande DNS-poster som kan aktivera underdomänövertagandeattacker när webbplatser inaktiveras:

  • Aktivera Defender för DNS-skydd: Använd Microsoft Defender för DNS (ingår i Defender för servrar-planen) för att övervaka och varna om misstänkt DNS-aktivitet, inklusive dataexfiltrering via DNS-tunnlar, kommando- och kontrollkommunikation för skadlig kod och interaktioner med skadliga domäner.

  • Övervaka skadlig DNS-aktivitet: Konfigurera aviseringar för att identifiera kommunikation med skadliga DNS-matchare och DNS-attacker som kan äventyra arbetsbelastningssäkerheten eller DNS-tjänstens tillgänglighet.

  • Identifiera dinglande DNS-poster: Använd Microsoft Defender för App Service för att identifiera dinglande DNS-poster vid inaktivering av App Service-webbplatser, vilket förhindrar underdomänövertagandeattacker genom att se till att anpassade domäner tas bort från DNS-registratorer.

Exempel på implementering

Utmaning: Ett företag behövde omfattande DNS-säkerhet som omfattar betrodda lösningstjänster, dns för privata nätverk för interna resurser och avancerad hotidentifiering i hybridmolninfrastrukturen.

Lösningsmetod:

  • Distribuerad Rekursiv DNS i Azure (168.63.129.16) för alla Azure VM-arbetsbelastningar med NSG-regler som tillåter DNS-trafik
  • Värdbaserade auktoritativa zoner i Azure DNS för lösning av offentlig domän med geo-distribution
  • Implementerade Privata DNS-zoner i Azure för privat slutpunktsmatchning (privatelink.database.windows.net, privatelink.blob.core.windows.net) som är länkade till virtuella produktionsnätverk
  • Konfigurerad privat DNS-integrering som säkerställer att privata slutpunkts-FQDN:er matchar privata IP-adresser (t.ex. sqlserver.database.windows.net → 10.0.2.4)
  • Aktiverad Microsoft Defender för DNS via Defender för servrar Planerar att övervaka DNS-tunnlar, C2-kommunikation och skadliga domäninteraktioner
  • Implementerade Defender för App Service för att identifiera överblivna DNS-poster när en webbplats tas ur bruk

Utfall: DNS-säkerhetsimplementeringen säkerställde tillförlitlig namnmatchning för molnarbetsbelastningar samtidigt som sekretessen för interna resurser bibehålls. Privata DNS-zoner förhindrade känsliga frågor från att passera offentliga nätverk, medan Defender för DNS gav insyn i DNS-baserade hot, inklusive dataexfiltreringsförsök och kommando- och kontrollaktivitet. Lösningen eliminerade underdomänövertaganderisker genom automatisk upptäckt av övergivna DNS-poster under ändringar i resurslivscykeln.

Kritiskhetsnivå

Måste ha gjort det.

Kontrollmappning

  • NIST SP 800-53 Rev.5: SC-7, SI-4, SI-4(4), SI-4(5)
  • PCI-DSS v4: 11.5.1, 12.10.1
  • CIS-kontroller v8.1: 8.5, 13.6, 13.8
  • NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. AE-02
  • ISO 27001:2022: A.8.16, A.8.22, A.5.24
  • SOC 2: CC6.1, CC7.2, CC7.3
  • Last updated on