Client-VPN als Einsatz bei Datenbanken in der Cloud

Eine nicht ganz schöne aber dennoch praktikable Lösung, wenn man die API-Schicht auf dem Internetserver (noch)nicht machen will: Einen SSH-Tunnel. Man muss aber dafür sorgen, dass der Tunnel immer aufgebaut bleibt – dazu über einen Interceptor prüfen und eventuell Tunnel wieder aufbauen. Das ist eine Möglichkeit. Man könnte den Tunnel auch außerhalb der Anwendung systemweit erstellen, prüfen muss man die Verbindung trotzdem.

Eine andere Möglichkeit ist die Nutzung von VPN.

Aber wie meine Vorredner bereits schrieben, die sauberste Lösung ist eine API-Schicht auf dem Internetserver.

LG

René

Ein VPN wäre nichts anderes als ein Verschleiern der Verbindung selbst. Das löst also nicht das Grundproblem des gemeinsamen Zugriffs von individuellen Benutzern auf Daten.

Sofern es sich hier um GDPR-relevante Daten handelt (und davon ist auszugehen, wenn mehrere Benutzer an einem System arbeiten) wäre das eine gesetzliche Verletzung. Kann man klein reden - bleibt eine Verletzung.

Daher nein: in 99,99% der Fälle löst hier ein VPN natürlich gar nichts.

Wie soll eine sichere und verschlüsselte VPN-Verbindung (z. B. mit durch Passphrasen geschützten SSL/TLS-Zertifikaten) gegen die EU-DSGVO verstoßen?

Im Übrigen die Lösung mit SSH sollte ebenfalls zertifikatsbasierend sein.

Es kommt schon vor, dass man eine zweischichtige Datenbankanwendung ins Internet bringen muss (zumindest die Datenbank) und da hat man den Salat: Es vergeht u. U. viel Zeit, bis die API-Schicht implementiert wurde. Hier können SSH und VPN Zeit verschaffen.

Wenn du bisher nur mit der DB auf dem gleichern Server gearbeitet hast, dann ist jetzt Zeitpunkt auf eine Api umzulernen.
Gute Ansätze dafür gibt es z.B. mit Microsofts Web Api mit Json als Format.
Entsprechende Anleitungen und Lernbeispiele gibt es auch in der Doku von Microsoft.

Doku:
https://learn.microsoft.com/de-de/aspnet/core/fundamentals/apis?view=aspnetcore-7.0
https://learn.microsoft.com/de-de/aspnet/core/tutorials/first-web-api?view=aspnetcore-7.0&tabs=visual-studio

Nachtrag:

@pollito
Den VPN Ansatz würde ich schon aus Kontrollgründen nie verwenden.
Wenn jemand Zugriff auf das VPN bekommt, was schon durch einen Rechner eine Benutzer passieren kann, dann wäre der Datenabfluss nicht kontrollierbar.
Da man dann durch das VPN in falscher Sicherheit gewiegt ist, macht sich kaum einer die Mühe mehr als Benutzer/Passwort zur DB zu konfigurieren.
Durch eine Api, ist der Zugang zur Datenbank sauber gesichert.
VPN zur DB ist also kein Ersatz für eine Api!

T-Virus

Zitat von pollito

Wie soll eine sichere und verschlüsselte VPN-Verbindung (z. B. mit durch Passphrasen geschützten SSL/TLS-Zertifikaten) gegen die EU-DSGVO verstoßen?

Keine Ahnung, was Du durchgelesen hast - aber offenbar nicht meine Antwort. Dort steht nirgends, dass der VPN gegen irgendwas verstoßen würde. Da steht, dass er Dir in der Situation absolut gar nichts bringt.

Meine Aussage ist:

Das löst also nicht das Grundproblem des gemeinsamen Zugriffs von individuellen Benutzern auf Daten.

Sofern es sich hier um GDPR-relevante Daten handelt (und davon ist auszugehen, wenn mehrere Benutzer an einem System arbeiten) wäre das eine gesetzliche Verletzung. Kann man klein reden - bleibt eine Verletzung.

Daher nein: in 99,99% der Fälle löst hier ein VPN natürlich gar nichts.

