Interviewfragen zu Identity & Access Management

Nein. Die drei Kategorien von Authentifizierungsfaktoren sind etwas, das man weiß (Passwort/PIN), etwas, das man hat (Token/Telefon) und etwas, das man ist (Biometrie). Ein Fingerabdruck oder Gesichtsscan gehört zu „etwas, das man ist“, einem gemessenen physischen Merkmal. Der Haken: Biometrie ist kein Geheimnis und lässt sich nicht erneuern — leckt die Vorlage deines Fingerabdrucks, kannst du deinen Fingerabdruck nicht ändern. Deshalb funktioniert Biometrie am besten als ein Faktor, der oft einen lokalen Schlüssel entsperrt, statt als eigenständiger Passwortersatz.

Nein. Das Löschen des Cookies entfernt nur die Anmeldedaten aus deinem Browser — der Session-Datensatz (oder ein noch gültiges JWT) auf dem Server bleibt typischerweise nutzbar, bis er abläuft oder explizit invalidiert wird. Ein Angreifer, der das Token bereits abgegriffen hat, kann es weiter nutzen. Der Irrtum hält das Cookie für die Session selbst; es ist nur ein Zeiger auf serverseitigen Zustand. Echtes Abmelden muss die Session serverseitig invalidieren oder das Token widerrufen und mit kurzer TTL versehen.

Nein. MFA hebt die Hürde stark, aber OTP- und Push-Faktoren sind phishbar: Adversary-in-the-Middle-Kits (z. B. Evilginx) leiten Login und Code in Echtzeit weiter, und MFA-Müdigkeit/Push-Bombing bringt Nutzer zum Bestätigen. Abgefangene Codes sind innerhalb ihres kurzen Fensters wiederverwendbar. Der Irrtum ist „MFA = nicht phishbar”; entscheidend ist der Faktortyp. Phishing-resistente MFA — FIDO2/WebAuthn-Passkeys, an den Origin der Seite gebunden — ist das, was dies tatsächlich vereitelt.

Nicht allein. Viele Systeme halten bestehende Sitzungen und bereits ausgestellte Tokens nach einem Passwortwechsel gültig — OAuth-Refresh-Tokens, „App-Passwörter“, API-Schlüssel und persistente Cookies — sodass ein Angreifer mit einer aktiven Sitzung drinbleiben kann. Die richtige Reaktion ist, das Passwort zu ändern UND alle Sitzungen und Tokens zu invalidieren, App-Anmeldedaten zu widerrufen und MFA-Geräte sowie Wiederherstellungseinstellungen zu prüfen. Anzunehmen, ein Reset allein werfe den Angreifer hinaus, ist ein klassischer Incident-Response-Fehler.

Nein. Ein Salt ist ein eindeutiger Zufallswert, der direkt neben dem Hash gespeichert wird; seine Aufgabe ist es, identische Passwörter unterschiedlich hashen zu lassen und vorberechnete Rainbow Tables zu vereiteln — nicht geheim zu bleiben. Es ist unproblematisch, wenn ein Angreifer, der die Datenbank stiehlt, auch die Salts erhält. Was Passwörter wirklich schützt, ist ein langsamer, gesalzener Hash (bcrypt, scrypt, Argon2). Ein separater, optionaler geheimer „Pepper“ ist ein anderes Konzept.

Grenzenlose Autonomie plus Tool-Zugriff ist die „exzessive Handlungsmacht

Wenn der Abruf jedes indexierte Dokument liefert, egal wer fragt, gibt das Modell getreu Daten preis, die der Nutzer nicht sehen sollte — das ist ein Autorisierungsfehler, keine Halluzination. Erzwingen Sie die dokumentbezogenen Berechtigungen des Nutzers zum Zeitpunkt des Abrufs, sodass nur autorisierte Fragmente in den Kontext gelangen. Ein längerer System-Prompt ist umgehbar und implementiert keine Zugriffskontrolle, die Temperatur ist irrelevant, und ein anderes Modell hat dieselbe Lücke.

