Sikkerhetsgrupper og nøkkelpar

Security groups støtter referanser til security groups som kilde eller destinasjon, noe som er mer fleksibelt og sikkert enn å angi IP-områder. En security group for en ALB kan for eksempel tillate 0.0.0.0/0 på port 443. Security group-en til EC2-instansene tillater innkommende trafikk på port 8080 bare fra ID-en til ALB-ens security group – ikke fra en IP-adresse. Hvis en ALB erstattes eller skaleres, gjelder regelen fortsatt korrekt uten endringer i IP-adresser. Dette mønsteret gir et lagdelt og dynamisk forsvar for arkitekturer med flere lag.

Stateful betyr at security group-en sporer tilkoblingstilstanden. Hvis den innkommende regelen tillater TCP-port 80 fra internett og en klient sender en forespørsel, tillates svarpakkene (utgående) automatisk tilbake til klienten – selv om det ikke finnes noen utgående regel for port 80. Dette er grunnleggende forskjellig fra Network ACLs, som er stateless og krever uttrykkelige regler for begge trafikkretninger. Stateful-funksjonen gjør security groups enklere å konfigurere for vanlige trafikkmønstre i applikasjoner.

De kan knytte flere security groups til én EC2-instans (opptil 5 som standard, og dette kan justeres). Reglene fra alle tilknyttede security groups kombineres ved hjelp av en union (OR-logikk) – hvis én security group tillater en forespørsel, tillates forespørselen. Dette betyr at security groups bare kan legge til tillatelser, aldri begrense dem. Hvis De vil stramme inn tilgangen, må De fjerne eller endre regler, ikke legge til en mer restriktiv security group. Husk denne additive virkemåten i eksamensoppgaver om begrensning av tilgang.

Hver VPC inkluderer en default security group. Standardreglene er: Innkommende trafikk tillates fra andre instanser som også er i standard-security group-en, og utgående trafikk tillates til alle destinasjoner. Dette er med hensikt tillatende, slik at nye instanser kan kommunisere som standard. I produksjonsmiljøer bør De opprette en egendefinert security group med et strengt begrenset sett av innkommende regler og fjerne instanstilknytninger til standard-security group-en for å unngå utilsiktet eksponering.

EC2-key pairs bruker asymmetrisk kryptografi for SSH-autentisering. AWS genererer nøkkelparet (eller De importerer Deres egen offentlige nøkkel): AWS lagrer den offentlige nøkkelen og setter den inn i instansen ved oppstart; De laster ned og lagrer den private nøkkelen (.pem-fil) – AWS lagrer den aldri. SSH bruker den private nøkkelen til å bekrefte identiteten Deres overfor serveren uten å overføre et passord. Den private nøkkelen må ha begrensede tillatelser (chmod 400), ellers nekter SSH å bruke den.

Hvis De mister den private nøkkelen til en Linux-EC2-instans, kan De ikke logge inn via SSH på vanlig måte. Gjenopprettingsalternativer omfatter: Systems Manager Session Manager (hvis SSM-agenten kjører og en IAM-rolle er tilknyttet – ingen nøkkel kreves), EC2 Instance Connect (setter inn en midlertidig nøkkel via nettleser eller CLI – krever en åpen SSH-port og EIC-tillatelser), eller stopp instansen, koble fra rot-EBS-volumet, koble det til en annen instans, endre filen authorized_keys, koble det til igjen og start instansen på nytt. For Windows bruker De Systems Manager til å hente passordet.

Hvis SSH (port 22) står åpen for 0.0.0.0/0, utsettes instansen for brute-force-angrep og angrep med gjenbruk av stjålne påloggingsopplysninger fra hvor som helst på internett. Beste praksis er å begrense SSH til Deres spesifikke bedrifts-IP-område eller bruke en bastion host (jump box) i et offentlig subnett med en strengt kontrollert security group, og deretter bruke SSH fra bastion-verten til private instanser. Enda bedre er det å bruke Systems Manager Session Manager for å fjerne eksponeringen av SSH-porten fullstendig – da trengs ingen innkommende regler.

Viktige standardgrenser for security groups (kan justeres via Service Quotas): opptil 2 500 security groups per VPC, 60 innkommende og 60 utgående regler per security group og 5 security groups per nettverksgrensesnitt. Når De refererer til en annen security group som kilde, teller hver kombinasjon av referert security group og regel som én regel. Hvis De når regelgrensene, kan De konsolidere ved å referere til security group-ID-er i stedet for individuelle IP-områder, eller bruke prefix lists til å samle flere CIDR-er i én håndterbar enhet.

En managed prefix list er et sett med CIDR-blokker som De kan referere til i regler for security groups eller rutetabeller. AWS vedlikeholder AWS-managed prefix lists for tjenester som S3 og CloudFront, slik at De kan tillate trafikk til og fra disse tjenestene uten å vedlikeholde IP-områder selv (IP-områdene endres over tid). De kan også opprette customer-managed prefix lists for å samle bedriftens IP-områder – oppdater prefix list-en på ett sted, så arver alle security groups som refererer til den endringen automatisk.

I denne leksjonen lærte De at security groups er stateful virtuelle brannmurer som som standard avviser innkommende trafikk, at kjeding av security groups etter ID er sikrere og mer fleksibelt enn bruk av IP-områder, og at key pairs gir asymmetrisk SSH-autentisering, mens Systems Manager Session Manager fjerner behovet for åpne SSH-porter. Neste tema er lagringsalternativer for EC2: Instance Store sammenlignet med EBS.