Datenbanken sind ein maßgeblicher Bestandteile der meisten unserer Anwendungen und die darin gespeicherten Informationen sind üblicherweise absolut schützenswert. Seien es geheime Firmendaten oder Informationen über Kunden, die als personenbezogene Daten zusätzlich der strengen Datenschutzgrundverordnung (DSGVO) unterliegen.

Worum auch immer es sich handelt, der Zugriff muss so stark wie möglich abgesichert werden!

Absichern - aber wie?

Die Datenbank ist in der Komponentenkette zwischen Anwender und Datenspeicher üblicherweise ganz hinten angesiedelt. Vorgeschaltete Komponenten kümmern sich um die Authentifizierung und Autorisierung des Anwenders, validieren die Eingaben, führen Protokoll über die durchgeführten Aktionen und greifen gezielt und performanceoptimiert auf die Daten zu.

Und damit kommen wir auch schon zum Thema dieses Artikels…die Frage ist nämlich, in welchem Benutzerkontext der Zugriff auf die Datenbank am besten erfolgen soll!

Der folgende Artikel beschäftigt sich mit diesem Thema, betrachtet diverse Entscheidungskriterien und weist auf kritische Konstellationen hin. Dabei werden auch Varianten betrachtet, die ausschließlich auf der Microsoft Windows Plattform verfügbar sind.
Bevor es nun aber um die Anmeldung am Datenbankserver geht, betrachten wir zwei Architekturformen die einen gravierenden Einfluss auf die Entscheidung haben.

Grundlegende Architekturformen

2-Tier Architektur (Client-Server)

Diese Architektur ist (vor allem) bei (älteren) Desktop-/Rich Client-Applikationen weit verbreitet und bedeutet üblicherweise, dass der Anwender eine Applikation auf seinem Rechner installieren muss, die dann über eine direkte Verbindung mit der Datenbank kommuniziert.

Diese Architektur ist besonders kritisch wenn es um den Zugriffsschutz geht!

Betrachten wir, was diese Architektur so kritisch macht!

1. Der Arbeitsplatz des Anwenders benötigt direkten Netzwerkzugriff auf das Datenbanksystem.
   Bei Microsoft SQL Server bedeutet das in der Standardkonfiguration, dass der Datenbankserver über Port 1433 erreichbar sein muss.
   Rein aus Netzwerksicht ist es somit möglich, dass der Anwender eine ODBC-Verbindung einrichten oder z.B. das Microsoft SQL Server Management Studio für direkte Zugriffe verwenden könnte.
   Selbst wenn der Port des Datenbankservers abgeändert wurde, kann dieser durch Verwendung eines Port-Scanners bestimmt werden.
2. In der installierten Applikation muss die Adresse des Datenbankservers hinterlegt sein, sodass es für den Anwender recht einfach möglich ist, diese Adresse herauszufinden.
   Selbst wenn die Adresse gut versteckt oder verschlüsselt abgespeichert wäre, ermöglichen Tools wie Process Monitor, TCPView oder andere Netzwerkmonitore es dem findigen Anwender diese zu ermitteln.
3. Alle aus der Datenbank geladenen Daten werden auf den Arbeitsplatz des Anwenders übertragen, was vor allem dann kritisch zu betrachten ist, wenn die Daten, die dieser Anwender eigentlich NICHT sehen darf, erst in der Applikation herausgefiltert werden.
   Es wäre also durch den Einsatz diverser Debugging-Tools möglich, die zusätzlich geladenen Daten abzugreifen.