Passwortspeicherung braucht einen absichtlich langsamen, gesalzenen, speicherharten Hash — bcrypt, scrypt oder Argon2 — damit das Knacken gestohlener Hashes teuer ist und Rainbow Tables nicht greifen. Ein schneller Hash wie SHA-256 lässt sich im großen Maßstab trivial per Brute Force knacken; reversible Verschlüsselung bedeutet, dass eine einzige Schlüsselkompromittierung alle Passwörter auf einmal offenlegt; und Klartext ist unhaltbar, egal wie abgeriegelt die Datenbank ist. Wählen Sie Argon2id (oder bcrypt) mit einem abgestimmten Kostenfaktor und einem einzigartigen Salt pro Benutzer.

Auditoren prüfen Nachweise, nicht Absichten: Legen Sie die Richtlinie zur Zugriffsüberprüfung vor, datierte Aufzeichnungen jeder Überprüfung mit der Freigabe eines Genehmigers sowie die Bestätigung, dass markierte Zugriffe tatsächlich entzogen und verifiziert wurden. Eine mündliche Bestätigung beweist nichts Wiederholbares, ein Versprechen, nächstes Quartal anzufangen, zeigt, dass die Kontrolle im Prüfzeitraum nicht wirksam war, und ein Organigramm beschreibt Berichtslinien, keine Zugriffsentscheidungen. Nur die datierten, zuordenbaren Artefakte belegen, dass die Kontrolle über den gesamten Zeitraum wie vorgesehen wirksam war.

Das Austrittsrisiko ist der verbleibende Zugriff, daher ist die zu verifizierende Kontrolle das zeitnahe Deprovisioning jedes Zugriffswegs — Verzeichniskonten, SSO, VPN, privilegierte und Dienstkonten sowie Drittanbieter-SaaS — abgeglichen mit dem Joiner/Mover/Leaver-Prozess (JML). Anzunehmen, die Personalabteilung erledige alles ohne Verifizierung, hinterlässt Lücken, die niemandem gehören. Das Konto „für den Fall der Rückkehr“ aktiv zu lassen ist ein dauerhaftes, unüberwachtes Risiko. Nur die E-Mail zu deaktivieren ignoriert die vielen anderen Systeme, die die Person noch erreichen könnte. Es geht darum, zu verifizieren, dass der Zugriff tatsächlich und vollständig entfernt ist, nicht darauf zu vertrauen.

Dringlichkeit, Autorität und das Überspringen der Prüfung sind lehrbuchhafter Social-Engineering-Druck, der auf ein hochwertiges Konto zielt. Der Mitarbeiter muss den definierten Identitätsprüfungsprozess befolgen, bevor er irgendetwas zurücksetzt, und eskalieren, falls er nicht erfüllt werden kann. Auf Verlangen zurückzusetzen, eine erratbare „Sicherheitsfrage“ wie die Lieblingsfarbe zu nutzen oder das neue Passwort per E-Mail an den Anrufer zu senden, übergibt einem Angreifer die Kontrolle über das Konto der Führungskraft.

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.

Ein Open Redirect in einem Authentifizierungsfluss erlaubt einem Angreifer, einen vertrauenswürdig wirkenden Login-Link zu basteln, der den Benutzer nach der Authentifizierung — und möglicherweise einen Autorisierungscode oder ein Token — an eine vom Angreifer kontrollierte Domain sendet und so Kontoübernahme und überzeugendes Phishing ermöglicht. Beheben Sie es, indem Sie exakte Redirect-URIs serverseitig streng per Allow-List freigeben und alles andere ablehnen. Es ist weder kosmetisch noch ein Performance-Problem, und HTTPS hilft nicht, weil das Ziel des Angreifers ebenfalls eine gültige HTTPS-Site sein kann.

LSASS speichert zwischengespeicherte Anmeldedaten und Geheimnisse, daher ist ein unerwarteter Prozess, der seinen Speicher liest, ein Kennzeichen für Anmeldedatendiebstahl (z. B. ein Dump im Mimikatz-Stil). Triagieren Sie den auffälligen Prozess und dessen übergeordneten Prozess, isolieren Sie den Host, um laterale Bewegung zu stoppen, und rotieren Sie die Anmeldedaten, die erfasst worden sein könnten — einschließlich privilegierter und Dienstkonten. Es hat nichts mit Grafik-Rendering oder Speicherplatz zu tun, und es als normal abzutun, kann zur Kompromittierung der gesamten Domäne führen. Die harmlos klingenden Ablenker sind genau die Art, wie Analysten einen aktiven Einbruch übersehen.

