Microsoft SQL Server 2005 aber sicher – Best Practices

Microsoft SQL Server 2005 aber sicher – Best
Practices
Thomas Tauxe, Consultant Februar 2009
Sicherheit ist ein wesentlicher Bestandteil, welcher zum stabilen Betrieb einer Umgebung
beiträgt. Die Sicherung eines SQL Servers besteht aus einer Reihe von Schritten die vier
Bereiche betreffen, die Plattform, die Authentifizierung, die Objekte und die Anwendungen.
Dieses Papier beschreibt Optionen für die Einrichtung, den Betrieb und die speziellen
Anforderungen im Applikationsbereich. Es behandelt einige, aber nicht alle Funktionen und
deren Sicherheitsfeatures des SQL Servers. Es soll dazu dienen, einen SQL Server im normalen
Einsatz sicher zu konfigurieren und zu betreiben. Für spezielle Anwendungsgebiete soll dieses
Dokument als Basis dienen.
1. Allgemeines
Die erste Voraussetzung für eine sichere SQL Installation ist eine sichere Umgebung. Auch bei
SQL 2005 haben sich die Voraussetzungen, was den Betrieb eines Servers betrifft, nicht
geändert. Der Server muss physisch sicher und regelmässig gesichert werden. Eine oder
mehrere Firewalls verhindern zudem den direkten Zugriff auf den SQL Server.
1.1.
Vor dem Installieren von SQL Server
Erhöhen der physikalischen Sicherheit
Physikalische und logische Isolation bilden die Basis der Sicherheit von SQL Server. Führen Sie
die folgenden Aufgaben aus, um die physikalische Sicherheit der SQL Server-Installation zu
erhöhen:
•
•
•
•
Platzieren des Servers in einem Raum, den nur autorisierte Benutzer betreten dürfen.
Aufstellen der Computer, die Datenbanken hosten, an physikalisch geschützten Orten.
Im Idealfall sollte dies ein geschlossener Computerraum mit Systemen für
Überschwemmungsschutz und Feuererkennung bzw. Brandbekämpfung sein.
Installieren der Datenbanken in der sicheren Zone des Intranets im Unternehmen und
ohne direkte Verbindung mit dem Internet.
Ausführen regelmäßiger Datensicherungen, und aufbewahren der Kopien an einem
sicheren Ort ausserhalb des Unternehmensgebäudes.
Verwenden von Firewalls
Firewalls sind ein wichtiger Bestandteil, wenn es um die Sicherung der SQL Server-Installation
geht. Sie bieten den wirksamsten Schutz, wenn die folgenden Richtlinien beachtet werden:
•
•
•
•
Einrichten einer Firewall zwischen Server und Internet.
Unterteilen des Netzwerks in Sicherheitszonen, die durch Firewalls voneinander
getrennt sind. Zunächst blockieren von sämtlichem Datenverkehr, und anschliessend
zulassen von ausgewählte Verbindungen.
Verwenden von mehreren Firewalls in einer mehrstufigen Umgebung.
Falls der Server in einer Windows-Domäne installiert wird, konfigurieren der inneren
Firewalls, dass die Windows-Authentifizierung verwendet werden kann.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 1 / 10
•
•
Deaktivieren von NTLM-Authentifizierung innerhalb einer Windows-Domäne, in
welcher es sich bei allen Windows-Versionen um Windows XP bzw. Windows Server
2003 oder höher handelt.
Falls die Anwendung verteilte Transaktionen verwendet, muss die Firewall
möglicherweise so konfiguriert werden, dass MS DTC-Datenverkehr zwischen separaten
MS DTC-Instanzen sowie zwischen MS DTC und Ressourcen-Managern des SQL Server
übermittelt werden können.
Isolieren von Diensten
Durch das Isolieren von Diensten wird das Risiko reduziert, dass durch einen gefährdeten
Dienst andere Dienste ebenfalls gefährdet würden. Folgende Richtlinien sollten beim Isolieren
von Diensten beachtet werden:
•
•
•
Installation von SQL Server nach Möglichkeit nicht auf einem Domänencontroller.
Ausführen von separaten SQL Server-Diensten unter separaten Windows-Konten.
Innerhalb einer mehrstufigen Umgebung sollten Web- und Geschäftslogik auf
getrennten Computern ausgeführt werden.
Deaktivieren von NetBIOS und Server Message Block
Für Server im Umkreisnetzwerk (DMZ) sollten alle nicht erforderlichen Protokolle deaktiviert
sein, einschließlich NetBIOS und Server Message Block (SMB).
NetBIOS verwendet die folgenden Ports:
•
•
•
UDP/137 (NetBIOS-Namensdienst)
UDP/138 (NetBIOS-Datagrammdienst)
TCP/139 (NetBIOS-Sitzungsdienst)
SMB verwendet die folgenden Ports:
•
•
TCP/139
TCP/445
Für Webserver und DNS-Server (Domain Name System) ist die Verwendung von NetBIOS oder
SMB nicht erforderlich. Deaktivierung der Protokolle auf diesen Servern, um das Risiko eines
Angriffs von Benutzern zu minimieren.
2. Plattform und Netzwerksicherheit
2.1.
Network Connectivity
Um Zugriff auf einen Datenbank zu erhalten, muss der Client und der Server ein gemeinsames
Netzwerkprotokoll unterstützen. Dazu muss auf dem Sever ein- oder mehrere
Netzwerkprotokolle aktiviert werden. Es wird empfohlen jeweils nur die benötigten Protokolle
zu aktivieren. Als gängiges Protokoll, welches auch von dem meisten Client unterstützt wird gilt
das TCP/IP Protokoll.
Um eine erhöhte Sicherheit zu erreichen, kann die Verschlüsselung mittels SSL-Protokoll
aktiviert werden. Diese Verschlüsselung gilt für alle Protokolle und kann nicht einzeln aktiviert
oder deaktiviert werden. Die Verschlüsselung steht allen Protokollen, mit Ausnahme von DB
Library und MDAC 2.53 Clients zur Verfügung. Um SSL Verschlüsselung verwenden zu
können, muss ein gültiges Zertifikat installiert sein.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 2 / 10
2.2.
Service Accounts
SQL Server-Services müssen immer mit den geringst möglichen Benutzerrechten ausgeführt
werden. Die Service Accounts benötigen keine LocalAdmin Rechte. Das SQL Server-Setup
konfiguriert die Service Accounts automatisch mit den spezifischen für SQL Server
erforderlichen Berechtigungen. Beim Ändern oder Konfigurieren der Windows-Dienste, die von
SQL Server 2005 verwendet werden, sollten nur die erforderlichen Berechtigungen erteilt
werden.
Die folgende Tabelle zeigt die benötigten Rechte der jeweiligen Services. Es ist möglich, für
jeden Service einen eigenen Benutzer zu erstellen. Dies wird jedoch aus administrativen
Gründen nur in einer hoch sicheren Umgebung umgesetzt.
Service
User Gruppe
Minimum benötigte
Rechte
SQL Server
(MSSQLSERVER)
SQLServer2005MSSQLUser
SQL Server Agent
SQLServer2005SQLAgentUser
Analysis Services
Reporting Services
Notification Services
Integration Services
SQLServer2005MSOLAPUser
SQLServer2005ReportServerUser
SQLServer2005NotificationServicesUser
SQLServer2005DTSUser
Full-Text Search
SQL Browser
SQLServer2005MSSQLUser2
SQLServer2005SQLBrowserUser
SQL Server Active
Directory Helper
SQL Writer
Runs only as built-in accounts
Log on as a service
Log on as a batch job
Replace a process-level token
Bypass traverse checking
Log on as a service
Log on as a batch job
Replace a process-level token
Bypass traverse checking
Adjust memory quotas for a
process
Log on as a service
Log on as a service
Keine
Log on as a service
Bypass traverse checking
Create global objects
Impersonate a client after
authentication
Log on as a service
Log on as a service
Deny log on as a batch job
Deny log on through Terminal
Services
Deny access to this computer
from a network
Deny log on locally
Deny log on as a batch job
Keine
Runs only as built-in accounts
Keine
Abhängig der zusätzlich verwendeten Funktionen, kann es notwendig sein weitere Rechte zu
vergeben. Zum Beispiel werden Netzwerk Berechtigungen benötigt um Mails mittels extended
Stored Procedures zu versenden oder OS Berechtigungen um xp_cmdshell zu verwenden.
Verwenden eines Domänenbenutzer Accounts
Ein Domänenbenutzerkonto wird unter Umständen bevorzugt, wenn der Dienst mit
Netzwerkdiensten interagieren muss. Viele Server-zu-Server-Aktivitäten können nur mit einem
Domänenbenutzerkonto ausgeführt werden, zum Beispiel:
•
•
Remoteprozeduraufrufe (Remote Procedure Calls, RPCs)
Replikation
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 3 / 10
•
•
•
Sichern auf Netzlaufwerken.
Heterogene Verknüpfungen, die Remotedatenquellen einbeziehen.
E-Mail-Features des SQL Server-Agents und SQL Mail. Diese Einschränkung gilt, wenn
Sie Microsoft Exchange verwenden. Die meisten anderen E-Mail-Systeme erfordern
ebenfalls, dass Clients (wie die Agent-Dienste SQL Server und SQL Server) unter Konten
mit Netzwerkzugriff ausgeführt werden.
Verwenden des lokalen Dienst Accounts
Das lokale Dienstkonto ist ein spezielles, integriertes Konto, dass mit einem authentifizierten
Benutzerkonto vergleichbar ist. Es bietet denselben Zugriff auf Ressourcen und Objekte wie
Mitglieder der Gruppe Benutzer. Durch diesen beschränkten Zugriff wird Ihr System geschützt,
wenn einzelne Dienste oder Prozesse gefährdet sind. Bei Diensten, die als lokales Dienstkonto
ausgeführt werden, erfolgt das Zugreifen auf Netzwerkressourcen als NULL-Sitzung ohne
Anmeldeinformationen.
Verwenden des Netzwerkdienst Accounts
Das Netzwerkdienstkonto ist ein spezielles, integriertes Konto, das mit einem authentifizierten
Benutzerkonto vergleichbar ist. Es bietet denselben Zugriff auf Ressourcen und Objekte wie
Mitglieder der Gruppe Benutzer. Bei Diensten, die als Netzwerkdienstkonto ausgeführt werden,
erfolgt das Zugreifen auf Netzwerkressourcen mithilfe der Anmeldeinformationen des
Computerkontos.
Best practices für Service Accounts
•
•
•
Verwenden einen Lokalen Dienst Accounts, wenn keine externen Ressourcen
verwendet werden müssen.
Verwenden eines Domänen Accounts, wenn auf Ressourcen ausserhalb des SQL Servers
zugegriffen werden muss.
Ein gemeinsamer Account für den SQL Server Service und den SQL Server Agent
Service.
1.1.
Tools
SQL Server stellt eine Vielzahl von Tools zur Konfiguration zur Verfügung. Einstellungen sollten
wenn immer möglich über diese Tools vorgenommen werden.
1.1.1.
Surface Area
SQL Server installiert und startet nur die unbedingt benötigten Komponenten. Dadurch werden
die möglichen Angriffspunkte minimiert. Bei der Standardkonfiguration sind deshalb viele
Punkte nicht aktiviert und sollten bei Bedarf bei der Installation aktiviert werden. Jeder nicht
installierte Dienst oder jedes nicht installierte Feature kann nicht angegriffen werden.
Das Surface Area Tool ermöglicht die einfache Konfiguration der Komponenten. So können
damit das Datenbankmail, die Verwendung der CLR, Mirroring, Servcice Broker und weitere
Optionen gesetzt werden.
2. Authentifizierung
2.1.
Berechtigungshierarchie
In der Datenbank wird eine hierarchische Auflistung der Entitäten verwaltet, die mit
Berechtigungen gesichert werden können. Diese Entitäten werden als sicherungsfähige
Elemente(Securables) bezeichnet. Die wichtigsten sicherungsfähigen Elemente sind Server und
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 4 / 10
Datenbanken, diskrete Berechtigungen können jedoch auf einer viel differenzierteren Ebene
festgelegt werden. In SQL Server werden die Aktionen von Prinzipalen(Principals) für
sicherungsfähige Elemente dadurch gesteuert, dass geprüft wird, ob diesen die entsprechenden
Berechtigungen erteilt wurden.
In der folgenden Abbildung werden die Beziehungen zwischen den DatenbankmodulBerechtigungshierarchien dargestellt.
(Quelle Microsoft ©)
2.2.
•
•
Authentication Mode
Windows Authentication Mode: Benutzer können auf einen Server über ein bestehendes
Windows-Benutzerkonto zugreifen. Wenn ein Benutzer versucht, eine Verbindung zu
einem Server herzustellen, validiert SQL Server den Windows-Benutzernamen und das
Passwort des Benutzers. Der User muss sich nicht zwei Mal anmelden, im Netzwerk
und beim SQL Server, sondern ein Anmeldevorgang reicht. Dieser Ansatz wird auch
vertrauenswürdige Verbindung (Integrated Security) genannt.
Mixed Mode: Dieser Modus kombiniert Windows-Authentifizierung und SQL ServerAuthentifizierung. Benutzer können wie gewohnt über ein Windows-Benutzerkonto
eine Verbindung herstellen. Aber man kann auch direkt in SQL Server Benutzerkonten
einrichten, die keinen Zusammenhang mit Windows-Konten haben. Jedes SQL ServerKonto speichert einen Benutzernamen und ein Passwort.
Nach Möglichkeit ist der Windows Authentication-Modus zu empfehlen. SQL Server
Authentication (Mixed) wird für non-trusted Umgebungen und zur Abwärtskompatibilität mit
früheren Versionen von SQL Server bereitgestellt. Windows Authentication ist in das WindowsSicherheitssystem integriert, das mehr Funktionen zur Verfügung stellt als SQL Server
Authentication, in der Regel einfacher zu benutzen, effizienter und sicherer. Man sollte sich
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 5 / 10
schon früh während des Entwicklungsprozesses entscheiden, welchen Modus man einsetzen
will.
Mit welchem Modus man auch arbeitet - man sollte das Passwort für den System-Administrator
(sa) in SQL Server immer eigenhändig vergeben. Bei der Installation erstellt SQL Server
automatisch einen Administrator-Benutzer mit dem SQL Server-Anmeldenamen sa und einem
leeren Passwort. Der SQL-Server kann nur dann mit einem leeren sa-Passwort installiert werden,
wenn der Windows Authentication Mode genutzt wird. Verwendet man den Windows
Authentication Mode, sollte die Notwendigkeit eines Passworts für den Benutzer sa theoretisch
nicht anfallen, da SQL Server-Anmeldungen nicht akzeptiert werden. Aber es kann auch nicht
schaden, trotzdem eines einzurichten, falls man in Zukunft doch einmal in den Mixed Mode
wechseln muss
2.3.
Password Policy
SQL Server 2005 beinhaltet die Passwort Policies, basieren auf dem
NetValidatePasswordPolicy() API, welches Teil der NetAPI32 Library auf Windows Server 2003
ist. SQL Server überprüft das Passwort auf die Komplexität, den Ablauf und Sperrung während
dem setzten bzw. während der Eingabe des Passwortes.
Es wird empfohlen, dieses Feature für alle nicht Windows Logins zu aktivieren. Achtung!
Applikationen mit hardcodierten Passwörter können aufgrund der nicht erfüllten Kriterien nicht
funktionieren. Ebenfalls kann ein abgelaufenes Passwort Probleme bei der Applikation
hervorrufen.
2.3.1.
Der Benutzer SA
Sollte der SQL Server im Mixed Mode betrieben werden ist darauf zu achten, dass der Benuzter
SA über ein sehr sicheres Passwort verfügt. Dieser Benutzer sollte ausschliesslich für den Notfall
verwendet werden. Stattdessen sollte nach der Installation ein SA äquivalentes Login erstellt
werden, welches für die höheren Administrationsarbeiten verwendet wird. Dadurch kann der
Zugriff auf den SQL Server erschwert werden, da kein „Standardlogin“ zur Administration
verwendet wird.
2.4.
Administrator Privileges
Als Administrator können folgende Optionen gesetzt werden:
•
•
•
•
Benutzer (Konto): Ein SQL Server-Sicherheitskonto, dass einen einzelnen Benutzer
repräsentiert. Ein Benutzer hat ein Windows-Benutzerkonto oder ein SQL Server-Login,
das sich auf ein Benutzerkonto in einer Datenbank bezieht.
Gruppen (Konto): Jeder Benutzer kann zu einer oder mehreren Gruppen gehören, die in
Windows oder in SQL Server definiert werden, je nach Authentifizierungsmodus. Jede
Gruppe verfügt über bestimmte Berechtigungen. Als Mitglied einer Gruppe erhält man
alle Berechtigungen der Gruppe.
Objekt-Eigentümerschaft: Die Eigentümerschaft gehört demjenigen Benutzer, der das
Objekt erstellt. Besitzer können anderen Benutzern Zugriff gewähren. Wenn man z.B.
eine View besitzt, kann man entscheiden, welche Benutzer sich Daten aus diesem View
anzeigen lassen dürfen.
Berechtigungen: Eine Berechtigung bezeichnet die Fähigkeit, bestimme Aktionen
durchzuführen, z.B. das Öffnen einer View oder die Änderung einer abgespeicherten
Abfrage. SQL Server kennt drei Zustände für Berechtigungen: GRANT erlaubt dem
Benutzer den Zugriff, REVOKE widerruft dies, und DENY verwehrt einem Benutzer den
Zugriff auf das Objekt.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 6 / 10
•
Rolle: Dies ist ein SQL Server-Sicherheitskonto, das mehrere Einzelkonten bei der
Zuweisung von Berechtigungen als Einheit behandelt. Kurz gesagt, legen Rollen fest,
was einem Benutzer in einer bestimmten Datenbank erlaubt ist und was nicht.
3. Objekte
3.1.
Schemas
Schemas haben mit der Version 2005 bei Microsoft Einzug gefunden. Mittels Schemas ist die
Trennung zwischen den Benutzer und den Objekten möglich. Ein Schema kann dazu
verwendet werden, um Berechtigungen auf ein oder mehrere Objekte zentral zu vergeben.
Objekte werden dazu unter einem Schema erstellt. Die Benutzer erhalten anschliessend das
Recht, dieses Schema zu verwenden. Der Zugriff kann, wie auf den Objekten selbst, definiert
aber zentral verwaltet werden. So ist es möglich, funktionale Gruppen von Objekten unter
einem Schema zu erstellen (z.B. Produktion, Verkauf, etc.) das Schema dbo dient dabei als
Default Schema. Jeder Benutzer hat auf diesem Schema Standardrechte. Somit können
allgemeine Objekte in diesem Schema erstellt werden.
Nachfolgend eine Zusammenfassung der Vorteile bei Verwendung von Schemas
•
•
•
•
•
•
Löschen von Datenbankbenutzer ist wesentlich einfacher, da ein Objekt nicht mehr
einem Benutzer gehört.
Mehrere Benutzer können über die Zugehörigkeit zu einer Rolle Besitzer eines Schemas
sein.
Mehrere Benutzer können sich ein Default Schema teilen um eine einheitliche
Namensauflösung zu erreichen.
Applikationshersteller können Schemas verwenden um unterschiedliche Appliationen
auf derselben Datenbank zu betreiben.
Verwaltung der Rechte über Schema erfolgt auf einer höheren Ebene.
Objekte können zwischen Schemas verschoben werden.
4. Applikation
4.1.
Execution Context
Der Ausführungskontext einer Sitzung oder eines Moduls kann explizit geändert werden, indem
ein Benutzer- oder Anmeldename in einer EXECUTE AS-Anweisung angegeben wird. Das
ausgeführte Modul kann mit einer anderen Berechtigung als dessen des aufrufenden Benutzers
ausgeführt werden. So kann ein Benutzer unter Umständen Tasks durchführen, für welche er
mit den persönlichen Rechten nicht berechtigt ist. Der Identitätswechsel bleibt wirksam, bis
eines der folgenden Ereignisse eintritt:
•
•
•
Die Sitzung wird beendet.
Kontext wird zu einem anderen Anmeldenamen oder Benutzer gewechselt.
Kontext wird auf den vorherigen Ausführungskontext zurückgesetzt.
Die Verwendung von EXECUTE AS für die explizite Annahme der Identität eines anderen
Benutzers ähnelt der Verwendung von SETUSER in früheren Versionen von SQL Server.
Dadurch ist es möglich für die Ausführungszeit einen definierten Benutzer festzulegen, welcher
unterschiedliche Berechtigungen gegenüber dem angemeldeten Benutzer besitzt.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 7 / 10
Best Practices für Execution Context
•
•
Verwenden von Execution Context für Tasks, welche ausserhalb der normalen
Berechtigung des Benutzers liegen.
Setzten des Execution Context für Tasks, welche unter einem bestimmten Benutzer
ausgeführt werden sollen.
4.2.
Encryption
SQL Server stellt mit der Encryption eine Methode zur Verfügung, welche es erlaubt Daten auf
Spaltenebene zu verschlüsseln. Verschlüsselungsalgorithmen definieren Datentransformationen,
die von nicht autorisierten Benutzern nicht einfach umgekehrt werden können. SQL Server
2005 ermöglicht Administratoren und Entwicklern die Auswahl aus mehreren Algorithmen,
einschließlich DES, Triple DES, RC2, RC4, 128-Bit-RC4, DESX, 128-Bit-AES, 192-Bit-AES und
256-Bit-AES. (AES wird unter Windows XP und Windows 2000 nicht unterstützt)
Die Verschlüsselungshierarchie stellt dabei eine besondere Herausforderung dar. Wie aus der
unteren Abbildung ersichtlich, verschlüsselt jede Ebene die darunterliegende Ebene, in dem
eine Kombination aus Zertifikaten, asymmetrischen und symmetrischen Schlüssel verwendet
wird. Die oberste Ebene wird mittels Windows-Datenschutz API verschlüsselt.
(Quelle:Microsoft©)
Jeder Algorithmus verfügt über Vor- aber auch Nachteile und es existiert kein Algorithmus
welcher für alle Fälle ideal ist. Grundsätzlich gelten jedoch folgende Punkte:
•
•
•
•
•
Eine starke Verschlüsselung verbraucht im Allgemeinen mehr CPU-Ressourcen als eine
schwache Verschlüsselung.
Lange Schlüssel führen in der Regel zu einer stärkeren Verschlüsselung als kurze
Schlüssel.
Eine asymmetrische Verschlüsselung ist stärker als eine symmetrische Verschlüsselung,
wenn beide die gleiche Schlüssellänge verwenden. Allerdings ist eine asymmetrische
Verschlüsselung relativ langsam.
Lange, komplexe Kennwörter sind stärker als kurze Kennwörter.
Verschlüsselte Daten können nicht komprimiert werden, aber komprimierte Daten
können verschlüsselt werden. Falls die Komprimierung verwendet wird, müssen die
Daten vor dem verschlüsseln komprimiert werden.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 8 / 10
Zertifikate
Ein öffentliches Zertifikat ist eine digital signierte Anweisung, die den Wert eines öffentlichen
Schlüssels an die Identität der Person, des Geräts oder des Dienstes bindet, der den
entsprechenden privaten Schlüssel besitzt. Zertifikate werden von einer Zertifizierungsstelle
ausgegeben und signiert. Die Entität, die ein Zertifikat von einer Zertifizierungsstelle erhält, ist
der Antragsteller dieses Zertifikats. In der Regel enthalten die Zertifikate die folgenden
Informationen.
•
•
•
•
•
Den öffentlichen Schlüssel des Antragstellers.
Die Bezeichnerinformationen des Antragstellers, z. B. Name und E-Mail-Adresse.
Den Gültigkeitszeitraum. Dies ist der Zeitraum, in dem das Zertifikat als gültig
betrachtet wird.
Ein Zertifikat ist lediglich für den angegebenen Zeitraum gültig; jedes Zertifikat enthält
die Datumsangaben Gültig von und Gültig bis. Diese Datumsangaben legen den
Gültigkeitszeitraum fest. Wenn der Gültigkeitszeitraum für ein Zertifikat abgelaufen ist,
muss vom Antragsteller des gerade abgelaufenen Zertifikats ein neues Zertifikat
angefordert werden.
Aussteller der Bezeichnerinformationen.
Die digitale Signatur des Ausstellers.
Diese Signatur bestätigt die Gültigkeit der Bindung zwischen dem öffentlichen Schlüssel
und den Bezeichnerinformationen des Antragstellers. (Zum Vorgang der digitalen
Signierung von Informationen gehört die Umwandlung der Informationen, sowie einiger
geheimer Informationen des Absenders in ein Tag, die so genannte Signatur.)
Ein wichtiger Vorteil von Zertifikaten besteht darin, dass die Hosts keine Kennwörter für
einzelne Antragsteller mehr verwalten müssen. Der Host stellt stattdessen lediglich die
Vertrauenswürdigkeit eines Zertifikatausstellers her, der dann eine unbegrenzte Anzahl von
Zertifikaten signieren kann.
SQL Server kann selbst Zertifikate erstellen. Die von SQL Server erstellten, selbstsignierten
Zertifikate unterliegen dem X.509-Standard und unterstützen die X.509 v1-Felder.
Asymmetrische Schlüssel
Ein asymmetrischer Schlüssel besteht aus einem privaten Schlüssel und dem entsprechenden
öffentlichen Schlüssel. Jeder Schlüssel kann die jeweils vom anderen verschlüsselten Daten
entschlüsseln. Die asymmetrische Verschlüsselung und Entschlüsselung sind relativ
ressourcenintensiv, sie bieten jedoch eine höhere Sicherheit als die symmetrische
Verschlüsselung. Ein asymmetrischer Schlüssel kann für die Verschlüsselung eines
symmetrischen Schlüssels zum Speichern in einer Datenbank verwendet werden.
Symmetrische Schlüssel
Ein symmetrischer Schlüssel ist ein Schlüssel, der sowohl für die Verschlüsselung als auch die
Entschlüsselung verwendet wird. Die Verschlüsselung und Entschlüsselung mithilfe eines
symmetrischen Schlüssels ist schnell und für einen routinemäßigen Einsatz mit sensiblen Daten
in der Datenbank geeignet.
Best practices für Data Encryption
•
•
•
•
•
Sensible und hochwertige Daten verschlüsseln
Daten mit symmetrischen Schlüssel verschlüsseln
Symmetrische Schlüssel mit Zertifikate oder asymmetrischen Schlüssel schützen.
Den Service Master Schlüssel, Datenbank Master Schlüssel und die Zertifikate mit den
entsprechenden DDL Statement sichern.
Backup der Datenbanken damit die symmetrischen und asymmetrischen Schlüssel
gesichert sind.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 9 / 10
Trivadis kann Ihnen mit unserem Fachwissen helfen die beste Lösung für Ihre
Umgebung zu finden.
Viel Erfolg beim Einsatz von Trivadis-Know-how wünscht Ihnen
Thomas Tauxe
Trivadis AG
Europa-Strasse 5
CH-8152 Glattbrugg (Zürich)
Tel. +41-44-808 70 20
[email protected]
Literatur und Links…
www.trivadis.com
Die obenstehenden Informationen wurden aus den folgenden Quellen
zusammengefasst:
SQL Server 2005 Books Online November 2008
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.03.2009 . Seite 10 / 10