So richten Sie Datenbank-Identitäten ein

In vielen Datenbanken haben Personen keine eigenen Berechtigungen, sondern arbeiten über eine gemeinsame Anmeldung je Abteilung, etwa vertrieb, deren Kennwort alle kennen. Mit Datenbank-Identitäten meldet sich jede Person als sie selbst an, und der Dienst wechselt für sie auf die gemeinsame Anmeldung – das Kennwort braucht niemand mehr, und der Dienst weiß weiter, wer gehandelt hat.

Im Bereich Identitäten legen Sie je Datenquelle die Identitäten an, unter denen Anfragen laufen dürfen, und in ihrer Detailliste „Zuordnungen“, wer sie annehmen darf: eine Person, ein Windows-Konto, eine Windows-Gruppe oder ein einzelner Schlüssel.

Voraussetzung in SQL Server (Sache des Datenbankverantwortlichen): Die gemeinsame Anmeldung gibt es, sie hat ihre Berechtigungen, und die Anmeldung der Datenquelle darf auf sie wechseln:

GRANT IMPERSONATE ON LOGIN::[vertrieb] TO [<Anmeldung der Datenquelle>];

Was diese Berechtigung bedeutet. IMPERSONATE erlaubt der Anmeldung der Datenquelle, mit EXECUTE AS LOGIN als vertrieb zu arbeiten – mit allen Berechtigungen von vertrieb und ohne dessen Kennwort (Microsoft: „GRANT Server Principal Permissions (Transact-SQL)“, https://learn.microsoft.com/sql/t-sql/statements/grant-server-principal-permissions-transact-sql, und „EXECUTE AS (Transact-SQL)“, https://learn.microsoft.com/sql/t-sql/statements/execute-as-transact-sql). Das gilt in SQL Server, nicht nur über den Datendienst: Wer die Anmeldedaten der Datenquelle kennt, kann jede Anmeldung annehmen, auf die sie wechseln darf. Daraus folgt:

• Gewähren Sie IMPERSONATE nur auf die gemeinsamen Anmeldungen, die eine Identität wirklich braucht, nie auf Anmeldungen mit Serverrollen wie sysadmin.
• Die Anmeldedaten der Datenquelle stehen verschlüsselt im Verwaltungsspeicher; außerhalb davon kennt sie am besten niemand (siehe So binden Sie eine Datenquelle an).
• Die Sperrliste (unten) ist die zweite Sicherung: Was darauf steht, nimmt der Dienst auch dann nicht an, wenn SQL Server den Wechsel erlauben würde.

1. Öffnen Sie Identitäten, wählen Sie Neue Datenbank-Identität aus und füllen Sie die Maske rechts aus:

   Feld	Eintrag
   Datenquelle	aus der Liste wählen
   Name zur Auswahl (ROLE=)	Der Name, mit dem eine Person die Identität wählt, etwa vertrieb; je Datenquelle eindeutig
   Art	Sammelanmeldung (Login): Wechsel auf die Sammelanmeldung. Eigene Anmeldung der Person (Own): Wechsel auf die eigene Anmeldung der Person. Anmeldung der Datenquelle (Alias): kein Wechsel. Unter der Auswahl steht, was die gewählte Art bewirkt
   Sammelanmeldung	Nur bei Art Sammelanmeldung: die Anmeldung in SQL Server, etwa vertrieb
   Aktiv	Angehakt

2. Wechseln Sie zurück in die Liste. Bei Art Sammelanmeldung probiert der Dienst den Wechsel sofort aus und lehnt die Identität mit einer Meldung ab, wenn die Anmeldung fehlt, auf der Sperrliste steht, keinen Zugang zur Datenbank hat oder SQL Server den Wechsel verweigert.
3. Klappen Sie die Identität auf, Register Zuordnungen, und legen Sie je Berechtigtem eine Zeile an – in genau einer der Spalten Person, Windows-Konto oder -Gruppe oder Schlüssel. Person und Schlüssel wählen Sie aus einer Liste (Name der Person, Bezeichnung und Ende des Schlüssels); ein Windows-Konto oder eine Gruppe tragen Sie mit Namen ein.

Im Bild: (1) wer die Identität annehmen darf.

Ergebnis: Anfragen der zugeordneten Personen laufen unter der Sammelanmeldung. Das Audit nennt beide: … durch Erika Muster (k…) als vertrieb.

• Mehrere Identitäten je Person: Ohne Wahl gilt die Vorgabe-Identität der Person (Auswahlliste unter Personen und Schlüssel; sie bietet die Identitäten an, die der Person, ihren Schlüsseln oder ihrem Windows-Konto zugeordnet sind, über eine Windows-Gruppe zugeordnete nicht). Fehlt sie, lehnt der Dienst ab und nennt die möglichen. Im ODBC-Treiber wählt die Person mit ROLE= oder in einer Auswahlliste.
• Eine Identität je Access-Sitzung. Access teilt eine Verbindung zwischen allen verknüpften Tabellen eines Prozesses, deren Verbindungszeichenfolgen ohne Kennwort gleich sind; die Identität der ersten Verbindung gilt dann für alle. Das ist beobachtetes Verhalten von Access, von Microsoft nicht als Zusage dokumentiert. Für eine andere Identität Access neu starten.
• Sperrliste: Anmeldungen und Serverrollen auf der Sperrliste der Datenquelle nimmt der Dienst nie an, etwa sysadmin. Sie steht im Bereich Identitäten, Register Sperrliste Identitätswechsel, als Baum: je Eintrag die Datenquelle, darunter seine Merkmale. Einen Eintrag legen Sie auf diesem Register mit Neuer Sperreintrag an, seine Merkmale mit Weitere > Merkmal zum Sperreintrag hinzufügen … auf dem markierten Eintrag: login (Anmeldung, Name oder SID) oder role (Serverrolle), dazu wahlweise from oder except_from mit einem Netz.
• Ausschalten statt löschen: Der Haken Aktiv an Identität oder Zuordnung wirkt ab der nächsten Anfrage.
• In der Datenbank sichtbar: SESSION_CONTEXT(N'wkl.person') nennt die Person, SESSION_CONTEXT(N'wkl.role') die Identität – für Trigger und Spaltenvorgaben, die festhalten sollen, wer geändert hat.

• So ordnen Sie SQL-Anmeldungen zu
• So binden Sie eine Datenquelle an
• Referenz: Weitergabe der Identität und Datenbank-Identitäten (Referenz) (Dokumentation des Datendienstes)