Set up access for each trust situation

Your organization decides who may access which data, from where, and on which device. The data service enforces that decision and gives you the evidence. This guide covers nine everyday situations, from the company PC and the personal device to the question “Why was this allowed?”, and shows where to set each one up in the admin app and how to check that it works.

The service tells requests apart by what it reliably knows at every sign-in: the person, the sign-in method (Windows account, personal key, SQL login), the individual key, the origin (the network of the address), and the time. Together with your rules, these decide whether a sign-in is allowed, needs a code, or is refused, and what it can reach afterward.

The service doesn't know the state of a device, such as whether it's managed or personal, encrypted, or protected by antivirus software. It tells devices apart by their own key and their origin, not by checking the device (see Notes). What the service establishes and what it doesn't is explained in Zero Trust and private devices.

1. Open Anmelderichtlinie (Sign-in policy) and choose Weitere (More) > Vorlagen der Richtlinie (Policy templates) > Büro ohne Code, außen mit Code (No code in the office, code from outside). Enter your company network, for example 10.0.0.0/8.
2. Open Personen und Schlüssel (People and keys) and choose Neue Person … (New person …). In the Anmeldung (Sign-in) step, choose the person's Windows-Konto (Windows account) and select their rules.

Check: Select the person and choose Weitere > Rechte (Permissions) > Anmeldung und Rechte … (Sign-in and permissions …). The Windows account's row shows “erlaubt” (allowed) in the company network and “Code nötig” (code required) from outside.

All steps, including a key for working from home: Set up a person's access by location.

1. Select the person and choose Weitere > Schlüssel (Keys) > Schlüssel ausstellen … (Issue key …). Name the key after the device, for example “Laptop privat”, purpose Arbeitsplatz (Workstation).
2. Expand the person, open the Schlüssel tab, and select the new key. In its form, set what should apply to this device: Nur lesen (Read-only), an early date under Läuft ab (UTC) (Expires (UTC)), and as restrictions a data source (Nur Datenquelle, Data source only) or a network (see Restrictions).
3. Pass the one-time link from the message on to the person.

With the sign-in policy from the previous section, the service asks for a code from outside.

Check: Anmeldung und Rechte … shows a row for this key, with the decision for each origin and the rule behind it.

Limits: The service knows that the device is personal only through this key. So issue one key per device: if a device is lost, you revoke only its key.

Background and limits in the data service: Admit private devices

1. Open Regeln (Rules) and choose Weitere > Neue Regel (New rule). Select Nur lesen (Read-only).
2. Choose Merkmal hinzufügen … (Add attribute) and add: Datenquelle (Data source) with the name of the data source, Objektart (Kind of object) views, and Methode (Method) GET.
3. Under Objekte (Objects), pick only the views brokers may see, for example a view of the contracts without health data.
4. Create the person, give them this rule, and issue a key as described under Personal device, with an expiration date.

Check: Anmeldung und Rechte … for the person; the tree under Regeln shows what the rule allows.

Limits: The service grants access to whole objects. Which customers and which columns a view shows is up to the database, through the view itself or row-level security in SQL Server. Keep sensitive columns out of the approved view. See Create a rule.

Background and limits in the data service: Restrict agents to their customers

• A report that reads every day: Issue a key with purpose Arbeitsplatz (Workstation), and in its form select Nur lesen (Read-only) and Ohne zweiten Faktor (Without second factor). Excel and Power BI can't ask for a code.
• A presentation: Issue a key with purpose Präsentation auf Abruf (On-demand presentation). It only reads, rests, and works only after you activate it for the hours of the meeting with Weitere > Schlüssel > Schlüssel freischalten … (Activate key …).

Check: On the Schlüssel tab, Zustand (State) shows “ruht” (resting) or “frei bis … UTC” (active until … UTC).

Limits: Whatever Excel or Power BI has loaded stays in the file on the device. The service controls access, not the copy. See Issue a presentation key and replace a lost key.

Background and limits in the data service: Separate reports from refresh

If a department has been using a shared SQL Server login whose password everyone knows, people now sign in as themselves, and the service switches to the shared login for them.

