Soll ich Daten in der Datenbank verschlüsseln?

16

Ich habe einen Kunden, für den ich eine Webanwendung zum Thema Patientenversorgung, Verwaltung von Patienten, Konsultationen, Verlauf, Kalender usw. erstellen werde.

Das Problem ist, dass es sich um sensible Daten, Anamnese und dergleichen handelt.

Der Client besteht darauf, die Daten auf Datenbankebene zu verschlüsseln, aber ich denke, dies wird die Leistung der Web-App beeinträchtigen. (Aber vielleicht sollte ich mir keine Sorgen machen)

Ich habe die Gesetze zum Datenschutz in Gesundheitsfragen gelesen (Portugal), bin aber nicht sehr genau darüber informiert (ich habe sie nur gefragt, ich warte auf ihre Antwort).

Ich habe den folgenden Link gelesen , aber meine Frage ist anders, ob ich die Daten in der Datenbank verschlüsseln soll oder nicht.

Ein Problem, das ich beim Verschlüsseln von Daten sehe, ist, dass ich einen Schlüssel benötige. Dies könnte das Benutzerkennwort sein, aber wir alle wissen, wie Benutzerkennwörter lauten (12345 usw. usw.) und einen Schlüssel zu generieren, den ich speichern müsste bedeutet dies, dass der Programmierer, dba, was auch immer Zugriff darauf haben könnte, irgendwelche Gedanken dazu?

Selbst das Hinzufügen eines zufälligen Salt zum Benutzerkennwort wird das Problem nicht lösen, da ich immer darauf zugreifen und die Daten entschlüsseln kann.

Tio
quelle
1
Ich bin eher ein clientseitiger Entwickler, aber ich vermute, dass durch die Verschlüsselung der Daten tatsächlich die Sicherheit abnimmt, wenn Sie denselben Schlüssel verwenden.
Erik Reppen
4
können Sie die gesamte Datenbank auf ein verschlüsseltes Volume stellen und es an einem Tag aufrufen. Sicher, dass Lese- / Schreibvorgänge langsamer sind, aber Sie behalten alle Vorteile von RDMS (oder was auch immer Sie verwenden), während die Daten auf der Festplatte verschlüsselt sind
DXM
2
Das bedeutet auch, dass Sie keine Daten in der MySQL Workbench sehen können? Alles Gute zum Debuggen.
Manoj R
4
Medizin ist eine stark regulierte Branche. Die Fachleute, die dort arbeiten, sind es gewohnt, sich von jemandem die Regeln erklären zu lassen. Diese Denkweise soll sich auf IT-Projekte auswirken. Es ist nicht wirklich ein Sicherheitsproblem. Es ist ein kulturelles Problem. Die Kosten für Geschäfte im medizinischen Bereich.
Reactgular
1
Ein Krankenhaus in Großbritannien wurde mit einer Geldstrafe von über 300.000 GBP belegt, weil Festplatten mit unverschlüsselten Datenbanken verloren gingen. Gesundheitsinformationen sind sehr sensibel.
MarkJ

Antworten:

9

Ich würde die Gesetze dazu persönlich überprüfen. Wenn die Daten verschlüsselt werden müssen, müssen sie verschlüsselt werden.

Wenn Sie jedoch keine Anleitung erhalten, möchte ich die Verbindung zwischen dem Patienten und seinen Daten schützen. Das heißt, Sie haben höchstwahrscheinlich eine PatientID, die in Tabellen in der gesamten Datenbank verwendet wird. PatientIDidentifiziert keinen Patienten, nur die Krankengeschichte des Patienten usw ... Um jedoch den PatientIDin der Rua de São Bernardo in Lissabon lebenden Joe Bloggs zu identifizieren , würde ich diesen in einem separaten DB aufbewahren, wenn ich kann. Verwenden Sie TDE für die persönlichen Daten des Patienten und verschlüsseln Sie es gegebenenfalls zusätzlich mit Schlüsseln in Ihrer Webanwendung.

Obwohl der Diebstahl dieser medizinischen Daten ohne die Mittel zur Identifizierung der Patienten äußerst peinlich sein wird, ist es unwahrscheinlich, dass etwas darüber hinausgeht. Es gibt buchstäblich Online-Wettbewerbe , die diese anonymisierten medizinischen Daten verwenden.

