Sicherheit für DNN-Installationen Teil 7 - Zugriff auf die Datenbank

SQL Server - 21.10.2018

Sicherheit DNN SQL Server

Wir kennen es alle: Probleme mit dem Zugriff auf SQL-Server-Datenbanken lassen sich vermeiden, indem wir dem Konto welches auf den SQL Server zugreift, die Datenbank-Rolle db_owner für die DNN-Datenbank zuweisen (oder noch schlimmer: diesem Konto sysadmin-Rechte für die gesamte SQL-Server-Installation gewähren). Und wir ahnen auch, dass wir hier potentielle Löcher aufreissen. Was ist also vernünftig?

Dazu sollten wir uns zuerst einmal überlegen, was passieren kann: Irgendein Bösewicht (oder eine Bösewichtin) kommt aus welchem Grund auch immer an die Anmeldeinformationen eines Superusers (oder auch "Host-Benutzer" genannt). Damit hätte er (oder sie) Zugriff auf die Erweiterungen und könnte nun z.B. bösartige Module installieren, aber auch vorhandene Module deinstallieren oder ähnliches. Er (oder sie) könnte in der SQL-Konsole einiges anrichten, z.B. Daten manipulieren, Tabellen anlegen oder löschen, irgendwelche Trigger setzen, Benutzerkonten einrichten und Rechte zuweisen - oder was auch immer.

Es wäre schon schlimm genug, wenn so etwas passieren würde, und wir können sicher nicht alles einschränken, was ein Superuser so über das UI anrichten könnte. Wir könnten aber zumindest verhindern, dass er Module installiert oder Tabellen oder andere Datenbank-Objekte löscht, indem wir die Rechte des Benutzerkontos, das auf die SQL-Datenbank zugreift, etwas einschränken. Voraussetzung dafür ist aber die Möglichkeit, auf den SQL-Server zugreifen zu können (z.B. über SQL Server Management Studio) und die notwendigen Rechte dafür zu haben (sysadmin). Über die SQL-Konsole von DNN werden wir wahrscheinlich kein Glück haben...

Welche Rechte benötigt dieses Konto?

Hier laufen wir in das erste Problem. Natürlich benötiigt das Konto für die Installation von DNN oder Erweiterungen wesentlich mehr Berechtigungen als für den "laufenden" Betrieb. In diesem Fall müssen wir diese Rechte vorübergehend erhöhen, und danach wieder zurücksetzen. Datauf gehe ich am Ende dieses Artikels ein.

Im laufenden Betrieb genügen folgende Berechtigungen:

  • Daten lesen
  • Daten schreiben, ändern oder löschen
  • gespeicherte Prozeduren und Funktionen ausführen

Für die ersten beiden gibt es im SQL Server bereits vordefinierte Rollen (db_datareader und db_datawriter), das Ausführen von gespeicherten Prozeduren benötigt aber etwas mehr. Wir können das bewerkstelligen, indem wir eine zusätzliche Rolle (db_executor) anlegen, mit folgendem Skript ist dies ein leichtes:

USE [dnndev]
GO

-- Anlegen der Rolle db_executor
CREATE ROLE db_executor
GO

-- Dieser Rolle Ausführungsrechte erteilen
GRANT EXECUTE TO db_executor
GO

Nun bleibt uns nicht mehr viel zu tun. Wir müssen dem Login noch die db_owner-Rolle wegnehmen, und die anderen Rollen entsprechend setzen. Dazu wählen wir im SQL Server Management Studio (SSMS) unter Security (Sicherheit) :: Logins (Anmeldungen) den Benutzer aus, klicken den Eintrag mit der rechten Maustaste an und wählen Properties (Eigenschaften). In der linken Seite des Eigenschaftenfensters klicken wir auf User Mappings (Benutzerzuordnungen), markieren im rechten oberen Teil die Datenbank und ordnen im unteren Bereich die Rollen zu:

SQL Server Benutzerzuordnungen

Das war's dann auch schon. Wenn wir nun aber eine Erweiterung oder ein Update installieren, passiert folgendes:

Fehler beim Update

Kein Problem - alles was man tun muss ist der Application Pool-Identity (oder dem entsprechenden Benutzer) für den Zeitraum der Installation die Rolle db_owner zuweisen:

SQL Server Benutzerzuordnungen (db_owner)

Es gibt aber noch eine zweite - kaum bekannte - Möglichkeit, die bereits vor langer Zeit eingeführt wurde: der "upgradeConnectionString". Dazu ist aber ein SQL Server-Benutzer notwendig, es gibt keine Möglichkeit, im Connection String einen Windows-Benutzer mit Username und Passwort anzugeben oder im Upgrade-Prozess eine Impersonifizierung vorzunehmen.

Zuerst einmal überprüfen wir, welche Sicherheitseinstellungen im SQL Server vorgenommen wurden. Dazu klickt man im SSMS mit der rechten Maustaste auf den Server selbst, wählt Properties (Eigenschaften), und dann links Security (Sicherheit) und prüft die Authentifizierungseinstellungen. Diese müssen SQL Server- und Windows-Authentifizierung erlauben:

SQL Server Sicherheitseinstellungen

Als nächstes legen wir den Benutzer an. Dazu öffnen wir den Baum unter Security, klicken mit der rechten Maustaste auf Logins und im Kontextmenü auf New Login…. Zuerst füllen wir die allgemeinen Daten (unter General (Allgemein) aus:

  • Benutzername
  • SQL Server Authentication (SQL Server Authentifizierung) muss gewählt sein
  • ein sicheres Passwort sollte gewählt werden
  • Enforce password policy (Passwort-Richtlinie erzwingen) soll deaktiviert werden - wir wollen hier ja nicht bei der ersten Anmeldung oder in regelmäßigen Zeitabständen das Passwort ändern müssen. Daher ist es aber auch sehr wichtig, ein möglichst sicheres Passwort zu verwenden.
  • Die Default Database (Standarddatenbank) kann man auf die von der Installation verwendete Datenbank setzen (ist aber nicht muss)

Neue Anmeldung - Allgemeine Daten

Unter User Mappings (Benutzerzuordnungen) aktivieren wir dann die Datenbank und ordnen die Rolle db_owner zu:

Neue Anmeldung - Benutzerzuordnung

Zuletzt müssen wir in der Datei web.config noch den Connection String eintragen. Dazu sucht man nach "upgradeConnectionString" und trägt die Verbindungsdaten ein:

<data defaultProvider="SqlDataProvider">
   <providers>
   <clear />
      <add name="SqlDataProvider"
         type="DotNetNuke.Data.SqlDataProvider, DotNetNuke"
         connectionStringName="SiteSqlServer"
         upgradeConnectionString="Persist Security Info=False;User ID=DNN-Admin;Password=MySecret#123;Initial Catalog=dnndev;Data Source=MySQLServer"
         providerPath="~\Providers\DataProviders\SqlDataProvider\"
         objectQualifier=""
         databaseOwner="dbo" />
   </providers>
</data>

So funktionieren sowohl Upgrades als auch die Installation von Erweiterungen.

Weiter: Sicherheit für DNN-Installationen Teil 8 - "Hiding the obvious"