chewi schrieb:

Desweitern würde mich interessieren welche Datenbank am besten für kleine Webanwendungen sind

Das hängt von mehreren Faktoren ab. Definiere mal Webanwendung, sag uns auch mal auf welchen Betriebssystem das laufen soll, mit so wenigen Angaben kann man keine brauchbaren Hinweise geben. Datenbanken tu ich jedenfalls nicht verschlüsseln, kann aber vorkommen, das ich verschlüsselte Daten darin ablege. Passwörter kommen als Hash in die DB. Wie viele User zeitgleich die DB nutzen wäre auch gut zu wissen. Wenn du dein Vorhaben nicht ganz genau beschreibst, wird es schwer zu helfen.

Moinsen,

der SQL-Server bietet in den aktuellen Versionen die Verschlüsselung der Datenbanken an.

Aber: Verschlüsselte Daten wieder herstellen (z. B. nach einem Plattencrash) ist schwierig bis unmöglich.

Die Frage ist, welche Möglichkeiten man haben möchte, wenn die Datenbank mal nicht mehr funzt. Da wäre meine dringende Empfehlung, die Sicherungen nicht zu verschlüsseln. Ebenso sollte man die Daten auch in einem gut lesbaren Format als zusätzliche Sicherung vorhalten.

So, und erst dann kommt die DSGVO.

Kurz gesagt: Es kommt auf die Umstände, die Datenart und die notwendige Schutzstufe an. Aber aus Sicht der Datensicherheit (nicht im Sinne der DSGVO) würde ich auf die Verschlüsselung der Datenbank an sich verzichten. Ob man den Inhalt einzelner Datenfelder extern verschlüsselt (oder verschlüsseln muß) steht auf einem anderen Blatt.

Viele Grüße

Gerrit

Wenn du dazu verlässliche Aussagen haben willst, dann solltest du einen spezialisierten Anwalt befragen.

Zudem darfst du natürlich gerne Mal schreiben wo genau du was gelesen hast.

Moinsen!

Noch eine Sache, die ich vergessen habe zu erwähnen: Die beste Verschlüsselung der Daten nutzt nix, wenn der unberechtigte Zugriff über Sicherheitslücken in der Webanwendung oder anderen Zugriffsebenen erfolgt, die von der DB die unverschlüsselten Dateen zur Verfügung gestellt bekommen.

Viele Grüße

Gerrit

chewi schrieb:

ich weiß nur bei Login-Daten wirklich verschlüsselt

Das ist nicht ganz richtig, Passwörter werden als Hash abgelegt, ein Hash ist nicht umkehrbar(außer durch BruteForce oder evtl. auch RainbowTables).

SQLite(nur einem L), wäre eine Option, aber recht eingeschränkt, da SQLite kein Rechtesystem beinhaltet. Da du sagtest es sei klug den Zugriff auf gewisse Daten einzuschränken kann das problematisch werden, hängt aber davon ab wie du den Zugriff realisierst, also selbst eine Art Zugriffrechte-System in deine App einbaust. Da du aber noch neu in dieser Materie zu sein scheinst, würde ich dann eher zu einer SQL Datenbank raten. Das Risiko das du was fehlerhaft machst ist erhöht, weil du noch keine Erfahrung hast.

Gegen SQL-Injections absichern ist nie falsch. Gibt aber auch Treiber die das schon machen, z.B. bei PHP, PDO mit "Prepared Statements". Sowas könnte es auch für SQL unter Windows geben, da musst du denn mal Informationen sammeln. Für Web setze ich nur Linux ein, daher kann ich dazu nicht viel sagen.

Moinsen,

beim Webzugriff würde ich von SQLite, Access etc. absehen, da diese nicht oder nur eingeschränkt mehrere Abfragen parallel verarbeiten können.

Ich persönlich bevorzuge den MS-SQLserver (die Kostnix-Version scheint für Deine Zwecke ausreichend).

