Erstellen von Anwendungsrollen in SQL Server (ADO.NET)

Artikel
08/21/2008

Aktualisiert: November 2007

Anwendungsrollen bieten die Möglichkeit, einer Anwendung anstelle von Datenbankrollen oder Benutzern Berechtigungen zuzuweisen. Benutzer können eine Verbindung mit der Datenbank herstellen, die Anwendungsrolle aktivieren und die der Anwendung erteilten Berechtigungen annehmen. Die der Anwendungsrolle gewährten Berechtigungen sind so lange in Kraft, wie die Verbindung besteht.

Sicherheitshinweis:
Anwendungsrollen werden aktiviert, wenn eine Clientanwendung in der Verbindungszeichenfolge einen Anwendungsrollennamen und ein Kennwort bereitstellt. In 2-Ebenen-Anwendungen stellen Anwendungsrollen ein Sicherheitsrisiko dar, weil das Kennwort auf dem Clientcomputer gespeichert werden muss. In 3-Ebenen-Anwendungen können Sie das Kennwort so speichern, dass die Benutzer der Anwendung nicht darauf zugreifen können.

Anwendungsrollen werden aktiviert, wenn eine Clientanwendung in der Verbindungszeichenfolge einen Anwendungsrollennamen und ein Kennwort bereitstellt. In 2-Ebenen-Anwendungen stellen Anwendungsrollen ein Sicherheitsrisiko dar, weil das Kennwort auf dem Clientcomputer gespeichert werden muss. In 3-Ebenen-Anwendungen können Sie das Kennwort so speichern, dass die Benutzer der Anwendung nicht darauf zugreifen können.

Features der Anwendungsrollen

Anwendungsrollen weisen die folgenden Features auf:

Im Unterschied zu Datenbankrollen enthalten Anwendungsrollen keine Member.
Anwendungsrollen werden aktiviert, wenn eine Anwendung der gespeicherten Systemprozedur sp_setapprole einen Anwendungsrollennamen und ein Kennwort bereitstellt.
Das Kennwort muss auf dem Clientcomputer gespeichert und zur Laufzeit bereitgestellt werden. Die Aktivierung der Anwendungsrolle von SQL Server aus ist nicht möglich.
Das Kennwort wird nicht verschlüsselt. Mit Einführung von SQL Server 2005 wird das Parameterkennwort als unidirektionaler Hash gespeichert.
Einmal aktiviert, bleiben durch die Anwendungsrolle abgerufene Berechtigungen für die gesamte Dauer der Verbindung wirksam.
In SQL Server 2000 kann der Ausführungskontext nicht wieder auf den ursprünglichen Aufrufer zurückgewechselt werden. Um Anwendungsrollen verwenden zu können, müssen Sie daher das Verbindungspooling deaktivieren. Weitere Informationen dazu finden Sie unter SQL Server-Verbindungspooling (ADO.NET).
Die Anwendungsrolle erbt die der Rolle public gewährten Berechtigungen.
Wenn ein Member der festen Serverrolle sysadmin eine Anwendungsrolle aktiviert, wechselt der Sicherheitskontext für die Dauer der Verbindung zum Sicherheitskontext der Anwendungsrolle.
Wenn Sie in einer Datenbank ein guest-Konto erstellen, das eine Anwendungsrolle besitzt, müssen Sie kein Datenbankbenutzerkonto für die Anwendungsrolle oder für eine der Anmeldungen erstellen, die die Rolle aufrufen. Anwendungsrollen können auf eine andere Datenbank nur direkt zugreifen, wenn in dieser anderen Datenbank ein guest-Konto vorhanden ist.
Integrierte Funktionen, die Anmeldenamen, z. B. SYSTEM_USER, zurückgeben, geben den Namen der Anmeldung zurück, die die Anwendungsrolle aufgerufen hat. Integrierte Funktionen, die Datenbankbenutzernamen zurückgeben, geben den Namen der Anwendungsrolle zurück.

Das Prinzip der minimalen Rechtegewährung

Anwendungsrollen sollten immer nur die unbedingt notwendigen Berechtigungen gewährt werden, um so für den Fall vorzusorgen, dass das Kennwort in die falschen Hände gerät. Berechtigungen für die Rolle public sollten in allen Datenbanken, die eine Anwendungsrolle verwenden, widerrufen werden. Deaktivieren Sie das guest-Konto in allen Datenbanken, auf die Inhaber der Anwendungsrolle keinen Zugriff haben sollen.

Verbesserungen bei den Anwendungsrollen

Mit Einführung von SQL Server 2005 kann der Ausführungskontext wieder auf den ursprünglichen Anrufer zurückgewechselt werden, nachdem eine Anwendungsrolle aktiviert wurde, sodass das Verbindungspooling nicht mehr deaktiviert werden muss. Die sp_setapprole-Prozedur verfügt über eine neue Option, die ein Cookie erstellt, das Kontextinformationen zum Aufrufer enthält. Sie können die Sitzung wiederherstellen, indem Sie die sp_unsetapprole-Prozedur aufrufen und ihr das Cookie übergeben.

Alternativen zu Anwendungsrollen

Anwendungsrollen sind von der Sicherheit eines Kennworts abhängig und stellen so ein potenzielles Sicherheitsrisiko dar. Kennwörter, die in den Anwendungscode eingebettet sind oder auf der Festplatte gespeichert werden, können leicht ausspioniert werden.

Ab SQL Server 2005 und höher können Sie die folgenden Alternativen in Erwägung ziehen.

Verwenden Sie Kontextwechsel mit der EXECUTE AS-Anweisung und deren Klauseln NO REVERT und WITH COOKIE. Sie können ein Benutzerkonto in einer Datenbank erstellen, das keiner Anmeldung zugeordnet ist. Anschließend weisen Sie diesem Konto Berechtigungen zu. Die Verwendung von EXECUTE AS mit einem login-less-Benutzer ist sicherer, da sie auf Berechtigungen und nicht auf dem Kennwort basiert. Weitere Informationen dazu finden Sie unter Anpassen von Berechtigungen mit Identitätswechsel in SQL Server (ADO.NET).
Signieren Sie gespeicherte Prozeduren mit Zertifikaten, die nur die Berechtigung gewähren, die zum Ausführen der Prozeduren notwendig ist. Weitere Informationen dazu finden Sie unter Signieren gespeicherter Prozeduren in SQL Server (ADO.NET).

Externe Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Ressource	Beschreibung
Anwendungsrollen in der SQL Server 2008-Onlinedokumentation	Beschreibt das Erstellen und Verwenden von Anwendungsrollen in SQL Server 2008.
Anwendungsrollen in der SQL Server 2005-Onlinedokumentation	Beschreibt das Erstellen und Verwenden von Anwendungsrollen in SQL Server 2005.
Einrichten von Anwendungssicherheit und Anwendungsrollen in der SQL Server 2000-Onlinedokumentation	Beschreibt das Erstellen und Verwenden von Anwendungsrollen in SQL Server 2000.