Glorf IT

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… 😉

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".

Wenn man eine Datenbank mittels des "SQL Server Management Studios" anhängt, dann bekommt man bereits vor dem eigentlichen Anhängen an der Oberfläche angezeigt, aus wie vielen Dateien die Datenbank besteht und wo die Dateien zuletzt lagen. Nun gibt es aber Anwendungen, die für Endanwender gedacht ist, die mit der Bedienung des Management-Studios durchaus überfordert sein könnten.

Wenn man das Anhängen – z.B. nach einer Rücksicherung aus einer Datei-Vollsicherung – nicht den Anwender manuell durchführen lassen will, sondern automatisch aus der eigenen Anwendung, dann muss man auch irgendwie an diese Infos ran kommen.

Zu diesem Zweck bietet Microsoft die undokumentiere DBCC-Funktion "checkprimaryfile". Damit kann man sich die wichtigsten Infos herausholen ohne die Datenbank vorher anhängen zu müssen.

Ist die Datei tatsächlich eine MDF-Datei?

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 0)
Mit der Option "0" überprüft "checkprimaryfile", ob die Datei eine MDF-Datei ist: "0" heißt "Nein", "1" heißt "ja". Beispiel:

Welche Version hat die Datenbank?

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 2)
Mit der Option "2" ermittelt "checkprimaryfile" die Version, den Namen und die Default-Collation der Datenbank:

Das ist deswegen relevant, weil man an einen SQL-Server-2005 keine 2008er Datenbank anhängen kann. Umgekehrt zwar schon, aber dann ist das fortan eine 2008er Datenbank. Die Versionen sind folgende:

Aus welchen Dateien besteht die Datenbank?

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 3)
Mit der Option "3" ermittelt "checkprimaryfile" die Liste der Datenbank-Dateien und gibt an, wo die Dateien zuletzt lagen als sie noch angehängt waren:

Im Beispiel sieht man, dass die Datenbank-Dateien zuletzt im Verzeichnis "C:\Programme\Microsoft SQL Server\MSSQL10.SQL2008SE\MSSQL\DATA\" lagen. Jetzt stehen sie im Verzeichnis "C:\temp". Daher muss man die Dateien zum Anhängen entweder wieder an den Ursprungsort verschieben oder beim Anhängen die neuen Pfade aller Dateien angeben.

Details zu den Datenbank-Dateien

dbcc checkprimaryfile ('C:\temp\Test_data.mdf', 1)
Mit der Option "1" wird die Datenbank wird kurzzeitig angehängt, Details zu den Dateien analysiert und dann wieder getrennt. Das geht freilich nur, wenn die Log und Secobdary-Files unter dem Pfad ansprechbar sind unter dem sie in der MDF-Datei stehen.

Dazu kann man die Datenbank auch gleich selber anhängen und dann angehängt lassen.

Risiken und Nebenwirkungen

Diese DBCC-Funktion ist undokumentiert und daher in zukünftigen Versionen möglicherweise nicht mehr lauffähig oder bringt andere Ausgaben. Ich fand leider nirgends Angaben zu der Funktion. Daher fand ich obige Angaben durch Ausprobieren raus. Sie können daher falsch sein. Interessanterweise klappten die Optionen 0,2,3 auch wenn ich an einem SQL-Server-2005 eine 2008er Datenbank analysierte. Die Option 1 nicht, weil da die Datenbank angehängt werden soll.

Nächsten Dienstag, am 7.4.2009, findet in Nürnberg wieder der nächste Vortrag der SQL-PAS Franken statt. Wer schon mal etwas von Azure gehört hat und sich fragt, wie man da DAten speichert und liest, der sollte sich mit den "SQL Data Services" (SDS) beschäftigen. Und genau das machen wir an dem Abend.

Dariusz Parys (Microsoft) erweist uns die Ehre. Es ist "Technology Evangelist" bei Microsoft und daher immer mit den neuesten Microsoft-Technologien beschäftigt. Er ist vor allem bekannt durch seine praxisnahen und visionären Workshops. Das sagt er selber über den Vortrag:

Mit Windows Azure besteht die Möglichkeit Daten im Internet abzulegen. Mittels der Azure Cloud Storages und der SQL Data Services können Daten auf unterschiedliche Art und Weise bearbeitet und behandelt werden. In diesem Vortrag werden beide Komponenten erklärt und mit ein paar Demos anschaulich visualisiert.

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… 😉

Offenbar war bis vor kurzer Zeit die Sektorgröße von Festplatten so fix auf 512 Bytes, dass Microsoft keinen Gedanken daran verschwendete, dass es auch andere Sektorgrößen geben kann. Zur Erinnerung: ein Sektor bestimmt die Größe des Datenblockes, der von der Festplatte bzw. vom Medium gelesen wird. Das wird gerne mit der Cluster-Größe verwechselt, die durch das Dateisystem (und damit durch die Formatierung) festgelegt wird.

Microsoft hat das Schreiben des Transaktionslogs derartig auf Performance optimiert, dass sie in den Datei-Header die Clustergröße schreiben mit der die Datenbank angelegt wurde. Wenn ich nun einen neuen Server anschaffe, dessen Plattensystem (z.B. SAN) eine größere Sektor-Größe hat, z.B. 1024 Bytes, dann kann die Datenbank vom SQL-Server dort weder angehängt werden, noch können alte Datensicherungen dort eingespielt werden. Ganz schön lästig, wenn man das nach einem Systemausfall mit dem neuen Server erst merkt.

Microsoft schreibt das im Artikel "SQL Server I/O Basics, Chapter 2" so:

SQL Server is not designed to dynamically upgrade the database to the larger sector sizes. SQL Server disallows restoring or attaching a database on a system with a larger sector size; it generates an error message and prevents the restore or attach operation. Enabling a database to function by using a smaller formatted sector size than the actual sector size violates the WAL protocol because the sector size variation guarantees the log records will not be correctly aligned with the physical sector size and log records will be rewritten.

Diese Info bezieht sich auf die Versionen 2000 und 2005. Weiß jemand, ob der SQL-Server-2008 damit inzwischen zurecht kommt? Als Lösung für die eigenen Systemdatenbanken erzeugt Microsoft sie auf Festplatten mit der Sektorgröße 4K. Wenn die auf eine Platte mit kleineren Sektoren kopiert werden, dann geht das nämlich, falls die kleinere Sektorgröße ein Teiler der großen ist.

Was könnte es für Anlässe geben, dass die Sektor-Größe anders ist?

• Moderne SANs sind hier konfigurierbar,
• manche RAIDs sind konfigurierbar,
• für Solid-State-Disks bieten sich andere Sektorgrößen an und
• für USB-Sticks auch.

Wir suchen gerade nach einer Lösung, wie man die Daten in so einer Datenbank noch retten kann, wenn das alte System nicht mehr zur Verfügung steht (also kein Kopieren von A nach B möglich ist). Hat jemand eine Idee? Oder hat jemand schon mal Erfahrungen mit diesem Feature gemacht?

Heute machte mich Klaus auf die Seite "SQL Server Data Mining" aufmerksam. Hier werden alle möglichen Informationen von Microsoft zur Verfügung gestellt.

This site has been designed by the SQL Server Data Mining team to provide the SQL Server community with access to and information about our exciting data mining features.

Ich finde die Sammlung schon ziemlich beeindruckend, aber es könnte noch übersichtlicher sein. Man muss schon etwas buddeln bis man die Dinge findet, die man sucht. Besonders gut gefällt mir die Sammlung mit Artikel und "Whitepapers".

Zufällig fand ich gerade in nettes Dokument, in dem mal übersichtlich alle Fragen zum Lizenzmodell des "SQL Server 2008 Enterprise Edition" erklärt werden…

Hier ist der Download (PDF).

Kennt jemand die Pendants zu den anderen Editionen?

Was man im Internet so über die kommende SQL-Server-Version mit Codenamen "Kilimanjaro" liest ist merkwürdig wenig. Ich habe mal ein paar Infos zusammengetragen, die mir zuverlässig erscheinen.