Das ist fehlerhafte Zugriffskontrolle (IDOR): Der Server prüft nicht, ob der authentifizierte Benutzer auf das angeforderte Objekt zugreifen darf. Die Behebung ist eine objektbezogene Autorisierung, die serverseitig bei jeder Anfrage erzwungen wird. Das Bereinigen der Zahl belegt keine Eigentümerschaft. Das Verschlüsseln oder Verschleiern der ID ist Obskurität und bleibt erratbar, leakbar oder wiederholbar. Die HTTP-Methode ist für die Autorisierung irrelevant. Prüfe stets das Recht des Aufrufers auf das konkrete Objekt, bevor du es zurückgibst.

Balanciere Nutzbarkeit und Risiko: erzwinge Conditional Access gebunden an die Geräte-Posture und isoliere Unternehmensdaten in einem verwalteten Container (MAM/MDM), sodass sie kontrolliert und selektiv gelöscht werden können, ohne das gesamte Privatgerät zu übernehmen. Uneingeschränkter Zugriff riskiert Datenabfluss auf nicht verwalteten, womöglich kompromittierten Endpunkten. Ein striktes Verbot treibt zu unsicheren Umgehungen wie dem Weiterleiten an private Mail. Und Daten als Anhang zu mailen verstreut sie unkontrollierbar auf Geräte, die du nie zurückholst.

Vertrauen anhand des Netzwerkstandorts bedeutet, dass ein einziger Fuß in der Tür breite laterale Bewegung gewährt — eine gephishte VPN-Zugangsdatei und der Angreifer ist „drin". Zero Trust beseitigt implizites Vertrauen: Jeder Zugriff wird authentifiziert, autorisiert und laufend anhand von Identität und Geräte-Posture neu bewertet, mit Least Privilege und Segmentierung (NIST SP 800-207). Ein zweites oder breiteres VPN dehnt nur dasselbe Flat-Trust-Problem aus, und dem LAN statt dem VPN zu vertrauen wiederholt den ursprünglichen Fehler.

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.

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.

Es zählt die Auswirkung: Ein wiederverwendetes oder überprivilegiertes Dienstkonto, das Domänen-Admin oder kritische Systeme freischaltet, ist das relevante Finding — prüfen Sie also die Wiederverwendung und mappen Sie die Rechte und den Lateral-Movement-Pfad. Zuerst alle anderen Hashes zu knacken ist Beschäftigung, die das Wesentliche verzögert. Das Passwort des Dienstkontos zu ändern ist destruktiv, bricht die Produktion und warnt die Verteidiger. Eine aktive Anmeldeinformation im Klartext per E-Mail zu senden ist selbst eine Exposition und schlechte operative Sicherheit.

Führungskräfte sind genau die Konten, die Angreifer wollen (BEC, Überweisungsbetrug), daher kehrt eine Ausnahme das Risikomodell um. Löse die Reibung, nicht die Kontrolle: setze phishing-resistente FIDO2/Passkeys ein, die schneller sind als Codes. Der Ausnahme nachzugeben zerstört die Glaubwürdigkeit des Programms und lässt deine wertvollsten Konten ungeschützt. Das MFA-Projekt einzustellen gibt eine erstklassige Kontrolle auf. Es heimlich hinter ihrem Rücken zu aktivieren zerstört Vertrauen und Rechenschaft.

Geringste Rechte plus Just-in-Time-Zugriff: gewähre die minimal nötigen Berechtigungen, zeitlich begrenzt und protokolliert, sodass Debugging möglich ist, ohne dass stehender Admin zu einem dauerhaften Risiko und einer Audit-Lücke wird. Dauerhafter Cluster-Admin verletzt das Prinzip der geringsten Rechte und vergrößert den Schadensradius jeder Kompromittierung. Eine pauschale Verweigerung blockiert legitime Arbeit und lädt zu riskanten Schatten-Workarounds ein. Das gemeinsame Anmeldeinformation des Admin-Dienstkontos zu teilen zerstört die Rechenschaft — Aktionen sind keiner Person mehr zuzuordnen.

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.

