Anmeldung und Authentifizierung

Überblick — was dieser Mechanismus leistet

InfraGuard besitzt zwei Authentifizierungsebenen:

1. Web-Konsole = Sitzungsanmeldung. Ein Betreiber meldet sich mit login_id + password an, und AuthController legt eine eigene Sitzung an. Jede Konsolenseite läuft danach durch die Middleware infr.auth (InfrAuth), die die Sitzung prüft und bei jeder Anfrage Stufe, Name und Sprache des Benutzers erneut aus der Datenbank liest, damit die Kopie in der Sitzung aktuell bleibt.
2. Externe Ingest-API = zustandsloser API-Schlüssel als Bearer. Wenn eine externe Anwendung Vorfälle, Sicherungsmeldungen oder Sicherheitsscans meldet, authentifiziert sie sich über die Middleware infr.apikey mit einem API-Schlüssel-Token (Authorization: Bearer … oder X-Infr-Api-Key) — nicht mit einer Sitzung. Keine Sitzung, kein CSRF.

Wesentliche Eigenschaften:

• Sitzungsabgleich — ändert eine Administratorin Stufe, Name oder Sprache eines Benutzers, wirkt das ab der nächsten Anfrage, ohne erneute Anmeldung.
• Durchsetzung auf URL-Ebene — Menüeinträge auszublenden genügt nicht. Routengruppen wie /security, /backup und /admin erzwingen die Mindeststufe mit der Middleware infr.level:N direkt an der URL.
• Destruktive Aktionen = erneute Stufenprüfung + Audit — Sperren, Wiederherstellen, Einstellungen ändern usw. sind durch eine Schreibstufen-Schranke, einen Eintrag in infr_audit_log und eine Bestätigung in der Oberfläche geschützt.

Wann Sie das nutzen

• Sie melden sich zum ersten Mal an der Konsole an oder wurden plötzlich zu /login zurückgeworfen und möchten wissen, warum.
• Sie binden eine externe Laravel-Anwendung an die Vorfall-Ingest-API oder an die Anbindung der Sicherungsrückmeldung an und müssen wissen, welcher Header sie authentifiziert.
• Eine Administratorin hat Stufe, Name oder Sprache geändert und Sie müssen erklären, warum keine erneute Anmeldung nötig ist.

Aufbau

Der Anmeldebildschirm (/login) besteht aus einer einzigen schlichten Karte.

Das Anmeldeformular trägt ein normales Blade-Token @csrf. Die Konsole ist durch Sitzung + CSRF geschützt und verlangt in der Oberfläche kein zusätzliches Bearer-Token.

Verwendung

Anmelden

1. Rufen Sie /login auf (sind Sie bereits angemeldet, werden Sie zu / weitergeleitet).
2. Geben Sie Ihre Login ID und Ihr Password ein.
   • Prüfung: login_id höchstens 60 Zeichen, password 4–120 Zeichen.
3. Klicken Sie auf Anmelden. Der Server sucht das Konto in infr_user über login_id + is_close=0 und prüft das Passwort.
4. Bei Erfolg wird die Sitzung neu erzeugt (session()->regenerate()) und Sie werden zu next (oder /) geschickt.

Eine erfolgreiche Anmeldung füllt diese Sitzungsschlüssel:

Zusätzlich wird die Spalte last_log mit der aktuellen Zeit gestempelt.

Abmelden

• Nutzen Sie den Eintrag Abmelden im Benutzermenü der Kopfleiste (oder POST /logout).
• Der Server verwirft infr_user_id, macht die Sitzung ungültig, erzeugt das CSRF-Token neu und leitet zu /login weiter.

Sitzungsdauer und Abgleich bei jeder Anfrage

Jede Konsolenseite läuft durch infr.auth (InfrAuth), das bei jeder Anfrage:

1. den Benutzer über die Sitzungsangabe infr_user_id neu lädt (heißer Pfad, minimale Spalten: id · login_id · name · email · user_level · role_id · team_id · lang · avatar · is_close).
2. Fehlt das Konto oder steht es auf is_close=1 (deaktiviert), verwirft es die Sitzung und leitet zu /login weiter (oder gibt JSON 401 zurück).
3. infr_user_level · infr_name · infr_lang mit den Werten aus der Datenbank überschreibt — so wirkt eine von der Administratorin geänderte Stufe, ein Name oder eine Sprache ab der nächsten Anfrage ohne erneute Anmeldung.
4. das Benutzermodell im Anfrage-Attribut infr_user ablegt und die Anzeigesprache über app()->setLocale() setzt.
5. OpsPolicy::markPresence() aufruft, um die Anwesenheit festzuhalten (der Sparmodus der Betriebsrichtlinie entscheidet damit, ob „gerade jemand an der Konsole arbeitet“, und steuert so die Datenbankerfassung — siehe Betriebsrichtlinie).

Die Sitzungsdauer richtet sich nach SESSION_LIFETIME (Vorgabe 120 Minuten).

Die Konsolenanmeldung hat kein eigenes Kontrollkästchen „Angemeldet bleiben“. Die Sitzung hält die oben genannte Dauer; danach müssen Sie sich erneut anmelden.

Authentifizierung der externen Ingest-API (Bearer-Schlüssel)

