Authentifizierung und Authorisierung

Der Zugriff auf die Ressourcen eines SQL Servers ist in der Regel auf Programme und Benutzer einzuschränken, die der Administraotor als vertrauenswürdig befindet, und die den Zugriff auf die Ressourcen benötigen. Die Benutzer und Programme werden verallgemeinert als Principal bezeichnet, denen auf die gesicherten Ressourcen (Securable) mittels einer Permisson der Zugriff erlaubt, oder explizit verwehrt werden kann.

Sicherungsfähige Elemente (Securables) und ihre Besitzer

Die Verhältnisse im SQL- Server sind ähnlich wie in unserer kapitalistischen Welt: jedes wertvolle Ding hat einen Besitzer (owner) ! Die wertvollen Dinge sind hier die sicherungsfähigen Elemente, oder kurz Securables, wie Serverinstanz, Datenbanken, Datenbank- Schemen, Tabellen u.s.w..

Die gesamte Serverinstanz z.B. ist ein securable, die von den Systemadministratoren besessen wird. Sie dürfen mit ihr tun und lassen, wass sie wollen !

Der gesamte Inhalt eines Securables ist automatisch auch im Besitz des Besitzers. Möchte jemand auf den Inhalt zugreifen, dann benötigt er seine Genehmigung (permission). Die Genehmigung (oder auch Berechtigung) kann damit immer nur vom Besitzer erteilt werden.

Für Entitäten einer Datenbank, wie Tabellen und gespeicherte Prozeduren, wird der Besitzer durch ihre zwingende Zugehörigkeit zu einem Schema festgelgt. Datenbankbenutzer können Schemen direkt besitzen, und sind damit indirekt Besitzer aller enthaltener Entitäten.

Erstbesitz dem Schöpfer

Wie in der realen Welt gehört dem Schöpfer zunächst seine Schöpfung. Erzeugt ein Administrator eine Datenbank, dann ist er zunächst deren Besitzer. Als Datenbankbesitzer kann er wiederum Entitäten wie Tabellen und gespeicherte Prozeduren anlegen, die dann automatisch in seinem Besitz sind.

Die Besitzverhältnisse können sich auch ändern, indem z.B. mittels ALTER AUTHORIZATION ON ... TO ... der Besitz an einem securable an ein anderes Principal übertragen wird. Weiteres dazu siehe unten.

Mehrstufiger Zugriffsschutz

Beim Zugriff auf eine Entität in einer Datenbank sind mehrere Sicherheitsbarrieren zu überwinden, wie das Bild oben zeigt. Zuerst muss eine erfolgreiche Anmeldung an der Serverinstanz gelingen (Login). Dann muss die Anmeldung als Datenbankbenutzer in der Datenbank eingetragen sein, in welcher die gesicherte Entität aufbewahrt wird. Der Datenbankbenutzer wiederum muss über ausreichend Rechte verfügen, um auf die Ressource in gewünschter Art und Weise zuzugreifen.

Anmeldung am Server (Authentifizierung)

Die erste Barriere beim Zugriff ist das Login (Anmeldung am Server). Der Administrator kann dazu einem Prinzipal (Windows- Benutzer, SQL- Server Benutzerkonto, Zertifikat) eine Recht auf Anmeldung am Server erteilen oder entziehen.

Versucht ein Prinzipal auf den Server zuzugreifen, dann prüft dieser, ob ein Anmelderecht existiert. Wenn ja, dann gilt das Prinzipal als authentifiziert, und es wird eine Sitzung eröffnet. Die Sitzung ist mit der Verbindung (Connection) assoziiert, über die der Zugriff durch das Prinzipal auf den Server erfolgte.

Wurde einem Windows- Benutzer ein Anmlederecht eingeräumt, dann ist innerhalb einer Arbeitsgruppe oder Domäne beim Zugriff kein erneutes login mit Benutzername oder Passwort nötig. SQL Server vertraut der Authentifizierung von Windows.

Der SQL- Server kann auch unabhängig vom Betriebssystem eine Liste berechtigter Prinzipale verwalten, genannt SQL Server Logins. Diese werden direkt in Systemtabellen des SQL- Servers gespeichert. Ein Principal mit einem SQL Server Login muss sich vor dem Zugriff stets mit seinem Benutzernamen und Passwort authentifizieren.

Einstellen des Authentifizierungsmodus über SQL Server Management Studio:

Eigenschaften vom Server\Sicherheit

Vordefinierte Anmeldungen

Jede Instanz eines SQL Servers verfügt über vordefinierte Anmeldungen.

Auflisten aller Logins

exec sp_helplogins

Auflisten aller angemeldeten Benutzer

exec sp_who [ @login_name='login']

SQL- Server Logins

SQL- Server Logins ermöglichen es Anwendungen und Usern, die nicht durch eine AD- Domäne verwaltet werden, sich an den SQL Server anzumelden. Für jedes SQL Server Login wird dazu in der Tabelle sysxlogins ein Benutzername + Passwort gewspeichert. Im Folgenden wird das Anlegen der Benutzerkonten beschrieben.