Validieren Sie vor dem Eskalieren. Unternehmens-VPNs, Cloud-Proxys (CASB oder M365-Dienst-IPs) und Mobilfunkanbieter erzeugen routinemäßig falsche „unmögliche Reisen“; prüfen Sie daher die Egress-IPs, das MFA-Ergebnis und das Gerät/den User-Agent, bevor Sie handeln. Bei jedem Treffer automatisch zu sperren verursacht Alarmmüdigkeit und untergräbt das Vertrauen der Nutzer in das SOC. Anzunehmen, es sei immer ein Fehlalarm, übersieht eine echte Kontoübernahme. Den Vorgesetzten anzuschreiben ist langsam und keine Kontrolle — die Protokolle antworten schneller und zuverlässiger.

Gehen Sie davon aus, dass das Passwort bereits kompromittiert ist: Erzwingen Sie ein Zurücksetzen UND machen Sie die aktiven Sitzungen und Token des Kontos ungültig, denn ein Reset allein vertreibt keinen Angreifer, der bereits eine aktive Sitzung oder ein Refresh-Token besitzt. Jagen Sie dann anomale Anmeldungen, MFA-Aufforderungen, Postfachregeln und OAuth-Berechtigungen aus dem Expositionsfenster. Die E-Mail zu löschen oder dem Benutzer zu sagen, er solle sein Passwort „beim nächsten Mal“ ändern, lässt das Konto weit offen. Ein Virenscan adressiert Malware auf dem Endgerät, nicht gestohlene Anmeldedaten in der Cloud.

Credential Stuffing spielt bekannte Benutzername:Passwort-Paare aus fremden Datenlecks ab und setzt auf Passwort-Wiederverwendung – hohe Erfolgsrate pro Versuch, oft über viele IPs und Geräte verteilt, um menschlich zu wirken. Password Spraying probiert ein oder zwei gängige Passwörter (wie Winter2026!) über viele Konten, um unter den Sperrschwellen zu bleiben. Stuffing nutzt Wiederverwendung aus; Spraying nutzt schwache gemeinsame Passwörter aus. MFA schlägt beide.

Unter Windows liegen die Hashes lokaler Konten (NTLM) in der SAM-Hive unter C:\Windows\System32\config\SAM, geschützt solange das OS läuft; lebende Anmeldedaten sitzen im LSASS-Speicher, und Domänen-Hashes liegen in NTDS.dit auf einem Domänencontroller. Unter Linux liegen Hashes in /etc/shadow (nur für root lesbar), während /etc/passwd Kontometadaten enthält. Angreifer stehlen diese, um Passwörter offline zu knacken oder Pass-the-Hash zu betreiben.

SPF veröffentlicht, welche IPs für eine Domain Mail senden dürfen. DKIM fügt eine kryptografische Signatur hinzu, damit der Empfänger prüfen kann, dass die Nachricht nicht verändert wurde und von der Domain stammt. DMARC bindet die SPF/DKIM-Ergebnisse über das Alignment an den sichtbaren From:-Header, sagt Empfängern, was bei Fehlschlag zu tun ist (none/quarantine/reject), und sendet Berichte. SPF und DKIM allein schützen das vom Nutzer gesehene From nicht – DMARC erzwingt das.

DAC lässt den Dateneigentümer den Zugriff nach eigenem Ermessen gewähren; MAC erzwingt den Zugriff zentral über Labels/Freigaben und ist nicht-diskretionär; RBAC gewährt Zugriff über Jobrollen; ABAC bewertet Attribute (Benutzer, Ressource, Umgebung) gegen eine Richtlinie für feingranulare, kontextbewusste Entscheidungen.

Die Klassifizierung kennzeichnet Daten nach Sensibilität, damit die Organisation Kontrollen anwendet, die zu Wert und Risiko verhältnismäßig sind, und so sowohl Unterschutz als auch verschwenderischen Überschutz vermeidet. Der Dateneigentümer (eine Geschäftsrolle) legt die Klassifizierung fest und akzeptiert das Risiko, während der Datenverwalter (oft die IT) die Schutzkontrollen umsetzt und pflegt.

Due Diligence ist die fortlaufende Untersuchung und das Verständnis von Risiken (wissen, was getan werden sollte), während Due Care das Ergreifen der angemessenen Maßnahmen ist, die eine umsichtige Person ergreifen würde, um sie anzugehen (es tatsächlich tun). Diligence ist Recherche und Aufsicht; Care ist Umsetzung und Pflege.

