it-swarm-eu.dev

Verwaltung von Verschlüsselungsschlüsseln für Webanwendungen

Kurz gesagt, betrachten wir eine Webanwendung, die einige Informationen in einer Datenbank als verschlüsselte Daten speichert. Während ich absichtlich versuche, dies etwas allgemein zu halten, sind hier einige Annahmen:

  • Die verschlüsselten Daten werden nur in der Datenbank gespeichert (nicht anderswo). Einige Felder in einem bestimmten Datensatz sind verschlüsselt, andere nicht.
  • Die Web-App muss die verschlüsselten Daten in die Datenbank schreiben.
  • Die Web-App muss verschlüsselte Daten lesen und anzeigen können. Daten werden nur in einem authentifizierten und autorisierten verwalteten Bereich der App angezeigt.
  • Bei den Daten handelt es sich um vertrauliche Informationen, die geschützt werden müssen, falls die Daten verfügbar gemacht werden (ohne die Schlüssel *).

Fragen :

  • Wo/wie speichern Sie die für die Verschlüsselung verwendeten Schlüssel? Wie verwalten Sie den Schlüssel in einem System, in dem Web- und Datenbankserver identisch sind? Zweitens, wie verwalten Sie den Schlüssel in Systemen, in denen der Webserver und der DB-Server getrennt sind?
  • Sind Schlüssel nur Dateien mit eingeschränkten Berechtigungen? In einem separaten Tool/einer separaten Software gespeichert? Ich habe erwähnt, dass manchmal die Verschlüsselungsschlüssel auch verschlüsselt sind, aber nicht klar, wo das helfen kann.

Ich weiß, dass dies eine ziemlich grundlegende Sicherheitsfrage ist. Wenn es also Ressourcen gibt, die mir vielleicht fehlen, wäre das auch sehr, sehr hilfreich. Ich habe (im Laufe der Jahre) viel Zeit damit verbracht, diese Informationen basierend auf Informationen zur Sicherheit von Web-Apps (OWASP, PCI DSS usw.) zu erfassen, aber oft sind diese Informationen sehr allgemein gehalten (z. B. "Daten schützen") "," Daten verschlüsseln ") oder sehr spezifisch (" um etwas mit AES zu verschlüsseln, tun Sie dies ... ").

* Ich verstehe, dass dies keine vollständige Sicherheitslösung für sich ist. Ich verstehe, dass es mehrere Vektoren gibt, um an diese Informationen zu gelangen und sie zu dekodieren. Ich erkenne an, dass dies in diesem Licht eine schlechte Frage sein kann :)

Bearbeitet, um dieser Frage weitere Informationen zu den Annahmen hinzuzufügen

47
Rob

Wo/wie speichern Sie die für die Verschlüsselung verwendeten Schlüssel?

Standardansatz Wenn Sie eine integrierte Verschlüsselung für eine SQL- oder Oracle-Datenbank verwenden, generiert die Datenbank einen Verschlüsselungsschlüssel und verschlüsselt diesen mit einem anderen Schlüsselschutzschlüssel oder Hauptschlüssel. Dies kann eine Passphrase oder ein längerer Schlüssel sein, der z.B. .pem Datei.

Dies wird normalerweise in einem eingeschränkten Verzeichnis gespeichert, auf das nur root/Administrator und das Datenbankdienstkonto zugreifen können. Bei der Datenbankinitiierung wird der Schlüssel gelesen und in den Speicher geladen. Dies wird dann verwendet, um die Verschlüsselungsschlüssel zu entschlüsseln.

Erstens, in einem System, in dem Web- und Datenbankserver identisch sind, wie verwalten Sie den Schlüssel?

Der Schlüssel wird in einem Verzeichnis auf dem Server gespeichert. Das Erneuern oder Widerrufen erfolgt normalerweise über das Datenbankprogramm.

Zweitens, in Systemen, in denen der Webserver und der DB-Server getrennt sind, wie verwalten Sie den Schlüssel?

Der Schlüssel wird lokal nur auf dem Datenbankserver gespeichert. Eine sicherere Option ist die Verwendung eines Hardware Security Module (HSM) in beiden Szenarien. Dies ist ein Hardwaregerät, das an den Server angeschlossen ist und zum Speichern des Schlüssels anstelle eines eingeschränkten Ordners auf dem Server verwendet wird.

Sind Schlüssel nur Dateien mit eingeschränkten Berechtigungen? In einem separaten Tool/einer separaten Software gespeichert? Ich habe erwähnt, dass die Verschlüsselungsschlüssel manchmal auch verschlüsselt sind, aber nicht klar ist, wo dies helfen kann.

