Nätverks-ACL:er jämfört med säkerhetsgrupper

AWS tillhandahåller två olika brandväggsmekanismer i en VPC. Säkerhetsgrupper fungerar på instansnivå (tekniskt på ENI-nivå) och är tillståndsbaserade. Network Access Control Lists (NACL:er) fungerar på subnätsnivå och är tillståndslösa. Båda utvärderas för all trafik som går in i eller ut ur ett subnät och dess associerade instanser. Genom att använda båda tillsammans får Ni försvar i flera lager: NACL:er som första linje vid subnätsgränsen och säkerhetsgrupper som brandvägg för varje instans. SAA-C03-provet jämför ofta dessa två mekanismer.

En Network ACL (NACL) är en numrerad lista med regler som tillämpas på all trafik som passerar gränsen för ett subnät. NACL:er är tillståndslösa – varje paket utvärderas separat. Om Ni tillåter inkommande TCP-trafik på port 80 måste Ni uttryckligen tillåta utgående returtrafik (dynamiska portar 1024–65535) så att svaret kan lämna subnätet. Reglerna utvärderas i numerisk ordning (lägsta nummer först); den första matchande regeln gäller och inga fler regler kontrolleras. Varje VPC levereras med en standard-NACL som tillåter all inkommande och utgående trafik.

NACL-regler utvärderas i stigande ordning efter regelnummer (1 till 32766), och utvärderingen stoppas så snart en regel matchar – en Allow-regel med lägre nummer kan åsidosättas av en Deny-regel med ännu lägre nummer för samma trafik. AWS rekommenderar att Ni numrerar regler i steg om 10 eller 100 för att lämna utrymme för att infoga regler senare. Varje NACL avslutas med en standardregel (* DENY) som nekar all trafik som inte matchas av någon uttrycklig regel. Denna regel för allt annat kan inte redigeras eller tas bort.

Eftersom NACL:er är tillståndslösa måste Ni ta hänsyn till båda riktningarna för varje anslutning. När en klient på internet ansluter till Er EC2-instans på port 443 skickar instansen svaret tillbaka till klientens dynamiska port (en slumpmässig hög port, vanligtvis 1024–65535 på Linux och 49152–65535 på Windows). NACL:ens utgående regler måste uttryckligen tillåta detta intervall. Ett vanligt konfigurationsfel för NACL:er är att skapa en Allow-regel för inkommande port 443 men glömma att tillåta utgående dynamiska portar, vilket gör att anslutningar upprättas men att svaren tyst tappas bort.

Som en påminnelse: säkerhetsgrupper kopplas till instanser (eller ENI:er), tillåter endast uttryckliga Allow-regler (inga Deny-regler), är tillståndsbaserade (svar på tillåten inkommande trafik tillåts automatiskt utgående utan någon regel) och utvärderar alla kopplade regler tillsammans med OR-logik. Ni kan ange andra säkerhetsgruppers ID:n som källor eller destinationer, vilket är enklare att underhålla än IP-intervall. Säkerhetsgrupper är den primära mekanismen för åtkomstkontroll på instansnivå, medan NACL:er lägger till ett extra lager på subnätsnivå.

Viktig jämförelse inför provet:

• Nivå: NACL = subnät; SG = instans (ENI)
• Tillstånd: NACL = tillståndslös; SG = tillståndsbaserad
• Regler: NACL = Allow OCH Deny; SG = endast Allow (implicit nekande)
• Utvärdering: NACL = i ordning (första matchningen gäller); SG = alla regler utvärderas (en Allow räcker)
• Omfattning: NACL gäller för alla instanser i subnätet; SG gäller endast för associerade instanser
• Inkommande/utgående: NACL kräver uttryckliga regler i båda riktningarna; SG är tillståndsbaserad (endast inkommande regler behövs för svar)