Das Identity-Lifecycle-Management steuert ein Konto von der Erstellung bis zur Stilllegung: Bereitstellung beim Onboarding (Joiner), Anpassung der Berechtigungen bei Rollenwechsel (Mover) und zeitnahe Deaktivierung beim Austritt (Leaver), mit durchgängigen periodischen Zugriffsüberprüfungen. Die häufigsten Fehler sind schleichende Rechteanhäufung bei Movern und verwaiste Konten durch versäumte Deaktivierungen.

Eine Richtlinie ist die übergeordnete verbindliche Absichtserklärung des Managements; ein Standard ist eine verbindliche konkrete Regel, die die Richtlinie durchsetzt (z. B. AES-256); eine Prozedur ist die verbindliche Schritt-für-Schritt-Anleitung; eine Leitlinie ist eine optionale Empfehlung. Richtlinien, Standards und Prozeduren sind verbindlich, während Leitlinien im Ermessen liegen.

Die quantitative Analyse weist konkrete Geldwerte zu, um den erwarteten Verlust zu berechnen; die qualitative Analyse stuft das Risiko auf relativen Skalen (hoch/mittel/niedrig) per Experteneinschätzung ein. Quantitativ verwendet SLE = Vermögenswert x Expositionsfaktor, ARO = erwartete Vorkommen pro Jahr und ALE = SLE x ARO, um den jährlich erwarteten Verlust in Euro auszudrücken.

Sie können mindern (Eintrittswahrscheinlichkeit/Auswirkung mit Kontrollen senken), übertragen (die finanzielle Auswirkung über Versicherung oder Verträge verlagern), vermeiden (die riskante Tätigkeit ganz einstellen) oder akzeptieren (das Restrisiko bewusst hinnehmen). Die Wahl hängt vom Risikoappetit und einem Kosten-Nutzen-Vergleich gegenüber dem erwarteten Verlust des Risikos ab.

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.

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.

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).

Ein JWT besteht aus drei base64url-Teilen – Header, Payload (Claims) und Signatur – durch Punkte verbunden. Der Server signiert Header und Payload mit einem Geheimnis oder privaten Schlüssel und verifiziert diese Signatur bei jeder Anfrage, um den Claims ohne serverseitigen Sitzungszustand zu vertrauen. Fallstricke: alg=none akzeptieren, RS256-zu-HS256-Schlüsselverwechslung, Ablauf/Aussteller/Zielgruppe nicht zu validieren, Geheimnisse in die lesbare Payload zu legen und keinen Widerrufsweg zu haben.

Kerberos stützt sich auf ein vertrauenswürdiges Key Distribution Center (KDC). Der Client authentifiziert sich einmal beim Authentication Server und erhält ein mit dem Schlüssel des KDC verschlüsseltes Ticket-Granting-Ticket (TGT). Um einen Dienst zu erreichen, legt er das TGT dem Ticket-Granting-Service vor und erhält ein mit dem Schlüssel dieses Dienstes verschlüsseltes Service-Ticket. Der Dienst entschlüsselt es und vertraut ihm. Passwörter durchqueren nie das Netz, und Tickets sind zeitlich begrenzt.

Die App leitet den Benutzer zum Autorisierungsserver weiter, um sich anzumelden und einzuwilligen. Der Server leitet mit einem kurzlebigen Autorisierungscode zurück. Das Backend der App tauscht diesen Code (plus sein Client-Geheimnis) dann am Token-Endpunkt über einen Server-zu-Server-Back-Channel gegen ein Access-Token. Das hält Tokens aus Browser/URL fern. Öffentliche Clients ergänzen PKCE, um den Code an den ursprünglichen Anforderer zu binden.

Speichere Passwörter mit einer bewusst langsamen, gesalzenen, adaptiven Passwort-Hashfunktion – bcrypt, scrypt oder Argon2 – nie mit einem schnellen Allzweck-Hash wie SHA-256 oder MD5. Schnelle Hashes sind auf Geschwindigkeit ausgelegt, sodass Angreifer mit GPUs Milliarden Versuche pro Sekunde gegen eine geleakte Datenbank testen können. Langsame Hashes haben einen einstellbaren Arbeitsfaktor (und Speicherkosten), der jeden Versuch teuer macht und Brute Force selbst nach einem Leak unpraktikabel hält.

