Hvad er sikkerhedsgrupper, og hvordan styrer de adgangen?

Question

Accepted Answer

**Sikkerhedsgrupper** er virtuelle firewalls, der styrer **indgående og udgående trafik** til AWS-ressourcer (såsom EC2-instanser) — definerer hvilke porte, protokoller og kilder, der er tilladt. De er fundamentale for AWS-netsikkerhed.

## Hvad sikkerhedsgrupper gø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
```

## Eksempler på regler

```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 kraftfuldt mønster: referencer til andre sikkerhedsgrupper

```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)
```

## Sikkerhedsgrupper 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 betyder noget

Forståelse af sikkerhedsgrupper er vigtig, fordi de er fundamentale for **AWS-netsikkerhed** — styrer hvilken trafik der kan nå dine ressourcer — så det er vigtig praktisk viden for sikker implementering af ressourcer.

Sikkerhedsgrupper fungerer som **virtuelle firewalls**, der definerer hvilken trafik (porte, protokoller, kilder), der er tilladt til og fra ressourcer, med en sikker-som-standard-model (kun tilladelsesregler; alt ikke eksplicit tilladet er forbudt) og tilstandsbeholdende adfærd (svar på tilladt trafik tillades automatisk).

Forståelse af, hvordan man konfigurerer regler korrekt, er vigtig for sikkerhed — for eksempel at tillade HTTP/HTTPS fra overalt for en webserver, men **begrænse SSH-adgang til specifikke IP-adresser** (ikke hele internettet — en vigtig, almindelig praksis, da eksponering af SSH til verden er en sikkerhedsrisiko).

Det **kraftfulde mønster med referencer til andre sikkerhedsgrupper** (tillader databasens sikkerhedsgruppe at acceptere trafik kun fra app-servernes sikkerhedsgruppe, uanset deres IP-adresser) muliggør rene **tiered sikkerhedsarkitekturer** (web → app → database, hvor hvert lag kun accepterer trafik fra det foregående) — en best-practice-tilgang, der begrænser eksponering og følger least privilege på netniveau.

Forståelse af **sikkerhedsgrupper vs NACLs** (sikkerhedsgrupper på ressourceniveau som det primære, tilstandsbeholdende, tilladels-kun-værktøj; NACLs på subnetniveau som et grovere, tilstandsløst sekundært lag) præciserer den lagdelte netværkssikkerhedsmodel.

Da styring af netværksadgang til ressourcer er fundamental for AWS-sikkerhed (dårligt konfigureret adgang — som alt for åbne porte eller verden-tilgængelig SSH/databaser — forårsager reelle sårbarheder), og da sikkerhedsgrupper er den primære mekanisme for dette (med sikkerhedsgruppe-referencer-mønsteret, der muliggør sikre tiered arkitekturer), er forståelse af sikkerhedsgrupper vigtig, praktisk-vigtig AWS-viden for sikker implementering af ressourcer — et kernesikerhedsemne, hvor korrekt konfiguration (passende begrænsning af adgang, brug af tiered sikkerhedsgruppe-referencer) direkte forhindrer de netværksniveau-eksponeringer, der fører til brud.