Meldet eine externe Anwendung an /api/v1/*, authentifiziert sie sich mit einem API-Schlüssel (zustandslos — keine Sitzung, kein CSRF).

Verhalten:

• Der Server wandelt das empfangene Token in einen Hash um und vergleicht ihn in konstanter Zeit (mit einem zeitkonstanten Vergleich) mit infr_api_key.key_hash (nur aktive Schlüssel). Der Schlüssel im Klartext wird nie gespeichert.
• Ratenbegrenzung von 120 Anfragen pro Minute je Schlüssel. Wird sie überschritten, kommt 429 rate_limited samt Header Retry-After zurück.
• Jeder Aufruf stempelt last_used_at · last_used_ip · use_count.

Wichtige Endpunkte:

# Erreichbarkeit / Schlüssel prüfen
curl -sS https://infraguard.example.com/api/v1/ping \
  -H "Authorization: Bearer YOUR_KEY"

# Vorfall automatisch anlegen (dedupliziert · source=pulse)
curl -sS -X POST https://infraguard.example.com/api/v1/incidents \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"NPE in checkout","fingerprint":"abc123","severity":"crit"}'

Schlüssel ausstellen, widerrufen und den Integrationscode kopieren Sie in Verwaltung ▸ API-Schlüssel (der Klartextschlüssel wird nur einmal bei der Ausstellung gezeigt).

Step-up — destruktive Aktionen absichern

Riskante Aktionen wie Sperren, Freigeben, Wiederherstellen oder Einstellungen ändern sind geschützt — nicht durch erneute Passworteingabe — sondern durch drei Verteidigungslinien:

1. Erneute Stufenprüfung — Schreibaktionen erfordern mindestens die Schreibstufe (2+), administrative Aktionen die Adminstufe (10); beides wird serverseitig erneut geprüft.
2. Audit-Protokoll — die Werte vor und nach der Änderung sowie handelnde Person und IP werden in das Audit-Protokoll (infr_audit_log) geschrieben.
3. Bestätigung in der Oberfläche — ein Bestätigungsdialog (Step-up) sichert die Aktion in der Oberfläche ab.

Datenquellen

Die Spalte infr_user.password erscheint niemals in Protokollen, URLs oder Cookies. Der Klartext eines API-Schlüssels wird nur bei der Ausstellung gezeigt; die Datenbank behält allein den Hash.

Zugriff

• /login · /logout — für jeden erreichbar (Gast).
• Gesamte Konsole — erfordert eine gültige Sitzung (infr.auth). Ohne sie werden Seitenanfragen zu /login umgeleitet und AJAX-Anfragen erhalten 401 unauthenticated.

Schranken auf URL-Ebene (werden nach der Anmeldung ausgewertet):

Stufenabstufung: demo=1 · staff=5 · admin=10. Die vollständige Richtlinie finden Sie unter Zugriffsstufen.

Fehlerbehebung und FAQ

Ich melde mich an, lande aber immer wieder auf /login. Das Sitzungscookie wird nicht gespeichert (Domain bzw. SESSION_DOMAIN passt nicht, oder ein reines HTTPS-Cookie wird über HTTP ausgeliefert), oder das Konto wurde auf is_close=1 (deaktiviert) gesetzt. Lassen Sie den Kontostatus von einer Administratorin prüfen.

Ich sehe „Diese Zugangsdaten stimmen nicht mit unseren Aufzeichnungen überein.“ Ein Tippfehler in login_id, ein falsches Passwort oder ein deaktiviertes Konto (is_close=1). Aus Sicherheitsgründen nennt die Meldung nicht, welcher Fall vorliegt.

Ein Konto kann sich nicht anmelden. Das Passwort ist möglicherweise falsch oder das Konto deaktiviert. Eine Administratorin setzt das Passwort unter Benutzer und Teams zurück.

Ich kann mich anmelden, aber /admin nicht öffnen. Ihre Stufe liegt unter 10. /admin wird von infr.level:10 bewacht, also gelangen nur Administratoren hinein. Ebenso erfordern /security und /backup Stufe 2 oder höher.

Ein AJAX-Aufruf liefert 401. Die Konsolensitzung ist abgelaufen. Laden Sie die Seite neu und melden Sie sich erneut an. JSON-Anfragen erhalten statt einer Weiterleitung {"error":"unauthenticated"} mit 401.

Eine Administratorin hat meine Stufe angehoben, es wirkt aber nicht. InfrAuth gleicht die Sitzung bei jeder Anfrage ab, es wirkt also ab dem nächsten Seitenwechsel — ohne erneute Anmeldung. Laden Sie neu, damit es sofort greift.

Menü bzw. Oberfläche erscheinen in einer unerwarteten Sprache. Die Anzeigesprache folgt infr_user.lang (Sitzungsschlüssel infr_lang) und wird bei jeder Anfrage abgeglichen. Ändern Sie sie unter Lokalisierung.

Die API liefert 401 invalid_api_key / 429 rate_limited. Ein inaktiver oder falsch geschriebener Schlüssel ergibt 401; mehr als 120 Anfragen pro Minute ergeben 429 (+ Retry-After). Prüfen Sie den Schlüsselstatus unter API-Schlüssel und drosseln Sie die Aufrufe.

Verwandte Themen

• Zugriffsstufen — user_level ↔ min_req, Abstufungen demo/staff/admin
• Rollen und Teams — Rollenumfang und Team-Eigentümerschaft
• Verwaltung von Benutzern und Teams — Konten anlegen, Passwörter zurücksetzen, deaktivieren
• API-Schlüssel — Ingest-API-Schlüssel ausstellen und Integrationscode
• Lokalisierung — Anzeigesprache und Locale-Rückfall
• Audit-Protokoll — destruktive Aktionen nachverfolgen