4. Und nun zu dem Punkt, um den sich dieser Artikel in weiterer Folge dreht:
   Für den Zugriff auf die Datenbank muss sich die Applikation authentifizieren, sich am Datenbankserver anmelden.
   Vereinfacht gesprochen kann das entweder im Kontext des Benutzers erfolgen, den der Anwender verwendet (Stichwort Windows Integrated Security bzw. Trusted Connection) oder aber im Kontext eines technischen Benutzers.
   Ein Zugriff im Kontext des Benutzers des Anwenders würde bedeuten, dass dieser auch mittels Datenbankwerkzeugen (siehe Punkt 1 und 2) auf die Datenbank zugreifen könnte.
   Ein Zugriff im Kontext eines technischen Benutzers würde erfordern, dass die Applikation die dafür notwendigen Zugangsdaten kennen muss.

3-Tier Architektur

Bei modernen Desktop-/Rich Client- sowie bei Web-Applikationen ist diese Architektur üblich. Die drei Schichten bezeichnen

1. Frontend/UI Layer
2. Backend/Business Layer
3. Database/Data Layer

wobei es durchaus weitere Schichten dazwischen geben kann.

Diese Architektur hat in Bezug auf den Zugriffsschutz einige Vorteile:

1. Die Applikation greift nicht direkt vom Arbeitsplatz des Anwenders auf die Datenbank zu.
   Die installierte Desktop- bzw. aufgerufene Web-Applikation kommuniziert mit den entsprechenden Services im Backend und benutzt dafür üblicherweise ein HTTP-basiertes Protokoll wie REST oder SOAP (natürlich verschlüsselt über HTTPS). Diese Services führen Authentifizierung, Autorisierung, Validierung und Protokollierung durch und führen ggf. den Zugriff auf den Datenbankserver aus.
   Der erste Vorteil ist also, dass vom Arbeitsplatz des Anwenders keine direkte Netzwerkverbindung zum Datenbankserver möglich sein muss - bzw. diese im Optimalfall bewusst unterbunden wird!
   Das wehrt den Versuch, mit Datenbankwerkzeugen direkt auf die Daten zuzugreifen, ab.
2. Die Applikation, die der Anwender auf seinem Arbeitsplatz verwendet, muss nur die Adresse der Backend-Services kennen, jedoch nicht die des Datenbankservers.
   Es ist für den Anwender somit grundsätzlich nicht einfach möglich, den Namen des Datenbankservers bzw. dessen IP-Adresse und Port herauszufinden um direkte Zugriffe zu versuchen. Vorausgesetzt natürlich, die Backend-Services geben im Fehlerfall keine technischen Detailinformationen an den Client zurück, die auf diese Informationen schließen lassen!
3. Aus der Datenbank geladene Daten können (falls notwendig) in den Backend-Services nocheinmal gefiltert werden, bevor sie an den Client geschickt werden.
   So könnten über die Zugriffsrechte des Anwenders hinausgehende Daten nur auf den Backend-Servern abgegriffen werden, was schon deutlich mehr Kenntnis über das System und je nach Betriebsinfrastruktur auch Zugriffs- bzw. Zutrittsberechtigungen zu den Servern erfordert.
   Prinzipiell ist es allerdings in jedem Fall empfehlenswert nur die Daten aus der Datenbank zu laden, die auch wirklich benötigt werden!
4. Auch hier muss eine Authentifizierung zwischen Backend-Services und Datenbank erfolgen.
   Unterstützen die Backend-Services die Impersonierung des vom Client zugreifenden Benutzers, kann der Zugriff auf die Datenbank ebenfalls im Kontext des Benutzers des Anwenders erfolgen. Der klare Vorteil der 3-Tier Architektur ist, dass das Benutzerkonto des Anwenders zwar auch Rechte in der Datenbank braucht, dieser aber aufgrund der netzwerktechnischen Trennung trotzdem nicht direkt darauf zugreifen kann.
   Ein Zugriff im Kontext eines technischen Benutzers ist auch hier eine gängige Variante, die das Hinterlegen der Zugangsdaten ebenfalls erfordert. Diesmal allerdings nicht am Arbeitsplatz des Anwenders sondern auf einem Server, was wiederum den Zugriff auf diese Daten für einen potentiellen Angreifer erschwert.
   Betreibt man die Backend-Services in der Microsoft Azure Cloud, kann man sich zusätzlich die Azure Managed Identities für den Datenbankzugriff zu Nutze machen. Die empfehlenswerteste aller Optionen - siehe später!

