Glorf IT

Bereits am morgigen Dienstag, am 12.5.2009, findet in Nürnberg wieder der nächste Vortrag der SQL-PAS Franken statt. Diesmal gehen wir auf Nummer "sicher".

Der genaue Titel lautet: "Sicherheitsketten im SQL Server – Rätsel gelöst?".
Sprecher ist der nicht ganz unbekannte Ralf Dietrich. Er ist Dank seiner vielen Vorträge und seiner Tätigkeit im Vorstand der SQL-PASS sehr bekannt. Über das Thema schreibt er selber:

Rätselhafte Einstellung: Datenbankübergreifende Besitzverkettung aktivieren?
Ja/Nein … was will der SQL Server hier von mir? Was verbirgt sich dahinter
und warum gibt es das auch innerhalb einer Datenbank? Wie kann ich es
nutzbar machen und welche Alternativen hat ein Entwickler? Welche
Fallstricke gilt es zur überwinden?

Gastgeber ist wieder die plus-IT GmbH im Eurocom Center (Lina-Ammon-Str. 3, Gebäude 3 / 3. Stock, 90471 Nürnberg).

Wie immer ist der Eintritt frei, auch Nicht-Mitglieder sind herzlich eingeladen. Weil es bei dem Thema und Referenten garantiert sehr, sehr voll wird, bitte bei Klaus Oberdalhoff unter kob(ät)sqlpass.de anmelden, damit er weiß, ob die Stühle reichen. Wer zu spät kommt oder sich nicht anmeldet, muss eben stehen… 😉

Groß-Klein-Schreibung ist in SQL weitgehend Geschmackssache. Daher hat lange gedauert bis mich mein Kollege Diethard umpolen konnte. Erst seit wenigen Jahren schreibe ich alle SQL-Schlüsselwörter groß.

Ob wohl es im Zeitalter der Syntaxhervorhebung tatsächlich fast egal ist, kann man auf Ausdrucken oder in per Mail verschickten Schnipseln die SQL-Befehle tatsächlich besser lesen. Die Umgewöhnung fiel mir sehr schwer, aber der Nutzen ist tatsächlich da.

Zur besseren Unterscheidung schreibe ich daher generell SQL-Schlüsselwörter groß und Variablen usw. klein. Hier ein Beispiel aus der Northwind-Datenbank:

SELECT EmployeeID, LastName, FirstName, Country
FROM Employees AS Emp
WHERE Emp.Country LIKE 'U_'

Den Name von Datenbank-Objekten sollte man hingegen generell immer "richtig" schreiben, d.h. so wie sie angelegt wurden. Deswegen habe ich im obigen Beispiel auch die Northwind-Schreibweise übernommen.
Zwar sind heutzutage case-insensitive Sortierungen üblich, aber das ist eine reine Konvention. Sollte in einem zukünftigen Release mal die Datenbank mit einer case-sensitiven Collation angelegt werden, dann wird die Suche des Optimierers in den internen Systemtabellen bei "falsch" geschriebenen Tabellennamen nicht fündig.

Besonders wichtig wird das bei Zugriffen auf Tabellen in den Systemdatenbanken. Hier wird bei der Installation des SQL-Servers festgelegt, welche Collation verwendet wird. Hier muss ich die Objektnamen in der Regel klein schreiben, z.B.:
EXEC sp_who
oder
SELECT name FROM sys.objects

Wegen der Übersichtlichkeit sorge ich dafür, dass Tabellen/Views/Procedures/etc in unseren Anwendungsdatenbanken gleich mit einem klein geschriebenen Namen oder mit Binnenkapitälchen angelegt werden. Jedenfalls dort wo ich darauf Einfluss habe. Aber natürlich ist das auch Geschmackssache… 😉

Um automatisch entscheiden zu können welchen Service-Pack (SP) oder Cummulative-Update-Package (CU) man einspielen muss, muss man wissen, ob der SQL-Server ein deutscher oder englischer ist. Früher hatten wir es schon einfacher, weil wir da immer nur mit englischen SQL-Servern zu tun hatten, damals noch von Sybase. Seit dem Umstieg auf Microsoft setzen wir immer den korrekten, landessprachlichen SQL-Server ein: auf deutschem Windows ist ein deutscher SQL-Server und auf einem englischen ein englischer.

Das haben wir der Auskunft des Microsoft-Supports zu verdanken, dass sie immer nur die landessprachlichen Versionen des SQL-Servers auf den entsprechenden Windows-Systemen testen, aber keine Mixe, wie z.B. den englischen SQL-Server auf einem deutschen Windows. Und nur diese Kombinationen werden von ihnen supportet. Aber ich will nicht lamentieren, so ist es einfach. Wir testen schließlich auch nicht jede denkbare Kombination unserer Software mit verschiedenen Sprachversionen von Windows.

