Datenbankverschlüsselung oder Verschlüsselung auf Anwendungsebene?

Question

Wenn Sie sensible Daten wie CCs oder Sozialversicherungsnummern, tun Sie speichern müssen:

1) Erstellen Sie Ihre eigene Verschlüsselungsroutine innerhalb der Anwendung, einen geheimen Schlüssel irgendwo in einer Konfigurationsdatei definieren, und dann manuell Verschlüsseln/Entschlüsseln von Daten zur Datenbank gehen.

2) Schieben Sie alle Probleme auf die Datenbank, mit den eingebauten DB-Funktionen (ich denke, die meisten Hersteller nennen es Transparent Database Encryption).

Welche Kompromisse haben Sie für Ihre Lösung gefunden? Fällt das Schreiben Ihrer eigenen Routine im Vergleich zu TDE schlecht? Ist die Wartbarkeit von Code oder umgekehrt DB-Anbieter ein Problem?

Answer 1

Ich habe eine Vielzahl von Verschlüsselungstechniken verwendet und ich glaube, dass es einfacher und sicherer ist, auf der Anwendungsseite mit einer bewährten Verschlüsselungsroutine (d. H. .NET-Bibliotheken) zu verschlüsseln.

Wenn Sie für die Datenbank verschlüsseln, bedeutet dies, dass die Daten in unverschlüsselter Form an die Datenbank und von dieser gesendet werden. Dies ermöglicht möglicherweise ein Snooping/Manipulieren zwischen der Anwendung und den Verschlüsselungsroutinen in der Datenbank. Selbst wenn Sie den Schlüssel auf der Anwendungsseite speichern, ist auf der Datenbankseite immer noch eine Verschlüsselung erforderlich. Wenn die Datenbank kompromittiert ist, sind Ihre Daten ernsthaft gefährdet (stellen Sie sich einfach vor, dass jemand Profiler ausführt, während Ihre Anwendung ausgeführt wird).

Wenn Sie in der Anwendung verschlüsseln/entschlüsseln, werden vertrauliche Daten (einschließlich des Schlüssels) niemals außerhalb des Anwendungsservers angezeigt. Jemand müsste sowohl den Webserver als auch den Datenbankserver kompromittieren, um auf alle Ihre Daten zugreifen zu können.

Außerdem würde ich Ihnen wärmstens empfehlen, Ihre eigene Verschlüsselungsroutine nicht zu rollen. Wahrscheinlich werden Sie einen Fehler machen, der die Gesamtsicherheit Ihrer Lösung verringert.

EDIT:

wollte auch einen weiteren Faktor hinzu, die Ihre Entscheidung beeinflussen. Müssen Sie von diesen verschlüsselten Daten abfragen? Wenn Sie auf Anwendungsebene verschlüsseln, müssen Sie die Daten zur Anwendung bringen, entschlüsseln und von dort aus arbeiten. Dies wird untragbar, da der Datensatz größer wird - während Sie bei der Datenbankverschlüsselung die Daten filtern können, bevor sie an die Anwendung gesendet werden.

Answer 2

Ich stimme Mayo, aber Verschlüsselung in der DB könnte die Wartung des gesamten Systems vereinfachen.

Bei der Verschlüsselung auf der Anwendungsebene müssen Sie die Schlüssel, die Authentifizierungs- und Autorisierungsphase für die Schlüssel und die Visualisierung der Daten verwalten (entsprechend dem, was Mayo geschrieben hat).

Wenn Sie Application Encryption wählen, müssen Sie sich nicht nur in der Entwicklungsphase, sondern auch in der Wartungsphase Gedanken über die Korrektheit des Algorithmus machen. Sie müssen Unit-Test für keine Regression implementieren. Sie müssen die Änderung des Verschlüsselungsalgorithmus verwalten, weil Sie vielleicht einen anderen und besseren Algorithmus wünschen.

Und Sie müssen sicher sein, dass verschlüsselte Daten immer entschlüsselt werden. Das liegt nicht auf der Hand, denn Software hat Bugs und so weiter. Verlorene Daten sind schlimmer als klare Daten ;-)

Sicher können Sie eine bekannte Verschlüsselungsbibliothek verwenden, aber all die verbleibenden Dinge sind eine riesige Arbeit für Sie zu tun.