Der Client baut eine Kette vom Server-Zertifikat (Leaf) über eine oder mehrere Zwischen-CAs bis zu einer Root-CA in seinem Vertrauensspeicher auf. Er verifiziert die Signatur jedes Zertifikats mit dem öffentlichen Schlüssel des nächsten Ausstellers, prüft Gültigkeitsdaten, Name-/Hostname-Übereinstimmung, Schlüsselverwendung und Widerruf (CRL/OCSP). Das Vertrauen endet an einer selbstsignierten, vorab vertrauten Wurzel; die Kette ist nur gültig, wenn jedes Glied stimmt.

Ein Salt ist ein einzigartiger Zufallswert, der pro Benutzer erzeugt und vor dem Hashing mit dem Passwort kombiniert wird. Er sorgt dafür, dass identische Passwörter unterschiedliche Hashes ergeben, und macht vorberechnete Angriffe wie Rainbow Tables nutzlos, da der Angreifer pro Salt eine eigene Tabelle bräuchte. Salts werden neben dem Hash gespeichert. Ein Pepper ist ein zusätzlicher geheimer Wert, für alle Benutzer gleich, getrennt aufbewahrt (z. B. in der App-Konfiguration oder einem HSM), sodass ein Datenbankleck allein nicht genügt.

SSO zentralisiert die Authentifizierung bei einem Identity Provider (IdP). Besucht ein Benutzer einen Service Provider (die App), leitet die App zum IdP weiter; der Benutzer meldet sich einmal an, und der IdP gibt eine signierte Assertion oder ein Token zurück, das seine Identität bürgt. SAML trägt dies als signierte XML-Assertion; OIDC trägt es als signiertes JSON-ID-Token auf OAuth 2.0. Die App vertraut der Signatur des IdP, statt Passwörter selbst zu handhaben.

TOTP (Time-based One-Time Password) kombiniert ein bei der Einrichtung festgelegtes gemeinsames Geheimnis mit der aktuellen, in feste Fenster (meist 30 Sekunden) unterteilten Zeit. Es führt HMAC über den Zeitschritt-Zähler mit dem Geheimnis aus und kürzt das Ergebnis dann auf einen 6-stelligen Code. Sowohl App als auch Server halten dasselbe Geheimnis und dieselbe Uhr, sodass sie unabhängig denselben Code berechnen – ohne Netzwerkaufruf. Der Code wechselt mit jedem Fenster.

Die CIA-Triade umfasst die drei Kernziele der Informationssicherheit: Vertraulichkeit (nur autorisierte Parteien können Daten lesen), Integrität (Daten werden nicht unbefugt verändert) und Verfügbarkeit (autorisierte Nutzer können bei Bedarf auf Systeme zugreifen). Nahezu jede Maßnahme lässt sich einem oder mehreren dieser Ziele zuordnen.

Defense in Depth bedeutet, mehrere unabhängige Sicherheitsmaßnahmen zu schichten, sodass bei Ausfall einer Maßnahme die anderen das Asset weiterhin schützen. Sie geht davon aus, dass keine einzelne Maßnahme perfekt ist — etwa durch die Kombination von Firewall, Netzwerksegmentierung, Endpunktschutz, MFA, Least Privilege und Verschlüsselung, statt sich allein auf den Perimeter zu verlassen.

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.

MFA erfordert zwei oder mehr Authentifizierungsfaktoren aus unterschiedlichen Kategorien — etwas, das man weiß (Passwort), etwas, das man hat (Telefon/Token), etwas, das man ist (Biometrie). Sie hilft, weil ein Angreifer, der einen Faktor wie ein Passwort stiehlt, sich ohne die anderen trotzdem nicht anmelden kann. Phishing-resistente MFA wie FIDO2 ist am stärksten.

Phishing ist Social Engineering, das Menschen dazu verleitet, Anmeldedaten preiszugeben, Geld zu überweisen oder Malware auszuführen, meist über gefälschte E-Mails oder Websites. Die Abwehr ist geschichtet: E-Mail-Filterung und -Authentifizierung (SPF/DKIM/DMARC), MFA zur Begrenzung des Schadens gestohlener Anmeldedaten, Awareness-Schulungen und eine einfache Möglichkeit, verdächtige Nachrichten zu melden.