Mit der Trennung der medizinischen Daten von den persönlichen Daten des Patienten. Verwenden Sie eine Reihe von Funktionen, um das Personal auf das zu beschränken, was es benötigt. Mit Ausnahme des medizinischen Personals, das den Patienten direkt behandeln muss (Krankenschwestern und Ärzte an vorderster Front), sollte niemand Zugang zu beiden haben. Empfangsmitarbeiter benötigen nur die persönlichen Daten des Patienten, Laborpersonal benötigt nur die Krankenakte und die Patienten-ID, OP-Krankenschwestern nur den aktuellen Gesundheitszustand und den Vornamen.

Wenn Sie die einzelnen Rollensätze identifiziert haben, möchten Sie diese nicht nur in Ihrer Webanwendung, sondern auch in der Datenbank sowie in einer zusätzlichen Sicherheitsebene implementieren.

M Afifi
quelle
1
IANAL, aber IMO-Laien sollten nicht "die Gesetze überprüfen", wenn die mögliche Haftung groß ist. Sie sollten einen Anwalt konsultieren.
Kevin Cline
Ich gehe mit diesem Ansatz als wahre Antwort. Medizinische Aufzeichnungen, die weder mit Patienten noch mit Ärzten in Verbindung stehen, sind bedeutungslos und unbrauchbar, selbst für statistische Analysen, da sie keinen Bezug haben oder beweisen, dass sie nicht erfunden sind.
Zalaboza
13

Ja, Sie sollten die Datenbank verschlüsseln.

Die grundlegende Verschlüsselung für gespeicherte Daten ("Daten in Ruhe") ist ein allgemein anerkanntes Sicherheitsprinzip und wird wahrscheinlich gesetzlich vorgeschrieben, wenn in Ihrem Land Gesetze zum Schutz persönlicher oder gesundheitlicher Informationen gelten.

Wir verwenden SQL Server 2008, also verwenden wir Microsofts TDE. Möglicherweise gibt es eine Lösung von Drittanbietern für MySQL, oder es könnte nur ein allgemeiner Ansatz zur Volumenverschlüsselung (wie TrueCrypt) funktionieren (obwohl ich etwas haben möchte, das für die Verwendung mit einer Datenbank zertifiziert wurde).

Wenn es richtig gemacht wird, sollte der Leistungseinbruch gering sein.

Übrigens ist der von Ihnen erwähnte Link (in Bezug auf die Trennung vertraulicher Informationen) etwas, das Sie zusätzlich zur grundlegenden Datenbankverschlüsselung berücksichtigen sollten.

EDIT: Die oben erwähnte Verschlüsselung würde das Volume verschlüsseln. Wenn jemand die Festplatte stiehlt, findet er die Daten verschlüsselt. Wenn jedoch jemand Abfragen in der Datenbank ausführen würde, würde er die unverschlüsselten Daten sehen (deshalb erwähnte ich die Trennung von Informationen, obwohl das OP dies nicht diskutieren wollte).

Beachten Sie, dass diese Empfehlung das Minimum darstellt, das Sie tun sollten. Wenn Sie Rechtsberatung wünschen, müssen Sie sich natürlich umsehen. Wenn Sie sich eingehender mit dem Schreiben von sicherem Code befassen möchten, beginne ich mit dem Buch Schreiben von sicherem Code .

jdigital
quelle
2
Ich bin mir nicht sicher, ob dies der Fall ist. Bei der Frage geht es nicht um die Verschlüsselung der Datenbank, sondern um die Verschlüsselung der Daten in der Datenbank. Das bedeutet, dass die Daten in SQL-Abfragen verschlüsselt werden.
Manoj R
1
Der Leistungstreffer sollte gering sein? Die Suche nach Daten ist LANGSAM. Das gesamte Konzept der Indizierung funktioniert nicht, wenn Daten verschlüsselt werden. Es ist ein vollständiger Tabellenscan erforderlich.
mike30
@mike Der oben beschriebene Ansatz würde das Volume verschlüsseln und keine Auswirkungen auf die Indizierung usw. haben.
jdigital
IMO benötigen Sie mehr Fachwissen, als Sie hier bekommen können. IANAL, aber ich denke, Ihr Kunde ist ziemlich exponiert, wenn diese Daten kompromittiert werden.
Kevin Cline
8

Bevor Sie sich für solche Sicherheitsaspekte entscheiden, sollten Sie das Bedrohungsmodell bewerten. Ohne eine Vorstellung davon, wogegen Sie sich verteidigen, sind Maßnahmen, die Sie ergreifen, wahrscheinlich von geringem Wert.

