Kombinieren der Verschlüsselung immer verschlüsselt UND auf Spaltenebene in SQL Server 2016

Wir müssen vertrauliche Spaltendaten mit SQL Server 2016 verschlüsseln und haben die Funktion Immer verschlüsselt (Always Encrypted, AE) ausgewählt, um diese Spalten mit einem deterministischen Ansatz zu verschlüsseln.

Da die deterministische AE-Verschlüsselung keine Ungleichungs-, Bereichs- oder LIKE-Abfragen für diese verschlüsselten Spalten zulässt, haben wir versucht, die Verschlüsselung für diese Spaltentypen mithilfe der Verschlüsselungstechnik mit symmetrischem Schlüssel (Spaltenebene) durchzuführen.

Ist es eine gute Praxis, die AE-Funktion für bestimmte Spalten (für die keine Abfragen für Ungleichheit, Bereich oder LIKE erforderlich sind) und eine Verschlüsselung mit symmetrischem Schlüsseltyp für Spalten zu implementieren, für die Abfragen für Ungleichheit, Bereich oder LIKE generiert werden müssen?

Ist es eine gute Praxis, die AE-Verschlüsselung und die Verschlüsselung auf Spaltenebene unter Berücksichtigung von Leistung, Sicherheit und Wartung in einer einzigen Tabelle zu kombinieren?

Experten beraten bitte.

Ich habe noch keine endgültige "Best Practices" -Liste für mehrere Verschlüsselungstypen für SQL Server gefunden, aber in Ihrer Situation würde ich wahrscheinlich Folgendes empfehlen:

1. Verschlüsseln Sie die erforderlichen Daten mit Always Encrypt
   • Es ist die neue Schärfe. Du bist auf 2016, genieße es!
   • Bessere Sicherheit - Der DBA kann keine Daten entschlüsseln, da der Schlüssel außerhalb der Datenbank gespeichert ist.
   • Weitere Optionen zum Optimieren einzelner Abfragen und zum Reduzieren des Leistungseinbruchs der Funktion.
   • Am einfachsten auf Datenbank- und App-Seite zu implementieren (es sei denn, TDE ist eine Option), da Sie nur Treiberparameter konfigurieren müssen, anstatt Ihre Abfragen wie bei der Verschlüsselung auf Spaltenebene zu ändern.
   • Die zusätzliche Entschlüsselungslast wird zum Problem der Anwendung (insbesondere des Treibers) (für mich als DBA in Ordnung).
   • Diese Funktion wird wahrscheinlich für eine Weile verbessert und optimiert, da es sich um eine neue handelt (meiner Meinung nach).
2. Erstellen Sie für Spalten, nach denen Sie suchen müssen , einen Hashwert, nach dem gesucht werden soll .
   • Erhält die Sicherheit der Daten, ist jedoch für Suchvorgänge sehr effizient. Damit können Sie die Suche in einer normalen Zeile durchführen, ohne jede Zeile entschlüsseln oder standardmäßig einen Tabellenscan durchführen zu müssen. Sie können es bei Bedarf für weitere Leistung indizieren.
     • Ihre App nimmt die Benutzereingaben und hasht sie und verwendet dann diesen Hash-Wert, um die in der Tabelle gespeicherte Hash-Version abzufragen. Diese Suche ist schnell und ermöglicht es Ihnen, nur die gewünschten Zeilen zu entschlüsseln, anstatt Zeilen zu entschlüsseln, die Sie nicht als Teil Ihrer Ergebnismenge benötigen.
   • Das Design hängt davon ab, wie viele Spalten Sie nachschlagen müssen und ob Sie in Ihren WHEREKlauseln mehrere oder einzelne Spalten verwenden .
   • Zusätzlicher Platz lohnt sich für die Leistung, solange Sie es sich leisten können.
3. Verwenden Sie keine Verschlüsselung auf Spaltenebene
   • Sie müssen die gesamte Spalte entschlüsseln, um Suchvorgänge durchzuführen. Dies ist weniger effizient als eine unverschlüsselte Hash-Spalte. Dies bedeutet, je größer Ihre Tabelle ist, desto ineffizienter wird diese Methode. 1 Million Zeilen bedeutet, dass Sie die CPU aufwenden müssen, um eine Million Zeilen zu entschlüsseln, selbst wenn Ihr Filter nur 1 Zeile zurückgibt. Nur weil Sie eine Suche durchführen können, heißt das nicht, dass sie performant ist.
   • Ich kann sehen, dass die langfristige Wartung von zwei Verschlüsselungsfunktionen in derselben Tabelle verwirrend ist und bestenfalls Stammeswissen wird.

Sie können # 2 auch mit Verschlüsselung auf Spaltenebene implementieren, aber ohne Einschränkungen kann ich nicht erkennen, warum Sie CLE im Allgemeinen immer als immer verschlüsselt auswählen.

Ich scherze darüber, dass die Verschlüsselung das Problem der Anwendung ist, aber ich finde, dass die Datenbank oft mit viel mehr Geschäftslogik und verrückter Funktionalität ausgestattet ist, als es in den meisten Fällen sein sollte. Wenn es eine Option gibt, um einige Berechnungen auf die Anwendungsseite zurückzuschieben, habe ich festgestellt, dass dies im Allgemeinen die beste Option ist und dazu beiträgt, dass die Fehlerbehebung und die allgemeine Optimierung nicht zum Albtraum werden.

Natürlich sollten Sie die Alternativen vollständig testen . Wenn Sie CLE oder eine Combo finden, die für Ihr spezielles Szenario am besten geeignet ist, ist es auch so.

Zusätzliche Lektüre:

• Immer verschlüsselte Leistung - Aaron Bertrand
• Immer verschlüsselte Leistung - Ein Follow-up - Aaron Bertrand
• Overhead für die Verschlüsselung auf Spaltenebene - Dallas Snyder
• Immer verschlüsselt (Database Engine) (offizielle Dokumentations-Landingpage)