Implementieren von IT-Kontrollen mit SQL Server 2008

SQL Server 2008-Kompatibilitätshandbuch
Technischer Artikel zu SQL Server
Autor: JC Cannon, Denny Lee
Mitwirkende: Andy Roberts, Ayad Shammout
Technische Lektoren: Dan Jones, Craig Gick, Jack Richins, Raul Garcia, Devendra Tiwari,
Steven Gott, Al Comeau, Lara Rubbelke
Veröffentlicht: November 2008
Betrifft: SQL Server 2008
Zusammenfassung: Dieses Whitepaper bietet eine Übersicht über den Ansatz zum
Einhalten von Gesetzen und Richtlinien (Kompatibilität) bei der
Verwaltung der SQL Server-Datenbank. Im Whitepaper werden die
kompatibilitätsbezogenen Funktionen von SQL Server 2008 und ihre
Anwendung auf IT-Kontrollen beschrieben. Zudem enthält dieses
Whitepaper Tipps und Skripts für einen schnellen Einstieg in die
Entwicklung einer Kompatibilitätslösung.
Hinweis: Sie können die Beispieldateien für dieses Dokument herunterladen.
1
Copyright
Die Informationen in diesem Dokument stellen die zum Datum der Veröffentlichung aktuelle
Ansicht der Microsoft Corporation zu den erörterten Themen dar. Da Microsoft auf geänderte
Marktbedingungen reagieren muss, dürfen diese Informationen nicht als Verpflichtung von
Microsoft ausgelegt werden, und Microsoft kann nicht garantieren, dass alle Informationen in
dem Dokument nach dem Datum der Veröffentlichung noch genau zutreffen.
Dieses Whitepaper dient ausschließlich Informationszwecken. MICROSOFT ÜBERNIMMT
FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT KEINE GEWÄHRLEISTUNG, WEDER
AUSDRÜCKLICH, KONKLUDENT NOCH GESETZLICH.
Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu
halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf
kein Teil dieses Dokuments ohne ausdrückliche schriftliche Erlaubnis der Microsoft
Corporation für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem
gespeichert oder darin eingelesen werden, 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. Die Bereitstellung dieses Dokuments gewährt
Ihnen jedoch keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder
anderem geistigen Eigentum, es sei denn, dies wurde ausdrücklich durch einen schriftlichen
Lizenzvertrag mit der Microsoft Corporation vereinbart.
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änennamen, Personen, Orten, Ereignissen, E-MailAdressen und Logos ist rein zufällig.
© 2008 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft, Active Directory, ActiveX, BitLocker, Excel, Internet Explorer, PivotTable,
PowerShell, SQL Server, Vista, Visual Basic, Visual Studio, Windows, Windows Server und
Windows Vista sind Marken der Microsoft-Unternehmensgruppe.
Alle anderen Marken sind Eigentum ihrer jeweiligen Inhaber.
2
Inhalt
Einführung ............................................................................................................................. 7
Verwendung dieses Dokuments ............................................................................................. 7
Dokumentfokus .................................................................................................................. 7
Dokumentvoraussetzungen ................................................................................................ 7
Grundlegendes zur Kompatibilität .......................................................................................... 8
GRC-Elemente ................................................................................................................... 9
Risikomanagement ......................................................................................................... 9
Führung .........................................................................................................................10
Kompatibilität .................................................................................................................10
Ein GRC-Beispiel...............................................................................................................12
Risiko mindernde Kontrollen ..............................................................................................13
Key Performance Indicators (KPIs) [Analysis Services] .....................................................14
Zuordnen von Vorschriften zu einem Kernsatz von IT-Kontrollen ......................................14
Implementieren von IT-Kontrollen mit SQL Server 2008 .......................................................16
Sichern der Plattform ............................................................................................................17
Sichern von SQL Server 2008 ........................................................................................17
Verwalten der SQL Server 2008-Oberflächenkonfiguration ............................................18
Kontrollieren der Identität und Aufgabentrennung .................................................................20
Verwenden der Windows-Authentifizierung .......................................................................20
Erstellen von Anmeldenamen ............................................................................................22
Zuweisen von Benutzern zu Serverrollen ..........................................................................23
Erteilen von Datenbankzugriff ............................................................................................24
Zuweisen von Benutzern zu Datenbankrollen ....................................................................25
Verwalten von Berechtigungen ..........................................................................................26
Serverrollenberechtigungen ...........................................................................................26
Datenbankberechtigungen .............................................................................................27
Berechtigungen auf Spaltenebene .................................................................................28
Aufgabentrennung.................................................................................................................30
Einschränken der Verwendung der Rolle "sysadmin" ........................................................30
3
Deaktivieren des Administratorkontos (sa) .....................................................................30
Verwenden von signierten Prozeduren zum Agieren als Systemadministrator
(Deaktivieren aller sysadmin-Konten) .............................................................................31
Beim Setup definierte sysadmin-Konten ............................................................................31
Zuweisen der sysadmin-Rolle beim SQL Server 2008-Setup .........................................31
Zuweisung von Dienst-SIDs unter Windows Vista und Windows Server 2008................33
Verwenden der Gruppe "VORDEFINIERT\Administratoren" ..........................................33
Identitätsverwaltung mit Multi-Tier-Anwendungen..............................................................34
Verschlüsseln von Datenbankdaten ......................................................................................35
SQL Server-Datenbankverschlüsselung ............................................................................35
Auswählen eines Verschlüsselungsalgorithmus ................................................................35
Verwenden der transparenten Datenverschlüsselung ........................................................35
Sichern des privaten Schlüssels des Zertifikats..............................................................36
Rotieren von Zertifikaten oder Rotieren von Schlüsseln .................................................37
Überwachen des Schlüsselzugriffs ....................................................................................37
Überwachen des Verschlüsselungsflags für die Datenbank ...............................................38
Behandeln von spezifischen Szenarien .............................................................................38
Absichern gegen den Diebstahl eines Computers ..........................................................38
Verhindern des Zugriffs durch Systemadministratoren und Datenbankbesitzer ..............39
Schützen einer Spalte in einer Datenbanktabelle ...........................................................39
Überwachen sensibler Vorgänge ..........................................................................................40
Sammeln von Protokollen ..................................................................................................41
Übertragen von Protokollen ...............................................................................................41
Verwenden von Skripts und Tools zum Verwalten der Überwachung ................................41
Überwachen bestimmter Benutzer und Tabellen ...............................................................43
Überwachen bestimmter Benutzer .................................................................................43
Überwachen bestimmter Tabellen ..................................................................................44
Verfolgen des sysadmin- und db_owner-Zugriffs ...........................................................44
Zentralisieren von Protokollen ...........................................................................................44
Erstellen von Berichten aus Protokolldateien .....................................................................45
Übersicht – Serveraktionen ............................................................................................46
Trendanalyse der Serveraktionen ..................................................................................46
Ausführen eines Drillthroughs zu den Serveraktionsdetails ............................................47
4
Übersicht – Datenbankaktionen .....................................................................................48
Ausführen eines Drillthroughs zu den Datenbankaktionen .............................................48
Übersicht – DDL-Aktionen ..............................................................................................49
Ausführen eines Drillthroughs zu den DDL-Aktionen ......................................................49
Übersicht – DML-Aktionen .............................................................................................50
Ausführen eines Drillthroughs zu den DML-Aktionen .....................................................50
Verwenden der richtlinienbasierten Verwaltung zum Definieren, Bereitstellen und Überprüfen
von Richtlinien.......................................................................................................................51
Struktur der richtlinienbasierten Verwaltung.......................................................................51
Richtlinienbasierte Verwaltung – Beispiel ..........................................................................52
Überwachen der Richtlinien der richtlinienbasierten Verwaltung ........................................52
Verwenden der richtlinienbasierten Verwaltung zur Einhaltung gesetzlicher Bestimmungen
..........................................................................................................................................52
Erstellen eines Plans......................................................................................................53
Welche Richtlinien möchten Sie basierend auf dem Plan erstellen? ..............................54
Bestimmen des Ausführungsmodus für Ihre Richtlinien .................................................55
Verwenden der richtlinienbasierten Verwaltung zum Implementieren von KPIs und KRIs
......................................................................................................................................57
Verwenden der richtlinienbasierten Verwaltung zum Überprüfen der
Überwachungskonfiguration ...........................................................................................58
Verwenden der richtlinienbasierten Verwaltung zum Überprüfen der
Verschlüsselungskonfiguration .......................................................................................58
Bereitstellen von Richtlinien ...........................................................................................59
Erstellen von Berichten zur richtlinienbasierten Verwaltung ...........................................61
Nützliche Skripts und Tipps ...................................................................................................64
Programmierschnittstellen zu SQL Server .........................................................................64
SMO ..............................................................................................................................64
Transact-SQL.................................................................................................................64
Windows PowerShell .....................................................................................................64
VBScript ............................................................................................................................65
Windows Data Access Components ..................................................................................65
Sicherstellen der Sicherheitseinstellungen ("Server Security Policy.xml") .............................66
Verwalten der Aufgabentrennung ("SOD Policy.xml") ...........................................................68
Verwenden von Skripts in Bedingungen ............................................................................69
5
Deaktivieren aller sysadmin-Konten ("ManageSA.sql") ......................................................70
Überprüfen des sa-Kontos ("ValidateSA.sql") ....................................................................71
Überprüfen der sysadmin-Rollenmitgliedschaft ("ValidateSysadmins.sql") ........................72
Erzwingen der Rollentrennung ("SOD Policy.xml") ............................................................72
Überwachen von Serverrollen ("ValidateServerRoles.sql").............................................73
Auflisten von Benutzern in mehreren Rollen ("ValidateServerRoles.sql") .......................74
Überwachen von Datenbankrollen ("ValidateDatabaseRoles.sql") .................................75
Verwalten von Verschlüsselungsschlüsseln ..........................................................................76
Überwachen des Zugriffs auf Verschlüsselungsschlüssel ("AuditCryptoActions.sql") ........76
Anzeigen von Zertifikaten und Schlüsseln ("ViewKeys.sql")...............................................77
Wechseln von Zertifikaten ("RotateCerts.sql") ...................................................................78
Sichern des privaten Zertifikatschlüssels ("BackupCerts.sql")............................................79
Sicherstellen der Zertifikatrotation und -sicherung ("CertRotationPolicy.xml") ....................80
Verwalten der Überwachung .................................................................................................81
Übertragen von SQL Server Audit-Protokollen an eine Tabelle ("StoreAuditLogs.sql") ......81
Verwenden von SSIS zum Verschieben von Protokollen in eine Datenbanktabelle
("LoadLogsPackage.dtsx") ................................................................................................84
Zugreifen auf SQL Server Audit-Ereignisse mithilfe von Excel ("AuditReport.xlsx") ...........87
Abrufen einer IP-Adresse aus einem Überwachungsprotokoll ...........................................89
Überwachungsprojekt ........................................................................................................90
SQL DB-Protokollordner (z. B. "H:\sqllog") ............................................................................91
Verwalten der Richtlinien der richtlinienbasierten Verwaltung ...............................................95
Erstellen einer Richtlinie mithilfe von PowerShell...............................................................95
Bereitstellen von Richtlinien der richtlinienbasierten Verwaltung mit PowerShell
("DeployPBMPolicies.ps1") ................................................................................................95
Übertragen von Richtlinienzustandsprüfungen in eine Datenbanktabelle ...........................97
Zusammenfassung..............................................................................................................101
6
Einführung
Weltweit werden Organisationen mit Vorschriften und Verordnungen überschwemmt. Zudem
besteht in Organisationen die dringende Notwendigkeit zur besseren Verwaltung der ITSysteme, um den effizienten Betrieb und die Sicherheit dieser Systeme zu gewährleisten.
Microsoft wird häufig gebeten, Anleitungen und Technologie bereitzustellen, um
Organisationen bei ihren Kompatibilitätsanstrengungen zu unterstützen. Das Whitepaper
"SQL Server 2008-Kompatibilitätshandbuch" wurde verfasst, um Organisationen und
Einzelpersonen zu veranschaulichen, wie sie die Funktionen der Microsoft® SQL Server®
2008-Datenbanksoftware verwenden können, um ihre Kompatibilitätsanforderungen zu
erfüllen. Dieses Whitepaper dient als Begleitdokument für das SQL Server 2008Kompatibilitäts-SDK (Software Development Kit), das Beispielcode und Anleitungen
bereitstellt, um die SQL Server 2008-Kompatibilitätsfunktionen besser zu verstehen und bei
der Lösungsentwicklung gezielt einzusetzen.
Verwendung dieses Dokuments
Dieses Dokument stellt Kompatibilitätsleitlinien für verschiedene Ebenen bereit. Im ersten Teil
dieses Whitepapers werden allgemeine Kompatibilitätskonzepte erläutert und beschrieben,
wo IT-Kontrollen gezielt zur Risikominimierung eingesetzt werden können und wie
Technologie zum Implementieren dieser Kontrollen verwendet wird. Im zweiten Teil werden
bestimmte Kompatibilitätsszenarien behandelt, beispielsweise Sichern der Plattform und
Schützen der Daten. Der dritte Teil dieses Whitepapers enthält Beispielcode, Beispiele und
Tipps, die verwendet werden können, um das Erstellen benutzerdefinierter
kompatibilitätsbezogener Lösungen auf Basis von SQL Server 2008 zu beschleunigen. Das
SDK kann auch für sich allein zur Implementierung von IT-Kontrollen verwendet werden.
Informationen hierzu können Sie der Infodatei entnehmen, die mit dem SDK geliefert wird.
Dokumentfokus
Dieses Dokument bietet allgemeine Hilfestellung bei der Verwendung von SQL Server 2008
zum Erfüllen der Kompatibilitätsanforderungen. Außerdem wird auf allgemeine
Kompatibilitätsleitlinien des Solution Accelerator-Teams von Microsoft und auf Anleitungen
zum Wahren der Sicherheit im Betriebssystem Windows Server® hingewiesen.
Dokumentvoraussetzungen
Die Leser dieses Dokuments sollten über grundlegende SQL Server-Kenntnisse verfügen,
um die hier vorgestellten Konzepte besser verstehen zu können. Das Compliance Hands-onLab im SDK vertieft das Verständnis der kompatibilitätsbezogenen Funktionen von
SQL Server 2008.
7
Grundlegendes zur Kompatibilität
Die Kompatibilität zwecks Einhaltung gesetzlicher Bestimmungen betrifft viele Organisationen
aller Größen. Die Kompatibilität wird wesentlich durch gesetzliche Bestimmungen wie den
Sarbanes-Oxley Act (SOX) und den Payment Card Industry Data Security Standard (PCIDSS) vorangetrieben. Aber auch Unternehmen, die noch nicht von gesetzlichen
Bestimmungen betroffen sind, müssen eigene organisatorische Richtlinien festlegen, um
Kompatibilität zu erreichen. Häufig kommt es jedoch zu Problemen, wenn in Unternehmen
ein Kompatibilitätsprogramm initiiert wird. Oftmals wissen Unternehmen nicht, wo sie den
Anfang machen sollen oder wie das Kompatibilitätsprogramm mithilfe von Technologie,
insbesondere SQL Server, automatisiert werden kann.
Die Kompatibilität ist der letzte Schritt eines dreistufigen Prozesses, der als GRC bezeichnet
wird. Dies ist die Kurzform von "Governance, Risk Management & Compliance" (Führung,
Risikomanagement, Kompatibilität). Organisationen, die ein GRC-Programm entwickeln
möchten, sollten einen Kompatibilitätsberater um Unterstützung bitten. Die Analysten des
Marktforschungsunternehmens Forrester haben die GRC-Branche unter die Lupe genommen
und einen Bericht über die GRC-Beratungsfirmen erstellt. Dieser Bericht enthält eine Liste
der Unternehmen, die als Berater in Betracht kommen. Im nächsten Abschnitt wird der Begriff
GRC näher erläutert. Zudem erfahren Sie, wie SQL Server in ein GRC-Programm integriert
werden kann.
8
GRC-Elemente
Mit GRC können Unternehmen Risiken identifizieren, diese Risiken mildern und sicherstellen,
dass die Risiken im Laufe der Zeit minimiert werden. Abbildung 1 bietet eine Übersicht über
diese Konzepte.
Abbildung 1: GRC-Elemente
Assessment
Prioritization
Action plan
Policies
Training
Practices
Monitoring
Validation
Remediation
Risikomanagement
Risikomanagement ist ein Programm zum Minimieren oder Ausschalten von Risiken.
Zunächst wird jeder Bereich einer Organisation analysiert, um festzustellen, wo
möglicherweise Risiken bestehen. Für jede Abteilung, beispielsweise Sicherheit, operativer
Ablauf, Vertrieb und Entwicklung, kann eine eigene Risikoeinschätzung durchgeführt werden.
Zunächst einmal sollten Unternehmen mit einem Kompatibilitätsprüfer zusammenarbeiten,
um für ihr Unternehmen eine Risikoeinschätzung durchzuführen. Nachdem die Risiken
ermittelt wurden, sollte diesen eine Priorität zugewiesen werden. Basierend auf den
Prioritäten sollte dann ein Aktionsplan aufgestellt und umgesetzt werden. Der Plan sollte
Aufschluss darüber geben, wie jedes Risiko behandelt werden sollte: Sollte das Risiko
ignoriert, abgemildert oder vermieden werden?
9
Strategien zum Bekämpfen der Risiken, die mit dem Speichern von Kreditkartendaten
verbunden sind
 Ignorieren – Schutz der Kreditkartendaten nicht verbessern.
 Abmildern – Schutz der Kreditkartendaten verbessern.
 Vermeiden – Keine Kreditkartendaten sammeln.
Risiken, für die eine Strategie zur Abmilderung verfolgt wird, sollten priorisiert werden. Zudem
sollte ein Aktionsplan aufgestellt und umgesetzt werden, um jedes Risiko abzumildern. Da die
Risiken in jeder Abteilung identifiziert und priorisiert werden, muss sichergestellt sein, dass
diese Risiken mit den organisatorischen Risiken in Einklang gebracht werden. Die Prioritäten
auf Abteilungsebene dürfen keine Prioritäten auf Organisationsebene außer Kraft setzen.
Führung
Die Führung stellt die Aktionen dar, die ausgeführt werden müssen, um die bei der
Risikoeinschätzung ermittelten Risiken zu bekämpfen. Bei diesem Schritt werden Richtlinien,
IT-Kontrollen, Praktiken, Systeme und Schulungen eingesetzt, um Risiken abzumildern. Die
Risiko mindernden Kontrollen, die unter erörtert werden, können in den Fällen verwendet
werden, wo die strikte Einhaltung von Richtlinien nicht möglich ist oder Risiken nicht
verhindert werden können. Mit SQL Server kann beispielsweise nicht verhindert werden,
dass der Systemadministrator sensible Daten anzeigt. Das Konto sysadmin kann jedoch
deaktiviert und alle Zugriffe vom Systemadministrator können überwacht werden, um
sicherzustellen, dass kein zweckwidriger Zugriff auf vertrauliche Daten erfolgt.
Strategien zum Anwenden von Führungsrichtlinien zum Schützen sensibler Daten
 Erstellen von Richtlinien zur ordnungsgemäßen Behandlung sensibler Daten.
 Schulen der Mitarbeiter in der Anwendung von Datenbehandlungsrichtlinien.
 Anwenden von Richtlinien auf Systeme, in denen sensible Daten gespeichert werden.
 Überwachen und Protokollieren der Behandlung sensibler Daten, um die Einhaltung der
Richtlinien sicherzustellen.
Kompatibilität
Um Kompatibilität sicherzustellen, wird überprüft, ob die identifizierten Risiken minimiert
werden. Im Folgenden wird anhand von Beispielen veranschaulicht, wie Risiken überprüft
werden können. 1. Wurde für jedes identifizierte Risiko eine Richtlinie definiert, um das Risiko
zu verhindern oder zu minimieren? 2. Wurden die entsprechenden Personen über die
Richtlinien informiert? 3. Wurden die Richtlinien über Prozesse, Software oder IT-Kontrollen
implementiert? 4. Werden die Richtlinien überwacht, um deren Einhaltung sicherzustellen
und bei einem Verstoß gegen die Richtlinien schnell Maßnahmen ergreifen zu können? Um
echte Kompatibilität zu erzielen, muss jeder Schritt durch einen Prüfer verifiziert werden
können. Hierzu können Überwachungsberichte, Ereignisprotokolle, Videobänder und der
Versionsverlauf hilfreich sein.
10
Strategien zum Überprüfen der Kompatibilität
 Aufzeigen, dass Richtlinien zum Behandeln der identifizierten Risiken entwickelt wurden.
 Aufzeigen, dass erforderliche Richtlinien implementiert wurden.
 Nachweisen, dass Richtlinien während des Erzwingungszeitraums umgesetzt und befolgt