Verschlüsselung in der DB schützt nur in der DB, aber Sie können erwägen, irgendeine Art von SSL-Kommunikation mit der DB zu verwenden. Ich denke (aber ich bin mir nicht sicher) TDE implementiert diese Art von sicherer Kommunikation.

Anwendung wird vom Benutzer verwendet, eine nicht vertrauenswürdige Einheit. Sie müssen berücksichtigen, dass die Daten in der Anwendung verloren gehen. Warum? Wenn ich Daten von einem System stehlen möchte, das Verschlüsselung der Daten auf Anwendungsebene oder DB-Ebene implementiert, könnte es genug sein, eine Fotokamera zu verwenden, um die Daten zu erhalten! Sehr einfach!

Sie müssen die Sicherheit des Systems berücksichtigen, aber auch die Funktionalität. Mehr ist die Sicherheit, weniger ist die Funktionalität. Ich hoffe, meine Überlegungen werden Ihnen nützlich sein.

Answer 3

Wenn Sie vertrauliche Daten verschlüsseln, beschränken Sie im Wesentlichen den Zugriff auf Benutzer, die Zugriff auf einen Schlüssel haben. Das Problem wird dann zu einem Schlüsselmanagement: Es wird sichergestellt, dass nur autorisierte Personen/Systeme Zugriff auf den Schlüssel haben, der zum Entschlüsseln der Daten benötigt wird.

Sie sollten natürlich einen Standard-Verschlüsselungsalgorithmus verwenden, der in diesen Tagen leicht genug ist, aber Sie müssen darüber nachdenken, vor welchen Bedrohungen Sie schützen, wie Sie den Zugriff auf den Schlüssel kontrollieren und wie Sie den physischen Zugriff auf die Server steuern.

Die Verwendung von TDE stellt sicher, dass der Inhalt einer Datenbank und deren Backups mit minimalen Auswirkungen für autorisierte Benutzer der Datenbank verschlüsselt werden. So kann jeder, der mit gültigen Zugangsdaten auf den Datenbankserver zugreifen kann, die unverschlüsselten Daten sehen. Außerdem hat jeder DBA normalerweise Zugriff auf den Schlüssel und kann die unverschlüsselten Daten sehen. Aber ein Drittanbieter, der beispielsweise ein externes Backup erhält, kann nicht auf die Daten zugreifen - was für die Einhaltung regulatorischer Anforderungen wichtig sein kann.

Auf der anderen Seite, wenn Sie in der Anwendungsebene verschlüsseln, können Sie einen Schlüssel verwenden, auf den nur Administratoren des Anwendungsservers zugreifen können. Dies gibt Ihnen möglicherweise mehr Sicherheit, wenn zum Beispiel Datenbankserver- und Anwendungsserveradministratoren getrennt gehalten werden (z. B. Mitglieder verschiedener Organisationen). Datenbankadministratoren, die keinen Zugriff auf den Anwendungsserverschlüssel haben, können die Daten nicht sehen.

In Ihrem ursprünglichen Beitrag sprechen Sie über das Verstecken eines geheimen Schlüssels in einer Konfigurationsdatei auf dem Anwendungsserver. Auf den ersten Blick klingt es wie das Sicherheitsäquivalent, den Schlüssel der Haustür unter der Fußmatte zu verstecken. Wenn Sie dies tun, müssen Sie darüber nachdenken, wie Sie sicherstellen, dass nicht autorisierte Personen nicht auf den Schlüssel zugreifen können.

Answer 4

Being PCI-DSS-konform nicht Ihre gesetzliche Haftung entfernen ...

Derzeit gibt es nur zwei Zustände, die eine solche Freistellung bieten: Washington & Minnesota ...

Förderung TDE DBA als PCI-DSS-Lösung ACHTUNG!

TDE schützt nur Daten im Speicher, die Daten nicht auf der Durchreise oder Daten im Speicher ... Wer den Zugang gelesen hat, die alle Daten mit einem beliebigen Werkzeug lesen kann ...

IMHO TDE gut ist, wenn sie kombiniert mit einer robusten Application-Level-Verschlüsselungslösung ... Als eigenständige Lösung mit TDE allein ist es eine tickende Zeitbombe, dass die PCI-QSAs, die es als PCI-DSS Compliant gekauft haben, kläglich gescheitert sind, ... Warten Sie, bis die Anwälte diesen grundlegenden Fehler verstehen ...

Jeder Sicherheitsguru wird Ihnen sagen, dass Sicherheitsschichten der beste Ansatz sind ....