Interviewfragen zu Cloud

Nein. Die Cloud läuft nach einem Modell geteilter Verantwortung: Der Anbieter sichert die zugrunde liegende Infrastruktur („Sicherheit der Cloud“), aber du bleibst verantwortlich für deine Daten, das Identitäts- und Zugriffsmanagement, die Konfiguration und — bei IaaS — das Betriebssystem und Patches („Sicherheit in der Cloud“). Die große Mehrheit der Cloud-Verstöße sind kundenseitige Fehlkonfigurationen wie öffentliche Buckets und zu freizügiges IAM, keine Anbieterausfälle. Anzunehmen, der Anbieter sichere deine Daten, ist genau, wie diese Verstöße entstehen.

Ungenutzte, überprivilegierte Dienstkonten sind bevorzugte Ziele und eine große Angriffsfläche. Inventarisieren Sie sie, deaktivieren oder löschen Sie die ungenutzten (mit Blick auf Ausfälle), beschränken Sie die verbleibenden auf Least Privilege und geben Sie jedem einen Eigentümer sowie eine wiederkehrende Überprüfung. Sie zu belassen ist ein dauerhaftes Risiko, pauschale Admin-Rechte maximieren den Schadensradius, und alles auf ein gemeinsames Konto zu konsolidieren zerstört Least Privilege und Nachvollziehbarkeit.

Das serverseitige Abrufen von durch Angreifer kontrollierten URLs ist Server-Side Request Forgery (SSRF): Es ermöglicht den Zugriff auf interne Dienste oder den Cloud-Metadaten-Endpunkt, um Zugangsdaten zu stehlen. Mildern Sie es durch eine Allow-List erlaubter Hosts und Schemata, das Sperren privater und Link-Local-Bereiche (mit erneuter Prüfung nach jeder Weiterleitung) und das Härten des Metadatenzugriffs mit IMDSv2. Zu sagen, es gebe kein Risiko, ignoriert den Zugriff, den die Anfrage gewährt, und ein Lade-Spinner oder Caching ändert nichts daran, wohin der Server sich verbinden darf.

Ohne Control-Plane-Audit-Logs bist du blind, wer auf Cloud-Ebene was getan hat, und Erkennung, Forensik und Compliance hängen alle von diesem Protokoll ab. Aktiviere CloudTrail sofort, organisationsweit, mit Lieferung an einen separaten, zugriffskontrollierten, manipulationssicheren (unveränderlichen) Bucket. Zu sagen, es sei egal, solange nichts schiefläuft, ignoriert, dass du keine Historie hättest, wenn doch etwas schiefläuft. Bis zu einem Vorfall zu warten bedeutet, dass die prägenden frühen Aktionen bereits unprotokolliert und unwiederbringlich sind. Anwendungslogs erfassen keine API-, IAM- oder Konsolenaktivität auf der Control Plane.

Management-Ports, die für das gesamte Internet offen sind, werden innerhalb von Minuten gescannt und per Brute Force angegriffen, daher besteht die Lösung darin, die Angriffsfläche zu verkleinern: Beschränke den Security-Group-Ingress auf bekannte Admin-CIDRs oder VPN, oder entferne den eingehenden Verkehr ganz mittels Bastion oder SSM Session Manager. SSH auf einen Nicht-Standard-Port zu verschieben ist Security by Obscurity, die Scanner trivial aushebeln. Ein stärkeres Passwort verkleinert die exponierte Fläche nicht und stoppt kein Credential Stuffing. Auf eine Host-Firewall zu vertrauen ignoriert die Angriffsfläche, die die Security Group offen ins Internet bewirbt.

Öffentliche Kundendaten sind eine aktive Exposition: Behebe zuerst den Zugriff, indem du Block Public Access aktivierst und die Bucket- sowie die IAM-Policy korrigierst, um den laufenden Abfluss zu stoppen. Ziehe danach die Zugriffsprotokolle heran (S3 Server Access Logs / CloudTrail-Datenereignisse), um zu bewerten, was tatsächlich erreicht wurde, und stoße die Breach- und Benachrichtigungsprozesse gemäß Richtlinie an. Ein Ticket für den nächsten Sprint lässt regulierte Daten tagelang offen. Die Daten woanders hinzukopieren erzeugt eine zweite Kopie, lässt aber den Originalbucket offen. Umbenennen ändert nichts an den Berechtigungen.