Also egal ob mit oder ohne VPN: Du löst das Grundproblem nicht, bleibt es in 99,99% der Fälle (der Daten-Art) ein GDPR-Problem.
Daher greift man mit Client-Anwendungen niemals direkt auf eine Datenbank zu - auch nicht mit einem VPN.

Ganz davon zu schweigen, dass man bei allen Cloudanbietern nicht direkt mit einem VPN auf eine Datenbank zugreifen kann, sondern dafür zusätzliche Infrastruktur in der Cloud benötigt. Macht also so oder so keinen Sinn.

In meinem ersten Posting:

Aber wie meine Vorredner bereits schrieben, die sauberste Lösung ist eine API-Schicht auf dem Internetserver.

Im zweiten:

Es kommt schon vor, dass man eine zweischichtige Datenbankanwendung ins Internet bringen muss (zumindest die Datenbank) und da hat man den Salat: Es vergeht u. U. viel Zeit, bis die API-Schicht implementiert wurde. Hier können SSH und VPN Zeit verschaffen.

Ich selbst habe dafür nie VPN verwendet, in einigen Projekten aber die SSH-Lösung genau aus dem Grund, den der vorige Anschnitt anreißt.

Ein 30 Jahre altes Projekt kann man nicht eben auf der linken Arschbacke von zwei auf drei Schichten bringen. So kann man sich u. U. Luft verschaffen, Kunde bringt Verständnis dafür und bleibt an der Angel und man selbst muss nicht in Schönheit sterben.

Ein 30 Jahre altes Projekt kann man nicht eben auf der linken Arschbacke von zwei auf drei Schichten bringen. So kann man sich u. U. Luft verschaffen, Kunde bringt Verständnis dafür und bleibt an der Angel und man selbst muss nicht in Schönheit sterben.

Es ist dem Gesetzgeber völlig egal, was Du für ein Projekt hast und wie alt das Projekt ist. Du musst Dich darum kümmern, dass die Regeln eingehalten werden - auch als Entwickler ist das Deine Aufgabe. Ja, das bedeutet manchmal, dass Software neu gebaut werden muss. Aber die Regeln existieren nicht zum Spaß oder um Dich zu ärgern.
Das als "Schönheit" und nicht als Notwendigkeit zu verstehen grenzt an Fahrlässigkeit. Aber leider ein Grund, wieso so viele Firmen immer mehr Probleme mit GDPR Beschwerden und/oder Datenleaks haben.. gut dass die Strafen mittlerweile sehr weh tun.
Und für solche Dinge gibt der Gesetzgeber sogar vergleichsweise viel Zeit, um sich um bestehende Dinge zu kümmern.

Natürlich kannst Du sagen "mir egal" - aber das sagt dann auch sehr viel über die Organisation aus.

Ob Du dem Kunden nun sagst "Hey, mit dem VPN ist das nun viel sicherer" und Dir damit Luft verschaffst, weil Du vielleicht verpennt hast das Frühzeitig anzupassen/Dich darum zu kümmern - das ist dann eine individuelle Sache von Dir. Aber sowas sollte man nicht empfehlen, weil das ganz weit weg von der Realität ist - und dem Gesetzgeber ebenfalls egal ist.

Und nochmal: das funktioniert sowieso nicht ohne zusätzliche Infrastruktur in der Cloud. Also sowieso Käse in diesem Fall.

Wer schwätzt noch über VPN? Sage mir, wer verbietet mir eine SSH-Lösung? Quellenangabe?

Es ist echt schade und Zeitverschwendung, wenn Du bereits vorhandene Antworten nicht liest oder nicht lesen willst.
Gerne kopiere ich es Dir erneut.

Das löst also nicht das Grundproblem des gemeinsamen Zugriffs von individuellen Benutzern auf Daten.

Und das gibt der Gesetzgeber vor? Ich habe von meiner Erfahrung mit SSH geschrieben. Bei den Anwendungen, um es dabei ging, hatte ich das Problem des gemeinsamen Zugriffs grundätzlich nicht. Dem Originalposter habe ich nur mögliche Interimslösungen aufgezeigt – mehr aber nicht. Seine Software und Möglichkeiten kennen ich nicht – er wird aber wohl abwägen können, was für ihn der geeignete Weg ist.

Der OP hat mit keinem einzigen Wort über das grundsätzliche Problem des gleichzeitigen Zugriffs geschrieben – sehr möglich, dass er dieses Problem hat. Bleibt dennoch eine Vermutung und das muss er lösen.

