Ransomware? | AWS. | GCP. | Azure. | Hardening your Hyperscaler cloud.

Ist unsere Hyperscaler Cloud immun gegen Ransomware-Angriffe?
So schützt man Cloud-Infrastrukturen vor Ransomware und anderen Bedrohungen

Viele Unternehmen gehen davon aus, dass AWS, Google Cloud oder Microsoft Azure automatisch sicher sind. Das stimmt nur teilweise. Hyperscaler schützen die Cloud-Plattform selbst, aber Kunden bleiben weiterhin verantwortlich für Identitäten, Konfigurationen, Workloads, Daten, Backups und Wiederherstellungsprozesse. Genau das bedeutet Shared Responsibility in der Praxis.

Das realistischere Ransomware-Szenario ist in der Regel nicht ein direkter Angriff auf den Hyperscaler selbst, sondern auf die Kundenumgebung innerhalb der Cloud. Kompromittierte Admin-Accounts, exponierte Management-Zugänge, schwache IAM-Konzepte, Fehlkonfigurationen im Storage, angreifbare öffentliche Services und löschbare Backups sind die eigentlichen Risikozonen.
  • Identitäten und privilegierte Zugriffe härten: MFA erzwingen, dauerhafte Admin-Rechte reduzieren, getrennte Admin-Konten nutzen, Break-Glass-Konten schützen und Least Privilege konsequent umsetzen.
  • Backups unveränderbar machen: Geschützte, versionierte und getrennt gesicherte Backups verwenden. Recovery regelmäßig testen und sicherstellen, dass Angreifer Sicherungen nicht löschen oder überschreiben können.
  • Zentrale Detection und Logging aufbauen: Verdächtige Logins, Policy-Änderungen, Massenlöschungen, ungewöhnliche API-Aktivitäten, Snapshot-Manipulationen und Hinweise auf Datenabfluss zentral überwachen.
  • Angriffsfläche reduzieren: Öffentliche Management-Zugänge entfernen, VPNs und Edge-Systeme schnell patchen, Netzwerke segmentieren und laterale Bewegung begrenzen.
  • Guardrails technisch erzwingen: Sicherheitsvorgaben dürfen nicht nur dokumentiert sein. Organisationweite Policies für Logging, Verschlüsselung, öffentliche Exponierung, Backup-Schutz und Löschrestriktionen müssen aktiv durchgesetzt werden.
  • AWS-Maßnahmen: IAM Least Privilege umsetzen, Root-Account absichern, Organizations aktivieren, GuardDuty, Security Hub CSPM, CloudTrail, AWS Config, AWS Backup Vault Lock und S3 Object Lock nutzen.
  • GCP-Maßnahmen: IAM-Rollen minimieren, Service Accounts regelmäßig prüfen, Security Command Center, Cloud Logging, Cloud Monitoring, Cloud Armor, Retention Policies, Bucket Lock und getrennte Backup-Projekte einsetzen.
  • Azure-Maßnahmen: Entra ID und Azure RBAC härten, Defender for Cloud und Microsoft Sentinel aktivieren, Azure Policy durchsetzen sowie Immutable Vault, Immutable Blob Storage und Resource Locks für kritische Ressourcen nutzen.
  • Recovery regelmäßig testen: Restore-Übungen für Storage, Datenbanken, Kubernetes-Workloads, IAM-Abhängigkeiten und Management-Systeme durchführen, bevor ein echter Vorfall eintritt.

Most common cloud mistakes. | Learn. | Harden your config.

What are the most common Cloud Security Mistakes?
The ransomware weaknesses organizations still overlook

Most successful ransomware incidents in cloud environments do not start with a “broken hyperscaler.” They start with preventable customer-side mistakes: weak identity controls, overprivileged access, exposed admin paths, deletable backups, missing monitoring, and poor recovery preparation.

