Nach der ersten Folge Serverseitige Datenbankprogrammierung, erzähle ich Ihnen in der zweiten Folge der Blogserie SQL Server 2014 ein wenig darüber, wie Sie die Zugriffsberechtigungen auf Ihre Datenbanken verwalten.

Hat man einmal eine Datenbank fertig erstellt, muss man noch dafür sorgen, dass all jene, die mit dieser Datenbank arbeiten sollen, den Zugriff auf diese bekommen. Andererseits soll die Ihre Datenbank nicht offen wie das sprichwörtliche Scheunentor sein, daher müssen Sie die Zugriffsberechtigungen gezielt vergeben. Selber hat man in der Praxis als derjenige der den SQL Server installiert hat als Administrator vorerst uneingeschränkten Zugriff auf den SQL Server und alle Datenbanken.

Login und User

Der Zugriff auf Datenbanken erfolgt beim Microsoft SQL Server in zwei Stufen. Mit dem Login (Anmeldung) meldet man sich auf dem Server an, mit dem User (Benutzer) greift man auf eine Datenbank zu. Dazu benötigt ein Anwender einen separaten Benutzer in jeder Datenbank, auf die zugegriffen werden soll. Das klingt auf den ersten Blick etwas kompliziert, ist es aber glücklicherweise bei genauerer Betrachtung nicht. Endanwender kommen nämlich nur mit dem Login in Kontakt. User werden den Logins direkt beim Anlegen zugeordnet. Für letztere gibt es kein Kennwort und nach dem Anmelden schlüpft man automatisch in die Rolle des zugeordneten Users. Um dabei den Überblick zu wahren, ist es in der Praxis sinnvoll, den einem Login zugeordneten Usern jeweils denselben Namen zu vergeben. Dies ist zwar keine technische Notwendigkeit, erleichtert aber die Verwaltung der Zugriffsberechtigungen.

Berechtigungen auf Systemebene werden an Logins erteilt. Dies kann zum Beispiel die Berechtigung zum Erstellen einer Datenbank oder jene zum Anlegen weiterer Logins sein. Das Zuweisen von Berechtigungen erfolgt in der Regel nicht direkt an einen Login, sondern wird indirekt durch die Mitgliedschaft in entsprechenden Serverrollen erteilt. Typischerweise erfolgt das Erteilen zusätzlicher Berechtigungen auf Serverebene nur an Administratoren und Entwickler, nicht an Endanwender. Dies benötigen auf Serverebene keine zusätzlichen Berechtigungen.

Das Zuweisen von Berechtigungen innerhalb einer Datenbank erfolgt an User, entweder direkt oder ebenfalls indirekt über Datenbankrollen. Mit den in jeder Datenbank bereits vordefinierten Datenbankrollen können Sie eine sehr einfache und rudimentäre Berechtigungsverwaltung umsetzen. So gibt es zum Beispiel eine Rolle mit dem Namen db_datareader, deren Mitgliedschaft den Lesezugriff auf alle Daten dieser Datenbank gewährt. Um den Schreibzugriff auf alle Daten einer Datenbank zu erlangen, genügt die Mitgliedschaft in der Rolle db_datawriter. Möchten Sie Berechtigungen differenzierter und granularer erteilen, empfiehlt es sich dazu benutzerdefinierte Datenbankrollen zu erstellen.

 

Datenbankzugriff

 

Wenn Sie sich fragen, was der Sinn der Aufsplitterung in Login und User ist, lässt sich das leicht erklären. An Logins erteilte Berechtigungen werden auf Serverebene in der Systemdatenbank master gespeichert. User, Datenbankrollen und die an sie erteilten Berechtigungen werden in der jeweiligen Datenbank selber gespeichert, ebenso wie die dazugehörigen Rollenmitgliedschaften. Dadurch wird das gesamte Berechtigungssystem einer Datenbank gemeinsam mit ihr bei einem Backup gesichert und kann wiederhergestellt werden. Auch wenn Sie ein Backup dazu nutzen, eine Datenbank auf einem neuen Server wieder einzuspielen, ist das gesamte Berechtigungssystem wieder vorhanden. Es müssen lediglich die entsprechenden Logins am neuen Server angelegt und mit den Benutzern in der Datenbank assoziiert werden – voila!