Das Einschränken des Ordners ist zulässig, solange Sie den Administratorzugriff verwalten und nach nicht autorisierten Anmeldungen, Anmeldungen als Dienstkonto, neuen Konten oder Gruppen suchen, die mit Zugriff auf den Ordner hinzugefügt wurden. Wie oben erwähnt, ist ein HSM die sicherere Option, wenn die von Ihnen geschützten Daten und die Bedrohungen, denen Sie ausgesetzt sind, diese benötigen.

Im Allgemeinen erstellt die Datenbank Instanz- oder Tabellenschlüssel und verschlüsselt diese dann mit dem Hauptschlüssel. Die weitere Verschlüsselung des Hauptschlüssels bietet nur minimale Vorteile.

11
Rakkhi

Während in der vorherigen Antwort einige gute Informationen bereitgestellt wurden, gibt es einen kritischen Konstruktionsfehler, der nicht wirklich bemerkt wird - sondern auf einigen der impliziten Annahmen in der Frage beruht.

Der Unterschied sollte nicht sein zwischen:

  • Web-App und DB auf demselben Server
  • Web App und DB auf verschiedenen Servern
  • anwendung vs. DB-Verschlüsselung

Das Design sollte beginnen von:

  • Wer benötigt Zugriff auf die Verschlüsselungs-/Entschlüsselungsschlüssel?

Oder sogar noch korrekter:

  • Wer ist für den Schutz der Vertraulichkeit der Daten verantwortlich?

Was wiederum kommt von:

  • Vor welchen Bedrohungen versuchen Sie sich zu schützen?
    Oder
  • Wen möchten Sie daran hindern, Ihre Daten zu lesen?

Nur basierend auf diesen Fragen können Sie ein ordnungsgemäß entwickeltes Kryptosystem entwerfen. (Und verhindern Sie den Krypto-Feen-Staub, auf den sich @ D.W. bezieht).

Einige Beispielszenarien:

  • Der Benutzer sollte für die Verschlüsselung verantwortlich sein und verhindern, dass selbst die App-Administratoren die Daten sehen
  • Die Clientanwendung sollte verantwortlich sein, ohne den Benutzer einbeziehen zu müssen - dies muss jedoch noch clientseitig erfolgen (z. B. ein Sicherungsprogramm).
  • Der Appserver verschlüsselt ausgewählte Daten als Teil der Geschäftslogik anwendungsmäßig und spezifisch (selbst die Datenbank kann die Daten nicht sehen).
  • Der Datenbankserver sollte gespeicherte Daten automatisch und transparent verschlüsseln. (Dies schützt nur vor Diebstahl der Datenbankdatei/physischen Festplatte, mit Einschränkungen ...).

Nehmen wir zur Vereinfachung an, dass die Verschlüsselung serverseitig erfolgen sollte, die Verantwortung beim Server liegt und der Endbenutzer (und Administrator) keinen Einfluss auf die Verschlüsselung hat.

Die Hauptfrage ist also, ob die Verschlüsselung vom Anwendungsserver oder vom Datenbankserver durchgeführt wird. (Eigentlich nicht so einfach, es gibt andere Möglichkeiten ...)
Dies führt, wie die meisten Sicherheitsprobleme, zu einem Kompromiss:

  • Verwalten Sie Ihre eigenen Schlüssel oder bevorzugen Sie die automatische Zusammenfassung der Infrastruktur? (die ursprüngliche Frage ... mehr Infos unten ...)
  • Sind Sie besorgt über böswillige (oder inkompetent unerfahrene) Programmierer?
  • Sind Sie besorgt über böswillige Administratoren?
  • Befürchten Sie die Verwendung nicht autorisierter Anwendungen?
  • Befürchten Sie einen nicht autorisierten SQL-Zugriff?
  • Befürchten Sie unbefugten direkten Dateizugriff?
  • Sind Sie besorgt über den Diebstahl physischer Festplatten/Server?

Und so weiter. (Beachten Sie, dass einige der oben genannten Fragen irrelevant sind und nicht durch Serververschlüsselung gelöst werden können.).