use master
go
-- Um die folgende Abfrage auszuführen, muß man Mitglied der Rolle sysadmin sein
select * from sysxlogins
go

Anlegen eines SQL Benutzerkontos

Mit der gespeicherten Prozedur sp_addlogin kann ein neues SQL Server Login angelegt werden

sp_addlogin [ @loginame = ]'login'
[ , [ @passwd = ] 'password' ] 
[ , [ @defdb =  ] 'database' ]       -- Datenbank, mit der Benutzer nach der Anmeldung verbunden ist
                                            -- (Standard: master)
[ , [ @deflanguage = ] 'language' ]  -- Sprache

Kennwort ändern

Das Kennwort eines SQL Server Logins kann mittels der gespeicherten Prozedur sp_password geändert werden

sp_password [ [ @old = ] 'old_password' , ] 
{ [ @new =] 'new_password' } 
[ , [ @loginame = ] 'login' ]

Benutzerkonto löschen

Bestehende SQL Server Logins werden gelöscht mittels sp_droplogin

sp_droplogin <login>

Windows- Authentifizierung

Windows- Gruppen (Workgroup, AD) existieren unabhängig vom SQL- Server. Soll einem authentifizierten Windows- User ein Login am SQL Server möglich sein, dann muß er im Verzeichnis der gültigen Anmeldungen aufgenommen sein. Dieser Aufnahmeprozess wird als hinzufügen eines Windows- Prinzipal bezeichnet.

Um Windows- Benutzerkonten hinzuzufügen, ist ein eigenständiger Satz von gespeicherten Systemprozeduren vorhanden:

sp_grantlogin [ @loninname = 'loginname']
sp_revokelogin [ @loninname = 'loginname']
sp_denylogin [ @loninname = 'loginname']

Auslisten der Windows- Logins

select name from sysxlogins where name like '%\%'

Sicherheitsrichtline für lokale Anmeldung am Server

Das direkte Ausführen von Scripten auf dem Server wird aus Sicherheitsgründen in der Regel unterbunden, um den Server nicht unnötig zu belasten. Sollen trotzdem direkt auf dem Server interaktiv Skripte ausgeführt werden, dann ist folgende Einstellung an den lokalen Richtlinen notwendig:

start/programme/verwaltung/lokale Sicherheitsrichtlinien/lokale Richtlinien/
     Zuweisen von Benutzerrechten/lokal anmelden-> Gruppe der SQL- Benutzer hinzufügen

Zugriff auf Datenbanken

Vorauasetzung für den Zugriff auf eine Datenbank ist natürlich eine gelungene Authentifizierung (= Anmeldung) am SQL- Server.

Datenbankbenutzer (database user)

Die mehrstufige Absicherung des Datenzugriffs in SQL Server verhindert, dass eine erfolgreiche Anmeldung uneingeschränkten Zugriff auf die gehosteten Datenbanken eines Servers zur Folge hat. Der Administrator muss den Zugriff auf eine Datenbank explizit gewähren. Dies erfolgt mit dem Instrument des Datenbank- Benutzers (database user)

Mit dem Anlegen eines Datenbank Benutzer für ein Login wird innerhalb der Datenbank ein Prinzipal geschaffen, dem Zugriffsrechte auf Datenbankobjekte für das Login erteilt werden können. Der Datenbankbenutzer einer Datenbank ist defakto der Avatar des Logins in der Datenbank.

Datenbankbesitzer (database owner)

Ein besonderer Datenbank Benutzer, den jede Datenbank hat, ist der Datenbankbesitzer, kurz dbo. Jede Datenbank hat genau einen Besitzer. Dieser besitzt implizit alle Rechte auf eine Datenbank. Dem Besitzer gehört auch das Schema dbo per Default.

• man die Datenbank erstellt hat
• man mittels sp_changedbowner als Datenbankbesitzer zugewiesen wurde
• Mitglied der Serverrolle Sysadmin ist (z.B. sa)

Ist man als domaeneX/UserY angemeldet, und hat die Datenbank DMS erstellt, dann ist man in DMS auch automatisch der dbo.

Der DBO hat folgende Rechte:

• Mitglieder allen Datenbankrollen außer db_owner hinzufügen
• Datenbanken sichern und wiederherstellen
• Prüfpunkte mittels Checkpoint setzen
• Objektberechtigungen in der Datenbank erteilten

Der Besitzer einer Datenbank kann geändert werden. Mittels SSMS gelingt dies über die Eigenschaften des Server, Abteilung Files

Alternativ kann der Besitzer auch mit dem TSQL- Befehl ALTER AUTHORIZATION geändert werden: Doku TSQL

use master
go
-- Das Login sa (Sysadmin, SQL Benutzer) wird zum Besiter der Datenbank keplerBi
alter authorization on database::keplerBi to sa

Datenbankschemas

Ein Datenbankschema ist ein Namensraum für eine Teilmenge von Datenbankobjekten wie Tabellen, gepeicherten Prozeduren etc. Jedes Datenbankobjekt gehört zu genau einem Datenbankschema.