Nun, es gibt ein paar Dinge, über die Sie sich in diesem Zusammenhang Sorgen machen könnten:

  • Angreifer erhalten physischen Zugriff auf Ihre Daten (z. B. Eindringen in das Datencenter, Diebstahl von Sicherungsbändern usw.)
  • Angreifer erhalten Lesezugriff auf Ihre Rohdatenbank
  • Angreifer, die Ihre Anwendung gefährden, z. B. durch SQL-Injection, Pufferüberläufe usw.

Für das erste Szenario sollte das Speichern der Datenbank und aller Sicherungen auf verschlüsselten Volumes funktionieren, vorausgesetzt, der Server ist kopflos - ein Diebstahl des Servers oder der Bänder würde dann das Unterbrechen der Verschlüsselung auf Festplattenebene erfordern.

Im zweiten Szenario hilft das Verschlüsseln von Datenbankdaten, allerdings nur, wenn Sie die erforderlichen Schlüssel oder Passphrasen nirgendwo speichern.

Im dritten Szenario hängt alles vom Kontext ab, in dem der Angriff erfolgt: Wenn es sich beispielsweise um einen XSS- oder CSRF-Angriff handelt, kann ein Angreifer alles tun, was der legitime Benutzer kann, und die Verschlüsselung Ihrer Daten hilft überhaupt nicht .

Ihr Bedrohungsmodell ist daher ein Angreifer, der Lesezugriff auf die unformatierte Datenbank erhält, indem er entweder die Anmeldeinformationen ermittelt und sich von außen beim Datenbankserver anmeldet oder Root-Zugriff auf den Datenbankserver erhält. Ein typischer Weg besteht darin, zuerst auf dem Webserver auf die Shell zuzugreifen. Von dort aus kann ein Angreifer die Zugangsdaten aus der Konfigurationsdatei lesen und eine Verbindung zur Datenbank herstellen.

Eine weitere Überlegung ist, wo Sie die Schlüssel und Passphrasen aufbewahren, insbesondere wenn Sie eine Plattform mit einem zustandslosen Ausführungsmodell wie PHP verwenden. Im Idealfall muss der Kunde seine Passphrase bei Bedarf eingeben und sie nur im Speicher aufbewahren, oder noch besser, die Entschlüsselung clientseitig durchführen (dies ist jedoch häufig nicht möglich). Auf einer statusfreien Plattform wird der Status normalerweise über Sitzungen, Memcache, Datenbanken oder Flatfiles übertragen. All dies ist jedoch weitaus anfälliger, als den Status im eigenen Speicher einer statusbehafteten Webanwendung zu halten. Dies zu vermeiden ist ein Henne-Ei-Problem, denn wenn Sie den Status verschlüsseln, bevor Sie ihn beibehalten, haben Sie gerade ein weiteres Geheimnis erstellt, an das Sie sich sicher erinnern müssen. Sich die Passphrase auf dem Client zu merken und sie zusammen mit jeder Anforderung zu senden, die sie benötigt, kann dann die am wenigsten schreckliche Lösung sein.

tdammers
quelle
2
+1: Ohne ein Bedrohungsmodell schließen Sie höchstwahrscheinlich die Vordertür ab, lassen die Hintertür jedoch weit offen.
Kevin Cline
8

Ignorieren Sie für einen Moment, wonach der Kunde fragt und was auch immer die Gesetze sind ...

Nein, Sie sollten die Daten wahrscheinlich nicht verschlüsseln. Wenn Sie dies tun, können Sie es nicht einfach suchen. Wie würden Sie beispielsweise nach einem Nachnamen suchen, like 'Smith%'wenn jeder Namenseintrag verschlüsselt wäre? Wie würden Sie den Blutdruck eines Patienten im Laufe der Zeit bestimmen, wenn Sie nicht können? select .... from.... where patient_id = N ?

Sie sollten natürlich sicherstellen, dass der Server ordnungsgemäß gesichert ist, dass die Netzwerkverbindung gesichert ist und dass die Benutzeroberfläche ordnungsgemäß gesichert ist (einschließlich Sitzungs-Timeouts, damit Benutzer nicht weggehen und den Zugriff jedem überlassen können, der ihren Computer verwendet). Möglicherweise möchten Sie auch Datenbanksicherungen verschlüsseln. Und physisch den Raum sichern, in dem sich der Server befindet. Aber ich würde die Live-Daten nicht verschlüsseln.

Erläuterung: Dies setzt voraus, dass das OP die Daten in der Datenbank tatsächlich verschlüsselt . Nicht das Dateisystem, auf dem sich die Datenbank befindet.

