SQL Server & BI Blog by Andreas Wolter

Normalerweise versuche ich ja, meine Konferenz-Teilnahmen vorab bekanntzugeben, um dem Leser auch eine Chance zu geben, diese eventuell einzuplanen.

Aufgrund akutem Zeitmangel, und auch dem Umstand gewidmet, das ich erst eine Woche vor der Konferenz spontan für einen ausgefallenen Sprecher eingesprungen bin, ist mir das diesmal nicht gelungen.

Ich hatte das Vergnügen, einen Vortrag über “Hochverfügbarkeitstechniken mit SQL Server 2012” zu halten, und auch in einem Interview zu diesem Thema befragt zu werden.

Ich möchte über die diesjährigen (ersten) Frankfurter Datenbanktage (der Termin für das nächste Jahr steht bereits fest: 26. - 28. März 2014) gerne noch im Nachhinein schreiben, da mir das Konzept mit gleichzeitigen Tracks & Sessions zu Oracle, DB2, MySQL, NoSQL und SQL Server sehr gefällt.

Es ist z.B. immer wieder interessant - aber auch bedauerlich, festzustellen, wie unbekannt Snapshot Isolation & RCSI in SQL Server eigentlich ist.
Das geht soweit, das in einer Session, in der es um die Fähigkeiten der verschiedenen Datenbanksysteme, während des Schreibens von Datensätzen, dennoch gleichzeitig einen konsistenten Zustand lesen zu können zu der Aussage kam, das nur Oracle dies beherrscht.
Das ist sehr schade.
Denn abgesehen davon, das diese Aussage so nicht richtig ist - SQL Server bietet 2 Varianten (eben Snapshot Isolation und Read Committed Snapshot Isolation), auf die das ebenso zutrifft; das Hintergrundwissen, das Microsoft den Entwicklern die Wahl zwischen vielen verschiedenen Isolationsstufen gibt, und warum dieses Konzept auch besser ist, als keine Wahl zu haben (oder zumindest so sehr auf nur eine festgelegt zu sein, das selbst Oracle-Admins meinen, es gäbe keine), scheint nicht so weit verbreitet zu sein, wie man es sich erhoffen würde.

Eine andere Session, die ich nur lesenderweise mir ansah, hat mich als Security Spezialist für SQL Server schon fast geschockt: Es ist zwar kein Geheimnis (auch wenn es interessanterweise gerade im Bankenbereich gern ignoriert wird), wie umfangreich die Anzahl der Sicherheitslücken in ORACLE ist (Beim "NIST" kann man sich darüber informieren: nvd.nist.gov), aber in welchem Ausmaß man selbst ohne spezieller Betrachtung derer eine sogenanntes Sicherheits-“Härtung” durchführen muss, um einigermaßen sicher vor den gröbsten Einfallstoren zu sein, hat mich als seit SQL Server 2005 “secure by default” gewohnter doch sehr überrascht. - Möglichst “sanft" (Session-Untertitel "Sanftes Härten"), damit danach auch noch alles funktioniert - und wir wollen die Angreifer ja auch nicht völlig vergraulen, oder? :) (Nachtrag: natürlich ist es nachvollziehbar, das man nicht einfach so alles "dicht" macht, und danach auch die validen Anwendungen nicht mehr funtionieren. Die Essenz ist: es muss ein Mittelweg gefunden werden, welcher die Angreifbarkeit und Verletzbarkeit zumindest mindert. Und das ist natürlich schon viel Wert!)
Welche meiner Daten so "geschützt" in Oracle-DBs liegen, wäre vielleicht gut zu wissen... ganz ohne Häme, denn der einzelne Kunde kann dafür meistens gar Nichts. - Nur wenn er informiert ist und gar nicht handelt (Und nicht einmal mildernd eingreift).

Um es aber auch klar zu sagen: auch einen SQL Server kann man angreifen, wenn Applikationen oder andere Verbindungen mit zu viel Rechten laufen, Service Accounts geshared werden, etc.. Deswegen hier noch einmal die beiden wichtigsten Sicherheitsprinzipien: "Separation of duties/roles" und "Principle of least privilege". Also Aufgaben/Rollen (Dienstkonten!) trennen und immer mit den geringstmöglichen Rechten arbeiten. Und oben drauf ein Auditing, damit man mitbekommt, wenn man einen Weg übersehen hat.

Und nicht zuletzt wegen der Möglichkeit solche Missverständnisse oder Vergleiche einmal live zu erfahren, oder auch einfach ganz andere Möglichkeiten, die es bei anderen DBMS ja auch gibt, kennenzulernen, empfinde ich die Frankfurter Datenbanktage als Bereicherung in der Konferenz-Landschaft.

Tatsächlich versucht die PASS Deutschland e.V. eine kleine Variante solcher Mixtur auch für den geplanten SQLSaturday #230 in Rheinland, auf welchem ich sicherlich auch anzutreffen sein werde, mit einzubringen. Ich bin gespannt, was daraus wird, und wie es aufgenommen wird.

vielleicht sieht man sich auf der nächsten Konferenz,

Andreas