Zuordnen von Remoteprinzipalen zu lokalen Prinzipalen

Die Service Broker-Dialogsicherheit verwendet Zertifikate zum Zuordnen von Remotevorgängen zu einem lokalen Sicherheitsprinzipal. In diesem Thema werden einige der Aspekte beschrieben, die bei der Auswahl eines lokalen Prinzipals, der einem Remotebenutzer zugeordnet werden soll, zu berücksichtigen sind.

Allgemeine Überlegungen

Der Zugriff auf SQL Server-Ressourcen findet innerhalb des Sicherheitskontexts eines Datenbankprinzipals statt. Die Service Broker-Dialogsicherheit verwendet die Remoteautorisierung, um den lokalen Sicherheitskontext zu ermitteln (d. h. den lokalen Datenbankprinzipal), innerhalb dessen die Nachrichten für einen bestimmten Dialog gesendet werden. Der lokale Sicherheitsprinzipal wird über das für die Konversation verwendete Zertifikat ermittelt. Weitere Informationen finden Sie unter Zertifikate für die Dialogsicherheit.

Der lokale Prinzipal benötigt lediglich die SEND-Berechtigung für den Dienst bzw. die Dienste, an den bzw. die der Prinzipal Nachrichten sendet. Der Prinzipal benötigt keine weiteren Berechtigungen in der Datenbank. Insbesondere ist die CONNECT-Berechtigung nicht erforderlich. Deshalb verwendet die Remoteautorisierung im Allgemeinen einen Datenbankprinzipal, der insbesondere für die Remoteautorisierung erstellt wurde. Dieser Prinzipal hat keine weiteren Berechtigungen und sollte nicht für andere Zwecke verwendet werden. Eine Erläuterung der Sicherheitsprinzipale in SQL Server finden Sie unter Prinzipale (Datenbankmodul).

Im Allgemeinen verwenden Sie einen Prinzipal pro Dienst. So wird der Zugriff auf die Dienste beschränkt. In einigen Fällen, in denen Ihre Anwendung mehrere miteinander eng verbundene Dienste verwendet, können Sie auch denselben Prinzipal für alle diese Dienste verwenden. Wenn Sie z. B. Ihre Anwendung so entwerfen, dass ein Dienst Ausgabenberichtsübermittlungen annimmt, während ein anderer Dienst Statusinformationen über die Ausgabenberichte bereitstellt, können Sie beide Dienste mit demselben Prinzipal sichern. In diesem Fall wird mit dem Zugriff auf einen Dienst auch der Zugriff auf den anderen Dienst bereitgestellt, sodass die Prinzipale nicht getrennt werden müssen.

Prinzipaltypen

Bei der Dialogsicherheit kann entweder ein Datenbankbenutzer oder eine Anwendungsrolle als lokaler Prinzipal verwendet werden. Jeder Prinzipaltyp weist andere Eigenschaften auf. Wählen Sie den Prinzipaltyp aus, der den Anforderungen Ihrer Anwendung am besten entspricht. In den meisten Fällen bietet ein Datenbankbenutzer ohne Anmeldenamen die flexibelste Art und Weise, Remoteverbindungen zu autorisieren und gleichzeitig die erforderlichen Privilegien zu minimieren.

Datenbankbenutzer ohne Anmeldenamen

Ein Datenbankbenutzer ohne Anmeldenamen kann keine direkte Verbindung mit der Datenbank herstellen, um Transact-SQL auszuführen. Ein Benutzer dieses Typs kann jedoch Besitzer von Objekten in der Datenbank sein, und ihm können Berechtigungen auf Datenbankebene erteilt werden. Deshalb verwenden viele Anwendungen einen Datenbankbenutzer ohne Anmeldenamen als lokalen Prinzipal. Beim Setupvorgang der Anwendung wird der Benutzer erstellt und lediglich die SEND-Berechtigung für den Dienst bzw. die Dienste erteilt, die für die Anwendung verwendet werden. Da diese Benutzer keinem Anmeldenamen entsprechen, können Sie die Datenbank, die den Dienst hostet, in eine andere Instanz verschieben, ohne die Sicherheitskonfiguration zu ändern.

Anwendungsrollen

Für eine Anwendungsrolle ist kein Serveranmeldename erforderlich. Die Transact-SQL-Anweisung, die eine Anwendungsrolle erstellt, muss jedoch ein Kennwort für die Anwendungsrolle enthalten. Gehen Sie deshalb bei der Planung von Setupskripts, die Anwendungsrollen erstellen, sorgfältig vor. Da eine Anwendungsrolle in einer bestimmten Datenbank enthalten ist, können Sie die Datenbank, die den Dienst hostet, problemlos in eine andere Instanz verschieben, ohne die Sicherheitskonfiguration zu ändern.

Datenbankbenutzer mit Anmeldenamen

Ein Datenbankbenutzer kann einem Serveranmeldenamen zugeordnet sein. Vermeiden Sie im Allgemeinen die Verwendung eines Datenbankbenutzers mit einem Anmeldenamen für die Remoteautorisierung. Da diese Benutzer zum Ausführen von Transact-SQL möglicherweise eine direkte Datenbankverbindung herstellen können, hat ein Datenbankbenutzer mit Anmeldenamen Privilegien, die für die Remoteautorisierung nicht erforderlich sind.

Beachten Sie, dass das Verfahren zur Remoteautorisierung nur die Datenbankberechtigungen prüft. Deshalb berücksichtigt die Remoteautorisierung keine Kontoberechtigungen, die normalerweise über die Windows-Anmeldung zur Verfügung stehen würden. Ein Benutzer, der z. B. einem Anmeldenamen zugeordnet ist, der Mitglied der BUILTIN\Administrators-Gruppe ist, verfügt normalerweise über die CONTROL SERVER-Berechtigung. Bei der Verwendung für die Remoteautorisierung hat der Benutzer jedoch lediglich die Berechtigungen, die dem Benutzer explizit erteilt wurden.