Worum es geht
Ein IT-Projekt mit KI ist bewusst nicht öffentlich – wer rein will, braucht einen
eigenen Login (siehe PHP-Session-Login). Am Anfang war jeder neue
Zugang Handarbeit: Passwort ausdenken, Hash erzeugen, Datei hochladen,
Mail tippen, irgendwo notieren. Fehleranfällig und jedes Mal gleich.
Daraus ist ein wiederholbarer Ablauf geworden: Aus einem
einzigen Satz („Leg dieser Person einen Zugang an") erledigt Claude
alle Schritte am Stück – vom sicheren Passwort über das Live-Schalten bis
zur fertig versendeten Zugangs-Mail und der Dokumentation. Derselbe Ablauf
deckt drei Fälle ab: neuen Account anlegen,
Passwörter rotieren und Gastzugänge vorbereiten.
Die Schritte
- 1 · Account & Passwort: ein zufälliges 20-Zeichen-Passwort erzeugen, als bcrypt-Hash (Cost 12) in die Userliste von
der Zugangsschutz über PHP-Sitzungen eintragen – Klartext kommt nie in die Datei
- 2 · Live schalten:
der Zugangsschutz über PHP-Sitzungen per SFTP ins /web-Verzeichnis der NAS schieben (über die SFTP-Integration zu Synology NAS) – ab da gilt der neue Login
- 3 · Verifizieren: den Login end-to-end nachspielen (ohne Cookie ⇒ 401, korrekter POST ⇒ 302, Folge-Request ⇒ 200) und prüfen, dass alte/rotierte Passwörter nicht mehr greifen
- 4 · Mail: die Zugangs-Mail mit Standard-Signatur über die Outlook-Anbindung erzeugen – an benannte Empfänger direkt versendet, für Gastzugänge als fertiger Entwurf zum Weiterleiten
- 5 · Dokumentieren: Zugangsdaten + Empfänger auf der zugriffsbeschränkten Confluence-Seite festhalten und ein Jira-Ticket als Audit-Spur anlegen
Was den Ablauf trägt
- Sichere Passwörter by default: zufällig generiert, 20 Zeichen, sofort als bcrypt-Hash – nicht selbst ausgedacht, nicht im Klartext im Code
- Getrennte Auth-Welt: die Web-Accounts sind reine Hash-Einträge, keine NAS-/DSM-/SFTP-Konten – ein geleaktes Web-Passwort öffnet maximal die ohnehin private Webseite
- Ein Ort für Klartext: Passwörter stehen ausschließlich auf der zugriffsbeschränkten Confluence-Seite – nicht im Git-Repo, nicht in der Mail-History länger als nötig
- Mail mit Signatur, automatisch: Versand über die Outlook-Anbindung mit fester Resultment-Signatur – kein Copy-&-Paste, keine vergessene Anrede
- Audit-Spur in Jira: jede Anlage/Rotation bekommt ein Ticket – nachvollziehbar, wer wann welchen Zugang erhalten oder erneuert hat
- Vorbereitete Gastzugänge: zwei generische Gast-Logins mit fertiger Mail-Vorlage – zum schnellen, kontrollierten Weiterleiten an Interessierte
Drei Fälle, ein Ablauf
- Neuer Account: Person + E-Mail nennen ⇒ Login angelegt, Willkommens-Mail mit Zugangsdaten versendet
- Passwort-Rotation: bestehende Logins bekommen neue Passwörter, die alten werden ungültig, betroffene Personen werden per Mail informiert
- Gastzugang: generischer Login ohne festen Empfänger, Mail-Vorlage liegt als Entwurf bereit – ideal zum Weiterreichen
Grenzen & Skalierungspfad
Der Ablauf ist für einen kleinen, kontrollierten Personenkreis gemacht
(Handvoll Logins). Bewusst nicht dabei: Selbst-Registrierung,
automatischer Passwort-Reset, abgestufte Rollen/Rechte – das wären eigene
Subsysteme. Wenn die Nutzerzahl wächst, wandert die Userliste aus
der Zugangsschutz über PHP-Sitzungen in eine kleine Datenbank oder an einen externen
Login-Anbieter (OIDC); der Provisioning-Ablauf selbst – Passwort,
Verifikation, Mail, Doku – bleibt dabei gleich. Mehr zum Auth-Layer
darunter: Baustein PHP-Session-Login.
Eingesetzt in
← zurück zur Baustein-Übersicht