Planlegge og implementere nettverkssikkerhetsgrupper (NSGs) og programsikkerhetsgrupper (ASGs)
Du kan bruke en sikkerhetsgruppe for Azure-nettverk til å filtrere nettverkstrafikk mellom Azure-ressurser i et virtuelt Azure-nettverk. En nettverkssikkerhetsgruppe inneholder sikkerhetsregler som tillater eller nekter inngående nettverkstrafikk til, eller utgående nettverkstrafikk fra, flere typer Azure-ressurser. For hver regel kan du angi kilde- og mål, portog protokoll.
Nettverkssikkerhetsgrupper (NSGer)
Sikkerhetsregler
En nettverkssikkerhetsgruppe inneholder så mange regler som ønsket, innenfor Azure-abonnementsgrenser. Hver regel angir følgende egenskaper:
| egenskap | Forklaring |
|---|---|
| Navn | Et unikt navn i nettverkssikkerhetsgruppen. Navnet kan være opptil 80 tegn langt. Det må begynne med et ordtegn, og det må slutte med et ordtegn eller med _. Navnet kan inneholde ordtegn eller '.', '-', '_'. |
| Prioritet | Et tall mellom 100 og 4096. Regler behandles i prioritert rekkefølge, med lavere tall behandlet før høyere tall, fordi lavere tall har høyere prioritet. Når trafikken samsvarer med en regel, stopper behandlingen. Som et resultat behandles ikke alle regler som finnes med lavere prioriteringer (høyere tall) som har de samme attributtene som regler med høyere prioriteringer. Standard sikkerhetsregler for Azure får det høyeste tallet med lavest prioritet for å sikre at egendefinerte regler alltid behandles først. |
| Kilde eller mål | En hvilken som helst, eller en individuell IP-adresse, klasseløs cidr-blokk (inter-domain routing) (10.0.0.0/24), for eksempel tjenestekode eller programsikkerhetsgruppe. Hvis du angir en adresse for en Azure-ressurs, angir du den private IP-adressen som er tilordnet ressursen. Nettverkssikkerhetsgrupper behandles etter at Azure oversetter en offentlig IP-adresse til en privat IP-adresse for innkommende trafikk, og før Azure oversetter en privat IP-adresse til en offentlig IP-adresse for utgående trafikk. Det kreves færre sikkerhetsregler når du angir et område, en tjenestekode eller en programsikkerhetsgruppe. Muligheten til å angi flere individuelle IP-adresser og -områder (du kan ikke angi flere servicekoder eller programgrupper) i en regel kalles utvidede sikkerhetsregler. Utvidede sikkerhetsregler kan bare opprettes i nettverkssikkerhetsgrupper som er opprettet gjennom ressursbehandlingsdistribusjonsmodellen. Du kan ikke angi flere IP-adresser og IP-adresseområder i nettverkssikkerhetsgrupper som er opprettet gjennom den klassiske distribusjonsmodellen. |
| Protokoll | TCP, UDP, ICMP, ESP, AH eller Any. ESP- og AH-protokollene er for øyeblikket ikke tilgjengelige via Azure-portalen, men kan brukes via Azure Resource Manager-maler. |
| Retning | Om regelen gjelder for inngående eller utgående trafikk. |
| Portområde | Du kan angi en enkeltperson eller et område med porter. Du kan for eksempel angi 80 eller 10000-10005. Ved å angi områder kan du opprette færre sikkerhetsregler. Utvidede sikkerhetsregler kan bare opprettes i nettverkssikkerhetsgrupper som er opprettet gjennom ressursbehandlingsdistribusjonsmodellen. Du kan ikke angi flere porter eller portområder i samme sikkerhetsregel i nettverkssikkerhetsgrupper som er opprettet gjennom den klassiske distribusjonsmodellen. |
| Handling | Tillat eller avslå |
Sikkerhetsregler evalueres og brukes basert på fem-tuppel (1. kilde, 2. kildeport, 3. mål, 4. målport og 5. protokoll) informasjon. Du kan ikke opprette to sikkerhetsregler med samme prioritet og retning. Det opprettes en flytpost for eksisterende tilkoblinger. Kommunikasjon er tillatt eller nektet basert på tilkoblingsstatusen for flytposten. Flytposten gjør at en nettverkssikkerhetsgruppe kan være tilstandsfull. Hvis du for eksempel angir en utgående sikkerhetsregel til en adresse over port 80, er det ikke nødvendig å angi en inngående sikkerhetsregel for svaret på utgående trafikk. Du trenger bare å angi en inngående sikkerhetsregel hvis kommunikasjon startes eksternt. Det motsatte er også sant. Hvis inngående trafikk er tillatt over en port, er det ikke nødvendig å angi en utgående sikkerhetsregel for å svare på trafikken over porten.
Eksisterende tilkoblinger kan ikke avbrytes når du fjerner en sikkerhetsregel som tillot tilkoblingen. Endring av regler for nettverkssikkerhetsgruppe påvirker bare nye tilkoblinger. Når en ny regel opprettes eller en eksisterende regel oppdateres i en nettverkssikkerhetsgruppe, gjelder den bare for nye tilkoblinger. Eksisterende tilkoblinger blir ikke revurdert med de nye reglene.
Slik filtrerer nettverkssikkerhetsgrupper nettverkstrafikk
Du kan distribuere ressurser fra flere Azure-tjenester til et virtuelt Azure-nettverk. Du kan knytte null, eller én, nettverkssikkerhetsgruppe til hvert virtuelle nettverksundernett og nettverksgrensesnitt i en virtuell maskin. Den samme nettverkssikkerhetsgruppen kan knyttes til så mange delnett og nettverksgrensesnitt som du velger. Bildet nedenfor illustrerer ulike scenarioer for hvordan nettverkssikkerhetsgrupper kan distribueres til tillate nettverkstrafikk til og fra Internett via TCP-port 80:
Referer til bildet, sammen med følgende tekst, for å forstå hvordan Azure behandler inngående og utgående regler for nettverkssikkerhetsgrupper:
Inngående trafikk
For innkommende trafikk behandler Azure reglene i en nettverkssikkerhetsgruppe som er knyttet til et delnett først, hvis det er en, og deretter reglene i en nettverkssikkerhetsgruppe som er knyttet til nettverksgrensesnittet, hvis det finnes en. Denne prosessen omfatter også intra-delnetttrafikk.
- VM1: Sikkerhetsreglene i NSG1- behandles, siden det er knyttet til delnett 1 og VM1- er i delnett 1. Med mindre du har opprettet en regel som tillater port 80 inngående, nekter DenyAllInbound standard sikkerhetsregel trafikken. Trafikken evalueres ikke av NSG2 fordi den er knyttet til nettverksgrensesnittet. Hvis NSG1- tillater port 80 i sikkerhetsregelen, behandler NSG2 trafikken. Hvis du vil tillate port 80 til den virtuelle maskinen, må både NSG1 og NSG2 ha en regel som tillater port 80 fra Internett.
- VM2: Reglene i NSG1- behandles fordi VM2- også er i delnett 1. Siden VM2- ikke har en nettverkssikkerhetsgruppe som er knyttet til nettverksgrensesnittet, mottar den all trafikk som er tillatt gjennom NSG1- eller nektes all trafikk som nektes av NSG1-. Trafikk er enten tillatt eller nektet alle ressurser i samme delnett når en nettverkssikkerhetsgruppe er knyttet til et delnett.
- VM3: Siden det ikke er noen nettverkssikkerhetsgruppe tilknyttet Delnett 2, er trafikk tillatt i delnettet og behandles av NSG2, fordi NSG2- er knyttet til nettverksgrensesnittet som er knyttet til VM3-.
- VM4: Trafikk kan VM4, fordi en nettverkssikkerhetsgruppe ikke er knyttet til Subnet 3eller nettverksgrensesnittet i den virtuelle maskinen. All nettverkstrafikk tillates via et delnett og nettverksgrensesnitt hvis de ikke har en nettverkssikkerhetsgruppe knyttet til seg.
Utgående trafikk
For utgående trafikk behandler Azure reglene i en nettverkssikkerhetsgruppe som er knyttet til et nettverksgrensesnitt først, hvis det finnes en, og deretter reglene i en nettverkssikkerhetsgruppe som er knyttet til delnettet, hvis det finnes en. Denne prosessen omfatter også intra-delnetttrafikk.
- VM1: Sikkerhetsreglene i NSG2- behandles. Den AllowInternetOutbound standard sikkerhetsregel i både NSG1 og NSG2 tillater trafikken med mindre du oppretter en sikkerhetsregel som nekter port 80 utgående til Internett. Hvis NSG2 nekter port 80 i sin sikkerhetsregel, nekter den trafikken, og NSG1 aldri evaluerer den. Hvis du vil nekte port 80 fra den virtuelle maskinen, må enten eller begge nettverkssikkerhetsgruppene ha en regel som nekter port 80 til Internett.
- VM2: All trafikk sendes via nettverksgrensesnittet til delnettet, siden nettverksgrensesnittet som er knyttet til VM2 ikke har en nettverkssikkerhetsgruppe tilknyttet. Reglene i NSG1 behandles.
- VM3: Hvis NSG2 nekter port 80 i sin sikkerhetsregel, nekter den trafikken. Hvis NSG2 ikke nekter port 80, tillater AllowInternetOutbound standard sikkerhetsregel i NSG2 trafikken fordi det ikke er noen nettverkssikkerhetsgruppe knyttet til Delnett 2.
- VM4: All nettverkstrafikk tillates fra VM4, fordi en nettverkssikkerhetsgruppe ikke er knyttet til nettverksgrensesnittet som er knyttet til den virtuelle maskinen, eller for å Delnett 3.
Intra-Subnet trafikk
Det er viktig å være oppmerksom på at sikkerhetsregler i en NSG som er knyttet til et delnett, kan påvirke tilkoblingen mellom virtuelle maskiner i det. Som standard kan virtuelle maskiner i samme delnett kommunisere basert på en standard NSG-regel som tillater intra-delnetttrafikk. Hvis du legger til en regel i NSG1- som nekter all inngående og utgående trafikk, kan ikke VM1- og VM2- kommunisere med hverandre.
Du kan enkelt vise aggregeringsreglene som brukes på et nettverksgrensesnitt, ved å vise de effektive sikkerhetsreglene for et nettverksgrensesnitt. Du kan også bruke IP-flyt til å bekrefte funksjonalitet i Azure Network Watcher for å finne ut om kommunikasjon er tillatt eller fra et nettverksgrensesnitt. Du kan bruke IP-flyt til å kontrollere om en kommunikasjon er tillatt eller avslått. I tillegg må du bruke IP-flyt til å kontrollere identiteten til nettverkssikkerhetsregelen som er ansvarlig for å tillate eller nekte trafikken.
Nettverkssikkerhetsgrupper er knyttet til delnett eller virtuelle maskiner og skytjenester som er distribuert i den klassiske distribusjonsmodellen, og til delnett eller nettverksgrensesnitt i ressursbehandlingsdistribusjonsmodellen.
Med mindre du har en bestemt grunn til det, anbefaler vi at du knytter en nettverkssikkerhetsgruppe til et delnett eller et nettverksgrensesnitt, men ikke begge deler. Siden regler i en nettverkssikkerhetsgruppe som er knyttet til et delnett, kan komme i konflikt med regler i en nettverkssikkerhetsgruppe som er knyttet til et nettverksgrensesnitt, kan du ha uventede kommunikasjonsproblemer som krever feilsøking.
Programsikkerhetsgrupper (ASGs)
Med programsikkerhetsgrupper kan du konfigurere nettverkssikkerhet som en naturlig utvidelse av en programstruktur, slik at du kan gruppere virtuelle maskiner og definere nettverkssikkerhetspolicyer basert på disse gruppene. Du kan bruke sikkerhetspolicyen på nytt i stor skala uten manuelt vedlikehold av eksplisitte IP-adresser. Plattformen håndterer kompleksiteten til eksplisitte IP-adresser og flere regelsett, slik at du kan fokusere på forretningslogikken. Hvis du vil forstå programsikkerhetsgrupper bedre, kan du vurdere følgende eksempel:
I det forrige bildet er NIC1 og NIC2 medlemmer av AsgWeb programsikkerhetsgruppe. NIC3 er medlem av AsgLogic programsikkerhetsgruppe. NIC4 er medlem av AsgDb programsikkerhetsgruppe. Selv om hvert nettverksgrensesnitt (NIC) i dette eksemplet bare er medlem av én nettverkssikkerhetsgruppe, kan et nettverksgrensesnitt være medlem av flere programsikkerhetsgrupper, opptil Azure Limits. Ingen av nettverksgrensesnittene har en tilknyttet nettverkssikkerhetsgruppe. NSG1- er knyttet til begge delnettene og inneholder følgende regler:
Tillat HTTP-Inbound-Internet
Denne regelen er nødvendig for å tillate trafikk fra Internett til nettserverne. Siden innkommende trafikk fra Internett nektes av standard sikkerhetsregelen DenyAllInbound, er det ikke nødvendig med noen ekstra regel for AsgLogic eller AsgDb programsikkerhetsgrupper.
| prioritet | kilde | kildeporter | mål | målporter | Protocol | Access |
|---|---|---|---|---|---|---|
| 100 | Internett | * | AsgWeb | 80 | TCP | Tillate |
Avslå-Database-All
Siden standard sikkerhetsregel for AllowVNetInBound tillater all kommunikasjon mellom ressurser i samme virtuelle nettverk, er denne regelen nødvendig for å nekte trafikk fra alle ressurser.
| prioritet | kilde | kildeporter | mål | målporter | Protocol | Access |
|---|---|---|---|---|---|---|
| 120 | * | * | AsgDb | 1433 | Enhver | Benekte |
Tillat-Database-BusinessLogic
Denne regelen tillater trafikk fra AsgLogic programsikkerhetsgruppe til AsgDb programsikkerhetsgruppe. Prioriteten for denne regelen er høyere enn prioriteten for regelen Avslå database-Alle. Som et resultat behandles denne regelen før regelen Deny-Database-All, slik at trafikk fra AsgLogic programsikkerhetsgruppe er tillatt, mens all annen trafikk blokkeres.
| prioritet | kilde | kildeporter | mål | målporter | Protocol | Access |
|---|---|---|---|---|---|---|
| 110 | AsgLogic | * | AsgDb | 1433 | TCP | Tillate |
Nettverksgrensesnitt som er medlemmer av programsikkerhetsgruppen, bruker reglene som angir det som kilde eller mål. Reglene påvirker ikke andre nettverksgrensesnitt. Hvis nettverksgrensesnittet ikke er medlem av en programsikkerhetsgruppe, brukes ikke regelen på nettverksgrensesnittet, selv om nettverkssikkerhetsgruppen er knyttet til delnettet.
Programsikkerhetsgrupper har følgende begrensninger:
Det er grenser for hvor mange programsikkerhetsgrupper du kan ha i et abonnement, og andre begrensninger knyttet til programsikkerhetsgrupper.
Alle nettverksgrensesnitt som er tilordnet en programsikkerhetsgruppe, må finnes i det samme virtuelle nettverket som det første nettverksgrensesnittet som er tilordnet til programsikkerhetsgruppen, er i. Hvis for eksempel det første nettverksgrensesnittet som er tilordnet en programsikkerhetsgruppe med navnet AsgWeb er i det virtuelle nettverket med navnet VNet1, må alle etterfølgende nettverksgrensesnitt tilordnet ASGWeb- finnes i VNet1-. Du kan ikke legge til nettverksgrensesnitt fra forskjellige virtuelle nettverk i samme programsikkerhetsgruppe.
Hvis du angir en programsikkerhetsgruppe som kilde og mål i en sikkerhetsregel, må nettverksgrensesnittene i begge programsikkerhetsgruppene finnes i samme virtuelle nettverk.
- Et eksempel ville være hvis AsgLogic hadde nettverksgrensesnitt fra VNet1 og AsgDb hadde nettverksgrensesnitt fra VNet2. I dette tilfellet ville det være umulig å tilordne AsgLogic som kilde og AsgDb som mål i en regel. Alle nettverksgrensesnitt for både kilde- og målprogramsikkerhetsgruppene må finnes i samme virtuelle nettverk.
Hvis du vil minimere antall sikkerhetsregler du trenger, og behovet for å endre reglene, må du planlegge programsikkerhetsgruppene du trenger, og opprette regler ved hjelp av servicekoder eller programsikkerhetsgrupper, i stedet for individuelle IP-adresser eller områder med IP-adresser, når det er mulig.