Um herauszubekommen, was für einen SQL-Server man vor sich hat, kann man die XP xp_msver verwenden. Sie gibt einem neben der Sprache (im Datensatz "Language") und Produktversion und sogar Product Key, auch Infos zum Windows-System aus (z.B. Hauptspeicher, Version, Anzahl Prozessoren). Um nur einen einzigen dieser Werte in eine Variable zu bekommen, die man dann auswerten kann, muss man das Result-Set in eine Tabellenvariable schreiben und dann gezielt auslesen, z.B. so:

DECLARE @MSVer TABLE (ID int, Name sysname, Internal_Value int, Value nvarchar(512));
INSERT @MSVer (ID, Name, Internal_Value, Value)
EXEC master.dbo.xp_msver N'Language';

…

Lässt man die Optionsangabe hinter xp_msver weg, dann werden alle Optionen mit Wert ausgegeben.

PS: Habe ich schon erwähnt, dass diese XP jeder ausführen darf? Die Gruppe "public" hat Ausführungsrechte. Man könnte sich überlegen diese Rechte nicht jedem geben zu wollen… 😉

Heute wurde ich auf den Artikel "Lock Pages In Memory in SQL Server Standard Edition" in WesleyB's Blog aufmerksam. Die Quintessenz ist, dass ab dem CU4 für SQL Server 2005 SP3 und ab CU2 für SQL Server 2008 SP1 auch in der Standard-Edition die Option "Lock Pages In Memory" mittels Trace-Flag erlaubt wird. Beide kummulativen Patches sollen im Juni erscheinen.

In dem Artikel sind auch ein paar gute Links auf weiterführende Artikel enthalten, wie z.B. der Erklärung des Features von Slava Oks: "Q and A: Using Lock Pages In memory on 64 bit platform " und "Be Aware: Using AWE, locked pages in memory, on 64 bit ". Beide finde ich sehr interessant, weil wir tatsächlich AWE auf Windows-64-Bit einsetzen.

In einem MSDN-Forum beschwert sich ein Kollegen im Artikel "Bug in SQL Server 2008 SP1?" darüber, dass negative Identity-Inkremente nicht mehr gehen.

Ich muss zugeben, dass ich auf diese Idee gar nicht erst gekommen bin, weil ich IDENTITY schon ewig kenne. Und "früher" wurde immer um Eins rauf gezählt. Aber seit ein paar Versionen (SQL-Server-2005?) kann man ja den Seed und das Inkrement frei wählen. Freilich gehen dann auch negative Werte. Aber möglicherweise kamen die Entwickler genau so wenig auf diese Idee und vergaßen in der Doku zu schreiben, dass die Werte positiv sein sollen? Deswegen entspricht die Angabe von negativen Seeds und Inkrementen tatsächlich den Spezifikationen: In den Books-Online steht nicht drin, dass die beiden positiv sein müssen.

Es werden noch Wetten angenommen: Ist das ein Bug oder "works as designed"? Ich gehe im Zweifelsfall von Letzterem aus… 😉

PS: Ich habe hier daheim gerade keinen 2008er SQL-Server, daher habe ich nicht ausprobiert, ob da wirklich ein Bug kommt.

Wir suchten dieser Tage eine gute Lösung für einen Supportproblem: Beim "Reconfigure" nach dem Ändern einer Konfigurationsoption kommt immer die Fehlermeldung, dass der SQL-Server das Recht "Lock Page in Memory" nicht habe.
Wenn man die Ursache erst mal kennt, dann ist die Lösung nahe liegend:
Vor Ort beim Kunden wurde "AWE enabled" eingeschaltet, dann viel später wurde der SQL-Server in einem anderem Benutzerkontext gestartet und dieser Benutzer hat nicht das Recht "Lock Page in Memory". Dann wird die Option beim Server-Start automatisch nicht als "Run-Value" gesetzt, aber als "Config-Value".

Wenn man nun irgendetwas anderes konfiguriert, dann bekommt man oben genannte FEhlrmeldung beim ausführen von "Reconfigure". Wenn man dann versucht das AWE auszuschalten, dann muss man dazu zunächst "show Advanced options" einschalten. Aber das geht nicht, weil ja schließlich das RECONFIGURE fehlschlägt. Was tun?