Använd NACL:er för: blockering av specifika IP-adresser (säkerhetsgrupper kan inte neka trafik – de kan endast tillåta den; NACL:er kan lägga till uttryckliga Deny-regler för att blockera kända skadliga IP-adresser eller webbskrapare). Regler för hela subnät (tillämpa samma regel på alla instanser i ett subnät utan att ändra enskilda säkerhetsgrupper). Ett extra försvarslager (om en felkonfiguration i en säkerhetsgrupp av misstag öppnar åtkomst kan en Deny-regel i NACL:en vid subnätsgränsen fortfarande blockera trafiken). I praktiken hanterar de flesta team åtkomst främst genom säkerhetsgrupper och använder NACL:er endast för uttrycklig blockering av IP-adresser.

Standard-NACL:en (som skapas med varje VPC) tillåter all inkommande och utgående trafik – den har reglerna 100 Allow All Inbound och 100 Allow All Outbound. Subnät som inte uttryckligen associeras med en anpassad NACL använder standard-NACL:en. Om Ni skapar en anpassad NACL börjar den endast med standardregeln Deny-All (regel *), vilket blockerar all trafik tills Ni lägger till uttryckliga Allow-regler. Det innebär att all trafik omedelbart blockeras om Ni kopplar en ny anpassad NACL till ett subnät. Se därför till att lägga till Allow-regler innan Ni associerar den med produktionssubnät.

För inkommande trafik till en EC2-instans passerar trafiken först genom NACL:en vid subnätsgränsen (och utvärderas i regelordning). Om NACL:en tillåter trafiken når den sedan säkerhetsgruppen på instansen – säkerhetsgruppen måste också tillåta den. Båda måste tillåta trafiken för att den ska nå instansen. För utgående trafik utvärderas säkerhetsgruppen först (tillståndsbaserad – tillåt om trafiken är ett svar på tillåten inkommande trafik), och därefter NACL:en (tillståndslös – måste ha en uttrycklig utgående Allow-regel). Genom att förstå denna ordning blir det tydligt varför NACL:er behöver regler för returtrafik även när säkerhetsgrupperna är tillståndsbaserade.

NACL:er är en vanlig källa till svårfelsökta nätverksproblem på grund av sin tillståndslösa natur. Symptom är att anslutningar upprättas men att data slutar flöda (utgående regel för dynamiska portar saknas), enkelriktad trafik (inkommande eller utgående regel saknas) eller att specifika IP-adresser inte kan ansluta (en Deny-regel med lägre nummer matchar före Allow-regeln). Felsökningsmetod: använd VPC Flow Logs för att se om paket ACCEPTeras eller REJECTas på NACL-nivå. Flödesloggen visar de nekade paketen och deras källa och destination, vilket hjälper Er att hitta den saknade regeln.

Det rekommenderade mönstret för VPC-säkerhet i flera nivåer: NACL:er på offentliga subnät tillåter endast portarna 80 och 443 samt nödvändiga temporära portar från internet; allt annat nekas. Säkerhetsgrupper för offentliga subnät på ALB tillåter 80/443 från 0.0.0.0/0. Säkerhetsgrupper för privata applikationer tillåter endast trafik från säkerhetsgruppens ID för ALB. Säkerhetsgrupper för privata dataresurser tillåter endast trafik från säkerhetsgruppens ID för applikationen. Denna försvar-i-djupet-strategi säkerställer att ytterligare ett lager ger skydd även om ett lager är felkonfigurerat – en princip som kallas minsta åtkomst i varje lager.

I den här lektionen har ni lärt er att NACL:er är tillståndslösa brandväggar på subnätsnivå som stöder både Allow- och Deny-regler som utvärderas i numrerad ordning, att säkerhetsgrupper är tillståndsbevarande brandväggar på instansnivå med endast Allow-regler där alla regler utvärderas tillsammans, samt att NACL:er används för uttrycklig blockering av IP-adresser och regler som gäller hela subnät, medan säkerhetsgrupper används för finjusterad åtkomstkontroll på instansnivå. Därmed är modulen VPC Basics klar – härnäst går vi igenom RDS och relationsdatabaser i AWS.