Geheimnisse gehören in einen verwalteten Speicher mit Zugriffskontrolle, Audit und Rotation, zur Laufzeit injiziert – niemals in die Versionskontrolle eingecheckt. Nutze einen Secrets Manager (AWS Secrets Manager, HashiCorp Vault) und entferne die eingecheckten Werte aus der Historie, dann rotiere sie, weil sie als kompromittiert gelten müssen. Base64 ist Kodierung, kein Schutz – jeder kann es dekodieren. Ein privates Repo verteilt das Geheimnis weiterhin an alle mit Clone-Zugriff sowie an CI-Systeme und Forks. Es ins Binary zu kompilieren versteckt nur ein Geheimnis, das weiterhin trivial extrahierbar ist.

Ein in ein Image eingebackener statischer Key leakt leicht und lebt ewig, daher besteht die Lösung darin, die langlebige Anmeldung vollständig zu eliminieren: Hänge eine IAM-Rolle über ein Instance Profile an, das temporäre, automatisch rotierte Anmeldedaten liefert, ohne dass etwas eingebacken ist. Manuelle Rotation alle 90 Tage lässt zwischen den Rotationen weiterhin ein langlebiges Geheimnis in der AMI. Den Key in eine Umgebungsvariable zu verschieben macht ihn weder weniger statisch noch weniger geleakt. Ihn dem Ops-Team zu mailen verteilt die Exposition auf Postfächer und Archive.

Die manuelle Konsolenänderung ist Konfigurations-Drift: Das nächste terraform apply kann den Fix still zurücksetzen, und die Änderung hat zudem Review und Audit umgangen. Gleiche sie ab, indem du die Änderung in Terraform codierst, plan/apply ausführst, damit Code und Realität übereinstimmen, und Leitplanken gegen Ad-hoc-Konsolenänderungen ergänzt (Konsolenzugriff nach Least Privilege, SCPs, Drift-Erkennung). Nichts zu tun hinterlässt eine Mine für das nächste apply. Den Terraform-State zu löschen ist destruktiv und kann Ressourcen verwaisen lassen oder duplizieren. Terraform aufzugeben wirft Reproduzierbarkeit, Review und Audit-Spuren weg.

Eine überprivilegierte Instanzrolle macht jeden Fehler auf Anwendungsebene – insbesondere ein SSRF, das den Instance-Metadata-Service erreicht – zur vollständigen Konto-Übernahme, weil der Angreifer die Anmeldedaten der Rolle erbt. Ersetze den Wildcard durch die minimalen Aktionen und Ressourcen-ARNs, die die Workload tatsächlich nutzt, und erzwinge IMDSv2, um den Metadaten-Endpunkt zu härten. Ein VPC schränkt IAM überhaupt nicht ein. Eine einzelne Deny-Regel ist Whac-A-Mole und lässt alles andere erlaubt. Ein Load Balancer ist für den Schadensradius der Anmeldedaten irrelevant.

Behandle jedes gepushte Geheimnis als verbrannt: widerrufe und rotiere es zuerst, denn Bots scrapen öffentliche Commits innerhalb von Sekunden, prüfe dann CloudTrail auf Missbrauch und entferne es aus der Historie. Den Commit zu löschen hilft nicht — der Schlüssel ist bereits geklont, geforkt und von Dritten gecacht. Das Repo privat zu machen lässt einen bereits geleakten, aktiven Schlüssel in den Händen von Angreifern. Die Datei in die .gitignore aufzunehmen ändert nichts an einem bereits committeten Geheimnis.

