Vom SysAdmin zum Cloud Security Engineer: ein Infrastructure First Pfad

Warum Sysadmins starke Cloud Security Engineers sind

Systemadministratoren haben jahrelang genau das mentale Modell aufgebaut, das Cloud Security Arbeit verlangt: wie Systeme miteinander verbunden sind, wie Zugriff gewährt und entzogen wird, wo die Versagensmodi liegen und wie man unter Veränderung operiert. Der Übergang heißt nicht, diese Intuition neu aufzubauen. Er heißt, sie von Racks und Active Directory Forests auf AWS Accounts und IAM Rollen umzuleiten.

Der Wechsel ist real, aber begrenzt. Cloud verändert die Tools, die Geschwindigkeit und die Versagens Oberflächen. Sie verändert nicht, wie gute Infrastruktur Sicherheit aussieht. Hiring Manager wissen das, weshalb Sysadmins stark um die Rollen konkurrieren, die auf der Cloud Security Engineer Karriereseite und der breiteren Security Engineer Karriereseite beschrieben sind.

Warum Sysadmin Disziplin direkt in Cloud Security übergeht

Cloud Security ist keine grundsätzlich neue Disziplin. Sie ist Infrastruktur Sicherheit mit einem anderen Betriebsmodell. Die Disziplinen, die du als Sysadmin bereits praktizierst, projizieren sich eng auf das, was Cloud Security Teams tatsächlich tagtäglich tun.

Patch Kadenz wird zu Vulnerability Management für AMIs, Container Base Images und Versionen managed Services. Backup und Recovery Arbeit wird zu Resilience Engineering und validierter Wiederherstellung gegen Ransomware Szenarien. Benutzerkonten Hygiene wird zu IAM Lifecycle und Break-Glass Account Governance. Netzwerksegmentierung zwischen On-Premises VLANs wird zu VPC Design mit privaten Subnetzen, Security Groups und Transit Gateway Routing.

Die Day-Two Arbeit, in der Sysadmins gut sind, Logs beobachten, Veränderung validieren, die Linie des Least Privilege halten, ist genau die Arbeit, die einen nützlichen Cloud Security Engineer von jemandem unterscheidet, der nur eine Prüfung bestehen kann. Cloud Plattformen machen Automatisierung leichter und schneller, aber die zugrunde liegende Disziplin ist dieselbe, die On-Premises Umgebungen im letzten Jahrzehnt stabil gehalten hat.

Deshalb schätzen Hiring Manager Sysadmins für Cloud Security Rollen. Quereinsteiger aus reinem Development haben oft kein operatives Bauchgefühl, und reine Security Analysten haben oft keine praktische Infrastruktur Erfahrung. Sysadmins kommen mit beidem.

Das Cloud Mental Model, das du brauchst (Shared Responsibility, Identity-First, Everything-as-Code)

Drei mentale Verschiebungen trennen Sysadmins, die Cloud Security Rollen landen, von denen, die stecken bleiben.

Die erste ist Shared Responsibility. Der Cloud Anbieter ist für die Sicherheit der Plattform verantwortlich. Du bist für die Sicherheit in der Plattform verantwortlich. Das klingt offensichtlich, aber die meisten Cloud Vorfälle gehen darauf zurück, dass Kunden etwas falsch konfigurieren, das der Anbieter bereits standardmäßig sichert. Dein Job ist die Kundenseite der Grenze.

Die zweite ist Identity-First Denken. On-Premises Netzwerke behandelten den Perimeter als primäre Kontrolle. Cloud behandelt Identity als primäre Kontrolle. Jeder API Aufruf, jedes Workload, jede Cross-Account Interaktion wird durch IAM vermittelt. AWS IAM, Azure RBAC und Microsoft Entra ID, Google Cloud IAM und Workload Identity Federation sind der neue Perimeter. Wenn du Role Chaining, Condition Keys, attributbasierte Zugriffskontrolle und Assume-Role Flows nicht verstehst, kannst du Cloud Security nicht in der Tiefe machen.

Die dritte ist Everything-as-Code. Click-Ops Cloud Security plateaut schnell. Moderne Teams beschreiben Netzwerke, Identity, Detection Rules und Compliance Baselines in Terraform, OpenTofu, Pulumi oder Bicep. Pull Requests sind, wie Veränderung passiert. Code Review ist, wie Risiko gefiltert wird. Wenn du noch nie Infrastruktur über Versionskontrolle verwaltet hast, ist diese Lücke das Größte, was zu schließen ist.

Der IaC Security Skill Stack (Terraform + Checkov + Pulumi + Open Policy Agent)

Infrastructure as Code ist der Einstiegspunkt für Shift-Left Security auf Cloud Plattformen. Der minimal viable Stack:

Terraform oder OpenTofu für deklarative Infrastruktur. Pulumi, wenn dein Team Allzweck Sprachen wie TypeScript oder Python bevorzugt. CloudFormation und Bicep bleiben in AWS und Azure Shops gültig.

Statische Analyse mit Checkov, tfsec, KICS oder Trivy. Diese Scanner fangen öffentliche S3 Buckets, fehlende Encryption Flags, zu permissive Security Groups und IAM Policies mit Wildcard Actions ab, bevor sie in Produktion gelangen. Die meisten Cloud Security Teams gaten Pull Requests mit mindestens einem dieser Tools.

Policy as Code mit Open Policy Agent und Conftest, oder Sentinel, wenn du Terraform Cloud betreibst. Damit kannst du organisationsspezifische Regeln kodieren, etwa öffentliche Load Balancer in Produktionsaccounts verbieten oder Tags für Kostenattribution und Incident Response verlangen.

Drift Detection mit AWS Config, Azure Policy oder GCP Security Command Center Custom Modules. Der Punkt ist nicht nur Drift zu finden, sondern ihn als Source of Truth ins IaC Repository zurückzuspielen.

Wenn du ein kleines Referenz Repository bauen kannst, das eine gehärtete Landing Zone provisioniert, jede Änderung mit Checkov scannt und Merges bei Policy Verletzungen blockiert, hast du ein Portfolio Artefakt, das direkt auf eine Cloud Security Engineer Stellenbeschreibung mappt.

Kubernetes Security ist die schwierigste Skill Klippe (und wo die Nachfrage am höchsten ist)

Kubernetes ist, wo Cloud Security die starken Kandidaten vom Rest trennt. Die Plattform exponiert mehr Konfigurationsfläche als jeder Cloud Account, und die meisten Production Cluster sind in mindestens einer materiellen Weise fehlkonfiguriert.

Die Fähigkeiten, die zählen:

Role-Based Access Control jenseits von cluster-admin. Echte Workloads brauchen namespaced Roles, gescopte Service Accounts und Binding Hygiene. Der default Service Account in jedem Namespace ist der häufigste Privilege Escalation Pfad.

NetworkPolicy als erste Segmentierungsebene, gefolgt von Service Mesh Policies in Istio, Linkerd oder Cilium für Umgebungen, die sie brauchen. Ohne NetworkPolicy kann jedes Pod mit jedem anderen Pod sprechen, das Cloud Äquivalent eines flachen VLANs.

Pod Security Admission, der Ersatz für die deprecated PodSecurityPolicy. Die meisten Teams paaren PSA mit OPA Gatekeeper oder Kyverno für reichere Admission Control: privilegierte Container blockieren, Non-Root Users verlangen, Image Registry Allow-Lists und signierte Images erzwingen.

Workload Identity. Pods sollten sich bei Cloud APIs über IRSA auf AWS, Workload Identity auf GCP oder Azure AD Workload Identity authentifizieren. Langlebige statische Credentials in Container Environment Variablen sind das größte Cloud-Native Breach Pattern.

Supply Chain Kontrollen, einschließlich SBOM Generierung mit Syft, Vulnerability Scanning mit Trivy oder Grype und Signature Verification mit Cosign und Sigstore. SLSA und in-toto liefern das Framework Vokabular, und jedes Team, das Supply Chain ernst nimmt, wird erwarten, dass du sie kennst.

Wenn du echte Tiefe in Kubernetes Security aufbaust, wirst du schwer zu ersetzen. Die Security Engineer Karriereseite markiert Kubernetes als wiederkehrende Senior Anforderung.

CSPM, CWPP, CNAPP: was diese Akronyme tatsächlich bedeuten

Der Cloud Security Tooling Markt ist dicht an Akronymen. Drei sind für jeden Sysadmin wichtig, der einsteigt.

Cloud Security Posture Management, oder CSPM, evaluiert Cloud Konfiguration kontinuierlich gegen Benchmarks wie CIS, PCI DSS oder interne Baselines. AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center und Drittanbieter Tools wie Wiz, Prisma Cloud und Orca sind die Hauptbeispiele. CSPM beantwortet die Frage, ist dieser Account so konfiguriert, wie wir gesagt haben, dass er sein sollte.

Cloud Workload Protection Platforms, oder CWPP, überwachen laufende Workloads auf Bedrohungen: Virtual Machines, Container und Serverless. AWS GuardDuty für Runtime Threat Detection, Microsoft Defender for Servers, Microsoft Sentinel für SIEM Korrelation und Runtime Tools wie Falco sind CWPP. CWPP beantwortet, passiert gerade etwas Schlechtes.