The real issue is usually not the lack of security features in AWS, GCP, or Azure. It is that organizations leave those controls partially configured, inconsistently enforced, or untested in production.
  • Relying on the hyperscaler alone: Teams assume AWS, Azure, or GCP automatically protect their tenant, workloads, identities, storage, and backups. They do not.
  • Weak IAM and excessive privileges: Missing MFA, too many admin roles, shared accounts, overprivileged service accounts, and poor separation of duties remain some of the biggest failure points.
  • Backups that can still be deleted or altered: Many teams have backups, but they are not immutable, not isolated, or not protected against the same compromised credentials.
  • Exposed management interfaces: Public admin portals, open SSH/RDP access, weak VPN hygiene, and insufficient segmentation make initial access much easier for attackers.
  • Poor visibility and incomplete logging: If policy changes, suspicious API calls, mass deletions, or unusual sign-ins are not centrally visible, ransomware activity is often detected too late.
  • Not enforcing cloud guardrails: Security controls exist, but they are optional. Without enforced policies, teams drift into insecure configurations over time.
  • AWS mistakes: Root account not tightly protected, broad IAM permissions, CloudTrail or Config not fully enabled, GuardDuty or Security Hub unused, and no S3 Object Lock or Backup Vault Lock.
  • GCP mistakes: Overuse of Owner roles, weak service account governance, Security Command Center not enabled, missing retention controls, no Bucket Lock, and insufficient project isolation.
  • Azure mistakes: Overprivileged Entra ID roles, weak Azure RBAC hygiene, Defender for Cloud not fully used, missing Azure Policy enforcement, and no immutable backup or resource lock strategy.
  • Never testing recovery: A backup that has never been restored under realistic conditions is an assumption, not a resilience strategy.

Was sind die häufigsten Cloud-Sicherheitsfehler?
Die typischen Schwachstellen hinter Ransomware-Vorfällen

Die meisten erfolgreichen Ransomware-Vorfälle in Cloud-Umgebungen beginnen nicht mit einem „unsicheren Hyperscaler“, sondern mit vermeidbaren Fehlern auf Kundenseite: schwache Identitätskontrollen, zu weitreichende Berechtigungen, exponierte Admin-Zugänge, löschbare Backups, fehlendes Monitoring und schlecht vorbereitete Recovery-Prozesse.

Das eigentliche Problem ist meist nicht der Mangel an Sicherheitsfunktionen in AWS, GCP oder Azure. Das Problem ist, dass diese Kontrollen nur teilweise konfiguriert, nicht verbindlich durchgesetzt oder nie realistisch getestet werden.
  • Zu stark auf den Hyperscaler vertrauen: Viele Teams gehen davon aus, dass AWS, Azure oder GCP ihren Tenant, ihre Workloads, Identitäten, Daten und Backups automatisch absichern. Das tun sie nicht.
  • Schwaches IAM und zu viele Berechtigungen: Fehlende MFA, zu viele Admin-Rollen, gemeinsam genutzte Konten, überprivilegierte Service Accounts und fehlende Aufgabentrennung gehören zu den größten Schwachstellen.
  • Backups, die trotzdem löschbar oder veränderbar sind: Viele Unternehmen haben Backups, aber sie sind nicht unveränderbar, nicht isoliert oder mit denselben kompromittierbaren Rechten erreichbar.
  • Exponierte Management-Zugänge: Öffentlich erreichbare Admin-Portale, offenes SSH/RDP, schwache VPN-Hygiene und unzureichende Segmentierung erleichtern den Initial Access erheblich.
  • Zu wenig Sichtbarkeit und unvollständiges Logging: Wenn Policy-Änderungen, verdächtige API-Calls, Massenlöschungen oder ungewöhnliche Anmeldungen nicht zentral sichtbar sind, wird Ransomware oft zu spät erkannt.
  • Guardrails nicht technisch erzwingen: Sicherheitskontrollen existieren zwar, sind aber optional. Ohne verbindliche Policies driften Umgebungen mit der Zeit in unsichere Konfigurationen.
  • Typische AWS-Fehler: Root-Account nicht streng abgesichert, zu breite IAM-Rechte, CloudTrail oder Config nicht vollständig aktiviert, GuardDuty oder Security Hub nicht genutzt sowie kein S3 Object Lock oder Backup Vault Lock.
  • Typische GCP-Fehler: Zu viele Owner-Rollen, schwache Service-Account-Governance, Security Command Center nicht aktiviert, fehlende Retention-Kontrollen, kein Bucket Lock und unzureichende Projekt-Isolation.
  • Typische Azure-Fehler: Zu weitreichende Entra-ID-Rollen, schwache Azure-RBAC-Hygiene, Defender for Cloud nicht konsequent genutzt, fehlende Azure-Policy-Durchsetzung und keine Strategie für immutable Backups oder Resource Locks.
  • Recovery nie realistisch testen: Ein Backup, das unter echten Bedingungen nie zurückgespielt wurde, ist keine belastbare Resilienzstrategie, sondern nur eine Annahme.
Created with