Was hat sich geändert

Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.

Version 7 → 8

Aktualisierung

Zwei neue Abschnitte: wie MFA-Ermüdung und weitergeleitete Codes funktionieren und warum Passkeys beidem standhalten, sowie was ein Konto privilegiert macht, mit einem Vergleich von dauerhaften Privilegien und Just-in-Time-Zugriff.

3 Lektionen aktualisiertDauer

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

Dauer von 17 auf 21 Minuten geändert.

Authentifizierung vs. Autorisierung und MFA-Faktoren

Im Kern jeder Zugriffsentscheidung stehen zwei Fragen: 1. **Authentifizierung (AuthN)**: *Wer sind Sie?* Das System prüft, ob die Person oder der Dienst das Konto tatsächlich kontrolliert. 2. **Autorisierung (AuthZ)**: *Was dürfen Sie tun?* Nach dem Identitätsnachweis entscheiden Richtlinien, Rollen und Berechtigungen, welche Anwendungen, Daten und Aktionen erlaubt sind. Ein Benutzer kann einwandfrei authentifiziert sein und trotzdem keine Berechtigung für das Lohnabrechnungssystem haben. Halten Sie beide Schritte gedanklich getrennt. ::diagram isf-authn-authz ### Multi-Faktor-Authentifizierung MFA kombiniert Faktoren aus unterschiedlichen Kategorien, damit ein einzelnes gestohlenes Geheimnis nicht ausreicht: - **Wissen**: Passwort, PIN, Sicherheitsfrage. - **Besitz**: ein Smartphone für Push-Benachrichtigungen, eine Authenticator-App mit TOTP-Codes, ein FIDO2-Sicherheitsschlüssel. - **Inhärenz**: Fingerabdruck oder Gesichtserkennung, meist zum Entsperren eines Geräts oder Passkeys. Nicht alle Faktoren sind gleich stark. SMS- und E-Mail-Codes können abgefangen oder per Phishing erbeutet werden. Push-Bestätigungen lassen sich durch sogenannte MFA-Fatigue-Angriffe missbrauchen. **Passkeys (FIDO2/WebAuthn)** sind an die echte Website gebunden und phishing-resistent; deshalb gelten sie in vielen Organisationen als bevorzugter Faktor. ### Zwei Angriffe auf den zweiten Faktor, und warum Passkeys standhalten **MFA-Ermüdung.** Der Angreifer besitzt das Passwort bereits, zum Beispiel von einer Phishing-Seite. Jeder Anmeldeversuch schickt eine Push-Anfrage auf das Telefon des Opfers. Der Angreifer wiederholt das, oft spät in der Nacht, bis der müde Benutzer auf Approve tippt, nur damit es aufhört. Technisch wurde nichts gebrochen: Der Benutzer wurde zermürbt. **Weitergeleitete Codes.** Eine gefälschte Anmeldeseite fragt nach Passwort und Einmalcode und reicht beides innerhalb von Sekunden an die echte Website weiter. Das funktioniert bei Codes per SMS, E-Mail und Authenticator-App gleichermaßen, denn ein Code gilt überall, wo er eingegeben wird. Ein **Passkey** schließt beide Lücken. Er ist ein Schlüsselpaar: Der private Schlüssel verlässt das Gerät des Benutzers nie, und das Gerät beantwortet eine Anmeldeanfrage nur für die Website-Adresse (den Origin), für die der Passkey registriert wurde. Eine täuschend ähnliche Seite hat eine andere Adresse und erhält deshalb nichts, was sie wiederverwenden könnte. Es gibt keine Anfrage, die man aus Reflex bestätigt, und keinen Code, der sich weiterreichen lässt. Ein Passkey ist außerdem **passwortlos**: Der Benutzer entsperrt ihn mit Fingerabdruck, Gesichtserkennung oder der Geräte-PIN; es wird kein Passwort eingegeben oder auf dem Server gespeichert. | Faktor | Ein gestohlenes Passwort reicht nicht | Hält einer gefälschten Anmeldeseite stand | | --- | --- | --- | | Code per SMS oder E-Mail | Ja | Nein, der Code lässt sich weiterleiten | | Code aus einer Authenticator-App | Ja | Nein, der Code lässt sich weiterleiten | | Push-Bestätigung | Ja | Nein, und wiederholte Anfragen können den Benutzer zermürben | | Passkey (FIDO2/WebAuthn) | Ja | Ja, er ist an die echte Website gebunden | > Tipp: Fragen Sie nicht nur, ob MFA aktiviert ist, sondern ob der Faktor phishing-resistent ist.

