1. #1
    U-Labs Elite

    Registriert seit
    28.10.2011
    Beiträge
    559
    Thanked 235 Times in 154 Posts

    Standard [PHP/MySQL] DSGVO-Konforme Daten

    In einem neuen Projekt möchte ich grundlegend anfangen, gespeicherte Nutzerdaten (ob nun Domain, Adressen o.ä.) zu verschlüsseln.

    Hier stellt sich die Frage, wie sinnvoll das ganze ist und wie weit dieses Verfahren implementiert werden könnte.

    Hierbei gebe es zwei Methoden:
    Einmal direkt im SQL-Query mit AES zu arbeiten oder eben unmittelbar in PHP mit AES, bevor die Daten hespeichert werden bzw. wieder abgerufen werden.

    Ich tendiere zu der SQL-Seite, da ich dann direkt in dem Queries suchen und vergleichen könnte.

    Jetzt stellt sich aber die Frage, wie Sicher das ganze sein kann, wenn man einen festen Salt nutzt. Wer den herausbekommt, kann mit dem Zugriff der Datenbank das ganze ja trotzdem einsehen. Vielleicht wäre hier ein variabler Salt mit einem CONCAT möglich, wo zusätzlich der primary key mit untergebracht wird und vielleicht aich noch zusätzlich noch der Name der Tabelle...

    Was findet ihr für Sinnvoll? Gibt es da schon diverse Pattern?

  2. The Following User Says Thank You to Bubble Gum For This Useful Post:

    x BoooM x (04.04.2019)

  3. #2
    Projektleitung
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    4.005
    Thanked 8.301 Times in 2.480 Posts
    Blog Entries
    5

    Standard AW: [PHP/MySQL] DSGVO-Konforme Daten

    Das hängt stark von den Daten und Rahmenbedingungen ab. Du bist mit deinen Gedanken auch schon 3 Schritte zu weit. Erst mal sollte man wenigstens eine grobe Risikoanalyse durchführen. Sprich ermitteln welche Daten man voraussichtlich in welchem Umfang besitzen wird, wie kritissch diese zu bewerten sind, welche Risikofaktoren mit welchen Folgen drohen usw. Erst dann hat man einen Überblick über die Gefahren und kann entscheiden, welche wie gelöst werden. Fängt man von hinten an einfach irgendwie zu verschlüsseln, entsteht schnell eine Festung mit offener Hintertür.

    Zum Thema serverseitige Verschlüsselung:
    Grundsätzlich hast du die Problematik von serverseitiger Verschlüsselung bereits erkannt. Die Schlüssel müssen immer in irgend einer Form auf dem Server liegen. Wird mit einem Salt im Programm verschlüsselt in die Datenbank geschrieben, schützt das nur gegen eine reine Kompromittierung der DB. In einem größeren SQL-Cluster überlegenswert, auf einem kleinen Server der alle Dienste betreibt wäre das auf der Liste der Risikofaktoren eher unten. Wirklich sauberen Schutz kann man nur mit End-zu-End-Verschlüsselung realisieren.

    Der wiederum stellt die User vor Usability-Probleme und ist nicht immer praktikabel. Beispiel: Ich will einen Chat betreiben. Da wäre E2EE zumindest für die Nachrichten das, was definitiv Stand der Technik und angemessen ist. Mit der E-Mail Adresse in einem Forum wie UL macht das wenig Sinn. Vergisst der User sein Passwort, lässt sich die E-Mail Adresse nicht entschlüsseln, um ihm ein neues Passwort zu schicken...

    Das große Ganze
    In Szenario eines Angreifers, der den Server kompromittieren will, muss man sich aber im klaren sein: Wenn er Zugriff auf die (verschlüsselte) DB besitzt, hat er sehr wahrscheinlich bereits recht weitreichenden Serverzugriff. Und ist damit auf der Zielgeraden. Eine serverseitige Verschlüsselung kann ihn da bestenfalls noch etwas bremsen. Mit

    Und genau da würde ich viel eher ansetzen: Systeme härten, Angriffsfläche minimieren, RBAC nutzen, zeitnah patchen, ggf. den Server physisch sichern und so weiter. Die ganzen Best Practices, die im Prinzip nichts neues sind, aber im Alltag immer noch viel zu opft vernachlässigt werden. Deswegen sind die meisten Angriffe auch bis heute damit erfolgreich.

    So lange

    - die hippe NodeJS-Anwendung mit 999 Abhängigkeiten mit root Rechten im Docker-Container läuft, der den Docker-Socket mountet um zu prüfen ob der Datenbank-Container abgeschmiert ist
    - PHP 5.4 (!) und PHP 4 (!!!) Anwendungen noch betrieben werden, weil "es doch läuft und ja auch nur intern erreichbar ist"
    - Rennomierte Consultants Buildserver aufsetzen, bei denen jeder Linux-Anfänger mit 5 Min Basteln eine Shell (!) mit Schreibzugriff auf die gesamte Serverkonfiguration (!!!) aufsetzen unter Aufsicht eines langjährigen Mitarbeiters

    haben wir ganz andere Probleme. Ich würde nicht mit Gewalt alles verschlüsseln, sondern nur bei derart sensiblen Daten, wo das praktikabel ist und Sinn macht. Dafür ein (durchgängiges) Sicherheitskonzept, bei dem alle Best Practices umgesetzt werden. Wenn man es jetzt noch schafft, dieses Niveau langfristig zu halten, hat man schon viel gewonnen und ist ziemlich gut gerüstet. Wichtig ist zu verstehen, dass Sicherheit ein Prozess und kein einmaliges ToDo ist. Wenn ich mein System absichern will, muss ich die Risiken kennen und verstehen. Das gilt vom Entwickler bis hin zum Admin.


  4. The Following User Says Thank You to DMW007 For This Useful Post:

    x BoooM x (04.04.2019)

  5. #3
    U-Labs Elite

    Registriert seit
    28.10.2011
    Beiträge
    559
    Thanked 235 Times in 154 Posts

    Standard AW: [PHP/MySQL] DSGVO-Konforme Daten

    Vielen Dank für die ausführlichen Infos!

    Ja, eine Kompromittierung wird dann höchstwahrscheinlich jede Software betreffen. Es gäbe aber auch Fallbeispiele, wo dann Beispielsweise ausschließlich Zugriff auf der Datenbank erlangt wird - Hier kann der Angreifer, wenn er denn ausschließlich Zugang zur Datenbank haz, nichts mit anfangen.

    Das ganze könnte man für verschiedene Fälle vielleicht noch mehr absichern. Nehmen wir ein konkretes Beispiel: Der Angreifer wird höchstwahrscheinlich nicht so dumm sein und versuchen nicht all zu lange verbunden zu sein, damit das Risiko ggf. geringer ist. Hier gäbe es dann noch zusätzlich die Möglichkeit, den Salt auf die Maschine zu begrenzen und einfach eine Hardware-ID verwenden. Wenn der Angreifer dann Daten zieht um sich das ganze auf einem Duplikat ansehen will, würde er auch nicht drankommen, außer er analysiert erst die Infos und versucht an der originalen Hardware-ID zu gelangen. Das gabze wäre zwar nice, aber auch hier steht man ggf. wieder vor der Peoblemstellung, sollte das System mal ausfallen und man wäre gezwungen mit Backups ein neues System aufzusetzen. Desweiteren muss man definieren, welche Hardware-ID "sicher" bzw. sinnvoll ist. Angenommen man nimmt Hardware-ID's der Platten - Die wären bei Beschädigung schnell im Rechenzentrum ausgebaut und ersetztworden und somit gäbe es eine neue, andere Hardware-ID - Die Daten wären dann ggf. verloren.

    Es geht auch nicht darum mit Gewalt alles zu verschlüsseln, was geht, sondern simple Präventivmaßnahmen. Vorzugsweise über Beispielsweise Adressdaten.

    Um das ganze zu erläutern:
    Ich hin gerade dabei ein Hosting-Panel als OpenSource zu implementieren. Vorraussetzung des Panels ist aktuelle Software wo Beispielsweise kein Uraltes PHP zum einsatz kommt. Die Vorraussetzung ist auch immer gegeben, da das ganze zwingend unter einem neuen System installiert werden muss. Die Konfiguration ist aber auch relativ gut miteinander abgestimmt.

    Das Ziel ist es auch nicht "mal eben" ein paar Datensätze zu verschlüsseln sondern das ganze so weitgehend und langfristig zu integrieren, dass das ganze System veenünftig konzipiert ist.

Ähnliche Themen

  1. Personalausweisnummer und DSGVO/PAuswG
    Von Bubble Gum im Forum Security
    Antworten: 6
    Letzter Beitrag: 19.12.2018, 08:30
  2. Knuddels wieder Pionier: Erstes DSGVO-Bußgeld
    Von Chrissy im Forum Internet und Technik
    Antworten: 5
    Letzter Beitrag: 16.12.2018, 20:53
  3. Sysadmin-Info, wer hat die noch? Wäre Interessant für die DSGVO!
    Von Bubble Gum im Forum Fragen & Probleme
    Antworten: 6
    Letzter Beitrag: 01.11.2018, 10:47
  4. Antworten: 8
    Letzter Beitrag: 22.03.2014, 22:57
  5. Mysql Fehler
    Von x BoooM x im Forum Webentwicklung
    Antworten: 1
    Letzter Beitrag: 28.02.2013, 20:51
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150