Da es bei dem Thema um eine Umstellung von lokaler APF Anwendung zu Cloud DB geht, muss man davon ausgehen, dass es hier einen Mehrbenutzerzugriff gibt.
Ich bezweifle, dass er für jede Installation eine eigene Datenbank einrichten wird/will.
Auch wird es nicht pro Gerät einen Benutzer geben.
Die Verwaltung + Kosten dürfte dann bei vielen Benutzern Kostenrahmen sprengen.
Entsprechend ergibt sich schon aus dem urspünglichen Vorhaben der Mehrbenutzer Zugriff.

Ansonsten hattest du übrigens selbst VPN in den Ring geworfen.
Das du dann keine zwei Antworten noch die Frage stellst, wer davon redet, ist auch eine wundersame Art das Thema zu leiten.

Der Lösungsansatz sowohl mit VPN sowie SSH führt aber zu dem gleichen Problemen, wie ich es oben schon angemerkt habe.
Auch dort kannst du den Datenabfluss überhaupt nicht kontrollieren.
Sobald jemand den Rechner karpert, kannst du genau 0 gegen einen Datenabfluss machen.
Da sich in dieser Situation auch noch alle den gleichen Zugang teilen müssten, wäre unmöglich irgendwas sinnvolles zu protokollieren.
Du lieferst also ohne eine Api vor der DAtenbank die DAten in jeder Form den Leuten mit Zugriff aus.

Eine Api bringt dann auch weitere Vorteile, die dir der rohe DB Zugriff nicht bieten kann.
Z.B. kann man in einer Api noch zusätzliche Authetifizierung sowie Authorisierung umsetzen.
Gerade Authorisierung kann u.U. durch eine Lizenzmodell bestimmte Zugriffe blockieren, was mit direkten Zugriff nicht möglich ist.
Ebenfalls sind Caching, Logging und weitere Möglichkeiten erst mit einer Api sauber machbar.

T-Virus

Und das gibt der Gesetzgeber vor?

Bin etwas erstaunt, dass Du das in Deiner Position nicht weißt....

Der Gesetzgeber hat im Sinne von GDPR bestimmt, dass das Rechtsprinzip umgekehrt ist. Das heisst, das Gesetz regelt nicht, was Du nicht darfst, sondern das Gesetz regelt, was Du darfst und musst. 
Daher ist die Frage "Sage mir, wer verbietet mir eine SSH-Lösung?" auch nicht abgedeckt und beantwortet Dir niemand. Du solltest Dich eher fragen: "Wie hilft mir SSH, dass ich gesetzkonform agiere?"

Das hat der Gesetzgeber so umgesetzt, dass Gesetzeslücken zB durch technologische Weiterentwicklung nicht entstehen. Aber auch so Betreiber dazu zwingt, dass alte Software angepasst, oder sogar in vielen Fällen ersetzt werden müssen, wenn diese nicht nach den Spielregeln spielen, zB weil sie schon 30 Jahre alt sind.

Der Gesetzgeber schreibt vor, wie Du mit GDPR-relevante Daten umgehen musst; teilweise explizit und teilweise implizit.

Handelt es sich um GDPR-Daten musst Du zB dafür sorgen, dass der Zugriff so umgesetzt wird, dass nur die Daten verwendbar sind, die für den eigentlichen Zweck benötigt werden. Das bedeutet implizit, dass Du eine Benutzerzugriffsverwaltung brauchst, sodass nicht jeder Benutzer auf alle Daten Zugriff hat. Man muss also i.d.R. einen Service vor die Datenbank schalten, um Datenabstrahierung und eine eine Autorisierung umsetzen zu können - ansonsten erfüllst Du die Vorgaben nicht; völlig egal ob Du SSH/VPN im Einsatz hast oder nicht.

Dieses Rechtsprinzip hat auf viele Dinge implizite Auswirkungen; auch wenn Du Daten hast, die gar nicht unter GDPR fallen. So helfen die Cloudanbieter, dass gewisse Umsetzungsfehler vermieden werden, weil sie zB per default dass Datenbanken nicht im Internet hängen und Du so potentiell eine Sicherheitslücke hast. Auch ist es technisch nicht bei den Cloudanbietern möglich, direkt per VPN/SSH auf Deine Datenbank zuzugreifen - weil man das sowieso nicht tun soll.

