Cloud-Security für Startups -- So schützt du deine Daten in der Cloud

Fast jedes Startup nutzt die Cloud -- ob AWS, Google Cloud, Azure oder kleinere Anbieter wie Hetzner und Exoscale. Die Cloud bietet unglaubliche Flexibilität und Skalierbarkeit, aber auch neue Sicherheitsrisiken. Denn in der Cloud bist du für die Sicherheit mitverantwortlich -- und viele Startups unterschätzen das.

Nach unserem Beitrag zur sicheren Software-Entwicklung widmen wir uns jetzt der Infrastruktur. Denn der sicherste Code nützt nichts, wenn dein S3-Bucket öffentlich zugänglich ist.

Das Shared Responsibility Model

Das wichtigste Konzept in der Cloud-Security: Die Verantwortung wird geteilt.

Was der Cloud-Anbieter schützt

Physische Sicherheit der Rechenzentren
Hardware und Netzwerk-Infrastruktur
Hypervisor und Host-Betriebssystem
Verfügbarkeit der Cloud-Dienste

Wofür du verantwortlich bist

Konfiguration der Cloud-Dienste
Zugriffsverwaltung (IAM)
Daten-Verschlüsselung
Netzwerk-Konfiguration (Security Groups, VPCs)
Betriebssystem-Patches (bei IaaS)
Anwendungs-Sicherheit
Logging und Monitoring

Kurz gesagt: Der Anbieter schützt die Cloud. Du schützt, was IN der Cloud läuft.

Die häufigsten Cloud-Security-Fehler

1. Öffentlich zugängliche Storage-Buckets

Der Klassiker. Unzählige Datenlecks entstehen durch falsch konfigurierte S3-Buckets, Google Cloud Storage oder Azure Blob Storage.

Wie es passiert:

// FALSCH -- Bucket oeffentlich
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::mein-bucket/*"
}

Wie es richtig geht:

Alle Buckets standardmässig privat
Block Public Access auf Account-Ebene aktivieren (AWS)
Zugriffsrechte explizit und minimal vergeben
Regelmässig auf öffentliche Buckets prüfen

2. Überprivilegierte IAM-Rollen

"Admin-Zugriff für alle, damit es schnell geht" -- der sichere Weg in die Katastrophe.

3. Fehlende Verschlüsselung

Daten in der Cloud müssen verschlüsselt sein -- sowohl bei der Übertragung als auch bei der Speicherung.

4. Keine Multi-Faktor-Authentifizierung

Besonders für den Root-Account bzw. den Organisations-Admin ist MFA absolut unverzichtbar. Lies dazu auch unseren Authentifizierung-Beitrag.

5. Verwaiste Ressourcen

Alte Test-Server, vergessene Datenbanken, nicht mehr genutzte API-Keys -- alles potenzielle Eintrittspunkte für Angreifer.

Identity and Access Management (IAM) richtig umsetzen

IAM ist das Herzstuck der Cloud-Security. Hier entscheidest du, wer was darf.

Grundprinzipien

Least Privilege -- Minimale Berechtigung: Jeder Nutzer und jeder Service bekommt nur die Rechte, die er tatsächlich braucht. Nicht mehr.

Keine Root-/Admin-Accounts für den Alltag:

# AWS: Root-Account nur fuer Account-Management nutzen
# Fuer den Alltag eigene IAM-User mit eingeschraenkten Rechten erstellen

Rollen statt User für Services:

// AWS IAM Role fuer einen Lambda-Service
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:eu-central-1:*:table/meine-tabelle"
    }
  ]
}

IAM Best Practices

Massnahme	Priorität
MFA für alle Nutzer	Kritisch
Root-Account sichern und nicht nutzen	Kritisch
Least Privilege durchsetzen	Hoch
Regelmässiger Access Review	Hoch
Service Accounts mit Rollen statt Keys	Hoch
Temporäre Credentials (STS) nutzen	Mittel
IAM Policies versionieren (Git)	Mittel
Cross-Account-Zugriffe minimieren	Mittel

Gruppen statt individuelle Berechtigungen

Erstelle Gruppen für typische Rollen in deinem Startup:

Entwickler: Zugriff auf Staging-Umgebungen, Code-Repositories, Logs
DevOps: Zugriff auf Produktion, aber nur mit definierten Aktionen
Gründer/Admin: Erweiterter Zugriff, aber nicht Root
Buchhaltung: Nur Billing-Zugriff
Externe Partner: Stark eingeschränkter, zeitlich begrenzter Zugriff

Netzwerk-Sicherheit in der Cloud

Virtual Private Cloud (VPC)

Deine Cloud-Ressourcen gehören in ein privates Netzwerk:

VPC (10.0.0.0/16)
├── Public Subnet (10.0.1.0/24)
│   └── Load Balancer, NAT Gateway
├── Private Subnet (10.0.2.0/24)
│   └── Application Server
└── Isolated Subnet (10.0.3.0/24)
    └── Datenbank

Public Subnets: Nur für Komponenten, die direkt aus dem Internet erreichbar sein müssen
Private Subnets: Für Application Server -- Zugriff nur über Load Balancer
Isolated Subnets: Für Datenbanken -- kein direkter Internet-Zugang

Security Groups und Firewalls

// Security Group fuer Web-Server
{
  "Inbound": [
    {"Port": 443, "Source": "0.0.0.0/0", "Description": "HTTPS"},
    {"Port": 80, "Source": "0.0.0.0/0", "Description": "HTTP (Redirect)"}
  ],
  "Outbound": [
    {"Port": 443, "Source": "0.0.0.0/0", "Description": "HTTPS ausgehend"},
    {"Port": 5432, "Source": "10.0.3.0/24", "Description": "PostgreSQL"}
  ]
}

Regeln:

Nur die absolut notwendigen Ports öffnen
Eingehenden Verkehr maximal einschränken
Kein SSH (Port 22) aus dem Internet -- nutze AWS Systems Manager, Google IAP oder ein VPN
Security Groups regelmässig aufräumen

VPN und Zero Trust

Für den Zugriff auf Cloud-Ressourcen:

WireGuard: Schnelles, modernes VPN (Open Source)
Tailscale: WireGuard-basiert, einfach einzurichten
AWS Client VPN / Google Cloud VPN: Native Lösungen
Zero Trust: BeyondCorp-Ansatz -- jeder Zugriff wird verifiziert, egal ob intern oder extern

Datenverschlüsselung in der Cloud

Verschlüsselung at Rest

Alle Daten, die in der Cloud gespeichert sind, müssen verschlüsselt sein:

AWS: S3 Server-Side Encryption (SSE-S3 oder SSE-KMS), EBS-Verschlüsselung
Google Cloud: Standardmässig verschlüsselt, CMEK für eigene Schlüssel
Azure: Azure Storage Service Encryption, Azure Disk Encryption

Verschlüsselung in Transit

TLS 1.2+ für alle Verbindungen (siehe HTTPS-Beitrag)
VPN für interne Kommunikation
Service Mesh (z.B. Istio) für mTLS zwischen Microservices

Key Management

Nutze den Key Management Service deines Cloud-Anbieters (AWS KMS, Google Cloud KMS, Azure Key Vault)
Rotiere Schlüssel regelmässig (automatisiert)
Definiere, wer Schlüssel erstellen, nutzen und löschen darf
Aktiviere Key-Logging (wer hat wann welchen Schlüssel genutzt?)

Logging und Monitoring

Ohne Monitoring bist du blind. Du erkennst Angriffe nicht und kannst nicht reagieren.

Was du loggen solltest

API-Aufrufe: AWS CloudTrail, Google Cloud Audit Logs, Azure Activity Log
Netzwerk-Verkehr: VPC Flow Logs
Zugriffe auf Daten: S3 Access Logs, Database Audit Logs
Authentifizierung: Login-Versuche, MFA-Events
Konfigurationsänderungen: AWS Config, Google Cloud Asset Inventory

Alerting einrichten

Definiere Alerts für kritische Events:

Root-Account Login
IAM-Policy-Änderungen
Security-Group-Änderungen
Ungewöhnliche API-Aufrufe
Fehlgeschlagene Login-Versuche (über Schwellenwert)
Neue Regionen oder Dienste aktiviert

Tools für Cloud-Monitoring

Tool	Typ	Kosten
AWS CloudWatch	Native Monitoring	Pay-per-Use
Google Cloud Monitoring	Native Monitoring	Free Tier
Grafana	Dashboards	Open Source
Prometheus	Metriken	Open Source
Datadog	Full-Stack Monitoring	Ab 15 EUR/Host/Monat

Für ein Startup empfehle ich den Start mit den nativen Tools deines Cloud-Anbieters. Die sind im Free Tier oft ausreichend.

Cloud-Security für verschiedene Anbieter

AWS Security Checkliste

MFA für Root-Account aktivieren (Hardware-Key empfohlen)
AWS Organizations mit Service Control Policies einrichten
CloudTrail in allen Regionen aktivieren
GuardDuty aktivieren (Bedrohungserkennung)
S3 Block Public Access auf Account-Ebene aktivieren
VPC mit privaten Subnets für alle Services
AWS Config für Compliance-Monitoring
IAM Access Analyzer nutzen
Security Hub aktivieren
Billing Alerts einrichten (Anomalie-Erkennung)

Google Cloud Security Checkliste

Organisation erstellen und Folder-Struktur aufsetzen
Cloud Identity für zentrales Nutzermanagement
Audit Logs aktivieren
VPC Service Controls für Datenexfiltrations-Schutz
Security Command Center aktivieren
Cloud Armor für DDoS-Schutz
Identity-Aware Proxy für internen Zugriff
Binary Authorization für Container
Billing Budgets und Alerts konfigurieren
Asset Inventory regelmässig prüfen

Hetzner Cloud / Exoscale (EU-Alternativen)

Für österreichische Startups, die bei europäischen Anbietern bleiben wollen:

Hetzner Cloud: Günstig, Rechenzentren in Deutschland und Finnland
Exoscale: Schweizer Anbieter, DSGVO-konform, Rechenzentren in Wien
IONOS: Deutsches Unternehmen, Cloud-Lösungen für KMUs

Auch bei diesen Anbietern gelten die gleichen Grundprinzipien: IAM, VPC, Verschlüsselung, Monitoring.

Compliance und Datenschutz in der Cloud

DSGVO-konform in der Cloud

Standortwahl: Nutze EU-Rechenzentren (AWS eu-central-1 Frankfurt, Google europe-west3 Frankfurt)
Auftragsverarbeitung: Vertrag zur Auftragsverarbeitung (AVV) mit dem Cloud-Anbieter abschliessen
Datentransfer: Kein unkontrollierter Transfer in Drittländer
Verschlüsselung: Pflicht für personenbezogene Daten
Löschkonzept: Wie löschst du Daten in der Cloud? Auch in Backups (siehe Backup-Strategien)

Welche Region wählen?

Für österreichische Startups empfehle ich:

AWS: eu-central-1 (Frankfurt) oder eu-west-1 (Irland)
Google Cloud: europe-west3 (Frankfurt) oder europe-west1 (Belgien)
Azure: westeurope (Niederlande) oder germanywestcentral (Frankfurt)
Hetzner: Nürnberg oder Falkenstein

Infrastructure as Code (IaC) -- Sicherheit durch Reproduzierbarkeit

Deine Cloud-Infrastruktur gehört in Code, nicht in manuelle Klick-Abenteuer:

Terraform Beispiel

# Sicherer S3 Bucket
resource "aws_s3_bucket" "daten" {
  bucket = "mein-startup-daten"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "daten" {
  bucket = aws_s3_bucket.daten.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "daten" {
  bucket = aws_s3_bucket.daten.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "daten" {
  bucket = aws_s3_bucket.daten.id
  versioning_configuration {
    status = "Enabled"
  }
}

IaC-Security-Scanning

Prüfe deine IaC-Konfigurationen auf Sicherheitsprobleme:

Checkov: Open Source, unterstützt Terraform, CloudFormation, Kubernetes
tfsec: Spezialisiert auf Terraform
Terrascan: Multi-Cloud IaC Scanner

# Checkov ausfuehren
checkov -d /pfad/zu/terraform/

# tfsec ausfuehren
tfsec /pfad/zu/terraform/

Kosten-Sicherheits-Balance

Cloud-Security muss nicht teuer sein. Hier eine Priorisierung für Startups:

Kostenlos / Im Free Tier

IAM richtig konfigurieren
MFA aktivieren
S3 Block Public Access
VPC einrichten
CloudTrail / Audit Logs (begrenzt)
Checkov / tfsec für IaC-Scanning

Günstig (unter 50 EUR/Monat)

AWS GuardDuty: ca. 10-30 EUR/Monat für kleine Umgebungen
VPC Flow Logs: abhängig vom Traffic
AWS Config: ca. 2-5 EUR/Monat
Tailscale VPN: kostenlos für bis zu 3 Nutzer

Investition (50-200 EUR/Monat)

Dediziertes Monitoring (Datadog, etc.)
Security Hub / Security Command Center
WAF (Web Application Firewall)
DDoS-Schutz (AWS Shield Advanced -- allerdings deutlich teurer)

Multi-Cloud und Vendor Lock-in

Einige Startups nutzen mehrere Cloud-Anbieter. Das bringt Flexibilität, aber auch Komplexität:

Vorteil: Kein Single Point of Failure, keine Abhängigkeit
Nachteil: Komplexere Sicherheitskonfiguration, mehr Angriffsoberfläche
Empfehlung für Startups: Starte mit einem Anbieter, sichere ihn richtig ab. Multi-Cloud ist später immer noch möglich.

Checkliste: Cloud-Security

Fazit

Cloud-Security ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Die gute Nachricht: Die wichtigsten Massnahmen sind kostenlos oder günstig. IAM richtig konfigurieren, MFA aktivieren, Buckets privat halten, Logs aktivieren -- damit hast du schon 80% der Cloud-Security-Probleme gelöst.

Nimm dir einen Nachmittag Zeit und geh die Checkliste oben durch. Dein Cloud-Account wird es dir danken.

Im nächsten Beitrag geht es um ein Thema, das hoffentlich nie akut wird, aber vorbereitet sein muss: Incident Response Plan erstellen.

Dieser Beitrag ist Teil der Serie "Cybersecurity für Startups" auf dem Startup Burgenland Blog. Du baust gerade dein Startup auf und brauchst Unterstützung? Startup Burgenland bietet dir Beratung, Förderungen und ein starkes Netzwerk -- von der Idee bis zum Markteintritt. Melde dich bei uns und werde Teil der wachsenden Startup-Community im Burgenland!

Dies ist Beitrag 7 von 10 der Serie "Cybersecurity für Startups" in der Kategorie Produkt und Technologie.

Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.

Cloud-Security für Startups -- So schützt du deine Daten in der Cloud

Cloud-Security für Startups -- So schützt du deine Daten in der Cloud

Das Shared Responsibility Model

Was der Cloud-Anbieter schützt

Wofür du verantwortlich bist

Die häufigsten Cloud-Security-Fehler

1. Öffentlich zugängliche Storage-Buckets

2. Überprivilegierte IAM-Rollen

3. Fehlende Verschlüsselung

4. Keine Multi-Faktor-Authentifizierung

5. Verwaiste Ressourcen

Identity and Access Management (IAM) richtig umsetzen

Grundprinzipien

IAM Best Practices

Gruppen statt individuelle Berechtigungen

Netzwerk-Sicherheit in der Cloud

Virtual Private Cloud (VPC)

Security Groups und Firewalls

VPN und Zero Trust

Datenverschlüsselung in der Cloud

Verschlüsselung at Rest

Verschlüsselung in Transit

Key Management

Logging und Monitoring

Was du loggen solltest

Alerting einrichten

Tools für Cloud-Monitoring

Cloud-Security für verschiedene Anbieter

AWS Security Checkliste

Google Cloud Security Checkliste

Hetzner Cloud / Exoscale (EU-Alternativen)

Compliance und Datenschutz in der Cloud

DSGVO-konform in der Cloud

Welche Region wählen?

Infrastructure as Code (IaC) -- Sicherheit durch Reproduzierbarkeit

Terraform Beispiel

IaC-Security-Scanning

Kosten-Sicherheits-Balance

Kostenlos / Im Free Tier

Günstig (unter 50 EUR/Monat)

Investition (50-200 EUR/Monat)

Multi-Cloud und Vendor Lock-in

Checkliste: Cloud-Security

Fazit

Erstgespräch vereinbaren