Cloud-Native Application Protection Platforms, oder CNAPP, bündeln CSPM, CWPP, IaC Scanning, Identity Analytics und manchmal Data Security in ein einziges Produkt. CNAPP ist die Marktrichtung und der Schirm, unter dem die meisten Vendor RFPs jetzt sitzen.

Du musst nicht jedes Produkt beherrschen. Du musst aber argumentieren können, welche Kontrolle in welche Schicht gehört, und artikulieren können, warum ein CSPM Finding mit Public S3 Bucket anders ist als ein CWPP Finding mit EC2 Instance, die bekannte C2 Infrastruktur kontaktiert.

Die Drei-Cloud Cert Entscheidung: AWS Security Specialty, Azure SC-100, GCP PCSE

Wähle zuerst eine Plattform. Oberflächliche Vertrautheit über drei ist konsistent weniger einstellbar als echte Tiefe in einer.

AWS Pfad: Solutions Architect Associate als Voraussetzung für Vokabular, dann AWS Certified Security Specialty (SCS-C02) als sicherheitsspezifisches Credential. Größter Arbeitsmarkt, breitestes Tooling Ökosystem, die Default Wahl ohne andere Einschränkungen. Die AWS Security Specialty Zertifizierungsseite erläutert den Prüfungsumfang.

Azure Pfad: AZ-104 für grundlegendes Vokabular, dann AZ-500 (Microsoft Certified: Azure Security Engineer Associate). Für Architekten Rollen ist SC-100 (Cybersecurity Architect Expert) das Senior Credential, oft gepaart mit SC-200 für SOC orientierte Arbeit in Microsoft Sentinel. Starke Wahl für Enterprise, regulierte Industrien und Regierungsarbeit in Europa. Siehe die Azure Security Engineer Zertifizierungsseite für Vorbereitungs Hinweise.

GCP Pfad: Professional Cloud Security Engineer (PCSE) ist das fokussierte Credential. Der Markt ist kleiner als AWS oder Azure, zahlt aber gut bei tech-forward Arbeitgebern. Mit Professional Cloud Architect für Breite kombinieren. Die GCP Security Zertifizierungsseite fasst die Prüfung zusammen.

Nützliche Cross-Platform Credentials sind CCSP von ISC2 für Governance lastige Rollen und CKS (Certified Kubernetes Security Specialist) für jedes Team, das Cluster betreibt.

EU Compliance Kontext: NIS2, DORA, DSGVO für Cloud

Europäische Arbeitgeber filtern zunehmend nach Compliance Fluss, und die regulatorische Untergrenze ist deutlich gestiegen.

NIS2, in nationales Recht in der gesamten EU umgesetzt, erweitert den Umfang der Cybersicherheits Verpflichtungen auf viele weitere Sektoren und erhöht Anforderungen an Incident Reporting, Supply Chain Security und Management Verantwortlichkeit. Cloud Workloads in Sektoren im Geltungsbereich brauchen klare Control Mappings, und CSPM Evidence ist oft Teil des Audit Trails.

DORA, der Digital Operational Resilience Act, gilt für Finanzdienstleistungen und ihre kritischen Dritten, einschließlich Cloud Anbieter. Er schreibt ICT Risikomanagement, Pflege eines Drittenregisters, Threat-Led Penetration Testing für signifikante Entitäten und rigorose Incident Klassifikation vor. Von Cloud Security Engineers in Banken, Versicherungen und Fintechs wird erwartet, DORA auf Arbeitsniveau zu kennen.

Die DSGVO prägt weiterhin Anforderungen an Datenresidenz, Verschlüsselung und Access Logging. Für Cloud bedeutet das praktisch, dass Workloads, die EU Personendaten verarbeiten, klare Datenfluss Dokumentation, Schlüsselverwaltungsstrategien, die Subprozessor Exposition berücksichtigen, und audit-fähige Evidence der Zugriffskontrolle brauchen.

Es wird nicht erwartet, dass du Jurist bist. Es wird erwartet, dass du zwischen Regulatoren, Auditoren und Ingenieuren übersetzen kannst, und dass du weißt, welche AWS Config Rules, Azure Policy Initiativen oder GCP Security Command Center Findings die Evidence liefern, die jede Kontrolle verlangt.

Ein realistischer 9-Monats Übergangsplan

Der Übergangs Zeitplan, der für berufstätige Sysadmins tatsächlich funktioniert:

Monate 1 bis 2: wähle eine Hauptplattform und schließe die Architect Zertifizierung auf Associate Niveau ab. Ziel ist Plattform Vokabular und die Fähigkeit, Konsole und CLI unter Druck zu navigieren.

