Hva er sikkerhetgrupper og hvordan kontrollerer de tilgang?

Question

Accepted Answer

**Sikkerhetgrupper** er virtuelle brannmurer som kontrollerer **innkommende og utgående trafikk** til AWS-ressurser (som EC2-instanser) — og definerer hvilke porter, protokoller og kilder som er tillatt. De er grunnleggende for AWS-nettverkssikkerhet.

## Hva sikkerhetgrupper gjør

```text
A SECURITY GROUP is a virtual firewall attached to resources (EC2, RDS, etc.):
  → INBOUND rules — what traffic can REACH the resource (port, protocol, source)
  → OUTBOUND rules — what traffic the resource can SEND OUT
  → only ALLOW rules (no explicit deny); everything not allowed is DENIED by default
  → STATEFUL — if inbound is allowed, the response is automatically allowed back
```

## Eksempelregler

```text
Inbound rules for a web server:
  Allow TCP 443 (HTTPS) from 0.0.0.0/0   → anyone can reach HTTPS
  Allow TCP 80  (HTTP)  from 0.0.0.0/0   → anyone can reach HTTP
  Allow TCP 22  (SSH)   from <your IP>/32 → ONLY your IP can SSH (not the whole world!)
→ everything else is blocked (default deny)
```

## Et kraftig mønster: referanse til andre sikkerhetgrupper

```text
Rules can allow traffic from ANOTHER security group (not just IPs):
  → DB security group: allow port 5432 FROM the app-server security group
  → means: only the app servers (whatever their IPs) can reach the database
→ Tiered security: web SG → app SG → db SG (each layer only accepts from the previous)
```

## Sikkerhetgrupper vs NACLs

```text
SECURITY GROUPS → at the RESOURCE level; stateful; allow-only; the primary tool
NETWORK ACLs (NACLs) → at the SUBNET level; stateless; allow AND deny rules;
  a secondary, coarser layer
→ Use security groups as the main control; NACLs for subnet-wide rules.
```

## Hvorfor det er viktig

Å forstå sikkerhetgrupper er viktig fordi de er grunnleggende for **AWS-nettverkssikkerhet** — de kontrollerer hvilken trafikk som kan nå ressursene dine — så det er viktig praktisk kunnskap for sikker distribusjon av ressurser.

Sikkerhetgrupper fungerer som **virtuelle brannmurer** som definerer hvilken trafikk (porter, protokoller, kilder) som er tillatt til og fra ressurser, med en sikker-som-standard-modell (bare tillat-regler; alt som ikke eksplisitt er tillatt, nektes) og tilstandsfull atferd (svar på tillatt trafikk tillates automatisk).

Å forstå hvordan du konfigurerer regler riktig er essensielt for sikkerhet — for eksempel å tillate HTTP/HTTPS fra overalt for en webserver, men **begrense SSH-tilgang til spesifikke IP-adresser** (ikke hele internett — en vanlig og viktig praksis, siden å eksponere SSH for verden er en sikkerhetsrisiko).

Det **kraftige mønsteret med referanse til andre sikkerhetgrupper** (tillate databasens sikkerhetgruppe til å motta trafikk bare fra appservernes sikkerhetgruppe, uavhengig av deres IP-adresser) muliggjør rene **tiered sikkerhet-arkitekturer** (web → app → database, der hvert lag bare godtar trafikk fra det forrige) — en best-practice-tilnærming som begrenser eksponering og følger minste-privilegie på nettverksnivået.

Å forstå **sikkerhetgrupper vs NACLs** (sikkerhetgrupper på ressursnivå som det primære, tilstandsfulle, kun-tillat-verktøy; NACLs på subnettnivå som et grovere, tilstandsløst sekundært lag) klargjør den lagdelte nettverkssikkerhetsmodellen.

Siden å kontrollere nettverkstilgang til ressurser er grunnleggende for AWS-sikkerhet (feilkonfigurert tilgang — som for åpne porter eller verdenswidt tilgjengelig SSH/databaser — forårsaker virkelige sårbarheter), og siden sikkerhetgrupper er den primære mekanismen for dette (med sikkerhetsgrupperefererings-mønsteret som muliggjør sikre tiered-arkitekturer), er det essensielt å forstå sikkerhetgrupper, praktisk viktig AWS-kunnskap for sikker distribusjon av ressurser — et kjernesikerhetstema der riktig konfigurering (begrensning av tilgang på passende måte, bruk av tiered sikkerhetsgruppereferanser) direkte forhindrer nettverksnivå-eksoneringer som fører til brudd.