{"id":216,"date":"2021-08-19T15:22:59","date_gmt":"2021-08-19T13:22:59","guid":{"rendered":"https:\/\/www.edilog.de\/network\/?p=216"},"modified":"2025-09-29T13:49:53","modified_gmt":"2025-09-29T11:49:53","slug":"top-datenbankbedrohungen","status":"publish","type":"post","link":"https:\/\/www.edilog.de\/network\/2021\/08\/19\/top-datenbankbedrohungen\/","title":{"rendered":"Top-Datenbankbedrohungen"},"content":{"rendered":"<p>Nachfolgend eine Liste der h\u00e4ufigsten Bedrohungen denen Datenbanksysteme heute ausgesetzt sind:<\/p>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li><strong>Missbrauch legitimer Berechtigungen (Insider Angriffe)<\/strong>\u00a0\u2013 Jeder berechtigte Benutzer kann auch legitime Datenbankberechtigungen f\u00fcr nicht autorisierte Zwecke missbrauchen. Hier gibt es zwei Risiken, die in Betracht zu ziehen sind. Das erste Risiko ist ein b\u00f6swilliger Benutzer, der Datens\u00e4tze vielleicht verkaufen m\u00f6chte. Das zweite sogar h\u00e4ufigere Risiko ist ein fahrl\u00e4ssiger Benutzer, der gro\u00dfe Datenmengen aus der Datenbank abruft, auf seinem Client-Ger\u00e4t zu Arbeitszwecken speichert und die Daten damit Bedrohungen wie Trojanern, Laptopdiebstahl usw. aussetzt.<\/li>\n<li><strong>Missbrauch \u00fcberm\u00e4\u00dfiger Berechtigungen (Nicht autorisierte Aktionen privilegierter User)<\/strong>\u00a0\u2013 Anwendern bzw. Anwendungen denen Datenbankzugriffberechtigungen erteilt werden, die ihren Aufgabenbereich \u00fcbersteigen, k\u00f6nnen diese Berechtigungen u.U. zu b\u00f6swilligen Zwecken missbrauchen. Z.B. sind Datenbankadministratoren (DBA), die grunds\u00e4tzlich \u00fcber erweiterte Rechte zur Erf\u00fcllung ihrer Aufgaben verf\u00fcgen, in der Lage unerkannt Aktivit\u00e4ten auf der Datenbank durchzuf\u00fchren, die nicht zur Erf\u00fcllung ihren Aufgaben geh\u00f6ren. H\u00e4ufig werden Datenbankbenutzern auch nur \u00fcberm\u00e4\u00dfige Berechtigungen erteilt, weil die Datenbankadministratoren nicht gen\u00fcgend Zeit haben, abgestufte Kontrollmechanismen f\u00fcr die Zugriffsberechtigungen einzelner Benutzer zu definieren und auf dem neuesten Stand zu halten. Die Folge ist, dass allen Benutzern oder gro\u00dfen Benutzergruppen allgemeine Standardzugriffsberechtigungen erteilt werden, die weit \u00fcber die Anforderungen ihrer Aufgaben hinausgehen.<\/li>\n<li><strong>Missbr\u00e4uchliche Berechtigungserweiterung (Privilegien Eskalation)<\/strong>\u00a0\u2013 Erlangung von umfassenden Zugriffsrechten (z.B. Administrationsberechtigungen) durch einen normalen Benutzer indem Datenbank Schwachstellen ausgenutzt werden (abh\u00e4ngig vom DBMS). Solche Schwachstellen k\u00f6nnen in gespeicherten Prozedu-ren, integrierten Funktionen, Protokollimplementierungen und sogar in SQL-Statements auftreten. Mit diesen Berechtigungen k\u00f6nnte der b\u00f6swillige Benutzer anschlie\u00dfend Pr\u00fcfmechanismen umgehen, Daten manipulieren oder stehlen, unerlaubte Transaktionen durchf\u00fchren etc.<\/li>\n<li><strong>Ausnutzen von Schwachstellen fehlerhaft konfigurierter Datenbanken<\/strong>\u00a0\u2013 In der Praxis finden sich sehr h\u00e4ufig Datenbanken mit nicht gepatchten Schwachstellen und solche mit Standardkonten und Konfigurationsparameter. Angreifer werden Systeme typischerweise auf diese Schwachstellen hin pr\u00fcfen, sodass hier die Gefahr einer Sicherheitsverletzung gegeben ist. Zudem ist w\u00e4hrend der Zeit, in der ein Datenbankanbieter einen Patch f\u00fcr eine bestimmte Schwachstelle entwickelt, die Datenbank einer Organisation nicht gegen Angreifer gesch\u00fctzt. Und selbst wenn ein Patch freigegeben worden ist, steht dieser u.U. noch nicht sofort zur Verf\u00fcgung. Grunds\u00e4tzlich sind beim Patchen einer Datenbank verschiedene Aspekte in Betracht zu ziehen. Zun\u00e4chst mu\u00df eine Organisation den Patchvorgang f\u00fcr das System f\u00fcr diesen bestimmten Patch bewerten und verstehen, welche Auswirkungen sich auf das System ergeben. Der Patch k\u00f6nnte evtl. bereits vorhandenen Code beeintr\u00e4chtigt oder eine Work-Around-M\u00f6glichkeit er\u00f6ffnen. Zudem verursacht ein Patchvorgang immer Ausfallzeiten, in denen der Datenbankserver nicht f\u00fcr die Benutzer zur Verf\u00fcgung steht. Gro\u00dfe Unternehmen mit einer gro\u00dfen Anzahl von Datenbanken m\u00fcssen eine zeitliche Abfolge f\u00fcr das Patching festlegen und Datenbanken eine Priorit\u00e4t zur Behebung der Schwachstelle zuordnen. Daher ist es \u00fcblich, dass sich Patching-Vorg\u00e4nge in vielen Organisationen \u00fcber Monate hinziehen \u2013 typischerweise werden zwischen 6 und 9 Monate ben\u00f6tigt (basierend auf von der Independent Oracle User Group \u2013 IOUG* durchgef\u00fchrten Studien). Beim Patching-Vorgang spielen DBAs, System- und IT-Admins, Entwickler eine Rolle. Aus diesen Gr\u00fcnden bleiben Server oft noch Monate nach der Freigabe eines Patches angreifbar und k\u00f6nnen von einem Angreifer \u00fcber Standardkonten und Konfigurationsparameter, die aus einer produktiv genutzten Datenbank nicht ent-fernt worden sind, ausgenutzt werden. Ein Angreifer k\u00f6nnte z.B. versuchen, \u00fcber ein Standardkonto Zugriff auf die Datenbank zu erlangen. Schwache Audit-Parameter erl\u00e4uben es einem Angreifer, Audit-Kontrollen zu umgehen oder Spuren seiner Aktivit\u00e4ten zu verwischen. Schwache Authentifizierungsschemata erm\u00f6glichen es Angreifern, die Identit\u00e4t legitimer Datenbankbenutzer anzunehmen, indem Anmeldeinformationen gestohlen oder anderweitig erhalten werden, Nutzung eines Exploits, um Zugang zur OS Shell zu erhalten. Dar\u00fcber kann dann der Code von Services\/Daemons in der Art ge\u00e4ndert werden, dass die zugreifenden Controls, Auditing oder Authentication Mechanismen deaktiviert werden. (abh\u00e4ngig vom DBMS)<\/li>\n<li><strong>SQL Injection<\/strong>\u00a0\u2013 Bei einem SQL-Injection-Angriff werden typischerweise nicht autorisierte Datenbank-Statements in einen angreifbaren SQL-Datenkanal wie gespeicherte Prozeduren und Eingabeparameter von Web-Applikationen eingeleitet. Diese eingef\u00fcgten Statements werden anschlie\u00dfend zur Datenbank weitergegeben und dort ausgef\u00fchrt, wodurch Angreifer uneingeschr\u00e4nkten Zugriff zur gesamten Datenbank erlangen k\u00f6nnen.<\/li>\n<li><strong>Unzureichender Audit-Trail<\/strong>\u00a0\u2013 Elementarer Bestandteil jeder Datenbankimplementierung sollte sein, alle vertraulichen und\/oder ungew\u00f6hnlichen Datenbanktransaktionen automatisch aufzuzeichnen. Schwache Datenbank-Audit-Richtlinien stellen auf vielen Ebenen ein ernsthaftes organisatorisches Risiko dar.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li><strong>Regulatorisches Risiko<\/strong>\u00a0\u2013 Organisationen mit schwachen oder fehlenden Datenbank-Audit-Mechanismen werden zunehmend feststellen, dass sie beh\u00f6rdlichen Regulierungsanforderungen nicht entsprechen.<\/li>\n<li><strong>Abschreckung<\/strong>\u00a0\u2013Datenbank-Audit-Mechanismen dienen dazu, Angreifer abzuschrecken, weil sie wissen, dass Datenbank-Audit-Aufzeichnungen Ermittlern Beweismaterialien liefern, um Eindringlin-gen eine Straftat nachzuweisen.<\/li>\n<li><strong>Erkennung und Wiederherstellung<\/strong>\u00a0\u2013Sicherheitsverletzungen k\u00f6nnen nach ihrem Auftreten durch Audit-Daten identifiziert werden und dienen der Zuordung zu bestimmten Anwendern und\/oder Reparatur des Systems.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Schwachstellen in grundlegenden Audit-Merkmalen<\/strong>\u00a0\u2013 Datenbanksoftware-Plattformen verf\u00fcgen in der Regel \u00fcber grundlegende Audit-Merkmale, welche allerdings h\u00e4ufig mehrere Schwachstellen aufweisen, die ihre Implementierung einschr\u00e4nken oder ausschlie\u00dfen.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li><strong>Fehlende Benutzer\u00fcberwachung<\/strong>\u00a0\u2013 Wenn Anwender \u00fcber Web-Applikationen auf Datenbanken zugreifen, lassen sich spezifische Benutzeridentit\u00e4ten mit nativen Auditmechanismen nicht identifizieren, da die Benutzeraktivit\u00e4ten dem Web-Applikatios-Account zugeordnet werden. Missbr\u00e4uchliche Datenbanktransaktionen in nativen Audit Logs lassen sich somit nicht auf den verantwortlichen Anwender zur\u00fcckverfolgen.<\/li>\n<li><strong>Leistungseinbu\u00dfen<\/strong>\u00a0\u2013 Native Datenbank-Audit-Mechanismen belegen h\u00e4ufig erhebliche CPU- und Festplattenressourcen, weswegen viele Organisationen wegen der auftretenden Leistungseinbu\u00dfen Audit-Funktionen zur\u00fccknehmen oder vollst\u00e4ndig deaktivieren.<\/li>\n<li><strong>Pflichtentrennung<\/strong>\u00a0\u2013 Anwender mit Administrationsrechten f\u00fcr den Datenbankserver k\u00f6nnen Audit- Funktionen einfach abschalten, um missbr\u00e4uchliche Aktivit\u00e4ten zu verschleiern. Daher sollten Audit-Pflichten idealerweise zwischen Datenbankadministratoren und der Datenbank-Server-Plattform getrennt sein.<\/li>\n<li><strong>Begrenzte Granularit\u00e4t<\/strong>\u00a0\u2013Native Audit-Mechanismen zeichnen h\u00e4ufig nicht alle erforderlichen Details, um Angriffe zu erkennen, den forensischen Nachweis zu f\u00fchren sowie Systeme wiederherzustellen. Datenbank-Client-Anwendung, Quell-IP-Adressen, Query-Response-Attribute und fehlgeschlagene Abfragen als wichtiger Indikator f\u00fcr Aussp\u00e4hungen vor einem Angriff werden z. B. von vielen nativen Mechanismen nicht aufgezeichnet.<\/li>\n<li><strong>Propriet\u00e4re Formate<\/strong>\u00a0\u2013 Da sich Audit-Mechanismen und Logs einzelner Datenbankserver-Plattformen z.T. erheblich voneinander unterscheiden, ist es f\u00fcr Organisationen mit gemischten Datenbankumgebungen nahezu unm\u00f6glich, einheitliche, skalierbare Audit-Prozesse \u00fcber das gesamte Unternehmen hinweg zu implementieren.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Denial of Service (DoS)<\/strong>\u00a0\u2013 Dies bezeichnet eine allgemeine Angriffskategorie, in der Angriffe dazu f\u00fchren, dass berechtigten Anwendern der Zugriff auf Netzwerk-Applikationen und Daten verweigert wird. Denial of Service (DoS)-Zust\u00e4nde lassen sich \u00fcber zahlreiche verschiedene Techniken hervorrufen, wobei viele dieser Techniken die bereits erw\u00e4hnten Schwachstellen ausnutzen. Ein DoS l\u00e4sst sich z. B. verursachen, indem Schwachstellen der Datenbankplattform genutzt werden, um einen Server zum Absturz zu bringen (z.B. Initiierung von Buffer Overflows). Weitere verbreitete DoS-Techniken sind die Kompromittierung von Daten, eine \u00dcberflutung des Netzwerks mit Netzwerkverkehr und eine \u00dcberlastung von Serverressourcen (Speicher, CPU usw.). Ressourcen\u00fcberlastungen treten besonders h\u00e4ufig in Datenbankumgebungen auf. Die Motivationen, die hinter DoS-Angriffen stecken, sind \u00e4hnlich vielf\u00e4ltig. DoS-Angriffe kommen h\u00e4ufig in Zusammenhang mit Erpressungsversuchen vor, in denen ein Remote-Angriffs-Server die Datenbank wiederholt zum Absturz bringt, bis das Opfer Gelder auf ein internationales Bankkonto \u00fcberweist. In anderen F\u00e4llen lassen sich DoS-Zust\u00e4nde auf eine Wurm-Infektion zur\u00fcckf\u00fchren. Unabh\u00e4ngig von der Ursache stellen DoS-Angriffe f\u00fcr viele Organisationen eine ernsthafte Bedrohung dar.<\/li>\n<li><strong>Schwachstellen im Datenbankkommunikationsprotokoll<\/strong>\u00a0\u2013 In Datenbankkommunikationsprotokollen aller Datenbankanbieter werden immer mehr Sicherheitsschwachstellen entdeckt, wobei in den jeweiligen nativen Audit-Trails keine Aufzeichnungen dieser Aktivit\u00e4ten vorhanden sind, weil sie Protokolloperationen nicht abdecken. Missbr\u00e4uchliche Aktivit\u00e4ten, die auf diese Schwachstellen abzielen, reichen von nicht autorisierten Zugriffen auf Daten bis zu Datenkompromittierungen und DoS-Angriffen.<\/li>\n<li><strong>Nicht autorisierte Kopien vertraulicher Daten<\/strong>\u00a0\u2013 H\u00e4ufig werden nicht alle Datenbanken ordnungsgem\u00e4\u00df erfasst und gewartet. Neue Datenbanken werden erstellt ohne dass das Sicherheitsteam Kenntnis von diesen Datenbanken wei\u00df. Werden nun vertrauliche Daten wie Transaktions-, Kunden- und Mitarbeiterdetails in diese Datenbanken kopiert werden, sind diese einem Sicherheitsrisiko ausgesetzt, sofern die erforderlichen Kontrollen nicht implementiert werden. Ein weiteres Beispiel sind alte Datenbanken, die vergessen und nicht in die Bewertung einbezogen wurden.<\/li>\n<li><strong>Unzureichend gesch\u00fctzte Backup-Daten<\/strong>\u00a0\u2013 Oft sind Speichermedien mit Datenbank-Backups v\u00f6llig ungesch\u00fctzt. In der Vergangenheit wurden immer wieder F\u00e4lle bekannt, in denen B\u00e4nder und Festplatten von Datenbank-Backups gestohlen worden sind, was zu ernsthaften Sicherheitsverletzungen gef\u00fchrt hat.<\/li>\n<li><strong>Angriffe per Web Applikation<\/strong>\u00a0\u2013 Applikationen, die mit einer Datenbank im Hintergrund arbeiten, k\u00f6nnen kompromittiert werden, um Zugriffsrechte zu erweitern und damit umfassenden Zugriff auf die Datenbankresourcen zu erlangen (z. B. per SQL Injection). Hier ist es notwendig, dass die Database Activity Monitoring L\u00f6sung statt dem Applikationsaccounts auch Zugriff auf den wirklichen Verursacher der Aktion hat.<\/li>\n<li><strong>Zugriff auf OS Ressourcen per Datenbankangriff<\/strong>\u00a0\u2013 z.B. erm\u00f6glicht die \u00c4nderung des UTL_FILE_DIR Parameters bei Oracle der Prozedur SYS.UTL_FILE wichtige Files auf dem Betriebssystem zu \u00fcberschreiben oder Daten zu extrahieren.<\/li>\n<li><strong>Password Angriffe (\u201eBruteForce-Attacken\u201c)<\/strong>\u00a0\u2013 Hier wird versucht Passworte zu erraten, indem zahlreiche Zei-chenkombinationen per Skript am DBMS ausprobiert werden oder DB Schwachstellen werden ausgenutzt.<\/li>\n<li><strong>Cross Site Scripting (XSS)<\/strong>\u00a0\u2013 Zugriff auf die Datenbank durch Diebstahl von Logoninformationen von legitimen Benutzern einer Webapplikation indem Userdaten in der Datenbank gespeichert werden und sp\u00e4ter anderen Usern auf der Website unverschl\u00fcsselt angezeigt werden.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Obwohl Datenbankinformationen somit vielen verschiedenen Angriffen ausgesetzt sind, ist es dennoch m\u00f6glich, Risiken durch eine Konzentration auf die wichtigsten Bedrohungen, erheblich zu reduzieren. Wenn es Organisationen gelingt, den oben beschriebenen wichtigsten Bedrohungen mittels geeigneten Ma\u00dfnahmen wie gelebten Berechtigungskonzepten, Erf\u00fcllung der Anforderungen an sichere Datenbanksysteme, dem Einsatz von Database Activity Monitoring L\u00f6sungen etc.\u00a0 zu begegnen, erf\u00fcllen sie damit globale Compliance-Anforderungen und bew\u00e4hrte Industriestandards bez\u00fcglich Datenschutz und Risikominimierung.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Nachfolgend eine Liste der h\u00e4ufigsten Bedrohungen denen Datenbanksysteme heute ausgesetzt sind: Missbrauch legitimer Berechtigungen (Insider Angriffe)\u00a0\u2013 Jeder berechtigte Benutzer kann auch legitime Datenbankberechtigungen f\u00fcr nicht autorisierte Zwecke missbrauchen. Hier gibt es zwei Risiken, die in Betracht zu ziehen sind. Das erste Risiko ist ein b\u00f6swilliger Benutzer, der Datens\u00e4tze vielleicht verkaufen m\u00f6chte. Das zweite sogar h\u00e4ufigere &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/www.edilog.de\/network\/2021\/08\/19\/top-datenbankbedrohungen\/\" class=\"more-link\"><span class=\"screen-reader-text\">\u201eTop-Datenbankbedrohungen\u201c<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[9,21,26],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/posts\/216"}],"collection":[{"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/comments?post=216"}],"version-history":[{"count":0,"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/posts\/216\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/media?parent=216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/categories?post=216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.edilog.de\/network\/wp-json\/wp\/v2\/tags?post=216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}