Zero Trust und private Geräte

graph TD
    C["Client: Access, Excel, Power BI, Fachanwendung – Firmen-PC, privates Gerät, Dienstleister"] -->|"Anfrage mit Anmeldung"| S["Signale: Herkunft, Land, Anmeldeverfahren, Person, Schlüssel, zweiter Faktor"]
    S --> R["Anmelderichtlinie: ablehnen, Code verlangen oder nichts"]
    R --> A["Rechte: Alias, Objekt, Verb, nur lesen; Einschränkung des Schlüssels"]
    A --> D[("Datenbank: Sichten und Prozeduren für Zeilen und Spalten")]
    R --> L["Protokoll: Anmeldeereignis, Audit, Befunde, Änderungsprotokoll"]
    A --> L

Abbildung: Jede Anfrage durchläuft dieselbe Kette. Der Betreiber legt Richtlinie und Rechte fest; der Dienst setzt sie bei jeder Anfrage durch und hält fest, was er entschieden hat.

Der Datendienst bestimmt keine Geschäftspolitik. Ob ein privater Laptop Kundendaten sehen darf, ob ein Mitarbeiter aus dem Ausland arbeitet oder ein Dienstleister zwei Wochen Zugang bekommt, entscheidet der Betreiber. Der Dienst gibt ihm die Mittel, diese Entscheidungen einzustellen, bei jeder Anfrage durchzusetzen und hinterher nachzuweisen. Diese Seite zeigt, welche Signale der Dienst dafür hat, wie verlässlich sie sind, und wo seine Grenzen liegen.

Wichtige Funktionen

Kein Vertrauen aus dem Netz allein. Jede Anfrage trägt eine Anmeldung; das Firmennetz kann einen Code ersparen, ersetzt aber keine Anmeldung.
Zugang je Person und Zweck. Eine Person hat mehrere persönliche Schlüssel, je Gerät oder Zweck einen, jeder für sich eingeschränkt, befristet und sperrbar.
Richtlinie nach Lage. Anmelderegeln verlangen je Anmeldeverfahren, Netz, Land, Netzbetreiber, Programm, Uhrzeit, Person und Windows-Gruppe einen zweiten Faktor oder lehnen ab; Ausnahmen gelten auf Wunsch nur bis zu einem Zeitpunkt.
Geringste Rechte bis zum Objekt. Regeln nennen Aliasse, Objektarten, einzelne Objekte, Verben und „nur lesen“; Zeilen und Spalten begrenzt die Datenbank über Sichten, unter der Anmeldung der Person.
Entzug sofort. Gesperrte Schlüssel, abgeschaltete Personen und beendete Sitzungen wirken ab der nächsten Anfrage.
Nachweis. Anmeldeereignisse mit Herkunft und Grund, Audit je Anfrage, Befunde der Anmelderegeln und ein Änderungsprotokoll jeder Einstellung.

Grundkonzepte

Was der Dienst feststellt und was nicht

Der Dienst unterscheidet drei Arten von Angaben: was er an seiner eigenen Verbindung beobachtet, was ein Client nur behauptet und was eine vertrauenswürdige Stelle bestätigt. Behauptete Angaben taugen in Regeln nur zum Einschränken, nie allein als Ausnahme.

Angabe	Art	Als Regelbedingung	Grenze
Netzadresse der Anfrage (hinter einem vertrauten Proxy die weitergereichte)	beobachtet	ja: Netze, eigene Netze	Hinter NAT oder Proxy ist es dessen Adresse
Land und Netzbetreiber aus der Adresse	beobachtet, geschätzt	ja: Land, Netzbetreiber	VPN, Mobilfunk und Cloud-Ausgänge verlegen Land und Netzbetreiber
Anmeldeverfahren (Windows, persönlicher Schlüssel, SQL-Anmeldung, Dienstschlüssel)	bestätigt	ja	–
Person und Windows-Gruppen	bestätigt	ja	Gruppen nur bei Windows-Anmeldung
Zweiter Faktor (Code aus einer Authenticator-App)	bestätigt	ja	Besitz des Telefons, nicht des Geräts, das anfragt
Programm (`User-Agent`)	behauptet	ja, zum Einschränken; als Ausnahme allein befreit es jeden, der den Text sendet	Excel und Power BI Desktop senden denselben Text; jedes Programm kann sich als anderes ausgeben
Uhrzeit	beobachtet	ja: Zeitfenster	Zone von `Gateway:SignInLog:TimeZone`
Zustand des Geräts (verwaltet, verschlüsselt, Virenschutz aktuell)	–	nein	Der Dienst hat keine Verbindung zu einer Geräteverwaltung (MDM) oder einem Endpunktschutz

