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 [email protected], 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.