Wichtiger Punkt: Der Zugriff vom Frontend auf das Backend muss ebenfalls gut abgesichert werden! Dies ist jedoch nicht Bestandteil dieses Artikels!

Authentifizierung

Kommen wir nun zum eigentlichen Thema des Artikels - der Authentifizierung, also der Anmeldung am Datenbankserver.

Zugriff im Kontext des Benutzers des Anwenders (Windows Integrated Security bzw. Trusted Connection)

Für Applikationen, die im Intranet eines Unternehmens betrieben werden, das alle Benutzer und Geräte in einem Active Directory verwaltet, ist dies durchaus eine spannende Möglichkeit. Es ermöglicht den Kontext des zugreifenden Benutzers über alle Schichten transportieren und ihn so jederzeit identifizieren zu können. So lassen sich z.B. Protokollierungsmechanismen darauf aufsetzen.

Vorteile:

• Der zugreifende Benutzer ist über alle Schichten hinweg bekannt und identifizierbar.
• Am Arbeitsplatz sind keine Zugangsdaten zu hinterlegen, da der Kontext des angemeldeten Benutzers (bzw. der Kontext des Benutzers, in dem die Applikation ausgeführt wird) für den Zugriff herangezogen wird.
  • Nur der Anwender muss wissen, wie er sich am System authentifizieren kann.
  • Die Authentifizierungsmethode ist flexibel, sodass neben Benutzername/Passwort auch Smartcard, Fingerprint, … verwendet werden können. Möglich ist alles, was Windows zur Systemanmeldung anbietet.
  • Falls der Benutzer sein Passwort ändert, hat das keine Auswirkung auf die Datenbankverbindung.
• Sind am Datenbankserver Verbindungen zu weiteren Servern konfiguriert (Linked Server), kann der Benutzerkontext auch über diese Verbindungen weiter transportiert werden.
• Werden in der Datenbank Ad-hoc Distributed Queries verwendet (z.B. in Views oder Stored Procedures) um auf andere Datenbanken zuzugreifen, kann der Benutzerkontext auch darüber zur Zieldatenbank transportiert werden.
• Bei mehrschichtigen Architekturen können beispielsweise auch Dateizugriffe im Kontext des Benutzers ausgeführt werden (z.B. um private Dokumente zu lesen).

Nachteile:

• Der Benutzer des Anwenders muss eine Zugriffsberechtigung für die Datenbank haben, was (vor allem bei einer 2-Tier Architektur) äußerst kritisch zu betrachten ist.
  Üblicherweise ist es Anforderung, dass der Anwender die Daten nur durch die dafür vorgesehene Applikation einsehen bzw. bearbeiten darf. Greift die Applikation also in seinem Kontext zu, muss sein Benutzerkonto die notwendigen Lese- und Schreibrechte besitzen.
  • In einer 2-Tier Architektur würde das bedeuten, dass der Anwender diese Berechtigungen über andere Datenbankwerkzeuge ebenfalls nutzen und somit an der Applikation vorbei auf die Daten zugreifen könnte. Das darf keinesfalls möglich sein!
    Daher ist es in diesem Fall unbedingt empfehlenswert Application Roles zu verwenden (siehe später).
  • In einer 3-Tier Architektur hat der Anwender (aus Netzwerksicht) üblicherweise keinen direkten Zugriff auf das Datenbanksystem, wodurch der direkte Zugriff über Datenbankwerkzeuge gar nicht möglich wäre. Dennoch ist zu evaluieren, ob die Verwendung einer Application Role auch in diesem Szenario eine gute Entscheidung wäre! Darf der Anwender zur Auswertung und Bearbeitung der Daten auch andere Werkzeuge (z.B. Microsoft Excel oder Microsoft Access) verwenden, fällt dieser Nachteil weg.