Authentifizierungsmodi

Der SQL Server kennt zwei unterschiedliche Arten der Authentifizierung. Jene über ein Windows-Konto oder über ein SQL Server-Konto. Schon bei der Installation des SQL Servers müssen Sie sich entscheiden, ob sie lediglich Windows-Authentifizierung aktivieren oder sich für den so genannten gemischten Modus entscheiden. Bei letzterem werden sowohl Windows- als auch SQL Server-Authentifizierung unterstützt. Für Windows-Authentifizierung werden Windows-Domänenkonten als Logins auf dem SQL Server registriert. Diese Variante hat für Endanwender den Vorteil, dass sie sich keinen weiteren Kontonamen samt Kennwort merken müssen. Für Entwickler entfällt das Handling des Kennwortes, da dies von Windows übernommen wird. Da diese Art der Authentifizierung nur für Domänenmitgliedern zugänglich ist, benötigen Sie für andere Anwender SQL Server-Logins samt Kennwort. Aber keine Angst, kein Domänenkonto erhält automatisch Zugriff auf den SQL Server. Jedes Konto muss zuvor als Login angelegt werden. Dabei wird die interne SID des Kontos auf dem SQL Server gespeichert. Dies kann einfach über folgende Anweisung bewerkstelligt werden:

CREATE LOGIN [domäne\kontoname] FROM WINDOWS;

Die eckigen Klammern um den Kontonamen herum sind notwendig, da mit den Schrägstrich ein Sonderzeichen enthalten ist. Sie können sowohl ein Benutzer- als auch ein Gruppenkonto dazu verwenden. Somit stellt die zweite Variante gewissermaßen eine Ausnahme dazu dar, dass ein neues Benutzerkonto nicht automatisch Zugriff auf einen SQL Server erlangt. Ich verwende in der Praxis Gruppenkonten gerne, um für mehrere Personen den Zugriff mit typischerweise niedrigen Berechtigungen zu vergeben. Somit ermögliche ich zum Beispiel einem ganzen Jahrgang eines Studienganges über deren Gruppenkonto den reinen Lesezugriff auf eine Datenbank zum Üben von SELECT-Statements.

Ein SQL Server-Konto erstellen Sie mit folgender Anweisung:

CREATE LOGIN anmeldename WITH PASSWORD = 'passwort';

Die Mitgliedschaft in einer Serverrolle erteilen Sie einem Login über diese Anweisung:

ALTER SERVER ROLE rollenname ADD MEMBER anmeldename;

User erstellen und Berechtigungen erteilen

Wie schon erwähnt, muss einem Login ein User in einer Datenbank zugeordnet werden, damit diesem der Zugriff auf diese Datenbank ermöglicht wird. Dazu muss man sich in der betroffenen Datenbank befinden, bevor man den User mit dieser Anweisung erstellt:

CREATE USER benutzername FOR LOGIN anmeldename;

Da Sie den Namen für den User explizit angeben, kann er auch vom Namen des zugeordneten Logins abweichen. Ich empfehle Ihnen das aber nicht, denn dies stiftet nur Verwirrung. Ein neu angelegter User ist lediglich Mitglied in der Datenbankrolle PUBLIC und darf daher vorerst nur das, dieser Rolle am Berechtigungen erteilt worden ist. Praktisch ist dies vorerst „nichts“. Um einem User die Mitgliedschaft in einer Datenbankrolle zu erteilen, können Sie die ALTER ROLE-Anweisung verwenden:

ALTER ROLE rollenname ADD MEMBER benutzername;

