So stufen Sie den Zugang nach Lage ab

Dieselbe Person arbeitet im Büro, im Homeoffice ohne VPN, beim Kunden und unterwegs. Mit einer Anmelderichtlinie gilt für den Datenzugriff im Firmennetz die einfache Anmeldung und von außen zusätzlich ein Code – ohne zweite Konfiguration und ohne zweites Programm. Die Verwaltung verlangt den Code dagegen immer, auch im Büro.

Der Dienst unterscheidet Lagen allein nach der Herkunft einer Anfrage (Netzadresse, hinter einem vertrauten Proxy die weitergereichte Adresse) und dem Anmeldeverfahren; die Anmelderichtlinie verbindet beides. Alle Lagen erreichen den Dienst über HTTPS: Der unverschlüsselte HTTP-Port antwortet nur auf dem Server selbst (siehe HTTPS und Zertifikat).

Warum die Verwaltung immer einen Code verlangt. Die Verwaltung kann Personen, Schlüssel und Regeln ändern, also jeden anderen Zugang. Deshalb gilt für sie die feste Untergrenze Gateway:Store:RequireAdminTotp (Vorgabe true): ein Code bei jedem Anmeldeverfahren und jeder Herkunft. Eine Ausnahme für das Firmennetz in einer Anmelderegel ändert daran nichts. Abschalten lässt sich die Untergrenze nur in der Konfigurationsdatei des Servers (siehe Konfiguration); empfohlen ist das nicht.

1. Richten Sie HTTPS mit einem Zertifikat ein, dem die Clients vertrauen; siehe HTTPS und Zertifikat. Steht ein Proxy vor dem Dienst, tragen Sie ihn als vertrauenswürdig ein; sonst gälte jeder Aufrufer mit der Adresse des Proxys als „innen“.

2. Lassen Sie zuerst jede Person, die von außen arbeiten soll, ihren zweiten Faktor einrichten; siehe „So richten Sie den zweiten Faktor ein oder setzen ihn zurück“ (Dokumentation der Verwaltungsanwendung).

   Reihenfolge einhalten. Gilt die Code-Pflicht für Daten (Schritt 3) schon, bevor eine Person ihren Faktor hat, weist der Dienst sie von außen mit 403 ab, sobald ihre Einrichtungsfrist (TotpEnrolHours, Vorgabe 24 Stunden) abgelaufen ist. Im Firmennetz arbeitet sie weiter.

3. Öffnen Sie in der Verwaltungsanwendung Anmelderichtlinie, Register Anmelderegeln, und legen Sie die Regel für den Datenzugriff an, mit Ihrem Firmennetz als Ausnahme (except_from, hier 10.0.0.0/8); siehe „So legen Sie die Anmelderichtlinie fest“ (Dokumentation der Verwaltungsanwendung):

   Regel	Bereich	Verfahren	Wirkung	Ausnahme
   Daten mit persönlichem Schlüssel von außen nur mit Code	Data	PersonalKey	RequireTotp	10.0.0.0/8
   SQL-Anmeldungen nur im Firmennetz (optional)	All	SqlLogin	Deny	10.0.0.0/8

   Die Regel „Verwaltung nur mit zweitem Faktor“ (Bereich Admin), mit der jeder neue Speicher beginnt, lassen Sie unverändert; die Untergrenze verlangt den Code dort ohnehin.

4. Für eine Präsentation beim Kunden stellen Sie einen eigenen Schlüssel aus, statt einen persönlichen weiterzugeben: nur lesend und vom zweiten Faktor ausgenommen. In der Verwaltungsanwendung ist das ein Schlüssel „Präsentation“ auf Abruf, der nur für die Stunden des Termins freigeschaltet wird (siehe „So richten Sie den Zugang einer Person nach Ort ein“ (Dokumentation der Verwaltungsanwendung)). Über die Schnittstelle geht auch ein Schlüssel, der auf eine Datenbank beschränkt ist und am Ende des Tages abläuft:

   POST /admin/v1/issue-key
   Content-Type: application/json
    
   { "person": "Vertrieb Präsentation", "label": "Power BI beim Kunden", "readOnly": true,
     "totpExempt": true, "databases": [ "fachdaten" ], "expiresAt": "2026-10-08T18:00:00Z",
     "delivery": "link" }

5. Optional grenzen Sie den Datenzugriff auf Länder ein, etwa „nur aus Deutschland“. Das braucht eine geladene Geodatenbank (siehe So prüfen Sie Anmeldemuster und Herkunft). Nehmen Sie das Firmennetz über seine Adressen aus, denn eine Anfrage von dort hat kein Land, und legen Sie Regel und Ausnahmen in einem Schritt an:

   POST /admin/v1/save-sign-in-rule
   Content-Type: application/json
    
   { "scope": "Data", "effect": "Deny", "label": "nur Deutschland",
     "exceptCountries": [ "DE" ], "exceptFrom": [ "10.0.0.0/8" ],
     "exceptions": [ { "persons": [ "Frank Mustermann" ], "countries": [ "TH" ],
                       "until": "2026-11-02T00:00:00Z", "label": "Urlaub" } ] }

   Die Ausnahme lässt Frank Mustermann bis zum 2. November auch aus Thailand zu und endet von selbst. Was für ihn in Thailand gilt, zeigt explain-sign-in mit einer Herkunft { "name": "Thailand", "address": null, "country": "TH" }; Einzelheiten unter Befristete Ausnahmen.

6. Prüfen Sie von außen (Mobilfunk oder ein Netz außerhalb der Ausnahme): Der Datenzugriff mit persönlichem Schlüssel verlangt einen Code, im Büro nicht. In der Verwaltungsanwendung zeigt Anmeldung und Rechte einer Person dasselbe für jede Herkunft, ohne dass sie sich anmelden muss.

Rückweg. Sperrt eine Regel Personen aus, die nicht gemeint waren, schalten Sie die Regel in der Verwaltungsanwendung aus. Ist auch die Verwaltung betroffen, entfernt der Befehl remove-sign-in-rule die Regel am Server (siehe Befehle am Server).

• Unbekannte Herkunft liegt im Bereich jeder Regel – eine Anfrage, deren Herkunft der Dienst nicht feststellen kann, gilt also nicht als „innen“.
• Ein Land ist nur ein Hinweis. Ein VPN, ein Proxy oder ein Mobilfunknetz verlegt die Herkunft in ein anderes Land. Eine Regel nach Land ergänzt Schlüssel, Netze und zweiten Faktor; sie ersetzt sie nicht. Ein Land, das sich nicht feststellen lässt, gilt nicht als „Deutschland“.
• Nach der Präsentation den Berichtsschlüssel sperren oder ablaufen lassen.
• Im Zug dauert die Anmeldung der Verwaltungsanwendung länger, vor allem weil sie dabei ihre Mengen verknüpft. Abgebrochene Verbindungen wiederholt der Treiber selbst.

• „So richten Sie den Zugang einer Person nach Ort ein“ (Dokumentation der Verwaltungsanwendung) – dasselbe in der Verwaltungsanwendung, in acht Schritten
• HTTP: Anmelderichtlinie und zweiter Faktor