• Funktioniert nur unter Microsoft Windows.

Application Role

Zeit um aufzuklären, worum es sich dabei handelt.

Wie der Name andeutet, ermöglicht eine Application Role einer Applikation das Einnehmen einer besonderen Rolle. Eine solche Rolle wird definiert durch eine Menge an Berechtigungen, wie sie beispielsweise auch an Benutzer vergeben werden kann.
Vor allem wenn der Zugriff auf die Datenbank im Kontext des am Client angemeldeten Benutzers erfolgen soll, ermöglicht die Application Role eine restriktivere Steuerung der Berechtigungen.

Am deutlichsten wird es mit einem Beispiel:

• Der Anwender ist mit dem Benutzer COMPANY\max auf seinem Arbeitsplatz angemeldet und verwendet die Client-Server Applikation ImportantApp.
• Diese Applikation greift auf die Datenbank ImportantAppDB am Datenbankserver IMPORTANTSQLSRV.company.at zu.
• Das Konzept sieht vor, dass der Zugriff auf die Datenbank im Kontext des angemeldeten Benutzers erfolgt, die Daten jedoch nur über diese Applikation bearbeitet werden dürfen. Die Auswertung der Daten ist dem Anwender auch mit anderen Werkzeugen (z.B. Microsoft Access) erlaubt.
  Somit erhält der Benutzer COMPANY\max die Berechtigung, sich auf die Datenbank zu verbinden und die Daten zu lesen (GRANT SELECT ...).
  ABER: Der Benutzer erhält keine Rechte um Daten zu schreiben! (DENY INSERT, UPDATE, DELETE)
• Ebenfalls wird die Application Role ImportantAppRole eingerichtet und ihr alle Berechtigungen erteilt.
  CREATE APPLICATION ROLE ImportantAppRole WITH PASSWORD = '<ImportantAppRolePassword>';
GRANT ALL ON ImportantTable TO ImportantAppRole;
• Der Anwender startet nun die Applikation ImportantApp welche sich zur Datenbank im Kontext des Benutzers COMPANY\max verbindet.
• Da dieser Benutzer nur Lese- jedoch keine Schreibrechte besitzt, muss die Applikation die zuvor eingerichtete Application Role ImportantAppRole aktivieren. Die Applikation ermittelt daher das dafür notwendige Passwort, welches verschlüsselt in seiner Konfiguration liegt und führt folgendes SQL-Kommando aus:
  EXEC sys.sp_setapprole 'ImportantAppRole', '<ImportantAppRolePassword>';
• Durch das SQL-Kommando wird die Application Role für die Datenbankverbindung aktiviert sodass die Applikation nun auf die Daten sowohl lesend als auch schreibend zugreifen kann.
• Der Anwender entschließt sich nun, mittels dem Microsoft SQL Server Management Studio auf die Datenbank zuzugreifen und verbindet sich zur Datenbank ImportantAppDB@IMPORTANTSQLSRV.company.at.
  Die Verbindung wird aufgebaut und er kann alle Daten abfragen. Verändern kann er sie jedoch nicht.

Soviel zur Funktionsweise einer Application Role. Sie ermöglicht es also einer Anwendung, die in Kenntnis des Namens der Application Role sowie des dazugehörigen Passwortes ist, erweiterte Rechte zu bekommen und so ihre Aufgaben zu erfüllen.
Wie zuvor schon erwähnt ist die Verwendung einer Application Role unerlässlich, wenn der Zugriff auf die Datenbank im Kontext des aufrufenden Benutzers erfolgt, dieser auf die Daten nur durch die Applikation jedoch nicht über andere Datenbankwerkzeuge (manipulierend) zugreifen können soll und es sich um eine 2-Tier Architektur handelt.