UEBA (User and Entity Behaviour Analytics) erstellt Verhaltens-Baselines für Benutzer und Entitäten (Hosts, Dienstkonten, Geräte) und nutzt Statistik oder maschinelles Lernen, um Abweichungen als Risiko zu bewerten. Es glänzt bei Bedrohungen ohne saubere Signatur: kompromittierte Anmeldedaten, Insider- Missbrauch und laterale Bewegung — z. B. ein Benutzer, der plötzlich auf Systeme zugreift, die er nie berührt, zu ungewöhnlichen Zeiten oder anomale Datenmengen bewegt. Es ergänzt die regelbasierte Erkennung, statt sie zu ersetzen, und braucht Abstimmung, um Fehlalarme durch legitime Verhaltensänderungen zu vermeiden.

Zugriffsüberprüfungen (Rezertifizierung) sind periodische Prüfungen, bei denen ein verantwortlicher Eigentümer bestätigt, dass der Zugriff jeder Person weiterhin gerechtfertigt ist, und widerruft, was es nicht ist. Sie sind das Sicherheitsnetz, das Privilegienwucherung, verwaiste Konten und für ein beendetes Projekt erteilte Berechtigungen aufspürt. Die Kontrolle funktioniert nur, wenn ein sachkundiger Eigentümer — meist der Vorgesetzte oder Ressourceneigentümer — den Zugriff wirklich prüft, statt ihn gedankenlos abzunicken, und wenn Widerrufe durchgesetzt werden.

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.

Das moderne NIST SP 800-63B stellt Länge über Komplexität: lange Passphrasen erlauben (mindestens 8, 64+ unterstützen), alle Zeichen einschließlich Leerzeichen akzeptieren und keine Zusammensetzungsregeln wie «ein Großbuchstabe, ein Symbol» vorschreiben. Neue Passwörter gegen Listen geleakter Passwörter prüfen, den verpflichtenden periodischen Ablauf streichen (nur bei Hinweis auf Kompromittierung wechseln) und wissensbasierte «Sicherheitsfragen» verwerfen. Ziel sind Regeln, die echten Angriffen standhalten, statt Benutzer in vorhersehbare Muster zu drängen.

Phishing-resistente MFA bedeutet, dass der zweite Faktor nicht gegen die echte Seite wiedereingespielt werden kann, selbst wenn der Benutzer getäuscht wird. FIDO2/WebAuthn-Passkeys erreichen das mit ursprungsgebundener Public-Key-Kryptografie: Der Authentikator signiert eine an die Domain der echten Seite gebundene Challenge, sodass eine von einer Nachahmerseite oder einem Angreifer-in-der-Mitte erbeutete Anmeldeinformation nutzlos ist. TOTP-Codes und Push-Aufforderungen bleiben phishbar, weil sie in Echtzeit weitergeleitet werden können.

PAM kontrolliert und überwacht die Konten, die den größten Schaden anrichten können — Domänenadministratoren, root, Dienstkonten. Es tresoriert und rotiert ihre Anmeldedaten, damit keine Geheimnisse geteilt oder hartkodiert werden, vermittelt Sitzungen, sodass Administratoren das rohe Passwort nie sehen, zeichnet auf, was privilegierte Benutzer tun, und gewährt die Erhöhung idealerweise just-in-time statt als dauerhaften Zugriff. Ziel ist es, den Schadensradius der Konten zu verkleinern, die Angreifer am meisten begehren.

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.

Halte Access-Tokens kurzlebig (Minuten), damit ein gestohlenes schnell abläuft, und nutze langlebigere Refresh-Tokens, um neue Access-Tokens zu erhalten, ohne den Benutzer erneut aufzufordern. Rotiere Refresh-Tokens bei jeder Verwendung und erkenne die Wiederverwendung eines verbrauchten Tokens als Diebstahlsignal, das die Kette widerruft. Das Ziel ist, das Begrenzen des Fensters eines kompromittierten Tokens gegen das Vermeiden ständiger erneuter Anmeldungen abzuwägen.

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.

Eine Risikobewertung identifiziert Assets und ihren Wert, die Bedrohungen und Schwachstellen, die sie betreffen könnten, und schätzt das Risiko dann als Funktion von Eintrittswahrscheinlichkeit und Auswirkung. Sie können es qualitativ durchführen (hoch/mittel/niedrig, schnell und subjektiv) oder quantitativ (SLE × ARO = ALE, datengetrieben, aber schwieriger). Rahmenwerke wie NIST RMF und ISO 27005 geben Struktur, und das Ergebnis speist die Risikobehandlung: mindern, übertragen, vermeiden oder akzeptieren.

