Microsoft SQL Server 2000 SP3 - Sicherheitsfunktionen und

Werbung
1
Microsoft SQL Server 2000 SP3 Sicherheitsfunktionen und bewährte
Methoden
Autoren: Girish Chander, James Hamilton, Willis Johnson, Richard Waymire.
Mitarbeiter/innen: Michael Dunner, Ray Escamilla, Alex Mackman, J.D. Meier, Ananda
Murukan und Srinath Vasireddy.
Zusammenfassung: Dieses Whitepaper enthält Sicherheitsempfehlungen für die
Installation, Verwaltung und Bereitstellung von Microsoft® SQL Server™ 2000
Service Pack 3 (SP3). Zudem bietet es ihnen die Möglichkeit, sich intensiver mit den
Details des SQL Server-Sicherheitsmodells auseinander zu setzen. Das Whitepaper ist
auf Administratoren und Entwickler ausgerichtet.
3
Inhalt
Einführung ..................................................................................................... 5
Voraussetzungen ............................................................................................ 5
SQL Server 2000-Sicherheitsmodell .................................................................. 5
Authentifizierungsmodi ............................................................................... 7
Internes Verwenden von Sicherheits-IDs ...................................................... 8
Rollen....................................................................................................... 9
Sichern des Zugriffs auf den Server ........................................................... 15
Sichern des Zugriffs auf die Datenbank....................................................... 16
Implementierung von Sicherheit auf Serverebene .......................................... 29
Verwenden von Sicherheits-IDs ................................................................. 29
Generierung von GUIDs für nicht vertraute Benutzer .................................... 30
Umbenennen von Windows-Benutzerkonten oder -Gruppenkonten ................. 30
Sichten der sysxlogins-Systemtabelle ......................................................... 31
Implementierung von Sicherheit auf Objektebene ............................................. 31
Überprüfen von Berechtigungen ................................................................. 31
Berechtigungen für Named Pipes und Multiprotokoll ..................................... 35
Installation eines sicheren Servers .................................................................. 35
Dateisystem ............................................................................................ 36
Firewalls ................................................................................................. 36
Deaktivieren von NetBIOS und SMB ........................................................... 37
Schritte vor dem Ausführen von SQL Server Setup ...................................... 38
Von SQL Server installierte Elemente ......................................................... 38
Installieren von SQL Server....................................................................... 39
Dienste ................................................................................................... 40
SQL Server-Konten .................................................................................. 42
Verschlüsseln von Datendateien mit EFS ..................................................... 44
Wählen statischer Ports für benannte Instanzen .......................................... 44
Löschen oder Sichern alter Setup-Dateien ................................................... 45
Verwaltung eines sicheren Servers .................................................................. 46
Installieren aller Service Packs und Sicherheitspatches ................................. 46
Überwachen des Servers mit Microsoft Baseline Security Analyzer ................. 46
Überwachung .......................................................................................... 47
4
Sicherheit für eine mehrstufige Bereitstellung ............................................... 48
Master-/Zielserver ................................................................................... 49
SSL und IPSec ......................................................................................... 50
Authentifizierung ..................................................................................... 51
Autorisierung .......................................................................................... 53
Remoteverwaltung ................................................................................... 56
Gespeicherte Prozeduren oder dynamisches SQL ......................................... 58
Verwenden getrennter Datenzugriffsassemblys ............................................ 58
SQL-Injektion .......................................................................................... 59
Speichern von Anmeldeinformationen ......................................................... 64
Persist Security Info-Eigenschaft................................................................ 66
Verschlüsseln von Benutzerdaten ............................................................... 66
Überprüfen von Kennwörtern mit einem Einweghashwert .............................. 67
Verwaltung von Ausnahmen ...................................................................... 67
Überlegungen zur Codezugriffssicherheit..................................................... 74
MSDE .......................................................................................................... 76
Abschluss: Prüfliste für bewährte Methoden ................................................... 77
Prüfliste für Administratoren...................................................................... 77
Prüfliste für Entwickler .............................................................................. 84
Prüfliste für Softwareanbieter .................................................................... 88
Anhang: Weitere Informationsquellen .............................................................. 90
Empfohlene Bücher: ................................................................................. 90
Empfohlene Tools, Whitepapers und Präsentationen ..................................... 91
Microsoft-Sites zu SQL Server und Sicherheit .............................................. 91
Whitepapers ............................................................................................ 92
Copyright ........................................................................................................ 93
5
Einführung
Das vorliegende Whitepaper richtet sich an Administratoren und Entwickler für
Microsoft SQL Server und enthält eine Einführung in die Sicherheitsfunktionen von
SQL Server 2000 Service Pack 3 (SP3). Es erläutert bewährte Sicherheitsmethoden und
gibt diesbezüglich detaillierte Empfehlungen. Darüber hinaus enthält das Whitepaper
Quellcodebeispiele. Am Ende des Dokuments finden Sie eine Prüfliste für bewährte
Sicherheitsmethoden. Das Hauptthema dieses Whitepapers ist das SQL Server-Modul.
Detaillierte Erläuterungen zu Replikation, Analysis Services oder
Data Transformation Services erhalten Sie über
http://go.microsoft.com/fwlink/?LinkId=15402.
Voraussetzungen
Die Sicherheitsfunktionen von SQL Server 2000 basieren auf dem Sicherheitsmodell von
Microsoft Windows NT 4.0 und Windows 2000. Grundkenntnisse der Windows NT 4.0und Windows 2000-Sicherheit werden in diesem Dokument vorausgesetzt. Außerdem
werden konzeptionelle Kenntnisse zu Domänen, globalen Gruppen, lokalen Gruppen
sowie Benutzerkonten im Kontext der Windows NT 4.0-Sicherheit wie auch von
Microsoft Active Directory unter Windows 2000 vorausgesetzt.
Zum besseren Verständnis der Codebeispiele sollten Sie mit Microsoft Visual Basic und
SQL (Structured Query Language) vertraut sein. Außerdem ist Erfahrung im Umgang mit
SQL-DMO (SQL Distributed Management Objects) von Vorteil.
Selbst im Umgang mit Windows NT 4.0, Windows 2000 oder SQL Server weitgehend
unerfahrene Benutzer können jedoch ihre Kenntnisse der Sicherheit in der praktischen
Anwendung dieser Produkte deutlich vertiefen.
SQL Server 2000-Sicherheitsmodell
Das Sicherheitsmodell von SQL Server 2000 basiert auf dem WindowsSicherheitsmodell. Detaillierte Erläuterungen zu bewährten WindowsSicherheitsmethoden finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15392.
6
SQL Server 2000 sollte wie im nachfolgenden Diagramm (Abbildung 1) gesichert
werden.
Abbildung 1: Windows-Benutzer und -Gruppen als leistungsstarkes und
flexibles Sicherheitsmodell für SQL Server-Administratoren
Die einzelnen Schritte im Diagramm können folgendermaßen zusammengefasst werden:
1. Benutzer jeder Domäne werden globalen Windows-Gruppen zugewiesen.
2. Die globalen Windows-Gruppen aus den verschiedenen Domänen werden in eine
lokale Windows-Gruppe platziert.
3. Der lokalen Windows-Gruppe werden Anmelderechte für SQL Server 2000 erteilt.
4. Der lokalen Windows-Gruppe werden Zugriffsrechte für die gewünschten
Datenbanken erteilt. Diese lokale Windows-Gruppe muss nicht mit der Gruppe
übereinstimmen, der in Schritt 3 Anmelderechte erteilt wurden. Mit anderen Worten:
Schritte 1 und 2 werden wiederholt ausgeführt, um die Benutzer nach den
erforderlichen Zugriffsberechtigungen zu gruppieren.
5. Der lokalen Windows-Gruppe werden Berechtigungen für spezifische
Datenbankobjekte zugewiesen.
7
Der andere Sicherheitsansatz basiert auf Rollen und wird in der Regel wie folgt
implementiert (Abbildung 2).
Abbildung 2: Rollenbasierte Sicherheit als weitere Sicherheitsoption in
SQL Server 2000
Werden Rollen zum Zuweisen von Objektberechtigungen verwendet, müssen den
einzelnen Benutzern nach wie vor Berechtigungen für den Server und die Datenbank
mithilfe des empfohlenen Ansatzes erteilt werden.
Schritte 1 bis 4 sind für beide Diagramme identisch. Der Unterschied besteht darin, dass
normalerweise nicht mehrere globale und lokale Windows-Gruppen erstellt werden. Auch
universelle Gruppen von Windows 2000 werden vollständig unterstützt.
Schritt 5: Einzelne Windows-Konten und Windows-Gruppen werden einer Rolle
zugewiesen.
Schritt 6: Anschließend werden den Rollen Objektberechtigungen zugewiesen.
Mit Rollen wird die Notwendigkeit reduziert, Benutzer unter Windows zu gruppieren, da
die Benutzer in SQL Server 2000 gruppiert werden.
Authentifizierungsmodi
In SQL Server 2000 werden zwei Authentifizierungsmodi für einen sicheren Zugriff auf
den Server bereitgestellt: der Windows-Authentifizierungsmodus und der gemischte
Modus.
8
Windows-Authentifizierungsmodus
Der Windows-Authentifizierungsmodus ist der standardmäßige Authentifizierungsmodus
in SQL Server 2000. Im Windows-Authentifizierungsmodus wird für SQL Server 2000 nur
die Windows-Authentifizierung des Benutzers verwendet. Windows-Benutzern oder
-Gruppen wird dann Zugriff auf den Server mit SQL Server gewährt. Verbindungen, die
in diesem Modus mit dem Server hergestellt werden, werden vertraute Verbindungen
genannt.
Beim Windows-Authentifizierungsmodus ermöglicht der Datenbankadministrator
Benutzern den Zugriff auf den Computer mit SQL Server durch Erteilen von
Anmelderechten für SQL Server 2000. Mit Windows-Sicherheits-IDs (Security Identifiers,
SIDs) werden von Windows authentifizierte Anmeldungen nachverfolgt. Da WindowsSIDs verwendet werden, kann der Datenbankadministrator Windows-Benutzern oder
-Gruppen direkt Anmeldezugriff gewähren.
Gemischter Modus
Im gemischten Modus können Benutzer von der Windows-Authentifizierung oder
SQL Server-Authentifizierung authentifiziert werden. Die Benutzernamen und
Kennwörter von Benutzern, die von SQL Server authentifiziert werden, werden in
SQL Server verwaltet.
Ebenso wie im Windows-Authentifizierungsmodus wird für den Server mit SQL Server
auch bei einer im gemischten Modus hergestellten Verbindung die Authentifizierung der
Benutzer durch Windows verwendet, wenn auf dem Client und dem Server NTLM oder
Kerberos-Anmeldeauthentifizierungsprotokolle verwendet werden können. Wenn auf
dem Client keine Windows-Standardanmeldung verwendet werden kann, benötigt
SQL Server einen Benutzernamen und ein Kennwort. Diese werden dann mit den
gespeicherten Angaben in den Systemtabellen verglichen. Verbindungen, die auf dem
Benutzernamen und Kennwort beruhen, werden nicht vertraute Verbindungen oder SQLVerbindungen genannt.
Internes Verwenden von Sicherheits-IDs
In SQL Server werden vertraute Anmeldungen mithilfe von SIDs nachverfolgt. WindowsBenutzern und -Gruppen kann der Zugriff auf Datenbanken oder spezifische
Datenbankobjekte direkt gewährt werden. Beispiel: Jane ist Mitglied der WindowsGruppen SALES und MARKETING. Die SALES-Gruppe verfügt über die
Anmeldeberechtigung für SQL Server sowie über die Zugriffsberechtigung für die pubsDatenbank. Ein Administrator kann Jane über ihren Windows-Namen REDMOND\Jane
Zugriff auf die authors-Tabelle gewähren. Auf das Windows-Konto muss per Domäne
und Benutzernamen verwiesen werden. In diesem Fall wird Janes SID in den
Systemtabellen der pubs-Datenbank gespeichert. SQL Server 2000 unterstützt keine
UPNs (User Principal Names, Benutzerprinzipalnamen). Wenn beispielsweise bei der
Windows-Anmeldung die Domäne SALES lautet und der Benutzer SOMEONE heißt, lautet
die Anmeldung bei SQL Server SALES\SOMEONE. Eine Anmeldung der Form
SOMEONE@MYCOMPANY.COM, wie sie von Active Directory unter Windows 2000
unterstützt wird, kann nicht verwendet werden.
9
Rollen
Rollen werden ähnlich wie Windows-Gruppen verwendet. Mit Rollen können Benutzer zu
einer Einheit zusammengefasst werden, auf die Berechtigungen angewendet werden.
Berechtigungen, die für eine Rolle erteilt, verweigert oder aufgehoben werden, gelten für
alle Mitglieder dieser Rolle. Eine Rolle kann eine Aufgabe darstellen, die von einer
Gruppe von Mitarbeitern einer Organisation ausgeführt wird. Dieser Rolle können dann
Berechtigungen erteilt werden. Sobald neue Mitarbeiter mit der Aufgabe beginnen,
werden sie Mitglieder der Rolle. Endet ihre Mitarbeit an der Aufgabe, werden sie aus der
Rolle entfernt. Das wiederholte Erteilen, Verweigern und Aufheben von Berechtigungen
für Einzelpersonen bei Aufgabenbeginn oder -ende wird somit überflüssig.
Die Leistungsstärke der Rollen beruht auf einigen Schlüsselkonzepten. Erstens werden
Rollen (mit Ausnahme der festen Serverrollen) in einer Datenbank implementiert. Dies
bedeutet, dass der Datenbankadministrator beim Gruppieren von Benutzern nicht vom
Windows-Administrator abhängt. Zweitens können Rollen geschachtelt werden. Für die
Schachtelungstiefe gibt es keine Beschränkungen, aber zirkulares Schachteln ist nicht
zulässig. Drittens kann ein Datenbankbenutzer gleichzeitig Mitglied mehrerer Rollen sein.
Ein Datenbankadministrator kann also Berechtigungen in Hierarchien anordnen. So kann
die Verwaltungsstruktur der Organisation widergespiegelt werden, in der die Datenbank
verwendet wird. Beispielsweise kann die Finanzabteilung separate Gruppen enthalten,
die für Verbindlichkeiten und Forderungen zuständig sind. Der Datenbankadministrator
kann separate Datenbankrollen für die Mitarbeiter der Kreditorenbuchhaltung
(APEmployees) und der Debitorenbuchhaltung (AREmployees) erstellen und jeder
Rolle nur die Berechtigungen zuweisen, die die Mitarbeiter für die entsprechende
Aufgabe benötigen. Anschließend kann der Datenbankadministrator eine Rolle
FinManagers erstellen, die die beiden stärker eingeschränkten Rollen (APEmployees
und AREmployees) enthält. Wenn die Leiter der Finanzabteilung in die Rolle
FinManagers aufgenommen werden, verfügen sie also über alle Berechtigungen der
ihnen unterstellten Mitarbeiter. Eine Mitarbeiterin der Kreditorenabteilung, die zur
Abteilungsleiterin befördert wird, muss der Datenbankadministrator nur noch zur Rolle
FinManagers hinzufügen.
Public (Rolle)
Die public-Rolle ist in jeder Datenbank vorhanden, auch in den Systemdatenbanken
master, msdb, tempdb und model. Die public-Rolle stellt die
Standardberechtigungen für Benutzer in einer Datenbank bereit und kann nicht gelöscht
werden. Ihre Funktion ähnelt der Funktion der Gruppe Jeder in der Windows NT 4.0Umgebung. Jeder Datenbankbenutzer ist automatisch Mitglied dieser Rolle. Daher
können Benutzer weder zu dieser Rolle hinzugefügt noch aus ihr entfernt werden.
Vordefinierte Rollen
SQL Server 2000 enthält mehrere vordefinierte Rollen. Diese Rollen weisen vordefinierte
implizite Berechtigungen auf, die keinen anderen Benutzerkonten erteilt werden können.
Es gibt zwei Arten von vordefinierten Rollen: feste Serverrollen und feste
Datenbankrollen.
10
Feste Serverrollen
Der Gültigkeitsbereich fester Serverrollen erstreckt sich auf den gesamten Server.
Die Rollen sind außerhalb der Datenbanken vorhanden. Alle Mitglieder einer festen
Serverrolle können andere Benutzernamen zu der Rolle hinzufügen.
Anmerkung Alle Mitglieder der Windows-Gruppe
VORDEFINIERT\Administratoren (der lokalen Administratorengruppe) sind
standardmäßig Mitglieder der sysadmin-Rolle.
In der folgenden Tabelle (Tabelle 1) werden die festen Serverrollen von
SQL Server 2000 aufgelistet.
Feste Serverrolle
Beschreibung
Sysadmin
Führt jede Art von Aktivität in SQL Server durch.
Serveradmin
Konfiguriert serverweite Konfigurationsoptionen, fährt den
Server herunter.
Setupadmin
Fügt Verbindungsserver hinzu oder entfernt sie und führt einige
gespeicherte Systemprozeduren aus, wie z. B.
sp_serveroption.
Securityadmin
Verwaltet serverweite Sicherheitseinstellungen, einschließlich
Verbindungsserver, und CREATE DATABASE-Berechtigungen.
Setzt Kennwörter für Benutzernamen mit der SQL ServerAuthentifizierung zurück.
Processadmin
Beendet in SQL Server ausgeführte Prozesse.
Dbcreator
Erstellt, ändert und löscht Datenbanken und stellt sie wieder her.
Diskadmin
Verwaltet Datenträgerdateien.
Bulkadmin
Ermöglicht einem nicht als Administrator angemeldeten Benutzer
das Ausführen der bulkadmin-Anweisung.
Tabelle 1: Feste Serverrollen von SQL Server 2000
Verwenden Sie die folgende Transact-SQL-Anweisung, um Benutzer zu festen
Serverrollen hinzuzufügen:
/* Add Bob to the sysadmin server role */
exec sp_addsrvrolemember "REDMOND\Bob", "sysadmin"
11
Windows-Benutzer und -Gruppen können zu Serverrollen hinzugefügt werden. Der
folgende Code zeigt, wie ein Benutzer mithilfe der SQL-DMO-Auflistung (Distributed
Management Objects) zu einer Serverrolle hinzugefügt wird:
' Declare variables
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Add Bob to the sysadmin server role
oServer.ServerRoles("sysadmin").AddMember ("REDMOND\Bob")
Weitere Informationen zur Verwendung fester Serverrollen finden Sie in der SQL ServerOnlinedokumentation.
Feste Datenbankrollen
Feste Datenbankrollen werden auf Datenbankebene definiert und sind in jeder
Datenbank vorhanden. Mitglieder der Administratorrollen db_owner und db_security
können Mitgliedschaften in festen Datenbankrollen verwalten. Allerdings können nur
Mitglieder von db_owner weitere Mitglieder zur festen Datenbankrolle db_owner
hinzufügen.
In der folgenden Tabelle (Tabelle 2) werden die festen Datenbankrollen von
SQL Server 2000 aufgelistet.
Feste
Datenbankrolle
Beschreibung
db_owner
Führt alle Verwaltungs- und Konfigurationsaktivitäten in der
Datenbank durch.
db_accessadmin
Fügt für Windows-Benutzer und -Gruppen sowie SQL ServerBenutzernamen den Zugriff hinzu und entfernt ihn.
db_datareader
Liest alle Daten aus allen Benutzertabellen.
db_datawriter
Löscht und ändert Daten in allen Benutzertabellen und fügt
Daten hinzu.
db_ddladmin
Führt alle DDL-Befehle (Data Definition Language,
Datendefinitionssprache) in einer Datenbank aus.
db_securityadmin
Ändert die Rollenmitgliedschaft und verwaltet
Berechtigungen.
12
Feste Datenbankrolle (Fortsetzung)
Beschreibung (Fortsetzung)
db_backupoperator
Sichert die Datenbank.
db_denydatareader
Kann keine Daten in Benutzertabellen in einer Datenbank
lesen.
db_denydatawriter
Kann keine Daten in Benutzertabellen oder Sichten
hinzufügen, ändern oder löschen.
Tabelle 2: Feste Datenbankrollen in SQL Server 2000
Weitere Informationen zur Verwendung fester Datenbankrollen finden Sie in der
SQL Server-Onlinedokumentation.
Benutzerdefinierte Rollen
Benutzerdefinierte Rollen sind eine einfache Möglichkeit zum Verwalten von
Berechtigungen in einer Datenbank, wenn eine Gruppe von Benutzern bestimmte
Aktivitäten in SQL Server 2000 ausführt. In Situationen, in denen keine anwendbare
Windows-Gruppe vorhanden ist oder der Datenbankadministrator nicht über die
Berechtigungen zum Verwalten der Windows-Benutzerkonten verfügt, wird dem
Datenbankadministrator mit benutzerdefinierten Rollen die gleiche Flexibilität
bereitgestellt wie mit Windows-Gruppen.
Benutzerdefinierte Rollen gelten nur auf Datenbankebene. Außerdem gelten sie nur für
die Datenbank, in der sie erstellt wurden.
Anwendungsrollen
Mit Anwendungsrollen kann ein Datenbankadministrator nur den Benutzern Zugriff auf
Daten gewähren, die eine bestimmte Anwendung verwenden.
Dazu wird folgender Vorgang verwendet: Ein Benutzer stellt über eine Anwendung eine
Verbindung mit einer Datenbank her. Die Identität der Anwendung wird dann mit der
gespeicherten Prozedur sp_setapprole für SQL Server nachgewiesen. An die Prozedur
werden zwei Parameter übergeben: der Name der Anwendungsrolle und das Kennwort.
(Das Kennwort der Anwendungsrolle ist nur der Anwendung bekannt.) Wenn der Name
und das Kennwort der Anwendungsrolle gültig sind, wird die Anwendungsrolle aktiviert.
Zu diesem Zeitpunkt werden alle Berechtigungen verworfen, die dem Benutzer aktuell
zugewiesen sind, und der Sicherheitskontext der Anwendungsrolle tritt in Kraft. Da nur
die Anwendung (und nicht der Benutzer) über das Kennwort für die Anwendungsrolle
verfügt, kann nur die Anwendung diese Rolle aktivieren und auf Objekte zugreifen, für
die die Rolle Berechtigungen aufweist.
13
Nach der Aktivierung können Anwendungsrollen nicht deaktiviert werden. Die einzige
Möglichkeit für einen Benutzer, den ursprünglichen Sicherheitskontext
wiederherzustellen, besteht im Trennen und erneuten Herstellen der Verbindung mit
SQL Server.
Anwendungsrollen arbeiten mit beiden Authentifizierungsmodi und enthalten keine
Mitglieder. Benutzer können nicht Anwendungsrollen zugeordnet werden, da die
Anwendung den Sicherheitskontext der Anwendungsrolle mithilfe der gespeicherten
Prozedur sp_setapprole anfordert.
Wie benutzerdefinierte Rollen sind Anwendungsrollen nur in einer Datenbank vorhanden.
Beim Zugreifen mit einer Anwendungsrolle auf eine andere Datenbank werden dieser
Anwendungsrolle nur die Rechte des Kontos Guest in der Datenbank erteilt. Wenn dem
Konto Guest nicht explizit Zugriff auf die Daten gewährt wurde oder es nicht vorhanden
ist, kann auf die Objekte nicht zugegriffen werden.
Ein anderes Schlüsselkonzept bei der Verwendung von Anwendungsrollen besteht darin,
dass der Benutzer, der die Anwendung ausführt, in SQL Server 2000 überwacht wird.
Mit Anwendungsrollen wird also der Sicherheitskontext bereitgestellt, in dem die
Datenbankobjekt-Berechtigungen überprüft werden, ohne dass die Identität des
tatsächlichen Benutzers verloren geht.
Im Folgenden wird eine beispielhafte Implementierung mit Anwendungsrollen
beschrieben. Wenn Jane Mitglied der ACCOUNTING-Gruppe ist und für Mitglieder der
ACCOUNTING-Gruppe der Zugriff auf Daten in SQL Server nur über das
Buchhaltungssoftwarepaket zugelassen ist, kann für die Buchhaltungssoftware eine
Anwendungsrolle erstellt werden. Der ACCOUNTING-Anwendungsrolle wird Zugriff auf
die Daten gewährt, während der Windows-Gruppe ACCOUNTING der Zugriff auf die
Daten verweigert wird. Versucht Jane nun, auf die Daten mithilfe von
SQL Query Analyzer zuzugreifen, wird der Zugriff verweigert. Verwendet Jane hingegen
die Buchhaltungssoftware, kann sie auf die Daten zugreifen.
In diesem Verfahren wird die Verwendung von Anwendungsrollen durch eine Anwendung
erläutert. So verwenden Sie Anwendungsrollen:
1. Erstellen Sie eine Anwendungsrolle.
2. Weisen Sie der Anwendungsrolle Berechtigungen zu.
3. Stellen Sie sicher, dass der Endbenutzer die Verbindung mit dem Server über die
Anwendung herstellt.
4. Stellen Sie sicher, dass die Anwendungsrolle von der Clientanwendung aktiviert wird.
Die ersten beiden Schritte dieses Vorgangs sind in der Regel von den letzten beiden
Schritten getrennt. Daher folgen zwei Codefragmente für Transact-SQL bzw.
Microsoft Visual Basic.
14
Das Transact-SQL-Skript lautet wie folgt:
/* Create the application role. */
EXEC sp_addapprole "AccAppRole", "ABC"
/* Grant permissions to SELECT. */
GRANT SELECT
ON authors
TO AccAppRole
GO
Es folgt der Code zum Aktivieren der Rolle:
/* Activate the role. */
EXEC sp_setapprole "AccAppRole", {ENCRYPT N "ABC"}
Die Verschlüsselung des Kennwortes ist optional, führt aber zu höherer Sicherheit, wenn
das Kennwort über ein WAN (Wide Area Network) übergeben wird.
Es folgt der Visual Basic-Code:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oDbRole As SQLDMO.DatabaseRole
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Create the Role object.
Set oDbRole = CreateObject("SQLDMO.DatabaseRole")
' Set the appropriate properties.
oDbRole.Name = "AccAppRole"
oDbRole.AppRole = True
oDbRole.Password = "45$#Jxew&fd2$Dw53987"
' Add the Role object to the servers Role collection.
oServer.Databases("pubs").DatabaseRoles.Add oDbRole
15
So verwenden Sie die Rolle:
' Declare variables.
Dim oConnection As ADODB.Connection
' Create the connection object and connect.
Set oConnection = CreateObject("ADODB.Connection")
oConnection.Provider = "sqloledb"
oConnection.Open "Server=SERVERNAME;Database=pubs;Trusted_Connection=yes"
' Activate the application role. There is no error handling for this
sample.
oConnection.Execute "EXEC sp_setapprole 'AccAppRole', {ENCRYPT N
'45$#Jxew&fd2$Dw53987'}, 'ODBC'"
Das Verschlüsselungsformat (letzter Parameter) muss für OLE DB- und ODBCDatenquellen festgelegt werden. Bei anderen Datenquellen kann das Kennwort nicht
explizit verschlüsselt werden. In diesem Fall müssen Sie ein verschlüsseltes
Kommunikationsprotokoll für den Server verwenden. Weitere Informationen finden Sie
in den Erläuterungen zu SSL und IPSec weiter unten.
Anwendungsrollen werden pro Sitzung implementiert. Wenn von der Anwendung
mehrere Sitzungen geöffnet werden und für alle Sitzungen dieselbe Rolle verwendet
werden soll, muss die Rolle in jeder Sitzung zunächst aktiviert werden.
Durch Implementieren von Anwendungsrollen kann Sicherheit mit noch höherer
Granularität als bisher bereitgestellt werden. So kann für eine Clientanwendung z. B. bei
einigen Verbindungen der Sicherheitskontext des Benutzers und bei anderen
Verbindungen eine Anwendungsrolle verwendet werden.
Beim Verwenden von Anwendungsrollen kann mit SELECT USER der Name der aktuellen
Anwendungsrolle zurückgegeben werden. Wenn die Identität des angemeldeten
Benutzers erforderlich ist, sollten Sie die folgende Transact-SQL-Anweisung verwenden:
SELECT SYSTEM_USER.
Anmerkung Beim Verwenden von Anwendungsrollen müssen Kennwörter
gespeichert werden. Verwenden Sie die geeignete Verschlüsselung und
Zugriffssteuerungslisten (Access Control Lists, ACLs). Weitere Informationen finden
Sie unter „Speichern von Anmeldeinformationen“ weiter unten.
Sichern des Zugriffs auf den Server
Der Zugriff auf den Server wird von den beiden Authentifizierungsmodi in
SQL Server 2000 unterschiedlich gesteuert. Sobald ein Benutzer jedoch Zugriff auf den
Server erhalten hat, sind die Authentifizierungsmodi identisch. Bei der SQL Server 2000Sicherheit wird standardmäßig die Windows-Authentifizierung verwendet, wenn sie
installiert ist.
16
Windows-Ebene
Beim Sichern des Zugriffs auf der Windows-Ebene sollten Administratoren für jeden
Benutzer, der auf SQL Server zugreift, ein Windows-Domänenanmeldekonto erstellen
(falls der Benutzer noch kein Konto besitzt).
Erstellen Sie auf der Ebene der Windows-Domäne globale Gruppen mit Berechtigungen,
die für spezifische Aufgaben von Organisationsmitarbeitern geeignet sind. Fügen Sie
Windows-Benutzer zu den entsprechenden globalen Gruppen hinzu. Erstellen Sie auf
dem Computer mit SQL Server 2000 lokale Windows-Gruppen mit Berechtigungen, die
den mit SQL Server ausgeführten Aufgaben entsprechen. Fügen Sie schließlich die
geeigneten globalen Windows-Gruppen zu den lokalen Windows-Gruppen hinzu.
Ziel dieses Vorgangs ist das Zusammenfassen von Rechten und Benutzern in Gruppen,
so dass sie gemeinsam verwaltet werden können. Auch wenn die Vorbereitung sehr
komplex scheinen mag, sollten diese Schritte unbedingt ausgeführt werden. Eine
umsichtige Sicherheitsplanung am Anfang zahlt sich später in Form verbesserter
Systemsicherheit und vereinfachter Verwaltung aus.
Detaillierte Erläuterungen zur Sicherheit auf der Windows-Ebene finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15394.
Sichern des Zugriffs auf die Datenbank
Nach einer erfolgreichen Anmeldung kann ein Benutzer nicht automatisch auf alle
Datenbanken in SQL Server 2000 zugreifen. Damit Benutzer auf eine Datenbank
zugreifen können, müssen Berechtigungen erteilt werden.
In diesem Abschnitt wird nicht zwischen nicht vertrauten Benutzern, Windows-Benutzern
und Windows-Gruppen unterschieden. Wird auf Windows-Benutzer oder -Gruppen
verwiesen, kann es sich dabei auch um Benutzer oder globale Gruppen in vertrauten
Domänen oder Domänen in derselben Struktur oder Gesamtstruktur handeln.
In jeder Datenbank wird ein Benutzer erstellt und mit einem SQL ServerBenutzernamen, einem Windows-Benutzer oder einer Windows-Gruppe verknüpft.
In SQL Server Enterprise Manager (einem Snap-In von Microsoft Management Console
[MMC] zum Verwalten von SQL Server 2000) ist das Erstellen von Benutzern ohne
spezifische Anmeldeberechtigungen nicht zulässig. Von MMC wird eine Liste aller Konten
erstellt, denen Anmeldeberechtigungen für den Server erteilt wurden, und aus dieser
Liste muss eine Auswahl getroffen werden. Das gleiche gilt für das SQL-DMOObjektmodell.
Mit Transact-SQL können jedem gültigen SQL Server-Anmeldenamen, jedem WindowsBenutzer oder jeder Windows-Gruppe Zugriffsberechtigungen für die Datenbank erteilt
werden, unabhängig davon, ob in der master-Datenbank in der sysxlogins-Tabelle ein
spezifischer Anmeldename vorhanden ist.
Anmerkung Obwohl dies technisch gesehen nicht erforderlich ist, wird dringend
empfohlen, beim Verwenden vertrauter Verbindungen in allen Datenbanken Benutzer
zu erstellen, deren Benutzer- und Anmeldenamen identisch sind.
17
Es folgen einige Beispiele für die Transact-SQL-Anweisungen, die zum Erteilen von
Berechtigungen für die Verwendung einer Datenbank erforderlich sind:
/* Grant access to Bob. */
exec sp_grantdbaccess 'REDMOND\Bob'
/* Grant access to Wendy, referring to her by first name within this
database. */
exec sp_grantdbaccess 'REDMOND\WendyH', 'Wendy'
Nur eine Änderung muss vorgenommen werden, damit dieses Beispiel auch für nicht
vertraute Clients gilt. Verwenden Sie anstelle des Domänenbenutzernamens den
Benutzernamen, mit dem der Benutzer in SQL Server 2000 authentifiziert wird.
Mit SQL-DMO wird die gleiche Funktionalität mit folgendem Code erreicht:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oUser As SQLDMO.User
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Create the User object.
Set oUser = CreateObject("SQLDMO.User")
' Set the appropriate properties.
oUser.Name = "Bob"
oUser.Login = "REDMOND\Bob"
' Add the User object to the servers Users collection.
oServer.Databases("pubs").Users.Add oUser
18
SQL Server-Ebene
Auf der SQL Server 2000-Ebene müssen Sie den erstellten lokalen Windows-Gruppen
Anmeldeberechtigungen für SQL Server erteilen. Sie können Benutzern die
Anmeldeberechtigungen für SQL Server zwar auch direkt erteilen, aber die Verwaltung
ist dann nur bei äußerst kleinen Umgebungen noch praktikabel. Berechtigungen für die
Anmeldung am Server können mit Enterprise Manager erteilt oder mithilfe von
Visual Basic oder Transact-SQL programmgesteuert implementiert werden.
Datenbankadministratoren, die mit Transact-SQL arbeiten, sollten die Einträge zu den
folgenden sicherheitsbezogenen gespeicherten Prozeduren in der Onlinedokumentation
lesen:
sp_addalias
sp_droprole
sp_addapprole
sp_droprolemember
sp_addgroup
sp_dropserver
sp_addlinkedsrvlogin
sp_dropsrvrolemember
sp_addlogin
sp_dropuser
sp_addremotelogin
sp_grantdbaccess
sp_addrole
sp_grantlogin
sp_addrolemember
sp_helpdbfixedrole
sp_addserver
sp_helpgroup
sp_addsrvrolemember
sp_helplinkedsrvlogin
sp_adduser
sp_helplogins
sp_approlepassword
sp_helpntgroup
sp_change_users_login
sp_helpremotelogin
sp_changedbowner
sp_helprole
sp_changegroup
sp_helprolemember
sp_changeobjectowner
sp_helprotect
sp_dbfixedrolepermission
sp_helpsrvrole
sp_defaultdb
sp_helpsrvrolemember
sp_defaultlanguage
sp_helpuser
sp_denylogin
sp_password
sp_dropalias
sp_remoteoption
sp_dropapprole
sp_revokedbaccess
19
(Fortsetzung)
sp_dropgroup
sp_revokelogin
sp_droplinkedsrvlogin
sp_setapprole
sp_droplogin
sp_srvrolepermission
sp_dropremotelogin
sp_validatelogins
Mit der folgenden Transact-SQL-Anweisung werden der lokalen Gruppe SALESLG
Anmelderechte erteilt:
/* Grant login. */
exec sp_grantlogin 'REDMOND\SALESLG'
Alternativ können Anmelderechte auch mit folgendem Visual Basic-Code erteilt werden:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oLogin As SQLDMO.Login
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Create the Login object.
Set oLogin = CreateObject("SQLDMO.Login")
' Set the appropriate properties.
oLogin.Name = "REDMOND\SALESLG"
oLogin.Type = SQLDMOLogin_NTGroup
' Add the Login object to the server's Logins collection.
oServer.Logins.Add oLogin
Um Benutzern mithilfe nicht vertrauter Verbindungen Zugriff auf SQL Server 2000 zu
gewähren, müssen Sie Benutzerkonten erstellen.
Anmerkung Wenn SQL Server 2000 auf Computern unter Windows installiert und
zur Verwendung des gemischten Modus konfiguriert ist, können vertraute
Verbindungen von entsprechenden Clients hergestellt werden.
20
Mit dem folgenden Transact-SQL-Skriptcode wird ein Benutzername für eine nicht
vertraute Verbindung erstellt:
/* Add a login. */
exec sp_addlogin 'Bob', '45$#Jxew&fd2$Dw53987', 'pubs'
Mit dieser Anweisung wird der Benutzername Bob hinzugefügt und das Kennwort auf
password festgelegt. pubs ist die Standarddatenbank. Die Standarddatenbank ist die
Datenbank, die für den Benutzer bei der Anmeldung verwendet wird. Ein Benutzer muss
nach wie vor ein Benutzerkonto in der Standarddatenbank erstellen, damit dies möglich
ist. Mit sp_addlogin wird kein Benutzerkonto zu der Datenbank hinzugefügt, auf die
verwiesen wird.
Obiges kann auch mithilfe von Visual Basic erreicht werden:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oLogin As SQLDMO.Login
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Create the Login object.
Set oLogin = CreateObject("SQLDMO.Login")
' Set the appropriate properties.
oLogin.Name = "Bob"
oLogin.Type = SQLDMOLogin_Standard
oLogin.SetPassword "","45$#Jxew&fd2$Dw53987"
' Add the Login object to the server's Logins collection.
oServer.Logins.Add oLogin
21
Sichern des Zugriffs auf die Datenbankobjekte
Sie können Rollen und Benutzern Berechtigungen erteilen und die Berechtigungen so
zuweisen, dass Benutzer bestimmte Anweisungen ausführen und auf bestimmte
Datenbankobjekte zugreifen können. Mit Anweisungsberechtigungen wird der
Benutzerkreis eingeschränkt, der Anweisungen wie CREATE DATABASE, CREATE TABLE
oder CREATE FUNCTION ausführen kann. Mit Objektberechtigungen wird der Zugriff auf
Objekte wie Tabellen, Sichten, benutzerdefinierte Funktionen oder gespeicherte
Prozeduren eingeschränkt. Objektberechtigungen hängen vom Objekt ab, auf das
verwiesen wird. Zu den Objektberechtigungen für Tabellen gehören z. B. die
Berechtigungen für SELECT, INSERT, UPDATE, DELETE und REFERENCES, während zu
den Objektberechtigungen für eine gespeicherte Prozedur EXECUTE-Berechtigungen
gehören.
Benutzerdefinierte Datenbankrollen
In einer idealen Umgebung wären Rollen überflüssig. In einer solchen Umgebung führen
alle Benutzer SQL Server 2000 auf Computern unter Windows 2000 im WindowsAuthentifizierungsmodus aus. Der Datenbankadministrator kann den WindowsAdministrator bitten, alle Benutzer mit einer spezifischen Datenzugriffsanforderung (oder
Rolle) in eine Windows-Gruppe zu platzieren, und der Datenbankadministrator erteilt
dieser Windows-Gruppe dann die erforderlichen Berechtigungen. In manchen
Umgebungen ist die Berechtigungsverwaltung auf der Windows-Ebene oder
Domänenebene jedoch nicht möglich. Für diesen Fall stehen SQL Server-Rollen zum
Gruppieren von Benutzern nach Berechtigungsanforderungen zur Verfügung.
Jeder Windows-Benutzer und jede Windows-Gruppe kann einer Rolle zugewiesen
werden. Dieser Rolle können wiederum Berechtigungen für Datenbankobjekte auf die
gleiche Weise zugewiesen werden, wie Berechtigungen zu Datenbankbenutzern
zugewiesen werden.
Anmerkung Benutzerdefinierte Rollen können nur in einer Datenbank erstellt
werden. Feste Serverrollen und feste Datenbankrollen sind vordefiniert und können
nicht geändert werden.
Rollen können mit dem folgenden Transact-SQL-Code erstellt werden:
/* Add role for Telephone Operators. */
exec sp_addrole "TelephoneOperators"
Alternativ können Rollen mit folgendem Visual Basic-Code erstellt werden:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
Dim oDbRole As SQLDMO.DatabaseRole
22
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Create the Database Role object.
Set oDbRole = CreateObject("SQLDMO.DatabaseRole")
' Set the appropriate properties.
oDbRole.Name = "TelephoneOperators"
' Add the Role object to the servers Role collection.
oServer.Databases("pubs").DatabaseRoles.Add oDbRole
Nach dem Erstellen einer benutzerdefinierten Datenbankrolle werden Benutzer, Gruppen
oder andere Rollen hinzugefügt. Rollen können geschachtelt werden, aber nicht zirkular,
da dies kontraproduktiv wäre.
Mit diesem Transact-SQL-Beispielcode werden ein Windows-Benutzer, eine WindowsGruppe und eine Datenbankrolle zur neu erstellten Rolle hinzugefügt:
/* Add a Windows user to the TelephoneOperators role. */
exec sp_addrolemember "TelephoneOperators", "REDMOND\Bob"
/* Add a Windows group to the TelephoneOperators role. */
exec sp_addrolemember "TelephoneOperators", "REDMOND\Sales"
/* Add HelpDeskOperators role to TelephoneOperators role. */
exec sp_addrolemember "TelephoneOperators", "HelpDeskOperators"
Sie können dies auch wie folgt mit SQL-DMO ausführen:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("MSNZBENTHOM")
23
' Use with statement for code legibility.
With oServer.Databases("pubs").DatabaseRoles("TelephoneOperators")
' Add the Windows user to the TelehoneOperators role collection.
.AddMember ("REDMOND\Bob")
' Add the Windows group to the TelehoneOperator's role collection
.AddMember ("REDMOND \Sales")
' Add the HelpDeskOperators role to TelehoneOperators role collection.
.AddMember ("HelpDeskOperators")
End With
Berechtigungssystem
Das Berechtigungssystem in SQL Server 2000 basiert auf dem additiven Modell, das
auch die Grundlage der Windows-Berechtigungen bildet. Wenn ein Benutzer Mitglied der
Rollen sales, marketing und research ist (Mitgliedschaft in mehreren Gruppen), erhält
der Benutzer die Berechtigungen aller dieser Rollen. Wenn z. B. sales über SELECTBerechtigungen für eine Tabelle verfügt, marketing über INSERT-Berechtigungen und
research über UPDATE-Berechtigungen, kann der Benutzer die Anweisungen SELECT,
INSERT und UPDATE ausführen. Wenn jedoch einer bestimmten Rolle, deren Mitglied der
Benutzer ist, eine bestimmte Objektberechtigung verweigert wird (wie z. B. SELECT),
besitzt der Benutzer diese Berechtigung ebenso wie unter Windows nicht. Die
restriktivste Berechtigung (DENY) hat Vorrang.
Erteilen und Verweigern von Berechtigungen für
Benutzer und Rollen
Berechtigungen in einer Datenbank werden immer Datenbankbenutzern oder -Rollen
und Windows-Benutzern oder -Gruppen erteilt, aber niemals SQL Server 2000Anmeldenamen. Folgende Methoden werden zum Festlegen der geeigneten
Berechtigungen für Benutzer oder Rollen in einer Datenbank verwendet: Erteilen,
Verweigern und Aufheben von Berechtigungen.
Mit der DENY-Anweisung für Berechtigungen kann ein Administrator einem Benutzer
oder einer Rolle eine Objekt- oder Anweisungsberechtigung verweigern. Wie bei den
Windows-Berechtigungen hat DENY Vorrang vor allen anderen Berechtigungen.
24
Wenn z. B. einige Datenbankbenutzer leichtfertig Daten ändern, wäre es nicht fair, allen
Benutzern Berechtigungen zu entziehen, da die meisten Benutzer die Daten ja
verantwortungsvoll verwenden. Es ist möglich, eine neue Rolle mit einem Namen wie
trouble_makers zu erstellen und dann dieser Rolle alle Einfüge-, Aktualisierungs- und
Löschvorgänge (INSERT, UPDATE, DELETE) für alle Tabellen zu verweigern (DENY).
Bei inadäquatem Verhalten werden Benutzer der trouble_makers-Rolle zugeordnet,
unabhängig von anderen Berechtigungen, die sie direkt oder durch Mitgliedschaft in
einer Gruppe oder Rolle besitzen.
Beim Auswerten der zugeordneten Berechtigungen eines Objekts wird zuerst geprüft, ob
eine mit DENY verweigerte Berechtigung vorhanden ist. In diesem Fall wird die
Auswertung angehalten und der Zugriff nicht gewährt. Ist DENY nicht vorhanden,
werden im nächsten Schritt die dem Objekt zugeordneten Berechtigungen mit denen des
aufrufenden Benutzers oder Prozesses verglichen. In diesem Schritt werden mit GRANT
oder REVOKE festgelegte Berechtigungen in Betracht gezogen. Wird die Berechtigung
erteilt (GRANT), wird die Auswertung angehalten und der Zugriff gewährt. Wird die
Berechtigung aufgehoben (REVOKE), werden frühere mit GRANT oder DENY festgelegte
Berechtigungen gelöscht. Das Aufheben und das Verweigern von Berechtigungen dürfen
daher nicht gleichgesetzt werden. Mit REVOKE wird eine frühere GRANT- oder DENYFestlegung für eine Berechtigung gelöscht. Mit DENY für eine Berechtigung wird der
Zugriff selbst bei erteilten Zugriffsberechtigungen verhindert, da die explizite DENYAnweisung alle anderen Berechtigungen außer Kraft setzt.
In diesem Abschnitt werden die Methoden in je einem Beispiel für Visual Basic und
Transact-SQL angewendet. Mit dem folgenden Transact-SQL-Code werden Bob und Jane
Berechtigungen erteilt, Objekte in der authors-Tabelle auszuwählen (SELECT), und Jane
werden Berechtigungen erteilt, Objekte in die titles-Tabelle einzufügen (INSERT):
/* Grant permissions to SELECT. */
GRANT SELECT
ON authors
TO Bob, [REDMOND\Jane]
GO
/* Grant permissions to INSERT. */
GRANT INSERT
ON titles
TO [REDMOND\Jane]
GO
Im vorherigen Beispiel wird gezeigt, wie mit der GRANT-Anweisung explizit angegebenen
Datenbankbenutzern (Bob) und einem Windows-Benutzer (Jane) Berechtigungen erteilt
werden.
25
Es folgt dasselbe Beispiel in Visual Basic:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Grant Jane and Bob permissions to select from the authors table.
oServer.Databases("pubs").Tables("authors").Grant SQLDMOPriv_Select, "Bob"
oServer.Databases("pubs").Tables("authors").Grant SQLDMOPriv_Select, _
"[REDMOND\Jane]
' Grant Jane permissions to select from the authors table.
oServer.Databases("pubs").Tables("authors").Grant SQLDMOPriv_Select, _
"[REDMOND\Jane]"
Die obigen Beispiele unterscheiden sich nur darin, dass einmal einem Benutzer über die
volle Kennzeichnung anhand des Domänennamens Zugriff gewährt wird, während das
andere Mal einem Benutzer Zugriff direkt gewährt wird, der bereits über
Datenbankzugriff verfügt. Aufgrund dieser Ähnlichkeiten wird in den folgenden
Beispielen nur der Code für vorhandene Datenbankbenutzer gezeigt.
Mit der folgenden Transact-SQL-Anweisung wird gezeigt, wie einem Benutzer SELECTBerechtigungen verweigert werden können:
/* Deny permissions to SELECT. */
DENY SELECT
ON authors
TO Bob
GO
26
Sie können dies auch wie folgt mit Visual Basic ausführen:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Deny Bob permissions to select from authors table.
oServer.Databases("pubs").Tables("authors").Deny SQLDMOPriv_Select, "Bob"
Mit dem folgenden Transact-SQL-Code wird gezeigt, wie Berechtigungen für einen
Benutzer aufgehoben werden:
/* Revoke permissions to SELECT. */
REVOKE SELECT
ON authors
FROM Bob
GO
Dies ist der Visual Basic-Code:
' Declare variables.
Dim oServer As SQLDMO.SQLServer
' Create a server object and connect.
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.Connect ("SERVERNAME")
' Revoke Bob permissions to select from the authors table.
oServer.Databases("pubs").Tables("authors").Revoke SQLDMOPriv_Select,
"Bob"
27
Besitzketten
Wenn mehrere Datenbankobjekte sequenziell aufeinander zugreifen, wird die Sequenz
als Kette bezeichnet. Obwohl diese Ketten niemals ohne Abhängigkeiten vorkommen,
bewertet SQL Server beim Traversieren der Verknüpfungen in einer Kette die
Benutzerberechtigungen für die einzelnen Objekte anders als beim separaten Zugriff.
Diese Unterschiede haben wichtige Auswirkungen auf das Verwalten der Sicherheit.
Überprüfen der Berechtigungen in einer Kette
Wenn der Zugriff auf ein Objekt über eine Kette erfolgt, wird von SQL Server zuerst der
Objektbesitzer mit dem Besitzer des aufrufenden Objekts (vorherige Verknüpfung in der
Kette) verglichen. Wenn beide Objekte denselben Besitzer aufweisen, werden die
Berechtigungen für das Objekt, auf das verwiesen wird, nicht ausgewertet.
Beispiel für Besitzverkettung
In Abbildung 3 unten ist Mary die Besitzerin der July2003-Sicht. Sie hat Alex
Berechtigungen für die Sicht erteilt. In dieser Instanz besitzt er keine anderen
Berechtigungen für Datenbankobjekte. Was geschieht, wenn Alex SELECT für die Sicht
ausführt?
1. Alex führt die Auswahlanweisung SELECT * FROM JULY2003 aus. Die
Berechtigungen für die Sicht werden von SQL Server überprüft. Es wird bestätigt,
dass Alex zum Auswählen von Objekten berechtigt ist.
2. Die July2003-Sicht benötigt Informationen aus der SalesXZ-Sicht. Der Besitzer der
SalesXZ-Sicht wird überprüft. Da diese Sicht dieselbe Besitzerin (Mary) aufweist wie
die aufrufende Sicht, werden die Berechtigungen nicht überprüft. Die angeforderten
Informationen werden zurückgegeben.
3. Die SalesXZ-Sicht benötigt Informationen aus der InvoicesXZ-Sicht. Der Besitzer
der InvoicesXZ-Sicht wird überprüft. Da diese Sicht dieselbe Besitzerin aufweist wie
das vorherige Objekt, werden die Berechtigungen nicht überprüft. Die angeforderten
Informationen werden zurückgegeben. Bisher hatten alle Sequenzelemente eine
einzige Besitzerin (Mary). Dies wird als ununterbrochene Besitzkette bezeichnet.
4. Die InvoicesXZ-Sicht benötigt Informationen aus der AcctAgeXZ-Sicht.Der Besitzer
der AcctAgeXZ-Sicht wird überprüft. Da hier ein anderer Besitzer vorliegt (Sam
statt Mary), werden die gesamten Informationen zu Berechtigungen für diese Sicht
abgerufen. Wenn die AcctAgeXZ-Sicht über Berechtigungen verfügt, die Alex den
Zugriff gewähren, werden die Informationen zurückgegeben.
5. Die AcctAgeXZ-Sicht benötigt Informationen aus der ExpenseXZ-Tabelle. Der
Besitzer der ExpenseXZ-Tabelle wird überprüft. Da hier ein anderer Besitzer vorliegt
(Joe statt Sam), werden die gesamten Informationen zu Berechtigungen für diese
Tabelle abgerufen. Wenn die ExpenseXZ-Tabelle über Berechtigungen verfügt, die
Alex Zugriff gewähren, werden die Informationen zurückgegeben.
28
6. Beim Abrufen von Informationen aus der ProjectionsXZ-Tabelle für die July2003Sicht wird zuerst überprüft, ob zwischen Datenbank 1 und Datenbank 2 die
datenbankübergreifende Verkettung aktiviert ist. In diesem Fall wird der Besitzer der
ProjectionsXZ-Tabelle überprüft. Da die Tabelle dieselbe Besitzerin (Mary) aufweist
wie die aufrufende Sicht, werden die Berechtigungen nicht überprüft. Die
angeforderten Informationen werden zurückgegeben.
Abbildung 3
Wert der Besitzverkettung
Mit der Besitzverkettung kann der Zugriff auf mehrere Objekte (z. B. mehrere Tabellen)
durch Festlegen von Berechtigungen für ein einzelnes Objekt (z. B. eine Sicht) verwaltet
werden. Außerdem bietet diese Funktion einen kleinen Leistungsvorteil in Szenarien, in
denen Berechtigungsprüfungen übersprungen werden können.
Datenbankübergreifende Besitzverkettung
SQL Server kann so konfiguriert werden, dass zwischen spezifischen Datenbanken oder
für alle Datenbanken in einer einzelnen Instanz die Besitzverkettung zugelassen wird.
Die datenbankübergreifende Besitzverkettung ist standardmäßig deaktiviert und sollte
nur dann aktiviert werden, wenn sie erforderlich ist.
29
Mögliche Gefährdungen
Die Besitzverkettung ist eine sehr nützliche Funktion beim Verwalten von
Berechtigungen für eine Datenbank. Allerdings wird vorausgesetzt, dass die
Objektbesitzer alle Konsequenzen jeder einzelnen Entscheidung beim Erteilen von
Objektberechtigungen vorhersehen. In Abbildung 3 besitzt Mary die meisten Objekte,
die der July2003-Sicht zugrunde liegen. Sie ist berechtigt, anderen Benutzern Zugriff
auf ihre Objekte zu gewähren. Jedes Mal, wenn Mary anderen Benutzern Zugriff auf die
erste Sicht in einer Kette gewährt, ist das Verhalten von SQL Server so, als hätte Mary
bewusst die Entscheidung getroffen, die Sichten und Tabelle freizugeben, auf die
verwiesen wird. In Wirklichkeit ist dies jedoch meist keine gültige Annahme.
Produktionsdatenbanken sind wesentlich komplexer als die in Abbildung 3 dargestellte
Datenbank. Auch die Berechtigungen für den Zugriff können selten perfekt den
Verwaltungsstrukturen von Organisationen zugeordnet werden.
Beachten Sie, dass Mitglieder von Datenbankrollen mit umfassenden Berechtigungen die
datenbankübergreifende Besitzverkettung zum Zugreifen auf Objekte in externen
Datenbanken verwenden können. Wenn z. B. die datenbankübergreifende
Besitzverkettung zwischen Datenbank A und Datenbank B aktiviert ist, kann sich ein
Mitglied der festen Datenbankrolle db_owner in einer dieser Datenbanken Zugriff auf
die andere Datenbank verschaffen. Der Vorgang ist einfach: Diane (db_owner-Mitglied
in Datenbank A) erstellt den Benutzer Stuart in Datenbank A. Stuart ist bereits als
Benutzer in Datenbank B vorhanden. Diane erstellt dann in Datenbank A ein Objekt (mit
Stuart als Besitzer), das ein Objekt von Stuart in Datenbank B aufruft. Da das
aufrufende und das aufgerufene Objekt denselben Besitzer aufweisen, werden in
Datenbank B die Objektberechtigungen nicht überprüft, wenn Diane über das von ihr
erstellte Objekt zugreift.
Anmerkung Die Besitzverkettung gilt für DML-Vorgänge (Data Manipulation
Language, Datenbearbeitungssprache) (SELECT, UPDATE, INSERT, DELETE), aber
nicht für DDL-Vorgänge (Data Definition Language, Datendefinitionssprache).
Implementierung von Sicherheit auf
Serverebene
Verwenden von Sicherheits-IDs
Von SQL Server 2000 wird überprüft, ob der Sicherheits-ID (Security Identifier, SID)
oder Gruppenmitgliedschafts-SIDs des Benutzers der Zugriff auf den Server explizit
verweigert wurde. In diesem Fall wird dem Benutzer kein Zugriff auf den Server
gewährt. Wird dem Benutzer der Zugriff nicht explizit verweigert, überprüft der Server,
ob dem Benutzer der Zugriff direkt oder über eine Gruppenmitgliedschaft gewährt
wurde. Wurde Zugriff gewährt, wird die Verbindung mit SQL Server 2000 beibehalten.
Anschließend wird der Vorgang für den Benutzer mit der entsprechenden
Standarddatenbank fortgesetzt (auf die der Benutzer ebenfalls Zugriff haben muss).
Die Zugriffsrechte des Benutzers werden dann für alle Objekte überprüft, auf die der
Benutzer zuzugreifen versucht. Wenn der Zugriff für einen bestimmten Satz an
Anmeldeinformationen nicht gewährt wurde, wird die Verbindung mit dem Server
beendet.
30
Wenn einem Windows-Benutzer oder einer Windows-Gruppe der Zugriff auf
SQL Server 2000 gewährt oder verweigert wird, werden diese Informationen in der
sysxlogins-Systemtabelle gespeichert. Auf die Tabelle wird später eingegangen. Von
SQL Server 2000 werden anhand der SID sowie der Gruppenmitgliedschafts-SIDs die
Benutzer identifiziert, die eine vertraute Verbindung verwenden.
Generierung von GUIDs für nicht vertraute
Benutzer
Für nicht vertraute Verbindungen – wenn z. B. SQL Server 2000 auf einem Computer
unter Windows 98 installiert ist – stehen Windows-SIDs nicht zur Verfügung. In diesem
Fall wird von SQL Server 2000 ein global eindeutiger Bezeichner (Globally Unique
Identifier, GUID) mit 16 Byte generiert. Die generierte GUID wird dann intern auf
dieselbe Weise wie Windows-SIDs für Windows-Benutzer und -Gruppen verwendet.
Umbenennen von Windows-Benutzerkonten
oder -Gruppenkonten
Wenn ein Windows-Benutzer oder eine Windows-Gruppe mit dem Tool BenutzerManager für Domänen unter Windows NT 4.0 oder dem Dienstprogramm
Active Directory-Benutzer und -Computer umbenannt wird, sind für SQL Server 2000
keine Informationen zu dieser Änderung verfügbar. Aus Leistungsgründen wird der voll
gekennzeichnete Name des Benutzers oder der Gruppe von SQL Server 2000 in der
sysxlogins-Tabelle verwaltet, da das Abfragen dieser Informationen vom
Domänencontroller sehr langsam sein kann. Dies trifft zu, wenn viele Namen gesucht
werden oder der Domänencontroller über ein langsames WAN (Wide Area Network)
verbunden ist.
Durch die Möglichkeit von Namensabweichungen zwischen SQL Server 2000-Benutzern
sowie -Gruppen und Windows-Benutzern sowie -Gruppen entstehen keine
Sicherheitsprobleme. Die für den Benutzer oder die Gruppe festgelegten Berechtigungen
gelten auch weiterhin ordnungsgemäß, da von SQL Server intern nur die SIDs
verwendet werden.
Wenn die Funktionen SUSER_SNAME() und SUSER_SID() zum Zurückgeben des
Benutzernamens bzw. der SID des Benutzers verwendet werden, wird zuerst die
sysxlogins-Tabelle abgefragt. Die lokale Sicherheitsinstanz (Local Security Authority,
LSA) von Windows wird nur dann abgefragt, wenn die sysxlogins-Tabelle weder den
Benutzernamen noch die SID enthält.
Außerdem sind bei Verwendung dieser Funktionen die Benutzernamen in
Systemmeldungen möglicherweise nicht aktuell.
31
Sichten der sysxlogins-Systemtabelle
Die sysxlogins-Systemtabelle enthält Informationen zu Benutzernamen. Auf diese
Systemtabelle, die nur in der master-Datenbank vorhanden ist, sollte nur über folgende
Sichten zugegriffen werden:

Syslogins – Diese Sicht stellt Informationen zu SQL Server-Benutzernamen bereit
und enthält zum leichteren Verständnis eine Interpretation der status-Spalte.

Sysremotelogins – Diese Sicht enthält eine Zeile für jeden Remotebenutzer, der
remote gespeicherte Prozeduren in SQL Server aufrufen darf.

Sysoledbusers – Diese Sicht enthält eine Zeile für jede Zuordnung zwischen einem
Benutzer und einem Kennwort für den angegebenen Verbindungsserver.
Implementierung von Sicherheit auf
Objektebene
Überprüfen von Berechtigungen
In SQL Server 2000 werden SIDs zum Identifizieren von Windows-Benutzern und
-Gruppen verwendet. Da SIDs bis zu 85 Byte umfassen können, werden sie in jeder
Datenbank den Benutzer-IDs von SQL Server zugeordnet. Die Zuordnung der SIDs zu
den Benutzer-IDs erfolgt in der sysusers-Tabelle. Mithilfe der Benutzer-ID von
SQL Server wird dann in der sysobjects-Tabelle der Besitzer einer Tabelle angegeben.
Außerdem wird sie in der syspermissions-Tabelle zum Festlegen von
Objektberechtigungen sowie in der systypes-Tabelle zum Angeben des Besitzers eines
benutzerdefinierten Typs verwendet.
Wenn ein Windows-Benutzer eine Verbindung mit SQL Server 2000 herstellt, erstellt der
Server eine Prozessstatusstruktur (PSS) im Arbeitsspeicher, die die SID des Benutzers,
die Gruppen-SIDs sowie andere Sicherheits- und Zustandsinformationen umfasst. Diese
Struktur ist ein Snapshot des Moments, in dem sich der Benutzer anmeldet. Der
Snapshot wird nicht aktualisiert. Pro Sitzungsverbindung mit dem Server ist eine solche
Struktur vorhanden. Ein einzelner Windows-Benutzer, der mehrere Sitzungen mit
SQL Server 2000 herstellt, weist mehrere Prozessstatusstrukturen auf.
Wenn ein Benutzer versucht, auf eine Datenbank zuzugreifen, wird von SQL Server
anhand der sysusers-Tabelle überprüft, ob dem Benutzer der Zugriff direkt oder
aufgrund der Mitgliedschaft in einer Gruppe mit verweigerten Zugriff verweigert wurde.
Wenn dies der Fall ist, wird dem Benutzer der Zugriff tatsächlich verweigert. Andernfalls
wird die sysusers-Tabelle erneut überprüft, und es werden alle Benutzer-IDs
aufgelistet, für die der Benutzer in Frage kommt. Wenn einem Benutzer Zugriff auf die
Datenbank gewährt wurde, wird die sysmembers-Tabelle gescannt, um alle
Rollenmitgliedschaften des Benutzers zu ermitteln. Die Benutzer-IDs aller anwendbaren
Mitgliedschaften werden ermittelt, damit die für diesen Benutzer geeigneten
Berechtigungen angewendet werden können. Im Gegensatz zu den
Prozessstatusstrukturen werden diese Informationen nicht dauerhaft gespeichert.
32
Sobald der SQL Server-Benutzer auf Datenbankobjekte zugreift, werden die
anwendbaren Berechtigungen ermittelt, indem die syspermissions-Tabelle auf Einträge
mit übereinstimmenden Benutzer-IDs (wie vorher identifiziert) überprüft wird. Vom
System wird zuerst überprüft, ob Berechtigungen mit der DENY-Anweisung verweigert
wurden. In diesem Fall wird dem Benutzer der angeforderte Zugriff auf das Objekt nicht
gewährt. Werden jedoch keine mit DENY verweigerten Berechtigungen gefunden und
sind Einträge vorhanden, mit denen dem Benutzer der angeforderte Zugriff gewährt
wird, wird der Zugriff gewährt. Die tatsächlichen Zugriffsberechtigungen werden dann
aus Leistungsgründen zwischengespeichert.
Aufwand zum Ändern von Berechtigungen
Wie bereits beschrieben, werden die SQL Server 2000-Objektberechtigungen pro Sitzung
zwischengespeichert, um den Prüfaufwand für wiederholten Zugriff auf dieselben
Objekte zu vermeiden. Im Gegensatz zur Prozessstatusstruktur, in der die
Sicherheitsinformationen nach der Erstellung nicht mehr geändert werden, wird der
Berechtigungscache fortlaufend aktualisiert. Dies wird mittels einer Versionsverwaltung
implementiert.
Bei der ersten Überprüfung wird den Berechtigungen eine Versionsnummer zugewiesen.
Wenn die Berechtigungen für ein Objekt geändert werden, wird der Versionszähler von
SQL Server 2000 erhöht. Bei jedem Zugriff auf ein Objekt wird der Wert des
Berechtigungszählers überprüft. Wenn er vom zwischengespeicherten Wert abweicht,
wird der Cacheinhalt verworfen, und die Objektberechtigungen werden erneut ermittelt.
Umbenennen von Windows-Benutzerkonten oder Gruppenkonten
Mit SQL Server 2000 können Sie Windows-Benutzern und -Gruppen
Zugriffsberechtigungen für Objekte in der Datenbank direkt erteilen. In diesem Fall
werden die SID und die Namen der Windows-Benutzer oder -Gruppen in der sysusersTabelle gespeichert.
Wenn der Windows-Administrator die Windows-Gruppe oder den -Benutzer umbenennt,
wird die Namensänderung nicht an SQL Server 2000 propagiert. Es ist wichtig, die
Gründe für dieses Verhalten zu verstehen.
Ebenso wie in früheren Versionen schreiben Administratoren und Entwickler auch in
SQL Server 2000 zahlreiche gespeicherte Prozeduren, Transact-SQL-Skripts, Trigger
usw. Angenommen, Susie Jones ist eine Benutzerin, die eine Tabelle in der Datenbank
erstellt. Ihr Benutzername lautet SUSIEJ, und ihre Tabelle heißt SUSIEJ.SALESDEMO.
Susie erteilt anderen Benutzern Zugriffsberechtigungen für die Tabelle, und mehrere
dieser Benutzer erstellen Sichten und gespeicherte Prozeduren auf Grundlage der
Tabelle. Nach Susies Hochzeit mit Bob Taylor wird ihr Benutzername in SUSIET
umbenannt. Übernähme SQL Server 2000 die Änderung, hieße die Tabelle plötzlich
SUSIET.SALESDEMO, wäre also ein anderes Objekt. Alle Sichten, gespeicherten
Prozeduren und der gesamte Code zum Zugreifen auf die Tabelle könnten dann nicht
mehr ordnungsgemäß verwendet werden. Deshalb werden SQL Server 2000Benutzerkonten nicht automatisch umbenannt, wenn das Windows-Konto im WindowsBenutzerverzeichnis umbenannt wird.
33
WITH GRANT OPTION
Die WITH GRANT OPTION-Klausel ist ein optionales Syntaxelement, das in der GRANTAnweisung verwendet werden kann. Diese Option wird nur auf Objektberechtigungen
angewendet und ermöglicht dem Empfänger der GRANT-Anweisung, die Berechtigung
weiterzugeben.
Wenn Bob z. B. Jane SELECT-Berechtigungen mit der WITH GRANT OPTION-Klausel
erteilt, kann Jane anderen Benutzern ebenfalls SELECT-Berechtigungen erteilen.
Wenn Bob die SELECT-Berechtigungen für Jane aufhebt, kann er mit der Option
CASCADE auch die SELECT-Berechtigungen für die Benutzer aufheben, denen Jane sie
erteilt hat.
sysusers-Systemtabelle
In gewisser Hinsicht hat die sysusers-Tabelle für die Datenbank die gleiche Bedeutung
wie die sysxlogins-Tabelle für die Instanz. Die sysusers-Tabelle ist in jeder Datenbank
vorhanden und enthält Informationen zu den Benutzern, denen der Zugriff auf die
Datenbank gewährt oder verweigert wird.
hasdbaccess-Spalte
Die hasdbaccess-Spalte der sysusers-Tabelle wird ähnlich verwendet wie die
hasaccess-Spalte der sysxlogins-Tabelle. Der Wert in dieser Spalte wird auf Null (0)
festgelegt, wenn der entsprechende Benutzer keine Zugriffsrechte für die Datenbank
besitzt, aber Objekte erstellt, explizit Berechtigungen für Datenbankobjekte erhält oder
explizit zu einer Rolle hinzugefügt wird.
Werden Objekte von einem Benutzer erstellt, ist dieser Benutzer in der Regel der
Objektbesitzer. Die Objekte gehören also nicht der Gruppe, über die dem Benutzer der
Zugriff auf die Datenbank gewährt wurde. Durch diesen direkten Besitz werden
Mehrdeutigkeiten vermieden, wenn ein Benutzer, der ein Objekt erstellt, Mitglied
mehrerer Gruppen mit den notwendigen Berechtigungen ist. Allerdings gibt es für diese
Regel eine Ausnahme. Ein Objekt kann direkt einer Rolle oder einer Windows-Gruppe
gehören, wenn der erstellende Benutzer bei der Objekterstellung den Besitz explizit der
Rolle oder Gruppe zuweist. Beispiel:
CREATE TABLE [builtin\administrators].test_table(acolumn VARCHAR(2))
In dieser Situation muss ein Eintrag für den Benutzer in der sysusers-Tabelle
vorhanden sein, damit das Objekt den geeigneten Besitzer bekommen kann. Der Eintrag
wird zwar automatisch erstellt, aber der Benutzer erhält nicht automatisch expliziten
Zugriff auf die Datenbank, da das hasaccess-Flag auf Null (0) festgelegt ist.
Bei Rollen, die auch in der sysusers-Tabelle aufgelistet werden, ist die hasdbaccessSpalte auf Null (0) festgelegt.
34
sysmembers-Systemtabelle
Die sysmembers-Systemtabelle wird zum Aufzeichnen der Mitgliedschaft von Benutzern
in Datenbankrollen verwendet. Sie ist eine der kleineren Tabellen und enthält nur zwei
Spalten sowie eine Zeile für jedes Mitglied einer Datenbankrolle.
Von SQL Server 2000 wird die erste Rollenmitgliedschaft eines Benutzers in die
gid-Spalte der sysusers-Tabelle platziert. Zum Identifizieren aller Rollen, zu denen ein
Mitglied gehört, muss von SQL Server 2000 daher nicht die sysmembers-Tabelle
abgefragt werden, wenn die gid-Spalte der sysusers-Tabelle auf Null (0) festgelegt ist.
Wenn der Eintrag in dieser Spalte nicht Null ist, gibt der Eintrag eine der Rollen an, und
die sysmembers-Tabelle muss nach einer vollständigen Liste aller Rollen abgefragt
werden, denen der Benutzer angehört.
syspermissions-Systemtabelle
Die syspermissions-Systemtabelle ist in jeder Datenbank vorhanden und dient zum
Nachverfolgen der Berechtigungen, die Benutzern erteilt oder verweigert wurden.
Die syspermissions-Systemtabelle besteht aus sehr wenigen Spalten. Die id-Spalte
verweist auf die Objekt-ID, für die die Berechtigungen erteilt oder verweigert werden.
Für Anweisungsberechtigungen ist diese Spalte auf Null (0) festgelegt.
Die grantee-Spalte enthält den Namen des Benutzers, dem die Berechtigungen erteilt
werden. Die grantor-Spalte enthält den Namen des Benutzers, der sie erteilt. Der hier
verwendete Wert entspricht der ID der Rolle, des Windows-Benutzers oder der WindowsGruppe in der sysusers-Tabelle.
Die actadd-Spalte verweist auf die positive Berechtigung (d. h. erteilte Berechtigungen)
für alle Spalten (im Fall einer Tabelle) des Objekts, während die actmod-Spalte auf alle
negativen (d. h. verweigerten) Berechtigungen für alle Spalten (im Fall einer Tabelle)
des Objekts verweist.
Die restlichen Spalten werden nur verwendet, wenn Berechtigungen auf Spaltenebene
implementiert werden. Die seladd-Spalte bezieht sich auf erteilte SELECTBerechtigungen. Dabei handelt es sich um ein Bitmuster der Spalten, für die diese
Berechtigung erteilt wurde. Da Spalten-IDs nie wiederverwendet werden, ist ein
Bitmuster sehr gut geeignet. Die selmod-Spalte bezieht sich auf verweigerte SELECTBerechtigungen.
Die nächsten zwei Spalten werden wie die beiden vorherigen implementiert, beziehen
sich jedoch auf UPDATE-Berechtigungen.
Die letzten zwei Spalten verweisen auf REFERENCES-Berechtigungen und werden wie die
vorherigen vier Spalten implementiert.
35
Berechtigungen für Named Pipes und
Multiprotokoll
Die Named Pipes-Netzwerkbibliothek ist ein IPC-Mechanismus (Inter-Process
Communications, prozessübergreifende Kommunikation), der unter Windows über die
Freigabe IPC$ implementiert wird. Wenn ein Client mithilfe der Named PipesNetzwerkbibliothek eine Verbindung mit SQL Server herstellt, wird die Verbindung mit
der Freigabe IPC$ hergestellt. Zu diesem Zeitpunkt erfolgt die Authentifizierung. Nach
der Clientauthentifizierung durch Windows (wie beim Zugriff auf andere Ressourcen)
wird die Named Pipes-Sitzung über die Freigabe IPC$ hergestellt. Dies erfolgt vor dem
Versuch, die Verbindung an SQL Server zu übergeben.
Alle Benutzer, die über die Named Pipes-Netzwerkbibliothek eine Verbindung mit
SQL Server herstellen, müssen über ein Windows-Konto und Windows-Berechtigungen
zum Zugriff auf die Freigabe IPC$ verfügen. Wenn diese Authentifizierung nicht
ausgeführt werden soll, muss zu einer anderen Netzwerkbibliothek gewechselt werden,
wie TCP/IP-Sockets oder Multiprotokoll, da diese Verbindungen nicht anhand der
Windows-Freigabe IPC$ überprüft werden. Beachten Sie, dass TCP/IP-Sockets die
Standard-Netzwerkbibliothek in SQL Server 2000 ist.
Mit der Multiprotokoll-Netzwerkbibliothek erfolgt die Windows-Authentifizierung vor dem
Übergeben der Verbindung durch SQL Server 2000. Der Grund ist, dass der Client durch
die Laufzeitdienste für den Remoteprozeduraufruf (Remote Procedure Call, RPC)
authentifiziert wird, wenn die Verbindung angefordert wird. Ebenso wie die
Named Pipes-Netzwerkbibliothek erfordert die Multiprotokoll-Netzwerkbibliothek ein
gültiges Windows-Konto.
Beachten Sie, dass die Multiprotokoll-Netzwerkbibliothek nicht zum Herstellen von
Verbindungen mit benannten Instanzen von SQL Server 2000 verwendet werden kann.
Installation eines sicheren Servers
Physische und logische Isolierung bilden die Grundlage der SQL Server-Sicherheit.
Computer, auf denen eine Datenbank gehostet wird, sollten sich an einem physisch
geschützten Standort befinden. Ideal wäre ein abgeschlossener Computerraum mit
überwachten Überschwemmungs- und Brandschutzsystemen. Datenbanken sollten in
der sicheren Zone des Unternehmensintranets installiert und nie direkt mit dem Internet
verbunden sein. Außerdem sollten alle Daten regelmäßig gesichert und die Kopien an
einem sicheren Ort außerhalb des Unternehmensstandorts aufbewahrt werden.
Anleitungen zu Sicherungsverfahren und anderen bewährten Methoden finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15393.
36
Dateisystem
Das für SQL Server-Installationen bevorzugte Dateisystem ist NTFS. NTFS ist stabiler als
FAT-Dateisysteme, Daten können einfacher wiederhergestellt werden, und zudem sind
Sicherheitsoptionen möglich, wie Zugriffssteuerungslisten (Access Control Lists, ACLs)
für Dateien und Verzeichnisse sowie die Dateiverschlüsselung (Encrypted File System,
EFS). Während der Installation werden von SQL Server geeignete ACLs für
Registrierungsschlüssel und Dateien festgelegt, wenn NTFS erkannt wird. Diese
Berechtigungen sollten nicht geändert werden.
Mit EFS werden Datenbankdateien mit der Identität des Kontos verschlüsselt, mit dem
SQL Server ausgeführt wird. Die Dateien können nur mit diesem Konto entschlüsselt
werden. Wenn Sie das Konto ändern möchten, mit dem SQL Server ausgeführt wird,
müssen Sie zuerst die Dateien mit dem alten Konto entschlüsseln und sie anschließend
mit dem neuen Konto neu verschlüsseln.
Von SQL Server 2000 Setup werden dem Dienstkonto bzw. den Dienstkonten
automatisch vollständige Zugriffsberechtigungen für die SQL Server-Dateien erteilt.
Der lokalen Administratorengruppe wird ebenfalls Vollzugriff gewährt.
Firewalls
Teilen Sie Ihr Netzwerk in durch Firewalls getrennte Sicherheitszonen auf. Blockieren Sie
zunächst den gesamten Datenverkehr, und lassen Sie dann nur den erforderlichen zu.
Vor dem Installieren von SQL Server sollten Sie sicherstellen, dass der Umkreisfirewall
Pakete herausfiltert, die an den TCP-Port 1433 (überwacht von der Standardinstanz) und
an den UDP-Port 1434 (überwacht von einer der Instanzen auf dem Computer)
adressiert sind. Zusätzliche Ports, die benannten Instanzen zugeordnet sind, sollten
ebenfalls im Umkreisfirewall blockiert werden. Weitere Informationen finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15394 sowie in Firewalls and Internet Security:
Second Edition (siehe „Weitere Informationsquellen“ weiter unten in diesem
Whitepaper).
Wenn Sie den Server in einer Windows-Domäne installieren, sollten Sie innere Firewalls
konfigurieren, um die Windows-Authentifizierung zuzulassen. Öffnen Sie die Ports, die
von der Kerberos- oder NTLM-Authentifizierung verwendet werden. Wenn die
Anwendung die Replikation verwendet, sollten Sie das Thema „Konfigurieren eines
TCP/IP abfragenden Verlegers oder Verteilers“ lesen, das über
http://go.microsoft.com/fwlink/?LinkId=15402 verfügbar ist. Wenn Ihre Anwendung
verteilte Transaktionen verwendet, müssen Sie möglicherweise auch den Firewall so
konfigurieren, dass DTC-Datenverkehr (Microsoft Distributed Transaction Coordinator)
zwischen verschiedenen DTC-Instanzen sowie zwischen DTC und Ressourcen-Managern,
wie SQL Server, möglich ist. Weitere Informationen finden Sie in Artikel 250367,
„Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a
Firewall“, in der Microsoft Knowledge Base unter
http://go.microsoft.com/fwlink/?LinkId=16419.
37
Deaktivieren von NetBIOS und SMB
Für die Server im Umkreisnetzwerk sollten alle unnötigen Protokolle deaktiviert werden,
einschließlich NetBIOS und SMB (Server Message Block). Für Webserver und
DNS-Server (Domain Name System) sind NetBIOS und SMB nicht erforderlich.
Beide Protokolle sollten deaktiviert werden, um Angriffen durch Benutzerenumeration
vorzubeugen.
NetBIOS verwendet folgende Ports:

UDP/137 (NetBIOS-Namensdienst)

UDP/138 (NetBIOS-Datagrammdienst)

TCP/139 (NetBIOS-Sitzungsdienst)
SMB verwendet folgende Ports:

TCP/139

TCP/445
Auf Servern, auf die vom Internet zugegriffen werden kann, sollte SMB deaktiviert
werden. Deaktivieren Sie hierfür in den Eigenschaften für die LAN-Verbindung im
TCP/IP-Eigenschaftendialogfeld die Optionen Datei- und Druckerfreigabe für
Microsoft-Netzwerke und Client für Microsoft-Netzwerke.
So deaktivieren Sie SMB
1. Zeigen Sie im Startmenü auf Einstellungen, und klicken Sie dann auf Netzwerkund DFÜ-Verbindungen.
2. Klicken Sie mit der rechten Maustaste auf die dem Internet zugewandte Verbindung,
und klicken Sie dann auf Eigenschaften.
3. Wählen Sie Client für Microsoft-Netzwerke aus, und klicken Sie dann auf
Deinstallieren.
4. Führen Sie die Schritte zum Deinstallieren aus.
5. Wählen Sie Datei- und Druckerfreigabe für Microsoft-Netzwerke aus, und
klicken Sie dann auf Deinstallieren.
6. Führen Sie die Schritte zum Deinstallieren aus.
So deaktivieren Sie NetBIOS über TCP/IP
1. Klicken Sie mit der rechten Maustaste auf dem Desktop auf Arbeitsplatz, und
klicken Sie dann auf Verwalten.
2. Erweitern Sie System, und wählen Sie dann Geräte-Manager aus.
3. Klicken Sie mit der rechten Maustaste auf Geräte-Manager, zeigen Sie auf Ansicht,
und klicken Sie dann auf Ausgeblendete Geräte anzeigen.
4. Erweitern Sie Nicht-PnP-Treiber.
5. Klicken Sie mit der rechten Maustaste auf NetBios über TCP/IP, und klicken Sie
dann auf Deaktivieren.
38
Damit wird der direkte SMB-Hostlistener für TCP/445 und UDP 445 deaktiviert.
Anmerkung Mit diesem Verfahren wird der Treiber Nbt.sys deaktiviert. Im
Dialogfeld Erweiterte TCP/IP-Einstellungen enthält die Registerkarte WINS die
Option NetBIOS über TCP/IP deaktivieren. Wenn diese Option aktiviert wird,
wird nur der NetBIOS-Sitzungsdienst deaktiviert (der den TCP-Port 139 abfragt).
SMB wird jedoch nicht vollständig deaktiviert. Führen Sie hierzu die unten genannten
Schritte aus.
Schritte vor dem Ausführen von
SQL Server Setup
Isolieren Sie beim Planen einer SQL Server-Installation die Komponenten. So wird die
Gefahr verringert, dass im Fall eines Angriffs über eine Komponente auch andere
Komponenten im System angegriffen werden. Sie müssen vermeiden, dass Ihr Server
den Schwachstellen anderer Software ausgesetzt ist (und umgekehrt). Im Folgenden
werden bewährte Methoden genannt:

Verwenden Sie einen dedizierten Computer als Datenbankserver.

Installieren Sie SQL Server nicht auf einem Domänencontroller.

Führen Sie Microsoft Internetinformationsdienste bzw. Internet Information Server
(IIS) und SQL Server nicht auf demselben Computer aus.

Wenn Sie mehrere Dienste auf demselben Computer ausführen, sollten Sie jeden
Dienst mit einem eigenen Windows-Konto ausführen.

Installieren Sie die Programm- und Datenbankdateien von SQL Server auf einem
Volume, das kein Systemvolume und vom Betriebssystem getrennt ist.
Von SQL Server installierte Elemente
Beim Installieren von SQL Server wird neben Programm- und Datendateien eine Reihe
von Windows-Diensten installiert, die sich standardmäßig unter
\Programme\Microsoft SQL Server befinden. In der folgenden Tabelle werden die
Dienste und Ordner aufgelistet, die in Abhängigkeit von den ausgewählten SetupOptionen erstellt werden können.
Anmerkung Im Mittelpunkt der folgenden Ausführungen steht SQL Server.
Detaillierte Erläuterungen zu Replikation, Analysis Services oder
Data Transformation Services erhalten Sie über
http://go.microsoft.com/fwlink/?LinkId=15402.
39
Element
Details
Dienste
MSSQLSERVER
MSSQLServerADHelper
Microsoft Search
SQLSERVERAGENT
Ordner
\Programme\Microsoft SQL Server\Mssql\Binn (Programmdateien)
\Programme\Microsoft SQL Server\Mssql\Data (Datendateien,
einschließlich MDF-, LOG- und NDF-Dateien)
\Programme\Microsoft SQL Server\80\Tools (gemeinsam
verwendete Tools und Onlinedokumentation)
\Programme\Microsoft SQL Server\Mssql\Logs (Fehlerprotokolle)
\Programme\Microsoft SQL Server\Mssql\Backup
(Sicherungsdateien)
\Programme\Microsoft SQL Server\Mssql\Jobs (temporäre
Auftragsausgabedateien)
Für benannte Instanzen wird der Instanzname wie folgt im Dateipfad
verwendet:
\Programme\Microsoft SQL Server\MSSQL$InstanceName\Binn
\Programme\Microsoft SQL Server\MSSQL$InstanceName\Data
Installieren von SQL Server
Wählen Sie während des Setups von SQL Server die Option für das benutzerdefinierte
Setup aus. So können Sie wählen, welche Elemente installiert werden sollen. Auf einem
Produktions-Datenbankserver sollten nur erforderliche Komponenten installiert werden.
Die folgenden Elemente sollten nicht installiert werden.
Tool
Zweck
Aktualisierungstools
Aktualisieren von Datenbanken von SQL Server,
Version 6.5.
Leistungsindikatoren
Überwachen und Optimieren der Leistung.
Onlinedokumentation
SQL Server-Dokumentation.
Entwicklungstools
Enthält Header und Bibliotheksdateien, die von
C-Entwicklern verwendet werden, sowie SDKs für MDAC
und XML und eine Oberfläche zum Debuggen
gespeicherter Prozeduren.
Codebeispiele
Beispielcode zur Fortbildung von Entwicklern.
40
Sie sollten möglichst den Windows-Authentifizierungsmodus für Verbindungen mit
SQL Server erforderlich machen. So wird die SQL Server-Installation vor den meisten
Angriffen aus dem Internet geschützt, da die Verbindungen auf WindowsBenutzerkonten und -Domänenbenutzerkonten eingeschränkt werden. Außerdem sind
die Windows-Mechanismen zur Sicherheitsdurchsetzung für Ihren Server vorteilhaft, wie
z. B. sicherere Authentifizierungsprotokolle sowie obligatorische Komplexität und
Ablaufdaten der Kennwörter. Zudem steht die Delegierung der Anmeldeinformationen
(die Möglichkeit, Anmeldeinformationen über mehrere Server hinweg weiterzugeben)
nur mit dem Windows-Authentifizierungsmodus und Kerberos zur Verfügung. Mit dem
Windows-Authentifizierungsmodus ist eine clientseitige Speicherung von Kennwörtern
nicht notwendig. Anwendungen mit SQL Server-Standardbenutzernamen sind durch
diese Speicherung anfälliger für Angriffe.
Während der Installation werden Sie aufgefordert, ein Kennwort für das Konto sa
festzulegen. Das Konto sa sollte immer ein sicheres Kennwort aufweisen, auch auf
Servern, in deren Konfiguration die Windows-Authentifizierung erforderlich gemacht
wird. So wird sichergestellt, dass kein leeres oder unsicheres Kennwort für sa offen
gelegt wird, wenn der Server später für den gemischten Authentifizierungsmodus
konfiguriert wird.
Planen Sie nicht, das Konto sa für tägliche Verwaltungsarbeiten zu verwenden. Microsoft
empfiehlt, SQL Server-Administratoren den Zugriff auf SQL Server über die
Mitgliedschaft in einer Windows-Gruppe zu gewähren, die Mitglied der festen Serverrolle
sysadmin in SQL Server ist. Dieser Ansatz hat einen kleinen Nachteil: WindowsAdministratoren können jedes Benutzerkonto zu einer Windows-Gruppe hinzufügen.
Wenn eine Windows-Gruppe Mitglied der festen Serverrolle sysadmin ist, können
Windows-Administratoren daher jedem Benutzer sysadmin-Berechtigungen in
SQL Server 2000 erteilen, indem sie das Benutzerkonto zu dieser Windows-Gruppe
hinzufügen. Falls dies ein Problem darstellt, sollten Sie nur einzelne WindowsBenutzerkonten zur festen Serverrolle sysadmin hinzufügen.
Dienste
SQL Server 2000 und der SQL Server-Agent werden als Windows-Dienste ausgeführt.
Jeder Dienst muss einem Windows-Konto zugeordnet sein. Von diesem Konto wird der
Sicherheitskontext für den Dienst abgeleitet. SQL Server ermöglicht Mitgliedern der
festen Serverrolle sysadmin das Zugreifen auf Funktionen des Betriebssystems. Diese
Betriebssystemaufrufe erfolgen im Sicherheitskontext des Windows-Kontos, das den
Serverprozess besitzt. Wenn Angreifer sich Zugriff auf den Server verschafft haben,
können diese Betriebssystemaufrufe zum Ausweiten des Angriffs auf jede andere
Ressource verwendet werden, auf die der besitzende Windows-Prozess (das SQL ServerDienstkonto) Zugriff hat. Aus diesem Grund ist es wichtig, den SQL Server-Diensten nur
die erforderlichen Rechte zu gewähren. Folgende Einstellungen werden empfohlen.
41
SQL Server-Modul/MSSQLServer
Hierbei handelt es sich um das SQL Server-Datenbankmodul, den einzigen
obligatorischen Dienst. Führen Sie das Modul mit einem WindowsDomänenbenutzerkonto mit regulären Zugriffsrechten aus. Führen Sie es nicht mit
einem lokalen Systemkonto, lokalen Administratorkonto oder
Domänenadministratorkonto aus. Falls benannte Instanzen vorhanden sind, lautet ihr
Name MSSQL$InstanceName.
SQL Server-Agent-Dienst/SQLServerAgent
Hierbei handelt es sich um einen Unterstützungsdienst, mit dem Befehle geplant und bei
Fehlern Operatoren benachrichtigt werden können. Deaktivieren Sie diesen Dienst, wenn
er in Ihrer Umgebung nicht erforderlich ist. Führen Sie ihn andernfalls mit einem
Windows-Domänenbenutzerkonto mit regulären Benutzerrechten aus. Führen Sie ihn
nicht mit einem lokalen Systemkonto, lokalen Administratorkonto oder
Domänenadministratorkonto aus. Falls benannte Instanzen vorhanden sind, lautet ihr
Name SQLAgent$InstanceName.
Wichtig Der SQL Server-Agent benötigt lokale Windows-Administratorrechte, wenn
eine der folgenden Bedingungen zutrifft:
Vom SQL Server-Agent wird mithilfe der SQL Server-Authentifizierung eine
Verbindung mit SQL Server hergestellt (nicht empfohlen).
Für den SQL Server-Agent wird ein MSX-Konto (Masterserverkonto) der
Multiserververwaltung verwendet, für das mithilfe der SQL ServerAuthentifizierung eine Verbindung hergestellt wird.
Vom SQL Server-Agent werden Microsoft ActiveX-Skriptaufträge oder
CmdExec-Aufträge ausgeführt, deren Besitzer Benutzer sind, die keine Mitglieder
der festen Serverrolle sysadmin sind.
Hilfsdienst von SQL Server für
Active Directory/MSSQLServerADHelper
Dieser Dienst unterstützt die Active Directory-Integration, einschließlich der DatenbankInstanzregistrierung. Deaktivieren Sie ihn, wenn er in Ihrer Umgebung nicht erforderlich
ist. Führen Sie ihn andernfalls mit dem lokalen Windows-Systemkonto aus.
Microsoft Search
Dieser Dienst stellt Funktionen für die Volltextsuche bereit. Deaktivieren Sie ihn, wenn
er in Ihrer Umgebung nicht erforderlich ist. Führen Sie ihn andernfalls mit dem lokalen
Systemkonto aus.
42
Microsoft DTC
Mit diesem Dienst wird die Verarbeitung von Transaktionen koordiniert, die auf
mindestens zwei Server verteilt sind. Deaktivieren Sie ihn, wenn er in Ihrer Umgebung
nicht erforderlich ist.
Verwenden Sie SQL Server Enterprise Manager, wenn Sie das einem SQL Server-Dienst
zugeordnete Konto ändern möchten. Enterprise Manager legt geeignete Berechtigungen
für die Dateien und Registrierungsschlüssel fest, die von SQL Server verwendet werden.
Verwenden Sie niemals das Dienste-Applet von Microsoft Management Console (in der
Systemsteuerung) zum Ändern dieser Konten, da hierfür Dutzende von
Registrierungsberechtigungen, NTFS-Berechtigungen und Windows-Benutzerrechten
manuell angepasst werden müssen – ein Vorgang, der leicht zu Fehlern führen kann.
Weitere Informationen finden Sie in Artikel 283811, „Change the SQL Server Service
Account Without Using SQL Enterprise Manager in SQL Server 2000“, in der
Microsoft Knowledge Base unter http://go.microsoft.com/fwlink/?LinkId=16419. Die
Kontenänderungen treten beim nächsten Start des Dienstes in Kraft. Wenn Sie das
Konto ändern möchten, das SQL Server und dem SQL Server-Agent zugeordnet ist,
müssen Sie die Änderung auf beide Dienste getrennt mithilfe von Enterprise Manager
anwenden.
SQL Server-Konten
Die Autorisierung in SQL Server wird über SQL Server-Benutzernamen,
Datenbankbenutzer und eine Vielzahl an Rollen verwaltet. Mit Benutzernamen wird der
Zugriff auf SQL Server gewährt, aber nicht auf einzelne Datenbanken. Benutzernamen
werden Datenbankbenutzern zugeordnet, um den Zugriff auf einzelne Datenbanken zu
gewähren. Datenbankbenutzer werden in der Regel zu festen oder benutzerdefinierten
Rollen zugewiesen, und den Rollen werden Berechtigungen erteilt, um die Funktionen
des Benutzernamens in der Datenbank festzulegen.
Stellen Sie anhand der folgenden Empfehlungen sicher, dass Sie stringente
Autorisierungseinstellungen auf die Datenbank oder Instanz von SQL Server anwenden.
Entfernen des Serverbenutzernamens
„VORDEFINIERT\Administratoren“
Standardmäßig wird die lokale Windows-Gruppe VORDEFINIERT\Administratoren
zur festen Serverrolle sysadmin hinzugefügt, deren Mitglieder SQL Server verwalten.
Dies bedeutet, dass Domänen- oder Systemadministratoren von Windows, die Mitglieder
von VORDEFINIERT\Administratoren sind, unbeschränkten Zugriff auf SQL ServerDatenbanken haben. Die meisten Unternehmen weisen unterschiedliche Mitarbeiter der
Domänen- und zur Systemadministratorenrolle zu. Entfernen Sie dazu den SQL ServerBenutzernamen VORDEFINIERT\Administratoren, und erstellen Sie eine WindowsGruppe für Datenbank- oder Systemadministratoren.
43
So fügen Sie einen neuen Benutzernamen für Datenbankadministratoren hinzu
1. Starten Sie Enterprise Manager.
2. Erweitern Sie Microsoft SQL Server, SQL Server-Gruppe und dann Ihren Server
mit SQL Server.
3. Erweitern Sie den Ordner Sicherheit, wählen Sie Benutzernamen aus, klicken Sie
mit der rechten Maustaste darauf, und klicken Sie dann auf Neuer Benutzername.
4. Geben Sie in das Feld Name eine benutzerdefinierte Windows-Gruppe ein, die nur
Datenbankadministratoren enthält.
5. Klicken Sie auf die Registerkarte Serverrollen, und wählen Sie
Systemadministratoren aus.
Damit wird der neue Benutzername zur sysadmin-Serverrolle hinzugefügt.
So löschen Sie den Benutzernamen „VORDEFINIERT\Administratoren“
1. Starten Sie Enterprise Manager.
2. Erweitern Sie Microsoft SQL Server, SQL Server-Gruppe und dann Ihren Server
mit SQL Server.
3. Erweitern Sie den Ordner Sicherheit, und wählen Sie Benutzernamen aus.
Wird VORDEFINIERT\Administratoren in der Liste der Benutzernamen angezeigt,
klicken Sie mit der rechten Maustaste darauf, und klicken Sie dann auf Löschen, um
den Benutzernamen zu entfernen.
Weitere Informationen finden Sie in Artikel 263712, „How to Impede Windows NT
Administrators from Administering a Clustered SQL Server“, in der
Microsoft Knowledge Base unter http://go.microsoft.com/fwlink/?LinkId=16419. Weitere
Informationen zum Neukonfigurieren von SQL-Dienstkonten nach der Installation finden
Sie unter http://go.microsoft.com/fwlink/?LinkId=15395.
Kein Aktivieren des SQL-Benutzerkontos „Guest“
Das Benutzerkonto Guest ermöglicht einem Benutzernamen ohne Benutzerkonto den
Zugriff auf eine Datenbank. Das Gastkonto ist standardmäßig in keiner
Benutzerdatenbank aktiviert. Ändern Sie diese Einstellung nicht. Durch das Aktivieren
des Gastkontos in einer Datenbank können authentifizierte Benutzernamen, denen nicht
explizit der Zugriff auf die Datenbank gewährt wurde, mithilfe der
Gastanmeldeinformationen auf die Datenbank zugreifen.
Öffnen Sie in der Computerverwaltung den Ordner Benutzer, um den Status des Kontos
Guest zu überprüfen. Das Gastkonto sollte mit einem kreuzförmigen Symbol angezeigt
werden. Ist es nicht deaktiviert, öffnen Sie das Eigenschaftendialogfeld, und aktivieren
Sie Konto ist deaktiviert. Außerdem sollten Sie das Gastkonto aus allen
benutzerdefinierten Datenbanken entfernen. Beachten Sie, dass Sie Guest weder aus
den Datenbanken master und tempdb noch aus während der Replikation erstellten
Verteilungsdatenbanken entfernen können.
44
Kein Erteilen von Berechtigungen an die publicRolle
Alle Datenbanken enthalten eine public-Datenbankrolle, in der alle Benutzer, Gruppen
und Rollen Mitglied sind. Erteilen Sie dieser Rolle keine zusätzlichen Berechtigungen.
Wenn Sie public Berechtigungen erteilen, erteilen Sie diese Berechtigungen allen
Benutzern der Datenbank, einschließlich Anwendungsrollen, Datenbankrollen und
einzelnen Benutzern. Die bewährte Methode ist das Erteilen spezifischer, erforderlicher
Berechtigungen an ausgewählte Benutzer, Rollen oder Gruppen.
Verschlüsseln von Datendateien mit EFS
Wenn der Server auf einem NTFS-Dateisystem installiert ist, können Sie einige
Datendateien verschlüsseln und so die Sicherheit erhöhen. Sie sollten den durch die
Verschlüsselung bedingten Leistungsverlust auf einem Testserver bewerten, ehe Sie
diese Funktion auf dem Produktionsserver implementieren. In der Regel sind die
Auswirkungen auf die Leistung vernachlässigbar, da die Datendateien entschlüsselt
werden, sobald der Serverprozess gestartet wird.
Verschlüsseln Sie Daten nur auf Dateiebene und nicht auf Verzeichnisebene. Auch wenn
die Verschlüsselung auf Verzeichnisebene bei Verwendung von EFS oft eine bewährte
Methode ist, da neue Dateien verschlüsselt hinzugefügt werden, sollten Sie die
Datendateien von SQL Server nur auf Dateiebene verschlüsseln. So wird das
Verschlüsseln der Protokolldateien vermieden.
So verschlüsseln Sie eine Datei mit EFS
1. Klicken Sie mit der rechten Maustaste auf die Datei.
2. Wählen Sie Eigenschaften aus.
3. Klicken Sie auf Erweitert.
4. Aktivieren Sie Inhalt verschlüsseln, um Daten zu schützen.
Weitere Informationen zu EFS finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15396 und
http://go.microsoft.com/fwlink/?LinkId=15397.
Wählen statischer Ports für benannte
Instanzen
Von der Standardinstanz von SQL Server wird standardmäßig der TCP-Port 1433
abgefragt. Benannten Instanzen werden TCP-Ports jedoch beim Starten des SQL ServerDienstes dynamisch von Windows zugewiesen. Diese Zuordnung benannter Instanzen zu
dynamisch zugewiesenen TCP-Ports kann durch mehrere Neustarts geändert werden.
45
Für Kerberos und für die Delegierungsfunktionalität von SQL Server muss für den
SQL Server-Dienst ein SPN (Service Principal Name, Dienstprinzipalname) registriert
sein. Ein Teil des SPN ist die Portnummer. Das Zuweisen statischer TCP-Ports zu
benannten Instanzen wird daher dringend empfohlen. Mit statischen TCP-Ports werden
nicht nur diese wichtigen Sicherheitsfunktionen aktiviert, sondern sie sind auch beim
Konfigurieren interner Firewalls leichter zu verwalten.
Anmerkung
Öffnen Sie SQL Server-Ports niemals im externen Firewall.
Verwenden Sie die SQL Server-Netzwerkkonfiguration, um jeder benannten Instanz
einen statischen TCP-Port zuzuweisen. Sie müssen TCP-Ports auswählen, die nicht von
anderen Anwendungen auf demselben Computer oder im selben Cluster verwendet
werden. Eine Liste bekannter Ports, die für verschiedene Anwendungen registriert sind,
finden Sie unter http://www.iana.org/. Die Teilnahme des Netzwerkadministrators an
der Planung der Portzuweisungen wird empfohlen.
So weisen Sie einer benannten Instanz einen statischen TCP-Port zu
1. Starten Sie die SQL Server-Netzwerkkonfiguration.
2. Wählen Sie die Registerkarte Allgemein aus.
3. Wählen Sie aus dem Dropdownmenü die benannte Instanz aus.
4. Klicken Sie im Dialogfeld Aktivierte Protokolle auf TCP/IP.
5. Klicken Sie auf die Schaltfläche Eigenschaften.
6. Geben Sie die gewünschte statische Portnummer ein, und klicken Sie auf OK.
Sie müssen den Server neu starten, damit diese Änderungen wirksam werden.
Löschen oder Sichern alter Setup-Dateien
Setup-Dateien von SQL Server enthalten möglicherweise Informationen, die Ihr System
für Angriffe anfällig machen, wie z. B. folgende:

Unzureichend verschlüsselte Anmeldeinformationen.

Anmeldeinformationen, die als Klartext angezeigt werden (gar keine
Verschlüsselung).

Kritische Konfigurationseinstellungen.
In SQL Server 2000 können folgende Dateien betroffen sein: Sqlstp.log, Sqlsp.log und
Setup.iss im Ordner systemdrive:\Programme\Microsoft SQL Server\
MSSQL\Install im Fall einer Standardinstallation bzw. im Ordner
systemdrive:\Programme\Microsoft SQL Server\ MSSQL$InstanceName\Install
im Fall benannter Instanzen.
Wenn das aktuelle System eine Aktualisierung von SQL Server 7.0-Installationen ist,
sollten auch folgende Dateien überprüft werden: Setup.iss im Ordner %Windir% und
Sqlsp.log im Windows-Ordner Temp.
46
Microsoft verteilt das kostenlose Dienstprogramm Killpwd, mit dem Kennwörter gesucht
und aus dem System entfernt werden. Weitere Informationen zu diesem kostenlosen
Download finden Sie in Artikel 263968, „Service Pack Installation May Save Standard
Security Password in File“, in der Microsoft Knowledge Base unter
http://go.microsoft.com/fwlink/?LinkId=16419.
Verwaltung eines sicheren Servers
Es liegt in der Verantwortung der Datenbankadministratoren, die Sicherheit fortlaufend
zu erhalten. Die unten besprochenen Punkte sind besonders wichtig.
Installieren aller Service Packs und
Sicherheitspatches
Die beste Möglichkeit zum Verwalten der Serversicherheit ist das Installieren aller
Sicherheitspatches und Service Packs, sobald sie veröffentlicht werden. Unter
http://go.microsoft.com/fwlink/?LinkId=15399 können Sie E-Mail-Benachrichtigungen
über neue Sicherheitspatches abonnieren.
Überwachen des Servers mit
Microsoft Baseline Security Analyzer
Microsoft Baseline Security Analyzer (MBSA) ist ein Tool, das nach häufigen unsicheren
Konfigurationen in verschiedenen Microsoft-Produkten scannt. Dazu gehören SQL Server
und Microsoft SQL Server 2000 Desktop Engine (MSDE 2000). Das Tool kann lokal oder
über ein Netzwerk ausgeführt werden. SQL Server-Installationen werden z. B. auf
folgende Probleme getestet:

Zu viele Mitglieder der festen Serverrolle sysadmin.

Erteiltes Recht zum Erstellen von CmdExec-Aufträgen an andere Rollen als
sysadmin.

Leere oder leicht zu ermittelnde Kennwörter.

Unsicherer Authentifizierungsmodus.

Zu viele Rechte, die der Gruppe Administratoren erteilt wurden.

Falsche ACLs für SQL Server-Datenverzeichnisse.

Kennwort für sa als Klartext in Setup-Dateien.

Zu viele Rechte, die dem Konto Guest erteilt wurden.

Ausführung von SQL Server auf einem System, das auch als Domänencontroller
verwendet wird.

Nicht angemessene Konfiguration der Gruppe Jeder, mit der der Zugriff auf
bestimmte Registrierungsschlüssel gewährt wird.

Nicht angemessene Konfiguration der SQL Server-Dienstkonten.

Fehlende Service Packs und Sicherheitsaktualisierungen.
47
MBSA kann von der grafischen Benutzeroberfläche (GUI) oder der Befehlszeile
ausgeführt werden. Die GUI-Version stellt für die meisten Benutzer die beste Option dar,
da die Verwendung einfacher ist und ein detaillierter Bericht im XML-Format generiert
wird.
So führen Sie die Befehlszeilenversion aus:
cd "c:\program files\microsoft baseline security analyzer"
mbsacli
MBSA-Berichte verweisen auf Microsoft-Sicherheitsbulletins, in denen mögliche Probleme
beschrieben und Hyperlinks zu Sicherheitspatches angeben werden.
Microsoft verteilt MBSA als kostenlosen Download. Die vollständige Dokumentation und
die neueste MBSA-Version finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15400.
Überwachung
SQL Server unterstützt mehrere Ebenen der Ereignis- und Zustandsüberwachung. Sie
sollten mindestens fehlgeschlagene Verbindungsversuche mit SQL Server protokollieren
und das SQL-Fehlerprotokoll regelmäßig prüfen. Speichern Sie die SQL-Fehlerprotokolle
möglichst nicht auf derselben Festplatte wie die Datendateien. Konfigurieren Sie die
Anmeldeüberwachung mithilfe von SQL Server Enterprise Manager.
Anmeldeüberwachung
So aktivieren Sie die Überwachung fehlgeschlagener Verbindungen mit
Enterprise Manager in SQL Server:
1. Erweitern Sie eine Servergruppe.
2. Klicken Sie mit der rechten Maustaste auf einen Server, und klicken Sie dann auf
Eigenschaften.
3. Klicken Sie auf der Registerkarte Sicherheit unter Überwachungsebene auf
Fehler.
Sie müssen den Server beenden und neu starten, damit diese Einstellung in Kraft tritt.
Allgemeine Überwachung
SQL Server 2000 unterstützt die Definition von Überwachungsereignissen und -spalten
sowie die Analyse von Überwachungsprotokollen mit einem GUI-basierten Tool:
SQL Profiler. Folgende Ereignisse können aufgezeichnet und analysiert werden:

Endbenutzeraktivitäten (alle SQL-Befehle, Abmelden/Anmelden, Aktivieren von
Anwendungsrollen).

Administratoraktivitäten (Datendefinitionssprache (Data Definition Language, DDL)
außer GRANT/REVOKE/DENY und Sicherheitsereignissen sowie Datenbank- oder
Serverkonfiguration).
48

Sicherheitsereignisse (GRANT/REVOKE/DENY, Anmeldung eines Benutzers,
Hinzufügen/Entfernen/Konfigurieren einer Rolle).

Dienstprogrammereignisse (Befehle Sichern/Wiederherstellen/Masseneinfügung/
bcp/DBCC).

Serverereignisse (Herunterfahren, Anhalten, Starten).

Überwachungsereignisse (Hinzufügen, Ändern, Beenden einer Überwachung).
Wenn die Überwachung beim Starten von SQL Server gestartet werden soll, sollten Sie
ein Überwachungsskript erstellen, es in eine gespeicherte Prozedur einbinden und die
gespeicherte Prozedur zum automatischen Starten kennzeichnen.
Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkId=14579
sowie im Thema „Verwenden von Überwachungsprotokollen“, das über
http://go.microsoft.com/fwlink/?LinkId=15402 oder in englischer Sprache („Using Audit
Logs“) unter http://go.microsoft.com/fwlink/?LinkId=15403 verfügbar ist
C2-Überwachung
SQL Server kann so konfiguriert werden, dass die Überwachung auf der für die
C2-Zertifizierung erforderlichen Ebene durchgeführt wird, unter Berücksichtigung der
Trusted Database Interpretation (TDI, Interpretation vertrauter Datenbanken) der
Trusted Computer System Evaluation Criteria (TCSEC, Bewertungskriterien vertrauter
Computersysteme) der National Security Agency der Vereinigten Staaten von Amerika.
Diese Überwachungsebene ist als C2-Überwachungsmodus bekannt und kann mithilfe
der erweiterten Option c2 audit mode der gespeicherten Prozedur sp_configure
aktiviert werden. Bei Überwachung auf der C2-Ebene können in kurzer Zeit große
Datenmengen generiert werden. Diese Option sollte daher nur dann ausgewählt werden,
wenn sie unbedingt erforderlich ist. SQL Server wird beim Ausführen in diesem Modus
automatisch heruntergefahren, wenn die Protokolldateien den verfügbaren Speicherplatz
überschreiten, um die Integrität des Überwachungspfades der C2-Ebene beizubehalten.
Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15401.
Sicherheit für eine mehrstufige Bereitstellung
SQL Server wird häufig als Teil eines mehrstufigen Systems von Anwendungen
bereitgestellt, zwischen denen die Kommunikation über ein Netzwerk erfolgt.
Die einfachste Version einer solchen Installation umfasst drei Ebenen:

Webserver: Webanwendung oder Webclient mit Benutzeroberfläche.

Anwendungsserver: Geschäftslogik, Vorverarbeitung von Batches vor der
Übertragung zur Datenbank; kann einen Webserver (ASP.NET/IIS) einschließen.
Diese Ebene wird auch als mittlere Stufe bezeichnet.

Datenbankserver: Datenbank (SQL Server). Diese Ebene wird manchmal als
Back-End bezeichnet.
49
Abbildung 4 zeigt Sicherheitslücken in einem einfachen mehrstufigen System.
Abbildung 4: Einfaches mehrstufiges System, in dem Hauptsicherheitslücken
gekennzeichnet sind
Eine vollständige Diskussion der Sicherheit für derartig komplexe Systeme würde den
Rahmen dieses Whitepapers sprengen. Weitere Informationen zur n-stufigen
Bereitstellung finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15404.
Master-/Zielserver
In einer Master/Ziel-Beziehung (MSX/TSX-Beziehung) muss es mindestens einen
Masterserver und mindestens einen Zielserver geben. Vom Masterserver werden
Aufträge an die Zielserver verteilt. Auf dem Masterserver wird die zentrale
(autorisierende) Kopie der Auftragsdefinitionen für Aufträge gespeichert, die auf
Zielservern ausgeführt werden. Von jedem Zielserver wird in regelmäßigen Abständen
eine Verbindung zum Masterserver hergestellt, und die Liste der ausstehenden Aufträge
auf dem Zielserver wird aktualisiert. Wenn Sie einen Server als Master- oder Zielserver
konfigurieren, sollten Sie folgende bewährte Methoden verwenden:

MSX/TSX sollte nur innerhalb des Unternehmensfirewalls bereitgestellt werden. Ein
Master- oder Zielserver sollte nie direkt über das Internet zugänglich sein.

Der SQL Server-Agent auf dem MSX sollte mit einem WindowsDomänenbenutzerkonto ohne Windows-Administratorrechte ausgeführt werden.
Beim Festlegen des SQL-Agent-Dienstkontos mit Enterprise Manager werden die
richtigen Rechte zugewiesen.
Anmerkung Wenn Sie ActiveX-Skripts oder CmdExec-Aufträge in Batches
verwenden, muss der SQL-Agent Mitglied der Windows-Gruppe Administratoren
sein.
Wurde für einen MSX-Server eine Aktualisierung von einer SQL Server-Version vor SP3
ausgeführt, können einige Aufträge beibehalten worden sein, deren Besitzer alte
SQL Server-Agent-Untersuchungskonten (computer_name_msx_probe_login) sind.
Sie sollten solche Aufträge neuen Besitzern zuweisen und die nicht mehr benötigten
Konten manuell entfernen.
50
SSL und IPSec
Damit Datenschutz und Integrität der Daten bei Übertragung über ein Netzwerk
sichergestellt sind, sollten Sie mit IPSec verschlüsselte Kommunikationskanäle oder
SSL-Verbindungen zur Datenbank verwenden. Abbildung 5 zeigt die Zuordnung der
OSI-Ebenen zum TCP/IP-Treiber.
Abbildung 5
IPSec ist ein auf der Netzwerkebene arbeitendes Verschlüsselungs- und
Authentifizierungsprotokoll mit der Aufgabe, Netzwerkverkehr vor Adressenspoofing,
Mitlesen von Inhalten und Übernehmen von Verbindungen durch einen Angreifer zu
schützen. Da das Protokoll auf einer der unteren Ebenen des OSI-Stapels arbeitet, ist es
für SQL Server nicht sichtbar. IPSec kann zwar ohne Konfigurieren der SQL ServerEbene verwendet werden, aber einige Kenntnisse zu öffentlichen und privaten Schlüsseln
sind hilfreich für das Planen der Bereitstellung. Weitere Informationen finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15405.
SSL arbeitet auf der Grenze zwischen der Sitzungsebene und der Transportebene des
OSI-Modells und ermöglicht das Aushandeln gemeinsam verwendbarer Sitzungsschlüssel
für Clients und Server. Mit SSL wird Verschlüsselung, aber keine Authentifizierung
bereitgestellt. Eine SSL-Kommunikation ist nur zwischen Anwendungsebenen möglich,
die speziell für die Verwendung dieses Protokolls entworfen wurden. Clientanwendungen,
die auf der obersten Ebene des MDAC-Stapels (Version 2.6 oder höher) ausgeführt
werden, müssen SSL nicht unterstützen, da diese Funktionalität von MDAC bereitgestellt
wird.
51
Eine bewährte Methode besteht darin, SSL für alle SSL-fähigen Verbindungen zu
erzwingen. Dies ist bei der Authentifizierung im gemischten Modus besonders wichtig.
Wenn Sie die Verschlüsselung für SSL-fähige Anwendungen erzwingen möchten, mit
denen Verbindungen zu Ihrem Server hergestellt werden, wenden Sie ein SSL-Zertifikat
auf den Server an und aktivieren in der SQL Server-Netzwerkkonfiguration für alle
aktivierten Protokolle das Kontrollkästchen Protokollverschlüsselung erzwingen.
Weitere Informationen zum Implementieren von SSL und IPSec, einschließlich weiterer
Konfigurationsoptionen, finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15406
und http://go.microsoft.com/fwlink/?LinkId=15407.
Authentifizierung
Für die Kommunikation zwischen Anwendungsstufen innerhalb einer Windows-Domäne
sollte immer die Windows-Authentifizierung verwendet werden.
Verwenden der Windows-Authentifizierung
In diesem Authentifizierungsmodus werden Anmeldeinformationen automatisch
verwaltet und nicht über das Netzwerk gesendet. Außerdem werden Benutzernamen und
Kennwörter nicht in Verbindungszeichenfolgen eingebettet.
Sicherheit für Verbindungszeichenfolgen
Bei der SQL Server-Authentifizierung enthält die jeweilige Verbindungszeichenfolge den
Benutzernamen und das Kennwort. Ein Angreifer, der eine Sicherheitslücke durch offen
gelegten Quellcode auf dem Webserver ausnutzt oder sich unautorisiert am Server
anmeldet, kann die Verbindungszeichenfolgen abrufen. Außerdem kann jeder
rechtmäßige Serverbenutzer die Verbindungszeichenfolgen anzeigen. Sichern Sie
Verbindungszeichenfolgen durch Verschlüsselung.
Für SQL Server-Verbindungen von Clientanwendungen und Anwendungen auf mittlerer
Stufe sollte nach Möglichkeit die Windows-Authentifizierung verwendet werden.
Anwendungsdesigner, die einen weniger sicheren Authentifizierungsmodus verwenden
müssen, sollten anderweitig einen ausreichenden Schutz der SQL ServerAnmeldeinformationen sicherstellen. Alle Verbindungen sollten über ein Konto hergestellt
werden, das nur die erforderlichen Mindestberechtigungen besitzt.
Verwenden der Windows-Authentifizierung statt
Verwalten der Anmeldeinformationen
Bei der Windows-Authentifizierung werden keine Anmeldeinformationen über das
Netzwerk gesendet. Das entsprechende Konto muss auf dem Datenbankserver sowohl
von Windows als auch von SQL Server erkannt werden. Dem Konto sollte ein
SQL Server-Benutzername zugeteilt werden, der nur die zum Datenbankzugriff
erforderlichen Berechtigungen besitzt. Durch diese Vorsichtsmaßnahmen wird der
Bereich möglicher Schäden eingeschränkt, wenn Ihr System durch Hacker geschädigt
wird. Im folgenden Beispiel wird eine typische Verbindungszeichenfolge gezeigt, für die
die Windows-Authentifizierung verwendet wird.
52
Bei Verwendung des ADO.NET-Datenproviders für SQL Server:
SqlConnection pubsConn = new SqlConnection(
"Server=dbserver; database=pubs; Integrated Security=SSPI;");
Bei Verwendung des ADO.NET-Datenproviders für OLE DB-Datenquellen:
OleDbConnection pubsConn = new OleDbConnection(
"Provider=SQLOLEDB; Data Source=dbserver; Integrated Security=SSPI;" +
"Initial Catalog=northwind");
Schützen der Anmeldeinformationen für die
SQL Server-Authentifizierung
Wenn Sie die SQL Server-Authentifizierung verwenden müssen, sollten Sie sicherstellen,
dass die Anmeldeinformationen nicht als Klartext über einen unverschlüsselten Kanal
gesendet werden. Da die Datenbank-Verbindungszeichenfolge Anmeldeinformationen
enthält, müssen Sie sie auch vor dem Speichern verschlüsseln. Verwenden Sie DPAPI für
die Sicherheit der Verbindungszeichenfolge. Weitere Informationen finden Sie weiter
unten in diesem Whitepaper unter „Speichern von Anmeldeinformationen“.
Damit über ein Netzwerk gesendete Anmeldeinformationen automatisch von SQL Server
verschlüsselt werden können, installieren Sie ein Serverzertifikat auf dem
Datenbankserver. Alternativ können Sie einen mit IPSec verschlüsselten Kanal zwischen
dem Webserver und dem Datenbankserver verwenden.
Herstellen von Verbindungen mit einem Konto mit
Mindestrechten
Für das Herstellen einer Verbindung von Ihrer Anwendung zur Datenbank sollte ein
Konto mit Mindestrechten verwendet werden. Wenn Verbindungen über die WindowsAuthentifizierung hergestellt werden, sollte das Windows-Konto Mindestrechte für das
Betriebssystem und eingeschränkte Rechte und Fähigkeiten hinsichtlich des Zugriffs auf
Windows-Ressourcen haben. Außerdem sollten dem entsprechenden SQL ServerBenutzernamen in der Datenbank nur die für Ihre Anwendung erforderlichen
Berechtigungen zugewiesen werden, unabhängig davon, ob Sie für Verbindungen zur
Datenbank die Windows- oder die SQL Server-Authentifizierung verwenden.
53
Autorisierung
Während des Autorisierungsprozesses wird ermittelt, welche Berechtigungen einem
Benutzer erteilt wurden. Es gibt zwei Schutzansätze. Im Datenzugriffscode kann mit
einer Autorisierung bestimmt werden, ob der angeforderte Vorgang ausgeführt werden
kann. Sobald die aufrufende Identität oder der aufrufende Code autorisiert wurde, wird
ein Befehl an die Datenbank ausgegeben. Daraufhin werden anhand einer
Datenbankautorisierung die Möglichkeiten für den SQL Server-Benutzernamen der
Anwendung beschränkt.
Bei unzureichender Autorisierung können Benutzer möglicherweise Daten anderer
Benutzer ändern, und nicht autorisierte Benutzer können Zugriff auf Daten mit
Zugriffsbeschränkung erhalten. Um diese Gefahr so gering wie möglich zu halten, sollten
Sie ein gestaffeltes Sicherheitskonzept (mehrere Sicherheitsebenen) für die Strategie
der Datenzugriffsautorisierung verwenden. Dazu gehören insbesondere folgende
Schritte:

Beschränken des Zugriffs für nicht autorisierte Aufrufer.

Beschränken des Zugriffs für nicht autorisierten Code.