In SqlServer 2000 stellte sich die Beziehung zwischen Schemas und Benzutzer noch wie folgt dar:

Löschen des Benutzers Anton hatte zur Folge, dass das zugeordnete Datenbankschema plus den darin enthaltenen Entitäten wie Tabellen, gespeicherten Prozeduren etc. ebenfalls gelöscht wurden. Ein aus dem Unternehmen scheidender Mitarbeiter namens Anton, der viele bedeutende Datenbanken- Entitäten erschaffen hatte, blieb so dem Unternehmen ewig in Erinnerung...

Workarround dbo-Schema

Ein Workarround aus dieser Situation bot die Möglichkeit, alle Datenbankentitäten unter dem Schema des dbo anzulegen. Der dbo ist der vom System vordefinierte Datenbankbenutzer für den Datenbank- Besitzer. Das Login, für das der Datenbankbesitzer steht, ist austauschbar (siehe oben). Damit entkoppelt das dbo- Schema die Entitäten von denen sie erschaffenden, angemeldeten Benutzern (Logins).

Vollständige Entkopplung von Schema und Benutzer ab Version 2005

Diese enge Bindung von Benutzern und Schemen wurde in Sql Server 2005 aufgegeben. Schemen können jetzt völlig unabhängig von Benutzern definiert werden:

Schemabesitz

Einem Schema kann ein Datenbankbenutzer als Besitzer zugeordnet werden. In einer Sitzung kann der Datenbankbenutzer dann Entitäten in seinem Schema anlegen, bearbeiten und löschen, sowie Zugriffsrechte an den Entitäten im Schema anderen Datenbankbenutzern gewähren.

Der dbo als Besitzer einer Datenbank ist auch automatisch Besitzer des Schemas (unabhängig davon, wer als Schemabesitzer eingetragen ist), und kann damit in jedem Schema schalten und walten, wie er will.

Berechtigungen (Permissions)

Ein Besitzer wie der Systemadministrator ("besitzt" Datenbankinstanz) kann anderen Prinzipals den Zugriff auf seine Bsitztümer (securables) genehmigen oder explizit verwehren mittels folgender TSQL Befehle:

• GRANT permission ON securable TO principal Dem Prinzipal den Zugriff auf das securable genehmigen.
• DENY permission ON securable TO principal Zugriffe und Ausführungsrechte werden explizit verboten. Vorausgegangene oder nachfolgenden Genehmigungen werden stets von diesem Verbot überschrieben ! Verbote haben Vorrag vor Genehmigungen.

  

  Im Bild bekommen der gute, als auch der böse Smiley der Reihe nach Genehmigungen als auch Verbote für den Zugriff auf Ressource A erteilt. Beide haben am Ende jedoch keinen Zugriff, da auch ein vorausgegangens Verbot (2. für bösen Smiley) eine nachfolgend erteilte Genehmigung außer Kraft setzt.
• Revoke Ein bestehende Genehmigung oder ein bestehendes Verbot werden gelöscht.

  

Achtung: Verbote haben Vorrang vor einer Erlaubnis ! Z.B. wird durch ein aus Mitgliedschaft geerbtes Verbot einer Rolle eine mögliche individuelle Erlaubnis für einen Datenbankbenutzer eliminiert.

Typen von Berechtigungen

An wen können Serverberechtigungen erteilt werden

• Windows- Benutzer

• Windows- Gruppe

• SqlServer Benutzerkonto

An wen können Datenbankberechtigungen erteilt werden

• Datenbankbenutzer

• Datenbankrolle

Datenbankrollen

Die Zusammenfassung einer Menge von Datenbankbenutzern kann analog den Gruppen in der Windowsadministration durch sog. Rollen erfolgen. Die Berechtigungen einer Rolle übertragen sich auf die in der Rolle enthaltenen Benutzer.

db_owner, db_ddladmin

Alle Mitglieder der Rolle db_owner haben die gleichen Rechte wie dbo. Demgegenüber können die Mitglieder von db_ddladmin nur DDL- Befehle ausführen.

Objekte, die von Mitgliedern der Gruppe db_owner und db_ddladmin erstellt werden, haben per Default den Namen UserName.Objektname.

db_accessadmin

Mitglieder dieser Gruppe können Datenbankbenutzer verwalten

db_securityadmin

Mitglieder dieser Gruppe können über Berechtigungen den Zugriff auf Datenbanken steuern (Sicherheit), indem sie die Befehle Grant und Revoke ausführen dürfen.

db_backupoperator

Mitglieder dieser Gruppe können Datensicherungen auf der Datenbank durchführen

db_datareader

db_datawriter

db_denydatareader

Mitglieder dieser Gruppe dürfen kein Select auf einer Datenbank durchführen. So kann ein Datenbankadministrator durch Mitgliedschaft in db_ddladmin befähigt werden, Tabellen einzurichten, durch seine Mitgliedschaft in db_denydatareader kann ihm das Lesen vertraulicher Daten untersagt werden -> Ü

db_denydatawriter

Kein Insert, Update, Delete