Die LLM-Supply-Chain umfasst Basismodelle, fine-getunte Varianten, Datensätze, Embeddings, Plugins, Bibliotheken und die Hosting-Plattform — jede davon ein Punkt, an dem Risiko entstehen kann. Zu den Bedrohungen zählen das Herunterladen manipulierter oder mit Backdoors versehener Modellgewichte, bösartige Fine-Tunes, vergiftete oder lizenzbelastete Datensätze, anfällige oder überberechtigte Plugins sowie typosquattete Modell-Repos. Verteidigung: Modelle aus vertrauenswürdigen Registries beziehen, Integrität und Provenienz prüfen, eine AI Bill of Materials pflegen, Abhängigkeiten scannen und pinnen, Plugins prüfen und das Least-Privilege-Prinzip auf alles anwenden, mit dem das Modell integriert wird.

Beginne mit einem minimalen, vertrauenswürdigen Basis-Image (distroless oder slim), um die Angriffsfläche zu verkleinern, scanne Images in der CI und in der Registry auf bekannte CVEs, fixiere und verifiziere Image-Digests, führe als Nicht-Root-Benutzer aus und vermeide es, Secrets einzubacken. Signiere Images und erzwinge Admission-Richtlinien, sodass nur gescannte, signierte Images laufen. Baue regelmäßig neu, damit gepatchte Basis-Layer durchfließen.

Verschlüsselung während der Übertragung (TLS) schützt Daten, die über das Netz wandern, vor Abhören und Manipulation; erzwinge TLS überall und lehne Klartext ab. Verschlüsselung im Ruhezustand schützt gespeicherte Daten auf Festplatten und Backups, typischerweise über KMS-verwaltete Schlüssel mit Umschlagverschlüsselung. Beide sind Basiskontrollen, aber keine stoppt eine autorisierte, aber bösartige Anfrage — der Dienst entschlüsselt transparent für gültige Aufrufer — daher bleibt Zugriffskontrolle am wichtigsten.

Ein Benutzer ist eine langlebige Identität mit permanenten Anmeldedaten; eine Rolle ist eine Identität ohne permanente Anmeldedaten, die jeder vertrauenswürdige Principal annehmen kann, um kurzlebige Tokens zu erhalten; eine Richtlinie ist das JSON-Dokument, das Berechtigungen gewährt und an beide angehängt wird. Geringste Rechte bedeutet, Rollen Benutzern vorzuziehen, Richtlinien auf konkrete Aktionen und Ressourcen einzugrenzen und nur das zu gewähren, was eine Aufgabe braucht — und im Lauf der Zeit zu überprüfen und auszumisten.

IMDS ist ein link-lokaler Endpunkt (169.254.169.254), der einer Instanz ihre Metadaten liefert, einschließlich temporärer Anmeldedaten für ihre angehängte IAM-Rolle. SSRF kann den Server dazu bringen, diese URL abzurufen und diese Anmeldedaten zu leaken. IMDSv2 verlangt ein PUT, um ein kurzlebiges Session-Token zu erhalten, setzt ein standardmäßiges IP-TTL/Hop-Limit von 1 und lehnt Anfragen mit bestimmten Headern ab — sodass ein einfaches SSRF-GET es nicht mehr erreichen kann.

RBAC steuert, was Identitäten gegen die Kubernetes-API tun können — Roles und ClusterRoles gewähren Verben auf Ressourcen, über RoleBindings an Subjekte gebunden — und sollte geringste Rechte befolgen, indem cluster-admin und Wildcards vermieden werden. Network Policies steuern den Pod-zu-Pod-Verkehr, der standardmäßig alles erlaubt, bis du ein Default-Deny anwendest und dann erforderliche Flüsse explizit zulässt. Zusammen begrenzen sie den Wirkungsradius, wenn ein Pod oder Token kompromittiert wird.