Am 6.10.2008 veröffentlichte Microsoft in einer Presseerklärung erste Infos:

• Hauptfeatures seien "self-service analysis capabilities code-named “Project Gemini”" und "self-service reporting".
• Freigabe sei im ersten Halbjahr 2010 (vorher werde es wieder ein CTP geben).

Das klingt alles sehr BI-lastig. Außerdem ein Release noch nicht mal 24 Monate nach SQL-Server 2008? Interessant finde ich die Aussage dazu im Artikel "Die nächste Version von SQL Server – Ankündigungen von der BI Konferenz:

SQL Server Kilimanjaro. Das wird die nächste Version von SQL Server. Es ist eine Zwischenrelease, die vor allem im Bereich Business Intelligence neue Funktionalitäten bringt. Das ist nicht die nächste Hauptrelease von SQL Server (die also wahrscheinlich eine Versionsnummer 11 hat und wie angekündigt 24-36 Monate nach SQL Server 2008 erscheinen wird), sondern eine Zwischenversion.

So sieht es auch Michael Otey im SQL Server Magazine:

While the marketing spin on the new release will be about customer choice, don’t forget that Microsoft plans for product releases on a major-minor cycle. Each server product gets a major release about every four years and then is followed by a minor R2 release about two years later. In the past, customers waited a long time (around five years) for products such as Windows XP and SQL Server 2005, so I can understand why Microsoft wants to shorten the release cycle. However, two years is too short, especially for an infrastructure product like SQL Server.

In einem Bericht von der Konferenz "SQL PASS 2008" wird der Vortrag von Ted Kummert beschrieben. Hier heißt es nun wieder anders:

Kilimanjaro – Keep an eye out for Kilimanjaro. This is the code name for the next release of SQL Server. It is expected to be released in 2010 or 24 to 36 months after the SQL Server 2008 release. One of the items that caught my eye was the ability to manage multiple SQL Server instances and migrate code seamlessly between the environments with a 'DAC Pack' which is a consolidated set of code.

Details zum "DAC Pack" (inkl. wirklich interessantem Film) findet man bei Neil Hutson:

Second was the Data-Tier Application Component (DAC) which combines details about the application that the developer is building and turns schema into something called a "DAC PACK" which can be offered to the Fabric Control Point to aid in the deployment of the data tier within the Managed SQL Server Fabric.

Der Film lässt leider offen, ob das auch für Updates gilt, aber ich denke mal doch. Was sollte ein Deploy, der nur auf der grünen Wiese aufsetzen kann?

Auf Ella Maschiach's BI Blog fand ich den Hinweis auf den ersten CTP1. Der Fragebogen steht noch online, aber die Anmeldefrist war bis 31.12.2008.

Komischerweise fand ich keine neueren Infos. Kennt jemand relevante Links aus diesem Jahr?

Beim gestrigen Vortrag zum Thema "Snapshot Isolation" kamen ein paar Themen zur Sprache zu denen wir nicht mehr alle Details zusammen bekamen. Hier ein paar Schnipsel zum Thema "Lock Escalation". Eine sehr gute und kompakte Sammlung von Infos findet man im Artikel "Lock Escalation in SQL2005" von Sunil Agarwal.

Eine Lock Escalation von Row-Locks auf Table-Locks wird ausgelöst, wenn

• die Zahl der gehaltenen Sperren die Schwelle von 5000 überschreitet oder
• der für Sperren genutzten Speicher 40% des aktuellen Cache überschreitet (wenn sp_configure-Option "locks" = 0) oder
• der für Sperren genutzte Speicher 40% des für Sperren konfigurierten Speichers überschreitet.

Gestern lernte ich, dass der Schwellwert von 5000 am SQL-Server-2008 konfigurierbar sei. Das klingt gut.

Zudem sprachen wir auch über Möglichkeiten, wie man gezielt verhindern kann, das die Sperren eskaliert werden. Auch das findet man im oben genannten Artikel sehr gut erklärt.