Beschränken der Anwendung in der Datenbank.
Abbildung 6 zeigt ein gestaffeltes Sicherheitskonzept für Benutzerdaten.
Abbildung 6
Im Datenzugriffscode können Anforderungen an Prinzipalberechtigungen verwendet
werden, um das aufrufende Prinzipal oder den aufrufenden Code zu autorisieren.
Codeidentitätsanforderungen sind eine Funktion der üblichen Zugriffssicherheit des
Laufzeitcodes einer Sprache.
Auf der SQL Server-Ebene sollten Sie einen SQL Server-Benutzernamen mit
Mindestrechten erstellen, der nur zum Ausführen gespeicherter Prozeduren autorisiert
ist. Benutzer sollten nicht autorisiert sein, einen der folgenden Vorgänge direkt für eine
Tabelle auszuführen: CREATE, READ, UPDATE, DELETE.
54
Beschränken des Zugriffs für nicht autorisierte
Aufrufer
Von Anwendungen auf der mittleren Stufe sollten vor dem Herstellen einer Verbindung
zur Back-End-Datenbank die Benutzer anhand der Rolle oder Identität autorisiert
werden. Rollenprüfungen sind üblicherweise in der Geschäftslogik der jeweiligen
Anwendung implementiert. Gibt es aber keine klare Trennung zwischen Geschäfts- und
Datenzugriffslogik, sollten Sie Anforderungen an Prinzipalberechtigungen für die
Methoden verwenden, mit denen auf die Datenbank zugegriffen wird.
Mit dem folgenden Attribut wird sichergestellt, dass die DisplayCustomerInfo-Methode
nur von Benutzern aufgerufen werden kann, die Mitglied der Manager-Rolle sind.
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Manager")]
public void DisplayCustomerInfo(int CustId)
{
}
Wenn Sie weitere Autorisierungsgranularität benötigen und innerhalb der
Datenzugriffsmethode rollenbasierte Logik ausführen möchten, verwenden Sie
obligatorische Anforderungen an Prinzipalberechtigungen oder explizite Rollenprüfungen,
wie nachfolgend gezeigt:
public void DisplayCustomerInfo(int CustId)
{
try
{
// Imperative principal permission role check to check that the caller
// is a manager
PrincipalPermission principalPerm = new PrincipalPermission(
null, "Manager");
// Code that follows is only executed if the caller is a member
// of the "Manager" role
}
catch( SecurityException ex )
{
. . .
}
}
55
Im folgenden Code wird mit einer expliziten programmgesteuerten Rollenprüfung
sichergestellt, dass der Aufrufer ein Manager ist.
public void DisplayCustomerInfo(int CustId)
{
if(!Thread.CurrentPrincipal.IsInRole("Manager"))
{
. . .
}
}
Beschränken des Zugriffs für nicht autorisierten
Code
Mit der ASP.NET-Codezugriffssicherheit und mit speziellen Codeidentitätsanforderungen
können Sie beschränken, welche sonstigen Assemblys auf die Datenzugriffsklassen und
-methoden zugreifen können.
Wenn Sie beispielsweise möchten, dass Ihre Datenzugriffskomponenten nur von Code
verwendet werden können, der in Ihrer Firma oder von einem bestimmten
Softwareanbieter geschrieben wurde, überprüfen Sie mit einer Instanz der
StrongNameIdentityPermission-Klasse, ob aufrufende Assemblys einen sicheren
Namen mit einem angegebenen öffentlichen Schlüssel haben.
using System.Security.Permissions;
. . .
[StrongNameIdentityPermission(SecurityAction.LinkDemand,
PublicKey="002...4c6")]
public void GetCustomerInfo(int CustId)
{
}
Mit dem folgenden Befehl können Sie die Textdarstellung des öffentlichen Schlüssels der
angegebenen Assembly extrahieren.
sn –tp assembly.dll
56
Da Assemblys für Webanwendungen dynamisch kompiliert werden, gibt es momentan
keine Möglichkeit, ihnen sichere Namen zu geben. Dadurch ist es schwierig, die
Verwendung einer Datenzugriffsassembly auf eine bestimmte Webanwendung zu
beschränken. Die beste Vorgehensweise besteht darin, eine benutzerdefinierte
Berechtigung zu entwickeln und diese Berechtigung aus der Datenzugriffskomponente
anzufordern. Mit vollständig vertrauten Webanwendungen (oder vollständig vertrautem
Code) kann dann diese Komponente aufgerufen werden. Dagegen kann mit teilweise
vertrautem Code die Datenzugriffskomponente nur dann aufgerufen werden, wenn die
benutzerdefinierte Berechtigung erteilt wurde.
Remoteverwaltung
Administratoren müssen häufig mehrere Server verwalten können. Stellen Sie sicher,
dass die Anforderungen für Ihre Remoteverwaltungslösung nicht die Sicherheit
beeinträchtigen. Die folgenden Punkte bieten dazu bewährte Methoden:

Beschränken Sie die Anzahl von Windows-Administratorkonten. Dazu gehört
das Beschränken der Anzahl von Administratorkonten und von Konten, über die eine
Remoteanmeldung möglich ist.

Beschränken Sie die Tools. Die Hauptoptionen für Windows sind der
Internetdienste-Manager und Terminaldienste. Eine Webverwaltung (über das
virtuelle Verzeichnis IISAdmin) wird nicht empfohlen. Diese Option wird daher von
IISLockdown.exe entfernt. Sowohl für den Internetdienste-Manager als auch für
Terminaldienste wird die Windows-Sicherheit verwendet. SQL Server
Enterprise Manager kann zur Remoteverwaltung von SQL Server verwendet werden.
Wenn Sie die SQL Server-Authentifizierung verwenden und Ihre
Anmeldeinformationen speichern müssen, sollten Sie Enterprise Manager so
konfigurieren, dass der Zugriff auf genau einen Windows-Benutzer beschränkt wird.
Aktivieren Sie dazu auf der Registerkarte Allgemein das Kontrollkästchen
Benutzerunabhängig lesen/speichern.

Beschränken Sie die Computer, über die das Verwalten des Servers möglich
ist. Mit IPSec kann als Beschränkung festgelegt werden, über welche Computer
Verbindungen zum Webserver hergestellt werden können.
Sicherheit für Terminaldienste
Sie können Microsoft Terminaldienste in gesicherter Form für die Remoteverwaltung
Ihres Datenbankservers verwenden.
Terminaldienste basiert auf dem proprietären Microsoft-Protokoll RDP (Remote Desktop
Protocol). RDP verwendet den TCP-Port 3389 und unterstützt zwei gleichzeitige
Benutzer.
57
Installieren von Terminaldienste
1. Doppelklicken Sie in der Systemsteuerung auf Software. Wählen Sie die Option
Windows-Komponenten hinzufügen/entfernen aus. Für die Remoteverwaltung
müssen Sie nicht den Lizenzdienst für Terminaldienste installieren.
2. Konfigurieren Sie Terminaldienste für den Remoteverwaltungsmodus.
3. Entfernen Sie das Konto TsInternetUser, das beim Installieren von Terminaldienste
erstellt wurde. Mit diesem Konto wird der anonyme Zugriff auf Terminaldienste über
das Internet unterstützt. Dieser sollte auf einem Server nicht möglich sein.
Konfigurieren von Terminaldienste
Verwenden Sie in der Programmgruppe Verwaltung das MMC-Snap-In
Terminaldienstekonfiguration, um Terminaldienste wie folgt zu konfigurieren:
1. Für Verbindungen mit Terminaldienste gibt es drei Verschlüsselungsgrade (Niedrig,
Mittel und Hoch). Legen Sie die Verschlüsselung auf 128-Bit-Schlüssel fest.
Beachten Sie, dass die Microsoft Windows-128-Bit-Verschlüsselung sowohl auf dem
Server als auch auf dem Client installiert sein muss.
2. Konfigurieren Sie Terminaldienste so, dass die Verbindung einer Sitzung nach
Erreichen des Wertes von Maximale Leerlaufdauer getrennt wird. Aktivieren Sie
außerdem die Option Sitzung beenden, so dass eine Sitzung beendet wird, deren
Verbindung getrennt wurde. Die Verbindung einer Sitzung wird nach 10 Minuten
getrennt, wenn der Benutzer die Terminaldienste-Clientanwendung geschlossen hat,
ohne sich vorher abzumelden.
3. Verwenden Sie im RDP-Eigenschaftendialogfeld die Registerkarte Berechtigungen,
um den Zugriff auf Terminaldienste zu beschränken. Standardmäßig sind alle
Mitglieder der Gruppe Administratoren zum Zugreifen auf Terminaldienste
berechtigt. Wenn Sie nicht möchten, dass alle Mitglieder der Gruppe
Administratoren auf Terminaldienste zugreifen können, entfernen Sie die Gruppe
und fügen die einzelnen Konten hinzu, über die Zugriff möglich sein soll. Das Konto
SYSTEM muss in der Liste enthalten sein.
Zum Erhöhen der Sicherheit sollten Sie eine sichere VPN-Verbindung zwischen dem
Client und dem Server oder einen IPSec-Tunnel verwenden. Bei dieser Vorgehensweise
wird eine gegenseitige Authentifizierung bereitgestellt, und die RDS-Nutzlast wird
verschlüsselt.
Kopieren von Dateien über RDP
Von Terminaldienste wird keine integrierte Unterstützung für Dateiübertragungen
bereitgestellt. Sie können jedoch das Dienstprogramm zum Kopieren von Dateien
(File Copy Utility) aus dem Windows 2000 Server Resource Kit installieren, um in
Terminaldienste Dateiübertragungsfunktionen zur Zwischenablageumleitungs-Funktion
hinzuzufügen. Weitere Informationen zu dem Dienstprogramm sowie
Installationsanweisungen finden Sie im Microsoft Knowledge Base-Artikel 244732, „HOW
TO: Install the File Copy Tool Included with the Windows 2000 Resource Kit“, unter
http://go.microsoft.com/fwlink/?LinkId=16419.
58
Gespeicherte Prozeduren oder dynamisches
SQL
Gespeicherte Prozeduren bieten Leistungs-, Wartungs- und Sicherheitsvorteile. Für
Datenzugriffe sollten Sie nach Möglichkeit parametrisierte gespeicherte Prozeduren
verwenden. Dies hat folgende Sicherheitsvorteile:

Die Rechte von Anwendungsdatenbank-Benutzern können so beschränkt werden,
dass sie nur die angegebenen gespeicherten Prozeduren ausführen können. Es ist
nicht erforderlich, direkten Tabellenzugriff zu gewähren. Weitere Informationen
finden Sie weiter oben in diesem Whitepaper in der Erläuterung zur Besitzverkettung.

Es können Längen- und Typprüfungen für alle Eingabedaten ausgeführt werden, die
an die gespeicherte Prozedur übergeben werden. Außerdem können Parameter nicht
als ausführbarer Code behandelt werden.
Können Sie keine parametrisierten gespeicherten Prozeduren verwenden, sondern
müssen Sie SQL-Anweisungen dynamisch erstellen, sollten Sie dafür Parameter und
Parameterplatzhalter mit Typbindung verwenden, damit die Längen und Typen der
Eingabedaten geprüft werden.
Verwenden getrennter
Datenzugriffsassemblys
Wenn Ihre Anwendung in einer mehrstufigen Umgebung bereitgestellt wird, sollten Sie
die Datenzugriffslogik nicht direkt für Endbenutzer offen legen. In ASP.NET sollte die
Datenzugriffslogik beispielsweise in einer eigenen Assembly getrennt von der Geschäftsund der Darstellungslogik bereitgestellt werden. Geben Sie der Assembly einen sicheren
Namen, damit die Anfälligkeit für Manipulationen verringert wird. Ein sicherer Name
besteht aus der Identität der Assembly - ihrem einfachen Textnamen, ihrer
Versionsnummer und kulturbezogenen Informationen (sofern bereitgestellt) - sowie aus
einem öffentlichen Schlüssel und einer digitalen Signatur. Der Name wird mithilfe des
entsprechenden privaten Schlüssels aus einer Assemblydatei generiert. (Eine
Assemblydatei enthält das Assemblymanifest, das wiederum die Namen und Hashwerte
aller Dateien enthält, die die Assembly bilden.) Mit Microsoft Visual Studio .NET und
anderen Entwicklungstools, die im .NET Framework SDK bereitgestellt werden, können
sichere Namen den Assemblys zugewiesen werden. Assemblys, die denselben sicheren
Namen aufweisen, werden als identisch angesehen. Außerdem können mit dem zu
einem sicheren Namen gehörenden öffentlichen Schlüssel die Sicherheitsrichtlinien für
den Codezugriff konfiguriert werden sowie der Assembly bestimmte Berechtigungen
erteilt werden. So kann aufrufender Code von Datenzugriffsmethoden und -klassen
autorisiert werden.
59
In Abbildung 7 ist ein solcher gestufter Schutz eines Servers dargestellt. Dabei erfolgt
eine prinzipalbasierte Autorisierung anhand von Anforderungen an
Prinzipalberechtigungen für Geschäftskomponenten. Zusätzlich wird mit
Berechtigungsanforderungen an die Codeidentität der Code autorisiert, mit dem die
Datenzugriffslogik aufgerufen wird.
Abbildung 7
SQL-Injektion
Als SQL-Injektion wird ein Angriff bezeichnet, bei dem zerstörerischer Code in
Zeichenfolgen eingefügt wird, die später zum Analysieren und Ausführen an SQL Server
übergeben werden. Durch jede vom Server vertraute clientseitige Anwendung, die
SQL-Anweisungen zurückgibt, ist der Server solchen Injektionsangriffen ausgesetzt, da
alle empfangenen syntaktisch gültigen Anweisungen vom Server ausgeführt werden.
Injektionen sind am einfachsten auszuführen, wenn in Anwendungen SQL-Anweisungen
aus Benutzereingaben erstellt werden. Injektionen sind aber auch möglich, wenn der
Client Benutzereingaben an serverseitige gespeicherte Prozeduren übergibt. Die Gefahr
für Ihren Server wird weiter erhöht, wenn mit der Anwendung Verbindungen über ein
Konto hergestellt werden, das zu viele Berechtigungen besitzt.
Beispiel für eine SQL-Skriptinjektion
Mit dem folgenden ASP-Skript wird eine SQL-Abfrage erstellt, indem fest codierte
Zeichenfolgen mit einer Zeichenfolge verkettet werden, die der Benutzer eingegeben
hat:
var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";
60
Der Benutzer wird aufgefordert, den Namen einer Stadt einzugeben. Wird beispielsweise
Redmond eingegeben, lautet die vom Skript erstellte Abfrage wie folgt:
select * from OrdersTable where ShipCity = 'Redmond'
Aber was passiert, wenn der Benutzer Folgendes eingibt?
'Redmond'; drop table OrdersTable--
In diesem Fall lautet die vom Skript erstellte Abfrage wie folgt:
select * from OrdersTable where ShipCity = 'Redmond';drop table
OrdersTable--
Das Semikolon (;) zeigt das Ende einer Abfrage und den Anfang der nächsten Abfrage
an. Die Zeichenfolge -- bedeutet, dass der Rest der aktuellen Zeile ein Kommentar ist
und ignoriert werden soll. Der Benutzer hat Ihren Clientcode dazu verwendet, eine
Zeichenfolge in die Anweisung zu injizieren, die mit ASP an SQL Server zurückgegeben
wird. Bei der Verarbeitung dieser Anweisung durch SQL Server werden zunächst in
OrdersTable alle Datensätze ausgewählt, in denen ShipCity gleich Redmond ist.
Anschließend wird die OrdersTable-Tabelle gelöscht.
Verhindern von SQL-Injektionen
Solange injizierter SQL-Code syntaktisch richtig ist, können Manipulationen serverseitig
nicht programmgesteuert entdeckt werden. Sie müssen daher alle Benutzereingaben
clientseitig überprüfen und serverseitige Typprüfungen erzwingen, indem Sie
parametrisierte gespeicherte Prozeduren aufrufen. Überprüfen Sie Benutzereingaben
immer durch Testen des Typs, der Länge, des Formats und des Bereichs. Nicht
überprüfte Eingaben können Programmfehler verursachen und von Hackern als
Eintrittspunkt in Ihr System verwendet werden. Beim Implementieren von
Vorsichtsmaßnahmen gegen zerstörerische Eingaben sollten Sie die Architektur und die
Bereitstellungsszenarios Ihrer Anwendung berücksichtigen. Beachten Sie, dass
Programme, die für die Ausführung in einer sicheren Umgebung vorgesehen sind, in eine
unsichere Umgebung kopiert werden können.
61
Überprüfen aller Eingaben
Die folgenden Empfehlungen sind bewährte Methoden:

Setzen Sie nicht einfach voraus, dass die Größe, der Typ oder der Inhalt der von
Ihrer Anwendung empfangenen Daten Ihren Erwartungen entspricht. Überprüfen Sie
beispielsweise Folgendes:

Wie ist das Verhalten Ihrer Anwendung, wenn ein unkonzentrierter oder
zerstörerischer Benutzer den Namen einer 10 MB großen MPEG-Datei eingibt, von
Ihrer Anwendung aber eine Postleitzahl erwartet wird?

Wie ist das Verhalten der Anwendung, wenn eine DROP TABLE-Anweisung in ein
Textfeld eingebettet wird?

Prüfen Sie die Größe und den Datentyp einer Eingabe, und erzwingen Sie
entsprechende Beschränkungen. So können Sie absichtlich erzeugten
Pufferüberläufen vorbeugen.

Prüfen Sie die Inhalte von Zeichenfolgenvariablen, und akzeptieren Sie nur erwartete
Werte. Weisen Sie Einträge zurück, die Binärdaten, Escapesequenzen und/oder
Kommentarzeichen enthalten. So können Sie Skriptinjektionen verhindern und einen
gewissen Schutz vor absichtlich erzeugten Pufferüberläufen erreichen.

Wenn Sie mit XML-Dokumenten arbeiten, überprüfen Sie alle eingegebenen Daten
anhand ihres Schemas.

Erstellen Sie Transact-SQL-Anweisungen niemals direkt aus Benutzereingaben.

Überprüfen Sie Benutzereingaben mithilfe gespeicherter Prozeduren.

In einer mehrstufigen Umgebung sollten alle Daten überprüft werden, bevor sie in
die vertraute Zone übernommen werden. Daten, die die Überprüfung nicht bestehen,
sollten zurückgewiesen werden. Außerdem sollte ein Fehler an die vorherige Stufe
zurückgegeben werden.

Implementieren Sie eine mehrstufige Überprüfung. Vorsichtsmaßnahmen, die Sie
gegen gelegentlich zerstörerische Benutzer ergreifen, sind gegen erfahrene Hacker
möglicherweise unwirksam. Die bewährte Methode besteht darin, Eingaben auf der
Benutzeroberfläche und danach bei jedem weiteren Überschreiten einer
Vertrauensgrenze zu überprüfen.
Beispielsweise können mit der Datenüberprüfung in einer clientseitigen Anwendung
möglicherweise einfache Skriptinjektionen verhindert werden. Wenn aber für die
nächste Stufe angenommen wird, dass die dort ankommenden Eingaben bereits
überprüft sind, hat jeder Hacker, der die Clientanwendung umgehen kann,
unbeschränkten Zugriff auf Ihr System.

Verketten Sie nie Benutzereingaben, die noch nicht überprüft wurden. Verkettung
von Zeichenfolgen ist die Hauptschwachstelle für Skriptinjektionen.

Weisen Sie folgende Zeichenfolgen in Feldern zurück, aus denen möglicherweise
Dateinamen erstellt werden: AUX, CLOCK$, COM1 bis COM8, CON, CONFIG$, LPT1
bis LPT8, NUL und PRN.
62
Weisen Sie nach Möglichkeit auch Eingaben zurück, die folgende möglicherweise
gefährlichen Zeichen enthalten.
Eingegebenes Zeichen
Bedeutung in Transact-SQL
;
Abfragetrennzeichen
'
Begrenzungszeichen für Zeichenfolgen
--
Kommentarzeichen
/* ... */
Kommentarzeichen. Text zwischen /* und
*/ wird vom Server nicht ausgewertet.
Xp_
Steht am Anfang des Namens einer
erweiterten gespeicherten
Katalogprozedur, beispielsweise
xp_cmdshell.
Verwenden typsicherer SQL-Parameter
Von der Parameters-Auflistung in SQL Server werden Typprüfung und
Längenüberprüfung bereitgestellt. Wenn Sie die Parameters-Auflistung verwenden,
werden Eingaben nicht als ausführbarer Code, sondern als Literalwerte behandelt.
Ein weiterer Vorteil der Parameters-Auflistung besteht darin, dass Sie Typ- und
Längenprüfungen erzwingen können. Jeder Wert außerhalb des zulässigen Bereichs löst
eine Ausnahme aus. Anhand des folgenden Codefragments wird verdeutlicht, wie die
Parameters-Auflistung verwendet wird:
SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add(
"@au_id", SqlDbType.VarChar, 11);
parm.Value = Login.Text;
In diesem Beispiel wird der @au_id-Parameter nicht als ausführbarer Code, sondern als
Literalwert behandelt. Typ und Länge dieses Wertes werden geprüft. Entspricht der Wert
von @au_id nicht den für Typ und Länge angegebenen Einschränkungen, wird eine
Ausnahme ausgelöst.
63
Verwenden parametrisierter Eingaben für
gespeicherte Prozeduren
Gespeicherte Prozeduren können für SQL-Injektionen anfällig sein, wenn die Eingaben
ungefiltert verwendet werden. Der folgende Code ist beispielsweise anfällig:
SqlDataAdapter myCommand =
new SqlDataAdapter("LoginStoredProcedure '" +
Login.Text + "'", conn);
Bei Verwendung gespeicherter Prozeduren sollten Sie Parameter als Eingaben
verwenden.
Verwenden der Parameters-Auflistung mit
dynamischem SQL
Auch wenn Sie keine gespeicherten Prozeduren verwenden, können Sie Parameter
verwenden, wie das folgende Beispiel verdeutlicht.
SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);
SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
SqlDbType.VarChar, 11);
Parm.Value = Login.Text;
Filtern von Eingaben
Eine weitere Möglichkeit zum Schutz vor SQL-Injektionen ist das Entfernen von
Escapezeichen durch Filtern der Eingaben. Dies ist wegen der großen Anzahl an Zeichen,
die Probleme bereiten können, aber kein zuverlässiger Schutz. Im folgenden
Codeausschnitt wird nach dem Begrenzungszeichen für Zeichenfolgen gesucht.
private string SafeSqlLiteral(string inputSQL)
{
return inputSQL.Replace("'", "''");
}
64
LIKE-Klauseln
Bei Verwendung einer LIKE-Klausel müssen Sie beachten, dass Platzhalterzeichen
weiterhin mit Escapezeichen verwendet werden müssen:
s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");
Parameter und Batches
Häufig wird fälschlicherweise angenommen, dass keine Parameter verwendet werden
können, wenn mehrere SQL-Anweisungen verkettet und als Batch an den Server
übertragen werden. Tatsächlich können Parameter verwendet werden, solange keiner
der Parameternamen mehrfach vorkommt. Dazu kann während der SQL-Textverkettung
zu jedem Parameternamen eine Zahl oder ein anderer eindeutiger Wert hinzugefügt
werden.
Speichern von Anmeldeinformationen
Sie sollten Anmeldeinformationen in keiner Form speichern. Die bewährte Methode
besteht darin, nur die Windows-Authentifizierung zu verwenden und zu keinem
Zeitpunkt Anmeldeinformationen zu verarbeiten. Wenn von Ihrer Anwendung
Verbindungen zu einem System außerhalb einer vertrauten Domäne hergestellt werden,
kann die Verwaltung von Anmeldeinformationen allerdings erforderlich sein. In diesem
Fall besteht die bewährte Methode darin, die Anmeldeinformationen mit DPAPI zu
verschlüsseln und in einem Registrierungsschlüssel zu speichern, für den eine
Zugriffssteuerungsliste (Access Control List, ACL) verwendet wird. Mit Regedt32.exe
können Sie folgende ACL auf den Schlüssel anwenden:
Administrators: Full Control
Process Account: Read
Mit der DPAPI-Verschlüsselung vermeiden Sie Probleme bei der Verwaltung des
Verschlüsselungsschlüssels. Der Grund ist, dass der Verschlüsselungsschlüssel durch die
Plattform verwaltet wird und an einen bestimmten Computer oder an ein bestimmtes
Windows-Benutzerkonto gebunden ist. Weitere Informationen zu DPAPI finden Sie unter
http://go.microsoft.com/fwlink/?LinkId=15408.
Möglicherweise müssen Sie zum Verarbeiten der DPAPI-Verschlüsselung eine verwaltete
Wrapperklasse erstellen. Weitere Informationen zum Erstellen einer verwalteten
Wrapperklasse finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15409.
65
Obwohl dies weniger sicher sein kann als das Verwenden eines gesicherten
Registrierungsschlüssels, muss von ASP.NET-Anwendungen die verschlüsselte
Zeichenfolge möglicherweise in Web.config gespeichert werden. In diesem Fall sollten
Sie wie im folgenden Beispiel ein benutzerdefiniertes Name/Wert-Paar für
<appSettings> verwenden:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="connectionString" value="AQA..bIE=" />
</appSettings>
<system.web>
...
</system.web>
</configuration>
Für den Zugriff auf den verschlüsselten Text aus dem <appSettings>-Element
verwenden Sie die ConfigurationSettings-Klasse wie folgt:
using System.Configuration;
private static string GetConnectionString()
{
return ConfigurationSettings.AppSettings["connectionString"];
}
Wenn von Ihrer Anwendung Verbindungsinformationen in einer UDL-Datei gespeichert
werden, schränken Sie den Zugriff mit NTFS-Berechtigungen ein. Verwenden Sie die
folgende eingeschränkte Zugriffssteuerungsliste:
Administrators: Full Control
Process Account: Read
UDL-Dateien werden nicht verschlüsselt. Sie können Anmeldeinformationen als Klartext
enthalten. Wenn Benutzer Ihrer Anwendung derzeit zum Speichern von
Anmeldeinformationen in einer UDL-Datei gezwungen sind, sollten Sie Ihre Anwendung
mit einer sichereren Methode neu entwerfen.
66
Persist Security Info-Eigenschaft
Sie sollten die Persist Security Info-Eigenschaft von OLE DBVerbindungszeichenfolgen nie auf true oder yes festlegen. Wenn Sie dieses Attribut in
eine Verbindungszeichenfolge einschließen, wird mit der ConnectionString-Eigenschaft
das Kennwort aus der Verbindungszeichenfolge extrahiert, bevor diese an den Benutzer
zurückgegeben wird. Bei der Standardeinstellung false wird diese Information
verworfen, sobald die Verbindung zur Datenbank hergestellt ist. Weitere Informationen
finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15410.
Verschlüsseln von Benutzerdaten
Wenn Sie von Benutzern bereitgestellte vertrauliche Daten (beispielsweise
Kreditkartennummern) speichern, sollten Sie diese mit einem starken symmetrischen
Verschlüsselungsalgorithmus verschlüsseln, wie z. B. Triple DES (3DES). Verschlüsseln
Sie den 3DES-Verschlüsselungsschlüssel mit DPAPI (Data Protection API), und speichern
Sie den verschlüsselten Schlüssel in einem Registrierungsschlüssel, in dessen ACL nur
Administratoren und dem Konto Ihres Anwendungsprozesses Zugriff gewährt wird.
Die grundlegende Vorgehensweise ist nachstehend skizziert.
Führen Sie während der Entwicklung folgende Aufgaben aus:
1. Generieren Sie mit der RNGCryptoServiceProvider-Klasse einen starken
Verschlüsselungsschlüssel (192 Bit, 24 Byte).
2. Sichern Sie den Verschlüsselungsschlüssel, und speichern Sie die Sicherung an
einem physisch sicheren Speicherort.
3. Verschlüsseln Sie den Schlüssel mit DPAPI, und speichern Sie ihn in einem
Registrierungsschlüssel. Sichern Sie den Registrierungsschlüssel mit der folgenden
ACL:
Administrators: Full Control
Process Account (for example ASPNET): Read
Verschlüsseln Sie Daten für das Speichern in der Datenbank wie folgt:
1. Beziehen Sie die zu verschlüsselnden Daten.
2. Rufen Sie den verschlüsselten Verschlüsselungsschlüssel aus der Registrierung ab.
3. Entschlüsseln Sie den Verschlüsselungsschlüssel mit DPAPI.
4. Verschlüsseln Sie die Daten mit der TripleDESCryptoServiceProvider-Klasse und
dem Verschlüsselungsschlüssel.
5. Speichern Sie die verschlüsselten Daten in der Datenbank.
67
Entschlüsseln Sie die verschlüsselten Daten wie folgt:
1. Rufen Sie die verschlüsselten Daten aus der Datenbank ab.
2. Rufen Sie den verschlüsselten Verschlüsselungsschlüssel aus der Registrierung ab.
3. Entschlüsseln Sie den Verschlüsselungsschlüssel mit DPAPI.
4. Entschlüsseln Sie die Daten mit der TripleDESCryptoServiceProvider-Klasse.
Wenn das DPAPI-Konto beschädigt wird, mit dem der Verschlüsselungsschlüssel
verschlüsselt wurde, kann dank dieses Verfahrens die Sicherung des 3DES-Schlüssels
vom Sicherungsspeicherort abgerufen und mit DPAPI mit einem neuen Konto
verschlüsselt werden. Der neue verschlüsselte Schlüssel kann in der Registrierung
gespeichert werden, und die Daten in der Datenbank können weiterhin entschlüsselt
werden.
Anmerkung
werden.
Auf diese Weise verschlüsselte Informationen können nicht indiziert
Überprüfen von Kennwörtern mit einem
Einweghashwert
Zum Überprüfen von Kennwörtern auf dem Server sollten Sie möglicherweise nicht das
Kennwort, sondern nur einen Hashwert des Kennwortes speichern. Mit einem
Hashingalgorithmus werden binäre Werte beliebiger Länge auf kleine binäre Werte fester
Länge abgebildet. Der entstehende Hashwert wird auch als Einweghashwert bezeichnet
und ist eine kompakte Darstellung der Daten, aus denen er generiert wurde. Er kann als
digitaler Fingerabdruck angesehen werden. Ein als Hashwert gespeichertes Kennwort ist
sicherer als das Kennwort und sogar sicherer als das verschlüsselte Kennwort, da ein
Hashingalgorithmus nur in eine Richtung vollständig deterministisch ist.
Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15411
und http://go.microsoft.com/fwlink/?LinkId=15412.
Verwaltung von Ausnahmen
Sie sollten keine unverarbeiteten Fehlercodes an einen Benutzer zurückgeben, da diese
Codes möglicherweise zu viele Informationen über die Struktur und die Inhalte Ihrer
Datenbank und die Authentifizierungsmechanismen enthalten. Ohne eine
ordnungsgemäße Verwaltung von Ausnahmen können bei Fehlerbedingungen, die durch
eine fehlerhafte Konfiguration, Probleme in Ihrem Code oder zerstörerische Eingaben
verursacht wurden, Verbindungszeichenfolgen, Datenbank-Metadaten, SQLCodefragmente sowie Rohdaten sichtbar werden, die nicht für Endbenutzer bestimmt
sind. Fehlermeldungen können auch Informationen wie Softwareversionen und
Konfigurationsdetails enthalten. Durch das Offenlegen von derartigen internen
Informationen wird Hackern das Erstellen eines Profils für Ihr System erleichtert, es hat
aber wenig Wert für Benutzer.
68
Auffangen und Protokollieren von Ausnahmen
Schließen Sie Datenzugriffscode in die Befehle try und catch ein, um Ausnahmen
aufzufangen und zu protokollieren. Beim Fehlschlagen von Verbindungsversuchen sollten
geeignete Informationen in einer Datei protokolliert werden, die mit einer
Zugriffssteuerungsliste (ACL) gesichert ist. Außerdem sollten nicht mehr benötigte
Verbindungen immer explizit geschlossen werden.
In den folgenden Beispielen werden diese bewährten Methoden für den Fall
veranschaulicht, dass ADO.NET verwendet wird. Beachten Sie, dass der Typ der jeweils
von ADO.NET generierten Ausnahme vom Datenprovider abhängt.