Du kommst also implizit fast gar nicht drum herum einen entsprechenden Service in der Cloud zu betreiben, um a) rechtskonform mit Daten umzugehen und b) damit die Datenhaltung und Verwendung in der Cloud so nutzbar ist, wie sie die Anbieter designed haben.
Die Cloudanbietern helfen also durch die möglichen Verwendungsarten und -vorgaben, dass Du "Dirty Zeug" umsetzt, was Du vielleicht On Prem als "Normal" empfindest - aber halt nich so cool is...

Und darum gehts hier in dem Thread. Dem Ersteller aufzeigen, wieso das in der Cloud so ist und wieso er das in der Cloud so machen muss - und warum sein aktuelles Vorhaben mit der Direktverbindung zur Datenbank nicht so eine gute Idee ist.

Dem Originalposter habe ich nur mögliche Interimslösungen aufgezeigt – mehr aber nicht.

Die ganze Diskussion VPN/SSH ist völlig irrelevant: a) eben völlig wurst für Deine Pflichten zu GDPR und b) funktionier es technisch nicht mal in der Cloud, ohne dass Du zusätzliche (teure) Infrastruktur brauchst. Deine mögliche Interimslösung ist also völlig an der Frage, am Ziel vorbei und hilft ihm 0,0 bei seinem Vorhaben.

Zitat von T-Virus

Ansonsten hattest du übrigens selbst VPN in den Ring geworfen.

Lediglich erwähnt.

Der Ansatz mit SSH führt zu keinem Datenabfluss, wenn er richtig gemacht wird, auch dann nicht, wenn der Rechner gekapert wird. In die Anwendung integriert, SSH nur mit durch Passphrasen gesicherten Zertifikaten, alle Zugangsdaten und Zertifikate verschlüsselt und serverseitig Zugriff von nur erlaubten IP-Adressen. Die Lösung ist auch von einem IT sachkundigen Datenschutzbeauftragten abgenommen worden und damit für mich der Käs' gegessen.

Nochmals: Es hängt von der Anwendung ab und ich weiß nicht, ob die Software vom OP eine Benutzer- und Mehrzugriffsverwaltung hat. Ich musste die Datenbank einer sehr großen 30-Jahre alten mehrbenutzerfähigen zweischichtigen Anwendung (Client + SQL) möglichst sicher ins Internet bringen, damit die Anwender von überall auf der Welt die Clientanwendung nutzen können. Das war billiger als z. B. RDS. Somit gewann man Zeit, um die Anwendung dreischichtig zu gestalten. Und mehr habe ich auch nicht behauptet.

Die Lösung ist auch von einem IT sachkundigen Datenschutzbeauftragten abgenommen

Das allein sagt gar nichts aus.

Dein SSH sorgt nur für eine sichere(re) Verbindung - nicht mehr, nicht weniger. Dann wurde halt die Verbindung abgenommen, und?
Das hat noch lang nichts mit dem Verwalten der Daten selbst zutun. Vielleicht war das bei Dir schon okay - das geht hier nicht heraus.

Aber nochmal: darum gehts auch hier in dem Thread nicht.
Dein "Vorschlag" oder nun "Erwähnung" genannt hilft 0,0 und hat mit der Fragestellung exakt nichts zutun.

und damit für mich der Käs' gegessen.

puh...

@Abt

Deine Probleme hätte ich gerne. Wo gibt das Gras zum kaufen? 😃

Sorry, aber jetzt wird es nur noch langweilig! Neben meinem Ingenieurstudium und anderen Qualifikationen bin ich seit 2018 Datenschutzbeauftragter. Meine Lösung (siehe vorigen Post von mir) ist datenschutzrechtlich in Ordnung und abgenommen (nicht von mir, ich darf das in diesem Fall nicht).

Zitat von pollito

bin ich seit 2018 Datenschutzbeauftragter.

Es wäre schön, wenn man das an Deinen Beiträgen herauslesen könnte und so auch ein Mehrwert für potentielle Leser entstehen würde.
Ansonsten Danke ich für den Rest Deines Beitrags, der die restlichen Antworten nochmals inhaltlich unterstreicht 😃