Nehmen wir nun an, Sie haben auf der Grundlage des oben Gesagten Ihre Entscheidung zwischen Appserver-Verschlüsselung und Datenbankverschlüsselung getroffen.
Beachten Sie, dass die Frage, ob sich der Webserver und die Datenbank auf demselben Server befinden oder nicht, hier fast keine Auswirkungen hat. Wenn die App verschlüsselt, werden nur "spezielle" Daten an die Datenbank gesendet, andernfalls ist dies umstritten. Dies tut wirkt sich jedoch auf die obige Bedrohungsdiskussion aus - einige Probleme werden durch das Design überholt, andere werden verbessert ...

  • Web-/Anwendungsserververschlüsselung
    • Der Verschlüsselungsschlüssel (EK), mit dem Sie die Daten verschlüsseln, sollte selbst mit einem Schlüsselverschlüsselungsschlüssel ( KEK).
    • Das verschlüsselte EK sollte an einem geschützten Ort gespeichert werden - dies kann eine Datei sein, ein Registrierungsschlüssel, was auch immer - das Wichtigste ist, den Zugriff darauf nur auf den Benutzer des App-Servers (und möglicherweise auf den Administrator - siehe unten) zu beschränken.
    • Der KEK braucht auch Schutz - das ist etwas kniffliger.
      Wenn Sie unter Windows arbeiten, haben Sie einfachen Zugriff auf DPAPI - dies bietet eine Schlüsselverwaltung auf Betriebssystemebene, sodass Sie das Betriebssystem haben können verschlüsseln Sie Ihren KEK und verwalten Sie die Schlüssel transparent für Sie. (Hinter den Kulissen verlässt sich DPAPI schließlich darauf, das Kennwort des Benutzers zu kennen (in USER_MODE), sodass dies der letzte Schwachpunkt eines tatsächlich bekannten Geheimnisses ist - aber niemand anderes sollte wissen das Kennwort des Servers in der erste Platz, richtig?)
      Eine weitere Option ist das externe Gerät/HSM, das weiter unten erläutert wird.
    • Der KEK benötigt natürlich auch Zugriffskontrolle - restriktive ACLs und all das.
    • Es gibt mehrere Gründe, warum Sie die EK von der KEK trennen möchten: Sie möchten keine großen Datenmengen mit einem einzigen Schlüssel verschlüsseln. Wenn Sie den Schlüssel ersetzen müssen, wird es viel einfacher (verschlüsseln Sie den EK einfach mit dem neuen KEK neu). Sie können eine stärkere, langsamere und komplexere Verschlüsselung/Speicherung auf dem KEK verwenden. Wenn Sie PCI-kompatibel sein müssen, können Sie Split-Knowledge auf dem KEK implementieren. und mehr.
    • Sowohl der EK als auch der KEK sollten nicht langfristig unverschlüsselt gespeichert werden - abhängig von Ihrer Plattform/Sprache bedeutet dies, z. nicht in einem String-Objekt in .NET oder Java speichern. Speichern Sie es stattdessen in veränderlichen Byte-Arrays und stellen Sie immer sicher, dass Sie es so schnell wie möglich entsorgen.
    • Einige Frameworks gehen sogar noch einen Schritt weiter und bieten bestimmte geschützte Objekte. Z.B. In .NET können Sie die Klassen System.Security.Cryptography.ProtectedMemory und/oder System.Security.Cryptography.ProtectedData verwenden, um die Schlüssel auch im Speicher zu schützen.
  • Datenbankverschlüsselung
    • Wenn Ihr Datenbankserver die Verschlüsselung durchführt, wird dies viel einfacher: Die Tabellen/Felder sind so konfiguriert, dass alle darin gespeicherten Daten automatisch verschlüsselt werden. Die Schlüsselverwaltung ist vollständig transparent (vom PoV der Anwendung, nicht vom DBA) bald.
    • Beispielsweise unterstützen Oracle und MS SQL Server beide die automatische integrierte Verschlüsselung. Für MSSQL ist die Schlüsselverwaltung komplex, ähnelt jedoch der oben beschriebenen. Vereinfacht: In der Datenbank ist ein EK gespeichert, das die Datenbank zum Ver- und Entschlüsseln von Tabellen oder Feldern konfigurieren kann. Dies befindet sich in einer geschützten Tabelle, die von einem KEK verschlüsselt und wiederum von einem KEK auf Serverebene verschlüsselt und wiederum mit DPAPI auf dem MSSQL-Dienstkonto verschlüsselt wird.
    • Alternativ unterstützt MSSQL auch die Verwendung von asynchroner Verschlüsselung, z. Speichern von öffentlichen/privaten Schlüsselpaaren - dies kann in bestimmten Szenarien hilfreich sein.
  • Dritte Option: externer Verschlüsselungsspeicher oder HSM (Hardware-Sicherheitsmodul) . Dies kann eine gemeinsam genutzte Hardware-Appliance, ein Server oder eine Hardware-Karte oder ein Dongle sein ... usw.
    • Diese Geräte sind so konzipiert, dass sie kleine Datenmengen - z. B. Ihren KEK - sehr sicher schützen.
      Wieder ein weiterer Grund, warum Sie die EK von der KEK trennen sollten. Auf diese Weise können Sie die Datenmassen mit EK effizient verschlüsseln und entschlüsseln und gleichzeitig die KEK sicher verwalten.
    • Der Zugriff auf den HSM erfolgt normalerweise über einen speziellen Treiber oder eine spezielle API. Möglicherweise können diese auch in die Datenbankverschlüsselung eingefügt werden (je nach Produkt usw.).
29
AviD