1. Abhilfe: Den User-Account das verlangte Recht geben. Das ist schnell erledigt, aber die Lösung ist ja viel zu einfach. Deswegen schauen wir uns die andere Lösung an:
2. Abhilfe: Den SQL Server mit dem Parameter "-f" ("minimal konfiguration") starten. Dann sind immer alle Konfigurationsoptionen zugänglich und man kann einfach "AWE enabled" ausschalten. Schon praktisch…

Heute fragte in der deutschen SQL-Server-Newsgroup im Usenet wieder jemand danach, wie man denn verhindern kann, dass der Sysadministrator (SA) des SQL-Servers die Daten in seiner Anwendungsdatenbank lesen bzw. ändern kann. Die Frage stellte ich mir auch schon so oft. Die traurige Tatsache ist, dass Microsoft hier eine ganz einfache Linie fährt: ein Admin darf alles. Das es in Deutschland Regelungen gibt, die anderes vorschreiben, ist nicht bei Ihnen angekommen.

Das geht über mehrere Stufen:

• Wer Domänen-Admin ist, der ist auch lokaler Administrator.
• Wer lokaler Windows-Admin oder Domänen-Admin ist, der ist auch SysAdmin im SQL-Server.
• Wer SysAdmin im SQL Server ist, der hat auch volle Adminrechte auf jeder Datenbank.

Natürlich kann man jeden einzelnen Schritt gut begründen und sinnvolle Beispiele nennen. Leider gibt es aber auch für jeden Schritt exotische Sonderfälle in denen das nicht so ist. In unserer Firma gibt es zum Beispiel eine personelle Trennung zwischen den Administratoren der Windows-Server und den SQL-Server-Administratoren. Um das zu verhindern, kann man zwar der vordefinierten SQL-Server-Rolle NT-Autorität\Administrator den Zugang zunächst versperren, aber leider nicht nachhaltig. Durch Start des SQL-Servers im Single-User-Modus wird das wieder aufgehoben. Das sollte für einen Admin machbar sein… 😉

Wenn man also verhindern will, dass der Admin die Objektdefinitionen auslesen will, dann muss man die Objekte schon "WITH ENCRYPTION" anlegen. Aber auch dabei sollte man sich nicht zu sicher fühlen, denn die Anleitung zur Entschlüsselung ist auch nicht so wirklich schwierig. Für mich ist das in der gleichen Liga wie die Obfuscation bei .Net… 😉

OK, aber wenigstens kann man verhindern, dass der Admin die Daten lesen kann. Dazu muss man lediglich die Inhalte der Felder verschlüsseln. Ich nehme an, dass ein Admin die mittels der SQL-Server-Encrypt-Funktionen verschlüsselten Felder tatsächlich nicht lesen kann. Wenn es durch Austausch oder Neugenerieren des Database-Master-Key doch gehen sollte, dann kann man immer noch "EncryptByPassphrase" verwenden. Hier sollte man allerdings bedenken, dass das Passwort im Klartext über die Leitung geht. Und ein Admin, der keinen Netztrace ziehen kann, darf sich wohl kaum Admin nennen. Aber die auf Signaturen basierenden Encrypt-Funktionen halte schon für recht sicher, bin hier aber nicht sehr erfahren. 🙂

Leider kenne ich keine Möglichkeit, wie man verhindern kann, dass der Admin Datensätze löscht oder ändert. Man kann allenfalls erzeugte Signaturen von Sätzen erstellen und inline speichern, um Änderungen einzelner Sätze zu bemerken. Und die Anzahl von Datensätzen zu bestimmten Schlüsseln verschlüsselt abspeichern, um das nachträgliche Anfügen oder Löschen zu bemerken. Das dürfte die gängigsten Fälle abdecken. Nur gegen mutwilligen Vandalismus ist man machtlos. Aber dafür gibt es ja hoffentlich Datensicherungen… 🙁

Das Resümee ist: Microsoft hat festgelegt, dass man dem Admin vertrauen muss. Wenn das nicht der Fall ist, dann sollte man schleunigst den Vertrag kündigen und die Admin-Passwörter ändern… 😉

Wer wissen will, wie viele Tabellen maximal in einer Datenbank des Microsoft SQL Servers sein können oder wie viele Columns in einem SELECT verwendet werden dürfen, der bekommt eine Antworten hier:

• Maximum Capacity Specifications for SQL Server 2008
• Maximum Capacity Specifications for SQL Server 2005
• Maximum Capacity Specifications for SQL Server 2000