Empfehlung: Sollen mehrere Applikationen auf dieselbe Datenbank zugreifen, sollte für jede Applikation eine eigene Application Role mit den notwendigen Rechten angelegt werden.

Achtung! Im Beispiel ist beschrieben, dass die Applikation zur Aktivierung der Application Role ein Passwort benötigt! Es muss daher eine sichere Möglichkeit geschaffen werden dieses Passwort zu hinterlegen, denn das zur Aktivierung zuständige T-SQL-Kommando kann problemlos auch in anderen Datenbankwerkzeugen ausgeführt werden um die erhöhten Zugriffsrechte zu erlangen.

Zugriff im Kontext eines technischen Benutzers

Bei dieser Variante wird ein vom Anwender unabhängiger Benutzer für den Zugriff auf die Datenbank verwendet. Es gibt dabei zwei Varianten von Benutzern, die dafür verwendet werden können.

SQL Server Benutzer

Am Datenbankserver wird ein eigener Benutzer (SQL Server Benutzer) angelegt. Dieser erhält ein möglichst starkes Passwort und die notwendigen Rechte.

Vorteile:

• Es müssen keine datenbankspezifischen Konstrukte zur Isolierung von Benutzer- und Applikationsrechten (in Form von Application Roles) angelegt werden.
• Die Angabe von Benutzername und Passwort ist in allen Datenbank-Clientbibliotheken unterstützt.
• Der Benutzer des Anwenders benötigt keinerlei Rechte am Datenbankserver.
• Plattformunabhängig.

Nachteile:

• Der vom Client zugreifende Benutzer ist auf der Datenbank nicht mehr bekannt, da der Zugriff im Kontext des technischen Benutzers erfolgt.
• Die Zugangsdaten des technischen Benutzers müssen gesichert und verschlüsselt konfiguriert werden, da sie ansonsten zur Herstellung einer Verbindung mit anderen Datenbankwerkzeugen verwendet werden können.
• Das Passwort des technischen Benutzers kann nicht so einfach geändert werden.
  Wurde es bekannt und aus diesem Grund serverseitig geändert, muss die notwendige Konfigurationsänderung für die Applikationen rasch ausgerollt werden können, um die Funktionalität weiterhin zu gewährleisten.
• Sind am Datenbankserver Verbindungen zu weiteren Servern konfiguriert (Linked Server), muss ein entsprechendes Login Mapping eingerichtet werden.
• Werden in der Datenbank Ad-hoc Distributed Queries verwendet (z.B. in Views oder Stored Procedures) um auf andere Datenbanken zuzugreifen, müssen die Verbindungsparameter (Connection String) die Zugangsdaten für den Zielserver beinhalten.

Active Directory Benutzer

Im Active Directory wird ein eigener Benutzer mit einem starken Passwort angelegt. Die Optionen, dass das Passwort bei der ersten Anmeldung bzw. periodisch geändert werden muss, werden deaktiviert. Schließlich wird der Benutzer am Datenbankserver als Login angelegt, als User in den Datenbanken gemappt und mit den notwendigen Rechten.

Vorteile:

• Es müssen keine datenbankspezifischen Konstrukte zur Isolierung von Benutzer- und Applikationsrechten (in Form von Application Roles) angelegt werden.
• Die Verbindung wird mittels Windows Integrated Security bzw. Trusted Connection authentifiziert, was alle Datenbank-Clientbibliotheken auf Microsoft Windows unterstützen.
• Der Benutzer des Anwenders benötigt keinerlei Rechte am Datenbankserver.
• Handelt es sich um eine Service-Anwendung (z.B. Windows-Dienst), kann diese sehr einfach im Kontext des technischen Benutzers gestartet werden.
• Sind am Datenbankserver Verbindungen zu weiteren Servern konfiguriert (Linked Server), kann der Kontext des technischen Benutzers auch über diese Verbindungen weiter transportiert werden.
• Werden in der Datenbank Ad-hoc Distributed Queries verwendet (z.B. in Views oder Stored Procedures) um auf andere Datenbanken zuzugreifen, kann der Kontext des technischen Benutzers auch darüber zur Zieldatenbank transportiert werden.

