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.<\/p>\n
Das geht über mehrere Stufen:<\/p>\n
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<\/a> wird das wieder aufgehoben. Das sollte für einen Admin machbar sein… \ud83d\ude09<\/p>\n 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<\/a> ist auch nicht so wirklich schwierig. Für mich ist das in der gleichen Liga wie die Obfuscation bei .Net… \ud83d\ude09<\/p>\n 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<\/a>" 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. \ud83d\ude42<\/p>\n 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… \ud83d\ude41<\/p>\n 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… \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[16],"tags":[484],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/2707"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=2707"}],"version-history":[{"count":3,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/2707\/revisions"}],"predecessor-version":[{"id":2710,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/2707\/revisions\/2710"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=2707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=2707"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=2707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}