wurden.
Die Einhaltung organisatorischer Richtlinien und Vorschriften (Kompatibilität) wird
normalerweise durch interne Überwachungsteams und professionelle externe Betriebsprüfer
sichergestellt. Stellen Sie sicher, dass die vorhandenen Systeme den Prüfern die
Kompatibilitätsüberprüfung erleichtern. Durch Zentralisierung der Überwachungssysteme
kann die Effizienz der Kompatibilitätsüberprüfung verbessert werden. Durch diese Techniken
werden die Kosten der Überprüfung reduziert, und die Unterbrechung täglicher Abläufe wird
minimiert.
11
Ein GRC-Beispiel
Als Nächstes wird unter Verwendung der im vorherigen Abschnitt beschriebenen GRCRichtlinien veranschaulicht, wie Sie diese Richtlinien anwenden können, um die
Notwendigkeit einer Zugangskontrolle für Gebäude einzuschätzen, so wie in Abbildung 2
gezeigt.
Abbildung 2: GRC-Beispiel
Loss from theft,
vandalism and
injury to personnel
Locked door, guard,
camera, badges and
policies
Review entrance
and guard logs,
tapes and news
reports
Risikomanagement
Bei der Risikoeinschätzung des Gebäudes stellen Sie möglicherweise fest, dass eine
Sicherheitsrichtlinie notwendig ist, um das Risiko eines Diebstahls von Computern,
Büroausstattung, persönlichen Gegenständen und geistigem Eigentum zu reduzieren.
Mitarbeiter können auch dem Risiko eines Angriffs oder Raubüberfalls ausgesetzt sein. Das
Gebäude selbst könnte durch Vandalismus beschädigt werden. Jedes dieser Risiken könnte
sich negativ auf den Nettogewinn einer Organisation auswirken, falls sie tatsächlich eintreten.
Führung
Nach Abschluss der Risikoeinschätzung werden eine Reihe von Richtlinien und Prozessen
definiert und zwecks Implementierung priorisiert. Für die Zutrittskontrolle zu Gebäuden und
den Schutz der Eingänge werden Richtlinien erstellt. Die Mitarbeiter werden in Schulungen
mit diesen Richtlinien vertraut gemacht. An den Türen werden elektronische Sperren
angebracht, damit diese nur mit den entsprechenden Mitarbeiterausweisen geöffnet werden
können. Den Mitarbeitern werden Ausweise ausgehändigt, die ihren Zutritt auf die Gebäude
beschränken, die sie im Rahmen ihrer Tätigkeit aufsuchen müssen. An gefährdeten
Standorten werden Kameras und Wachposten platziert, um Richtlinien besser durchsetzen
zu können.
12
Kompatibilität
Um gegenüber einem Prüfer nachweisen zu können, dass die Richtlinien für den
Gebäudezugang erfüllt wurden, können die Eingangsprotokolle vorgelegt werden. Anhand
dieser Protokolle kann nachgewiesen werden, dass die Daten ordnungsgemäß in den
Protokollen erfasst wurden und die in den Protokollen aufgeführten Mitarbeiter sich legitim im
Gebäude aufgehalten haben. Die Bänder der Kameras können eingesehen werden, um
sicherzustellen, dass Mitarbeiter die Zugangsrichtlinien befolgt haben und der Zugang von
Nicht-Unternehmensangehörigen zum Gebäude verhindert wurde. Zudem könnte ein Auditor
die Wachposten befragen und die aktuellen Berichte lesen, um zu prüfen, ob es in Bezug auf
das Gebäude Vorfälle gegeben hat.
Risiko mindernde Kontrollen
Mit Risiko mindernden Kontrollen, die auch als Kompensationskontrollen bezeichnet werden,
können die Risiken einer Kontrolle, die nicht hundertprozentig erzwungen werden kann,
verringert werden. In dem oben geschilderten GRC-Beispiel wird die Kamera als Kontrolle zur
Risikominimierung eingesetzt, um zu sehen, ob Einzelpersonen sich ohne Mitarbeiterausweis
Zugang zum Gebäude verschaffen. Denn mit einer elektronischen Sperre an Türen kann eine
Einzelperson zwar gezwungen werden, sich mit ihrem Mitarbeiterausweis Zugang zu
Räumen zu verschaffen, aber sie hindert keinen daran, durch die Tür zu treten, nachdem
eine andere Person die Tür geöffnet hat.
Die Überwachung wird in Computersystemen häufig als Risiko mindernde Kontrolle
verwendet, um sensible Vorgänge zu überwachen, die nicht unterbunden werden können.
Beispielsweise haben Systemadministratoren häufig Zugang zu allen Systemdaten, obwohl
sie nicht immer autorisiert sind, die Daten anzuzeigen. Durch Überwachung der von
Systemadministratoren durchgeführten Aktionen kann festgestellt werden, ob die
Zugriffsrichtlinien befolgt wurden.
Mit SQL Server 2008 werden zwei Funktionen eingeführt, die zum Entwickeln von Risiko
mindernden Kontrollen verwendet werden können. Mit SQL Server Audit können sensible
Vorgänge und privilegierte Konten, z. B. das sa-Konto, überwacht werden. Mit der
richtlinienbasierten Verwaltung (Policy-Based Management, PBM) kann sichergestellt
werden, dass kritische Konfigurationseinstellungen auf den richtigen Wert festgelegt sind und
dieser Wert nicht geändert wird. Während es im jeweiligen Fall zwar nicht immer möglich ist,
bestimmte Vorgänge, Konten oder Konfigurationseinstellungen zu blockieren, können aber
die von ihnen dargestellten Risiken durch die Verwendung dieser beiden neuen Funktionen
minimiert werden.
13
Key Performance Indicators (KPIs) [Analysis Services]
Bei Key Performance Indicators (KPIs) handelt es sich um Einstellungen oder Kennzahlen,
aus denen abgeleitet werden kann, ob die Leistung des Unternehmens, der Abteilung oder
der Systeme den Erwartungen entspricht. Die Werte oder Bereiche für KPIs werden
normalerweise durch die Entscheidungsträger für betriebswirtschaftliche Belange festgelegt.
Einige IT-Kontrollen können als KPIs verwendet werden. Beispielsweise können
Datenbankabfrageleistung, CPU-Auslastung, verfügbarer Speicher und verfügbare
Verbindungen alle als Indikatoren eines fehlerfreien Systems gemessen werden.
Risikokennzahlen (Key Risk Indicators, KRIs) sind Einstellungen oder Messungen, die darauf
hinweisen können, dass Unternehmen, Abteilungen oder Systeme einem Risiko ausgesetzt
sind. Die Werte oder Bereiche für KRIs werden normalerweise durch die Entscheidungsträger
für technische Belange festgelegt. Zum Implementieren von IT-Kontrollen werden häufig ITKontrollen verwendet. Beispiele für KRIs sind Sicherheitspatches, Aktivierung der
Verschlüsselung, Anzahl der Personen mit Administratorrolle und Häufigkeit von
Sicherungen.
Informationen zum Verwenden der richtlinienbasierten Verwaltung zum Implementieren von
KPIs und KRIs finden Sie unter Verwenden der richtlinienbasierten Verwaltung zum
Implementieren von KPIs und KRIs weiter unten in diesem Dokument.
Zuordnen von Vorschriften zu einem Kernsatz von IT-Kontrollen
Die Definition von Richtlinien zum Einhalten von Vorschriften führt oft zur Entwicklung von ITKontrollen, die zum Implementieren der Richtlinien dienen. Für eine Richtlinie, die den Zugriff
auf Kreditkartennummern einschränkt, sind möglicherweise IT-Kontrollen für strenge
Authentifizierung, Kennwortrichtlinien und die Anwendung einer Verschlüsselung erforderlich.
Während einige Kontrollen durch Geschäftsprozesse implementiert werden, werden viele
Kontrollen mithilfe von Technologie implementiert.
14
In Abbildung 3 finden Sie ein Beispiel der IT-Kontrollen, die ggf. für einige der geläufigeren
Bestimmungen und Vorschriften in den USA erforderlich sind. Das Planungshandbuch für die
IT-Kompatibilität von Microsoft bietet Hilfestellung beim Zuordnen von Bestimmungen zu
einem Kernsatz von IT-Kontrollen und enthält Informationen über die Microsoft-Technologie,
die Sie bei der Erstellung dieser Kontrolle unterstützt.
GLBA
HIPAA
PCI
IT Control
SOX
Abbildung 3: SOX: Sarbanes Oxley Act. PCI: Payment Card Industry, HIPAA: Health
Information Portability and Accountability Act, GLBA: Graham Leach Bliley Act
ID Management
Separation of Duties
Encryption
Key Management
Auditing
Control Testing
Policy Management
Die nächsten Abschnitte dieses Whitepapers sind nach den genannten IT-Kontrollen
aufgegliedert.
Symbol
Beschreibung
Identitätsverwaltung
Aufgabentrennung
Verschlüsselung
Schlüsselverwaltung
Überwachung
Richtlinienbasierte Verwaltung
15
Implementieren von IT-Kontrollen mit SQL Server 2008
SQL Server 2008 umfasst mehrere Funktionen, die das Implementieren datenbankbezogener
IT-Kontrollen ermöglichen. Darüber hinaus können einige IT-Kontrollen mithilfe der Plattform
implementiert werden, auf der SQL Server installiert ist. Es ist wichtig, dass das
Kompatibilitätsteam in Ihrer Organisation die zu implementierenden IT-Kontrollen definiert
und festlegt, welche davon auf die Datenbank angewendet werden. In den folgenden
Abschnitten werden die Funktionen erläutert, die zum Implementieren von IT-Kontrollen
verwendet werden können. Folgende Bereiche werden behandelt:

Sichern der Plattform
In diesem Abschnitt werden die Maßnahmen beschrieben, die vor der Softwareinstallation
oder Datenbankkonfiguration ergriffen werden müssen. Mit diesen Maßnahmen können
die Risiken für das Betriebssystem und die Datenbankanwendung minimiert werden.

Kontrollieren der Identität und Aufgabentrennung
Dieser Abschnitt enthält Empfehlungen zum Definieren von Datenbankprinzipalen und
Erzwingen der Aufgabentrennung.

Verschlüsseln von Datenbankdaten
In diesem Abschnitt werden die Verschlüsselungsfunktionen von SQL Server 2008
beschrieben. Zudem werden Aspekte der Verschlüsselung erörtert, die häufig außer Acht
gelassen werden.

Überprüfen sensibler Informationen
In diesem Abschnitt wird die neue Überwachungsfunktion von SQL Server 2008
vorgestellt und erläutert, wie diese für die zentralisierte Protokollerfassung und
Berichterstattung verwendet werden können.

Verwenden der richtlinienbasierten Verwaltung zum Definieren, Bereitstellen und
Überprüfen von Richtlinien
In diesem Abschnitt wird die SQL Server 2008-Funktion zur richtlinienbasierten
Verwaltung vorgestellt und erläutert, wie diese zum Verwalten mehrerer Datenbanken
mithilfe einer einzelnen Richtlinie verwendet werden kann.
16
Sichern der Plattform
Bevor Sie mithilfe von SQL Server Richtlinien anwenden oder IT-Kontrollen implementieren,
sollten Sie sicherstellen, dass Sie über eine sichere Grundlage für die Installation von
SQL Server verfügen:





Verwenden Sie das neueste Betriebssystem mit aktuellen Service Packs.
Installieren Sie die neuesten Sicherheitspatches.
Installieren Sie AntiMalware-Software.
Minimieren Sie die Angriffsfläche des Betriebssystems:
o Begrenzen Sie die ausgeführten Dienste.
o Installieren Sie nur Software, die zum Unterstützen der Serverrolle erforderlich ist.
o Deaktivieren Sie unnötige Ports.
o Konfigurieren Sie die Firewall.
Beschränken Sie die Benutzer, die Zugriff auf den Server haben, und die Rollen der
Benutzer.
Wenn Sie an weiteren Informationen interessiert sind, einschließlich Anleitungen zum Sichern
von Windows Server 2008, laden Sie das Windows Server 2008-Sicherheitshandbuch
herunter.
Sichern von SQL Server 2008
Nachdem Sie die Plattform gesichert haben, sollten Sie zunächst SQL Server installieren und
sichern, bevor die Richtlinien angewendet und IT-Kontrollen entwickelt werden. Weitere
Informationen, einschließlich Richtlinien zum Sichern von SQL Server 2008, finden Sie im
Whitepaper Sichern von SQL Server.
17
Verwalten der SQL Server 2008-Oberflächenkonfiguration
Ab SQL Server 2008 gibt es das Tool zur Oberflächenkonfiguration nicht mehr. Die
Funktionen des Tools zur Oberflächenkonfiguration, die das Verhalten von SQL Server
steuern, wurden ersetzt und durch die Funktionen für die richtlinienbasierte Verwaltung
erheblich erweitert. Abbildung 4 zeigt das Bild mit den Oberflächenkonfigurationsfacets der
richtlinienbasierten Verwaltung. Es gibt sogar Oberflächenkonfigurationsfacets für Analysis
Services und Reporting Services. Weitere Informationen zum Verwalten der
Oberflächenkonfiguration finden Sie unter Grundlegendes zur Oberflächenkonfiguration.
Abbildung 4: Oberflächenkonfigurationsfacet der richtlinienbasierten Verwaltung
18
Die in Abbildung 4 gezeigten Konnektivitätsverwaltungsfunktionen des Tools zur
Oberflächenkonfiguration sind verfügbar, wenn Sie den SQL Server-Konfigurations-Manager
verwenden. Abbildung 5 zeigt die SQL Server-Konfigurations-Manager-Knoten zum
Konfigurieren von Diensten, Netzwerk und Protokollen.
Abbildung 5: SQL Server-Konfigurations-Manager
Die SQL Server-Konfiguration kann mithilfe der gespeicherten Prozedur sp_configure
verwaltet werden. Mit dieser gespeicherten Prozedur können Sie beispielsweise folgende
Einstellungen verwalten:





Sicherungskomprimierung
Common Criteria-Aktivierung
Common Language Runtime (CLR)-Aktivierung
Remotezugriff
Benutzerverbindungen
19
Kontrollieren der Identität und Aufgabentrennung
Der erste Schritt zum Einschränken des Zugriffs auf die Daten in der Datenbank besteht
darin, die Personen zu beschränken, die auf die Datenbank zugreifen können. SQL Server
2008 bietet verschiedene Möglichkeiten, um zu verwalten, welche Benutzer auf eine
Datenbank zugreifen können und welche Vorgänge von den Datenbankbenutzern ausgeführt
werden können. Abbildung 6 zeigt die verschiedenen Ebenen der Identitätsverwaltung, die
von SQL Server 2008 bereitgestellt werden. Außerdem können Benutzern besondere
Berechtigungen erteilt oder verweigert werden. Bevor Sie Benutzern Zugriff erteilen, sollten
Sie planen, wer Datenbankzugriff auf welcher Ebene und für welche Vorgänge erhalten
sollte. Beachten Sie dann die folgenden Richtlinien:





Verwenden Sie die Windows-Authentifizierung für alle Datenbankanmeldungen.
Gewähren Sie Benutzern Zugriff auf Datenbanken im erforderlichen Umfang.
Erteilen Sie Benutzern erforderliche Berechtigungen, oder verweigern Sie
Berechtigungen.
Weisen Sie Benutzern die Rollen zu, die sie zum Ausüben ihrer Tätigkeit benötigen.
Verwenden Sie die richtlinienbasierte Verwaltung zum Überprüfen der Identitätsrichtlinien.
Abbildung 6: Entstehung der Datenbankbenutzerdefinition
Verwenden der Windows-Authentifizierung
Die Identitätsverwaltung ist nach dem Überprüfen der Plattformsicherheit der wichtigste
Schritt beim Schützen der Datenbank. Der erste Teil der Identitätsverwaltung besteht darin,
die Möglichkeit zu schaffen, alle auf die Datenbank zugreifenden Personen zu identifizieren.
20
Mithilfe des Windows-Authentifizierungsmodus wird die SQL Server-Identität mit einem
Active Directory®-Konto verknüpft, um eine starke Identität bereitzustellen. Die Integration
der Zugriffverwaltung in Active Directory-Domänendienste (AD DS) bietet mehrere Vorteile
für SQL Server:



Konsistente Identität auf allen Servern
Zentralisierte Erzwingung von Kennwortrichtlinien
Zentralisierte Mittel zum Deaktivieren von Konten
Informationen über die Kontobereitstellung finden Sie unter Konfiguration des
Datenbankmoduls – Kontobereitstellung.
Der Windows-Authentifizierungsmodus wird in SQL Server Management Studio über die Seite
Sicherheit im Dialogfeld Servereigenschaften aktiviert, so wie unter Abbildung 7 gezeigt.
Abbildung 7: Sicherheitseigenschaften für Server
21
Mit der richtlinienbasierten Verwaltung kann eine Richtlinie erstellt werden, die sicherstellt,
dass Sicherheitseinstellungen festgelegt sind und nicht geändert wurden. Verwenden Sie das
Facet "Serversicherheit" der richtlinienbasierten Verwaltung, um für diese Einstellungen eine
Richtlinie zu erstellen. Weitere Informationen zum Verwenden der richtlinienbasierten
Verwaltung zum Überprüfen von Einstellungen finden Sie unter Verwenden der
richtlinienbasierten Verwaltung zum Definieren, Bereitstellen und Überprüfen von Richtlinien.
Erstellen von Anmeldenamen
Für den Zugriff auf eine Datenbank muss einem Benutzer zuerst ein Anmeldename
zugewiesen werden. Ein Anmeldename kann einem Benutzer mit einem Windows®-Konto
oder einer Windows-Sicherheitsgruppe zugewiesen werden, zu der ein Benutzer gehört.
Informationen zum Erstellen von Anmeldenamen finden Sie unter Vorgehensweise: Erstellen
einer SQL Server-Anmeldung. Das Verwenden einzelner Benutzerkonten anstelle von
Sicherheitsgruppen bietet mehr Kontrolle über die Anmeldungen, da WindowsAdministratoren ohne Wissen der Datenbankadministratoren der Benutzergruppe neue
Benutzer hinzufügen könnten. Allerdings ist Verwaltungsaufwand bei Sicherheitsgruppen
geringer. Unten sehen Sie ein Beispiel eines Skripts zum Erstellen eines Anmeldenamens
aus einem Windows-Konto.
CREATE LOGIN [SQLVM03-18158EA\Pat] FROM WINDOWS
22
In Abbildung 8 wird das Dialogfeld Anmeldung - Neu angezeigt, das zum Erstellen eines
neuen Anmeldenamens für eine Datenbank verwendet werden kann. Sie können auf das
Dialogfeld zugreifen, indem Sie mit der rechten Maustaste auf den Ordner "Anmeldungen"
klicken und dann auf Neue Anmeldung klicken.
Abbildung 8: Dialogfeld Anmeldung - Neu
Zuweisen von Benutzern zu Serverrollen
Die in SQL Server definierten Anmeldenamen sollten einer entsprechenden Serverrolle in
SQL Server zugewiesen werden. Indem Anmeldenamen einer anderen Rolle als sysadmin
zugewiesen werden, kann ihr Zugriff auf eine bestimmte Gruppe von Servervorgängen
beschränkt werden. Wenn ein Anmeldename beispielsweise der Rolle dbcreator zugewiesen
wird, werden hierdurch Berechtigungen zum Erstellen, Ändern, Löschen und
Wiederherstellen von Datenbanken erteilt. Benutzer mit dieser Rolle können jedoch keine
anderen Vorgänge ausführen. Unter Rollen auf Serverebene finden Sie eine Liste fester
Datenbankrollen und der Vorgänge, die Benutzer mit dieser Rolle ausführen können. Im
folgenden Beispiel wird ein Skript dargestellt, mit dem ein Benutzer einer Serverrolle
zugewiesen wird.
sp_addsrvrolemember N'SQLVM03-18158EA\Pat', N'dbcreator'
23
Die Eigenschaftenseite in Abbildung 9 kann verwendet werden, um einem Anmeldenamen
Serverrollen zuzuweisen. Sie können auf die Eigenschaften zugreifen, indem Sie auf
Eigenschaften und dann auf die Registerkarte Serverrollen klicken.
Abbildung 9: Serverrollen der Serveranmeldung
Erteilen von Datenbankzugriff
Nachdem ein Anmeldename erstellt wurde, muss ihm noch Zugriff auf eine Datenbank erteilt
werden, bevor auf die Daten zugegriffen werden kann. Es muss sichergestellt werden, dass
nur berechtigten Personen Zugriff auf eine Datenbank erteilt wird. Und wenn das erledigt ist,
sollte der Typ des erteilten Zugriffs mit Sorgfalt festgelegt werden. Weitere Informationen zum
Gewähren von Datenbankzugriff für Anmeldenamen finden Sie unter Vorgehensweise:
Erstellen eines Datenbankbenutzers. Im folgenden Beispiel wird ein Skript dargestellt, mit
dem einem Anmeldenamen Zugriff auf die Datenbank "Test2" erteilt wird.
USE Test1
CREATE USER [Pat] FOR LOGIN [SQLVM03-18158EA\Pat]
24
Das Dialogfeld Datenbankbenutzer - Neu in Abbildung 10 kann verwendet werden, um
einem Anmeldenamen Zugriff auf eine Datenbank zu erteilen. Das Dialogfeld kann auch
verwendet werden, um Benutzer einem Schema und Datenbankrollen zuzuweisen. Sie
können auf das Dialogfeld zugreifen, indem Sie mit der rechten Maustaste auf den Ordner
Benutzer klicken und dann auf Neuer Benutzer klicken.
Abbildung 10: Dialogfeld Datenbankbenutzer - Neu
Zuweisen von Benutzern zu Datenbankrollen
Benutzer, denen Zugriff auf eine Datenbank in SQL Server erteilt wurde, sollten einer
entsprechenden Datenbankrolle zugewiesen werden. Indem Benutzer einer anderen Rolle
als db_owner zugewiesen werden, kann ihr Zugriff auf eine bestimmte Gruppe von
Datenbankvorgängen beschränkt werden. Wenn ein Benutzer beispielsweise der Rolle
db_datareader zugewiesen wird, ist er berechtigt, Daten aus allen Datenbanktabellen zu
lesen. Benutzer mit dieser Rolle können jedoch keine anderen Vorgänge ausführen. Unter
Rollen auf Datenbankebene finden Sie eine Liste fester Datenbankrollen und die Vorgänge,
die Benutzer mit dieser Rolle ausführen können. Das folgende Beispiel zeigt ein Skript, mit
25
dem einem Benutzer Datenbankrollen zugewiesen werden, um ihm die Berechtigung zum
Lesen und Schreiben von Datenbankdaten zu erteilen.
sp_addrolemember N'db_datareader', N'Pat'
sp_addrolemember N'db_datawriter', N'Pat'
Datenbankrollen können auch bei der Benutzererstellung über das Dialogfeld
Datenbankbenutzer - Neu zugewiesen werden, so wie im Abschnitt Erteilen von
Datenbankzugriff beschrieben.
Verwalten von Berechtigungen
Berechtigungen sind Rechte oder Vorgänge, die Datenbankbenutzern und Anmeldenamen
gewährt oder verweigert werden. Wenn ein Anmeldename oder Benutzer einer Rolle
zugewiesen wird, erbt der Anmeldename oder Benutzer den Berechtigungssatz, der der Rolle
zugeordnet ist. Alternativ können den Benutzern und Anmeldenamen auch separat
Berechtigungen erteilt werden. Weitere Informationen, einschließlich einer Liste von
Berechtigungen, finden Sie unter Berechtigungen (Datenbankmodul).
Berechtigungen können verwendet werden, um Benutzern präzise Rechte zuzuweisen und
um die Rechte zu beschränken, die sie normalerweise aufgrund ihrer Rollenmitgliedschaft
erben. Beispielsweise kann einem Benutzer, der den Datenbankrollen db_datareader und
db_datawriter zugewiesen ist, mit dem Befehl DENY die Berechtigung zum Löschen von
Einträgen verweigert werden. Dieses Verfahren könnte verwendet werden, um einem
Benutzer das Erstellen und Aktualisieren von Verkaufseinträgen zu erlauben, aber nicht das
Löschen von Einträgen. Das folgende Skript kann verwendet werden, um einem Benutzer die
Berechtigung zum Löschen von Zeilen aus der Tabelle "CCTable1" zu verweigern.
DENY DELETE ON OBJECT::CCTable1 TO [Pat]
Hinweis:
Einige gespeicherte Systemprozeduren und DBCC-Befehle prüfen beim
Ausführen von Vorgängen die Rollenmitgliedschaft, aber nicht die
Berechtigungen. Daher muss immer überprüft werden, ob sich Berechtigungen
wie erwartet verhalten, bevor sie produktiv eingesetzt werden.
Serverrollenberechtigungen
Jeder Serverrolle ist ein Satz von Berechtigungen zugeordnet. Diese Rollen vereinfachen es,
einem Benutzer einen Berechtigungssatz zuzuweisen. Weitere Informationen, einschließlich
einer Auflistung der Berechtigungssätze, die den festen Serverrollen zugewiesen sind, finden
Sie unter Berechtigungen der festen Serverrollen (Datenbankmodul). Im folgenden Beispiel
wird ein Skript zum Anwenden einer Serverberechtigung dargestellt.
GRANT ALTER ANY LOGIN TO [SQLVM03-18158EA\Pat]
26
Die in Abbildung 11 gezeigte Seite Anmeldungseigenschaften kann verwendet werden,
um Serverberechtigungen für einen Anmeldenamen zu gewähren oder zu verweigern. Auf
der Registerkarte Explizit sind alle Berechtigungen einzeln aufgeführt. Über diese
Registerkarte können Berechtigungen gewährt bzw. verweigert oder das Erteilen einer
Berechtigung durch den Anmeldenamen zugelassen werden. Auf der Registerkarte Effektiv
sind die Berechtigungen aufgeführt, die einem Anmeldenamen basierend auf dessen
Rollenmitgliedschaft gewährt werden. Im Beispiel in Abbildung 11 wird Pat die
Löschberechtigung für Tabelle CCTable1 verweigert.
Abbildung 11: Berechtigungen der Serveranmeldung
Datenbankberechtigungen
Jeder Datenbankrolle ist ein Satz von Berechtigungen zugewiesen. Der Satz von
Berechtigungen, der festen Datenbankrollen zugewiesen ist, ist unter Berechtigungen der
festen Datenbankrollen (Datenbankmodul) aufgeführt. Im folgenden Beispiel wird ein Skript
zum Anwenden einer Datenbankberechtigung dargestellt.
USE Test1
27
GRANT CREATE TABLE TO [SQLVM03-18158EA\Pat]
Die Seite Datenbankbenutzer in Abbildung 12 kann verwendet werden, um einem Benutzer
Datenbankberechtigungen zu gewähren oder zu verweigern. Auf der Registerkarte Explizit
sind alle Berechtigungen einzeln aufgeführt. Über diese Registerkarte können
Berechtigungen gewährt bzw. verweigert oder das Erteilen einer Berechtigung durch den
Benutzer zugelassen werden. Auf der Registerkarte Effektiv sind die Berechtigungen
aufgeführt, die einem Benutzer basierend auf dessen Rollenmitgliedschaft gewährt werden.
Abbildung 12: Berechtigungen des Datenbankbenutzers
Berechtigungen auf Spaltenebene
Die Sicherheit auf Spaltenebene kann verwendet werden, um zu verhindern, dass ein
Benutzer auf bestimmte Spalten in einer Tabelle zugreift. Verwenden Sie die DENY
(Objektberechtigung), um den Zugriff auf eine Spalte zu verhindern. Im folgenden Beispiel
wird ein Skript zum Verweigern des Zugriffs auf eine Spalte dargestellt.
DENY SELECT ON [CCTable1] ([CCNumber]) TO [SQLVM03-18158EA\Pat]
28
Hinweis:
Eine Abfrage scheitert, wenn sie eine Spalte enthält, auf die ein Benutzer nicht
zugreifen kann. Beispielsweise funktioniert die Anweisung SELECT * nicht für
eine Tabelle, für die dem Benutzer der Zugriff verweigert wurde. Es wird
empfohlen, dass Anwendungen die in einer Abfrage erforderlichen spezifischen
Spalten enthalten und nicht die Anweisung SELECT * zu verwenden.
Die unten angezeigte Tabelleneigenschaftenseite kann verwendet werden, um den Zugriff
auf bestimmte Spalten in einer Tabelle zu blockieren. Das Beispiel in Abbildung 13 zeigt,
dass Pat der Zugriff auf die Spalte mit den Kreditkartennummern verweigert wurde. Dem
Benutzer müssen SELECT-Berechtigungen für die Tabelle gewährt werden, bevor die
Schaltfläche Spaltenberechtigungen aktiviert wird.
Abbildung 13: Gewähren und Verweigern von Berechtigungen für Datenbankspalten
29
Aufgabentrennung
Die Aufgabentrennung (Separation of Duties, SOD), auch als Rollentrennung bezeichnet,
spielt bei der Identitäts- und Berechtigungsverwaltung eine wichtige Rolle. Sie hilft beim
Abwehren von Bedrohungen durch Einzelpersonen und kann verwendet werden, um die
ordnungsgemäße Ausführung von Aufgaben sicherzustellen. Wenn einer Aufgabe
beispielsweise ein separater Autor, Prüfer und Genehmigender zugewiesen ist, kann jede
dieser Personen sicherstellen, dass die anderen im Rahmen der ihnen übertragenen
Aufgaben agieren und dass beim Ausführen einer Aufgabe keine Fehler gemacht werden.
Die Aufgabentrennung verfolgt zwei Hauptziele:


Sicherstellen, dass die Rollen der Benutzer (z. B. Prüfer und Genehmigender) nicht in
Konflikt stehen
Sicherstellen, dass Benutzer mit einer bestimmten Rolle keine Vorgänge außerhalb
dieser Rolle ausführen können
Viele Datencontroller möchten verhindern können, dass Benutzer mit weit reichenden
Berechtigungen auf ihre sensiblen Daten zugreifen. Derzeit kann mit SQL Server nicht
verhindert werden, dass Mitglieder der Rolle sysadmin bestimmte Vorgänge ausführen, die
ggf. mit den Regeln der Aufgabentrennung in Konflikt stehen. Es können jedoch Risiko
mindernde Kontrollen erstellt werden, um das Risiko zu reduzieren, dass ein
Systemadministrator unzulässige Vorgänge ausführt. Als erste Möglichkeit kann das Konto
sa deaktiviert werden. Zweitens können die Mitglieder der Rolle sysadmin auf die absolut
notwendigen Personen beschränkt werden. Drittens kann jeder von einem
Systemadministrator ausgeführte Vorgang überwacht und geprüft werden. Darüber hinaus
kann die richtlinienbasierte Verwaltung verwendet werden, um zu überprüfen, ob jede dieser
Kontrolle aktiviert ist. Beispiele für die Verwendung der richtlinienbasierten Verwaltung zum
Verwalten der Aufgabentrennung finden Sie unter Verwalten der Aufgabentrennung.
Einschränken der Verwendung der Rolle "sysadmin"
Mitglieder der Serverrolle sysadmin in SQL Server sind berechtigt, beliebige Funktionen in
der Datenbank auszuführen. Daher sollte sorgfältig überlegt werden, welche Personen dieser
Rolle als Mitglied hinzugefügt werden. Die Berechtigungen sollten nur einer kleinen Gruppe
von Benutzern erteilt werden. Es sollte zwar mehr als ein Administrator zugewiesen werden,
um für einen Stellvertreter zu sorgen, aber es ist nicht empfehlenswert, die Berechtigungen
zu umfassend zu verteilen.
Deaktivieren des Administratorkontos (sa)
Normalerweise ist das Konto sa nicht zum Verwalten von SQL Server erforderlich und sollte
nicht verwendet werden. Das Konto sa ist keiner speziellen Einzelperson zugeordnet, sodass
nicht einfach festgestellt werden kann, wer das Konto sa verwendet. Mit SQL Server
Management Studio kann das Konto umbenannt werden, um sicherzustellen, dass es nicht
von Anwendungen verwendet wird. Das Konto kann auch deaktiviert werden, damit Benutzer
sich nicht mit dem Konto anmelden können.
30
Verwenden von signierten Prozeduren zum Agieren als Systemadministrator
(Deaktivieren aller sysadmin-Konten)
Das Deaktivieren aller sysadmin-Konten kann ein Problem darstellen, da nur ein
Systemadministrator das sa-Konto erneut aktivieren und/oder bestimmte Befehle wie
DBCC PINTABLE ausführen kann. Diese Einschränkung kann jedoch nur durch Verwenden
von signierten Prozeduren überwunden werden. Eine signierte Prozedur kann unter der Rolle
sysadmin von Datenbankbenutzern ausgeführt werden, die nicht Mitglied der Rolle
sysadmin sind. Eine solche Prozedur kann verwendet werden, um alle sysadmin-Konten zu
aktivieren und zu deaktivieren. Weitere Informationen finden Sie unter Deaktivieren aller
sysadmin-Konten. Diese Prozeduren können auch verwendet werden, um Vorgänge
auszuführen, die normalerweise dem Systemadministrator vorbehalten sind. Auf diese
Weise können diese Aktionen von Benutzern mit eingeschränkten Rechten ausgeführt
werden, ohne ihnen alle Berechtigungen eines Systemadministrators gewähren zu müssen.
Hinweis:
Vermeiden Sie es, einem Anmeldenamen die Berechtigung CONTROL SERVER
zuzuweisen. Diese Berechtigung erlaubt dem Benutzer, viele der für einen
Systemadministrator vorbehaltenen Vorgänge auszuführen. Darüber hinaus ist
der Benutzer in der Lage, die Identität des sa-Kontos anzunehmen, auch wenn
das Konto deaktiviert ist. Wenn Sie einem Benutzer die Berechtigung CONTROL
SERVER gewähren müssen, sollten Sie mit DENY IMPERSONATE auch für
jedes sysadmin-Konto die Berechtigung zum Identitätswechsel verweigern.
Beispiel:
USE master
DENY IMPERSONATE ON LOGIN::Yukonsa TO [SQLVM03-18158EA\Pat];
Beim Setup definierte sysadmin-Konten
In den Tabellen unten werden die Prinzipale beschrieben, die bei Neuinstallationen für die
Rolle sysadmin definiert werden. Bei Upgrades wird die aktuelle Mitgliedschaft der Rolle
sysadmin nicht geändert.
Zuweisen der sysadmin-Rolle beim SQL Server 2008-Setup
Den SQL Server-Diensten werden während der Installation Dienstkonten zugewiesen. Es
wird jedoch empfohlen, diese Konten in Domänenkonten oder lokale Benutzerkonten zu
ändern. So kann verhindert werden, dass andere Anwendungen, die unter denselben
Diensten ausgeführt werden, auf SQL Server-Ressourcen zugreifen. Weitere Informationen
zum Zuweisen von Dienstkonten finden Sie unter Einrichten von Windows-Dienstkonten.
31
Bei Neuinstallationen von SQL Server 2008 werden der Rolle sysadmin standardmäßig die
folgenden drei Prinzipale als Kernsatz zugewiesen.
Konto
Zweck
Dies ist das obligatorische Benutzerkonto für das
sysadmin-Konto bei Ausführung im gemischten Modus.
Das Konto wird standardmäßig deaktiviert, wenn
SQL Server mithilfe des WindowsAuthentifizierungsmodus eingerichtet wird.
Windows-Prinzipal
Dies ist das obligatorische Windows-Konto, das beim
Setup bereitgestellt werden muss. Diese Person agiert
als der sysadmin (Systemadministrator) für die
SQL Server-Instanz.
NT-AUTORITÄT\SYSTEM
Wird von Windows-Diensten wie Microsoft Update,
Windows Update, System Center Configuration Manager
und Windows Cluster Server verwendet.
Tabelle 1: Bei der Installation definierte sysadmin-Rollen
sa
Bei der Installation von SQL Server unter Windows Vista® oder Windows Server 2008
werden der Rolle sysadmin die folgenden Konten hinzugefügt.
Konto
NT-DIENST\MSSQLSERVER
Zweck
Dies ist eine besondere Sicherheits-ID (SID), die
dem SQL Server-Dienst beim Setup zugewiesen
wird. Sie ersetzt nicht das Konto, unter dem der
Dienst ausgeführt wird. Die Einstellung
"NETZWERKDIENST" bleibt bestehen, sofern sie
nicht von der Person geändert wird, die
SQL Server installiert. Die SID wird verwendet,
wenn der Dienst eine Verbindung mit SQL Server
herstellt. Das Konto wird verwendet, wenn der
Dienst eine Verbindung mit einer
Remoteressource herstellt, beispielsweise mit
einer Dateifreigabe, um Protokolle zu speichern.
NT-DIENST\SQLSERVERAGENT
Dies ist eine besondere SID, die dem SQL ServerAgent-Dienst beim Setup zugewiesen wird. Sie
ersetzt nicht das Konto, unter dem der Dienst
ausgeführt wird. Die Einstellung
"NETZWERKDIENST" bleibt bestehen, sofern sie
nicht von der Person geändert wird, die
SQL Server installiert. Die SID wird verwendet,
wenn der Dienst eine Verbindung mit SQL Server
herstellt. Das Konto wird verwendet, wenn der
Dienst eine Verbindung mit einer
Remoteressource herstellt, beispielsweise mit
einer Dateifreigabe, um Protokolle zu speichern.
Tabelle 2: sysadmin-Prinzipale, die unter den Betriebssystemen Windows Vista und
Windows Server 2008 zugewiesen werden
32
Bei der Installation von SQL Server unter anderen Betriebssystemen als Windows Vista oder
Windows Server 2008 werden der Rolle sysadmin die folgenden Konten hinzugefügt.
Konto
NT-AUTORITÄT\NETZWERKDIENST
Zweck
Dieses Konto wird standardmäßig den SQL
Server- und SQL Server-Agent-Diensten
zugewiesen. Dieses Konto wird für den Zugriff
auf SQL Server und die dazugehörigen
Ressourcen verwendet. Es wird empfohlen,
ein Windows-Benutzerkonto zu verwenden.
Hierdurch wird das Risiko begrenzt, dass ein
anderer Dienst, der dieses Konto verwendet,
auf SQL Server zugreifen kann. Beim
Verwenden eines Windows-Kontos besteht
das Risiko, dass der Dienst nicht mehr
verwendet werden kann, wenn das
Kontokennwort geändert wird und diese
Änderung nicht auf der Registerkarte
Anmelden der Diensteigenschaftenseite
widergespiegelt wird.
localhost\SQLServer2005MSSQLUser$
Diese Windows-Gruppe wird verwendet, um
localhost$MSSQLSERVER
Benutzer zu definieren, die Zugriff auf
SQL Server benötigen.
localhost\SQLServer2005SQLAgentUser Diese Windows-Gruppe wird verwendet, um
$localhost$MSSQLSERVER
Benutzer zu definieren, die Zugriff auf den
SQL Server-Agent benötigen.
Tabelle 3: sysadmin-Prinzipale, die früheren Versionen von Windows zugewiesen sind
Hinweis:
In dieser Tabelle stellt "localhost" den Namen des Computers dar.
Zuweisung von Dienst-SIDs unter Windows Vista und Windows Server 2008
Windows Vista und Windows Server 2008 bieten die Möglichkeit, den Diensten eine
ausgeblendete SID zuzuweisen. Beim SQL Server 2008-Setup wird den SQL Server- und
SQL Server-Agent-Diensten eine separate SID zugewiesen. Das Konto, das den Diensten
zugewiesen wird, wird noch benötigt, um den Dienst zu starten und auf externe Ressourcen
zuzugreifen. Wenn die Dienste jedoch auf SQL Server und lokale Ressourcen zugreifen,
beispielsweise Dateien und Registrierungseinträge, werden ihre entsprechenden SIDs
verwendet.
Verwenden der Gruppe "VORDEFINIERT\Administratoren"
Vor der Veröffentlichung von SQL Server 2008 waren die Mitglieder der Gruppe
"VORDEFINIERT\Administratoren" auch Mitglied der Rolle sysadmin in SQL Server. Bei
Installationen unter Windows Vista oder Windows Server 2008 werden die Mitglieder der
Gruppe "Administratoren" jedoch als Standardbenutzer ausgeführt und können daher nicht
auf SQL Server zugreifen. Natürlich könnten diese Benutzer ihre Token auf Administrator
heraufstufen, um auf SQL Server zuzugreifen. Dies ist jedoch nicht empfehlenswert.
SQL Server 2005 SP2 wird mit einem Kontobereitstellungstool ausgeliefert, das
Administratoren das Hinzufügen ihrer Windows-Konten zur Rolle sysadmin erlaubt.
33
In SQL Server 2008 wird die Gruppe "VORDEFINIERT\Administratoren" nicht der Rolle
sysadmin hinzugefügt. Zudem steht das Kontobereitstellungstool nicht zur Verfügung. Beim
Setup kann der Rolle sysadmin jedoch ein Windows-Konto hinzugefügt werden. Nach dem
Setup können dem Konto sysadmin bei Bedarf zusätzliche Windows-Konten hinzugefügt
werden. Es wird empfohlen, der Rolle sysadmin keine Windows-Gruppen hinzuzufügen, da
hierdurch jede Person, die Lese-/Schreibzugriff für die Gruppe besitzt, auf SQL Server
zugreifen kann.
Identitätsverwaltung mit Multi-Tier-Anwendungen
In vielen Anwendungen wird den Benutzern mithilfe eines Kontos, das speziell für die
Anwendung erstellt wurde, Zugriff auf die Datenbank gewährt. Dieser Entwurf verhindert den
direkten Zugriff auf die Datenbank und rationalisiert die Verwaltung. Der Nachteil ist jedoch,
dass nicht verfolgt werden kann, welcher Benutzer bestimmte Vorgänge ausführt. Durch
Verwenden eines Dienstkontos mit der Berechtigung IMPERSONATE wird es Anwendungen
gestattet, den Befehl EXECUTE AS zu verwenden, um dem Benutzer eine bestimmte Rolle
zuzuweisen und dadurch die vom Benutzer ausführbaren Vorgänge zu beschränken. Sie
können das Konto deaktivieren, dessen Identität angenommen wird, um die
Benutzeranmeldung zu verhindern, aber gleichzeitig das Nachverfolgen der Benutzer mit
feinerer Granularität erlauben.
34
Verschlüsseln von Datenbankdaten
Der Schutz sensibler Daten ist bei Datenbankvorgängen ein wichtiger Aspekt. SQL Server
2008 stellt mehrere Möglichkeiten zum Schutz sensibler Daten mithilfe von Verschlüsselung
bereit. In diesem Abschnitt wird die Verwendung der Verschlüsselung in SQL Server
behandelt und erläutert, welche besonderen Erwägungen zu berücksichtigen sind. Weitere
Informationen, einschließlich Skripts zum Verwalten der richtlinienbasierten Verwaltung,
finden Sie unter Verwalten von Verschlüsselungsschlüsseln.
SQL Server-Datenbankverschlüsselung
Ab SQL Server 2005 steht die systemeigene Verschlüsselung für Datenbankanwendungen
zur Verfügung. Davor konnten Anwendungen nur mithilfe der CAPICOM-Funktionen von
Windows eine eigene Verschlüsselung bereitstellen. Weitere Informationen zum Verwenden
der SQL Server-Verschlüsselung finden Sie unter SQL Server-Verschlüsselung.
Auswählen eines Verschlüsselungsalgorithmus
Bei der Auswahl eines Verschlüsselungsalgorithmus wird normalerweise zwischen dem
Schutzgrad und der Leistungsstufe abgewogen. Im Allgemeinen bieten
Verschlüsselungsschlüssel einen stärkeren Schutz, die Ausführung nimmt jedoch mehr Zeit
in Anspruch. Die Ausführung ist bei asymmetrischen Schlüsseln zwar langsamer als bei
symmetrischen Schlüsseln, dafür bieten sie aber einen stärkeren Schutz, und die
Verschlüsselung ist nicht freigegeben. Beim Verwenden eines Zertifikats ist die Sperrung
erlaubt, aber SQL Server unterstützt die Sperrung nicht, es sei denn, das Zertifikat wird lokal
gelöscht. Weitere Informationen zum Auswählen eines Algorithmus finden Sie unter
Auswählen eines Verschlüsselungsalgorithmus.
Verwenden der transparenten Datenverschlüsselung
Mit SQL Server 2008 wurde die transparente Datenverschlüsselung eingeführt, um die
Verschlüsselung von Datenbankdaten zu erlauben, ohne Anwendungen ändern zu müssen.
Bei der transparenten Datenverschlüsselung werden Datendateien, Protokolldateien und
Sicherungen verschlüsselt.
35
Abbildung 14 zeigt die Vorgänge, die beim Implementieren der transparenten
Datenverschlüsselung berücksichtigt werden müssen:




Der private Zertifikatschlüssel muss unbedingt gesichert werden.
Zertifikate und Schlüssel müssen regelmäßig gewechselt (rotiert) werden, so wie dies die
Vorschriften vorsehen.
Verwenden Sie die erweiterbare Schlüsselverwaltung für einen stärkeren Schlüsselschutz
und Aufgabentrennung.
Überwachen Sie den Schlüssel- und Verschlüsselungszugriff.
Abbildung 14: Verwalten von Schlüsseln für die transparente Datenverschlüsselung
Sichern des privaten Schlüssels des Zertifikats
Der Verschlüsselungsschlüssel für eine Datenbank, die mit der transparenten
Datenverschlüsselung verschlüsselt wurde, wird in der Datenbank gespeichert und mit einem
Zertifikat geschützt. Der private Zertifikatschlüssel muss unmittelbar nach der
Zertifikaterstellung und noch vor dessen Verwendung in Verbindung mit der transparenten
Datenverschlüsselung gesichert werden. Wenn das Zertifikat aus einem bestimmten Grund
zerstört wurde, bevor das Zertifikat gesichert werden konnte, können alle mit der transparenten
Datenverschlüsselung geschützten Datenbanksicherungen nicht mehr wiederhergestellt
werden. Das folgende Skript kann zum Sichern eines Zertifikats verwendet werden.
USE master
BACKUP CERTIFICATE [MyServerCert] TO FILE =
'c:\certificates\MyServerCert.crt'
WITH PRIVATE KEY (FILE = 'c:\certificates\MyServerCert.pvk',
ENCRYPTION BY PASSWORD = 'MyPass7779311#');
36
Zertifikatsicherungen sollten an einem sicheren Ort gespeichert werden. Sie können auf
einem Datenträger gespeichert und in einem Safe aufbewahrt oder in eine sekundäre
Datenbank mit eingeschränktem Zugriff importiert werden.
Rotieren von Zertifikaten oder Rotieren von Schlüsseln
Viele Vorschriften sehen vor, dass die Verschlüsselungsschlüssel in Organisationen
regelmäßig gewechselt (rotiert) werden. Die Zertifikate der transparenten
Datenverschlüsselung und die Datenbankverschlüsselungsschlüssel können mithilfe von
Skripts turnusmäßig gewechselt werden. Möglicherweise ist der erste Gedanke, den
Datenbankverschlüsselungsschlüssel zu wechseln. Das Rotieren des Zertifikats erfüllt jedoch
eher den Zweck der Richtlinie. Durch Rotieren von Zertifikaten kann der Schutz aktualisiert
werden, ohne die Datenbank erneut verschlüsseln zu müssen. Zudem kann hierdurch der
Zugriff auf verschlüsselte Daten auf einfache Weise aufgehoben werden. Beim Rotieren des
Datenbankverschlüsselungsschlüssels werden die Daten erneut verschlüsselt, aber hierdurch
wird kein zusätzlicher Schutz bereitgestellt, so wie es die Richtlinie beabsichtigt.
Wenn beispielsweise 100 Datenbanksicherungsbänder mithilfe von 100 verschiedenen
Verschlüsselungsschlüsseln erstellt wurden, kann weiterhin mit einem einzelnen Zertifikat auf
alle Sicherungsbänder zugegriffen werden. Wenn die Zertifikate zwischen den Sicherungen
gewechselt werden, wäre ein Zugriff auf jedes der 100 Zertifikate erforderlich, um die
verschlüsselten Daten von den Bändern abzurufen.
Bei jeder Neuerstellung eines Zertifikats muss es aus Gründen der Redundanz gesichert
werden. Die Sicherung kann mithilfe von Skripts ausgeführt werden. Die gesicherten
Zertifikate sollten sofort in eine sichere Datenbank importiert werden. Anschließend sollte die
Kopie zerstört oder an einem sicheren Ort gespeichert werden. Sie können einen Auftrag
erstellen, um die Schlüssel turnusmäßig zu wechseln. Mithilfe der richtlinienbasierten
Verwaltung kann sichergestellt werden, dass Zertifikate oder Schlüssel in einem bestimmten
Turnus gewechselt werden.
Hinweis:
Um verschlüsselte Sicherungen, Momentaufnahmen oder Protokolleinträge
wiederherzustellen, muss der Zugriff auf das zur Verschlüsselung verwendete
Zertifikat möglich sein. Zu diesem Zweck muss eine Zertifikatkopie erstellt und
geschützt werden, um einen unerwünschten Zugriff auf sensible Daten zu
vermeiden.
Überwachen des Schlüsselzugriffs
Der Zugriff auf Verschlüsselungsschlüssel ist ein sensibler Vorgang. Das Überwachen dieses
Zugriffs kann als Risiko mindernde Kontrolle für PCI-DSS (Payment Card Industry Data
Security Standard) und andere Vorschriften und Verordnungen verwendet werden. Schlüssel
und Zertifikate für die transparente Datenverschlüsselung werden in der Benutzerdatenbank
bzw. in der master-Datenbank gespeichert. Der Zugriff auf diese Objekte kann mithilfe einer
Serverspezifikation überwacht werden, die die Überwachungsaktionstypen
DATABASE_OBJECT_ACCESS_GROUP und DATABASE_OBJECT_CHANGE_GROUP
zum Überwachen von Schlüsselzugriffen bzw. Änderungen umfasst. Diese Aktionen sollten
37
lediglich eine geringfügige Protokollierung in Produktionsdatenbanken auslösen, da nur sehr
wenige Objekte überwacht werden, die in der Produktion selten geändert werden. Im
Folgenden finden Sie eine Liste der Datenbankobjekte:
•
•
•
•
•
•
•
•
•
•
•
Assembly
Asymmetrischer Schlüssel (nur privater Schlüssel)
Zertifikat (nur privater Schlüssel)
Datenbank-Überwachungsspezifikationen (nur Änderungen)
Volltextkatalog
Volltextstoppliste (nur SQL Server 2008)
Partitionsfunktionen (nur Änderungen)
Schema (nur Änderungen)
Service Broker-Objekte
o Vertrag
o Nachrichtentyp
o Remotedienstbindung
o Route
o Dienst
Symmetrischer Schlüssel
Trigger (nur Änderungen)
Überwachen des Verschlüsselungsflags für die Datenbank
Nachdem der Verschlüsselungsschlüssel eingerichtet wurde, um die transparente
Datenverschlüsselung für eine Datenbank zu ermöglichen, muss auch das
Verschlüsselungsflag aktiviert werden. Dieses Flag sollte überwacht werden, um
sicherzustellen, dass der Schutz der Datenbank aufrechterhalten bleibt. Um das
Verschlüsselungsflag für eine Datenbank zu überwachen, sollte der Überwachungsaktionstyp
DATABASE_CHANGE_GROUP einer Serverüberwachungsspezifikation hinzugefügt werden.
Behandeln von spezifischen Szenarien
SQL Server 2008 stellt mehrere Optionen zum Schützen von sensiblen Daten bereit. Die
gewählte Option hängt vom gewünschten Schutzgrad, der Möglichkeit zur
Anwendungsänderung, der Leistung und von anderen Faktoren ab. Bei der Auswahl eines
Schutzmechanismus sollten Sie das Szenario berücksichtigen, für das Sie Schutz
bereitstellen möchten.
Absichern gegen den Diebstahl eines Computers
Das verschlüsselnde Dateisystem (Encrypting File System, EFS) von Windows, die
BitLocker-Laufwerkverschlüsselung von Windows und die transparente
Datenverschlüsselung können gemeinsam oder einzeln verwendet werden, um die in Dateien
gespeicherten Datenbankdaten zu schützen, falls ein Computer gestohlen wird. EFS und
BitLocker™ erlauben allen Personen, die einen Administratorzugriff auf das Computersystem
besitzen, die Datenbankdatei außerhalb von SQL Server anzuzeigen. Mit EFS und BitLocker
können nur Dateien geschützt werden, die sich in einem geschützten System befinden. Das
Verwenden von EFS und BitLocker kann zu einer Beeinträchtigung der Datenbankleistung
38
führen. Wenn eine Datei auf ein ungeschütztes Volume kopiert wird, ist die Verschlüsselung
nicht mehr vorhanden. Die transparente Datenverschlüsselung schützt eine Datei auch dann,
wenn diese in ein anderes System kopiert oder auf Band gesichert wird. Weitere
Informationen zum Verwenden der transparenten Datenverschlüsselung im Vergleich zu
BitLocker oder EFS finden Sie unter Datenbankverschlüsselung in SQL Server 2008
Enterprise Edition.
Verhindern des Zugriffs durch Systemadministratoren und Datenbankbesitzer
Der Systemadministrator und der Datenbankbesitzer können nicht am Anzeigen von
Tabellendaten gehindert werden. Die Mitglieder der Rollen sysadmin
(Systemadministratoren) und db_owner (Datenbankbesitzer) können jedoch deaktiviert
werden, um so das Sicherheitsrisiko zu entschärfen. Gespeicherte Prozeduren können
verwendet werden, um Vorgänge auszuführen, die auf die Rolle sysadmin beschränkt sind.
Weitere Informationen finden Sie unter Einschränken der Verwendung der Rolle "sysadmin".
Wenn es notwendig ist, dem Systemadministrator oder Datenbankbesitzer Zugriff zu
erteilen, können die Aktionen dieser Benutzer mithilfe von SQL Server Audit verfolgt werden.
Weitere Informationen finden Sie unter Verfolgen des sysadmin- und db_owner-Zugriffs.
Schützen einer Spalte in einer Datenbanktabelle
Häufig besteht der Wunsch, eine einzelne Spalte in einer Tabelle zu schützen, die
vertrauliche Daten enthält, beispielsweise Kreditkartennummern. SQL Server 2008 stellt
hierfür mehrere Möglichkeiten bereit. Die Spalte könnte mit einer Kryptografiefunktion
verschlüsselt werden. Weitere Informationen finden Sie unter Vorgehensweise:
Verschlüsseln einer Datenspalte. Dieser Mechanismus erfordert Änderungen an der
Anwendung, verhindert die Suche und Indizierung und wirkt sich negativ auf die Leistung
aus. Spaltendaten können auch mithilfe der Sicherheit auf Spaltenebene geschützt werden,
die weiter oben in diesem Dokument im Abschnitt Berechtigungen auf Spaltenebene
behandelt wurde.
39
Überwachen sensibler Vorgänge
In diesem Abschnitt wird erläutert, wie sensible Vorgänge mithilfe von SQL Server Audit
überwacht werden können. Mit SQL Server Audit können Datenbankereignisse mithilfe von
Überwachungsaktionsgruppen auf einer hohen Ebene oder mithilfe von
Überwachungsaktionen auf einer differenzierten Ebene überwacht werden. Eine Liste der
Überwachungsaktionsgruppen und Überwachungsaktionen finden Sie hier. Skripts zum
Verwalten der Überwachung und zum Erstellen verschiedener Überwachungselemente
finden Sie weiter unten in diesem Abschnitt unter Verwalten der Überwachung.
Anhand eines Beispiels wird das Zentralisieren der Sammlung von Überwachungsprotokollen
mithilfe von System Center Operations Manager sowie mithilfe einer Netzwerkfreigabe
erläutert. Es wird ein Skript bereitgestellt, das veranschaulicht, wie SQL Server Integration
Services (SSIS) und SQL Server Reporting Services (SSRS) (siehe Abbildung 15) zum
Entwickeln von sich wiederholenden Berichten verwendet werden.
Abbildung 15: Zentralisieren von Überwachungsprotokollen und Berichterstellung
SQL Server Database Servers
Process Audit Information
Use SQL Server Integration Services to process SQL Server 2008 audit log data
and store in its own SQL Server database.
SSIS
SQL Server
database
SQL Server
database
Transfer Logs
SQL Audit
File Server
SQL Server
database
SQL Server
database
po
Re
e
rat
ne
e
G
rts
SSRS
Compliance Reports
Von einer höheren Perspektive aus betrachtet basiert die Architektur zum Überwachen
sensibler Vorgänge auf folgenden Schritten: Aktivieren der Überwachung der verschiedenen
Datenbanken und Server und Platzieren dieser Protokolldateien an einem zentralen Ort (dies
40
ist in Abbildung 15 der Protokollordner). Von diesem Ort aus können Sie (z. B. mithilfe von
SQL Server Integration Services) eigene Prozesse entwickeln, um die
Überwachungsprotokolle in aussagekräftige Berichte zu verwandeln.
Sammeln von Protokollen
Das SQL Server Audit-Objekt kann so konfiguriert werden, dass Protokolle in einer Datei
gespeichert werden. Das Senden von Protokollen an eine Remotefreigabe ist das
empfohlene Verfahren zum Speichern von Protokollen. Auf diese Weise werden sie der
Kontrolle des Serveradministrators entzogen und können mit Protokollen von anderen
Servern konsolidiert werden. Dem Ordner, in dem die Protokolle gespeichert werden, muss
vom SQL Server-Dienst Schreibzugriff erteilt werden. Standardmäßig wird der Dienst unter
dem Netzwerkdienstkonto ausgeführt. Beim Verwenden eines Dienstkontos besteht das
Risiko, dass jeder Dienst, der unter dem Konto ausgeführt wird, auf den Ordner mit den
Protokollen zugreifen und die Protokolldateien überschreiben kann. Um dieses Risiko zu
reduzieren, kann ein Benutzerkonto verwendet werden. Wenn das Benutzerkonto jedoch
deaktiviert wird oder das Kennwort geändert und das aktualisierte Kennwort nicht an die
unter diesem Konto ausgeführten Dienste weitergegeben wird, kann der SQL Server-Dienst
nicht gestartet werden.
Übertragen von Protokollen
Um das Risiko des Überschreibens von Protokollen zu minimieren, können die Protokolle aus
der Datei in eine private Datenbank verschoben werden. Sobald sich die Protokolldateien in
der Datenbank befinden, können nur Benutzer mit Datenbankzugriff auf die Protokolle
zugreifen. Möglicherweise halten es einige Prüfer jedoch für bedenklich, dass Protokolle
geändert werden können, nachdem sie in einer Datenbanktabelle gespeichert wurden.
Mithilfe von SSIS kann ein Paket erstellt werden, das die Protokolle aus der Protokolldatei in
eine Datenbanktabelle verschiebt. Das Paket kann in einen Auftrag geladen werden, der
mithilfe des SQL Server-Agents erstellt wird und dazu dient, das Paket regelmäßig
auszuführen. Hierdurch kann das Risiko des Überschreibens von Protokollen in der
Protokolldatei minimiert werden.
Verwenden von Skripts und Tools zum Verwalten der Überwachung
Nachdem Sie die Überwachung für Datenbanken aktiviert haben, steht Ihnen eine Fülle von
Informationen in Form von Überwachungsprotokollen zur Verfügung. In diesen Protokollen
werden in kurzer Zeit viele Informationen gespeichert. Daher sollten Sie gezielt überlegen,
wie Sie Überwachungsprotokolle sinnvoll nutzen können. Dies können Sie am einfachsten
erreichen, indem Sie die Überwachungsdaten in eine SQL Server-Datenbank laden, um in
dieser Datenbank Abfragen auszuführen. Anhand der Ergebnisse dieser Abfragen können
Sie die Vorgänge in der SQL Server-Umgebung besser verstehen.
41
Der grundlegende Datenfluss bei der Verarbeitung der Überwachungsprotokolle wird in
Abbildung 16 veranschaulicht.
Abbildung 16: GRC-Beispiel
Read Logs
Add
Import Id
Manage/
Load
Dimensions
Split Facts
Count Rows
Store File
Information
Load Facts
1) Protokolle lesen: Sie benötigen einen Mechanismus, um
Überwachungsprotokolldateien zu lesen und die Daten zu filtern und je nach
Anforderung zu transformieren.
2) Import-ID hinzufügen: Um feststellen zu können, welche
Überwachungsprotokolldateien verarbeitet wurden, identifizieren Sie im ETL-Prozess
die verarbeiteten Dateien und weisen ihnen eine Import-ID zu. Auf diese Weise
können Sie allen importierten Überwachungsereignissen eine Import-ID zuordnen.
Mithilfe dieser Zuordnung können Sie die Dateien ermitteln, aus denen die jeweilige
Überwachung stammt.
3) Dimensionen verwalten/laden: Es gibt Textbeschreibungen für verschiedene
Überwachungsereignisse sowie zugeordnete Domänencodes (z. B.
Überwachungskategorien und Sicherheitsklasse). Um die Größe der
Überwachungsdatenbank zu reduzieren, verknüpfen Sie die Dimensions-IDs mit der
Überwachungsereignis-Faktentabelle und verwalten eine separate Dimensionstabelle,
die die Dimensions-ID mit dem Dimensionsnamen übersetzt.
4) Fakten teilen/Fakten laden: Dies erfüllt den Zweck, alle Daten zu transformieren,
damit die Überwachungsereignis-Faktentabellen anstelle von Textwerten (wie jeweils
anwendbar) IDs enthalten, um den Speicherbedarf zu minimieren. Die Schritte 3 und
4 bieten für das Unternehmen den Vorteil, dass die Überwachungsberichte bei der
Erstellung nach den angegebenen Kategorien angezeigt werden können.
5) Zeilen zählen/Dateiinformationen speichern: Um den Mechanismus der
Überwachungsverarbeitung zu überwachen, muss sichergestellt werden, dass die
Überwachungsdateien verarbeitet wurden (daher die Aktion "Dateiinformationen
speichern"). Die Zeilen werden gezählt, um einen weiteren Datenüberprüfungsschritt
bereitzustellen, der sicherstellt, dass die Anzahl von Zeilen in der Datenbank mit der
Anzahl von Zeilen in den Überwachungsprotokolldateien übereinstimmt.
Weitere Informationen finden Sie unter Überwachungsprojekt.
42
Überwachen bestimmter Benutzer und Tabellen
SQL Server Audit erlaubt das Überwachen auf mehreren Granularitätsebenen. Da beim
Überwachen aller Datenbankvorgänge eine große Anzahl von Protokollen gesammelt wird,
ist es im Allgemeinen nahezu unmöglich, diese zu verarbeiten. Zudem kann hierdurch der
Speicherplatzbedarf enorm ansteigen und die Netzwerkleistung merklich beeinträchtigt
werden. Um dieses Problem zu beheben, stellt SQL Server Audit ein Verfahren zum
Überwachen bestimmter Ressourcen (z. B. Benutzer, Gruppen oder Tabellen) und
bestimmter Aktionen (SELECT, UPDATE oder EXECUTE) bereit. In den folgenden
Abschnitten werden diese Funktionen ausführlicher beschrieben.
Überwachen bestimmter Benutzer
Wenn Sie garantieren können, dass Ihre Umgebung sicher ist (z. B. können nur Mitglieder
der Rolle sysadmin Schema- und Datenänderungsaufgaben ausführen, und alle anderen
Benutzer können nur Daten lesen), haben Sie die Möglichkeit, nur den Benutzer sysadmin
zu überwachen. Hierbei wird jedoch vorausgesetzt, dass die vorhandenen
Sicherheitsrichtlinien alle zu berücksichtigenden Aspekte abdecken und dass autorisierte
Benutzer keine Fehler machen. Dies ist ein gängiger Ansatz in vielen
Produktionsumgebungen. Wenn die obigen Annahmen zutreffen, müssen Sie ggf. nur die
vom Benutzer sysadmin durchgeführten Aktionen überwachen, sodass er bei einem Verstoß
zur Rechenschaft gezogen werden kann.
Aber in vielen anderen Szenarien müssen Sie viel mehr Benutzer überwachen, da diese
Benutzer Daten in das System einfügen oder Systemdaten aktualisieren oder ändern können.
Im Idealfall ist nur der Benutzer sysadmin berechtigt, die Schemas und Objekte in der
Umgebung zu ändern, aber in diesem Fall müssen Sie dennoch die Benutzer überwachen,
die Datenänderungen vornehmen dürfen.
Letztendlich können Sie auch einfach die Überwachung aktivieren und jeden einzelnen
Benutzer überwachen, wenn Sie es aus geschäftlicher Perspektive für sinnvoll halten. Wenn
Sie sich jedoch für diese umfassende Überwachung entscheiden, füllen sich die
Überwachungsprotokolle in kurzer Zeit, da alle Aktivitäten – auch rechtmäßige –
aufgezeichnet werden. Dieser Ansatz eignet sich beispielsweise für das Gesundheitswesen.
Dort müssen alle Benutzer überwacht werden, die auf eine Datenbank zugreifen, auch wenn
sie nur eine Datenleseanforderung ausführen. Dies ist in den Richtlinien zur HIPAAEinhaltung (Health Information Portability and Accountability Act) vorgeschrieben. Sie können
die Überwachung aller Benutzer auch beibehalten, wenn Sie der Ansicht sind, dass ihre
Sicherheitsrichtlinien nicht alle Möglichkeiten abdecken. So können Sie mögliche
Hackerangriffe auf das System erkennen (z. B. Angriffe durch Einschleusung von SQLBefehlen). Wenn diese detaillierte Überwachung in Ihrem Szenario jedoch nicht erforderlich
ist, kann die Überwachungsprotokolllast reduziert werden, indem nur die Benutzer überwacht
werden, die das Schema der Datenbank (z. B. sysadmin) oder Daten in der Datenbank
ändern können.
43
Überwachen bestimmter Tabellen
Genauso wie es Benutzer gibt, deren Aktionen nicht überwacht werden müssen, gibt es auch
einige Tabellen im System, die nicht überwacht werden müssen. Angenommen, Sie haben
die Sicherheitsberechtigungen so festgelegt, dass nur die Daten in einer kleinen Gruppe von
Tabellen geändert werden können. In diesem Fall ist es sinnvoll, die Anzahl aufgezeichneter
Überwachungsereignissen zu beschränken, indem nur die Tabellen, die geändert werden
können, überwacht werden.
Dann wiederum gibt es einige Szenarien, in denen zwar alle Aktionen überwacht werden
müssen, die Berichterstattung aber nur für die Tabellen erforderlich ist, die Sie als sensibel
ansehen. Auf diese Weise können Sie zwischen Ihren Berichterstattungsanforderungen und
der Anforderung zum Speichern sämtlicher Überwachungsinformationen zur Einhaltung von
Vorschriften differenzieren. Zur Umsetzung dieser Differenzierung verweist die
Verarbeitungspipeline auf eine Konfigurationstabelle oder -datei, in der angegeben ist,
welche Tabellen in die Verarbeitung einbezogen oder von der Verarbeitung ausgeschlossen
werden sollen.
Verfolgen des sysadmin- und db_owner-Zugriffs
Häufig ist es so, dass bei Benutzern mit weit reichenden Berechtigungen ein höherer
Überwachungsbedarf besteht als bei Benutzern mit eingeschränkten Berechtigungen. SQL
Server Audit vereinfacht das Verfolgen von Mitgliedern der Rollen sysadmin und db_owner
auf einer differenzierteren Ebene. Beim Erstellen von Überwachungsaktionen für eine
Datenbank wird durch Zuweisen von "db_owner" als Prinzipalname die Nachverfolgung der
Mitglieder der Datenbankrolle db_owner sowie der Mitglieder der Serverrolle sysadmin
veranlasst, da Mitglieder von sysadmin als dbo (Datenbankbesitzer) zugeordnet werden,
und dieser ist immer Mitglied der Rolle db_owner. Das folgende Skript veranschaulicht dies
anhand eines Beispiels.
USE [Test1]
ALTER DATABASE AUDIT SPECIFICATION [AuditDBO]
ADD (SELECT ON [dbo].[CCTable1] BY [dbo])
Zentralisieren von Protokollen
Wenn Sie nur jeweils einen Server überwachen, macht das Zentralisieren von
Protokolldateien keinen Sinn. In den meisten Fällen arbeiten Sie jedoch mit einer großen
Anzahl von Servern und müssen mit dem Zustrom vieler Überwachungsprotokolle zurecht
kommen. Aus diesem Grund besteht der optimale Ansatz darin, die erstellten
Überwachungsprotokolle an einem zentralen Ort zu speichern. Dies bietet aus Sicht der
Verwaltbarkeit den Vorteil, dass Sie einfach auf einen zentralen Ort zugreifen können, wenn
Sie die Überwachungsprotokolle prüfen möchten, und diese Informationen nicht von jedem
einzelnen Server abrufen müssen. Bei Bedarf können Sie separate Repositorys (Ordner)
verwenden, die auf einer Geschäftslogik basieren. Das Verwenden eines zentralen Orts für
Überwachungsprotokolle vereinfacht jedoch das Speichern und Verwalten der Protokolle.
44
Im Zusammenhang mit dem Zentralisieren von Überwachungsprotokollen sollten Sie auch
die Verarbeitung zentralisieren. Bei einer zentralisierten Verarbeitung verwenden Sie einen
Satz dedizierter Server, die auf den zentralen Ort für die Protokolldateien ausgerichtet und für
die Verarbeitung der Überwachungsprotokolle zuständig sind. Bei diesem Ansatz stören sich
Datenquellenaktionen und Überwachungsaktionen (Verarbeiten und Abfragen) nicht
gegenseitig. Ein gängiger Ansatz ist beispielsweise, die Protokolldateien so zu konfigurieren,
dass sie bei einer Größe von 100 MB geteilt werden. Sie können hierbei auch eine etwas
höhere Dateigröße konfigurieren, damit nicht zu viele Dateien verwaltet werden müssen.
Beachten Sie jedoch, dass die Protokolldateien nicht so groß sein sollten, da in diesem Fall
die Verarbeitung einer einzelnen Datei sehr lange dauert.
Bei einer zentralisierten Verarbeitung können Sie auch Berichte generieren, die es Ihnen
ermöglichen, die Überwachungsinformationen für die gesamte Umgebung von einem
zentralen Ort aus anzuzeigen.
Hinweis:
Der einzige Nachteil beim Zentralisieren der Protokolle ist die mögliche
Leistungsbeeinträchtigung. Wenn Sie viele Ereignisse überwachen müssen
(beispielsweise in HIPPA-Szenarien, wo jeder Benutzer und jede Tabelle
überwacht wird), müssen umfangreiche Datenmengen ausgewertet werden. Das
Überwachungsprotokolldatei verhält sich hierbei ähnlich wie ein
Transaktionsprotokoll, und ein einzelner Dateiserver, der Daten über ein
langsames 100-MB-Netzwerk überträgt, kann möglicherweise nicht Schritt halten,
sodass der Abfragedurchsatz beeinträchtigt wird.
Erstellen von Berichten aus Protokolldateien
In diesem Abschnitt werden die verschiedenen Überwachungsberichte erläutert, damit Sie
die Ereignisse verstehen, die in der gesamten SQL Server-Umgebung auftreten. Im Abschnitt
Nützliche Tipps und Skripts werden verschiedene Möglichkeiten (mit zunehmender
Komplexität) zum Interpretieren der Überwachungsprotokolldateien bereitgestellt. Hierbei
handelt es sich um Beispiele für allgemeine Berichte, die Sie ggf. erstellen können, um das
System besser zu verstehen. Die Berichte sind nach dem Typ der Aktion unterteilt: Server,
Datenbank, Datenbankdefinitionssprache (DDL) und Datenbearbeitungssprache (DML).
45
Übersicht – Serveraktionen
Dieser Bericht gibt ihnen eine tägliche Übersicht über alle Ereignisse, die auftreten, geordnet
nach Serverinstanz, Datenbankprinzipal, Datenbank, Aktionsklasse und Aktion.
Abbildung 17: Bericht über Serveraktionen
Trendanalyse der Serveraktionen
Wenn Sie hier einen Bereich von Datumsangaben hinzufügen, können Sie feststellen, dass
eine große Anzahl von Anmeldungen erfolgreich war. Sie können jedoch auch sehen, dass
einige Massenverwaltungen und Anmeldungen gescheitert sind. Ein weitere Analyse zeigt ein
interessantes Muster bei den gescheiterten Anmeldungen. Wir haben den Bericht
"Serveraktionen - Übersicht" für den Zeitraum vom 19.08.2008 bis 21.08.2008 betrachtet und
uns nur auf die Aktion Fehler bei der Anmeldung konzentriert, wie Sie in Abbildung 18
sehen können.
Abbildung 18: Bericht "Trendanalyse der Serveraktionen"
46
In diesem speziellen Szenario gab es am 21.08.2008 mehr Anmeldefehler als an allen
anderen Tagen. Dies ist ein Beispiel für einen intelligenten Aggregatbericht, der
aussagefähige Informationen bereitstellt. In diesem Fall können anhand des Berichts
detaillierte Informationen darüber abgerufen werden, warum an diesen Tagen Anmeldungen
gescheitert sind.
Ausführen eines Drillthroughs zu den Serveraktionsdetails
Wenn wir zu Abbildung 17 zurückkehren, können wir auch einen Drillthrough zu den Details
dieses Berichts ausführen, um weitere Informationen zu diesen gescheiterten Anmeldungen
zu erhalten. In diesem Beispiel gab es 83 Anmeldefehler. Wenn Sie auf diese Zahl klicken,
werden detaillierte Informationen zu diesen Anmeldefehlern angezeigt.
Abbildung 19: Bericht über Serveraktionsdetails
47
Übersicht – Datenbankaktionen
Ebenso wie Sie einen Bericht über Serveraktionen anzeigen können, können Sie
Überwachungsereignisse nach der Anzahl der ausgeführten Datenbankaktionen anzeigen.
Wie Sie in Abbildung 20 sehen können, gibt es zwei Serverinstanzen, für die am 21.08.2008
drei bzw. vier Datenbankaktionen durchgeführt wurden.
Abbildung 20: Bericht über Datenbankaktionen
Ausführen eines Drillthroughs zu den Datenbankaktionen
Dieser Bericht zeigt, dass für die DataCollectionSPW-Datenbank drei GRANT-Aktionen und
für die master-Datenbank vier CREATE-Aktionen durchgeführt wurden. Wenn Sie einen
Drillthrough zu den Details ausführen (indem Sie auf die Zahl klicken), können Sie schnell
erkennen, dass es sich bei den CREATE-Anweisungen lediglich um RESTORE LABELONLYAnweisungen handelt, die von MYDOMAIN\Sql (Anmeldename) ausgeführt wurden.
Abbildung 21: Bericht über Datenbankaktionsdetails
Hinweis:
Wenn Sie eine Benutzerdatenbank sichern, benötigen Sie CREATEBerechtigungen für die master-Datenbank, um die Sicherungsmedien anzeigen
zu können. "CREATE-Berechtigung" ist eine unzutreffende Bezeichnung, da Sie
die Datenbank ja nicht erstellen, aber gleichwohl ist diese Berechtigung zum
Durchführen einer Sicherung erforderlich. Daher befinden sich in der folgenden
Überwachung RESTORE LABELONLY-Anweisungen.
48
Übersicht – DDL-Aktionen
Um zu verstehen, welche Datendefinitionen in Ihrer Umgebung vorgenommen wurden,
können Sie den Bericht Übersicht – DDL-Aktionen anzeigen, so wie in Abbildung 22
dargestellt. In diesem Fall gab es am 20.08.2008 für die angegebene Serverinstanz 44
DROP TABLE-Anweisungen für die SQLDBADMIN-Datenbank.
Abbildung 22: Bericht über Datenbank-DDL
Ausführen eines Drillthroughs zu den DDL-Aktionen
Um sicherzustellen, dass die DROP TABLE-Anweisungen gültig sind, können Sie einen
Drillthrough zu den einzelnen DDL-Aktionen ausführen. Sie liefern Informationen zu Uhrzeit,
Aktion, Objektname und der verwendeten DROP-Anweisung, sodass Sie die durchgeführten
Aktionen überprüfen können.
Abbildung 23: Bericht über Datenbank-DDL-Details
49
Übersicht – DML-Aktionen
Sie können sogar den Typ der DML-Anweisungen prüfen, die in der gesamten Umgebung
ausgeführt wurden. Dem Bericht Übersicht – DML-Aktionen können Sie entnehmen, dass
am 21.08.2008 vier DELETE-Anweisungen für die SQLDBADMIN-Datenbank durchgeführt
wurden.
Abbildung 24: Bericht über Datenbank-DML
Ausführen eines Drillthroughs zu den DML-Aktionen
Dieser Bericht stellt Details bereit, die Ihnen dabei helfen, die Gültigkeit jeder DML-Aktion
festzustellen. Wenn Sie auf "4" klicken, werden alle DELETE-Anweisungen sowie der
Serverprinzipalname des Benutzers angezeigt, der diese Anweisungen ausgeführt hat.
Abbildung 25: Bericht über Datenbank-DML-Details
50
Verwenden der richtlinienbasierten Verwaltung zum Definieren,
Bereitstellen und Überprüfen von Richtlinien
Bisher wurde in diesem SDK gezeigt, wie Sicherheit, Identität, Verschlüsselung und
Überwachung verwaltet werden, um gesetzliche Vorschriften oder Richtlinien einzuhalten. In
diesem Abschnitt werden Beispiele für die Verwendung der richtlinienbasierten Verwaltung
bereitgestellt, um zu überprüfen, ob jeder dieser Bereiche ordnungsgemäß entsprechend der
Richtlinie konfiguriert wurde.
Struktur der richtlinienbasierten Verwaltung
Die richtlinienbasierte Verwaltung bildet den Computer, die Datenbank und Datenbankobjekte
als hierarchische Struktur von verwalteten Zielen mit geschachtelten Zieltypen ab. Die
richtlinienbasierte Verwaltung erlaubt die Definition von Kategorien, die auf eine Gruppe von
Richtlinien zeigen. Jede Richtlinie umfasst eine einzelne Bedingung, die zum Überprüfen der
Richtlinie verwendet wird. Jede Bedingung enthält einen Ausdruck, der aus
Ausdrucksklauseln besteht. Jede Richtlinie kann auf eine Datenbank oder auf ein
Datenbankobjekt, z. B. Benutzer, Tabelle oder gespeicherte Prozedur, ausgerichtet sein. In
Abbildung 26 sehen Sie ein Diagramm dieser Konzepte. Weitere Informationen zu den
Kategorien, Ausdrücken, Facets, Richtlinien und Zielen der richtlinienbasierten Verwaltung
finden Sie unter Verwalten von Servern mit der richtlinienbasierten Verwaltung.
Sie können bei Bedarf einen eigenen Satz von Richtlinien definieren. Als Einstieg können Sie
den Satz von Richtlinien verwenden, der im Lieferumfang von SQL Server 2008 enthalten ist.
Eine Beschreibung der Richtlinien finden Sie hier.
Abbildung 26: Objekte der richtlinienbasierten Verwaltung und ihre Beziehungen
Category
Audit
Certificate
Policy
Policy
Policy
Condition
Condition
Condition
Expression 1
Expression 2
:
Expression n
Expression 1
Expression 2
:
Expression n
Expression 1
Expression 2
:
Expression n
Table
Target
Database
:
Server
51
Richtlinienbasierte Verwaltung – Beispiel
Um der richtlinienbasierten Verwaltung eine Gruppe datenbankbezogener Richtlinien
zuzuordnen, beginnen Sie mit dem Erstellen einer Kategorie, um den Bereich der
Vorschriften oder Richtlinien darzustellen, die im Unternehmen verwaltet werden sollen.
Erstellen Sie beispielsweise eine Kategorie namens PCI, wenn dies ein Standard ist, der im
Unternehmen befolgt werden soll. Erstellen Sie als Nächstes einen Satz von Richtlinien für
die richtlinienbasierte Verwaltung, um jede der gesetzlichen Richtlinien zu erfüllen, die Sie
automatisieren möchten und können. Definieren Sie die Bedingungen, die zum Überprüfen
der einzelnen Richtlinien erforderlich sind, und wenden Sie diese auf die Datenbanken an,
die dem PCI-Standard unterliegen. Abbildung 27 zeigt, wie die richtlinienbasierte Verwaltung
für PCI konfiguriert werden könnte.
Abbildung 27: Richtlinienbasierte Verwaltung – Beispiel
PCI
PCI DB1
PCI DB2
Access
Policy
Encryption
Policy
Key
Policy
Limit Access
Encrypt Data
Manage Keys
sa disabled
limit DB users
:
audit DB access
encryption enabled
keys rotated
keys copied
:
log key access
PCI DB3
Target
PCI DB4
log flag access
:
PCI DBn
Überwachen der Richtlinien der richtlinienbasierten Verwaltung
Jede Richtlinie der richtlinienbasierten Verwaltung kann überwacht werden, um die
Einhaltung der Richtlinie sicherzustellen. Eine Richtlinie kann auf Grundlage eines Zeitplans
überwacht werden oder nur bei einer Änderung des Ziels, für das die Richtlinie erstellt wurde,
jedoch nicht beides gleichzeitig. Beide Formen der Überwachung sind erforderlich, um
sicherzustellen, dass eine Richtlinie über einen bestimmten Zeitraum erzwungen wurde und
dass sich die Bedingungen zwischen den geplanten Prüfungen nicht geändert haben.
Erstellen Sie hierzu für jede gesetzliche Richtlinie, die durch die richtlinienbasierte
Verwaltung dargestellt werden soll, zwei Gruppen von Richtlinien.
Verwenden der richtlinienbasierten Verwaltung zur Einhaltung gesetzlicher
Bestimmungen
Vom Standpunkt der Kompatibilität aus können Sie mit den Funktionen "Nach Zeitplan" oder
"Bedarfsgesteuert" der richtlinienbasierten Verwaltung regelmäßige Integritätsprüfungen
durchführen, um festzustellen, wer oder was gegen die Richtlinien oder Best Practices
verstößt. Mit der Option Bei Änderung: Verhindern können Sie Benutzer daran hindern, die
52
Änderung tatsächlich vorzunehmen. Wenn Sie die Option Bei Änderung: Nur
protokollieren auswählen, darf die Änderung stattfinden, aber die Aktion wird protokolliert.
Erstellen eines Plans
Wie Sie das Erstellen von Richtlinien planen, hängt grundsätzlich von den
Geschäftsrichtlinien, Best Practices und den IT-Standards ab. Im Folgenden finden Sie einige
Beispiele für Richtlinien:
 Benennungskonventionen: Verwenden bestimmter Benennungskonventionen für
Datenbankobjekte (beispielsweise müssen gespeicherte Prozeduren der
Benutzeroberfläche das Präfix "usp" aufweisen).
 Keine Benutzerobjekte in Systemdatenbanken: Sicherstellen, dass keine
Benutzerobjekte aus Versehen in den master-, msdb- und tempDB-Datenbanken
gespeichert wurden.
 Datenbanksicherung ist aktuell: Aus betrieblichen Überlegungen kann es
notwendig sein, dass stets aktuelle Sicherungen (z. B. der letzten 24 Stunden)
vorhanden sind.
 Standarddatenbankeigenschaften: Mit dieser Richtlinie kann sichergestellt werden,
dass Datenbankeigenschaften wie "Automatische Verkleinerung" und "Automatisch
schließen" deaktiviert sind. Oder es kann sichergestellt werden, dass "Automatische
Vergrößerung" ordnungsgemäß konfiguriert ist, damit die Datenbankgröße nicht
ständig zunimmt und der Speicherplatz knapp wird.
 Dienstkonten überprüfen: Sicherstellen, dass Datenbankdienste, beispielsweise der
SQL Server-Agent, das richtige Dienstkonto verwenden.
 Anmeldestandards: In gemischten Umgebungen erstellen viele Anbieter
Anmeldenamen für ihre Anwendungen (z. B. aus zwei Zeichen bestehende
Anmeldenamen). Sie können auch Richtlinien entwickeln, die auf diesen Typ der
Erstellung prüfen.
 sysadmin-Überprüfung: Sicherstellen, dass der Serverrolle sysadmin die richtigen
Mitglieder zugewiesen sind und dass das sa-Konto deaktiviert ist.
Dies sind einige Beispiele für die Typen von Richtlinien, die Sie erstellen können. Wie Sie
sehen, sind die Möglichkeiten zahlreich und vielfältig. Um die Richtlinienerstellung jedoch
korrekt auszuführen, müssen Sie zunächst IT-Standards und Best Practices entwickeln und
verstehen. Darauf aufbauend müssen Sie die Typen von Richtlinien, die Sie bereitstellen
möchten, kategorisieren und nach Rang ordnen.
53
Kategorie
Rang
Vorgänge
1
Richtlinie
Sicherstellen, dass die
Datenbanksicherung aktuell ist
2
Sicherstellen, dass
Zertifikatsicherungen aktuell
sind
…
…
28
Sicherstellen, dass sich der
Datenordner auf Laufwerk "H:\"
befindet
Benennungskonventionen 1
Sicherstellen, dass der
Datenbankname weniger als
50 Zeichen umfasst
2
Sicherstellen, dass der
Datenbankname keine
Leerzeichen enthält
3
Sicherstellen, dass die
Datenbankrollen …
…
…
40
Sicherstellen, dass die Namen
der gespeicherten Prozeduren
nicht die Zeichenfolge "foo"
enthalten
Tabelle 4: Richtlinienrangfolge nach Kategorie
Ausführungsmodus
Nach Zeitplan
Nach Zeitplan
…
Bedarfsgesteuert
Nach Zeitplan
Nach Zeitplan
Bei Änderung:
Verhindern
…
Bedarfsgesteuert
Entwickeln Sie eine Tabelle mit möglichen und vorhandenen Richtlinien, die Sie bei der
Planung der Richtlinienstrategie heranziehen können. In dieser Tabelle ist aufgeführt, welche
Richtlinien bereits erstellt wurden. Anhand dieser Informationen können Sie unnötige
Richtlinien vermeiden und sicherstellen, dass Richtlinien nicht in Konflikt stehen oder sich
überschneiden. Außerdem hilft Ihnen die Tabelle dabei, neue Richtlinien zu identifizieren und
zu priorisieren.
Welche Richtlinien möchten Sie basierend auf dem Plan erstellen?
Wie oben angegeben, besteht ein Zweck des Richtlinienplans darin, die Priorität der
Richtlinien zu ermitteln. Basierend auf diesem Richtlinienplan können Sie Ihren Plan erstellen
und dann schrittweise neue Richtlinien bereitstellen.
Der Grund für diesen schrittweisen Ansatz ist, dass Sie zunächst die Auswirkung der
Richtlinien auf das System kennen lernen müssen. Wenn Sie zunächst nur mit wenigen
Richtlinien beginnen, ist die Auswirkung auf das System vernachlässigbar. Wenn Sie aber im
Laufe der Zeit Hunderte von Richtlinien entwickeln, die zur gleichen Zeit ausgeführt werden,
treten Ressourcenkonflikte auf. Dabei wollten Sie anhand der Richtlinien jedoch lediglich
prüfen, ob ein Verstoß gegen die Best Practices oder IT-Standards stattgefunden hat. Aus
diesem Grund ist es wichtig, eine Rangfolge für die Richtlinien festzulegen.
54
Bestimmen des Ausführungsmodus für Ihre Richtlinien
Gemäß dem obigen Plan müssen Sie für jede Richtlinie den Typ der Erzwingung festlegen.
Möglicherweise möchten Sie die Richtlinien "nach Zeitplan" ausführen, um regelmäßig auf
Richtlinienverstöße zu prüfen. Beachten Sie jedoch, dass sich diese
Richtlinienüberprüfungen negativ auf die Leistung der Server auswirken. Daher sollten Sie
Richtlinienänderungen immer testen, um zu verstehen, wie die Leistung durch Hinzufügen
von Richtlinien beeinträchtigt werden kann.
Unterscheiden Sie daher zwischen den Richtlinien, die wirklich nach einem Zeitplan
ausgeführt werden müssen, und denen, die je nach Bedarf ausgeführt werden können. Es ist
beispielsweise nicht sinnvoll, regelmäßig zu prüfen, ob Datenbanksicherungen und
Zertifikatschlüsselsicherungen aktuell sind. Sie können aber beispielsweise die
Richtlinienprüfung für den Speicherort des SQL Server-Datenordners bedarfsgesteuert
durchführen (um z. B. sicherzustellen, dass dieser sich auf Laufwerk "H:\" befindet).
Währenddessen ist es möglich, dass ein Benutzer versucht, eine einzelne Datenbankrolle zu
erstellen – in diesem Fall können Sie eine Richtlinie erstellen, die Benutzer daran hindert,
diese Änderung vorzunehmen. Oder wenn Sie die Änderung zulassen möchten, können Sie
anfordern, dass die Änderung zumindest protokolliert wird (mit der Option Bei Änderung Nur protokollieren), damit Sie die vorgenommenen Änderungen nachverfolgen können.
Tabelle 5 zeigt die verschiedenen Ausführungsmodi, die vom Richtlinien-Facet abhängen. In
der Tabelle werden folgende Ausführungsmodi dargestellt: Prüfung "Bei Änderung:
Verhindern" (Check on Change Prevent, CoC: Prevent), Prüfung "Bei Änderung: Nur
protokollieren" (Check on Change Log, CoC: Log) und Prüfung "Nach Zeitplan" (Check on
Schedule, CoS). Weitere Informationen darüber, welche Ausführungen für welche Facets
anwendbar sind, finden Sie unter Richtlinienbasierte Verwaltung für SQL Server: Facets.
Facet-Name
CoC:
Prevent
CoC:
Log
CoS
Anwendungsrolle
Asymmetrischer Schlüssel
Überwachung
Sicherungsmedium
Broker-Priorität
Broker-Dienst
Zertifikat
Anmeldeinformationen
Kryptografieanbieter
Datendatei
Datenbank
DatenbankÜberwachungsspezifikation
DDL-Trigger auf Datenbankebene
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
55
Datenbankwartung
Datenbankoption
Datenbankleistung
Datenbankrolle
Datenbanksicherheit
Standardwert
Endpunkt
Dateigruppe
Volltextkatalog
Volltextindex
Volltext-Stoppliste
Index
Verbundener Server
Protokolldatei
Anmeldung
Anmeldeoptionen
Nachrichtentyp
Mehrteiliger Name
Name
Partitionsfunktion
Partitionsschema
Planhinweisliste
Remotedienstbindung
Ressourcenkontrolle
Ressourcenpool
Regel
Schema
Server
Serverüberwachung
Serverüberwachungsspezifikation
Serverkonfiguration
DDL-Trigger auf Serverebene
Serverinformationen
Serverleistung
Serversicherheit
Servereinstellungen
Serversetup
Dienstvertrag
Dienstwarteschlange
Dienstroute
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
56
Statistik
Gespeicherte Prozedur
X
X
Oberfläche
X
Oberfläche für AS
Oberfläche für RS
Symmetrischer Schlüssel
Synonym
Tabelle
Tabellenoptionen
X
X
Trigger
Benutzer
Benutzerdefiniertes Aggregat
Benutzerdefinierter Datentyp
Benutzerdefinierte Funktion
X
X
Benutzerdefinierter Tabellentyp
Benutzerdefinierter Typ
Benutzeroptionen
X
X
Ansicht
Ansichtsoptionen
X
X
Arbeitsauslastungsgruppe
X
X
XML-Schemaauflistung
Tabelle 5: Facet-Unterstützung – Ausführungstyp
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Verwenden der richtlinienbasierten Verwaltung zum Implementieren von KPIs und KRIs
Leistungskennzahlen (Key Performance Indicators, KPIs) und Risikokennzahlen (Key Risk
Indicators, KRIs) werden von vielen Geschäftsleuten verwendet, um sicherzustellen, dass ihr
Unternehmen ordnungsgemäß geführt wird. Die richtlinienbasierte Verwaltung kann
verwendet werden, um KPIs und KRIs für die SQL Server-Datenbank zu erstellen. Erstellen
Sie zuerst eine Kategorie für die richtlinienbasierte Verwaltung, um die Gruppe von KPIs und
KRIs darzustellen, die Sie erstellen möchten. Erstellen Sie als Nächstes eine Gruppe von
Richtlinien, mit denen sichergestellt werden kann, dass sich die KPIs und KRIs im zulässigen
Bereich befinden. Hilfe beim Erstellen von Richtlinien für die richtlinienbasierte Verwaltung
finden Sie in diesem Lernprogramm.
57
Die richtlinienbasierte Verwaltung stellt Facets zur Verfügung, um Sie beim Erstellen von
KPIs wie Datenbankleistung, Serverleistung, Ressourcenpool und Planhinweisliste zu
unterstützen. Nachdem Sie die Richtlinien erstellt haben, sollten Sie diese wie jeweils
erforderlich überwachen. Sie können auch konfigurieren, dass Sie benachrichtigt werden,
wenn die Werte außerhalb der normalen Betriebsbereiche liegen.
Verwenden der richtlinienbasierten Verwaltung zum Überprüfen der
Überwachungskonfiguration
Die richtlinienbasierte Verwaltung kann verwendet werden, um zu überprüfen, ob die
Überwachung auf den Servern ordnungsgemäß konfiguriert wurde. Anhand dieser Richtlinien
kann geprüft werden, ob Datenbank- und Serverüberwachungsspezifikationen vorhanden
sind und ob diese aktiviert sind.
Hinweis:
Wie oben im Abschnitt Überwachen sensibler Vorgänge angegeben, gibt es
verschiedene Stufen der Sensitivität, und nicht alle Benutzer oder Objekte
müssen überwacht werden. Daher muss im Richtlinienplan berücksichtigt werden,
dass einige Richtlinien auf bestimmte Systeme zutreffen und andere nicht.
Beispielsweise muss die Überwachung für Server, die private persönliche
Informationen enthalten, aktiviert werden, um sicherzustellen, dass alle Aktionen
verfolgt wurden. Aber bei Servern, die allgemeine Informationen bereitstellen,
müssen ggf. nur die sysadmin-spezifischen Aktionen überwacht werden. Im
letzteren Fall wäre es nicht sinnvoll, mit einer Richtlinie sicherzustellen, dass alle
Aktionen verfolgt wurden, da dies keine nützlichen Informationen liefert.
Verwenden der richtlinienbasierten Verwaltung zum Überprüfen der
Verschlüsselungskonfiguration
Eine weitere gute Möglichkeit zum Verfolgen des Systemzustands ist das Erstellen von
Richtlinien, die sicherstellen, dass die Verschlüsselung aktiv ist. Genauso wie bei der
Überwachung treffen die Richtlinien möglicherweise nicht auf alle verfügbaren Server zu. Für
Server mit privaten Informationen ist eine Verschlüsselung erforderlich, und mithilfe von
Richtlinien muss überprüft werden, ob die Verschlüsselung aktiv ist. Aber für Server, die
allgemeine und nicht vertrauliche Daten enthalten, muss weder die Verschlüsselung aktiviert
werden noch sind entsprechende Richtlinien erforderlich. Einige Richtlinienbereiche
umfassen folgende Prüfungen:





Sicherstellen, dass die transparente Datenverschlüsselung für die relevanten
Datenbanken aktiviert wurde (diese Prüfung wird z. B. für Datenbanken ausgeführt,
die nur persönliche Informationen enthalten).
Sicherstellen, dass die Sicherung der Datenbank auch verschlüsselt ist.
Sicherstellen, dass die Verschlüsselungsschlüssel regelmäßig (z. B. monatlich)
gewechselt wurden.
Sicherstellen, dass die Schlüssel gesichert wurden.
Sicherstellen, dass sich die Schlüsselsicherung an zentraler Stelle befindet.
58

Beschränken des Zugriffs auf Verschlüsselungsschlüssel.
Bereitstellen von Richtlinien
Es gibt verschiedene Methoden, um Richtlinien für mehrere Server bereitzustellen. Eine
Methode ist die Verwendung eines zentralen Verwaltungsservers, auf dem alle Richtlinien
gespeichert werden. Diese Richtlinien können dann im Dateiformat nach einem
freigegebenen Speicherort exportiert werden.
Abbildung 28: Exportieren einer Richtlinie
59
Wenn Sie Richtlinien aus SQL Server Management Studio importieren möchten, können Sie
den Viewer "Registrierte Server" verwenden und diese Richtlinien für die gesamte Gruppe
importieren, so wie in Abbildung 29 gezeigt.
Abbildung 29: Importieren einer Richtlinie
Sie können auch Windows PowerShell™-Skripts programmgesteuert verwenden, um
Richtlinien bereitzustellen, so wie in Bereitstellen von Richtlinien für die richtlinienbasierte
Verwaltung mithilfe von PowerShell gezeigt:
60
Erstellen von Berichten zur richtlinienbasierten Verwaltung
Auch bei Verwendung der Berichterstellungsinfrastruktur für Überwachungen wird empfohlen,
einen zentralen Ort zu verwenden, damit Sie die Ausführung und den Zustand aller
Serverrichtlinien prüfen können. Auf diese Weise können Sie den Zustand der
Serverumgebung von einem zentralen Ort aus überwachen.
Abbildung 30: Zentrale Sammlung von Richtlinieninformationen
w
Vie orts
p
Re
SQLAudit
Central Server
Obtain Server
List
Extract Policy
Data
Server 1
to
t Logs
Extrac are
filesh
Server 2
Load Policy Data
Policy Extract
Server n
Wie in Abbildung 30 dargestellt, können Sie den zentralen SQLAudit-Server als Hub zum
Sammeln von Richtlinieninformationen verwenden. Der Prozess (das folgende Skript ist ein
PowerShell-Skript) ruft zunächst eine Liste der Server ab, die auf die Richtliniendaten
zugreifen müssen. Anschließend können die Daten aus den erforderlichen Tabellen extrahiert
und in einer Dateifreigabe gespeichert werden. Diese Daten können dann auf den zentralen
SQLAudit-Server geladen werden, um über diesen Server Berichte anzuzeigen.
61
Anzeigen aller Richtlinien
Wie Sie im Bericht in Abbildung 31 sehen können, können Sie alle Richtlinien anzeigen, die
in allen Serverinstanzen vorhanden sind, einschließlich Ausführungsmodus, Facets,
Richtlinien und Bedingungen.
Abbildung 31: Richtlinienbericht für die richtlinienbasierte Verwaltung
Von hier aus können Sie einen Drilldown zu den Details ausführen, wenn Sie beispielsweise
die "Ausgewertete Richtlinie" der "Testrichtlinie mit vielen Verletzungen" für den
Serverinstanznamen "Caregroup" am 18.06.2008 anzeigen möchten.
Abbildung 32: Detaillierter Richtlinienbericht für die richtlinienbasierte Verwaltung
62
In Abbildung 32 können Sie sehen, dass der Bericht der Richtlinienauswertung nur Fehler
enthält. Dies ist darauf zurückzuführen, dass die richtlinienbasierte Verwaltung
standardmäßig nur Fehlereignisse aufzeichnet. Um sowohl erfolgreiche als auch gescheiterte
Ereignisse (Fehlerereignisse) aufzuzeichnen, legen Sie den Parameter LogOnSuccess der
Richtlinienverwaltungseigenschaften auf TRUE fest, so wie in Abbildung 33 dargestellt. Mit
dem LogOnSuccess-Parameter wird bestimmt, ob die richtlinienbasierte Verwaltung
erfolgreiche Richtlinienauswertungen protokolliert.
Abbildung 33: Richtlinienverwaltungseigenschaften
63
Nützliche Skripts und Tipps
In diesem Abschnitt werden eine Reihe nützlicher Skripts und Tipps bereitgestellt, die Sie bei
der Entwicklung von Kompatibilitätslösungen für kommerzielle Anwendungen oder
Unternehmensanwendungen unterstützen. Jedes dieser Skripts ist im Kompatibilitäts-SDK
enthalten. Gegebenenfalls ist der Name der Datei, die das Skript enthält, im Titel angegeben.
Programmierschnittstellen zu SQL Server
SQL Server stellt mehrere Programmierschnittstellen bereit. Dieser Abschnitt bietet eine
Übersicht über die drei Programmierschnittstellen, die in diesem Abschnitt verwendet
werden: SQL Server Management Objects (SMO), Transact-SQL und Windows PowerShell.
SMO
SQL Server Management Objects (SMO) steht für eine Auflistung von Objekten, die zum
Programmieren aller Aspekte der Microsoft SQL Server-Verwaltung vorgesehen sind. Sie
können SMO verwenden, um benutzerdefinierte SQL Server-Verwaltungsanwendungen zu
erstellen. Das SMO-Objektmodell erweitert und ersetzt das SQL-DMO-Objektmodell (SQL
Distributed Management Objects). Verglichen mit SQL-DMO bietet SMO eine bessere
Leistung, Steuerung und Benutzerfreundlichkeit. SMO unterstützt die meisten SQL-DMOFunktionen und enthält verschiedene neue Klassen zur Unterstützung neuer Features in SQL
Server.
Transact-SQL
Die Sprache Transact-SQL wird traditionell zum Erstellen von Schnittstellen zu SQL Server
verwendet. Bei allen Anwendungen erfolgt die Kommunikation mit einer Instanz von
SQL Server über das Senden von Transact-SQL-Anweisungen an den Server. Dabei spielt
die Benutzeroberfläche der Anwendung keine Rolle. Entwickler, die Datenbankanwendungen
erstellen möchten, sollten sich mit dieser Sprache vertraut machen.
Windows PowerShell
Windows PowerShell ist eine Befehlszeilenshell und Skriptsprache, die IT-Spezialisten eine
bessere Kontrolle und eine Steigerung ihrer Produktivität ermöglicht. Windows PowerShell
bietet eine neue, auf Administratoren ausgerichtete Skriptsprache, über 130 standardmäßige
Befehlszeilentools sowie konsistente Syntaxregeln und Hilfsprogramme für einfache
Systemverwaltung und schnellere Automatisierung. Windows PowerShell ist jetzt im
Lieferumfang von Windows Server 2008 enthalten. Informationen für einen schnellen Einstieg
in das Skripting finden Sie in der Windows PowerShell Quick Reference.
In mehreren Beispielen in diesem Abschnitt werden PowerShell-Skripts verwendet.
Informationen zum Verwenden von PowerShell mit SQL Server finden Sie hier. Sie können
sich auch ein Video mit Tipps und Tricks für SQL Server PowerShell ansehen.
Hinweis:
Die erstmalige Ausführung von PowerShell-Skripts kann schwierig sein. Stellen
Sie zuerst sicher, dass Sie das Hilfsprogramm SQLPS ausführen, um PowerShell
zu starten, und nicht POWERSHELL. Wenn Sie weitere Hilfe benötigen, lesen Sie
die Informationen im Abschnitt Ausführen von Windows PowerShell-Skripts.
64
VBScript
Microsoft Visual Basic® Scripting Edition (VBScript) ermöglicht aktives Skripting in einer
großen Vielzahl von Umgebungen, einschließlich Webclientskripting in Microsoft Internet
Explorer® und Webserverskripting in Microsoft Internetinformationsdienste (IIS). Mit VBScript
können Sie Anwendungen erstellen, die auf SQL Server zugeschnitten sind. Unter Script
Repository: SQL Server finden Sie ein Skriptrepository mit Dutzenden von Beispielen für
SQL Server.
Windows Data Access Components
Windows Data Access Components ist eine Gruppe von Technologien, die Zugriff auf
Informationen im gesamten Unternehmen bieten. Diese Technologien umfassen
Microsoft ActiveX® Data Objects (ADO), OLE DB und Microsoft Open Database Connectivity
(ODBC). Datengesteuerte Client/Server-Anwendungen, die über das Web oder ein LAN
bereitgestellt werden, können diese Komponenten verwenden, um Informationen aus einer
SQL Server-Datenbank auf einfache Weise zu integrieren.
65
Sicherstellen der Sicherheitseinstellungen ("Server Security
Policy.xml")
Im Abschnitt zum Verwenden der Windows-Authentifizierung wird erläutert, wie wichtig es ist,
den Windows-Authentifizierungsmodus zur Serverauthentifizierung zu verwenden. Sie
können dies manuell in SQL Server Management Studio konfigurieren, indem Sie den Modus
auf der Seite Sicherheit unter Servereigenschaften auswählen, so wie in Abbildung 34
gezeigt. Mit der richtlinienbasierten Verwaltung können die meisten Servereinstellungen
überwacht werden. Die Datei "Server Security Policy.xml" enthält ein Beispiel, das die
Vorgehensweise veranschaulicht.
Abbildung 34: Sicherheitseigenschaften für Server
66
Die Windows-Authentifizierung ist ein Beispiel für eine Sicherheitseinstellung, die verwendet
werden kann, um den Zugriff auf sensible Daten zu beschränken. Mit der richtlinienbasierten
Verwaltung können Datenbankadministratoren Richtlinien erstellen, um sicherzustellen, dass
bestimmte Sicherheitseinstellungen und andere Einstellungen ordnungsgemäß konfiguriert
und verwaltet werden. Im Allgemeinen ist das Erstellen einer Richtlinie für die Einstellungen
eines Objekts ganz einfach. Sie müssen lediglich mit der rechten Maustaste auf das Objekt
und dann auf Facet klicken. Sie können hierzu auch auf das Menü Facets zugreifen,
nachdem Sie mit der rechten Maustaste auf das Serverobjekt geklickt haben. Abbildung 35
zeigt ein Beispiel:
Abbildung 35: Auswählen von Facets für das Serverobjekt
67
Im Dialogfeld Facets anzeigen, das in Abbildung 36 dargestellt wird, werden die für das
ausgewählte Objekt verfügbaren Facets und die Einstellungen der Facets angezeigt.
Abbildung 36: Dialogfeld mit Serverfacets für die richtlinienbasierte Verwaltung
Verwalten der Aufgabentrennung ("SOD Policy.xml")
Mit der Richtliniendatei "SOD Policy.xml" wird sichergestellt, dass das sa-Konto umbenannt
und deaktiviert wurde. Es wird überprüft, ob nur bestimmte Benutzer und Dienstkonten der
Rolle sysadmin hinzugefügt wurden. Außerdem wird sichergestellt, dass Benutzer nur einer
Rolle zugewiesen werden. Im weiteren Verlauf dieses Abschnitts wird gezeigt, wie Sie diese
Funktionen manuell ausführen können. Diese Richtlinie enthält zwei Skripts, die die
Flexibilität von Ausdrücken der richtlinienbasierten Verwaltung veranschaulichen.
68
Hinweis:
Wenn Sie Skripts als Teil einer Richtlinienbedingung einfügen, wird im Dialogfeld
Richtlinien auswerten neben der Richtlinie ein Warnsymbol angezeigt. Zudem
wird oben im Dialogfeld eine Warnmeldung angezeigt, so wie in Abbildung 37
gezeigt. Das Einschließen von Skripts verhindert auch, das Skripts automatisch
von SQL Server Management Studio ausgewertet werden. Durch Klicken auf die
Schaltfläche Auswerten wird die Richtlinienauswertung jedoch zugelassen.
Abbildung 37: Richtlinie mit hervorgehobenen Skripts im Dialogfeld Richtlinien
auswerten
Verwenden von Skripts in Bedingungen
Das Verwenden von Skripts ist eine der leistungsstärkeren Möglichkeiten, um eine Bedingung
für die richtlinienbasierte Verwaltung zu konfigurieren. Das folgende Skript wird von der
Bedingung zum Überprüfen von Rollen in der Richtlinie zur Aufgabentrennung verwendet.
IsNull(ExecuteSql('Numeric',
'SELECT COUNT(DISTINCT name)
FROM sys.server_role_members,
sys.server_principals
WHERE principal_id = member_principal_id
AND role_principal_id
IN (SUSER_ID (''sysadmin''),
SUSER_ID (''bulkadmin''),
SUSER_ID (''securityadmin''))
GROUP BY name
HAVING COUNT(member_principal_id)> 1 '), 0)
Die Funktion ExecuteSQL erlaubt das Einbetten einer SELECT-Anweisung in einen
Ausdruck der richtlinienbasierten Verwaltung. Diese SELECT-Anweisung bestimmt, ob ein
Benutzer Mitglied von mehr als einer der aufgelisteten Sicherheitsrollen ist. Wenn dies zutrifft,
wird ein Wert größer als Null zurückgegeben, sodass die Bedingung scheitert. Die Liste der
Rollen kann bei Bedarf geändert werden. Rollennamen sollten in Anführungszeichen gesetzt
69
werden, da die SELECT-Anweisung in Apostrophe eingebettet ist. Die Funktion IsNull wird
verwendet, um eine numerische Rückgabe zu erzwingen, falls das Resultset NULL ist.
Deaktivieren aller sysadmin-Konten ("ManageSA.sql")
Das Deaktivieren aller sysadmin-Konten stellt eine sichere Methode dar, um zu verhindern,
dass privilegierte Benutzer auf Daten und Vorgänge zugreifen, auf die sie nicht zugreifen
sollten. Normalerweise ist es keine gute Idee, alle sysadmin-Konten zu deaktivieren, da nur
ein sysadmin ein Konto erneut aktivieren kann. Falls dies geschieht, könnte ein sysadminKonto erneut aktiviert werden, indem die Datenbank heruntergefahren und im
Einzelbenutzermodus gestartet wird. Der folgende Code veranschaulicht, wie alle sysadminKonten deaktiviert werden können.
USE master
GO
CREATE PROCEDURE sp_DisableSA AS
IF (DB_ID() = 1)
BEGIN
DECLARE @cmd nvarchar(max)
-- SID 0x01 ist immer "sa"
SET @cmd = N'ALTER LOGIN ' + QUOTENAME(SUSER_NAME(0x01)) +
N' DISABLE'
EXEC ( @cmd )
END
ELSE
BEGIN
RAISERROR ('sp_DisableSA is only valid when hosted in master DB',
-- Meldungstext.
16, -- Schweregrad.
1 -- Status.
);
END
GO
CREATE PROCEDURE sp_EnableSA AS
IF (DB_ID() = 1)
BEGIN
DECLARE @cmd nvarchar(max)
-- SID 0x01 ist immer "sa"
SET @cmd = N'ALTER LOGIN ' + QUOTENAME(SUSER_NAME(0x01)) +
N' ENABLE'
EXEC ( @cmd )
END
ELSE
BEGIN
RAISERROR ('sp_EnableSA is only valid when hosted in master DB',
-- Meldungstext.
16, -- Schweregrad.
1 -- Status.
);
END
GO
70
-- Zertifikat zum Signieren der gespeicherten Prozedur erstellen
CREATE CERTIFICATE SACert WITH SUBJECT = 'For signing stored
procedures'
GO
-- Anmeldung zum Ausführen der gespeicherten Prozedur zulassen
GRANT EXECUTE ON sp_DisableSA TO [SQLVM03-18158EA\Pat];
-- Gespeicherte Prozedur signieren
ADD SIGNATURE TO sp_DisableSA BY CERTIFICATE SACert;
-- Zertifikatbasierte Anmeldung erstellen
CREATE LOGIN [CertLogin] FROM CERTIFICATE SACert;
-- Anmeldung der sysadmin-Rolle hinzufügen, damit das sa-Konto
-- von der gespeicherten Prozedur deaktiviert werden kann
EXEC sp_addsrvrolemember [CertLogin], N'sysadmin';
-- Privaten Schlüssel entfernen, damit die gespeicherte Prozedur
nicht erneut signiert werden kann
ALTER CERTIFICATE [SACert] REMOVE PRIVATE KEY;
-- Serverüberwachungsspezifikation ändern, um die Nutzung der
-- gespeicherten Prozedur bei Bedarf nachzuverfolgen. Sicherstellen,
dass die Überwachungsspezifikation
-- deaktiviert ist, bevor der ALTER-Befehl ausgeführt wird.
ALTER SERVER AUDIT SPECIFICATION [Audit Login Changes]
WITH (STATE = OFF)
GO
ALTER SERVER AUDIT SPECIFICATION [Audit Login Changes]
ADD (SERVER_PRINCIPAL_CHANGE_GROUP)
GO
ALTER SERVER AUDIT SPECIFICATION [Audit Login Changes]
WITH (STATE = ON)
GO
Überprüfen des sa-Kontos ("ValidateSA.sql")
Die Bedingung zum Überprüfen von Rollen kann verwendet werden, um zu überprüfen, ob
das sa-Konto umbenannt und deaktiviert wurde. Das folgende Skript veranschaulicht die
manuelle Durchführung dieser Aufgabe.
IF (SELECT COUNT(*)
FROM sys.server_principals
WHERE = principal_id 1
AND is_disabled = 1
AND name != 'sa') = 1
PRINT 'Compliant'
ELSE
PRINT 'Non-compliant'
71
Überprüfen der sysadmin-Rollenmitgliedschaft ("ValidateSysadmins.sql")
Mit der Bedingung zum Überprüfen von Rollen in der Richtliniendatei "SOD Policy.xml" kann
überprüft werden, ob nur die dafür vorgesehenen Benutzer Mitglied der Rolle sysadmin sind.
Das folgende Skript veranschaulicht die manuelle Durchführung dieser Aufgabe.
DECLARE
DECLARE
DECLARE
DECLARE
SET
SET
SET
SET
@Admin1
@Admin2
@Admin3
@Admin4
@Admin1
@Admin2
@Admin3
@Admin4
=
=
=
=
sysname
sysname
sysname
sysname
@@SERVERNAME + '\Pat'
'NT AUTHORITY\SYSTEM'
'NT AUTHORITY\NETWORK SERVICE'
'sa'
IF EXISTS (SELECT name
FROM sys.server_role_members A,
sys.server_principals B
WHERE A.member_principal_id = B.principal_id
AND role_principal_id = SUSER_ID('sysadmin')
AND name NOT IN (@Admin1, @Admin2,
@Admin3, @Admin4))
PRINT 'Non-compliant'
ELSE
PRINT 'Compliant'
Erzwingen der Rollentrennung ("SOD Policy.xml")
Diese Skripts überprüfen, ob ein Benutzer in mehr als einer Rolle vorhanden ist, und listen
diese Benutzer zusammen mit dem Namen der Rolle auf. Hierbei behandelt ein Satz die
Serverrollen und der andere die Datenbankrollen.
Beachten Sie, dass von SQL Server nicht einfach überwacht werden kann, wer Mitglied der
Windows-Sicherheitsgruppen ist. Jede Organisation sollte eine Richtlinie zum Verwalten der
Sicherheitsgruppenmitgliedschaft erstellen. Wenn Gruppen verwendet werden, kann von
SQL Server nicht festgestellt werden, ob eine Einzelperson aufgrund von
Gruppenmitgliedschaften mehreren SQL Server-Rollen zugewiesen ist.
72
Überwachen von Serverrollen ("ValidateServerRoles.sql")
Das Dialogfeld Anmeldungseigenschaften kann verwendet werden, um die Serverrollen
eines Benutzers anzuzeigen und zu ermitteln, ob der Benutzer Mitglied in mehr als einer
kritischen Rolle ist, so wie in Abbildung 38 gezeigt.
Abbildung 38: Dialogfeld Anmeldungseigenschaften
Die richtlinienbasierte Richtliniendatei "SOD Policy.xml" erlaubt die Überwachung von
Serverrollen, um sicherzustellen, dass ein Benutzer maximal einer Rolle zugewiesen ist,
ohne dass Sie hierzu die Rollen der einzelnen Benutzer manuell anzeigen müssen. Das
folgende Skript führt dieselbe Funktion aus. Wenn eine Anzahl größer als null zurückgegeben
wird, ist ein Benutzer Mitglied von mehreren aufgelisteten Rollen.
SELECT COUNT(*)Count
FROM sys.server_role_members, sys.server_principals
WHERE principal_id = member_principal_id
AND role_principal_id
IN (SUSER_ID('sysadmin'), SUSER_ID ('bulkadmin'),
SUSER_ID ('securityadmin'))
GROUP BY member_principal_id
HAVING COUNT(member_principal_id)> 1
73
Auflisten von Benutzern in mehreren Rollen ("ValidateServerRoles.sql")
Wenn Benutzer Mitglied mehrerer Rollen sind, listen diese Skripts den Namen der Benutzer
zusammen mit den Serverrollen auf, denen die Benutzer angehören. In diesem Beispiel
enthält das Skript nur drei Serverrollen. Die Anzahl der Rollen und die Rollenauswahl können
geändert werden, da sie sich nicht auf die Funktionsweise des Skripts auswirken.
SELECT A.Name, B.NAME Role
FROM sys.server_principals A,
sys.server_principals B,
sys.server_role_members C
WHERE A.name IN (SELECT Name
FROM sys.server_role_members,
sys.server_principals
WHERE principal_id = member_principal_id
AND role_principal_id
IN (SUSER_ID('sysadmin'),
SUSER_ID ('bulkadmin'),
SUSER_ID ('securityadmin'))
GROUP BY member_principal_id, name
HAVING COUNT(member_principal_id)> 1
)
AND A.principal_id = C.member_principal_id
AND B.principal_id = C.role_principal_id
ORDER BY Name
74
Überwachen von Datenbankrollen ("ValidateDatabaseRoles.sql")
Das Dialogfeld Datenbankbenutzer kann verwendet werden, um die Datenbankrollen eines
Benutzers anzuzeigen und zu ermitteln, ob der Benutzer Mitglied in mehr als einer kritischen
Rolle ist, so wie in Abbildung 39 gezeigt.
Abbildung 39: Datenbankrollenmitgliedschaft des Benutzers
Dieses Skript listet die Benutzer nach Name auf und gibt an, zu wie vielen der aufgelisteten
Datenbankrollen der Benutzer gehört. Das Skript sollte ein NULL-Resultset zurückgeben,
wenn kein Benutzer in mehr als einer Rolle vorhanden ist. In diesem Beispiel enthält das
Skript nur drei Datenbankrollen. Die Anzahl der Rollen und die Rollenauswahl können
geändert werden, da sie sich nicht auf die Funktionsweise des Skripts auswirken.
SELECT COUNT(member_principal_id) Count, Name
FROM sys.database_role_members,
sys.database_principals
WHERE principal_id = member_principal_id
AND role_principal_id
IN (DATABASE_PRINCIPAL_ID('db_securityadmin'),
DATABASE_PRINCIPAL_ID('db_backupoperator'),
DATABASE_PRINCIPAL_ID('db_datawriter'))
GROUP BY member_principal_id, Name
75
HAVING COUNT(member_principal_id)> 1
ORDER BY Name
Wenn Benutzer Mitglied mehrerer Rollen sind, listen diese Skripts den Namen der Benutzer
zusammen mit den Datenbankrollen auf, denen die Benutzer angehören. In diesem Beispiel
enthält das Skript nur drei Datenbankrollen. Die Anzahl der Rollen und die Rollenauswahl
können geändert werden, da sie sich nicht auf die Funktionsweise des Skripts auswirken.
SELECT A.Name, B.Name Role
FROM sys.database_principals A,
sys.database_principals B,
sys.database_role_members C
WHERE A.name IN
(SELECT Name
FROM sys.database_role_members,
sys.database_principals
WHERE principal_id = member_principal_id
AND role_principal_id
IN (DATABASE_PRINCIPAL_ID('db_securityadmin'),
DATABASE_PRINCIPAL_ID('db_backupoperator'),
DATABASE_PRINCIPAL_ID('db_datawriter'))
GROUP BY member_principal_id, name
HAVING COUNT(member_principal_id)> 1
)
AND A.principal_id = C.member_principal_id
AND B.principal_id = C.role_principal_id
ORDER BY Name
Verwalten von Verschlüsselungsschlüsseln
Datenbankadministratoren verwenden die Verschlüsselung oft, um sensible Daten zu schützen,
und behandeln erst im Nachhinein die ordnungsgemäße Verwaltung von
Verschlüsselungsschlüsseln. Zudem stellt SQL Server keine umfassenden Tools bereit, um das
Verwalten von Verschlüsselungsschlüsseln zu vereinfachen. Dieser Abschnitt enthält Anleitungen
zum Verwalten von Schlüsseln sowie Skripts, um Sie bei diesem Prozess zu unterstützen.
Überwachen des Zugriffs auf Verschlüsselungsschlüssel
("AuditCryptoActions.sql")
SQL Server Audit ermöglicht das Überwachen des Zugriffs auf Verschlüsselungsschlüssel
sowie der Verschlüsselungseinstellung für Datenbanken. Durch Überwachen der Ereignisse
DATABASE_OBJECT_ACCESS_GROUP und DATABASE_OBJECT_CHANGE_GROUP
mit einer Serverüberwachungsspezifikation kann sichergestellt werden, dass jeder Zugriff auf
die Datenbankverschlüsselungsschlüssel protokolliert wird. Durch Überwachen des
Ereignisses DATABASE_CHANGE_GROUP mithilfe einer DatenbankÜberwachungsspezifikation wird sichergestellt, dass alle Änderungen am
Verschlüsselungsflag für die Datenbank protokolliert werden.
Wenn eine Serverüberwachungsspezifikation geändert wird, um alle Datenbankobjekte
hinsichtlich Änderungen und Zugriff zu überwachen, werden dadurch nicht viele Ereignisse
protokolliert. Dies ist darauf zurückzuführen, dass nur wenige Datenbankobjekte vorhanden
76
sind, auf die nicht häufig zugegriffen wird bzw. die in stabilen Datenbanken nicht häufig
geändert werden. Unter Überwachen des Schlüsselzugriffs finden Sie eine Liste von Objekten.
Anzeigen von Zertifikaten und Schlüsseln ("ViewKeys.sql")
Zertifikate für die transparente Datenverschlüsselung müssen in der master-Datenbank
mithilfe eines Skripts erstellt werden, beispielsweise mit dem folgenden Skript. Der
Hauptschlüssel muss nur erstellt werden, wenn zuvor noch kein Hauptschlüssel erstellt
wurde. Der Hauptschlüssel ist zum Schützen des Zertifikats erforderlich.
USE master;
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'UseStrongPassword1!';
GO
CREATE CERTIFICATE MyServerCert
WITH SUBJECT = 'My DEK Certificate for Sensitive Data'
Nachdem ein Zertifikat erstellt wurde, kann es angezeigt werden, indem eine Abfrage für die
Zertifikattabelle in der master-Datenbank ausgeführt wird, so wie im Folgenden gezeigt.
USE master
SELECT name, certificate_id, start_date, thumbprint,
pvt_key_last_backup_date
FROM sys.certificates
Tabelle 6 zeigt einige wichtige Spalten aus der Zertifikattabelle. Die Spalte start_date sollte
verwendet werden, um festzustellen, wann das Zertifikat erneut erstellt werden soll. Anhand
der Spalte thumbprint kann bestimmt werden, welche Datenbanken mit dem Zertifikat
verknüpft sind. Sie ist der Spalte encryptor_thumbprint zugeordnet, die weiter unten in
diesem Abschnitt beschrieben wird. In der Spalte pvt_key_last_backup_date wird
angezeigt, wann das Zertifikat zuletzt gesichert wurde. Wenn der Wert in der Spalte NULL ist,
wurde das Zertifikat nie gesichert. Die Sicherung ist wichtig, denn falls das Zertifikat jemals
zerstört wird, können Objekte, die mit dem Zertifikat geschützt wurden (z. B.
Sicherungsbänder), nicht mehr wiederhergestellt werden.
name
NewServerCert
DEKCert_258
DEKCert_260
DEKCert_261
start_date
2008-07-20 19:43:04.000
2008-07-23 04:21:40.000
2008-07-23 04:51:55.000
2008-07-25 05:11:26.000
thumbprint
pvt_key_last_backup_date
0xBF372D91C333B1E…
NULL
0x99CF8887C56CEC9… 2008-07-23 04:50:36.553
0x8BFD5885501314B…
2008-07-23 04:51:56.490
0xC1B737DAFDCFAC… 2008-07-25 05:11:28.800
Tabelle 6: Spalten aus der Zertifikattabelle
Bevor die transparente Datenverschlüsselung für eine Datenbank aktiviert werden kann,
müssen mithilfe eines Skripts Verschlüsselungsschlüssel für die transparente
Datenverschlüsselung erstellt werden, beispielsweise mit dem folgenden Skript. Damit die
Erstellung der Verschlüsselungsschlüssel erfolgreich ist, muss zuvor ein Zertifikat erstellt
worden sein.
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
77
ENCRYPTION BY SERVER CERTIFICATE DEKCert_258
GO
Nachdem der Schlüssel erstellt wurde, kann er angezeigt werden, indem mithilfe der
dynamischen Verwaltungssicht eine Abfrage durchgeführt wird, so wie unten gezeigt.
SELECT database_id, create_date, regenerate_date,
encryptor_thumbprint
FROM sys.dm_database_encryption_keys
Tabelle 7 zeigt einige wichtige Spalten aus der Sicht. In der Spalte database_id ist die
Datenbank angegeben, für die der Schlüssel erstellt wurde. Die ID "2" steht für tempdb
(temporäre Datenbank). In der Spalte regenerate_date ist angegeben, wann der Schlüssel
zuletzt generiert wurde. Wenn der Schlüssel zum ersten Mal erstellt wird, entspricht dieser
Wert dem Wert in der Spalte create_date. Diese Spalte sollte verwendet werden, um zu
bestimmen, wann der Schlüssel erneut erstellt werden soll. Wie im Abschnitt Wechseln von
Zertifikaten oder Wechseln von Schlüsseln erläutert, ist es besser, das Zertifikat anstelle des
Verschlüsselungsschlüssels zu wechseln. Anhand der Spalte encryptor_thumbprint kann
bestimmt werden, welches Zertifikat zum Schützen des Schlüssels verwendet wird.
database_id
2
7
8
9
create_date
2008-08-20 17:46:28.110
2008-07-01 20:27:03.983
2008-07-01 20:27:04.137
2008-07-01 20:27:32.667
regenerate_date
2008-08-20 17:46:28.110
2008-08-07 16:14:36.013
2008-08-07 16:14:36.103
2008-08-07 16:14:36.213
encryptor_thumbprint
0
0xC1B737DAFDCFAC9C…
0xC1B737DAFDCFAC9C…
0xC1B737DAFDCFAC9C…
Tabelle 7: Spalten aus der Sicht "sys.dm_database_encryption_keys"
Wechseln von Zertifikaten ("RotateCerts.sql")
Mit dem folgenden Skript wird jedes Zertifikat in der aktuellen Datenbank erneut generiert.
Das Skript sollte nur für die master-Datenbank ausgeführt werden. Nur Zertifikate, die einen
Monat alt sind und zum Schützen eines Datenbankverschlüsselungsschlüssels verwendet
wurden, werden neu generiert. Die DATUMSDIFFERENZ-Funktion kann geändert werden,
um die Häufigkeit der Generierung zu ändern. Die ID des rotierten Zertifikats wird im Namen
des neuen Zertifikats verwendet, um Konflikte zu vermeiden. Nachdem das neue Zertifikat
generiert wurde, wird es verwendet, um jeden Datenbankverschlüsselungsschlüssel zu
schützen, der vom vorherigen Zertifikat geschützt wurde. Dieses Skript kann mithilfe des
SQL Server-Agents als geplanter Auftrag verwendet werden.
Hinweis:
DECLARE
DECLARE
DECLARE
DECLARE
DECLARE
Der private Schlüssel für jedes neu erstellte Zertifikat muss sobald wie möglich
mit einem sicheren Verfahren gesichert werden. Geschieht dies nicht, können
verschlüsselte Daten möglicherweise nicht wiederhergestellt werden, falls der
ursprüngliche private Schlüssel verloren geht.
@Thumbprint
@CertID
@CertName
@DB_ID
@cmd
varbinary(32)
int
sysname
int
nvarchar(max)
-- Das INSENSITIVE-Schlüsselwort verwenden, um zu verhindern, dass
-- während dieses Skripts erstellte neue Zertifikate verarbeitet werden.
78
DECLARE Certificate_Cursor INSENSITIVE CURSOR FOR
SELECT [thumbprint], [certificate_id]
FROM sys.certificates
WHERE (DATEDIFF(MONTH, [start_date], GETDATE()) > 0 )
AND [thumbprint]
IN (SELECT DISTINCT encryptor_thumbprint
FROM sys.dm_database_encryption_keys)
OPEN Certificate_Cursor;
FETCH NEXT FROM Certificate_Cursor INTO @Thumbprint, @CertID;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @CertName = 'DEKCert' + '_' + LTRIM(STR(@CertID));
SET @cmd = N'CREATE CERTIFICATE ' + QUOTENAME(@CertName) +
N' WITH SUBJECT = ''DEK Certificate'''
EXEC( @cmd )
DECLARE Database_Cursor CURSOR FOR
SELECT [database_id]
FROM sys.dm_database_encryption_keys
WHERE [encryptor_thumbprint] = @Thumbprint
OPEN Database_Cursor;
FETCH NEXT FROM Database_Cursor INTO @DB_ID;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @cmd = N'USE ' + QUOTENAME(DB_NAME(@DB_ID)) + ';' +
N'ALTER DATABASE ENCRYPTION KEY ' +
N'ENCRYPTION BY SERVER CERTIFICATE ' +
QUOTENAME(@CertName)
EXEC (@cmd);
FETCH NEXT FROM Database_Cursor INTO @DB_ID;
END
CLOSE Database_Cursor;
DEALLOCATE Database_Cursor;
FETCH NEXT FROM Certificate_Cursor INTO @Thumbprint, @CertID;
END
CLOSE Certificate_Cursor;
DEALLOCATE Certificate_Cursor;
Hinweis:
Dieses Skript scheitert, wenn es mehr als zweimal ausgeführt wird, ohne dass
das Protokoll gesichert wurde.
Sichern des privaten Zertifikatschlüssels ("BackupCerts.sql")
Dieses Skript sucht nach jedem Zertifikat, das zum Schützen eines
Datenbankverschlüsselungsschlüssels verwendet wird und nicht gesichert wurde (die Spalte
pvt_key_last_backup_date ist NULL), und sichert das Zertifikat in einer Datei im
Verzeichnis "C:\certificates". Als Dateiname wird der Name des Zertifikats mit der
Dateierweiterung ".crt" verwendet. Der private Schlüssel wird im gleichen Verzeichnis wie die
Dateierweiterung ".pvt" gesichert. Nachdem das Zertifikat gesichert wurde, sollte der private
79
Zertifikatschlüssel sofort an einem sicheren Ort verwahrt oder in einer Datenbank gespeichert
werden. Die Dateikopie sollte zerstört werden.
Hinweis:
Die Sicherung eines Zertifikats sollte nicht mit einem Skript wie dem folgenden
automatisiert werden, es sei denn, die Kennworterstellung erfolgt auf sichere
Weise. Wenn das Kennwort in einem Skript verfügbar gemacht wird, wird der
private Schlüssel dem Risiko eines unberechtigten Zugriffs ausgesetzt. Die Datei
sollte an einem sicheren Ort gespeichert oder gelöscht werden, nachdem sie in
eine sekundäre Datenbank importiert wurde. Kennwörter sollten nicht
wiederverwendet werden.
DECLARE @CertName
DECLARE @cmd
sysname
nvarchar(max)
DECLARE Cert_Cursor CURSOR FOR
SELECT [name]
FROM sys.certificates
WHERE [pvt_key_last_backup_date] IS NULL AND [thumbprint] IN
(SELECT DISTINCT [encryptor_thumbprint]
FROM sys.dm_database_encryption_keys)
OPEN Cert_Cursor;
FETCH NEXT FROM Cert_Cursor INTO @CertName;
WHILE @@FETCH_STATUS = 0
BEGIN
SET @cmd =
N'BACKUP CERTIFICATE ' + QUOTENAME(@CertName) +
N' TO FILE = ''c:\certificates\' + @CertName +
N'.crt'' WITH PRIVATE KEY ( FILE = ''c:\certificates\' +
@CertName +
N'.pvk'', ENCRYPTION BY PASSWORD = ''MyPass7779311#'');'
EXEC ( @cmd )
FETCH NEXT FROM Cert_Cursor INTO @CertName;
END
CLOSE Cert_Cursor;
DEALLOCATE Cert_Cursor;
Sicherstellen der Zertifikatrotation und -sicherung
("CertRotationPolicy.xml")
Mithilfe der richtlinienbasierten Verwaltung kann sichergestellt werden, dass Zertifikate und
Schlüssel gemäß Richtlinie in einem bestimmten Turnus gewechselt (rotiert) werden. Zudem
wird sichergestellt, dass die privaten Zertifikatschlüssel gesichert werden. Die Richtlinie der
richtlinienbasierten Verwaltung in der Datei "CetRotationPolicy.xml" enthält eine Bedingung
mit drei Skriptausdrücken, mit der sichergestellt werden kann, dass Zertifikate und Schlüssel
einmal wöchentlich rotiert werden und dass jeder private Zertifikatschlüssel gesichert wird.
80
Verwalten der Überwachung
Nachdem mithilfe von SQL Server Audit Überwachungsprotokolle gesammelt wurden,
müssen Sie diese Protokolle ggf. verarbeiten, um forensische Analysen oder Trendanalysen
durchzuführen. In diesem Abschnitt wird erläutert, wie Sie aus den erfassten Protokollen
einen größeren Nutzen ziehen können.
Übertragen von SQL Server Audit-Protokollen an eine Tabelle
("StoreAuditLogs.sql")
Protokolle aus mehreren Systemen können in einer zentralen Dateifreigabe gesammelt
werden, so wie in Abbildung 40 gezeigt. Um das Erstellen von Berichten aus den
Protokollen zu vereinfachen, müssen diese in eine Datenbanktabelle verschoben werden.
SQL Server Integration Services (SSIS) kann verwendet werden, um ein Paket zu erstellen,
das nach Zeitplan ausgeführt werden kann. Die Protokolle können entweder manuell oder mit
einem Skript verschoben werden. Nachdem die Protokolle in eine Tabelle verschoben
wurden, kann die Tabelle in Microsoft Excel® geöffnet werden, um Diagramme zu erstellen
und Trendanalysen durchzuführen. Diese Mechanismen werden im folgenden Abschnitt
beschrieben.
Abbildung 40: Übertragen von Überwachungsprotokollen an eine Datenbanktabelle
SQL Servers
Process Audit Information
Use SSIS to process SQL Server Audit log data and store in its own SQL Server
database.
SSIS
SQL Server
database
SQL Server
database
Transfer Logs
SQL Server Audit
File Server
SQL Server
database
SQL Server
database
Dieses Skript verschiebt die Ereignisse aus der SQL Server Audit-Protokolldatei in eine
Datenbanktabelle, um die Berichterstattung zu vereinfachen. Durch diese Verschiebung wird
auch verhindert, dass der Systemadministrator eines Servers, über den Ereignisse gesendet
werden, die Datei überschreibt. Hierbei müssen zwei Dinge beachtet werden:

SQL Server Audit speichert nur die Codes für die Vorgänge und Objekttypen in der
Protokolldatei. Dieses Skript verknüpft daher die Aktions- und Objekttabellen, um die
Beschreibungen einzuschließen, und speichert sie dann in der Datenbanktabelle.
81

Der Name der zuletzt gelesenen Datei und der Offset in der Datei werden in lokale
Variablen geladen und beim Lesen von Daten verwendet, damit dieselben Protokolle
nicht zweimal geladen werden.
USE Test1
GO
DECLARE
@data_path nvarchar(256),
@offset
int
SET @data_path = NULL
SET @offset = NULL
IF NOT EXISTS (SELECT * FROM sys.objects
WHERE object_id = OBJECT_ID(N'[dbo].[AuditLog]')
AND type in (N'U'))
CREATE TABLE [dbo].[AuditLog](
[event_time] [datetime2](7) NULL,
[sequence_number] [int] NULL,
[action_id] [varchar](4) NULL,
[action_name] [nvarchar](128) NULL,
[succeeded] [bit] NULL,
[permission_bitmask] [bigint] NULL,
[is_column_permission] [bit] NULL,
[session_id] [smallint] NULL,
[server_principal_id] [int] NULL,
[database_principal_id] [int] NULL,
[target_server_principal_id] [int] NULL,
[target_database_principal_id] [int] NULL,
[object_id] [int] NULL,
[class_type] [varchar](2) NULL,
[class_type_desc] [nvarchar](35) NULL,
[session_server_principal_name] [nvarchar](128) NULL,
[server_principal_name] [nvarchar](128) NULL,
[server_principal_sid] [binary](85) NULL,
[database_principal_name] [nvarchar](128) NULL,
[target_server_principal_name] [nvarchar](128) NULL,
[target_server_principal_sid] [binary](85) NULL,
[target_database_principal_name] [nvarchar](128) NULL,
[server_instance_name] [nvarchar](128) NULL,
[database_name] [nvarchar](128) NULL,
[schema_name] [nvarchar](128) NULL,
[object_name] [nvarchar](128) NULL,
[statement] [nvarchar](2000) NULL,
[additional_information] [nvarchar](2000) NULL,
[file_name] [nvarchar](260) NULL,
[audit_file_offset] [bigint] NULL
) ON [PRIMARY]
-- Zeit und Offset des letzten Protokolleintrags abrufen
SELECT @data_path = file_name, @offset = audit_file_offset
FROM AUDITLOG
WHERE event_time = (select MAX(event_time)FROM AUDITLOG)
INSERT INTO [Test1].[dbo].[AuditLog]
([action_name]
82
,[class_type_desc]
,[event_time]
,[sequence_number]
,[action_id]
,[succeeded]
,[permission_bitmask]
,[is_column_permission]
,[session_id]
,[server_principal_id]
,[database_principal_id]
,[target_server_principal_id]
,[target_database_principal_id]
,[object_id]
,[class_type]
,[session_server_principal_name]
,[server_principal_name]
,[server_principal_sid]
,[database_principal_name]
,[target_server_principal_name]
,[target_server_principal_sid]
,[target_database_principal_name]
,[server_instance_name]
,[database_name]
,[schema_name]
,[object_name]
,[statement]
,[additional_information]
,[file_name]
,[audit_file_offset])
SELECT name, class_type_desc, C.*
FROM sys.dm_audit_actions A, sys.dm_audit_class_type_map B,
sys.fn_get_audit_file('C:\logs\*', @data_path, @offset) C
WHERE A.action_id = C.action_id
AND B.class_type = C.class_type
83
Verwenden von SSIS zum Verschieben von Protokollen in eine
Datenbanktabelle ("LoadLogsPackage.dtsx")
Wie im vorherigen Abschnitt erläutert und in Abbildung 40 gezeigt, kann SQL Server
Integration Services (SSIS) verwendet werden, um Daten zu übertragen und um während
des Übertragungsprozesses Daten zu transformieren. Abbildung 41 zeigt die Tasks aus
einem SSIS-Projekt zum Verschieben der Daten aus einer SQL Server Audit-Datei in eine
Datenbanktabelle. Der erste Task erstellt die Überwachungstabelle, wenn diese nicht
vorhanden ist. Der zweite Task führt die Übertragung durch.
Abbildung 41: Zwei SSIS-Tasks zum Sammeln von Überwachungsprotokollen
84
Abbildung 42 zeigt die Details des Übertragungstasks. Die Protokollrohdaten werden aus
der SQL Server Audit-Datei gelesen. Die Datei wird mit der Aktionstabelle kombiniert, um den
Aktionsnamen abzurufen. Der Datenstrom wird dann mit der Klassentabelle kombiniert, um
die Klassentypbeschreibung abzurufen. Die endgültigen Daten werden dann in die
Überwachungstabelle eingefügt.
Abbildung 42: Tasks zum Sammeln von Überwachungsdaten und Speichern der
Daten in einer einzelnen Tabelle
85
SSIS speichert die Ausgabe in einem Paket, das mithilfe des SQL Server-Agents in einen
Aufgabenschritt geladen werden kann, so wie in Abbildung 43 gezeigt. Auf diese Weise
kann die Datenübertragung automatisiert werden. Durch Verschieben der Daten aus einer
Protokolldatei in eine lokale Datenbank wird der Zugriff auf Daten durch Administratoren
erleichtert. Besprechen Sie dies mit den Prüfern, da einige möglicherweise darüber besorgt
sein könnten, dass Protokolle einfacher geändert werden können. Die Datei
"CreateAuditJob.sql" erstellt einen Überwachungsauftrag, der mithilfe der Paketdatei
"LoadLogsPackage.dtsx", die sich im Verzeichnis "C:\" befindet, alle fünf Minuten ausgeführt
wird.
Abbildung 43: In SQL Server-Agent geladenes SSIS-Paket
86
Zugreifen auf SQL Server Audit-Ereignisse mithilfe von Excel
("AuditReport.xlsx")
Nachdem die Daten in einer Datenbanktabelle gespeichert wurden, können sie mithilfe von
Excel in eine Tabellenkalkulation importiert werden. Gleiches gilt für SQL Server AuditProtokolle. Excel stellt einen bekannten Mechanismus zum Analysieren von Daten in einem
Tabellenformat bereit. Abbildung 44 zeigt eine Ansicht der im vorherigen Abschnitt
beschriebenen SQL Server Audit-Tabelle, nachdem diese mithilfe des Menübands "Daten" in
Excel importiert wurde. Filter können verwendet werden, um die Ansicht auf einen Bereich
von Daten, Aktionen, Objekten und Benutzern zu beschränken.
Abbildung 44: In Excel geladene SQL Server Audit-Protokolle
87
Mit dem Menüband Einfügen in Excel kann aus den Daten eine dynamische PivotTable®Sicht erstellt werden. Abbildung 45 zeigt ein Beispiel einer PivotTable, die aus den Daten
der Tabellenkalkulation mit den Überwachungsinformationen erstellt wurde. In die PivotTable
wurden Felder für Aktion, Klassentyp und Serverprinzipalname eingefügt. Für die PivotTable
wurde ein Balkendiagramm erstellt, das die Anzahl von Aktionen, die für bestimmte Objekte
ausgeführt wurden, geordnet nach Typ anzeigt. Anhand der PivotTable-Feldliste kann
bestimmt werden, welche Felder Teil des Diagramms sind und wie sie verwendet werden.
Abbildung 45: Aus SQL Server Audit-Protokollen generierte PivotTable
88
Abrufen einer IP-Adresse aus einem Überwachungsprotokoll
Wenn Sie Überwachungsprotokolle anzeigen, können Sie anhand des Felds
"server_principal_name" die ID des Benutzers bestimmen, der den protokollierten Vorgang
ausgeführt hat. Wenn die Datenbankverbindung jedoch über ein SQL Server-Konto und nicht
über ein Windows-Konto hergestellt wird, stellt das Feld "server_principal_name" keine
nützlichen Informationen bereit, mit denen die Person, die den Vorgang ausgeführt hat, auf
einfache Weise ermittelt werden kann. Die Protokolle stellen jedoch Informationen bereit, die
Aufschluss über die mögliche Identität des Benutzers geben. Jeder Protokolleintrag enthält
eine Sitzungs-ID (session_id). Dieses Feld ist der ID zugeordnet, die dem Benutzer bei der
Anmeldung zugewiesen wird. In dem aktuellen Anmeldedatensatz (gekennzeichnet durch die
Aktions-ID "LGIS"), der dieselbe ID aufweist, enthält das Feld "additional_information" die IPAdresse des Computers, der eine Verbindung mit der Datenbank hergestellt hat. Anhand der
Protokolle dieses Computers kann festgestellt werden, wer den Computer verwendet hat, als
die Verbindung hergestellt wurde. Das folgende Skript kann verwendet werden, um die IPAdresse aus dem Feld "server_principal_name" abzurufen.
SELECT event_time, statement,
CAST(additional_information AS XML).value('declare namespace
z="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data";
(//z:address)[1]', 'nvarchar(300)')
FROM sys.fn_get_audit_file('C:\logs\*',Null, Null)
WHERE action_id = 'LGIS'
ORDER BY event_time DESC
89
Überwachungsprojekt
Dieses Projekt wurde im Rahmen einer Zusammenarbeit zwischen Caregroup Healthcare
(Ayad Shammout), Microsoft Consulting Services (Andy Roberts) und SQL Customer
Advisory Team (Denny Lee) erstellt. Ziel der Zusammenarbeit war die Erstellung einer
Arbeitsvorlage eines End-to-End-Überwachungsprojekts, das Überwachungsprotokolle
abruft, Daten transformiert, lädt und aggregiert und Berichte erstellt. Weitere Informationen
finden Sie im (noch nicht veröffentlichten) Audit Project Technical Spotlight.
Abbildung 46: Überwachungsprojektmappen-Workflow
Process Audit Information
Use SSIS to process SQL Server Audit Information
SQL Server Audit Data
SSIS
SQL Audit
SQL 2008
Ge
ne
ra
te
Re
po
Transfer
File Server
rts
Logs
SQL Server
2008
SQL Server
2008
SQL Server 2008
Security Reports
SSRS 2008
Security Analysis
Compliance
Reports
Security Information
Erwerb der Lösung
Entzippen Sie die Datei "SQLAudit.zip". Die ZIP-Datei sollten folgende Dateien enthalten:
 SQLAuditRepositoryDatabase.sql – die SQL-Datei, die Ihre SQLAudit-Datenbank
erstellt

LoadLogsPackage.dtsx – ein SSIS-Paket, das die Überwachungsdaten abruft,
extrahiert, transformiert und lädt und die Überwachungsprotokolle archiviert

SQLAuditReports – eine SSRS-Lösung (SQL Server Reporting Services), die Sie auf
dem Server bereitstellen können, um Überwachungsberichte anzuzeigen
90
Erstellen der SQLAudit-Datenbank
Diese Datenbank ist das Repository der Überwachungsdaten.
1. Öffnen Sie die Datei "SQLAuditRepositoryDatabase.sql" in SQL Server Management
Studio, und aktivieren Sie den SQLCMD-Modus (wählen Sie im Menü Abfrage den
SQLCMD-Modus aus). Wenn der SQLCMD-Modus aktiviert ist, sind die :setvar-Zeilen
grau hervorgehoben.
2. Definieren Sie die folgenden Variablen.
Variable
Beschreibung
Kommentare
DataDirectory
SQL DB-Datenordner
(z. B. "H:\sqldata\")
LogDirectory
Stellen Sie sicher, dass die Pfade mit einem
umgekehrten Schrägstrich enden ("\").
Stellen Sie sicher, dass die Pfade mit einem
umgekehrten Schrägstrich enden ("\").
SQL DB-Protokollordner
(z. B. "H:\sqllog\")
DatabaseName Name der Datenbank
(z. B. SQLAudit)
Keine.
3. Führen Sie das Skript aus, um die Datenbank zu erstellen.
Installieren Sie das LoadLogsPackageSSIS-Paket.
Sie erstellen die zum Ausführen des SSIS-Pakets erforderlichen Konfigurationsdateien.
1. Doppelklicken Sie auf SQLAuditLoader.SSISDeploymentManifest. Wenn mit dem
Paket kein Programm verknüpft ist, navigieren Sie zu "C:\Programme\Microsoft SQL
Server\100\DTS\Binn\dtsinstall.exe", um es im Paketinstallations-Assistenten zu
öffnen. Weitere Informationen zum Installieren von Paketen finden Sie unter
http://msdn.microsoft.com/de-de/library/ms365321(SQL.100).aspx
2. Klicken Sie auf Weiter, klicken Sie auf Bereitstellung im Dateisystem, und klicken
Sie dann auf Weiter. Wählen Sie einen Installationsordner aus, beispielsweise
C:\Programme\Microsoft SQL Server\100\DTS\Packages\SQLAuditLoader, klicken
Sie auf Weiter, und klicken Sie dann auf Weiter.
3. Konfigurieren Sie folgende Paketeigenschaften.
Parameter
Beispielwert
SSIS-Protokollanbieter für
SQL Server
SqlAuditLogRepository
SqlAuditLogRepository
Data Source=.;Initial
Catalog=$DBName$;Provider=SQLNCLI10.1;Integra
ted Security=SSPI;Auto Translate=False;Application
Name=SSIS-Package-{21C9032A-E45A-41F2BA67-9EF35FCD18C3}SqlAuditLogRepository;
Geben Sie den Namen der
SQLAudit-Datenbank an (z. B.
SQLAudit).
91
User:auditLogArchivePath
Pfad, unter dem die verarbeiteten
Überwachungsprotokolle archiviert
werden.
User:LogFilePath
Ort der Überwachungsprotokolle
D:\audit\logs\archive
D:\Audit\logs
Diese Werte werden in der Datei LoadLogsPackageConfig.dtsConfig gespeichert.
Sie können die Werte manuell ändern, wenn Sie nach der Installation des SSISPakets Änderungen vornehmen müssen.
Hinweis:
Diese Version des Überwachungsprojekts setzt voraus, dass ein lokales
Dateiverzeichnis vorhanden ist, um die Überwachungsprotokolle
abzurufen.
4. Klicken Sie auf Weiter, und klicken Sie dann auf Fertig stellen.
Ausführen des SSIS-Pakets
Bei der Paketausführung wird angenommen, dass sich im Ordner "D:\audit\logs"
Protokolldateien befinden (so wie oben angegeben). Nach der Verarbeitung werden die
Protokolldateien in den Ordner "D:\audit\logs\archive" verschoben.
1. Wechseln Sie über eine Eingabeaufforderung zum SQLAuditLoader-Verzeichnis (z. B.
"C:\Programme\Microsoft SQL Server\100\DTS\Packages\SQLAuditLoader").
2. Führen Sie den folgenden Befehl aus:
dtexec /ConfigFile LoadLogsPackageConfig.dtsConfig /File
LoadLogsPackage.dtsx
Hinweis:
Stellen Sie sicher, dass Sie die SQL Server 2008-Version von DTExec ausführen.
Wenn Sie DTExec auf Servern mit mehreren Instanzen von SQL Server 2005 und
SQL Server 2008 ausführen, wird ggf. standardmäßig die SQL Server 2005Version (9.00.xxxx) von DTExec und nicht die SQL Server 2008-Version
(10.00.xxxx) verwendet. Um dies zu vermeiden, können Sie einen
vollqualifizierten DTExec-Pfad verwenden (z. B. C:\Programme\Microsoft SQL
Server\100\DTS\Binn\dtexec.exe).
Da viele Überwachungsprotokolldateien vorhanden sind, wird empfohlen, dieses SSISPaket regelmäßig auszuführen (z. B. alle 15 Minuten), um sicherzustellen, dass die Daten
zeitgerecht geladen werden.
Generieren von Aggregatberichten
Beim Ausführen des SSIS-Pakets werden die aud.AuditLog_[EventType]-Tabellen in der
SQLAudit-Datenbank mithilfe der Überwachungsprotokolle aufgefüllt. Da jedoch sehr viele
92
Überwachungsereignisse vorhanden sind, ist es von Vorteil, Aggregatberichte (d. h.
Zusammenfassungsberichte) zu erstellen, die eine Zusammenfassungsansicht aller
Überwachungen bereitstellen.
 Hierzu stellen Sie in SQL Server Management Studio eine Verbindung mit der
SQLAudit-Datenbank her und führen dann folgende Befehle aus.
exec
exec
exec
exec
aud.rspAggServerActions @EventDate = '08/22/2008'
aud.rspAggDatabaseActions @EventDate = '08/22/2008'
aud.rspAggDMLActions @EventDate = '08/22/2008'
aud.rspAggDDLActions @EventDate = '08/22/2008'
Hierdurch werden die aud.rptAgg[AuditEvent]Actions-Tabellen mit den Statistiken
über Zusammenfassungen aufgefüllt.
 Es wird vorgeschlagen, diese gespeicherten Prozeduren jede Nacht auszuführen
(z. B. mithilfe des SQL Server-Agents), um diese täglichen Informationen auf dem
neuesten Stand zu halten. Das folgende Skript veranschaulicht beispielsweise eine
Aufgabe, die jede Nacht ausgeführt wird:
-- @LastDay-Variable deklarieren, um sie auf das Datum des letzten
Tages festzulegen
-- Der Auftrag wird nach Mitternacht ausgeführt, um die Daten für den
letzten Tag zu aggregieren
Declare @LastDay char(11)
select @LastDay = Convert(char(11), getdate()-1 , 1)
Select @LastDay
Exec
Exec
Exec
Exec
aud.rspAggServerActions @LastDay
aud.rspAggDatabaseActions @LastDay
aud.rspAggDDLActions @LastDay
aud.rspAggDMLActions @LastDay
Auf welcher Partition befinden sich die Daten?
Das SQL-Skript zum Erstellen der Überwachungsdatenbank (SQLAudit) erstellt automatisch
zwölf monatliche Dateigruppen, beginnend mit dem Monat, in dem Sie das Skript ausgeführt
haben. Außerdem wird mit dem Partitionsschema und den Partitionsfunktionen sichergestellt,
dass die aud.AuditLog_%-Tabellen nach Monat partitioniert und mit den monatlichen
Datengruppen korreliert werden. Verwenden Sie das folgende Skript, um anzuzeigen, welche
Datenzeilen sich in welchen Tabellenpartitionen befinden.
select partition_id, OBJECT_NAME(object_id), object_id, index_id,
partition_number, partition_id, rows as [RowCount], x.value
from sys.partitions
left outer join (
select boundary_id, value
from sys.partition_range_values
where function_id = (
select function_id
from sys.partition_functions
where [name] = 'monthly_partition_function'
)
) x
on x.boundary_id = partition_number - 1
where OBJECT_NAME(object_id) like 'AuditLog%' and index_id = 1
order by OBJECT_NAME(object_id), partition_number
Anzeigen von Berichten
93
Wie oben im Abschnitt "Überwachen sensibler Vorgänge" erwähnt, gibt es eine Reihe von
Berichten, die von den Überwachungsprotokollen generiert werden können. Sie können diese
Berichte anzeigen, indem Sie die SQLAuditReports-Reporting Services-Lösung bereitstellen.
1. Öffnen Sie die SQLAuditReports-Reporting Services-Lösung im Microsoft Visual
Studio®-Bereitstellungssystem.
2. Legen Sie die Bereitstellungseigenschaft "TargetServerURL" auf Ihren Server fest,
d. h. ändern Sie http://campschurmann/ in den Namen Ihres Servers.
Abbildung 47: SQLAuditingReports-Eigenschaftenseite
3. Stellen Sie sicher, dass die freigegebene Datenquelle "SQLAudit.rds" auf Ihre eigene
SQLAudit-Datenbank zeigt (und nicht auf die Version der SQLAudit-Datenbank eines
anderen Servers).
4. Stellen Sie die Berichte bereit (über "Erstellen > Bereitstellen"). Sie können die
Berichte unter folgendem Pfad anzeigen: Fehler! Hyperlink-Referenz ungültig.
Bekannte Probleme

Es kann vorkommen, dass in den Überwachungsprotokollen nicht der Name der
Serverinstanz aufgezeichnet wird, d. h. in den Überwachungsprotokollen ist das Feld
für den Serverinstanznamen leer. Um dies zu umgehen, durchsucht das SSIS-Paket
das gesamte Überwachungsprotokoll, ermittelt den Serverinstanznamen und weist
diesen Namen dem gesamten Protokoll zu (da ein Überwachungsprotokoll nur von
einem Server stammt). Es gibt jedoch auch Situationen, in denen nicht einmal dies
möglich ist, da die gesamte Datei keinen Serverinstanznamen enthält. Sie können
diesem Fall vorbeugen, indem Sie die Überwachungsprotokolle gemäß der
Benennungskonvention einrichten.
94
SQLAudit$%Server$InstanceName%_%GUID%.sqlaudit
[aud].[fn_GetServerInstanceName] analysiert den Namen der Überwachungsdatei,
ruft den hervorgehobenen Serverinstanznamen (%Server$InstanceName%) ab und
verwendet diesen Namen, sofern er nicht bereits vorhanden ist. Um die Protokolldatei
gemäß dieser Benennungskonvention zu benennen, ändern Sie bei der Erstellung der
Serverüberwachung den Namen der Überwachung unter Verwendung des
SQLAudit$Server$InstanceName-Formats.
Verwalten der Richtlinien der richtlinienbasierten Verwaltung
Die richtlinienbasierte Verwaltung ist eine gute Möglichkeit, die Datenbankverwaltung zu
automatisieren. Die Verwaltung mehrerer Server und die skriptbasierte Verwaltung mithilfe
der richtlinienbasierten Verwaltung sind keine einfachen Aufgaben. Dieser Abschnitt enthält
Anleitungen und Skripts zum Erweitern der Funktionen der richtlinienbasierten Verwaltung.
Erstellen einer Richtlinie mithilfe von PowerShell
Der Blog von Sethu Srinivasan ist eine hervorragende Ressource, um das Erstellen einer
Richtlinie mithilfe von PowerShell (und nicht manuell über SQL Server Management Studio)
zu erlernen. Sie können über den folgenden Link auf den Blog zugreifen.
http://blogs.msdn.com/sethus/archive/2008/06/16/sql-2008-powershell-script-for-creating-apolicy-and-saving-to-file.aspx
Der Microsoft.SqlServer.Management.Dmf-Namespace enthält Klassen, die Objekte der
richtlinienbasierten Verwaltung von SQL Server darstellen.
Weitere Informationen finden Sie unter http://msdn.microsoft.com/dede/library/microsoft.sqlserver.management.dmf.aspx.
Bereitstellen von Richtlinien der richtlinienbasierten Verwaltung mit
PowerShell ("DeployPBMPolicies.ps1")
Das folgende PowerShell-Skript kann verwendet werden, um Skripts der richtlinienbasierten
Verwaltung in einer anderen Datenbankinstanz bereitzustellen:
# Richtlinien von einem Server exportieren
$policydir = "C:\Policies\"
del C:\Policies\*
$sourceserver = "<Machine>\<Instance>"
$conn = new-object
Microsoft.SQlServer.Management.Sdk.Sfc.SqlStoreConnection("server=$so
urceserver;Trusted_Connection=true");
$polstore = new-object
Microsoft.SqlServer.Management.DMF.PolicyStore($conn);
$fileprefix = "ExportedPolicy_"
$policycount = 0
#Temporäre Problemumgehung bis ein Fehler behoben wird.
#$sourcepolicycount = $polstore.Policies.Count;
foreach ($policy in $polstore.Policies)
95
{
$policycount++;
$StringWriter = New-Object System.IO.StringWriter;
$XmlWriter = New-Object System.XMl.XmlTextWriter $StringWriter;
#$polstore.ExportPolicy($polstore.Policies[$policy.Key],
$XmlWriter);
$policy.serialize($XmlWriter);
$XmlWriter.Flush();
$StringWriter.Flush();
$outputfile = $policydir + ("{0}.xml" -f (Encode-SqlName
$policy.Name));
$StringWriter.ToString() | out-file $outputfile;
}
if ($policycount -gt 0)
{
Write-Host $policycount "of" $sourcepolicycount "policies have
been exported to" $policydir -foregroundcolor "green"
}
else
{
write-host "No policies were exported" -foregroundcolor "red"
}
# Richtlinien auf mehrere Server importieren
$policylocation = "C:\Policies"
$serversfile = "C:\Servers.txt"
$servercount = 0
$servers = Get-Content $serversfile
foreach ($server in $servers) {
$servercount++;
$conn = new-object
Microsoft.SQlServer.Management.Sdk.Sfc.SqlStoreConnection("server='$s
erver';Trusted_Connection=true");
$polstore = new-object
Microsoft.SqlServer.Management.DMF.PolicyStore($conn);
foreach ($fileobject in get-childitem $policylocation){
$file = $fileobject.FullName
$reader = [System.Xml.XmlReader]::Create((convert-path
$file));
$output = $polstore.ImportPolicy($reader, 0, $true,
$true);
}
}
if ($servercount -gt 0)
{
Write-Host "Policies have been imported to" $servercount
"servers." -foregroundcolor "green"
}
else
{
write-host "No policies were imported" -foregroundcolor "red"
}
96
Übertragen von Richtlinienzustandsprüfungen in eine Datenbanktabelle
Unten wird eine Gruppe von PowerShell- und SQL-Skripts angezeigt, die
Richtlinieninformationen von mehreren Servern extrahiert und lädt und diese Informationen
an einem zentralen Ort einfügt, von dem aus Sie die Informationen anzeigen können.
Hinweis:
Bei der folgenden Übertragung einer Richtlinienzustandsprüfung findet eine
direkte Datenbanktabellenübertragung der Richtliniendaten aus der msdbDatenbank in die zentrale Datenbank statt. Eine potenziell bessere Möglichkeit für
diese Aufgabe stellt PBMTalk von Dan Jones bereit, der auch in diesem SDK
enthalten ist. Weitere Informationen finden Sie im PMTalk-Ordner, der eine
PowerPoint-Präsentation, ein richtlinienbasiertes Klassendiagramm sowie Code
für die richtlinienbasierte Verwaltung enthält, um die Daten der richtlinienbasierten
Verwaltung zu exportieren.
Erwerb der Lösung
Entzippen Sie die Datei "Policy.zip" in einem Ordner Ihrer Wahl (z. B. "D:\audit\code\Policy").
Aktualisieren der SQLAudit-Datenbank
Verwenden Sie diese Datenbank als zentralen Server. Um die erforderlichen Richtliniendaten
hinzuzufügen, installieren Sie "PolicyLoad.sql" auf dem zentralen Server, auf dem Sie alle
Berichte prüfen möchten, beispielsweise auf dem Server mit der SQLAuditÜberwachungsdatenbank. Auf diese Weise enthält Ihre zentrale SQLAudit-Datenbank jetzt
alle Richtlinien- und Überwachungsdaten.
Füllen Sie in der zentralen SQLAudit-Datenbank die Tabelle pol.ServerList mit allen Servern
auf, aus denen Sie Richtlinieninformationen extrahieren möchten. Beispiel:
insert into pol.ServerList values ('campschurmann', 1)
insert into pol.ServerList values ('emmonsroute', 1)
insert into pol.ServerList values ('emmonsglacier', 0)
wobei "1" aktiviert und "0" deaktiviert ist.
Ausführen des PowerShell-Skripts
Wie unter Verwenden der richtlinienbasierten Verwaltung zum Definieren, Bereitstellen und
Überprüfen von Richtlinien erläutert, erfüllt dieses Skript den Zweck, die oben angegebene
pol.ServerList-Tabelle zu lesen und alle in dieser Tabelle aufgelisteten Server zu
durchlaufen, die Richtliniendaten zu extrahieren und dann die Daten auf einen zentralen
Server zu laden. Kopieren Sie das PowerShell-Skript "PolicyExLoad.ps1" auf den zentralen
Server, z. B. "D:\audit\code\Policy".
Stellen Sie sicher, dass dieser Ordner auch einen Archivordner enthält (z. B.
"D:\audit\code\Policy\archive").
Dies ist ein PowerShell-Skript, das mithilfe von SQL Server-Snap-Ins sicherstellt, dass Sie
"sqlps" ausgeführt haben, bevor Sie die normale Eingabeaufforderung öffnen (und nicht das
PowerShell-Befehlsfenster).
97
Über die Befehlszeile können Sie folgenden Befehl ausführen.
.\PolicyExLoad.ps1 "[SQLCentral]" "[Datenbank]" "[Datum]" "[Ordner]"
SQLCentral: Die Serverinstanz, die die zentrale Datenbank (d. h. die SQLAuditDatenbank) enthält.
Datenbank: In den meisten Fällen die SQLAudit-Datenbank.
Datum: Das letzte Datum (d. h. ein Tag), an dem die Richtlinien ausgeführt wurden.
Wenn Sie alle Richtlinieninformationen abrufen möchten, verwenden Sie
Anführungszeichen ("") anstelle eines Datums.
Ordner: Das zentrale Repository für Richtlinienprotokolldateien; wie oben erwähnt,
sollte dieser Ordner auch einen Archivordner enthalten.
Von hier stellt das Skript eine Verbindung mit jedem Server her, extrahiert die
Richtliniendaten und schreibt diese dann als CSV-Datei auf eine Protokollfreigabe. Beachten
Sie, dass es zwei Typen von Richtliniendaten gibt:
 Richtliniendimensionstabellen: Diese Tabellen enthalten die Grundkonstrukte der
Richtlinien (Richtlinienname, Bedingungen, Kategorien usw.). Wenn eine Richtlinie
geändert oder gelöscht wird, werden diese Informationen in den entsprechenden
msdb-Tabellen in den Richtliniendaten auf den Remoteservern aktualisiert. Das
folgende Skript ruft den Richtliniennamen, die Bedingungen und die
Kategorieinformationen aus folgenden Tabellen ab:
o syspolicy_policies
o syspolicy_conditions
o syspolicy_policy_categories
 Richtlinienfaktentabellen: Da diese Tabellen den Ausführungsverlauf und Details
zum Richtlinienzustand enthalten, werden die Daten in diesen Tabellen nicht
aktualisiert (nur neue Ereignisse werden eingefügt). Das folgende Skript ruft
Ausführungsverlauf, Details zum Ausführungsverlauf und Richtlinienzustand aus
folgenden Tabellen ab:
o syspolicy_policy_execution_history
o syspolicy_policy_execution_history_details
o syspolicy_system_health_state
Das Extrahierungsskript erstellt dann CSV-Dateien für jede Tabelle mit der folgenden
Benennungskonvention:
ServerName_[Richtlinientabelle]_jjjjMMdd_hhmmss.csv
98
Das PowerShell-Skript greift dann auf die gespeicherte Prozedur
[pol].[uspImportPolicyData] zu, die zusätzliche Geschäftslogik zum Importieren aller CSVDateien in die entsprechende Tabelle enthält.

Wenn die Datei für eine Richtliniendimensionstabelle bestimmt ist, werden die Daten
zuerst in eine Stagingtabelle eingefügt. Dann werden alle mit den Serverinstanzen
verknüpften Daten in der Stagingtabelle aus der Richtlinientabelle entfernt. Der Grund
dafür ist, dass die Richtlinieninformationen (z. B. Name des Erstellers, verwendete
Facets und Bedingungen oder aktualisierter Text) stets aktuell sein sollen. Dann wird
die Stagingtabelle zum Auffüllen der Richtlinientabelle verwendet.

Wenn die Datei für eine Richtlinienfaktentabelle bestimmt ist, wird sie einfach in die
entsprechende Faktentabelle hochgeladen. Da die Richtlinienfaktentabellen über
eindeutige Indizes verfügen, wird sichergestellt, dass keine Duplikate in das System
gelangen. Auch wenn Sie mehrere Richtlinienfaktendateien haben, die mehrmals
ausgeführt wurden, können diese auch weiterhin ausgeführt werden. Die Datenbank
stellt sicher, dass keine doppelten Daten eingefügt werden.

Nachdem die Datei importiert wurde, wird sie in das Verzeichnis <Ordner\Archiv>
importiert, damit sie nicht erneut verarbeitet wird.
99
Anzeigen einiger Richtlinienberichte
Installieren Sie das SQL-Skript "PolicyReports.sql" auf dem zentralen Server und in der
Datenbank (wo "PolicyLoad.sql" installiert wurde).
So wie in Verwenden der richtlinienbasierten Verwaltung zum Definieren, Bereitstellen und
Überprüfen von Richtlinien erläutert, gibt es eine Reihe von Berichten, die von den
Überwachungsprotokollen generiert werden können. Sie können diese Berichte anzeigen,
indem Sie die [Richtlinienberichte - PBM]-Reporting Services-Lösung bereitstellen.
 Öffnen Sie die [Richtlinienberichte - PBM]-Reporting Services-Lösung in Visual
Studio.
 Legen Sie die Bereitstellungseigenschaft "TargetServerURL" auf Ihren Server fest,
d. h. ändern Sie http://campschurmann/ in den Namen Ihres Servers.
Abbildung 48: Eigenschaftenseite der [Richtlinienberichte – PBM]-Reporting
Services-Lösung
 Stellen Sie sicher, dass die freigegebene Datenquelle "SQLAudit.rds" auf Ihre eigene
SQLAudit-Datenbank zeigt (und nicht auf die Version der SQLAudit-Datenbank eines
anderen Servers).
 Stellen Sie die Berichte bereit (Über "Erstellen" > "Bereitstellen"). Sie können die
Berichte unter folgendem Pfad anzeigen: Fehler! Hyperlink-Referenz ungültig.
100
Zusammenfassung
Microsoft und das SQL Server-Team setzen sich für die Bereitstellung einer Technologie ein,
die Kunden und Partner dabei unterstützt, ihre Kompatibilitätsanforderungen zwecks
Einhaltung von Vorschriften zu erfüllen. SQL Server 2008 stellt die Technologie und
Funktionen bereit, auf die Organisationen sich stützen, um den wachsenden
Herausforderungen bei der Verwaltung von Daten und der Bereitstellung von aussagefähigen
Einblicken für Benutzer gerecht zu werden. Mit maßgeblichen Weiterentwicklungen in
Schlüsselbereichen stellt SQL Server 2008 eine Plattform für die agile Entwicklung von
Kompatibilitätslösungen bereit.
Dieses Whitepaper bietet nur eine Übersicht über die kompatibilitätsbezogenen Features und
Funktionen in SQL Server 2008. Wir planen, die kompatibilitätsbezogenen Funktionen in
zukünftigen Versionen zu erweitern. Weitere Informationen zur Kompatibilität finden Sie unter
http://www.microsoft.com/sql.
Weitere Informationen:
http://www.microsoft.com/sqlserver/: SQL Server-Website
http://technet.microsoft.com/de-de/sqlserver/: SQL Server TechCenter
http://msdn.microsoft.com/de-de/sqlserver/: SQL Server DevCenter
http://www.microsoft.com/sqlserver/2008/en/us/wp-sql-2008-security.aspx: SQL Server
Security White Paper
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1626&SiteID=1: SQL Server
Security Forum
http://blogs.msdn.com/sqlsecurity/: SQL Server Security Blog
http://blogs.msdn.com/sqlpbm/: SQL Server Policy-Based Management Blog
101
War dieses Whitepaper hilfreich? Senden Sie uns Ihr Feedback. Nennen Sie uns anhand einer
Skala von 1 (schlecht) bis 5 (sehr gut) die Bewertung dieses Whitepapers und die Gründe für
Ihre Bewertung. Beispiel:


Vergeben Sie eine gute Bewertung auf Grund der guten Beispiele, hervorragenden
Screenshots, klaren Formulierungen oder aus einem anderen Grund?
Vergeben Sie eine weniger gute Bewertung auf Grund schlechter Beispiele, ungenauer
Screenshots oder unklarer Formulierungen?
Dieses Feedback trägt zur Verbesserung der Qualität von uns veröffentlichter Whitepapers bei.
Feedback senden