SQL Server: Sicherheit für Entwickler

Always Encrypted

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Mit Always Encrypted steht eine Technologie bereit, die sicherstellt, das sich sensible Daten sowohl in der Datenbank als auch im Transit, also zwischen Server und Client, stets in verschlüsseltem Zustand befinden.
10:23

Transkript

So, und das Letzte, was ich Ihnen zeigen möchte, ist das Always Encrypted Feature, was neu im Secret Server 2016 kommt. Dieses Feature ist dafür gedacht, sensible Daten, die in der Datenbank gespeichert werden, immer in verschlüsselten Zustand zu halten, das bedeutet, sowohl wenn sie auf der Platte liegen, sprich, auf dem Server, als auch, wenn sie sich im Transit befinden zwischen Server und Client, das heißt, im Netzwerk. Den Vorteil, den ich habe, ist, dass ich von Seiten der Anwendung nur im ConnectionString Änderungen machen muss. Ich muss serverseitig ein bisschen was machen, keine Frage, aber die Anwendung lässt sich relativ leicht umstellen, indem ich schlicht und ergreifend das neue Token dazuschreibe, Column Encryption Setting=enabled. Das sorgt dafür, dass die Anwendung, sie muss mit mindestens .NET 4.6 geschrieben sein, dann entsprechend auch genau dieses Feature mehr oder minder automatisch benutzt, und das lässt sich daher clientseitig extrem einfach einbauen. Und was Sie serverseitig tun müssen, das zeige ich Ihnen jetzt auch. Und ich wechsle deswegen erst einmal in das SQL Server Management Studio. So hier im SQL Server Management Studio bin ich in der Datei AlwaysEncrypted.sl. Das Erste, was ich wiederum machen muss, ist schlicht eine Datenbank für unsere Tests anzulegen und als Nächstes brauche ich 2 Arten von Schlüsseln. Ich brauche zum einen einen Column Master Key und ich brauche einen Column EntryptionKey. Beides muss vorhanden sein, damit ich das Always On Feature benutzen kann. Jetzt ist es natürlich so, dass ich in Demos normalerweise Skripte zeige, weil es immer schön nachvollziehbar ist, hier kann es sein, dass das möglicherweise gar nicht so richtig gut funktioniert, wie man sich das vorstellt. Auf meiner Maschine wird es funktionieren, das heißt, ich kann hier erst einmal den Master Key anlegen und hier unten auch dann den Encryption Key anlegen. Das funktioniert soweit auch, das Problem ist aber Folgendes: Wenn ich in die Datenbank reingehe, die ich gerade angelegt habe, dann kann ich hier unter Security sehen, dass es für Always Encrypted Keys hier einen entsprechend neuen Ordner gibt. Dort gibt es jeweils Unterordner für Master Key und für Encryption Keys. Wenn ich jetzt hingehe und hier über die Oberfläche einen Master Key anlege, dann kann ich hier unten eine Key Definition Source angeben. Das ist zum einen hier diese Dropdown-Liste und zum anderen hier auch das Zertifikat, was dahinter steht und wichtig ist dieser Thumbprint, dieser Daumenabdruck. Wenn Sie den nicht haben, dann wird das Statement hier, Sie sehen, das ist zum Beispiel der gleiche Abdruck, zwar laufen und es lässt sich auch einen Column EntryptionKey anlegen, das Dumme ist aber, wenn dann die Anwendung versucht auf diese Keys zuzugreifen, würde es ein Fehler geben. Das heißt, es kann sein, dass es für Sie besser ist, das über die Oberfläche anzulegen, deshalb mache ich das einfach mal. Ich lasse den T-SQL-Code hier einfach mal stehen als Hinweis, damit Sie sehen, wie es entsprechend auch mit T-SQL funktioniert und ich gehe einfach hin und ich mache es hier über die Oberfläche. Um den Namen treu zu sein MasterColumnKey, habe dann entsprechend genau diesen MasterColumnKey, den ich anlege. Und als Nächstes lege ich einen entsprechenden, ich nehme mir wieder den Namen, vorsichtshalber in die Zwischenablage, um irgendwelche Typos zu vermeiden und lege einen entsprechenden Encryption Key an und da wähle ich dann exakt meinen MasterColumnKey aus. So, das funktioniert, es wird vor allen Dingen auch hinterher beim Programmlauf soweit funktionieren, und deswegen benutze ich hier das T-SQL nicht. So, nachdem dieser Hürde gemeistert ist, scrolle ich weiter runter. Das ist die Create-Table-Anweisung, die notwendig ist, um eine Tabelle anzulegen mit in dem Fall 2 verschlüsselten Spalten. Beide mal entsprechend Text, NVARCHAR (50) um genau zu sein. Ich kann eine Collation, wenn ich möchte, angeben. Ich kann entsprechend sagen, womit verschlüsselt werden soll, ob es Deterministic sein soll oder eine Randomized dahinter. Details werden sich alle noch als brauchbar oder weniger brauchbar herausstellen, wenn Secret Server 2016 mal auf dem Markt ist. Ich kann auswählen, welchen Algorithmus ich haben möchte und ich muss den gerade angelegten ColumnEncryptionKey entsprechend dazulegen, dann weiß der SQL Server, okay, das ist der Schlüssel, mit dem der Inhalt verschlüsselt werden soll, der wiederum ist einer Master Column Key zugeordnet und der wiederum ist dem Benutzer zugeordnet. Und das ist nämlich genau das, was auch gleich passiert, wenn ich versuche mit einer Anwendung auf diese Tabelle zuzugreifen. Das heißt, ich lege die einfach an, es hat funktioniert. Und was aber weniger funktioniert, ist, wenn ich versuche Daten einzufügen, das gibt einen Fehler oder wenn ich versuche entsprechend das Ganze über Parameter zu machen, dann bekomme ich auch ein Fehler. Das heißt, so funktioniert es nicht so ohne Weiteres. Ich muss also dafür in eine entsprechende App wechseln, damit ich mir die Inhalte anzeigen beziehungsweise Inhalte einfügen kann. Und das tue ich jetzt, ich wechsle jetzt ins Visual Studio. Im Visual Studio angekommen, kann ich mir hier kurz einen Überblick verschaffen. Ich bin hier in einer kleinen Konsolenanwendung, dotnetconsulting.AlwaysEncrypted heißt sie. Ich kann hier auf die Eigenschaften gehen, mir versichern, dass ich entsprechend auf .NET Framework 4.6 oder höher kompiliere, in dem Fall ist es genau 4.6. Ich kann ein Blick in die Konfiguration werfen. Und Sie sehen, hier ist das neue Tugend zu finden: Integrated Security=true. Und habe dann quasi die Möglichkeit mir anzuschauen, was sonst noch hier zu finden ist. Der restliche Code wird, soweit sei schon mal verraten, entsprechend ganz normaler .NET-Code sein. Ich mache hier nichts Spezielles, außer dass ich Insert-Statements ausführe, die ich entsprechend mit Parameter versehe. Ich führe Updates-Statements aus, die entsprechend wieder über Parameter entsprechend gefüttert werden und zum Schluss lese ich auch Daten aus, ich gebe die letztendlich an die Oberfläche, sprich, Console.WriteLine ist hier mein Kandidat an die Oberfläche aus dann. Ich kann das Ganze gleich mal laufen lassen, dass werden Sie sehen, wie das dann aussieht. Vorerst aber die kleinen Details noch mal. Ich habe es gerade schon im Connection-String gezeigt, dass die Column-Security-Settings eingeschaltet wurden und ich kann mir, wenn ich das möchte, entsprechend auch anzeigen lassen, also welchen Connection-String ich benutze, den gebe ich hier noch mal in der Oberfläche aus. Das heißt, ich wechsle jetzt wieder zurück auf dem Server und dort führen wir das Programm dann einmal aus und dann sehen auch, was da genau passiert an der Stelle. So, Sie werden sich wahrscheinlich fragen, warum ich jetzt zurück auf den Server wechsle, um entsprechen das Programm auszuführen? Der Grund ist relativ einfach, weil es sonst schlicht und ergreifend noch nicht wirklich funktioniert. Insofern habe ich das Programm kompiliert, ich habe die Binaries auf diesen Server gelegt und hier in einen Ordner verfrachtet. Und von dort aus werde ich sie entsprechend auch ausführen. Bevor ich das jedoch tue, gehe ich hin und starte den SQL Profiler, damit Sie sehen können, was wirklich auf der Leitung passiert. So, ohne was einzustellen, schlicht und ergreifend einfach alles bestätigt. Ich kläre das Fenster noch mal, damit ich hier keine einzige Anzeige habe, dann mache ich das zum Symbol und ich habe hier die fertigen Binaries. Ich lasse die einmal ausführen. Und Sie sehen, es wird createData aufgerufen, updateData wird aufgerufen und readData und das sind in der Tat dann die Inhalte. Und ich kann mal gucken, was der Profiler in dem Moment mitgeschrieben hat, ich drücke hier mal auf Pause, damit nicht noch was passiert, und Sie sehen Select-Statements, na ja, nichts besonders Spannendes. Allerdings, wenn ich mir anschaue zum Beispiel die Statements, die die Instance durchführen, die sensiblen Daten sind automatisch verschlüsselt worden. Und Sie sehen hier immer, dass der User verschlüsselt ist, dass das Secret verschlüsselt, das heißt, die Information gehen verschlüsselt über die Leitung, ohne dass Sie wirklich groß was dran tun müssen. Jetzt bleibt einem sicherlich die Neugier: Wie sieht es denn in der Tabelle selber aus? Ich kann also noch mal in das SQL Server Management Studio gehen, und mir die Tabellen anschauen. Genauso auch die Tabelle, es sind ja nicht mehr is ja nur eine, ich mache mal ein simples Select drauf. Und Sie sehen, auch der Inhalt hier ist verschlüsselt. Es kann unverschlüsselte Spalten geben, das ist diese Unwichtig, keine Frage, aber ich bekomme genau den Inhalt angezeigt. Und wenn ich selber ein Select-Statement schreiben würde, dann sehe das an der Stelle genauso aus. Das heißt, damit habe ich keine große Angriffsfläche mehr, die Daten werden verschlüsselt. Sie müssen sich allerdings bewusst sein, dass natürlich das Ver- und Entschlüsseln der Information Rechenzeit kostet, und zwar in dem Fall aufgrund der Architektur, Rechenzeit des Clients, das heißt, der muss in der Lage sein, die Daten entsprechend zu ver- und entschlüsseln. Und das geht also nicht auf Lasten des Servers, sondern die Clients müssen die Arbeit tun. So, das war die kleine Aussicht auf Always Encrypted. Sicherlich eine sehr spannende Sache, besonders, wenn ich bedenke, dass dort sensible Daten gespeichert werden können und ich beispielsweise ein Backup mache oder Ähnliches und das mir abhandenkommt. Das bedeutet in dem Moment, dass niemand auf die Daten wirklich zugreifen kann. Die sind sicher, in dem Sinne, zumindestens indem, was man heutzutage als sicher bezeichnet und liegen verschlüssel in der Datenbank vor und werden entsprechend auch verschlüsselt übertragen. Erst der Client entschlüsselt die Information und stellt sie dann entsprechend der Anwendung zur Verfügung. Und damit habe ich ein durchaus rundes Paket, ohne besonders viel Aufwand treiben zu müssen beziehungsweise ohne dass ich das Problem habe, dass ich sehr komplexe Programmierung verwenden muss von Client-Seite aus. Und das ist das, was möglicherweise viele davon abgeschreckt hat bis jetzt, den ein oder anderen Verschlüsselungsalgorithmus des SQL Servers zu benutzen. Man wird sehen, wie dieses Feature sich entwickelt und man wird sehen auch, wie sie die Kunden von Microsoft dieses Feature annehmen werden.

SQL Server: Sicherheit für Entwickler

Lernen Sie, wie sich das Thema Sicherheit im Entickleralltag mit Microsofts Datenbankserver umsetzen lässt.

2 Std. 31 min (25 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Exklusiv für Abo-Kunden
Erscheinungsdatum:15.01.2016

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!