CloudTrail zeichnet jeden API-Aufruf im Konto auf — wer was wann von wo aus getan hat — und liefert dir den maßgeblichen Audit-Trail für Untersuchungen und Compliance. GuardDuty ist ein verwalteter Bedrohungserkennungsdienst, der CloudTrail-, VPC-Flow- und DNS-Logs analysiert, um Funde wie Anmeldedaten-Exfiltration oder Krypto-Mining sichtbar zu machen. CloudTrail ist die zu schützende Quelle der Wahrheit; GuardDuty verwandelt diese Telemetrie in umsetzbare Alarme.

Die klassischen Fehler sind öffentliche ACLs oder Bucket-Richtlinien, die anonymen Zugriff oder Zugriff für alle AWS-Benutzer erlauben, zu weit gefasste Principals oder Wildcard-Aktionen, fehlende Standardverschlüsselung und fehlendes Logging. Man verhindert sie, indem man Block Public Access auf Kontoebene aktiviert, IAM-/Bucket-Richtlinien nach dem Prinzip der geringsten Rechte einsetzt, Standardverschlüsselung und TLS erzwingt und Zugriffs-Logging sowie Config-Regeln einschaltet, um Abweichungen zu erkennen.

Speichere Secrets in einem dedizierten verwalteten Dienst (Secrets Manager, Parameter Store, Vault), verschlüsselt mit einem KMS-Schlüssel, und gewähre den Zugriff über IAM-Rollen, sodass Workloads sie zur Laufzeit mit kurzlebigen Anmeldedaten abrufen. Backe Secrets niemals in Code, Container-Images oder eingecheckte .env-Dateien ein. Füge automatische Rotation, eingegrenzte Schlüsselrichtlinien und Audit-Logging hinzu, sodass jeder Abruf nachvollziehbar ist.

Security Groups sind zustandsbehaftete Firewalls, die an Instanzen/ENIs angehängt sind: Sie haben nur Allow-Regeln, und der Rückverkehr eines erlaubten Flusses wird automatisch zugelassen. Network ACLs sind zustandslose Filter an der Subnetzgrenze: Sie haben geordnete Allow- und Deny-Regeln, und du musst den Rückverkehr auf ephemeren Ports explizit erlauben. Security Groups sind die primäre Kontrolle; NACLs ergänzen grobe Leitplanken auf Subnetzebene wie das Blockieren eines IP-Bereichs.

Der Anbieter sichert die Cloud selbst ab — physische Rechenzentren, Hardware, den Hypervisor und die von ihm betriebenen verwalteten Dienste. Du sicherst ab, was du in die Cloud stellst — deine Daten, Identitäten, Konfigurationen, das OS-Patching wo zutreffend und die Zugriffskontrollen. Die genaue Grenze verschiebt sich: Bei IaaS besitzt du das OS aufwärts, bei SaaS besitzt du vor allem Daten und Zugriff.

CI/CD ist hochwertig, weil sie Deployment-Anmeldedaten hält und nicht vertrauenswürdigen Code ausführt. Risiken umfassen kompromittierte Abhängigkeiten und Build-Actions, geleakte oder zu weit gefasste Secrets, veränderliche Drittanbieter-Actions sowie überprivilegierte Runner oder OIDC-Vertrauen. Reduziere sie mit fixierten und verifizierten Abhängigkeiten, kurzlebiger OIDC-Föderation statt langlebiger Schlüssel, geringsten Rechten eingegrenzt auf konkrete Repos/Branches, isolierten ephemeren Runnern und signierten Artefakten mit nachverfolgter Provenienz (SLSA).

Die Signierung bindet ein Artefakt kryptografisch an seinen Hersteller, sodass Konsumenten überprüfen können, dass es nicht manipuliert oder ausgetauscht wurde. Die Provenienz sind signierte Metadaten, die beschreiben, wie, wo und aus welcher Quelle das Artefakt gebaut wurde. Zusammen — über Tools wie Sigstore für schlüssellose Signierung und das SLSA-Framework für Provenienzstufen — ermöglichen sie es einem Deployer zu überprüfen, dass ein Image aus der erwarteten Pipeline und Quelle stammt, und vereiteln so Manipulation und Angriffe durch Abhängigkeitssubstitution.

