Hello, verschlüsseln der Datenbank hat nur dann Sinn, wenn man die Datenbank vor dem Arbeiten damit wieder entschlüsseln kann. Es hat also meistens auch keinen Sinn, einzelne Spalten zu verschlüsseln, wenn man diese (datenbanintern) indizieren muss, um z. B. Relationen auflösen zu können. Es hat aber Sinn, eine solche Datenbank in einer privaten Umgebung zu hosten (was bei heutigen DSL-Anschlüssen durchaus möglich ist), und die Verbindung zum lastbehafteten Webserver zur weniger belasteten Datenbank in der privaten DMZ über eine VPN-Verbindung, bzw. (bei MySQL/MariaDB möglich) einen "intern" verschlüsselten Zugang zu sichern. Die Datenhohheit verbleibt damit im eigenen Hause, vorausgesetzt natürlich, man reißt dort keine weiteren Lücken auf. ## [Ergänzung]: _Die API auf dem Webserver darf dann selstverständlich keinen Vollzugriff auf die Tabellen der Datenbank haben und die Geschäftsregeln (Zugriffskontrolle, Historeie) müssen in der Datenbank vereinbart werden._ Als DB-Server reicht hier meistens schon eine Raspberry-PI 4.0b. Dieses Verfahren hat bereits 2001 mit M$-Access-Datenbanken gut funktioniert. Inzwischen sind die Netze ungefähr 160 mal so schnell (im Upload des DSL-Anschlusses und 1.470 mal so schnell im Download, der hier aber eher unwichtiger ist). Da sehe ich also für mäßig frequentierte Webseiten kein Nadelöhr. Du könntest auf diese Weise die Verschlüsselung in diejenige Schicht legen, in die sie ohnehin gehört! Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, verschlüsseln der Datenbank hat nur dann Sinn, wenn man die Datenbank vor dem Arbeiten damit wieder entschlüsseln kann. Es hat also meistens auch keinen Sinn, einzelne Spalten zu verschlüsseln, wenn man diese (datenbanintern) indizieren muss, um z. B. Relationen auflösen zu können. Es hat aber Sinn, eine solche Datenbank in einer privaten Umgebung zu hosten (was bei heutigen DSL-Anschlüssen durchaus möglich ist), und die Verbindung zum lastbehafteten Webserver zur weniger belasteten Datenbank in der privaten DMZ über eine VPN-Verbindung, bzw. (bei MySQL/MariaDB möglich) einen "intern" verschlüsselten Zugang zu sichern. Die Datenhohheit verbleibt damit im eigenen Hause, vorausgesetzt natürlich, man reißt dort keine weiteren Lücken auf. ## [Ergänzung]: _Die API auf dem Webserver darf dann selstverständlich keinen Vollzugriff auf die Tabellen der Datenbank haben und die Geschäftsregeln (Zugriffskontrolle, Historeie) müssen in der Datenbank vereinbart werden._ Als DB-Server reicht hier meistens schon eine Raspberry-PI 4.0b. Dieses Verfahren hat bereits 2001 mit M$-Access-Datenbanken gut funktioniert. Inzwischen sind die Netze ungefähr 160 mal so schnell (im Upload des DSL-Anachlusses). Da sehe ich also für mäßig frequentierte Webseiten kein Nadelöhr. Du könntest auf diese Weise die Verschlüsselung in diejenige Schicht legen, in die sie ohnehin gehört! Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, verschlüsseln der Datenbank hat nur dann Sinn, wenn man die Datenbank vor dem Arbeiten damit wieder entschlüsseln kann. Es hat also meistens auch keinen Sinn, einzelne Spalten zu verschlüsseln, wenn man diese (datenbanintern) indizieren muss, um z. B. Relationen auflösen zu können. Es hat aber Sinn, eine solche Datenbank in einer privaten Umgebung zu hosten (was bei heutigen DSL-Anschlüssen durchaus möglich ist), und die Verbindung zum lastbehafteten Webserver zur weniger belasteten Datenbank in der privaten DMZ über eine VPN-Verbindung, bzw. (bei MySQL/MariaDB möglich) einen "intern" verschlüsselten Zugang zu sichern. Die Datenhohheit verbleibt damit im eigenen Hause, vorausgesetzt natürlich, man reißt dort keine weiteren Lücken auf. ## [Ergänzung]: _Die API auf dem Webserver darf dann selstverständlich keinen Vollzugriff auf die Tabellen der Datenbank haben und die Geschäftsregeln (Zugriffskontrolle, Hiostoreie) müssen in der Datenbank vereinbart werden._ Als DB-Server reicht hier meistens schon eine Raspberry-PI 4.0b. Dieses Verfahren hat bereits 2001 mit M$-Access-Datenbanken gut funktioniert. Inzwischen sind die Netze ungefähr 160 mal so schnell (im Upload des DSL-Anachlusses). Da sehe ich also für mäßig frequentierte Webseiten kein Nadelöhr. Du könntest auf diese Weise die Verschlüsselung in diejenige Schicht legen, in die sie ohnehin gehört! Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, verschlüsseln der Datenbank hat nur dann Sinn, wenn man die Datenbank vor dem Arbeiten damit wieder entschlüsseln kann. Es hat also meistens auch keinen Sinn, einzelne Spalten zu verschlüsseln, wenn man diese (datenbanintern) indizieren muss, um z. B. Relationen auflösen zu können. Es hat aber Sinn, eine solche Datenbank in einer privaten Umgebung zu hosten (was bei heutigen DSL-Anschlüssen durchaus möglich ist), und die Verbindung zum lastbehafteten Webserver zur weniger belasteten Datenbank in der privaten DMZ über eine VPN-Verbindung, bzw. (bei MySQL/MariaDB möglich) einen "intern" verschlüsselten Zugang zu sichern. Die Datenhohheit verbleibt damit im eigenen Hause, vorausgesetzt natürlich, man reißt dort keine weiteren Lücken auf. Als DB-Server reicht hier meistens schon eine Raspberry-PI 4.0b. Dieses Verfahren hat bereits 2001 mit M$-Access-Datenbanken gut funktioniert. Inzwischen sind die Netze ungefähr 160 mal so schnell (im Upload des DSL-Anachlusses). Da sehe ich also für mäßig frequentierte Webseiten kein Nadelöhr. Du könntest auf diese Weise die Verschlüsselung in diejenige Schicht legen, in die sie ohnehin gehört! Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, verschlüsseln der Datenbank hat nur dann Sinn, wenn man die Datenbank vor dem Arbeiten damit wieder entschlüsseln kann. Es hat also meistens auch keinen Sinn, einzelne Spalten zu verschlüsseln, wenn man diese (datenbanintern) indizieren muss, um z. B. Relationen auflösen zu können. Es hat aber Sinn, eine solche Datenbank in einer privaten Umgebung zu hosten (was bei heutigen DSL-Anschlüssen durchaus möglich ist), und die Verbindung zum lastbehafteten Webserver zur weniger belasteten Datenbank in der privaten DMZ über eine VPN-Verbindung, bzw. (bei MySQL/MariaDB möglich) einen "intern" verschlüsselten Zugang zu sichern. Die Datenhohheit verbleibt damit im eigenen Hause, vorausgesetzt natürlich, man reißt dort keine weiteren Lücken auf. Dieses Verfahren hat bereits 2001 mit M$-Access-Datenbanken gut funktioniert. Inzwischen sind die Netze ungefähr 160 mal so schnell (im Upload des DSL-Anachlusses). Da sehe ich also für mäßig frequentierte Webseiten kein Nadelöhr. Du könntest auf diese Weise die Verschlüsselung in diejenige Schicht legen, in die sie ohnehin gehört! Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, verschlüsseln der Datenbank hat nur dann Sinn, wenn man die Datenbank vor dem Arbeiten damit wieder entschlüsseln kann. Es hat also meistens auch keinen Sinn, einzelne Spalten zu verschlüsseln, wenn man diese (datenbanintern) indizieren muss, um z. B. Relationen auflösen zu können. Es hat aber Sinn, eine solche Datenbank in einer privaten Umgebung zu hosten (was bei heutigen DSL-Anschlüssen durchaus möglich ist) und die Verbindung zum lastbehafteten Webserver zur weniger belasteten Datenbank in der privaten DMZ über eine VPN-Verbindung, bzw. (bei MySQL/MariaDB möglich) einen "intern" verschlüsselten Zugang zu sichern. Die Datenhoheheit verbleibt damit im eigenen Hause, vorausgesetzt natürlich, man reißt dort keine weiteren Lücken auf. Dieses Verfahren hat bereits 2001 mit M$-Access-Datenbanken gut funktioniert. Inzwischen sind die Netze ungefähr 160 mal so schnell (im Upload des DSL-Anachlusses). Da sehe ich also für mäßig frequentierte Webseiten kein Nadelöhr. Du könntest auf diese Weise die Verschlüsselung in diejenige Schicht legen, in die sie ohnehin gehört! Glück Auf Tom vom Berg -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz