Security Hardening – Best Practices für STACKIT

26. März 2026 #security

security hardening compliance

Security Hardening – Best Practices für STACKIT

Cloud-Infrastruktur ist nur so sicher wie ihre Konfiguration. Fehlkonfigurationen sind die häufigste Ursache für Sicherheitsvorfälle. Dieser Artikel gibt dir eine praxisnahe Checkliste und konkrete Maßnahmen, um deine STACKIT-Umgebung abzusichern.

Was ist Security Hardening?

Security Hardening bezeichnet das systematische Reduzieren der Angriffsfläche deiner Infrastruktur:

Minimalprinzip – Nur das installieren und aktivieren, was wirklich benötigt wird
Least Privilege – Jeder Benutzer und Service bekommt nur die minimal nötigen Rechte
Defense in Depth – Mehrere Sicherheitsschichten statt einer einzelnen Maßnahme
CIS Benchmarks – Branchenstandards für sichere Konfiguration von Betriebssystemen und Cloud-Diensten
Compliance – Einhaltung von DSGVO, ISO 27001 und BSI-Grundschutz

:::warning Sicherheit ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Plane regelmäßige Reviews ein. :::

Tutorial: STACKIT-Umgebung härten

1. IAM und Zugriffskontrolle

# Service Account mit minimalen Rechten erstellen
stackit iam service-account create \
  --name deploy-bot \
  --project-id your-project-id \
  --description "CI/CD Deployment – nur Compute-Zugriff"

# Rolle zuweisen (nur was nötig ist)
stackit iam role add \
  --service-account-id your-sa-id \
  --project-id your-project-id \
  --role compute.instanceAdmin

Checkliste IAM:

Keine Verwendung von Root-/Owner-Accounts im Alltag
MFA für alle Benutzer aktiviert
Service Accounts statt persönlicher Credentials für Automatisierung
Regelmäßige Überprüfung ungenutzter Accounts und Berechtigungen

2. Netzwerk absichern

# Security Group: Nur HTTPS und SSH von bekannten IPs
stackit security-group rule create \
  --security-group-id your-sg-id \
  --project-id your-project-id \
  --direction ingress \
  --protocol tcp \
  --port-range "443" \
  --remote-ip "203.0.113.0/24"

Checkliste Netzwerk:

Kein SSH-Zugang aus dem Internet (0.0.0.0/0)
Security Groups nach Whitelist-Prinzip konfiguriert
Getrennte Netzwerke für Produktion, Staging und Entwicklung
Kein öffentlicher Zugriff auf Datenbanken

3. Server härten (CIS Benchmark)

# Unnötige Dienste deaktivieren
sudo systemctl disable --now cups avahi-daemon bluetooth

# Automatische Sicherheitsupdates aktivieren (Ubuntu/Debian)
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# SSH härten
sudo tee /etc/ssh/sshd_config.d/hardening.conf << 'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
EOF
sudo systemctl restart sshd

4. Verschlüsselung sicherstellen

Bereich	Maßnahme
Daten at Rest	Volume-Verschlüsselung aktivieren
Daten in Transit	TLS 1.2+ erzwingen
Secrets	KMS oder Secrets Manager nutzen
Backups	Verschlüsselte Backups konfigurieren

5. Logging und Monitoring

# Zentrale Log-Konfiguration
logging:
  destinations:
    - type: opensearch
      endpoint: "https://your-opensearch-host:9200"
      index: "security-logs"
  alerts:
    - name: failed_login_spike
      condition: "count(failed_login) > 10 in 5m"
      notify: ["ops-team@example.com"]

6. Compliance-Check automatisieren

# CIS Benchmark mit Lynis prüfen
sudo apt install lynis
sudo lynis audit system
sudo cat /var/log/lynis-report.dat | grep warning

:::danger Dokumentiere alle Abweichungen von CIS Benchmarks und begründe sie. Auditoren erwarten nachvollziehbare Entscheidungen. :::

Nächste Schritte

Führe einen initialen Security-Audit mit Lynis oder OpenSCAP durch
Erstelle eine Hardening-Baseline als Infrastructure-as-Code (Terraform/Ansible)
Plane vierteljährliche Security-Reviews und Penetrationstests
Implementiere ein Incident-Response-Playbook für Sicherheitsvorfälle