Die Menschen hinter den Produkten, Teil 3: Il-Sung Lee, SQL Server Security PM

Als dritten Teil meiner Menschen hinter den Produkten Serie heute ein Kollege, mit dem ich schon ein paar Mal zusammen gearbeitet habe: Il-Sung Lee. Er spricht über SQL Server Sicherheit, Verschlüsselung, Auditing, Modulsignaturen, Besitzverkettung und Separation of Duties.

Am Anfang hatten wir eine kurze Diskussion über asiatische Sprachen und warum so wenige Europäer gewillt sind, sie zu lernen. Diesen Teil möchte ich den Lesern nicht vorenthalten – jedenfalls den Teil, von dem ich eine Aufzeichnung habe.

Il-Sung sagte, dass viele asiatische Sprachen recht einfach zu lernen sind, weil die Grammatik deutlich einfacher ist als bei westlichen Sprachen und nannte als Beispiel eine Sprache (Mongolisch?) in der es keine Zeitformen gibt sondern die Zeit immer mit angegeben wird.

Aber ich glaube, alle großen Sprachen, wie Chinesisch, Japanisch oder Koreanisch sind ziemlich kompliziert. Schon weil das so alte Kulturen sind. Jede Sprache scheint mit der Zeit komplizierter zu werden

Koreanisch ist nicht so schlecht, denn das Alphabet in Koreanisch ist ziemlich modern. Das Alphabet wurde ca. 1600 geschaffen. Der König hat einige Linguisten bezahlt um eine Schriftsprache zu kreieren die die meisten Menschen lernen können. Vorher hat Korea die chinesischen Schriftzeichen verwendet.

Heutzutage werden die chinesischen Schriftzeichen gar nicht mehr verwendet?

Nein, gar nicht. Heutzutage gibt es etwa 10 Vokale und 14 bis 16 Konsonanten.

Das ist alles?

Ja. Es ist sehr ähnlich zu den europäischen Sprachen. Jedes Zeichen besteht normalerweise aus drei Teilen – Konsonant, Vokal, Konsonant. Sehr kompakt.

Hast Du in Korea gewohnt?

Ich wurde da geboren, aber wir sind nach Kanada gezogen als ich vier war. Ich bin also im Wesentlichen Kanadier

Du sprichst also nicht so gut Koreanisch?

Ich spreche Koreanisch, aber leider habe ich einen sehr starken englischen Akzent.

So, nun aber das eigentliche Interview

Hallo Il-Sung, ich kenne Dich jetzt schon eine ganze Weile, aber kannst Du Dich mal kurz vorstellen: Wer bist Du, was ist Deine Rolle?

Ich bin der Program Manager für das SQL Server Engine Security Team, auch als „Core Security Infrastructure Team“ bekannt. Ich bin also verantwortlich für das Team, das die Security Features in der SQL Server Engine erstellt. Dinge wie Authentifizierung, Autorisierung, Verschlüsselung, Auditing kommen aus unserem Team. Wir spielen auch eine große Rolle im gesamten Bereich Sicherheit, Datenschutz und Compliance. Viele Kunden, besonders in Nordamerika, haben ein hohes Interesse an Compliance-Aspekten. Ich bin seit einem knappen Jahr in dieser Rolle. Davor war ich der Program Manager für das SQL Server Protocols Team, das sich mit den Protokollen zwischen Client und Server beschäftigt. Das habe ich gemacht seitdem ich vor etwa dreieinhalb Jahren zu Microsoft gekommen bin. Davor habe ich für IBM gearbeitet, als Entwickler für die Sicherheitsfeatures von DB2. Also so ähnlich wie das was ich jetzt mache. Das war mein erster Job.

Wie lange warst Du bei IBM?

Ich was siebeneinhalb Jahre bei IBM. Nach dieser Zeit habe ich beschlossen, dass ich wieder an die Westküste will. Ich stamme aus Vancouver, Kanada.

Du magst also den Regen?

Och, Regen ist gar nicht so schlimm. Ich mag keinen Frost und Schnee. Da durchzufahren hat mich immer verrückt gemacht. Ich fahre lieber hier in die Berge zum Ski fahren.

In unserem Software-Entwicklungszyklus gibt es doch überall Security, im ganzen Produkt. Was gehört da zu Deinem Aufgabenbereich und was nicht?