Scannen Sie Images auf bekannte CVEs in OS-Paketen und App-Bibliotheken sowie auf Fehlkonfigurationen und eingebettete Secrets, sowohl zur Build-Zeit als auch fortlaufend in der Registry — weil neue CVEs auftauchen, nachdem ein Image gebaut wurde. Verwenden Sie minimale oder distroless Basis-Images, um die Angriffsfläche zu verkleinern, pinnen und referenzieren Sie Basis-Images per Digest und führen Sie den Container als Nicht-Root aus. Scannen ist notwendig, ersetzt aber nicht den Laufzeitschutz.

IaC-Scanning analysiert Terraform-, CloudFormation-, Kubernetes- und ähnliche Definitionen statisch gegen eine Richtlinie, um Fehlkonfigurationen zu finden — öffentliche S3-Buckets, offene Security Groups, fehlende Verschlüsselung — bevor sie überhaupt bereitgestellt werden. Da dieselbe Vorlage viele Ressourcen bereitstellt, verhindert eine einmalige Korrektur wiederkehrende Drift, und das Erkennen vor dem Anwenden ist weitaus günstiger als das Beheben aktiver Cloud-Ressourcen. Zu den Tools gehören Checkov, tfsec und KICS, idealerweise als Policy-as-Code-Gates durchgesetzt.

Behandeln Sie die Pipeline wie Produktionsinfrastruktur: Sie hält die Zugangsdaten, um Code auszuliefern und die Produktion zu erreichen, sodass ihre Kompromittierung jede nachgelagerte Kontrolle umgeht. Härten Sie sie mit isolierten, kurzlebigen Runnern; Tokens mit minimalen Rechten und kurzer Lebensdauer (OIDC-Föderation statt langlebiger Secrets); geschützten Branches und geprüfter Pipeline-Konfiguration; per Digest gepinnten Drittanbieter-Actions; und vollständigem Audit-Logging. Die Pipeline ist ein erstklassiges Ziel, keine Klempnerei.

Least Privilege bedeutet, dass jeder Nutzer, Prozess und Dienst nur den für seine Aufgabe minimal erforderlichen Zugriff erhält und nicht mehr. Es begrenzt den Wirkungsradius eines kompromittierten Kontos, senkt das Insider-Bedrohungsrisiko und verkleinert die Angriffsfläche. Man wendet es über rollenbasierten Zugriff, regelmäßige Zugriffsüberprüfungen und Just-in-Time-Erhöhung an.

Bedingter Zugriff macht die Zugriffsentscheidung vom Kontext abhängig statt von einer festen Regel. Er wertet Signale aus — wer der Benutzer ist, Gerätekonformität, Standort, die App und einen aus Anomalieerkennung berechneten Risikowert — und reagiert verhältnismäßig: erlauben, blockieren oder eine Verschärfung wie MFA oder ein konformes Gerät verlangen. Risikobasierter Zugriff ist die dynamische Variante, bei der ein Echtzeit-Risikosignal die Richtlinie steuert.

Identitätsföderation stellt Vertrauen zwischen einem Identitätsanbieter (IdP), der Benutzer authentifiziert, und Dienstanbietern (vertrauenden Parteien) her, die diese Authentifizierung nutzen. Der IdP verifiziert den Benutzer und stellt eine signierte Assertion oder ein Token aus; der Dienstanbieter vertraut ihm, statt eigene Anmeldedaten zu verwalten. Das ermöglicht domänenübergreifendes SSO und zentrale Kontrolle, konzentriert aber das Risiko: Kompromittiert man den IdP, kompromittiert man alles, was ihm vertraut.

Just-in-Time-Zugriff gewährt erhöhte Privilegien nur bei Bedarf, für begrenzte Zeit, meist mit Genehmigung — danach laufen sie automatisch ab, sodass es kein dauerhaftes Privileg zu stehlen gibt. Break-Glass-Konten sind die bewusste Ausnahme: hochprivilegierte Notfallkonten, normalerweise ruhend, hinter strengen Kontrollen und starken Alarmen verriegelt, die nur genutzt werden, wenn die normalen Zugriffswege versagen. JIT verkleinert die alltägliche Angriffsfläche; Break-Glass garantiert, dass man in einer Krise dennoch hineinkommt.

