Så filtrerar Security Groups trafik

En security group (SG) är en virtuell brandvägg som ansluts direkt till ett elastiskt nätverksgränssnitt (ENI) på en resurs, till exempel en EC2-instans, en RDS-databas eller en lastbalanserare. Den kontrollerar inkommande och utgående trafik på resursnivå i stället för vid nätverksgränsen, så två instanser i samma subnät kan ha helt olika regler.

Security groups innehåller endast regler som tillåter. Det går inte att skriva ett uttryckligt deny. Trafik som inte matchar en allow-regel släpps helt enkelt inte igenom. Det innebär att Ni bygger åtkomst genom att lägga till de tillstånd Ni vill ha, medan standardbeteendet implicit blockerar allt annat.

En helt ny security group nekar all inkommande trafik och tillåter all utgående trafik. Ni öppnar avsiktligt för inkommande åtkomst, port för port, medan utgående trafik förblir helt öppen om Ni inte begränsar den. Scenarier på prov bygger ofta på att man kommer ihåg att utgående trafik som standard är tillåten.

Varje regel definierar ett protokoll (TCP, UDP, ICMP), ett portintervall och en källa (för inkommande trafik) eller ett mål (för utgående trafik). Källan kan vara ett CIDR-block, till exempel 10.0.0.0/16, eller ett annat security group-ID, vilket gör att Ni kan referera till grupper i stället för fasta IP-adresser.

Om Ni anger ett annat security group-ID som källa skapas dynamisk, identitetsbaserad åtkomst. En databas-SG kan till exempel tillåta port 5432 endast från SG:n för applikationslagret. När appservrar skalas upp och ned behövs inga IP-ändringar, eftersom medlemskapet i den refererade gruppen styr åtkomsten.

Security groups är stateful. När Ni tillåter en inkommande begäran tillåts svaret automatiskt ut, oavsett reglerna för utgående trafik, och vice versa. Anslutningen spåras, så Ni behöver aldrig skriva en matchande regel för returtrafiken. Detta är den största beteendemässiga skillnaden jämfört med network ACLs.

Ett enda ENI kan ha flera security groups anslutna samtidigt. Deras regler kombineras som en union: om någon ansluten grupp tillåter trafiken släpps den igenom. Det finns ingen regelordning eller prioritet, så Ni kan inte använda en grupp för att åsidosätta en annan med ett deny.

Tillämpa principen om minsta behörighet genom att endast öppna exakt de portar som varje lager behöver. Ett webblager kan tillåta 443 från internet, ett applager tillåter 8080 endast från webb-SG:n och ett datalager tillåter 3306 endast från app-SG:n. Denna kedjning mellan lager begränsar möjligheten till lateral förflyttning efter ett intrång.

Den farligaste felkonfigurationen är att tillåta 0.0.0.0/0 på port 22 eller 3389, vilket exponerar SSH eller RDP mot hela internet. GuardDuty och Security Hub flaggar detta. Föredra att inte ha några inkommande administrationsportar alls och använd i stället Session Manager, som behandlas i SSM-kursen.

Säkerhetsgrupper loggar inte själva tillåtna eller nekade paket. För att se vilken trafik som faktiskt flödade använder du VPC Flow Logs, som registrerar beslutet att acceptera eller avvisa varje anslutning. Kombinera utformningen av SG:er med Flow Logs för att verifiera att reglerna fungerar som avsett.

Säkerhetsgrupper är ditt första och mest detaljerade lager av nätverksförsvar i en VPC och verkar på instansnivå. De kompletterar nätverks-ACL:er som gäller för hela subnät och verktyg på applikationslagret, som WAF. Det är viktigt att behärska deras tillståndskänsliga beteende, att de endast tillåter trafik och att reglerna kombineras som en union inför SCS-C02-examen.

Säkerhetsgrupper är tillståndskänsliga virtuella brandväggar som endast tillåter trafik och som kopplas till resursens ENI. Nya grupper nekar all inkommande trafik och tillåter all utgående trafik. Regler anger protokoll, port och en källa som kan vara en CIDR eller ett annat grupp-ID. Flera grupper kombineras som en union utan nekanderegler eller inbördes ordning. Undvik öppna administrationsportar och använd Flow Logs för att observera trafiken, eftersom SG:er inte loggar.