Es gibt zwei Security Teams in der SQL Server Entwicklung. Unser Team beschäftigt sich mit den Security Features in der Engine. Für SQL Server 2008 war das zum Beispiel Transparent Data Encryption (TDE) oder Extensible Key Management. Security beeinflusst aber alle Teile von SQL Server. Daher gibt es ein zweites Team, das SQL Secure Initiative Team. So etwas gibt es zum Beispiel auch in der Windows-Produktgruppe. Dieses Team beschäftigt sich mit der Security des gesamten Produktes. Sie beschäftigen sich mit Dingen wie Angriffsszenarien, sicherem Softwaredesign und Sicherheit in jedem Aspekt des Produkts. Nicht nur für die relationale Datenbank sondern auch für AS, RS, IS, die Clientsoftware. Wenn man also diese beiden Teams zusammen nimmt ist Security im ganzen Produkt abgedeckt.

Eine Frage, die immer kommt wenn ich über eine reine Softwarelösung für Verschlüsselung rede wie die SQL Server 2005 Verschlüsselung oder auch Transparent Data Encryption – ohne Extensible Key Management – ist, dass im Endeffekt ja alle Schlüssel in Software auf derselben Maschine gespeichert sind. Es ist einfach, Daten zu verschlüsseln. Aber dieser Schlüssel muss wieder mit einem anderen Schlüssel verschlüsselt werden, und dieser wieder. Kannst Du uns erklären, wie da vermieden wird, dass im Endeffekt das Ende der Schlüsselkette unverschlüsselt gespeichert wird?

Ja, richtig. Wenn man Daten verschlüsselt, dann müssen die Schlüssel selbst geschützt werden. Sonst ist das schlimmer als wenn gar nicht verschlüsselt wird. Aus diesem Grund verwendet SQL Server eine Schlüsselhierarchie, mit der die Schlüssel geschützt werden. Für Transparent Data Encryption funktioniert das so: Die Datenbank wird mit einem Database Encryption Key verschlüsselt (symmetrisch, schnell). Das wird mit einem Zertifikat verschlüsselt (asymmetrisch). Dieses Zertifikat muss wieder geschützt werden. Das passiert mit dem Database Master Key von master, der schützt alles in dieser Datenbank. Das wird vom Service Master Key geschützt, der auf der Ebene der Instanz alles schützt. Und der Service Master Key wieder von Windows selbst geschützt, mit DPAPI. Wenn man sich diese Hierarchie also anschaut verlassen wir uns im Endeffekt auf die Sicherheitsfunktionen des Betriebssystems.

Du hast das Extensible Key Management (EKM) erwähnt. Das kann hier eine wichtige Rolle spielen. Manche Kunden, die sich um Sicherheit besonders Gedanken machen stellen fest, dass es das Beste ist, wenn die Schlüssel woanders gespeichert werden. Mit EKM kann man den Database Encryption Key mit einem Schlüssel schützen, der auf einem dieser Key Management Geräte (HMSs und so) gespeichert ist. Mit diesen Geräten wird also der Schlüssel getrennt von den Daten gespeichert, und die HSMs haben sehr umfassende Sicherheitsvorkehrungen zum Schutz der Schlüssel, die sie speichern. Die Hierarchie geht also außerhalb des Datenbankservers weiter.

Die verschlüsselte Version des Database Encryption Key wird zum HSM Device gesendet, dort entschlüsselt und das Ergebnis wieder an SQL Server zurückgeschickt. Ein EKM Gerät wird seine Schlüssel nie herausgeben, denn dann würden sie die Kontrolle über die Schlüssel verlieren. Normalerweise gibt es einen verschlüsselten Kanal zwischen dem Gerät und der Anwendung (hier: SQL Server), die die Ver- oder Entschlüsselung anfordert. In vielen Fällen ist das Gerät über das Netzwerk zu erreichen, aber es gibt sie auch als PCI Karten oder ähnliches im Server. In allen Fällen werden dem Gerät verschlüsselte Daten geschickt. Das HSM Gerät verwendet dann einen Schlüssel, den es selber hat für die Entschlüsselung. Man bekommt niemals direkt Zugang zu dem auf dem HSM Gerät gespeicherten Schlüssel. SQL Server speichert also selbst keinen Schlüssel sondern nur einen Zeiger auf den Schlüssel auf dem externen Gerät.

Noch eine Frage: Viele Kunden beschäftigen sich auch mit der Verschlüsselung von Daten auf Laptops oder anderen Geräten, die keine Enterprise Edition von SQL Server haben. Aber TDE ist ein Enterprise Edition Feature ist kann es in solchen Szenarien nicht verwendet werden. Was empfiehlst Du um Datenbanken zu schützen, die sich auf Laptops oder ähnlichem befinden?