Identitätsvokabular

Der Text hat sich nur in anderen Sprachen geändert.

IAM, PAM und IGA

Identitätssicherheit wird meist in drei Disziplinen unterteilt. Sie überschneiden sich, und reife Programme betreiben sie gemeinsam. - **IAM (Identity and Access Management)** steuert den täglichen Zugriff: Single Sign-On, MFA, Verzeichnisse, Benutzerlebenszyklus und Zugriffsrichtlinien. Ziel ist, dass die richtigen Personen mit möglichst wenig Reibung die richtigen Anwendungen erreichen. - **PAM (Privileged Access Management)** schützt die wenigen Konten, die den größten Schaden anrichten können: Domänenadministratoren, root, Datenbankbesitzer, Cloud-Administratoren. Typische Kontrollen sind ein Credential-Tresor, Passwortrotation, genehmigte Sitzungen und Sitzungsaufzeichnung. - **IGA (Identity Governance and Administration)** fragt, ob ein Zugriff überhaupt bestehen *sollte*. Dazu gehören Zugriffsanträge und Genehmigungen, regelmäßige Zugriffsüberprüfungen (Rezertifizierungen), Funktionstrennung und Nachweise für Audits. Eine einfache Eselsbrücke: IAM öffnet die Tür, PAM bewacht den Tresorraum, und IGA prüft regelmäßig die Gästeliste. In der Monofor-Suite vereint **Monosign** Zugriffsmanagement und Governance in einer Plattform, **Monopam** konzentriert sich auf privilegierten Zugriff, und **Monosync** synchronisiert Identitätsdaten zwischen Quellen und Zielen. Benutzer von Monopam und Monosync melden sich normalerweise über Monosign an, das damit als zentrale Identität dient. ::diagram isf-iam-pam-iga ### Was ein Konto privilegiert macht Ein Konto ist privilegiert wegen dem, **was es ändern kann**, nicht wegen der Person, die es benutzt. Ein Domänenadministrator ist das naheliegende Beispiel. Ein Dienstkonto, das ein Backup-Werkzeug mit Administratorrechten auf allen Servern verwendet, ist genauso mächtig und wird leichter übersehen: Niemand meldet sich damit an, sein Passwort ändert sich selten, und niemand fühlt sich dafür zuständig. Wenn Sie mit einem Kunden privilegierte Konten auflisten, fragen Sie nach beiden Arten: nach denen, die Menschen benutzen, und nach denen, die Maschinen benutzen. ### Dauerhafte Privilegien und Just-in-Time-Zugriff **Dauerhafte Privilegien (standing privilege)** bedeuten, dass der mächtige Zugriff ständig vorhanden ist, ob ihn jemand nutzt oder nicht. Jede Stunde, die er besteht, ist eine Stunde, in der ein Angreifer ihn nutzen kann. **Just-in-Time-Zugriff** beseitigt das: Die Person beantragt den Zugriff, wenn eine Aufgabe ihn erfordert, er wird für ein begrenztes Zeitfenster gewährt und endet danach von selbst. Beispiel: Eine Datenbankadministratorin braucht am Donnerstagabend Produktionszugriff für eine Schemaänderung. | | Dauerhaftes Privileg | Just-in-Time-Zugriff | | --- | --- | --- | | Wann sie den Zugriff besitzt | Das ganze Jahr | Donnerstag 20:00 bis 22:00 Uhr | | Wer entschieden hat | Wer es vor langer Zeit eingerichtet hat | Ein Kollege, der diesen Antrag genehmigt hat | | Was ein Angreifer am Freitag findet | Ein funktionierendes Administratorkonto | Nichts Verwertbares | > Tipp: Beginnen Sie mit der IAM-Abdeckung, schützen Sie dann privilegierte Konten und ergänzen Sie anschließend Governance. Lücken in einem der drei Bereiche werden zu Angriffspfaden.