Sicherheitsfixe für SQL Server und warum Sicherheits Best Practices wichtig sind
(MS15-058 SQL Server Security Bulletin)
Ziemlich genau ein Jahr, nachdem die seit 5 Jahren ersten Sicherheits-Bugs in SQL Server gefixt werden mussten, gibt es nun, seit 14.7.2015, wieder einen Grund, seine Security-Patching-Policy zu testen.
– Wenn man denn eine solche für SQL Server hat.
Und damit möchte ich jetzt niemanden anprangern. Denn: die letzten Jahre waren wir aufgrund des Mangels an Sicherheit bedingten Fixen in SQL Server schlicht verwöhnt. Sicherheitslecks (zumindest solche, die bekannt geworden sind) sind seit SQL Server 2000 so gut wie nicht mehr aufgetreten.
– Dazu gibt es diverse Statistiken und Aufsätze, wie diesem von dem amerikanischen Sicherheitsexperten David Litchfield (www.davidlitchfield.com/security.htm) oder dem ITIC-Report von 2010: SQL Server Most Secure Database; Oracle Least Secure Database Since 2002 oder auch die Statistik vom NIST (National Institute of Standards and Technology) von 2013, auf der die folgende Grafik basiert:
Dadurch dass er auf Basis der NIST-Daten 5 Jahre in Folge als sicherstes Datenbanksystem galt, mag der SQL Server in Sachen Sicherheitspatching durchaus aus dem Fokus der Administratoren gewandert sein.
Der Security Bulletin vom Juli 2015:
Vulnerabilities in SQL Server Could Allow Remote Code Execution (3065718)
https://technet.microsoft.com/en-us/library/security/MS15-058
Beschrieben werden 3 Sicherheitslecks:
Welche SQL Server Versionen sind betroffen?
Die Liste, beginnend mit SQL Server 2008 Service Pack 3 und endend mit SQL Server 2014 findet sich im Bulletin. Genauer kann man anhand seiner jeweiligen SQL Engine Nummer in diesem Blog-Artikel von Microsoft suchen:
Unter welchen Umständen kann ein System durch diese Lücken angegriffen werden?
Die Voraussetzungen sind für die 3 Sicherheitslecks natürlich unterschiedlich und auch (absichtlich) nicht bis ins letzte Detail beschrieben. WAS man jedoch herauslesen kann, ist, dass diejenigen, die Rechte nur sehr feingradig und dediziert gesetzt haben, wesentlich weniger angreifbar sind, da teilweise Schemaänderungsrechte im Datenbank-Bereich Voraussetzungen sind. Daher erinnere ich an dieser Stelle gern daran, dass man weise beraten ist, wirklich nur benötigte Rechte zu vergeben, und Schemas als Sicherheitsbereiche zu verstehen. Die Verwendung von db_owner beispielsweise sollte Tabu für Applikations-Benutzer sein. Wer solche Regeln bisher beherzigt hat, kann sich auch weiterhin einigermaßen sicher fühlen, da die Möglichkeit, diese Sicherheitslecks auszunutzen somit stark verringert ist.
Deswegen sollte man Best Practices für Sicherheit immer beherzigen. Eine vulnerability ist eben noch kein exploit.
Hier noch ein paar Links in Sachen Security in SQL Server:
SQL Server Best Practices – Implementation of Database Object Schemas
SQL Server 2012 Security Best Practices – Operational and Administrative Tasks
SQL Server 2012 Label Security Toolkit and white paper
SQL Server Database Ownership: recommendations
Guest account in User Databases
Schema-design for SQL Server: recommendations for Schema design with security in mind
Happy patching
Andreas
[insert_php]
the_tags( ‚Tags: ‚ , ‚ – ‚ , ‚ ‚ );
[/insert_php]
[insert_php]
echo‘Categories: ‚; the_category( ‚ – ‚ );
[/insert_php]
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!