Der Dienst behauptet nichts über ein Gerät, das er nicht prüfen kann. Ein „privates Gerät“ erkennt er nicht als solches. Er kann aber unterscheiden, wie sich jemand anmeldet und von wo: Eine Windows-Anmeldung aus dem Firmennetz kommt in aller Regel von einem Firmen-PC in der Domäne; ein persönlicher Schlüssel aus dem Internet kann von jedem Gerät kommen. Genau diese Unterscheidung nutzen die Anleitungen unten.

Was der Dienst nicht steuert

Daten auf dem Gerät. Was ein Client einmal erhalten hat, liegt dort: in einer Excel-Datei, im Speicher von Power BI, in einer Access-Datenbank. Speichern, Kopieren und Drucken steuert der Dienst nicht; das ist Sache der Geräteverwaltung und der Anwendung.
Den Zustand des Telefons mit dem zweiten Faktor. Der Code beweist den Besitz der App, nicht dass das anfragende Gerät sicher ist.
Geschäftsregeln je Zeile. Ob ein Vermittler einen bestimmten Kunden sehen darf, entscheidet die Datenbank (Sicht, Prozedur), nicht eine zweite Regelwelt im Dienst; siehe Zeilenweise Einschränkung.

Alltagssituationen

Situation	Wichtigste Mittel	Anleitung
Verwalteter Firmen-PC	Windows-Anmeldung, Regeln nach Windows-Gruppe, Firmennetz	Windows-Anmeldung einrichten, Zugang nach Lage
Privater Laptop	eigener persönlicher Schlüssel, eingeschränkt, Code von außen	Private Geräte zulassen
Mitarbeiter im Ausland	Regel nach Land, befristete Ausnahme	Zugriff auf Reisen erlauben
Vermittler mit eigenem Gerät	Sicht je Vermittler, Regel auf die Sicht, befristeter Schlüssel	Vermittler auf ihre Kunden beschränken
Excel und Power BI	Schlüssel je Zweck, nur lesend, ein Alias	Berichte und Aktualisierung trennen
Access- und VBA-Fachanwendung	Person an SQL Server weitergeben, eigener Alias je Anwendung	Fachanwendung anbinden
Unbekanntes oder verdächtiges Gerät	Ablehnung nach Herkunft, Code, Befunde mit Meldung	Anmeldemuster prüfen
Dienstleister auf Zeit	Person mit befristetem Schlüssel, Schlüssel auf Abruf	Zugang auf Zeit vergeben
Verlorenes Gerät	Schlüssel sperren, Sitzungen beenden, Faktor zurücksetzen	Auf ein verlorenes Gerät reagieren
Prüfung durch Revision	Anmeldeereignis, Audit, Änderungsprotokoll, Erklärung der Richtlinie	Eine Zugriffsentscheidung nachvollziehen

Eine Regel vor dem Scharfschalten prüfen

Eine durchgesetzte Anmelderegel wirkt, sobald sie gespeichert ist. Eine neue Regel prüfen Sie deshalb im Probemodus:

Die Regel mit Mode = Report anlegen. Sie wird bei jeder Anmeldung beurteilt, ändert aber nichts.
Mit explain-sign-in für typische Personen und Herkünfte nachrechnen, was sie täte (tried).
Einige Tage echten Betrieb abwarten und in SignInRuleReports ansehen, wie viele Anmeldungen sie getroffen hätte, von wie vielen Personen und Herkünften. Die einzelnen Anmeldungen findet SignInEvents mit contains(Rules,'"mode":"report"').
Passt das Ergebnis, die Regel auf Enforce umschalten; sonst Bedingungen oder Ausnahmen anpassen und weiter erproben.

Einzelheiten unter Regel erproben.

Ablehnungen legen Sie mit save-sign-in-rule in einem Schritt samt Ausnahmen an, damit Sie sich nicht zwischen zwei Änderungen selbst aussperren (siehe Anmeldung).