In dem fünften Teil der Blogserie „IT Security in Web Anwendungen“ thematisieren wir Datenbanken, die sichere Konfiguration und Kommunikation sowie praktische Werkzeuge zum Monitoring und Betrieb. Anhand konkreter Beispiele – auf SQL- und Betriebssystembasis – wollen wir die wichtigsten Punkte im Bezug auf IT-Security im Datenbank-Umfeld aufzeigen und Best Practices auflisten.
In unserem ersten Post dieser Blogserie sind wir das Thema „Injections“ angegangen und haben gezeigt, wie diese zustandekommen bzw. zu verhindern sind. In dem zweiten Teil der Serie sind wir auf File Up-/Download und Storage eingegangen und haben allgemeine Sicherheitsrisiken sowie Prävention und Alternativen aufgelistet. In dem dritten Teil thematisieren wir Sessions und Session Hijacking-Attacken sowie einen möglichen Schutz gegen solcher Attacken. Der vierte Teil thematisierte das HTTP(S)-Protokoll im Allgemeinen und ist auf sicherheitsrelevante Aspekte eingegangen.
In dem kommenden Posts der Blogserie möchten wir uns tiefergehend mit den verschiedenen Bereichen der IT Security beschäftigen. In insgesamt neun Blogposts möchten wir tiefergehend auf verschiedene Szenarien eingehen, mögliche Schutzmechanismen präsentieren und diese – wenn möglich – durch praktische Beispiele demonstrieren. Nach Blogpost #9 werden wir diese Serie und weitere Tipps und Tricks als PDF zur Verfügung stellen. Sie können sich unter dem nachfolgenden Formular zum Newsletter anmelden, um das PDF zu erhalten:
[newsletters_subscribe form=3]
Betrieb von Datenbank und Webserver
Wie auch Web Anwendungen, laufen Datenbanken auf einem Webserver und stellen Schnittstellen zur Laufzeit für Programme zur Verfügung um Daten abzufragen, zu speichern oder zu modifizieren. Waren Open-Source-Datenbanken wie MySQL oder dessen Fork MariaDB in den letzten Jahren quasi der Standard im Web-Umfeld, ist dies heutzutage nicht mehr selbstverständlich. Alternative relationale Datenbanken wie PostgreSQL oder NoSQL-Lösungen wie MongoDB kommen immer mehr zum Einsatz und bieten eine gute Voraussetzung für performante und skalierbare Web Anwendung.
Mit Oracle RDBMS und Microsoft SQL sind auch proprietäre Alternativen vorhanden, wobei Microsoft die eigene SQL-Implementierung unter einer Open-Source-Lizenz veröffentlich hat. Insbesondere Oracle ist im Enterprise-Umfeld (z.B. Banken und Versicherungen) sehr beliebt und finden weitläufig Einsatz.
Meist laufen Datenbanken auf Linux-Servern, jedoch gibt es auch Windows Server sowie weitere kleinere Betriebssysteme und Anbietende. Neben Datenbanken laufen meist Webserver auf einem Betriebssystem um Anfragen über z.B. HTTP(S) entgegenzunehmen und statische bzw. dynamische Webseiten zur Verfügung zu stellen. Die Bekanntesten sind Apache Webserver und Nginx bzw. „Microsoft Internet Information Services“ (kurz: IIS) für Windows.
Datenbank-Security fängt bei dem Betriebssystem an
Datenbanken sind sehr eng verknüpft mit dem Betriebssystem und daher wundert es nicht, dass grundlegende Sicherheitskonfigurationen auf Betriebssystemebene gemacht werden müssen. Bei einfachen Anwendungen, die Applikation und Datenbank auf dem selben Server hosten, sollte die Datenbank nach außen hin nicht erreichbar sein. Beispielsweise kann bei MySQL der Port 3306 geschlossen werden, damit Angreifende die Möglichkeit entbunden wird zu attackieren. Des Weiteren kann in der MySQL-Konfigurationsdatei angegeben werden, dass Verbindungen nur über localhost akzeptiert werden (bind-address Direktive). Sind Applikation und Datenbank auf dem selben Server, ist das Setzen dieser Direktive von sehr hoher sicherheitskritischer Bedeutung.
Laufen Datenbank und Applikation auf verschiedenen Servern sollte die Datenbank hinter einer Firewall stehen und im Idealfall über ein Protokoll (z.B. HTTP(S)) kommunizieren. Datenbankports sollten auch in diesem Fall nicht offen sein, da auf der einen Seite die Gefahr durch Misskonfiguration und somit das Offenstehen für das Internet besteht, zum anderen aber auch eine Gefahr durch „interne“ Angreifende vermieden wird. Werden Daten über das HTTP(S) zu Verfügung gestellt und eine direkte Verbindung über den Datenbankport verboten, sollte auch hier die bind-address auf localhost gesetzt werden.
Der Server, auf dem die Datenbank betrieben wird, sollte darüber hinaus weitere sicherheitsrelevante Aspekte beachten. Die wichtigsten von diesen sind:
- das Betriebssystem immer aktuell halten, Sicherheitspatch so schnell wie möglich einspielen,
- Den Zugriff auf IP-Adressen legitimer Server limitieren,
- Backups (auch oder insbesondere von der Datenbank) erstellen,
- Umgebungen separieren, Produktionsumgebung stark isolieren.
Daten- und Kommunikationsverschlüsselung für Datenbanken
Nahezu alle Datenbanksysteme (RDBMS, NoSQL, etc.) ermöglichen die unsichere Kommunikation über eine nichtverschlüsselte Verbindung. Das bedeutet, dass der gesamte Datenverkehr unverschlüsselt stattfindet und (sensible) Informationen im Klartext über das Netz gesendet werden. Jedoch bestehen auch hier viele Konfigurationsmöglichkeiten um das Datenbanksystem sicherer und robuster zu gestalten. So bieten nahezu alle Anbietende die Möglichkeit, unsichere Verbindungen abzulehnen. In der PostgreSQL-Konfigurationsdatei muss beispielsweise zunächst
alter system set ssl=on;
und anschließend in der pg_hba.conf der Typ von host auf hostssl gesetzt werden, um alle Verbindungsanfragen über unsichere Kommunikation abzulehnen. Des Weiteren können neben „gültigen“ Zertifikaten (also jene, die von einer vertrauenswürdigen Certificate Authority (CA) ausgestellt wurden) auch selbstsignierte (self-signed) genutzt werden. Es wird jedoch empfohlen auf gültige Zertifikate zurückzugreifen.
Jedoch ist Verschlüsselung nicht gleich Verschlüsselung. Einige Algorithmen sind schlichtweg nicht mehr sicher vor Brute-Force-Attacken und können – mit entsprechender Rechnerleistung – erraten werden. Es sollte also darauf geachtet werden, dass aktuelle und moderne Verfahren und Algorithmen (TLSv1.2+, AES-GCM, ChaCha20, etc) zum Einsatz kommen.
Neben der verschlüsselten Kommunikation sollte auch in Betracht gezogen werden, die Daten selbst zu verschlüsseln. Je nach Art und Umfang der zu speichernden Daten könnte dies sinnvoll sein. Viele Datenbanksysteme unterstützten native Verschlüsselung. Das bedeutet, dass Entwickler oder Administratoren einen Schlüssel zur Verschlüsselung setzen um im Anschluss „normal“ mit der Datenbank arbeiten zu können 1Datenverschlüsselung ist ein sinnvoller Schutz vor unbefugter Einsicht nicht autorisierter Drittparteien, kann aber u.U. einen Layer an Komplexität einführen. Eine generelle Empfehlung für Verschlüsselung auf Datenebene kann also nicht pauschal ausgesprochen werden, meist könnte es auch genügen wenigen Parteien Zugriff zu gewähren und somit die Datenbank weitesgehend zu isolieren.
Authentifizierung
Jede Datenbank sollte mit mindestens einem Benutzernamen und einem starken, nicht zu erratenden Passwort vor unbefugtem Zugriff geschützt sein (idealerweise kommen Zertifikate anstelle eines Passworts zum Einsatz). Der Benutzende sollte so wenig wie möglich an Berechtigungen erhalten. Insbesondere sollte gut überlegt werden, welche Benutzende Datenbankschemata verändern oder löschen können, Berechtigungen für Benutzermanagement und Konfiguration erhalten. Hier gilt die Faustregel: so wenig wie möglich, so viel wie notwendig.
Im Rahmen von zeitlich wiederkehrenden Reviews oder Audits sollte kritisch begutachtet werden, ob Benutzende notwendig bzw. Berechtigungen gerechtfertigt sind, dass inaktive Benutzende gesperrt oder gelöscht und Passwörter regelmäßig geändert werden.
Microsoft SQL Server beispielsweise bietet die Integration von z.B. Windows-Kennungen, bei der vorhandene Windows-Konten anstelle von SQL Server-Konten verwendet werden. Dies bietet den Vorteil, dass nicht zusätzliche Benutzerdaten angelegt werden, sondern das Windows-Konto (welches wiederum von Mechanismen wie Active Directory verwaltet werden) genutzt wird.
Neben Entwickler:innen und Administrator:innen sollten auch eigene Zugangsdaten pro Anwendung, die mit der Datenbank kommuniziert, erstellt werden. Wenn möglich, sollten diese verschlüsselt außerhalb des Webroots und niemals hardcoded im Source-Code stehen bzw. in Versionsverwaltungstools (wie z.B. GIT oder SVN) eingecheckt werden. Die Berechtigungen auf Betriebssystemebene sollten so eingestellt werden, dass möglichst wenige Benutzende oder Gruppen diese einsehen können.
Monitoring und Betrieb
Das Aufsetzen und Inbetriebnehmen von Datenbanksystemen stellt meist nur den Anfang der Arbeit für Administrator:innen oder Security-Engineers dar. Zwar sind die bisher beschriebenen Vorkehrungen eine gute Basis zum Schutz vor potenziellen Attacken, allerdings können immer noch ungeahnte und unbekannte Szenarien oder sogenannte Zero-Day-Lücken zum Alptraum werden. Doch nicht nur Kriminelle können Systeme kompromittieren und zum Stillstand bringen, auch „natürliche“ Gründe können hier von Bedeutung sein. Beispielsweise kann die Festplatte eines Servers voll sein und somit die Datenbank kann keine neuen Daten schreiben oder es könnte zu einem unerwarteten Fehler und somit zum Herunterfahren des Datenbanksystems gekommen sein.
Solche Umstände mitzubekommen ist schwierig, denn Betriebssysteme bieten keine oder sehr wenige Boardmittel zum Monitoring und Alerting solcher Ereignisse. Um bestmöglichst auf unerwartete Umstände zu reagieren, sollten externe Tools herangezogen werden. Viele Monitoring-Systeme – wie z.B. Datadog, Kibana oder Sentry – bieten neben dem Monitoring und Alerting auch Erkennung sogenannter „Anomalien“. So kann es bspw. sein dass die Datenbank immer nachts zu einer bestimmten Uhrzeit nicht erreichbar ist, weil Updates und Patches eingespielt werden. Die genannten Tools würden dies als „normalen“ Umstand klassifizieren und nicht melden, während ein plötzlicher Anstieg von CPU-Ressourcen auf einen DDoS-Angriff (also eine Anomalie) hinweisen und Administratoren benachrichtigen kann.
IT Security mit Ucar Solutions
Wir bieten Ihnen vollumfänglichen System- und Source-Code Audit zum Absichern Ihrer Datenbanken, Server und Anwendungen gegen eine Vielzahl potenzieller Sicherheitsrisiken und weiteren sicherheitsrelevanten Aspekten. Durch automatisierte und manuelle Prozesse helfen wir Ihnen, Ihre sensiblen und geschäftskritischen Informationen zu schützen und die geltenden Gesetze einzuhalten.
Unsere automatisierten Tests beinhalten u.a. Penetrationtests, toolbasierte Codeanalyse und -dokumentation. Darauf aufbauend analysieren wir den Source-Coden persönlich, versuchen die Architektur zu verstehen und mögliche Probleme bzw. Vorschläge in dem Zusammenhang zu identifizieren bzw. unterbreiten.
Des Weiteren agieren wir auch als „Software-as-a-Service“ (kurz SaaS) Vendor und bieten Ihnen verschiedene Teil- oder Vollkomponenten als Software-Service an, welche vollumfänglich, unter Berücksichtigung aller o.g. sicherheitsrelevanten ununterbrochen zur Verfügung stehen. So können Sie sich um Ihre Anwendung kümmern während wir Teilbereiche zur Verfügung stellen.
Nutzen Sie das nachfolgende Kontaktformular und kontaktieren Sie uns heute noch für ein unverbindliches Erstgespräch. Wir freuen uns darauf!