Vom .NET Framework-Datenprovider für SQL Server werden SqlException-Objekte
generiert.

Vom .NET Framework-Datenprovider für OLE DB werden OleDbException-Objekte
generiert.

Vom .NET Framework-Datenprovider für ODBC werden OdbcException-Objekte
generiert.
In diesem Code wird der .NET Framework-Datenprovider für SQL Server verwendet, um
Ausnahmen vom Typ SqlException aufzufangen:
try
{
// Data access code
}
catch (SqlException sqlex) // more specific
{
}
catch (Exception ex) // less specific
{
}
Ausführliche Informationen zu Datenbank-Zugriffsfehlern werden durch die
Eigenschaften der SqlException-Klasse offen gelegt. Dazu gehören die MessageEigenschaft, die eine Beschreibung des Fehlers enthält, die Number-Eigenschaft, mit
der der Typ des jeweiligen Fehlers eindeutig identifiziert wird, und die StateEigenschaft, die weitere Informationen enthält. So wird normalerweise ein bestimmtes
Auftreten einer speziellen Fehlerbedingung gekennzeichnet. Wenn beispielsweise eine
gespeicherte Prozedur für mehrere Zeilen den gleichen Fehler generiert, kennzeichnet
die State-Eigenschaft das jeweilige Auftreten. Außerdem gibt es die Errors-Auflistung,
die eine Reihe von SqlError-Objekten mit ausführlichen Informationen zu SQL ServerFehlern enthält.
69
Im folgenden Codefragment wird gezeigt, wie eine SQL Server-Fehlerbedingung mithilfe
des Datenproviders verarbeitet werden kann.
using System.Data;
using System.Data.SqlClient;
using System.Diagnostics;
// Method exposed by a Data Access Layer (DAL) Component
public string GetProductName( int ProductID )
{
SqlConnection conn = new SqlConnection(
"server=(local);Integrated Security=SSPI;database=products");
// Enclose all data access code within a try block
try
{
conn.Open();
SqlCommand cmd = new SqlCommand("LookupProductName", conn );
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@ProductID", ProductID );
SqlParameter paramPN =
cmd.Parameters.Add("@ProductName", SqlDbType.VarChar, 40 );
paramPN.Direction = ParameterDirection.Output;
cmd.ExecuteNonQuery();
// The finally code is executed before the method returns
return paramPN.Value.ToString();
}
catch (SqlException sqlex)
{
// Handle data access exception condition
// Log specific exception details
LogException(sqlex);
// Wrap the current exception in a more relevant
// outer exception and re-throw the new exception
70
throw new Exception(
"Failed to retrieve product details for product ID: " +
ProductID.ToString(), sqlex );
}
finally
{
conn.Close(); // Ensures connection is closed
}
}
// Helper routine that logs SqlException details to the
// Application event log
private void LogException( SqlException sqlex )
{
EventLog el = new EventLog();
el.Source = "CustomAppLog";
string strMessage;
strMessage = "Exception Number : " + sqlex.Number +
"(" + sqlex.Message + ") has occurred";
el.WriteEntry( strMessage );
foreach (SqlError sqle in sqlex.Errors)
{
strMessage = "Message: " + sqle.Message +
" Number: " + sqle.Number +
" Procedure: " + sqle.Procedure +
" Server: " + sqle.Server +
" Source: " + sqle.Source +
" State: " + sqle.State +
" Severity: " + sqle.Class +
" LineNumber: " + sqle.LineNumber;
el.WriteEntry( strMessage );
}
}
71
Schließen aller nicht benötigten
Datenbankverbindungen
Nach Auftreten eines Fehlers ist es wichtig, die Datenbankverbindungen zu schließen
und alle sonstigen begrenzten Ressourcen freizugeben. Verwenden Sie finally-Blöcke
oder die C#-Anweisung using, damit Verbindungen unabhängig vom Auftreten einer
Ausnahmebedingung geschlossen werden. Im nächsten Beispiel wird die Verwendung
eines finally-Blockes verdeutlicht. Wie nachstehend gezeigt, kann auch die
C#-Anweisung using verwendet werden:
using ((SqlConnection conn = new SqlConnection(connString)))
{
conn.Open();
// Connection will be closed if an exception is generated or if control
flow
// leaves the scope of the using statement normally
}
Beispiel: Sicherheit für eine
Datenzugriffskomponente
Im folgenden Code wird eine Verbindungszeichenfolge aus der Registrierung abgerufen
und mithilfe der verwalteten DPAPI-Hilfsprogrammbibliothek entschlüsselt, die in MSDN
unter http://go.microsoft.com/fwlink/?LinkId=15413 bereitgestellt wird. Mit diesem
Beispiel wird eine Implementierung einer CheckProductStockLevel-Methode
veranschaulicht, mit der der Lagerbestand aus einer Artikeldatenbank abgefragt wird.
Im Code sind einige der wichtigen Sicherheitsfunktionen für Datenzugriffscode
veranschaulicht, die weiter oben aufgeführt werden.
public static int CheckProductStockLevel(string productCode)
{
int quantity = 0;
// (1) Code protected by try/catch block
try
{
// (2) Input validated with regular expression
Regex rex = new Regex("^[A-Za-z0-9]{12}$");
if (rex.IsMatch(productCode) == false)
72
// Error messages should be retrieved from a resource assembly to
// assist localization. The localization code is omitted here for
brevity
throw new ArgumentException("Invalid product code" );
//(3) The using statement ensures that the connection is closed
using (SqlConnection conn = new SqlConnection(GetConnectionString()))
{
// (4) Use of parameterized stored procedures is a countermeasure
for
//
SQL injection attacks
SqlCommand cmd = new SqlCommand("spCheckProduct", conn);
cmd.CommandType = CommandType.StoredProcedure;
// Parameters are type checked
SqlParameter parm =
cmd.Parameters.Add("@ProductCode",
SqlDbType.VarChar,12).Value =
productCode;
// Define the output parameter
SqlParameter retparm = cmd.Parameters.Add("@quantity",
SqlDbType.Int);
retparm.Direction = ParameterDirection.Output;
conn.Open();
cmd.ExecuteNonQuery();
quantity = (int)retparm.Value;
}
}
catch (SqlException sqlex)
{
// (5) Full exception details are logged. Generic (safe) error message
//
is thrown back to the caller based on the SQL error code
//
Log and error identification code has been omitted for clarity
throw new Exception("Error Processing Request");
}
73
catch (Exception ex)
{
// Log full exception details
throw new Exception("Error Processing Request");
}
return quantity;
}
// (6) Encrypted database connection string is held in the registry
private static string GetConnectionString()
{
// Retrieve the cipher text from the registry; the process account must be
// granted Read access by the key's ACL
string encryptedString = (string)Registry.LocalMachine.OpenSubKey(
@"Software\OrderProcessing\")
.GetValue("ConnectionString");
// Use the managed DPAPI helper library to decrypt the string
DataProtector dp = new
DataProtector(DataProtector.Store.USE_MACHINE_STORE);
byte[] dataToDecrypt = Convert.FromBase64String(encryptedString);
return Encoding.ASCII.GetString(dp.Decrypt(dataToDecrypt,null));
}
Im obigen Code werden die nachfolgend aufgelisteten Sicherheitsmerkmale vorgestellt
(diese sind durch die Nummern in den Kommentarzeilen identifiziert).
1. Der Datenzugriffscode befindet sich innerhalb eines try/catch-Blockes.
Dies ist wichtig, damit im Fall einer Ausnahme keine Informationen der Systemebene
an die aufrufende Anwendung zurückgegeben werden. Möglicherweise wird die
Ausnahme von der aufrufenden ASP.NET-Webanwendung oder vom aufrufenden
Webdienst verarbeitet, und es wird eine geeignete generische Fehlermeldung an den
Client zurückgegeben. Im Datenzugriffscode wird dies jedoch nicht vorausgesetzt.
2. Die Eingabe wird mit einem regulären Ausdruck überprüft. Die übergebene
Produkt-ID wird geprüft, damit sichergestellt ist, dass sie ausschließlich Zeichen von
A-Z und 0-9 enthält und nicht länger als 12 Zeichen ist. Dies ist die erste in einer
Reihe von Gegenmaßnahmen, mit denen SQL-Injektionsangriffen vorgebeugt werden
soll.
74
3. Das SqlConnection-Objekt wird innerhalb der C#-Anweisung „using“
erstellt. Somit wird die Verbindung unabhängig vom Auftreten einer Ausnahme
immer innerhalb der Methode geschlossen. So wird die Gefahr von DoS-Angriffen
(Denial of Service) verringert, mit denen sämtliche zur Datenbank bestehenden
Verbindungen verwendet werden sollen. Eine ähnliche Funktionalität kann mit einem
finally-Block erreicht werden.
4. Für Datenzugriffe werden parametrisierte gespeicherte Prozeduren
verwendet. Dies ist eine weitere Maßnahme gegen SQL-Injektionen.
5. An den Client werden keine ausführlichen Fehlerinformationen
zurückgegeben. Zum Vereinfachen der Problemdiagnose werden ausführliche
Informationen zu Ausnahmen protokolliert.
6. Die verschlüsselte Datenbank-Verbindungszeichenfolge wird in der
Registrierung gespeichert. Eine der sichersten Möglichkeiten zum Speichern einer
Datenbank-Verbindungszeichenfolge besteht darin, sie mit DPAPI zu verschlüsseln
und den verschlüsselten Text in einem Registrierungsschlüssel zu speichern, der mit
einer Zugriffssteuerungsliste (ACL) gesichert ist. Abhängig davon, welcher Prozess
die Komponente hostet, können folgende ACLs geeignet sein: Administratoren:
Vollzugriff; ASP.NET (oder Konto für Enterprise Services-Prozess): Lesen.
Überlegungen zur Codezugriffssicherheit
In manchen Bereitstellungsszenarios kann die Codezugriffssicherheit (Code Access
Security, CAS) sinnvoll sein. Clientsoftware, die mit .NET entwickelt wurde, unterstützt
Datenzugriffe mit Berechtigungsprüfungen der Codezugriffssicherheit. Die genauen
Anforderungen sind unterschiedlich und richten sich nach der Implementierung des von
Ihnen gewählten verwalteten ADO.NET-Datenproviders. Wenn Ihr Datenzugriffscode in
einer vollständig vertrauten Umgebung ausgeführt und beispielsweise immer von
Webanwendungen aufgerufen wird, die für vollständiges Vertrauen konfiguriert sind,
sind vom verwalteten Datenprovider ausgegebene Anforderungen von Berechtigungen
mit Codezugriffssicherheit immer erfolgreich.
Wenn Ihr Datenzugriffscode dagegen auch aufrufende Anwendungen unterstützen soll,
denen nur teilweise vertraut wird, müssen Sie die Berechtigungsanforderungen des
verwalteten Datenproviders kennen. Wenn für den Provider beispielsweise
Berechtigungen erforderlich sind, die einer Webanwendung mit mittlerer
Vertrauenswürdigkeit (einer üblichen Konfiguration, die von hostenden Unternehmen
verwendet wird) nicht erteilt werden, schlägt die Berechtigungsanforderung beim
Datenbankzugriff fehl, und es wird eine SecurityException-Ausnahme ausgelöst. Für
ein solches Szenario müssen Sie Ihren Datenzugriffscode isolieren, um die zusätzlichen
Berechtigungsanforderungen zu kapseln. Dazu müssen Sie den Datenzugriffscode in eine
eigene Assembly platzieren, ihn also nicht in die Darstellungslogik einer Webanwendung
oder in zugehörige CodeBehind-Dateien aufnehmen.
75
Wenn Sie über den .NET Framework-Datenprovider für SQL Server auf SQL Server
zugreifen, wird vom Provider die SQL-Clientberechtigung (SqlClientPermission)
angefordert. Diese Berechtigung ist für jede Datenzugriffskomponente erforderlich, bei
der die Kommunikation mit SQL Server über diesen Provider erfolgt. Weitere
Informationen zu SqlClientPermission und zu den Berechtigungsanforderungen der
anderen Datenprovider finden Sie unter http://go.microsoft.com/fwlink/?LinkId=15414.
Anmerkung Diese Berechtigungen sind auch für jeglichen Code erforderlich, der
Ihre Datenzugriffskomponente aufruft. Dies gilt nur dann nicht, wenn Sie Ihre
Datenzugriffsassembly im Sandboxbereich ausführen, weil die
Berechtigungsanforderung die vollständige Aufrufliste durchläuft.
Anmerkung Die Vertrauensstufe einer Webanwendung wird durch die
Konfiguration des zugehörigen <trust>-Elements in Web.config oder
Machine.config festgelegt.
Mit SqlClientPermission kann auch der zulässige Wertebereich von Name/Wert-Paaren
für eine an das SqlConnection-Objekt übergebene Verbindungszeichenfolge beschränkt
werden. Im folgenden Code wurde die CheckProductStockLevel-Methode um eine
zusätzliche Sicherheitsprüfung erweitert, damit in der Verbindungszeichenfolge keine
leeren Kennwörter verwendet werden können.
[SqlClientPermissionAttribute(SecurityAction.PermitOnly,
AllowBlankPassword=false)]
public static int CheckProductStockLevel(string productCode)
{
. . .
}
Da für den Code nur Lesezugriff auf einen bestimmten Registrierungsschlüssel
erforderlich ist, können außerdem Zugriffe auf andere Bereiche der Registrierung mit
dem RegistryPermissionAttribute verhindert werden.
[RegistryPermissionAttribute(SecurityAction.PermitOnly,
Read=@"HKEY_LOCAL_MACHINE\Software\OrderProcessing")]
[SqlClientPermissionAttribute(SecurityAction.PermitOnly,
AllowBlankPassword=false)]
public static int CheckProductStockLevel(string productCode)
{
. . .
}
76
In der folgenden Tabelle sind die Berechtigungen aufgeführt, die Ihren
Datenzugriffsassemblys (und deren Aufrufern, wenn Sie den Datenzugriffscode nicht im
Sandboxbereich ausführen) für jeden ADO.NET-Datenprovider erteilt werden müssen.
ADO.NETDatenprovider
Erforderliche Berechtigungen mit Codezugriffssicherheit
SQL Server
SQL-Clientberechtigung (SqlClientPermission).
(Wird von Webanwendungen mit mittlerer Vertrauenswürdigkeit
unterstützt.)
OLE DB
OLE DB-Berechtigung (OleDbPermission; momentan noch ohne
Auswirkung; für einen OLE DB-Provider in .NET Framework 1.0
und 1.1 sind aufrufende Anwendungen mit vollständiger
Vertrauenswürdigkeit erforderlich.)
Oracle
Oracle-Berechtigung (OraclePermission; momentan noch ohne
Auswirkung; für einen Oracle-Provider in .NET Framework 1.0
und 1.1 sind aufrufende Anwendungen mit vollständiger
Vertrauenswürdigkeit erforderlich.)
ODBC
ODBC-Berechtigung (OdbcPermission; momentan noch ohne
Auswirkung; für einen ODBC-Provider in .NET Framework 1.0
und 1.1 sind aufrufende Anwendungen mit vollständiger
Vertrauenswürdigkeit erforderlich.)
MSDE
SQL Server 2000 Desktop Engine (MSDE 2000) ist eine Version des SQL ServerDatenmoduls, die zum Weitervertreiben mit Clientanwendungen vorgesehen ist. MSDE
besitzt die gleiche Sicherheitsarchitektur und die gleichen Sicherheitsfunktionen wie
SQL Server. Bei Verwendung von MSDE gelten die folgenden zusätzlichen Richtlinien.

Wenn Sie eine MSDE-Instanz installieren, die nur als lokaler Datenspeicher
verwendet wird, sollten Sie die Server-Netzwerkbibliotheken deaktivieren. Weitere
Informationen finden Sie im Microsoft Knowledge Base-Artikel 814130, „How to
Secure Network Connectivity for SQL Server 2000 Local Databases“, unter
http://go.microsoft.com/fwlink/?LinkId=16419.

Beim Verteilen von MSDE an Ihre Kunden sollten Sie nicht die
Zusammenführungsmodule, sondern das von Microsoft bereitgestellte
Installationsprogramm verwenden.

Wenn Ihr Produkt MSDE umfasst, sollten Sie dies Ihren Kunden mitteilen.
Möglicherweise müssen sie zukünftig MSDE-spezifische Softwareaktualisierungen
installieren oder akzeptieren.

Fügen Sie bewährte Sicherheitsmethoden in Ihre Produktdokumentation ein.
77
Abschluss: Prüfliste für bewährte Methoden
In der folgenden Prüfliste sind die bewährten Methoden zusammengefasst, die in diesem
Whitepaper erläutert werden. Weitere Informationen finden Sie in den obigen
Ausführungen.
Prüfliste für Administratoren
Einrichten der Umgebung vor der
Installation
Physische Sicherheit

Stellen Sie die physische Sicherheit
Ihres Servers sicher.
Firewalls

Richten Sie einen Firewall zwischen
Ihrem Server und dem Internet ein.

Blockieren Sie im Umkreisfirewall
immer den TCP-Port 1433 und den
UDP-Port 1434. Wenn weitere Ports
von benannten Instanzen überwacht
werden, sollten auch diese Ports
blockiert werden.

In einer mehrstufigen Umgebung
sollten Sie mehrere Firewalls
verwenden, um abgeschirmte
Subnetze zu erstellen.

Isolieren Sie Dienste, um das Risiko zu
verringern, dass bei einem Angriff
über einen Dienst auch andere Dienste
angegriffen werden.

Installieren Sie SQL Server niemals
auf einem Domänencontroller.

Führen Sie jeden SQL Server-Dienst
mit einem eigenen Windows-Konto
aus.

Führen Sie in einer mehrstufigen
Umgebung Weblogik und
Geschäftslogik auf verschiedenen
Computern aus.
Isolieren von Diensten
78
Einrichten der Umgebung vor der
Installation (Fortsetzung)
Dienstkonten

Erstellen Sie Windows-Konten zum
Ausführen von SQL Server-Diensten
mit möglichst geringen
Berechtigungen.
Dateisystem

Verwenden Sie NTFS.

Verwenden Sie RAID für besonders
wichtige Datendateien.
Neueste Version und neuestes Service
Pack

Installieren Sie immer die neuesten
Service Packs und Sicherheitspatches.
Dienstkonten

Führen Sie SQL Server-Dienste nur
mit den Mindestberechtigungen aus.

Verwenden Sie Enterprise Manager,
um Dienste den Windows-Konten
zuzuordnen.
Authentifizierungsmodus

Machen Sie die WindowsAuthentifizierung für Verbindungen mit
SQL Server erforderlich.
Sichere Kennwörter

Weisen Sie dem Konto sa immer ein
sicheres Kennwort zu (auch dann,
wenn Sie die WindowsAuthentifizierung verwenden).

Verwenden Sie immer sichere
Kennwörter für alle SQL ServerKonten.
Installation
79
Konfigurationsoptionen und
Einstellungen nach der Installation
Löschen oder Sichern alter Setup-Dateien

Löschen oder archivieren Sie nach der
Installation die folgenden Dateien:
Sqlstp.log, Sqlsp.log und Setup.iss.
Sie finden diese Dateien für eine
Standardinstallation im Ordner
systemdrive:\Programme\Microsoft
SQL Server\MSSQL\Install oder für
eine benannte Instanz im Ordner
systemdrive:\Programme\Microsoft
SQL Server\MSSQL$InstanceName\
Install.

Ist das aktuelle System eine
Aktualisierung von SQL Server 7.0,
löschen Sie folgende Dateien:
Setup.iss im Ordner %Windir% und
Sqlsp.log im Windows-Ordner Temp.
Wählen statischer Ports für benannte
Instanzen

Weisen Sie den benannten Instanzen
von SQL Server statische Ports zu.
Festlegen der Überwachungsebene für
Anmeldungen

Legen Sie die Überwachungsebene für
Anmeldungen auf Fehler oder Alle
fest.
Aktivieren der Sicherheitsüberwachung

Aktivieren Sie die
Sicherheitsüberwachung von
sysadmin-Aktionen, Änderungen bei
der Mitgliedschaft fester Rollen, allen
zur Anmeldung gehörenden
Aktivitäten und Kennwortänderungen.

Nachdem Sie die entsprechenden
Überwachungsoptionen aktiviert
haben, sollten Sie ein
Überwachungsskript erstellen, es in
eine gespeicherte Prozedur einbinden
und die gespeicherte Prozedur zum
automatischen Starten kennzeichnen.
Sichern von sa, auch im WindowsAuthentifizierungsmodus

Weisen Sie dem Konto sa ein sicheres
Kennwort zu, auch auf Servern, in
deren Konfiguration die WindowsAuthentifizierung erforderlich gemacht
wird.
Entfernen von Beispieldatenbanken

Entfernen Sie Beispieldatenbanken
von den Produktionsservern.
80
Sicherer Betrieb
Sicherheitsmodell

Arbeiten Sie mit dem SQL ServerSicherheitsmodell.
Sicherungsrichtlinien

Sichern Sie alle Daten regelmäßig, und
speichern Sie Kopien an einem
sicheren Ort außerhalb des
Unternehmens.

Testen Sie Ihr NotfallWiederherstellungssystem.
Reduzieren von Schnittstellen und
Funktionen

Reduzieren Sie die Schnittstellen Ihres
Systems, die Angriffen ausgesetzt sein
können, indem Sie nur die in Ihrer
Umgebung benötigten Dienste und
Funktionen ausführen.
Reduzieren der Administratoranzahl

Schränken Sie die Mitgliedschaft der
festen Serverrolle sysadmin auf
wenige vertrauenswürdige Personen
ein.
Sichere Kennwörter

Verwenden Sie komplexe Kennwörter
für alle SQL Server-Konten.
Datenbankübergreifende Besitzverkettung

Deaktivieren Sie die
datenbankübergreifende
Besitzverkettung, wenn sie in Ihrem
System nicht verwendet wird.
xp_cmdshell

Standardmäßig kann xp_cmdshell
nur von Mitgliedern der sysadminRolle ausgeführt werden. Sie sollten
diese Standardeinstellung nicht
ändern.

Erteilen Sie Benutzern, die nicht
Mitglied der sysadmin-Rolle sind,
keine Ausführungsberechtigung für
xp_cmdshell.
81
Sicherer Betrieb (Fortsetzung)
Verschlüsselung

Installieren Sie ein Zertifikat, damit
SSL-Verbindungen ermöglicht werden.

Für Zertifikate sollte der voll
gekennzeichnete DNS-Name des
Servers verwendet werden.

Verwenden Sie das SQL ServerDienstkonto, um Datenbankdateien
mit EFS zu verschlüsseln.

Wenn für Ihre Anwendung eine
Datenverschlüsselung erforderlich ist,
sollten Sie möglicherweise
entsprechende Produkte verwenden
(z. B. von Protegrity, Inc. oder
Application Security, Inc.).
Rollen und Gruppen

Fassen Sie Benutzer in SQL ServerRollen oder Windows-Gruppen
zusammen, um die Verwaltung der
Berechtigungen zu vereinfachen.
Berechtigungen

Erteilen Sie der public-Datenbankrolle
niemals Berechtigungen.
Verteilte Abfragen

Wenn Sie SQL Server in einer
Umgebung einrichten, die verteilte
Abfragen unterstützt, sollten Sie
Verbindungsserver und nicht
Remoteserver verwenden.

Ermöglichen Sie den
Verbindungsserverzugriff nur den
Benutzernamen, die Zugriff benötigen.

Deaktivieren Sie den Ad-hocDatenzugriff für alle Provider außer
SQL OLE DB für alle Benutzer außer
den Mitgliedern der festen Serverrolle
sysadmin.

Ermöglichen Sie den Ad-hoc-Zugriff
nur für vertraute Provider.
82
Sicherer Betrieb (Fortsetzung)
Gastkonten

Aktivieren Sie nicht das Konto Guest.
Dienstkonten

Verwenden Sie SQL Server
Enterprise Manager, um das zu einem
SQL Server-Dienst zugeordnete Konto
zu ändern.

Wenn Sie Änderungen für mehrere
Dienste vornehmen, müssen Sie diese
Änderungen mit Enterprise Manager
auf jeden Dienst getrennt anwenden.
MBSA (Microsoft Baseline Security
Analyzer)

Fügen Sie MBSA zu Ihrem
wöchentlichen Wartungsplan hinzu,
und befolgen Sie alle
Sicherheitsempfehlungen von MBSA.
Durchsuchen von Anmeldeinformationen

Suchen Sie regelmäßig nach Konten
mit NULL-Kennwort, und entfernen Sie
solche Konten, oder weisen Sie ihnen
sichere Kennwörter zu.

Löschen Sie nicht verwendete Konten.
Auflisten der Mitgliedschaft in festen
Rollen

Durchsuchen Sie regelmäßig feste
Server- und Datenbankrollen, damit
sichergestellt ist, dass nur
vertrauenswürdigen Personen
Mitgliedschaft erteilt ist.
Automatisch gestartete Prozeduren

Überprüfen Sie die Sicherheit von
gespeicherten Prozeduren, die für
automatisches Starten (Autostart)
gekennzeichnet sind.
Benutzername-Benutzer-Zuordnung

Stellen Sie sicher, dass die
Zuordnungen zwischen
Datenbankbenutzern und
Benutzernamen auf der Serverebene
richtig sind.

Führen Sie regelmäßig
sp_change_users_login mit der
Option report aus, um zu überprüfen,
ob die Zuordnungen Ihren
Erwartungen entsprechen.
Empfohlene regelmäßige
Verwaltungsvorgänge
83
Empfohlene regelmäßige
Verwaltungsvorgänge (Fortsetzung)
Direkte Katalogaktualisierungen

Lassen Sie keine direkten
Katalogaktualisierungen zu.
Datenbankübergreifende Besitzverkettung

Verwenden Sie sp_dboption, um
Datenbanken aufzulisten und zu
überprüfen, für die die
datenbankübergreifende
Besitzverkettung aktiviert ist.

Verwalten Sie eine Inventarliste mit
allen Versionen, Editionen und
Sprachen von SQL Server, für die Sie
zuständig sind.

Nehmen Sie Instanzen von MSDE in
die Inventarliste auf.

Verwenden Sie SQL Scan und
SQL Check (beide über die MicrosoftWebsite verfügbar), um in Ihrer
Domäne nach Instanzen von
SQL Server zu suchen.
Bulletins

Abonnieren Sie die MicrosoftSicherheitsbulletins.
Anwenden von Patches

Verwalten Sie Testsysteme, die die
gleiche Konfiguration aufweisen wie
Ihre Produktionssysteme und
umgehend für das Testen neuer
Patches zur Verfügung stehen.

Testen Sie Patches sorgfältig, bevor
Sie sie auf Produktionssysteme
anwenden.

Erwägen Sie das Patchen von
Entwicklungssystemen mit relativ
wenig Testen.
Bewährte Methoden für das Patchen
von Instanzen
Instanzerkennung und -auflistung
84
Prüfliste für Entwickler
Zusätzlich zu den bisher aufgeführten Punkten sollten Entwickler die folgenden
bewährten Methoden beachten.
Allgemein
Wirksames Verwenden der
Besitzverkettung
Verwenden von Rollen zum Vereinfachen
der Berechtigungsverwaltung und des
Besitzes

Verwenden Sie die Besitzverkettung in
einer einzelnen Datenbank, um die
Verwaltung der Berechtigungen zu
vereinfachen.

Vermeiden Sie nach Möglichkeit eine
datenbankübergreifende
Besitzverkettung.

Wenn eine datenbankübergreifende
Besitzverkettung unumgänglich ist,
sollten Sie sicherstellen, dass die
beiden Datenbanken immer als eine
administrative Einheit bereitgestellt
werden.

Weisen Sie Berechtigungen der Rollen
statt direkt den Benutzern zu.

Legen Sie als Objektbesitzer Rollen
statt Benutzer fest, wenn Sie
Anwendungsänderungen für den Fall
verhindern möchten, dass ein als
Besitzer festgelegter Benutzer
gelöscht wird.
85
Allgemein (Fortsetzung)
Aktivieren der Verschlüsselung (SSL oder
IPSec)

Aktivieren Sie verschlüsselte
Verbindungen zu Ihrem Server, und
erwägen Sie, nur verschlüsselte
Verbindungen zuzulassen.

Wenn Sie die SQL ServerAuthentifizierung zulassen, sollten Sie
unbedingt die Netzwerkebene mit
IPSec oder die Sitzung mit SSL
verschlüsseln.
Kein Zurückgeben von SQL ServerFehlern an den jeweiligen Benutzer

Ihre Anwendung sollte SQL ServerFehler nicht an den Endbenutzer
zurückgeben. Protokollieren Sie solche
Fehler, oder senden Sie sie an den
Systemadministrator.
Verhindern von SQL-Injektionen

Verhindern Sie SQL-Injektionen
dadurch, dass sämtliche
Benutzereingaben überprüft werden,
bevor sie zum Server übertragen
werden.

Begrenzen Sie den Bereich möglicher
Schäden, indem Sie nur Konten mit
Mindestberechtigungen das Senden
von Benutzereingaben an den Server
ermöglichen.

Führen Sie auch SQL Server nur mit
den Mindestberechtigungen aus.
86
Optionen für eine mehrstufige
Umgebung
Dieselbe/vertraute Domäne
(vollständige WindowsAuthentifizierung)
Gehören der Anwendungsserver und der
Datenbankserver zur selben Domäne oder zu
vertrauten Domänen, sollten Sie die WindowsAuthentifizierung verwenden und eine vollständige Bereitstellung konfigurieren, so dass in
allen Clientkontexten Tunnelverbindungen zu
SQL Server hergestellt werden. Dies ermöglicht
das Überwachen aller Benutzer, die auf
SQL Server zugreifen, sowie das Durchsetzen
der Windows-Sicherheitsrichtlinien. Außerdem
müssen Anmeldeinformationen nicht in der
mittleren Stufe gespeichert werden. In diesem
Szenario stellt der Client eine Verbindung zum
Anwendungsserver her, der dann die Identität
des Clients annimmt und eine Verbindung zu
SQL Server herstellt.

Jeder Benutzer des Anwendungsservers
muss einen gültigen Windows-Benutzernamen auf dem Datenbankserver besitzen,
und die Delegierung muss aktiviert sein.

Alle in diesem Szenario interagierenden
Systeme (auch der Domänencontroller)
müssen Computer unter Windows 2000 oder
höher sein.

Für das Konto, mit dem die Anwendung
ausgeführt wird, muss die Active DirectoryOption Konto wird für Delegierungszwecke vertraut aktiviert sein.

Das Clientkonto muss delegiert werden
können (stellen Sie sicher, dass die Active
Directory-Benutzerkontooption Konto kann
nicht delegiert werden deaktiviert ist).

Der Anwendungsdienst muss einen gültigen
SPN (Service Principal Name,
Dienstprinzipalnamen) aufweisen.
Anmerkung Die vollständige
Bereitstellung empfiehlt sich nicht in
unternehmensübergreifenden oder
internetbasierten Installationen, wenn
der Sicherheitsplan möglichst geringen
Benutzerzugriff auf den Datenbankserver
vorsieht, oder in Unternehmen, deren
Richtlinien die Delegierung ausschließen.
87
Optionen für eine
mehrstufige Umgebung
(Fortsetzung)
Gemischtes Szenario (teilweise
Windows-Authentifizierung)
Wenn die Stufe, die die Schnittstelle zum Internet
bildet, nicht für jeden möglichen Benutzer ein
eigenes Windows-Domänenkonto enthält, wird ein
Aufteilen der Authentifizierung in Bereiche
empfohlen. In der äußeren Stufe (auf der Benutzer
authentifiziert werden) sollten die
Anmeldeinformationen oder die gesamte Sitzung mit
SSL verschlüsselt werden. Von der äußeren Stufe
sollten Verbindungen zum Datenbankserver über die
Windows-Authentifizierung hergestellt werden, und
Transaktionsinformationen sollten in einem
gesonderten Sicherheitskontext weitergeleitet
werden, der nur die zum Erfüllen seiner Funktion
notwendigen Berechtigungen aufweist. Somit wird
die mittlere Stufe effektiv als zusätzliche
Schutzebene zwischen Ihrem Server und dem
Internet verwendet.
Anmerkung Es empfiehlt sich nicht, die
SQL Server-Authentifizierung zwischen der
mittleren Stufe und SQL Server zu verwenden, da
in diesem Fall die Anmeldeinformationen
gespeichert werden müssen. Wenn Sie die
SQL Server-Authentifizierung zwischen der
mittleren Stufe und SQL Server verwenden
müssen, sollten Sie mehrere Konten erstellen, die
entsprechend den verschiedenen Benutzerklassen
unterschiedliche Berechtigungsstufen aufweisen.
Dazu müssen Sie Programmlogik zur mittleren
Stufe hinzufügen, damit Verbindungen
entsprechend der jeweils gewünschten
Berechtigungsstufe zugewiesen werden können.
Verschiedene nicht vertraute
Domänen oder keine Domänen
(keine WindowsAuthentifizierung)
Wenn die Windows-Authentifizierung zwischen den
Stufen nicht möglich ist, sollten Sie für die
Anmeldesequenz die SSL-Verschlüsselung
erforderlich machen. Es empfiehlt sich, die gesamte
Sitzung zu verschlüsseln.

Sie sollten außerdem mit DPAPI die
Anmeldeinformationen verschlüsseln, die
gespeichert werden müssen.

Sie sollten verschlüsselte Anmeldeinformationen
in einem Registrierungsschlüssel speichern, der
mit einer Zugriffssteuerungsliste (Access Control
List, ACL) geschützt ist.
88
Prüfliste für Softwareanbieter
Zusätzlich zu allen bisher aufgeführten Punkten haben sich die folgenden
sicherheitsbezogenen Entwicklungsmethoden als hilfreich erwiesen, um die Qualität und
die Sicherheit von Code in verschiedenen Entwicklungsumgebungen zu verbessern.
Sicherheitsvorgänge
Kenntnisse zu unterschiedlichen
Sicherheitsproblemen

Stellen Sie sicher, dass die Mitglieder
Ihres Entwicklungsteams die
wesentlichen Sicherheitsprobleme
kennen: aktuelle Gefahren,
Sicherheitstrends, Wechseln von
Sicherheitsumgebungen und
Angriffsszenarios.

Machen Sie entsprechende
Sicherheitsschulungen für alle
Entwickler und Tester zur Pflicht.

Schärfen Sie das Bewusstsein für
Probleme, wie siteübergreifende
Skripterstellung, Pufferüberläufe,
SQL-Injektionen und gefährliche APIs.

Identifizieren Sie bestimmte
Bedrohungskategorien, die für Ihr
Produkt gelten; beispielsweise Denial
of Service (DoS), Ausweitung von
Berechtigungen, Spoofing,
Datenmanipulationen, Offenlegen von
Informationen und fehlende
Nachweisbarkeit.

Analysieren Sie
Sicherheitsbedrohungen für Ihr
Produkt, für jede Komponente einzeln.

Erstellen Sie anhand Ihres Produkts
eine Prüfliste für
Sicherheitsbedrohungen.

Fügen Sie Sicherheitsüberprüfungen
zu allen Stadien (vom Entwurf bis zum
Testen) Ihres
Produktentwicklungszyklus hinzu.
89
Sicherheitsvorgänge (Fortsetzung)
MSDE-Installationen
Wenn Sie MSDE zusammen mit Ihrer
Anwendung verteilen, gelten die
folgenden zusätzlichen Empfehlungen:

Installieren Sie MSDE mit dem
Windows-Sicherheitsmodus als
Standardeinstellung.

Verwenden Sie dabei niemals ein
leeres Kennwort für sa.

Wenn Sie MSDE an Ihre Kunden
verteilen, sollten Sie keine
Zusammenführungsmodule, sondern
das von Microsoft bereitgestellte
Installationsprogramm verwenden.

Wenn Sie eine Instanz von MSDE
installieren, die nur als lokaler
Datenspeicher verwendet wird, sollten
Sie die Server-Netzwerkbibliotheken
deaktivieren.

Wenn Ihr Produkt MSDE einschließt,
sollten Sie dies Ihren Kunden
mitteilen. Möglicherweise müssen sie
zukünftig MSDE-spezifische
Softwareaktualisierungen installieren
oder akzeptieren.

Mit MSDE wird standardmäßig der
SQL Server-Agent installiert, die
Einstellung für den Dienststarttyp
bleibt jedoch Manuell. Wenn Ihre
Anwendung den SQL Server-Agent
nicht verwendet, sollten Sie diese
Einstellung in Deaktiviert ändern.
Schließen Sie bewährte
Sicherheitsmethoden in Ihre
Produktdokumentation ein.
90
Anhang: Weitere Informationsquellen
Empfohlene Bücher:
Inside Microsoft SQL Server 2000, von Kalen Delaney (auch in deutscher Sprache
verfügbar). Copyright 2000, Microsoft Press. ISBN: 0-7356-0998-5.
Writing Secure Code: Second Edition, von Michael Howard und David LeBlanc.
http://go.microsoft.com/fwlink/?LinkId=16316
Dieses Buch ist eine hilfreiche Übungsressource, in der die häufigsten Sicherheitsfehler
besprochen werden, die beim Entwickeln/Codieren und Testen von
Komponenten/Anwendungen gemacht werden. Das Buch enthält bewährte Methoden
und Prüflisten zur Sicherheit. Es enthält außerdem Strategien zum Entwickeln von
sicheren Anwendungen, zum Schreiben von robustem Code, der wiederholten Angriffen
standhält, und zum Testen von Anwendungen hinsichtlich Sicherheitsfehlern.
Hacking Exposed Windows 2000, von Joel Scambray und Stuart McClure.
In diesem Buch werden die Vorgänge aus Sicht eines Hackers beschrieben. Es wird
ausführlich beschrieben, wie in Computer unter Windows 2000 eingedrungen werden
kann. Dabei wird das Bewusstsein dafür geschärft, wie solche Angriffe abgewehrt
werden können. Das Buch enthält außerdem einen Abschnitt zu SQL Server sowie dazu,
wie SQL Server verwendet werden kann, um sich unautorisierten Zugang zum gesamten
System zu verschaffen.
Designing Secure Web-Based Applications for Microsoft Windows 2000, von Michael
Howard.
http://go.microsoft.com/fwlink/?LinkId=15415
Dieses Buch enthält eine umfassende Vorstellung der Sicherheitskonzepte von
Microsoft Windows 2000, Internet Explorer, Internet Information Services, SQL Server
und COM+. Die Hauptaspekte des Softwareentwurfs für verschiedene
Sicherheitskategorien und -ebenen sowie die Interaktion zwischen isolierten
Sicherheitsinseln werden erläutert. Außerdem werden Kernthemen der Sicherheit
erläutert, wie Risikoanalyse , Gefahren, Authentifizierung, Autorisierung und
Datenschutz. Es wird aufgezeigt, wie Sie Risiken verringen können, indem Sie geeignete
Sicherheitsmaßnahmen auf Ihre Umgebung und Anwendungen anwenden. Manager,
Entwickler und Tester können die in diesem Buch vermittelten Kenntnisse dazu
verwenden, sich Komponenten aus der Sicherheitsperspektive anzusehen,
Gefahrenanalysen vorzunehmen und geeignete Gegenmaßnahmen zu ergreifen, indem
sie die Sicherheit des Codes/Entwurfs sowie die Testumgebungen entsprechend
verbessern.
91
Building Secure Microsoft ASP.NET Applications, von J. D. Meier (u.a.).
http://go.microsoft.com/fwlink/?LinkId=15416
In diesem Handbuch wird ein praktischer, szenario-orientierter Ansatz für das Entwerfen
und Erstellen von sicheren ASP.NET-Anwendungen für Windows 2000 sowie Version 1.0
von .NET Framework vorgestellt. Der Schwerpunkt des Buches liegt auf den
Schlüsselelementen der Authentifizierung, Autorisierung und sicheren Kommunikation in
und zwischen den Stufen von verteilten .NET-Webanwendungen.
Firewalls and Internet Security: Second Edition, von William R. Cheswick, Steven M.
Bellovin und Aviel D. Rubin. Addison-Wesley, 2003.
Dieses Buch ist die Standardeinführung in die Internetsicherheit. Sehr empfehlenswert.
Empfohlene Tools, Whitepapers und
Präsentationen
http://go.microsoft.com/fwlink/?LinkId=15417
Diese Site enthält eine umfassende Zusammenstellung von Hyperlinks zu Whitepapers
zur SQL Server-Sicherheit, bewährten Methoden für Unternehmen, Sicherheitsbulletins
und vielem mehr.
http://go.microsoft.com/fwlink/?LinkId=15419
Das Tool MBSA (Microsoft Baseline Security Analyzer). Dieses Tool unterstützt Sie beim
Analysieren der Sicherheit eines Systems. Es wird empfohlen, dass Administratoren
dieses Tool regelmäßig ausführen. Mit diesem Tool werden einige SQL Server-spezifische
Prüfungen ausgeführt.
http://go.microsoft.com/fwlink/?LinkId=15422
Der Assistent für kritische Updates von SQL Server.
Microsoft-Sites zu SQL Server und Sicherheit
http://go.microsoft.com/fwlink/?LinkId=15423
Der Bereich der Microsoft-Website, in dem es ausschließlich um Sicherheit geht.
http://go.microsoft.com/fwlink/?LinkId=15424
Die SQL Server-Hauptsite mit Hyperlinks zu den Downloadbereichen für die neuesten
Service Packs, neuesten Bulletins und sonstigen Ressourcen.
http://go.microsoft.com/fwlink/?LinkId=15425
TechNet-Ressourcensite.
http://go.microsoft.com/fwlink/?LinkId=15426
MSDN-Ressourcensite.
92
Whitepapers
http://go.microsoft.com/fwlink/?LinkId=15428
SQL Server Developer Center. Enthält die neuesten technischen Whitepapers und
Downloads.
http://go.microsoft.com/fwlink/?LinkId=16263
Dieses Whitepaper wurde bei der Veröffentlichung von SQL Server 2000 geschrieben.
Es bildet die Grundlage für Teile des vorliegenden Whitepapers.
http://go.microsoft.com/fwlink/?LinkId=15429
Eine Reihe von Hyperlinks zu Inhalten, bei denen es um SQL Server-Sicherheit geht.
93
Copyright
Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus
der Sicht der Microsoft Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft
auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine Verpflichtung
seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten
Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.
Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT SCHLIESST GEMÄSS
DER INFORMATIONEN IN DIESEM DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE
AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH GEREGELT, ABER ABDINGBAR.
Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu
halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze
darf ohne ausdrückliche Erlaubnis der Microsoft Corporation kein Teil dieses Dokuments
für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert
oder eingelesen werde, unabhängig davon, auf welche Art und Weise oder mit welchen
Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies
geschieht.
Es ist möglich, dass Microsoft Rechte an Patenten bzw. an angemeldeten Patenten, an
Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den
fachlichen Inhalt dieses Dokuments beziehen. Das Bereitstellen dieses Dokuments gibt
Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf
sonstiges geistiges Eigentum, es sei denn, dies wird ausdrücklich in den schriftlichen
Lizenzverträgen von Microsoft eingeräumt.
Die in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten,
Domänen, Personen, Orten, Ereignissen sowie E-Mail-Adressen und Logos sind frei
erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit tatsächlichen
Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen, E-MailAdressen und Logos ist rein zufällig.
 2003 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft, Active Directory, ActiveX, Microsoft Press, MSDN, Visual Basic, Visual C++,
Visual Studio, Win32, Windows und Windows NT sind entweder eingetragene Marken
oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Alle weiteren in diesem Dokument aufgeführten Firmen- und Produktnamen können
geschützte Marken ihrer jeweiligen Inhaber sein.
Herunterladen
Random flashcards
Erstellen Lernkarten