TDE ist Klasse, weil es die Transportabilität der Daten in verschlüsseltem Zustand ermöglicht. Aber derzeit ist das nur ein Enterprise Edition Feature. Auf den anderen Plattformen kann man Betriebssystemfunktionen verwenden. Insbesondere würde ich Bitlocker in Windows Vista empfehlen. Das funktioniert sehr gut, und alle Daten sind verschlüsselt, solange sie auf dem Bitlocker-geschützten Dateisystem bleiben. Man muss natürlich aufpassen, wenn man die Daten auf ein anderes Dateisystem wie zum Beispiel eine externe Platte kopiert.

Wenn man kein Vista hat kann man EFS verwenden, was in älteren Betriebssystemen vorhanden ist. Allerdings gibt es da ein paar Performanceprobleme wegen den unterschiedlichen Lese- und Schreib-Zugriffsmustern zwischen SQL Server und EFS. Dann gibt es auch Fremdhersteller, die Verschlüsselungslösungen anbieten, aber dazu kann ich nicht viel sagen.

Du hast auch Auditing als neues Feature in SQL Server 2008 erwähnt. Kannst Du ein wenig über das Design dieses Features und die Anforderungen sprechen?

Auditing ist ein richtig cooles Feature, meiner Meinung nach eines der besten Neuerungen in SQL Server 2008. Dabei sollte man nicht vergessen, dass Auditing in SQL Server 2008 eine erste Version ist. Auf dieser Infrastruktur werden wir in der Zukunft weiter aufbauen. Für diese Version haben wir eine sehr sehr solide Kernfunktionalität für Auditing erstellt. Wir haben verschiedene Audit-Ziele wie das Sicherheits-Log von Windows, und natürlich Dateien. Und wir haben einen sehr großen Performancevorteile gegenüber dem, was die meisten Leute vorher gemacht haben, nämlich SQL Traces. Zusätzlich bieten wir detailiertes und sehr spezifisches Auditing. Man kann sehr genau festlegen was man auditieren möchte, etwa nur den Zugriff von bestimmten Benutzern auf bestimmte Tabellen. Dieses Feature genügt für die Auditing-Ansprüche der meisten Benutzer. Natürlich gibt es noch weitere Anforderungen, die wir uns jetzt anschauen. In zukünftigen Versionen von SQL Server wird es dann weitere Verbesserungen dieses Features geben.

Habt Ihr Performancemessungen für Auditing gemacht?

Ja. Wir haben Benchmarks basierend auf Kunden-Workloads gemacht. Dabei haben wir direkt zwischen SQL Trace und SQL Auditing verglichen. Dabei haben wir soweit ich mich erinnere eine 11%-46% höhere Performance für SQL Audit ermittelt. Und bei IO-intensiven Workloads kann der Performancevorteil noch höher sein, denn Auditing verwendet Extended Events, die eine stark optimierte IO-Struktur haben. Das alles gilt, wenn man dieselben Audits erstellt wie in SQL Trace. Mit Trace kann ich aber kein spezifisches Auditing erstellen. Mit Trace musste man also häufig nachträglich noch viel filtern, um die wirklich relevanten Einträge zu finden. Mit Audit kann man viel gezielter festlegen, was auditiert wird und so noch größere Performancevorteile erreichen. Ich kann zum Beispiel sagen: mich interessieren nur Select-Zugriffe von Systemadministratoren auf diese Tabelle, mehr nicht. Dann werden weniger Events generiert.

Gibt es irgendetwas im Bereich SQL Server Security wovon Du denkst, die Kunden wissen es oft nicht, sollten es aber wissen? Ein Feature von dem Du möchtest, dass die Kunden es mehr benutzen würden?

Ja, eine Feature von dem ich möchte, dass es mehr Kunden kennen sollten ist das ganze Konzept der Modulsingatur (module signing). Das wurde mit SQL Server 2005 eingeführt. Das funktioniert so:

Man kann ein Modul, zum Beispiel eine Stored Procedure, mit einem Zertifikat kryptografisch signieren. Der erste Vorteil ist, dass wenn jemand jetzt versucht, dieses Modul zu bearbeiten dann wird die Signatur und damit das Modul ungültig. Vor allem aber kann man diesem Zertifikat zusätzliche Berechtigungen geben (über einen certificate mapped account). Wenn ein Benutzer das Recht hat, die Stored Procedure auszuführen dann bekommt er im Kontext dieser Prozedur zusätzliche Berechtigungen, die dem Zertifikat gegeben wurden. Das entspricht EXECUTE AS in der Stored Procedure, ist aber besser, weil jetzt der Benutzerkontext nicht geändert wird. Man bekommt nur während der Ausführung der Prozedur zusätzliche Berechtigungen. Ein gutes Beispiel um das einzusetzen sind DBCC-Kommandos. Wenn man jemandem die Möglichkeit geben will, bestimmte DBCC-Kommandos auszuführen, ihm aber keine sysadmin-Rechte geben möchte dann kann man eine Stored Procedure mit den DBCC-Kommandos erstellen, diese mit einem Zertifikat signieren, diesem Zertifikat sysadmin-Rechte geben und dem Benutzer nur die Ausführung der Prozedur erlauben. Dadurch kann der Benutzer nur genau diese DBCC-Kommandos ausführen, hat sonst aber keine sysadmin-Rechte. Und da die Prozedur signiert ist kann sie auch keiner ändern ohne die Signatur ungültig zu machen. Und die Benutzer führen das Kommando auch in ihrem eigenen Kontext aus, nicht unter sa oder sowas. Das vereinfacht das Auditing.

