So lassen Sie private Geräte zu

Eine Person arbeitet auch vom eigenen Laptop aus, ohne Domäne und ohne Geräteverwaltung. Sie soll dort nur erreichen, was sie unterwegs braucht, mit einem Code aus der Authenticator-App, und der Zugang soll sich jederzeit einzeln entziehen lassen, ohne ihren Firmen-PC zu berühren.

Der Dienst erkennt ein privates Gerät nicht als solches (siehe Zero Trust und private Geräte). Er unterscheidet aber das Anmeldeverfahren: Der Firmen-PC meldet sich mit dem Windows-Konto an, das private Gerät mit einem eigenen persönlichen Schlüssel. Diesen Schlüssel schränken Sie auf das Nötige ein, und eine Anmelderegel verlangt für persönliche Schlüssel außerhalb des Firmennetzes den zweiten Faktor.

1. Zweiten Faktor der Person einrichten, falls noch nicht geschehen: enroll-totp der Verwaltungsschnittstelle mit "delivery": "link" oder "mail", oder die Person richtet ihn bei der ersten Anmeldung selbst ein.

2. Schlüssel ausstellen mit issue-key:

   { "person": "Erika Muster", "label": "Privater Laptop", "expiresAt": "2027-03-31T00:00:00Z",
     "readOnly": true, "databases": [ "fachdaten" ], "delivery": "link" }

   Rechte entstehen nur aus den Regeln der Person; der Schlüssel schränkt sie ein und erweitert nie.

3. Anmelderegel anlegen mit save-sign-in-rule, falls es sie noch nicht gibt:

   { "scope": "Data", "method": "PersonalKey", "effect": "RequireTotp",
     "label": "Schlüssel von außen nur mit Code", "exceptFrom": [ "10.0.0.0/8" ] }

   Tragen Sie unter exceptFrom Ihre Firmennetze ein. Vorher mit explain-sign-in prüfen, siehe Eine Regel vor dem Scharfschalten prüfen.

4. Auf dem Laptop eintragen: im ODBC-Treiber (Access) als Schlüssel; vor der ersten Abfrage fragt der Treiber in einem Dialog nach dem Code und hält die Sitzung für den Prozess. Excel und Power BI können keinen Code abfragen: Für sie stellen Sie einen eigenen, nur lesenden Schlüssel mit Ausnahme vom Code aus, siehe Berichte und Aktualisierung trennen.
5. Prüfen: explain-sign-in für die Person mit einer Herkunft aus dem Internet zeigt beim neuen Schlüssel code. Nach der ersten echten Anmeldung steht das Ereignis in SignInEvents mit Method = personalKey und Outcome = totpSuccess; in PersonalKeys zeigt der Schlüssel „zuletzt benutzt“ mit Herkunft.

Ergebnis: Der Laptop erreicht nur den Alias fachdaten, nur lesend, nur mit Code von außen, bis zum Ablauf. Der Firmen-PC der Person ist davon nicht betroffen.

• Was auf dem Laptop bleibt, steuert der Dienst nicht. Abgerufene Daten liegen dort in Excel, Power BI oder Access. Wo das nicht sein darf, geben Sie nur Sichten frei, die schutzwürdige Spalten weglassen (siehe Vermittler auf ihre Kunden beschränken).
• Ein Schlüssel je Gerät. Geht der Laptop verloren, sperren Sie nur diesen Schlüssel, siehe Auf ein verlorenes Gerät reagieren.
• Netze am Schlüssel (from) binden einen Schlüssel an bekannte Netze, etwa das Heimnetz mit fester Adresse. Für Laptops unterwegs passt das selten.
• Selbstbedienung: Personen können sich eigene Schlüssel selbst ausstellen; diese laufen immer ab und können weder Netze noch die Ausnahme vom Code setzen (siehe Anmeldung).
• Die Klickwege in der Verwaltungsanwendung beschreibt das „Administrator-Handbuch für WKL Database Gateway Manager“ (Dokumentation der Verwaltungsanwendung).

• Zero Trust und private Geräte
• So stufen Sie den Zugang nach Lage ab
• HTTP: Anmeldung (Referenz)