Säkerhetsgrupper och nyckelpar

Security groups stöder referenser till security groups som källa eller mål, vilket är mer flexibelt och säkert än att ange IP-intervall. Till exempel tillåter en ALB:s security group 0.0.0.0/0 på port 443. EC2-instansernas security group tillåter inkommande trafik på port 8080 endast från ALB:ns security group-ID—inte från någon IP-adress. Om en ALB ersätts eller skalas gäller regeln fortfarande korrekt utan att IP-adresser behöver ändras. Detta mönster skapar ett lagerindelat och dynamiskt skydd för arkitekturer med flera lager.

Tillståndsbevarande innebär att security group spårar anslutningstillståndet. Om Er inkommande regel tillåter TCP-port 80 från internet och en klient skickar en begäran, tillåts svarspaketen (utgående) automatiskt tillbaka till klienten—även om det inte finns någon utgående regel för port 80. Detta skiljer sig grundläggande från Network ACLs, som är tillståndslösa och kräver uttryckliga regler för trafik i båda riktningarna. Tillståndsbevarande funktionalitet gör security groups enklare att konfigurera för typiska trafikmönster i applikationer.

Ni kan koppla flera security groups till en enda EC2-instans (upp till 5 som standard, vilket kan justeras). Reglerna från alla anslutna security groups kombineras med union (OR-logik)—om någon security group tillåter en begäran tillåts begäran. Detta innebär att security groups bara kan lägga till behörigheter, aldrig begränsa dem—om Ni vill begränsa åtkomsten måste Ni ta bort eller ändra regler, inte lägga till en mer restriktiv security group. Tänk på detta additiva beteende vid provfrågor om åtkomstbegränsning.

Varje VPC innehåller en default security group. Dess standardregler är: inkommande trafik tillåts från andra instanser som också ingår i default security group, och utgående trafik tillåts till alla destinationer. Detta är avsiktligt tillåtande så att nya instanser kan kommunicera som standard. I produktionsmiljöer bör Ni skapa en anpassad security group med en strikt uppsättning inkommande regler och ta bort instansernas kopplingar till default security group för att undvika oavsiktlig exponering.

EC2-key pairs använder asymmetrisk kryptografi för SSH-autentisering. AWS genererar nyckelparet (eller så importerar Ni Er egen publika nyckel): AWS lagrar den publika nyckeln och lägger in den i instansen vid starten; Ni laddar ned och lagrar den privata nyckeln (.pem-fil)—AWS lagrar den aldrig. SSH använder den privata nyckeln för att bevisa Er identitet för servern utan att överföra ett lösenord. Den privata nyckeln måste ha begränsade behörigheter (chmod 400), annars vägrar SSH att använda den.

Om Ni förlorar den privata nyckeln till en Linux-EC2-instans kan Ni inte logga in via SSH på vanligt sätt. Återställningsalternativ omfattar: Systems Manager Session Manager (om SSM-agenten körs och en IAM-roll är kopplad—ingen nyckel behövs), EC2 Instance Connect (lägger in en tillfällig nyckel via webbläsare eller CLI—kräver en öppen SSH-port och EIC-behörigheter), eller stoppa instansen, koppla från rotvolymen i EBS, ansluta den till en annan instans, ändra filen authorized_keys, ansluta den igen och starta om. För Windows använder Ni Systems Manager för att hämta lösenordet.

Om SSH (port 22) lämnas öppet för 0.0.0.0/0 utsätts Er instans för brute force- och så kallade credential stuffing-attacker från hela internet. Bästa praxis är att begränsa SSH till Ert specifika företags-IP-intervall eller använda en bastion host (jump box) i ett publikt subnät med en strikt kontrollerad security group och därefter använda SSH från bastionvärden till privata instanser. Ännu bättre är att använda Systems Manager Session Manager för att helt eliminera exponering av SSH-porten—inga inkommande regler behövs alls.

Viktiga standardbegränsningar för security groups (justerbara via Service Quotas) är: upp till 2 500 security groups per VPC, 60 inkommande och 60 utgående regler per security group samt 5 security groups per nätverksgränssnitt. När Ni refererar till en annan security group som källa räknas varje kombination av refererad security group och regel som en regel. Om Ni når regelgränserna kan Ni konsolidera genom att referera till security group-ID:n i stället för enskilda IP-intervall, eller använda prefix lists för att gruppera flera CIDR-intervall i en enda hanterbar enhet.

En managed prefix list är en uppsättning CIDR-block som Ni kan referera till i regler för security groups eller routningstabeller. AWS underhåller AWS-managed prefix lists för tjänster som S3 och CloudFront, så att Ni kan tillåta trafik till och från dessa tjänster utan att själva underhålla IP-intervall (som ändras över tid). Ni kan även skapa customer-managed prefix lists för att gruppera företagets IP-intervall—uppdatera prefix list på ett ställe så ärver alla security groups som refererar till den ändringen automatiskt.

I den här lektionen har Ni lärt Er att: security groups är tillståndsbevarande virtuella brandväggar som som standard nekar inkommande trafik, det är säkrare och mer flexibelt att kedja security groups med ID än att använda IP-intervall, samt att key pairs tillhandahåller asymmetrisk SSH-autentisering medan Systems Manager Session Manager eliminerar behovet av öppna SSH-portar. Nästa avsnitt handlar om lagringsalternativ för EC2: Instance Store jämfört med EBS.