GroßmeisterB
quelle
stimme völlig zu, aber GESETZE nicht :(
Zalaboza
1
Nun, Sie könnten, AES_DESCRYPT('') LIKE 'Smith%'wenn auch unglaublich langsam. Oder Sie könnten intensiv werden und einen invertierten Index mit gesalzenen Hashes
erstellen
1

Wenn Sie die Webanwendung sorgfältig mit einem effektiven MVC-Framework wie CakePHP entwickeln. Zend oder Rails, dann sollten Sie in der Lage sein, die Verschlüsselung auf Datenmodalebene zu aktivieren / deaktivieren.

CakePHP zum Beispiel hat einige Beispiele für Verhaltensweisen von Modal, die Daten verschlüsseln. Den Prozess für die Controller und Ansichten transparent machen.

Ignorieren von Problemen mit der Indizierung und anderen Problemen mit der technischen Datenbank, wenn Sie dies tun. Dies sollte als konfigurierbare Option möglich sein.

Außerdem würde ich die Verschlüsselung entweder zu einem späteren Zeitpunkt oder nur auf dem Produktionsserver aktivieren. Verschlüsselte Daten sind während der Entwicklung nur schwer zu debuggen und zu verarbeiten und können nur in bestimmten Spalten ausgeführt werden.

Reactgular
quelle
1

Ja, Sie sollten die Datenbank verschlüsseln.

Da es sich um persönliche und sensible Informationen handelt, glaube ich definitiv, dass dies so sein sollte.

Aus dem Kennwort können Sie einen Verschlüsselungsschlüssel ableiten, den Sie nur für die Sitzung speichern. Auf diese Weise wird es nirgendwo gespeichert und niemand (einschließlich Datenbankadministratoren) kann es wissen, da auch niemand das Kennwort kennen kann. Jeder, der versucht, die Datenbank direkt anzuzeigen, sieht sich Kauderwelsch an. Die einzige Möglichkeit, dies zu beschädigen, ist das Hijacken von Sitzungen, aber ich gehe davon aus, dass Sitzungen auch sicher sind.

dagnelies
quelle
Die Leute vergessen sehr oft ihre Passwörter ... und was dann?
neugierig
-1

Ich frage mich, warum der Client Sie auffordert, die DB zu verschlüsseln. Wenn er Sie bitten würde, die Daten zu schützen, würde ich zustimmen, aber er hat bereits eine implizite Implementierung im Auge. So lange er nicht genau weiß, wovon er spricht, wirft er aus meiner Sicht nur Schlagworte.

Ich finde es auch sehr nutzlos, die DB zu verschlüsseln, da ich davon überzeugt bin, dass buchstäblich jedes wichtige DBMS die Sicherheit angemessen berücksichtigt und wahrscheinlich besser als Sie. Um über das DBMS auf die Datenbank zugreifen zu können, benötigen Sie Anmeldeinformationen. Im Falle einer verschlüsselten Datenbank würden Sie auch diese Anmeldeinformationen benötigen, und um die Daten zu entschlüsseln, würden Sie diese Anmeldeinformationen benötigen, die Sie anscheinend bereits haben.

Wenn ich dieser Denkweise folge, schlage ich vor, dass das DBMS die Sicherheit handhabt und sich bemüht, die Anmeldeinformationen von der Benutzereingabe bis zum Datenbankzugriff zu schützen. Dies kann auch zu starken Passwörtern und regelmäßigen Änderungen führen.

sschrass
quelle
... jedes wichtige DBMS berücksichtigt die Sicherheit ... außer wenn dies nicht der Fall ist .
Jay Elston
Die erste Frage, die ich stellen müsste, ist, wie sie das gemacht haben und wie der Schaden durch Verschlüsselung der Datenbank verhindert werden kann. Ich habe diesen Artikel nur schnell durchgesehen, hatte aber den Eindruck, dass sie über Berechtigungsnachweise verfügten.
Schrumpf
Genau - DB-Anmeldeinformationen können und werden gefährdet. Die Herausforderung besteht darin, das System so zu gestalten, dass nicht autorisierte Benutzer auch dann Zugriff auf die Anmeldeinformationen erhalten, wenn sie zusätzliche Verschlüsselungsschlüssel benötigen, um auf vertrauliche Daten zugreifen zu können. Für Gesundheitsinformationen ist dies noch komplizierter. Nicht jeder, der Zugriff auf die DB-Anmeldeinformationen hat, sollte auf vertrauliche Daten zugreifen können. Beispielsweise sollte der DBA die Patientendaten nicht im Klartext lesen können. Die einzigen Personen, die diese Daten lesen können sollten, sind die Patienten und ihre Versorger.
Jay Elston