Damit ich den Artikel wieder finde, wenn ich es brauche, hier ein Merker:
Im Posting "How to un install SQL Server 2005" werden mehrere relevante Artikel zur manuellen Deinstallation des SQL Servers 2005 gesammelt. Das benötigt man beispielsweise manchmal bei Kunden, wenn der Update z.B. mit SP3 fehlschlug, weil das System verkorkst ist. Dann klappt manchmal auch die automatische Deinstallation nicht. Danach lässt es sich dann hoffentlich wieder komplett installieren, sonst hat man ein noch größeres Problem… 😉

Bis ich den Namen aussprechen konnte, musste ich echt lange üben: "Visual Studio Team System 2008 Database Edition GDR R2". Zur Erinnerung: Das ist die Visual-Studio-Edition mit der man Datenbank-Projekte komfortabel erstellen kann und die Unit-Tests für Datenbank-Objekte ermöglicht. Weil die Edition asynchron zu den anderen Studio-Editionen erscheint, haben die ein Namensproblem. Mit dem Visual-Studio-2008 erschien im Prinzip die bisherige 2005er Version in leicht neuem Gewand. Kurze Zeit später erschien die "echte" neue Version für Visual-Studio-2008, sie wurde "GDR" genannt, um den Unterschied deutlich zu machen.

Jetzt erschien davon das zweite Release, also "R2". Das steht nun zum Download bereit und kann von allen genutzt werden, die entweder damals eine Lizenz für die Database-Edition kauften, die gleich die ganze Team-Suite haben oder (seit ein paar Monaten) auch alle, die eine Developer-Lizenz haben.

Die Liste der Fehlerbehebungen ist echt lang, die Features klingen wenig spektakulär, aber extrem nützlich. Auf einer Clip-Seite von Microsoft stehen sie:

Zusätzlich zur Unterstützung für SQL Server 2008-Datenbankprojekte beinhaltet diese Version eine Vielzahl zuvor veröffentlichter Power Tools sowie mehrere neue Features, etwa getrennte Build- und Bereitstellungsphasen, Analyse von statischem Code und eine verbesserte Integration mit SQL CLR-Projekten.

Wobei ich dachte, das würde schon von der GDR unterstützt. Aber da kann ich mich täuschen.

Hier die Links:

• Download
• Info auf dem Blog von Gerd Drapers (Team-Leiter)

Durch den Heise-Online-Artikel "SQL-Injection reloaded: Zugriff auf das Betriebssystem" wurde ich auf das Tool sqlmap aufmerksam. Damit kann man versuchen (eigene?) Systeme mittels SQL-Injection zu kompromittieren.

Sqlmap scheint sich aber vorwiegend auf web-basierte Clients zu konzentrieren. Schade, ich hätte das gerne mal gegen unsere Windows-Anwendungen laufen lassen. Das ist schon deswegen interessant, weil die normalen Benutzer nicht genug Rechte haben sollten, um die vom Tool verwendeten Funktionen (z.B. xp_cmdshell) zu nutzen. Aber wer weiß, vielleicht nutzt es ja vorher eine mir bisher unbekannte Methode der escalation of rights… 😉

Heute verdiente ich mir durch eine gewonnene Wette eine Tüte Gummibärchen. Ein Kollege las in einem Vergleich zwischen der SQL Server Compact Edition und der Express Edition, dass die Extensions bei der Express-Edition fix auf MDF, NDF und LDF festgelegt seien. Das erschien mir esoterisch.

Komischerweise steht im Artikel "Choosing Between SQL Server 2005 Compact Edition and SQL Server 2005 Express Edition"
tatsächlich in der tabellarischen Übersicht unter dem Punkt "Support for different file extensions" bei Compact Edition "ja", bei Express Edition "nein". Im Text steht sogar:

Microsoft considers SQL Server MDF files to be the security equivalent of .EXE files, and should be treated with the same sense of concern when receiving EXEs from unknown sources. To minimize the possibility of illicit code running, SQL Server Express Edition data files must always use an MDF file extension.

Ich hatte das zuletzt unter SQL-Server-2000 ausprobiert, aber führte die einschlägigen Aktionen auch mal schnell am SQL-Server-2005 durch:

CREATE DATABASE [MyExtensionTest]
ON ( NAME = 'datafile',
FILENAME = 'c:\temp\datafile.data'
)
LOG ON (
NAME = 'logfile',
FILENAME = 'c:\temp\datafile.log'
)

Das klappte genauso einwandfrei, wie ein CREATE-TABLE danach. Auch das Trennen und das anschließende erneute Anhängen der Datenbank klappte an der Express-Edition-2005 ganz prima. Wären wir bei den Myst-Busters, dann gehörte diese Info eindeutig in die Kategorie "Gerücht".