5 Sicherheit und Zugriff auf SQL Server 2008 R2

SQL Server 2008 R2: Administration
5 Sicherheit und Zugriff auf
SQL Server 2008 R2
5.1 Grundkonzept
Das Sicherheitskonzept von SQL Server 2008 R2 ist dreistufig aufgebaut:
•
Betriebssystem-Ebene: Zunächst ist eine Anmeldung am Betriebssystem nötig. Ein Benutzer
kann sich nur dann anmelden, wenn er ein Benutzerkonto hat. Erfolgt die Anmeldung in einer
Active Directory-Domäne, so wird die Authentifizierung mit dem Protokoll Kerberos v5
durchgeführt; bei lokalen Anmeldungen wird gegen die SAM-Datenbank (Security Account
Management) eine NTLMv2-Anmeldung durchgeführt. Jedes Benutzerkonto hat dabei eine
eindeutige SID (Security Identifier). Benutzer können auch Gruppen zugeordnet sein, wobei
Gruppenkonten ebenfalle eine eigene SID haben.
•
SQL Server-Instanz-Ebene: Damit ein Windows-Benutzer sich mit dem SQL Server verbinden
kann, muss ein Login (deutsch: Anmeldung) erstellt werden. Logins werden in der masterDatenbank gespeichert.
Man unterscheidet zwei Authentifizierungsvarianten:
−
Windows-Authentifizierung (Trusted Connection, vertraute Verbindung): Hier erfolgt
keine neuerliche Kennwortabfrage. Die Zuordnung zu einem Windows-Konto erfolgt über
die SID. Diese Art der Authentifizierung entspricht dem Single-Sign-On-Konzept (nur eine
Kennworteingabe berechtigt zum Zugriff auf alle berechtigten Ressourcen) und ist zu
empfehlen.
−
SQL Server-Authentifizierung: Aus historischen Gründen gestattet SQL Server nach
wie vor die Verwaltung eigener, von Windows unabhängiger Anmeldekonten. Hier ist die
Anmeldung durch Eingabe eines Login-Namens und Kennworts durchzuführen. Nach der
Standardinstallation von SQL Server wird das SQL Server-Login sa erzeugt, das durch
© Mag. Christian Zahler, Stand: August 2011
65
SQL Server 2008 R2: Administration
die Mitgliedschaft zur sysadmin-Serverrolle administrative Berechtigungen auf die
gesamte SQL Server-Instanz hat. Vergessen Sie nicht, ein sicheres Kennwort für das saLogin festzulegen!
•
Datenbank-Ebene: Schließlich muss auf Datenbankebene ein Datenbankbenutzer angelegt
werden, der einem Login zugeordnet werden muss. Datenbankbenutzer werden in den
Systemtabellen der jeweiligen Datenbank gespeichert.
Neu ab SQL Server 2008:
•
Kerberos-Authentifizierung mit allen Protokollen möglich (TCP/IP, Named Pipes, Shared Memory)
•
SPNs können auch in Connection Strings spezifiziert werden (die Portnummer ist nicht mehr Teil
der SPNs)
•
Kerberos ist auch möglich, ohne dass die SPNs im AD registriert werden
Standardmäßig ist auf SQL Server-Ebene nur die Windows-Authentifizierung aktiviert. Es ist auch
möglich, sowohl Windows- als auch SQL Server-Authentifizierung zu erlauben.
Bereits bei der SQL Server-Installation konnte die Serverauthentifizierung konfiguriert werden; im
laufenden Betrieb ist das in den Servereigenschaften möglich:
5.2 Anlegen von Login-Konten (SQL Server-Ebene)
a) Grafische Oberfläche im Management Studio:
66
© Mag. Christian Zahler, Stand: August 2011
SQL Server 2008 R2: Administration
b) TSQL: CREATE LOGIN, ALTER LOGIN, DROP LOGIN
-- Windows-Login erzeugen
CREATE LOGIN "CONTOSO\frank" FROM WINDOWS;
-- SQL-Login erzeugen
CREATE LOGIN Mary WITH PASSWORD = 'Pa$$w0rd';
In der Tabelle sysxlogins (1. Zeile = Benutzer AKopflos) findet man die SQL-Logins:
Domain Users werden über die SID identifiziert; die SQL Users erkennt man an der wesentlich
kürzeren SID. In der Spalte xstatus befindet sich eine Zahl, deren letztes Bit den Serverzugang
kennzeichnet (1 – ungerade Zahl = Verbot; 0 – gerade Zahl = Erlaubnis).
Es kann auch eine Windows-Sicherheitsgruppe einem SQL-Login zugeordnet werden (obiges
Beispiel: Administratoren-Gruppe).
© Mag. Christian Zahler, Stand: August 2011
67
SQL Server 2008 R2: Administration
In der Spalte password ist das SQL-Passwort gespeichert, der Eintrag NULL bedeutet WindowsAuthentifizierung.
5.3 Berechtigungen auf SQL-Serverebene
Server-Logins erhalten Berechtigungen auf SQL Server-Instanzebene durch:
•
Explizite Zuweisung: über das Management-Studio oder mit den TSQL-Anweisungen GRANT,
DENY und REVOKE
Beispiel:
USE master
GRANT ALTER ANY DATABASE
TO [ADVENTUREWORKS\Cornelia]
GRANT ALTER
ON LOGIN :: AWWebApp
TO [ADVENTUREWORKS\Cornelia]
•
Mitgliedschaft in einer Serverrolle: So
haben etwa Mitglieder der Serverrolle
sysadmin Administrationsrechte auf die
gesamte SQL Server-Instanz. Alle Logins
sind Mitglied bei der Serverrolle public;
diese Rolle gewährt Basisberechtigungen,
damit beispielsweise die vorhandenen
Benutzer-Datenbanken wenigstens
aufgelistet werden können.
5.4 Anlegen von Datenbankbenutzern
Das Anlegen von Datenbankbenutzern kann in der grafischen Oberfläche folgendermaßen
durchgeführt werden:
Achten Sie auf die korrekte Zuordnung des neuen Datenbankbenutzers zu einem vorhandenen Login!
68
© Mag. Christian Zahler, Stand: August 2011
SQL Server 2008 R2: Administration
Selbe Aufgabe mit TSQL: CREATE USER
-- Erstellen eines Benutzers für eine Anwendung mit gleichem Namen
CREATE USER Bernhard
-- Erstellen eines Benutzers mit einem Namen, der vom Namen der zugeordneten
Anmeldung abweicht
CREATE USER Jonas FOR LOGIN [ADVENTUREWORKS\Jonas]
-- Erstellen eines Benutzers mit einem explizit definierten Standardschema
CREATE USER SalesUser FOR LOGIN [DBSERVER1\SalesUsers]
WITH DEFAULT_SCHEMA = 'Sales'
5.5 Berechtigungen auf Datenbankebene
Datenbankbenutzer erhalten Berechtigungen für Datenbankzugriffe auf zwei Arten:
•
Explizite Zuweisung: über das Management-Studio oder mit den TSQL-Anweisungen GRANT,
DENY und REVOKE.
Beispiel: Dem Datenbankbenutzer SalesUser werden Leseberechtigungen für die Tabelle
sales.orders erteilt:
USE AdventureWorks
GRANT SELECT
ON sales.orders
TO SalesUser
© Mag. Christian Zahler, Stand: August 2011
69
SQL Server 2008 R2: Administration
•
Mitgliedschaft in einer StandardDatenbankrolle: So haben etwa
Mitglieder der Datenbankrolle
db_owner Administrationsrechte auf
die entsprechende Datenbank. Alle
Datenbankbenutzer sind
automatisch Mitglied der
Datenbankrolle public.
•
Mitgliedschaft in einer
benutzerdefinierten
Datenbankrolle: Es können auch
eigene Datenbankrollen erzeugt
werden.
5.6 Erteilen expliziter Objektberechtigungen im
Management Studio
Im Management-Studio ist das explizite Erteilen von Berechtigungen entweder von der Seite des zu
berechtigenden Datenbankbenutzers oder von der Seite des "Securables", also des Objekts, auf das
zugegriffen wird, konfigurierbar:
5.6.1 Benutzerseitige Berechtigungen
Eigenschaften des Datenbankbenutzers, Karteikarte "Sicherungsfähige Elemente":
70
© Mag. Christian Zahler, Stand: August 2011
SQL Server 2008 R2: Administration
© Mag. Christian Zahler, Stand: August 2011
71
SQL Server 2008 R2: Administration
5.6.2 Objektseitige Berechtigungen
Eigenschaften des Objekts (der Tabelle, Sicht usw.), Karteikarte "Berechtigungen":
72
© Mag. Christian Zahler, Stand: August 2011
SQL Server 2008 R2: Administration
© Mag. Christian Zahler, Stand: August 2011
73
SQL Server 2008 R2: Administration
5.7 Spezielle Datenbankbenutzer
Der Datenbankbenutzer dbo ist in allen Datenbanken standardmäßig vorhanden. Mitglieder der
Serverrolle sysadmin und die Anmeldung sa sind dem Datenbankbenutzer dbo zugeordnet.
Jedes Objekt, das von einem Mitglied der Serverrolle sysadmin erstellt wurde, gehört automatisch
dem Datenbankbenutzer dbo. Der Benutzer dbo kann nicht gelöscht werden.
Der Datenbankbenutzer guest ist ebenso in allen Datenbanken standardmäßig vorhanden, aber
deaktiviert. Er ermöglicht ohne Datenbankbenutzerkonto den Zugriff auf eine Datenbank.
5.8 Unterbrochene Besitzerkette
Der Datenbankbenutzer sollte Zugriff auf die Daten immer nur über Sichten oder gespeicherte
Prozeduren erhalten; eine direkte Abfrage einer Tabelle sollte verboten sein.
Daher könnte man folgende Berechtigungsstruktur einführen:
74
© Mag. Christian Zahler, Stand: August 2011