So vergeben Sie Zugang auf Zeit

Ein externer Dienstleister soll zwei Wochen lang Lagerdaten prüfen. Er bekommt keinen Zugang zum Firmennetz, nur zu dieser einen Datenbank, nur lesend, und nach den zwei Wochen soll nichts übrig bleiben, das noch wirkt.

Der Dienstleister wird eine Person mit eigener Regel und einem befristeten Schlüssel. Soll er nur zu verabredeten Zeiten arbeiten, ruht der Schlüssel und wird auf Abruf freigeschaltet.

1. Person anlegen (Persons, Name mit Firma) und den zweiten Faktor einrichten lassen (enroll-totp mit "delivery": "mail").
2. Regel zuordnen, nur lesend und nur auf die nötigen Sichten (siehe Rechte je Objekt).

3. Schlüssel ausstellen, befristet und auf Wunsch ruhend:

   { "person": "Dienstleister – Firma X", "label": "Prüfung Lager", "expiresAt": "2026-11-06T00:00:00Z",
     "readOnly": true, "databases": [ "lager" ], "onDemand": true, "delivery": "mail" }

4. Für einen Arbeitstag freischalten: activate-key mit { "id": "k…", "hours": 8 }; vorzeitig beenden mit deactivate-key.
5. Prüfen: explain-sign-in für die Person zeigt den Schlüssel außerhalb der Freischaltung als rests; PersonalKeys zeigt Status „ruht“ bzw. „frei bis …“.
6. Am Ende die Person sperren (Enabled = false). Löschen lässt sie sich nicht, sobald sie Spuren hinterlassen hat; so bleibt im Protokoll nachvollziehbar, wer was getan hat.

Ergebnis: Der Dienstleister erreicht nur die Lagerdaten, nur lesend, nur in freigeschalteten Stunden und spätestens bis zum 6. November.

• Ablauf ohne Zutun. Ein abgelaufener Schlüssel öffnet nichts mehr, auch wenn ihn niemand sperrt.
• Höchstlaufzeit. Länger als Gateway:Store:MaxKeyLifetimeDays lässt sich kein Schlüssel ausstellen.
• Anmelderegeln gelten auch für den Dienstleister; nennt eine Regel Länder oder Netze, prüfen Sie mit explain-sign-in seine Herkunft.

• HTTP: Anmeldung – Schlüssel auf Abruf
• So reagieren Sie auf ein verlorenes Gerät
• Zero Trust und private Geräte