Nachteile:

• Der vom Client zugreifende Benutzer ist auf der Datenbank nicht mehr bekannt, da der Zugriff im Kontext des technischen Benutzers erfolgt.
• Die Zugangsdaten des technischen Benutzers müssen gesichert und verschlüsselt konfiguriert werden, da sie ansonsten zur Herstellung einer Verbindung mit anderen Datenbankwerkzeugen verwendet werden können.
• Handelt es sich um eine Client-Anwendung, muss die Applikation zuvor eine Anmeldung und Impersonierung des technischen Active Directory Benutzers durchführen, bevor die Verbindung zur Datenbank hergestellt werden kann. Unmittelbar nachdem die Verbindung aufgebaut wurde kann die Impersonierung wieder zurückgenommen werden, sodass die Applikationslogik wieder im Kontext des aufrufenden Benutzers weiterlaufen kann.
  Alle Zugriffe auf das System (z.B. Registry, Dateisystem) während der Herstellung der Datenbankverbindung erfolgen im Kontext des impersonierten Benutzers. Es können also z.B. keine Zugriffe auf persönliche Dokumente des Anwenders durchgeführt werden, da der technische Benutzer auf diese keine Zugriffsberechtigung hat.
  Die SQL Server Management Objects führen leider teilweise solche Zugriffe aus und lösen dadurch Fehler aus. Es ist also nicht sichergestellt, dass diese Methode mit jeder Datenbank-Clientbibliothek funktioniert. Workaround: Die SQL Server Management Objects werden in eine externe Applikation ausgelagert, die dann zur Durchführung der notwendigen Aktionen im Kontext des technischen Active Directory Benutzers ausgeführt wird (Stichwort CreateProcessAsUser).
• Das Passwort des technischen Benutzers kann nicht so einfach geändert werden.
  Wurde es bekannt und aus diesem Grund im Active Directory geändert, muss die notwendige Konfigurationsänderung für die Applikationen rasch ausgerollt werden können, um die Funktionalität weiter zu gewährleisten.
• Funktioniert nur unter Microsoft Windows.

Azure Managed Identity

Abschließend noch eine Authentifizierungsvariante, die es allerdings nur im Umfeld von Microsoft Azure gibt.

Die sogenannten Azure Managed Identities im speziellen die System Assigned Managed Identities ermöglichen es, Berechtigungen direkt an Azure-Ressourcen zu vergeben. Im Bereich des Datenbankzugriffs bedeutet das, dass man einer Web-Applikation die Berechtigung erteilen kann auf diese Datenbank zuzugreifen.
Das Einrichten eines eigenen Benutzerkontos inkl. Passwort ist dabei gar nicht mehr nötig. Das wird von Azure vollautomatisch im Hintergrund verwaltet, sodass man sich auch über die gesicherte Ablage der Zugangsdaten oder Passwortänderungen keine Gedanken mehr machen muss!

Für in Microsoft Azure betriebene Applikationen ist diese Variante meine absolute Empfehlung!
Details dazu sowie eine Implementierungsanleitung folgen in einem separaten Artikel.

Anregungen zu weiteren Konstellationen oder Fragen bitte entweder per Email.

Weiterführende Informationen

• Application Roles (Microsoft, Englisch)
• Azure Managed Identity (Microsoft, Englisch)
• Titelbild (Pixabay)

Glossar

• Anwender
  Als Anwender wird eine Person, ein Mensch bezeichnet. Diese Person bedient den Rechnet bzw. die Applikation.
• Benutzer Damit ist das technische Benutzerkonto gemeint, mit dem der Anwender am Rechnet angemeldet ist bzw. unter dem die Applikation gestartet wurde.
  Jeder Anwender kann mehrere Benutzer verwenden.