So reagieren Sie auf ein verlorenes Gerät

Eine Mitarbeiterin meldet, dass ihr Laptop im Zug liegen geblieben ist; auf ihm sind ein persönlicher Schlüssel in Excel und eine Access-Anwendung mit dem ODBC-Treiber eingerichtet. Ihr Telefon mit der Authenticator-App hat sie noch. Der Zugang von diesem Laptop soll sofort enden, ihre übrige Arbeit nicht.

Je nachdem, was verloren ist, entziehen Sie unterschiedlich viel. Alles wirkt ab der nächsten Anfrage, ohne Neustart.

1. Schlüssel des Geräts finden: PersonalKeys mit $filter=Person eq 'Erika Muster'; die Bezeichnung (etwa „Privater Laptop“) und „zuletzt benutzt“ mit Herkunft zeigen, welcher es ist.
2. Sperren: PATCH /admin/v1/odata/PersonalKeys('k…') mit { "Revoked": true } und der gelesenen Version in If-Match. Eine Sperre lässt sich nicht aufheben.
3. Sitzungen beenden: SessionTokens mit $filter=Person eq 'Erika Muster' and Revoked eq false lesen und je Sitzung { "Revoked": true } setzen. So endet auch ein Code, der auf dem Laptop noch gilt.
4. Telefon verloren: reset-totp mit { "person": "Erika Muster" }; die Person richtet den Faktor bei der nächsten Anmeldung neu ein.
5. Prüfen: Ein Versuch mit dem gesperrten Schlüssel erscheint in SignInEvents mit Outcome = refused und Reason = revoked. Kommt er von einer unbekannten Herkunft, ist das ein Hinweis auf Missbrauch.

Ergebnis: Der Laptop erreicht nichts mehr; Firmen-PC und andere Schlüssel der Person arbeiten weiter.

• Daten auf dem Gerät – eine Excel-Datei, eine Access-Datenbank mit Kopien – erreicht der Dienst nicht. Ob sie verschlüsselt sind, entscheidet die Verwaltung der Geräte.
• Ein Schlüssel je Gerät macht diesen Fall klein: Sie sperren einen Schlüssel statt aller.
• Alle Schritte stehen im Änderungsprotokoll mit Akteur und Zeit.

• So lassen Sie private Geräte zu
• So prüfen Sie Anmeldemuster und Herkunft
• Zero Trust und private Geräte