RBAC vergibt Berechtigungen über Rollen, die Benutzern zugewiesen werden — einfach nachzuvollziehen, aber anfällig für eine Rollenexplosion, je mehr Sonderfälle entstehen. ABAC wertet Richtlinien über Attribute von Benutzer, Ressource, Aktion und Umgebung aus und skaliert so auf feingranulare, kontextbewusste Entscheidungen, allerdings auf Kosten der Komplexität. Die meisten reifen Systeme kombinieren beides: Rollen für grobe Vergaben, Attribute und Richtlinien für die bedingten Details.

SCIM (System for Cross-domain Identity Management) ist eine standardisierte REST/JSON-API und ein Schema zum Erstellen, Aktualisieren und Löschen von Benutzerkonten über Anwendungen hinweg. An ein HR-System oder einen IdP angebunden, automatisiert es den Joiner-Mover-Leaver-Lebenszyklus: Konten und Berechtigungen werden bei Einstellung provisioniert, bei Rollenwechsel angepasst und — am wichtigsten — beim Austritt deprovisioniert, was die verwaisten Konten beseitigt, die Angreifer lieben.

Zero Trust verwirft die Annahme, dass das Sich-im-Netzwerk-Befinden dich vertrauenswürdig macht. Jede Anfrage an eine Ressource wird auf ihre eigenen Merkmale hin authentifiziert und autorisiert — Verifikation von Identität, Gerätegesundheit und Kontext — durch einen Policy Decision Point, der Least-Privilege-Zugriff pro Session gewährt. Es gibt keine vertrauenswürdige interne Zone; der Netzwerkstandort einer Anfrage ist nur ein Signal, kein Freifahrtschein.

Threat Modeling beantwortet vier Fragen: Was bauen wir, was kann schiefgehen, was tun wir dagegen und haben wir gute Arbeit geleistet. Sie diagrammieren das System (oft ein Datenflussdiagramm mit Vertrauensgrenzen), zählen Bedrohungen mit einem Framework wie STRIDE auf, priorisieren nach Risiko und weisen Gegenmaßnahmen zu. PASTA fügt eine risiko- und angreiferzentrierte Note hinzu; Angriffsbäume zerlegen ein einzelnes Ziel. Es zur Designzeit zu tun ist weit billiger, als Produktion zu patchen.

Schwachstellenmanagement ist eine fortlaufende Schleife: Assets und Schwachstellen entdecken (Scanning, Asset-Inventar), nach echtem Risiko priorisieren (CVSS plus Ausnutzbarkeit, Exposition und Asset-Kritikalität — Frameworks wie EPSS und SSVC helfen), beheben oder mindern, den Fix verifizieren und über Trends und SLAs berichten. Der Scan ist der leichte Teil; die Disziplin liegt darin, zu priorisieren und die Schleife zu schließen, damit das Risiko mit der Zeit tatsächlich sinkt.

Secrets niemals fest im Quellcode codieren oder in Git committen. In einem dedizierten Secrets Manager oder Vault speichern, zur Laufzeit injizieren, den Zugriff mit geringsten Rechten begrenzen, regelmäßig rotieren und kurzlebige dynamische Anmeldeinformationen langlebigen statischen vorziehen. Jeden Zugriff auditieren.

SSRF bringt einen Server dazu, HTTP- (oder andere) Anfragen an ein vom Angreifer gewähltes Ziel zu stellen, und missbraucht die Netzwerkposition des Servers, um interne Dienste hinter der Firewall zu erreichen. In der Cloud ist es besonders gravierend, weil der Instanz-Metadaten-Dienst (z. B. 169.254.169.254) IAM-Anmeldedaten zurückgeben kann und so ein SSRF zur Kompromittierung des Cloud-Kontos macht.