Monate 3 bis 4: Deep Dive in Identity. Baue eine AWS Multi-Account Organization mit Control Tower oder Äquivalent, konfiguriere SSO von einem externen Identity Provider, schreibe IAM Policies für drei realistische Workload Personas und dokumentiere die Versagensmodi, die du findest.

Monate 5 bis 6: Infrastructure as Code und IaC Scanning. Schreibe deine Lab Umgebung in Terraform oder OpenTofu neu, füge Checkov einem Pre-Commit Hook hinzu und baue ein minimales Open Policy Agent Ruleset, das Public Storage und unverschlüsselte Volumes blockiert.

Monat 7: Container und Kubernetes Security. Stelle ein EKS, AKS oder GKE Cluster bereit, härte es gegen den CIS Benchmark, installiere Falco für Runtime Detection und demonstriere SBOM Generierung plus Image Signing an einem Beispiel Workload.

Monat 8: bestehe die sicherheitsspezifische Zertifizierung, AWS Security Specialty, AZ-500 oder GCP PCSE.

Monat 9: Portfolio Politur und Job Suche. Veröffentliche ein Write-Up des Labs, beitrage eine Detection Rule oder ein IaC Modul zu einem Open-Source Projekt und beginne, dich für Cloud Security Engineer Rollen zu bewerben. Das Bootcamp Programm ist um genau diese Art projektgeführter Progression gebaut und komprimiert die Lernschleife für Berufstätige.

Gehaltsrealität: vom Sysadmin zum Junior Cloud Security zum Senior Cloud Security in der EU

Die EU Vergütungslandschaft belohnt den Schritt klar.

Sysadmin und Infrastructure Operations Rollen in Westeuropa zahlen typisch zwischen 35.000 und 45.000 EUR für Mid-Level Praktiker, mit Senior On-Premises Spezialisten, die die niedrigen Fünfziger erreichen.

Junior bis Mid-Level Cloud Security Engineer Rollen, das realistische Ziel nach einem erfolgreichen Übergang, zahlen zwischen 55.000 und 80.000 EUR je nach Standort und Sektor. Berlin, Amsterdam, Dublin, Paris und Madrid clustern um die Mitte dieses Bandes, mit London und Zürich darüber.

Senior Cloud Security Engineer Rollen, typisch drei bis fünf Jahre nach dem Übergang erreicht, zahlen zwischen 75.000 und 95.000 EUR. Spezialisten in Kubernetes Security, Detection Engineering oder regulierten Industrien drücken das obere Ende.

Cloud Security Architect Rollen in regulierten Sektoren überschreiten regelmäßig 100.000 EUR in großen europäischen Hubs. Beratungsarbeit bei Big 4 Firmen und Security Boutiquen folgt einer ähnlichen Kurve mit abrechenbarer Auslastung und Reisen als Variablen.

Das Gehalts Delta zwischen Sysadmin und Cloud Security Engineer ist real, typisch 15.000 bis 30.000 EUR am Übergangspunkt, und die Trajektorie nach oben ist steiler als traditionelle Ops Karrieren. Die Prämie ist nachhaltig und nicht vorübergehend, weil die Nachfrage das Angebot Jahr für Jahr übersteigt.

Wo das Bootcamp passt

Das Unihackers Cybersecurity Bootcamp deckt Cloud Security Grundlagen in Modul m11 (Security Engineering and Emerging Topics) ab, neben dem breiteren Sicherheitskontext, den Cloud Security Engineers brauchen. Für Sysadmins mit starkem Infrastruktur Hintergrund ergänzt das Bootcamp den Sicherheits- und offensiven Kontext, den reine Infrastruktur Hintergründe verfehlen. Lies das Programm für Modul für Modul Aufschlüsselung.

Häufige Blockaden

Drei Muster erklären die meisten festgefahrenen Sysadmin zu Cloud Security Übergänge:

1. Sich über drei Clouds verteilen, bevor man eine beherrscht. Oberflächliche Vertrautheit ist weniger wert als echte Tiefe. Die meisten Senior Cloud Security Rollen wollen plattformspezifische Expertise.

2. Infrastructure as Code überspringen. Moderne Cloud Security Arbeit setzt IaC Fluss voraus. Click-Ops Cloud Security Engineers gibt es, aber sie tendieren auf Junior Niveau zu plateauen.

3. Identity Komplexität unterschätzen. Cloud Identity ist der häufigste Angriffsvektor und der schwerste Skill zum Vortäuschen. Baue hier echte Tiefe.

Der Übergang ist real und gut bezahlt, belohnt aber Tiefe vor Breite. Senior Cloud Security Engineers haben zuerst eine Plattform gut aufgebaut, dann erweitert.