1. Open Identitäten (Identities) and choose Neu (New). Pick the Datenquelle (Data source), enter the Name zur Auswahl (Name to choose by), and choose the kind Sammelanmeldung (Login) (Shared login) with the login in SQL Server.
2. Expand the identity, open the Zuordnungen (Assignments) tab, and assign the people or the department's Windows group.

Check: In Protokoll (Log), on the Audit tab, every request shows the person and the identity.

See Set up database identities. A program without a person signs in with a service key, which is set in the service's configuration, not in this app.

Background and limits in the data service: Connect a line-of-business application

1. Create the person with Neue Person … and give them only the rules the job needs.
2. In their key's form, enter the end of the job under Läuft ab (UTC) (Expires (UTC)).
3. When the job ends, select the person and choose Weitere > Störung und Austritt (Problems and departures) > Person sperren … (Lock person …).

Check: On the Übersicht (Overview), the Schlüssel laufen ab (Keys expiring) card shows whose keys expire in the next 14 days. The Austritte und Sperren (Departures and locks) evidence report lists who was locked and when.

Background and limits in the data service: Grant temporary access

1. Expand the person, open the Schlüssel tab, and select the device's key.
2. Choose Weitere > Schlüssel > Schlüssel neu ausstellen … (Reissue key …): the old key is revoked, and the new one has the same settings. If the person won't get a replacement device, choose Schlüssel sperren … (Revoke key …) instead.
3. Choose Weitere > Darunter zeigen (Show below) > Sitzungen der Person (Person's sessions), select an open session of the device, and choose Weitere > Zweiter Faktor und Sitzung (Second factor and session) > Sitzung beenden (End session).

If several kinds of access are affected, Person sperren … revokes all keys and ends all sessions at once.

Check: The key's Zustand (State) shows “gesperrt” (revoked), and Gesperrt am (Revoked on) shows when, in UTC. See Revoke a key or lock a person.

Background and limits in the data service: Respond to a lost device

1. Open Anmeldungen (Sign-ins), go to the Hinweise (Hints) or Herkunft (Origin) tab, and select the network's row.
2. Choose Herkunft sperren … (Block origin …) and confirm.

As a general rule, allow Windows accounts and SQL logins only in the company network: Anmelderichtlinie, Weitere > Vorlagen der Richtlinie > Außen nur Schlüssel (Keys only from outside).

Check: The new sign-in rule appears under Anmelderichtlinie; Anmeldung und Rechte … shows “abgelehnt” (refused) for a person from this origin. See Review sign-ins and where they come from.

• In advance, for one person: Weitere > Rechte > Anmeldung und Rechte … shows, for each sign-in method and origin, whether a sign-in is allowed, needs a code, or is refused, and which rule causes that. The service calculates this the same way as for a real sign-in.
• After a refusal: Weitere > Störung und Austritt > Warum abgewiesen? … (Why rejected? …) shows the latest refusals with their cause and a fix.
• Who did what: Protokoll, on the Audit tab (accesses) and the Änderungsprotokoll (Change log) tab (who changed which rule and when).
• For auditors: Protokoll > Weitere > Nachweisberichte (Evidence reports): permissions overview, MFA coverage, departures and locks, and administrative changes, as an Excel file and a PDF.

See Create evidence reports.

Background and limits in the data service: Trace an access decision

Sign-in rules and rules take effect as soon as you save them. So check two or three typical people right afterward with Anmeldung und Rechte …, for example one in the office and one with a key from outside. Changing or deleting the rule takes effect just as quickly. For a rule that affects administration, keep a second sign-in open until the check has passed (see Define the sign-in policy).

Background and limits in the data service: Zero Trust and private devices

• Device state: The service doesn't check whether a device is managed, encrypted, or protected. If your policy requires that, you need device management (MDM) or a check in front of the service; in the service, you reflect the result through separate keys and networks.
• Local copies: The service decides which data a request receives. What an app stores afterward, such as an Excel file or an Access table, is outside its control.
• Origin: The service sees the address a request comes from. Behind a proxy, that address counts only if the proxy is listed as trusted in the service's configuration.
• Windows groups aren't known to Anmeldung und Rechte …: the service learns them only when someone signs in with Windows.
• Times are always in UTC.

• Set up a person's access by location
• Define the sign-in policy
• Create a person and issue a key
• Create a rule
• Revoke a key or lock a person
• Zero Trust and private devices
• Allow access while travelling