Auf der anderen Seite: Gibt es ein Feature in SQL Security von dem Du denkst, dass es missbraucht wird oder das die Kunden anders verwenden sollten als sie das tun?

Ja, eine Sache, auf das die Benutzer beim Entwurf ihrer Berechtigungsstruktur mehr Augenmerk legen sollten ist das ganze Konzept von Ownership Chaining (Besitzverkettung). Es gibt einen guten Artikel in Books Online, der Besitzverkettung erklärt. Aber im Wesentlichen geht es darum: Wenn zum Beispiel eine Sicht und eine Tabelle, die die Sicht verwendet denselben Eigentümer haben und ein Benutzer Rechte auf die Sicht hat, dann werden für den Zugriff auf die Tabelle über die Sicht keinerlei Berechtigungen mehr geprüft. Wenn also einem Benutzer die Recht auf eine Tabelle entzogen wurden, er aber noch Rechte auf die Sicht hat dann kann er über die Sicht auf die Tabelle zugreifen. Das kann verschachtelt so weitergehen. Solange der Eigentümer der Objekte derselbe ist werden keine weiteren Berechtigungen geprüft. Wenn also einem Benutzer der komplette Zugriff auf eine Tabelle entzogen werden soll muss auch jeder indirekte Zugriff entzogen werden.

Das ist ein verbreitetes Design. Viele Kunden mögen Besitzverkettung, aber man sollte sich der Folgen bewusst sein. Eine einfache Möglichkeit, das zu verhindern und die Kette zu brechen sind verschiedene Eigentümer für die Objekte. Dann werden für jedes Objekt getrennt die Berechtigungen geprüft.

Eine letzte Frage: Es gibt eine große Diskussion über „Separation of Duty“ (deutsch etwa: Trennung der Zuständigkeiten, das Thema kommt vor allem aus Standards wie PCI-DSS). Wir haben in SQL Server all die Teile, die man für die Implementierung braucht. Aber hast Du einen Leitfaden, wie man Separation of Duty implementiert?

Separation of Duty ist ein sehr heißes Thema wegen der vielen juristischen und Compliance-Anforderungen heutzutage. Ich glaube, Separation of Duty wird von vielen Leuten missverstanden. Man kann das nicht erreichen wenn man alles als sysadmin oder sa betreibt. Punkt. Das ist dasselbe, als wenn man alles als Windows-Administrator ausführt. Wenn man Windows-Administrator ist dann gibt es immer eine Möglichkeit, auf alles zuzugreifen. Und sa und sysadmin in SQL Server sollten genauso behandelt werden. Es ist ein besonders privilegierter Benutzer der dazu dient, dass man alles tun kann. Ein Konto, das man als letzes Mittel hat. Jedes Betriebssystem, jede Datenbank hat so ein Konto. Wenn die Benutzer aber alles als sysadmin betreiben ist es sehr schwer, Separation of Duties zu erreichen. Man sollte so herangehen: Was muss dieser Benutzer tun können? Und wie kann ich ihm die Berechtigungen geben, die er dafür braucht. Wenn also jemand Backups machen soll dann gibt man ihm die entsprechenden Berechtigungen und packt ihn nicht in die sysadmin-Rolle. Wenn man dieses Konzept gut durchdenkt kann man angemessene Separation of Duties erreichen. Denn nun kann jeder seine Tagesaufgabe erledigen ohne auf weitere Daten Zugriff zu haben. Und das ist das Hauptproblem, das viele Kunden haben: Sie wollen, dass die Benutzer ihr System administrieren können ohne auf bestimmte Daten zugreifen zu können.

Wir arbeiten derzeit an einigen Whitepapern (hey, was ist hier der deutsche Plural?), die auf diese Fragen detailierter eingehen und einen Leitfaden bieten. Diese Dokumente werden bald erscheinen. Dort zeigen wie, wie einfach man mit SQL Server Mitteln die Anforderungen erfüllen kann.

Danke, Il-Sung