DSGVO - Verschlüsselung der Daten at-rest
-
@Marcel Korrekt. Es gibt viele (unkomplizierte) Möglichkeiten, die Daten at-rest zu verschlüsseln.
Die Frage ist, ob dies gemacht wird oder nicht.
-
Es ist richtig, dass wir die Wiki Daten verschlüsselt abspeichern. Dazu verwenden wir die MariaDB Encryption und verschlüsseln / entschlüsseln die Daten direkt über den Datenbank Controller. Aktuell wird dafür eine AES Verschlüsselung mit einem 128-bit Key verwendet.
Die Daten sind also, selbst bei einem ungewollten Zugriff auf die DB geschützt. Den Key speichern wir natürlich an einer anderen Stelle und nicht in der DB auf
Eine Verschlüsselung der Disks bzw auf Physischer Ebene machen wir nicht, das wäre Performancemäßig nicht machbar bar bzw. für uns nicht finanziell tragbar. Mir ist auch nicht bewusst, dass das üblich wäre bei Webprojekten in einem Banken-Kontext könnte ich mir das ggf. noch vorstellen, aber nicht für "einfache" Webprojekte.
-
@hbuerger Danke für die Antwort, für das Wiki habt ihr das ja auch so dokumentiert. Die Frage ist, ob auch die Personendatensätze mit MariaDB Encryption gesichert sind oder als Plain Text in der Datenbank liegen.
Falls letzteres: Was spricht dagegen, hier genauso wie bei den Wiki Daten vorzugehen?
-
Personendaten werden nicht verschlüsselt abgelegt. Das hat mehrere Gründe:
- Wiki Daten können sensibler sein.
Kunden nutzen das Wiki u.A. um sensible Daten über andere Personen dort abzuspeichern und zu dokumentieren. Daher wurde die Sicherheitsstufe für diese Text erhöht und die Texte werden verschlüsselt.
- Der Datenschutz verlangt keine Verschlüsselung
Es ist eine falsche Annahme, dass der Datenschutz eine Verschlüsselung vorschreibt. Die Daten dürfen lediglich nicht ohne Kontrolle / Erlaubnis zugänglich sein. Das ist der Fall. Durch unser fein-granulares Rechtesystem kann man genau einstellen, wer welche Daten sieht.
- Hosting: Datenbanken sind abgeriegelt
Wir haben hohe Sicherheitsstandards und stellen sicher, dass die Datenbanken nur von uns festgelegten Usern und aus festgelegten Orten zugänglich sind. D.h. Auf die Datenbanken kommt daher sowieso keiner drauf, der das nicht soll. Ich kann hier natürlich nur für unsere Hosting Kunden sprechen. Wer CT Self-Hostet ist dafür selber verantwortlich.
- Performance
Verschlüsselung kostet. Das kostet Zeit und damit wird ChurchTools langsamer. Es ist daher nicht üblich einfach alles zu verschlüsseln. Es ist immer eine Abwägung zw. Kosten-Nutzen und da gerade die Personen Daten die mit Abstand frequentiertesten Datensätze sind in ChurchTools wäre es eine denkbar schlechte Idee diese von der Datenbank verschlüsseln zu lassen.
Ich hoffe das beantwortet die Frage
-
Danke. Für mich schon. Ist immer schön zu sehen, wenn insbesondere Sicherheitsrelevante Designentscheidungen transparent erklärt werden.
-
@hbuerger die ersten drei Punkte kann man diskutieren, aber der vierte ist einfach nicht richtig.
Aktuelle Prozessoren machen machen AES in Hardware, Serverprozessoren wahrscheinlich schon seit 10 Jahren. Der Overhead ist je nach Technologie vernachlässigbar. Hier ein kleiner Vergleich für Disk/FS-Encryption: https://www.phoronix.com/scan.php?page=article&item=ext4-crypto-418&num=1
Das wohl schwerwiegendeste Argument ist doch, dass ihr Hetzner vertraut und die Verschlüsselung an der gefragten Stelle ausschließlich gegen physischen Zugriff schützt.
-
@hbuerger
ad 1) das kann man nicht generell sagen. Persönliche Daten sind persönliche Daten
ad 2) Vollkommen richtig
ad 3) Naja. Das ist kein Argument. Fehler gibts immer. Sicherheitslücken auch.
ad 4) In Wahrheit vernachlässigbar ...An sich ist das Problem hier eher folgendes:
Wenn man die Disken verschlüsselt sind sie nur verschlüsselt solange das System nicht läuft. Sprich: Kann man sich sparen. DB seitige Verschlüsselung hilft nur, wenn die DB auf einem anderen System läuft als der Rest der Webanwendung (der Teil der den Key zum entschlüsseln hat) und auch dann nur, wenn ich davon ausgehe dass die DB Maschine die größere Angriffsfläche hat. Jetzt ist es aber sehr viel einfacher den Zugriff auf die DB abzusichern (z.b.: nur für die Webserver, bzw. das Netz aus dem die Admins daher kommen) als den Zugriff auf den Webserver.
Sprich das System mit der größten Angriffsfläche, die PHP Applikation auf einem public Webserver hat auch den Key mit dem die Daten entschlüsselt werden und Zugriff auf die Datenbank. Verschlüsselung in der DB tut da nicht weh, aber groß helfen tut es praktisch gesehen nicht.
Was anderes wäre es wenn es sich um ein shared DB System handelt. das die DBs von mehreren Gemeinden hostet. dann würde ein einfach Bug schon den Zugriff auf die Daten anderer Gemeinden ermöglichen. Keine Ahnung wie das Hosting von Churchtools genau aussieht, aber deshalb macht es Sinn (wenn man denn weiß was man tut) selbst zu hosten, anstatt hosten zu lassen. Die DSGVO sagt nämlich per sie dass die Daten ein erfassende Partei die Verantwortung trägt und nicht diejenige die die Daten speichert. Im Falle eines Problems kann man zwar versuchen sich schadlos zu halten wenn man ein entsprechendes Zertifikat / Agreement vom Provider hat. Mehr aber auch nicht.
-
@Marcel Wir sprechen von Hosting bei Hetzner, das hat im Normalfall mit Serverhardware nix zu tun.
-
Ich habe gedacht, dass grundsätzlich durch https:// als SSL/TLS die Daten verschlüsselt werden.
Kann ja sein, dass ich mich irre. Bin davon ausgegangen, dass die Datenbank per SSL/TLS verschlüsselt ist. -
@fcgkitzingen SSL/TLS bezieht sich nur auf die Verbindung zwischen dem Nutzer Computer und dem Server auf dem CT läuft. Die Verschlüsselung der Datenbank und anderer Daten müsste von CT oder dem Datenbanksystem selbst auf dem Server durchgeführt werden.
-
@deliarmin danke für die Erklärung, ich dachte immer CT läuft im RZ von Hetzner & somit hätte Hetzner physischen Zugriff auf die Serverhardware. Aber dann habe ich mich da wohl geirrt.