Allerdings würde ich dazu raten, diesen nicht direkt dem Webinterface zugänglich zu machen sondern einen selbstgeschriebenen Proxy - nein, das ist dann kein Webinterface auf einem IIS oder Indianer sondern ein natives TCP-Protokoll oder, wenn es Http sein soll, ein selbstgeschriebener HTTP-Server mit eigenen HTTP-Klassen - dazwischen zu schalten, insbesondere, wenn die Komponenten über mehrere Rechner verteilt sind (z. B. Webinterface im Rechenzentrum, DB-Maschine im Betrieb). Der Proxy kann dann auch gleich die Geschäftslogik mit abarbeiten.

Außerdem gehört die Verwaltung der Zugriffsrechte mMn. der Benutzer eher in die Geschäftslogik. Die würde ich selbst implementieren und dazu nicht den SQL-Server nehmen.

Viele Grüße

Gerrit

Bitte keinen selbstgeschriebenen HTTP-Server oder komisch gestricktes Zeug.

Was richtig ist, die Webanwendung hat niemals direkten Zugriff auf die Datenbank. Dazwischen gehört eine (Rest-) API die die Anfragen bearbeitet und die DB anspricht.
Schau mal nach JWT für die Berechtigungen.

Was denkst du denn was du für welchen Personenkreis speichern musst, wenn du denkst du musst auch die Daten verschlüsseln?

Moinsen,

MrTrebron schrieb:

Bitte keinen selbstgeschriebenen HTTP-Server oder komisch gestricktes Zeug.

Na, das sehe ich aber deutlich anders. Egal ob Indianer, IIS, oder andere: Die Dinger sind so komplex geworden, daß man da nur allzu leicht was in der Konfiguration übersehen kann. Wenn dann noch PHP, WordPress etc. pp. mitwerkeln wirds noch unübersichtlicher. Und auch die entsprechenden NET-Klassen nutzen im Hintergrund entsprechende Funktionen.

Da sieht das bei einem ganz schlanken HTTP-Server aber deutluch besser aus. Klar, HTTP-Parsen kann auch komplex werden, wenn man's selber macht, aber für den Anwendungszweck muß man ja nicht alles unterstützen.

Viele Grüße

Gerrit

Sorry, not sorry @Gerrit so an Scharrn. Du schmeißt da gerade ganz viel Zeug zusammen und rätst dann noch zum Frickeln.

Niemand hat Wordpress gesagt (volles CMS) oder PHP (was man als Backend gerne hernehmen kann wenn man PHP mag).
SQLite oder Access könnten sogar mit entsprechendem Serverdienst, bedingt, Multiuser fähig sein. Können halt bloß nicht mehrere Threads gleichzeitig auf die DB zugreifen.

Und wenn die grundlegenden Einstellungen von Apache, nginx, IIS oder ähnliches schon zuviel sind, dann bitte nichts veröffentlichen.

Da, außer Webanwendung und Datenbank, nicht viel bekannt ist, kann man mit Abstrakt beraten.

Also der Dreiklang im Frontend mit HTML/CSS/Javascript. Vielleicht sogar ohne Framework weil nur kleine Überprüfungen und das Ansprechen der API.
Im Backend eine API. Ich bevorzuge REST, aber wer lieber SOAP mag soll damit glücklich werden. Hier geht viel. Express.js, C#, PHP und und und.
Zur Authentifizierung bieten sich JWT an, es sei denn es läuft alles intern mit (Azure-)AD und man kann auf Single Sign On mit Windows setzen.
Datenbank ist dann wieder Geschmackssache aber auch die Art der Daten können den Ausschlag für oder gegen ein bestimmtes System geben. SQLite, MySQL oder MS-SQL ist nicht für jede Struktur. Ebenso wenig wie NoSQL Datenbanken wie Mongo sind kein Allheilmittel.

Mit PostgreSQL stellt auf jeden Fall auch einen Verschlüsselung auf Datensatzebene zur Verfügung.
Access ist eigentlich kein solides Datenbank-Backend.