Spezifische Rechte werden an einen User oder eine Rolle mit der Anweisung GRANT erteilt, REVOKE entzogen und mit DENY explizit verweigert.

GRANT berechtigung ON objektname TO benutzer oder rolle;
REVOKE berechtigung ON objektname FROM benutzer oder rolle;
DENY berechtigung ON objektname TO benutzer oder rolle;

Eine Ausnahme stellen Mitglieder der Serverrolle sysadmin dar. Diese haben nicht nur alle Berechtigungen auf Serverebene, sondern auch Vollzugriff auf alle Datenbanken auf diesem Server. Dies ist der Fall, da sie in jeder Datenbank immer mit dem vordefinierten User dbo (=Database Owner) assoziiert werden, der fixes Mitglied der Datenbankrolle db_owner ist.

Contained Database

Eine Sonderstellung stellen die mit dem SQL Server 2012 eingeführten Contained Databases dar. Die Idee hinter dieses Sonderform ist, dass eine Datenbank auf einem Server ohne jegliche Verbindungen nach Außen auskommt und daher, wenn Sie auf einem anderen Server transferiert wird, ohne weitere Eingriffe sofort voll funktionsfähig ist. Daher werden in diesen Datenbanken auch Features, die Verbindungen nach Außen benötigen, nicht unterstützt. Dazu zählt beispielsweise Datenbank-Email, dem ich mich in meinem nächsten Blogbeitrag widmen werde.

Das Besondere am Handling von Contained Databases ist, dass sie ohne Login, nur über User direkt erreichbar sind. Denn Logins werden ja eben nicht in der Datenbank sondern auf Serverebene verwaltet. User melden sich also direkt an einer Contained Database an und haben keinerlei Zugriff auf irgendetwas außerhalb dieser Datenbank – sind also quasi nur Gast auf diesem Server.

Contained Database

Da diese User keinem Login zugeordnet sind, übernehmen Sie dessen Funktion. Sie haben entweder ein eigenes Kennwort für SQL Server-Authentifizierung oder sind für Windows-Authentifizierung direkt einem Domänenkonto zugeordnet. Die Anweisung zum Erstellen eines Users in einer Contained Database ist in der Syntax daher eine Mischform aus CREATE LOGIN und CREATE USER.

CREATE USER benutzername WITH PASSWORD = 'passwort';

Ein wenig ungewöhnlich wirkt die Anweisung zum Anlegen eines Users für den Einsatz von Windows-Authentifizierung in einer Contained Database.

CREATE USER [domäne\kontoname oder andere name] FOR LOGIN [domäne\kontoname];

Denn hier entsteht der Eindruck, dass sowohl ein User als auch ein LOGIN angelegt werden, dem ist aber nicht so. Sie können aber auch diese abgekürzte Variante verwenden, können dann aber keinen vom Windows-Konto abweichenden Usernamen vergeben:

CREATE USER [domäne\kontoname];

Rollenmitgliedschaften und Berechtigungen erteilen Sie auf dieselbe Art und Weise wie bei klassischen Datenbanken.

 

Konopasek, SQL Server 2014Ich hoffe, ich konnte Ihnen damit einen ersten Einblick in die Logik der Zugriffssteuerung mit dem Microsoft SQL Server geben. Wie Sie dazu im Detail vorgehen, lesen Sie im gerade neu erschienenen Buch SQL Server 2014. Der schnelle Einstieg. Hier finden Sie auch wertvolle Tipps, wie Sie indirekte Berechtigungen über den Einsatz von Views und Stored Procedures gezielt einsetzen können.

Im nächsten Beitrag wird es über den Einsatz von Datenbank Email gehen. Da lesen Sie, wie Sie direkt über den SQL Server aus Ihrer Datenbankanwendung heraus sehr einfach Mails versenden können. Aber auch Administratoren benötigen Datenbank-Email, um sich über bestimmte Vorgänge auf dem Server informieren zu lassen. Bis bald!