Enumerieren Sie die Rechte des Kontos und die Fehlkonfigurationen des Hosts: Token-Privilegien wie SeImpersonate, Dienstpfade ohne Anführungszeichen, schwache Dienstberechtigungen, AlwaysInstallElevated und gespeicherte Zugangsdaten. Missbrauchen Sie dann das zuverlässigste — Token-Impersonation (Potato-Angriffe) ist ein gängiger Weg zu SYSTEM.

Defense in Depth bedeutet, mehrere unabhängige Sicherheitskontrollen zu staffeln, sodass bei Versagen einer Kontrolle die anderen das Asset weiterhin schützen. Keine Kontrolle gilt als perfekt, daher stapelt man präventive, detektierende und reagierende Maßnahmen über die Schichten Netzwerk, Host, Anwendung und Daten.

Geringste Rechte bedeutet, dass jeder Benutzer, Prozess oder Dienst nur den minimal für seine Aufgabe nötigen Zugriff erhält, und nicht mehr. Das verkleinert den Wirkungsradius jeder Kompromittierung oder jedes Fehlers. Man setzt es mit rollenbasiertem Zugriff, Just-in-Time-Erhöhung, regelmäßigen Zugriffsüberprüfungen und der Abschaffung dauerhafter Adminrechte durch.

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.

Überall TLS erzwingen, jede Anfrage authentifizieren (z. B. OAuth2/OIDC-Tokens) und pro Objekt autorisieren, sodass Benutzer nur ihre eigenen Daten erreichen. Eingabevalidierung, Rate Limiting und Kontingente, Schemavalidierung sowie gründliches Logging ergänzen. Der häufigste API-Fehler ist gebrochene objektbezogene Autorisierung, also prüfe bei jedem Ressourcenzugriff die Eigentümerschaft.

Segmentierung teilt ein Netzwerk in isolierte Zonen, sodass ein Einbruch in einer die anderen nicht ungehindert erreichen kann, was laterale Bewegung begrenzt. Zero Trust geht weiter: Es entfernt implizites Vertrauen auf Basis des Netzwerkstandorts vollständig und authentifiziert und autorisiert jede Anfrage, egal woher sie stammt – Mikrosegmentierung ist eine Möglichkeit, es umzusetzen.

Brute Force zielt auf ein einzelnes Konto mit vielen Passwortversuchen, daher sieht man viele Fehlschläge auf einen Benutzernamen konzentriert. Password Spray dreht das um: ein oder wenige gängige Passwörter über viele Konten probiert, langsam und unauffällig, sodass jedes Konto nur ein paar Fehlschläge sieht. Das Erkennungssignal ist das Verhältnis von Konten zu Fehlschlägen und das Timing, nicht die reine Anzahl der Fehlschläge.

Lateral Movement bedeutet, dass ein Angreifer einen Fußabdruck nutzt, um andere Systeme zu erreichen. Anzeichen sind unerwartete Netzwerk-Logons (Typ 3) und RDP (Typ 10), Zugriff auf Admin-Shares wie C$ und ADMIN$, Remote-Ausführungstools wie PsExec, WMI und WinRM, Pass-the-Hash-Muster und ein normalerweise lokales Konto, das sich plötzlich an vielen Hosts authentifiziert.

Bestätigen Sie vor dem Handeln, dass der Alert echt ist: Lesen Sie, was ausgelöst wurde und warum, dann reichern Sie an — wer ist der Benutzer, sind Quell-IP/Geo/Gerät erwartbar, ist es Impossible Travel, gab es zuvor Fehlschläge? Klassifizieren Sie als echten oder falschen Treffer, eskalieren oder dämmen Sie ein, wenn echt (Sitzung deaktivieren, MFA-Reset erzwingen), und dokumentieren Sie alles, damit der nächste Analyst Ihrer Argumentation folgen kann.

HTTP ist zustandslos — jede Anfrage ist unabhängig und hat keine Erinnerung an vorherige. Sitzungen fügen darauf Zustand hinzu: Nach der Anmeldung gibt der Server eine Kennung aus, die der Browser in einem Cookie speichert und bei jeder Anfrage erneut sendet. Serverseitige Sitzungen halten den Zustand auf dem Server, indiziert über eine undurchsichtige Sitzungs-ID; zustandslose Tokens wie JWTs legen signierten Zustand in das Token selbst, sodass der Server ohne Speicher prüfen kann.