Hello, wie Dedlfix schon schrieb, gibt es für die Verschlüsselung von Datenbanken im Betrieb (noch) kein schlüssiges Konzept. Man sollte die Datenbank und ihre Zugriffsmodule nebst Geschäftsregeln daher immer in einem sicheren Bereich hosten und kapseln. Den Übertragungsweg zur Frontend-API sollte man hingegen mit Transportsicherung verschlüsseln. Alle Statements für Datenabfrage und -veränderung sollten ausschließlich im sichern Bereich erstellt und gespeichert werden (SQL-Injection verhindern). Diese kann man dann durch Datenbank-Benutzerfunktionen zur Verfügung stellen, die nur noch wenige Parameter übernehmen können und keine funktionelle Veränderung der Statements mehr zulassen. Diese Funktionen kann man nach DDS, DMS, DSS (Data Definition, Data Manipulation, Data Selection) für unterschiedliche User mit abgestuften Rechten zugänglich machen, sodaß eine einfache Abfrageseite niemals Datenveränderungen in Auftrag geben kann. Die Frontend-API sollte keinen direkten Zugriff mehr auf die Tabellen bekommen. Wenn Du dieses Schema einhältst, hast Du nach dem Stand der Technik alles z. Zt. mögliche für die Sicherheit getan. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, wie Dedlfix schon schrieb, gibt es für die Verschlüsselung von Datenbanken im Betrieb (noch) kein schlüssiges Konzept. Man sollte die Datenbank und ihre Zugriffsmodule nebst Geschäftsregeln daher immer in einem sicheren Bereich hosten und kapseln. Den Übertragungsweg zur Frontend-API sollte man hingegen mit Transportsicherung verschlüsseln. Alle Statements für Datenabfrage und -veränderung sollten ausschließlich im sichern Bereich erstellt und gespeichert werden (SQL-Injection verhindern). Diese kann man dann durch Datenbank-Benutzerfunktionen zur Verfügung stellen, die nur noch wenige Parameter übernehmen können und keine funktionelle Veränderung der Statements mehr zulassen. Diese Funktionen kann man nach DDS, DMS, DSS (Data Definition, Data Manipulation, Data Selection) für unterschiedliche User zugänglich machen, sodaß eine einfache Abfrageseite niemals Datenveränderungen in Auftrag geben kann. Die Frontend-API sollte keinen direkten Zugriff mehr auf die Tabellen bekommen. Wenn Du dieses Schema einhältst, hast Du nach dem Stand der Technik alles z. Zt. mögliche für die Sicherheit getan. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, wie Dedlfix schon schrieb, gibt es für die Verschlüsselung von Datenbanken im Betrieb (noch) kein schlüssiges Konzept. Man sollte die Datenbank und ihre Zugriffsmodule nebst Geschäftsregeln daher immer in einem sicheren Bereich hosten und kapseln. Den Übertragungsweg zur Frontend-API sollte man hingegen mit Transportsicherung verschlüsseln. Alle Statements für Datenabfrage und -veränderung sollten ausschließlich im sichern Bereich erstellt und gespeichert werden (SQL-Injection verhindern). Diese kann man dann durch Benutzerfunktionen zur Verfügung stellen, die nur noch wenige Parameter übernehmen können und keine funktionelle Veränderung der Statements mehr zulassen. Diese Funktionen kann man nach DDS, DMS, DSS (Data Definition, Data Manipulation, Data Selection) für unterschiedliche User zugänglich machen, sodaß eine einfache Abfrageseite niemals Datenveränderungen in Auftrag geben kann. Die Frontend-API sollte keinen direkten Zugriff mehr auf die Tabellen bekommen. Wenn Du dieses Schema einhältst, hast Du nach dem Stand der Technik alles z. Zt. mögliche für die Sicherheit getan. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, wie Dedlfix schon schrieb, gibt es für die Verschlüsselung von Datenbanken im Betrieb (noch) kein schlüssiges Konzept. Man sollte die Datenbank und ihre Zugriffsmodule nebst Geschäftsregeln daher immer in einem sicheren Bereich hosten und kapseln. Den Übertragungsweg zur Frontend-API sollte man hingegen mit Transportsicherung verschlüsseln. Alle Statements für Datenabfrage und -veränderung sollten ausschließlich im sichern Bereich erstellt und gespeichert werden. Diese kann man dann durch Benutzerfunktionen zur Verfügung stellen, die nur noch wenige Parameter übernehmen können und keine funktionelle Veränderung der Statements mehr zulassen. Diese Funktionen kann man nach DDS, DMS, DSS (Data Definition, Data Manipulation, Data Selection) für unterschiedliche User zugänglich machen, sodaß eine einfache Abfrageseite niemals Datenveränderungen in Auftrag geben kann. Die Frontend-API sollte keinen direkten Zugriff mehr auf die Tabellen bekommen. Wenn Du dieses Schema einhältst, hast Du nach dem Stand der Technik alles z. Zt. mögliche für die Sicherheit getan. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.

Hello, wie Dedlfix schon schrieb, gibt es für die Verschlüsselung von Datenbanken im Betrieb (noch) kein schlüssiges Konzept. Man sollte die Datenbank und ihre Zugriffsmodule nebst Geschäftsregeln daher immer in einem sicheren Bereich hosten jnd kapseln. Den Übertragungsweg zud Frontend-API sollte man hingegen mig Transportsicherung verschlüsseln. Alle Statements für Datenabfrage und -veränderung sollten ausschließlich im sichern Bereich erstellt und gespeichert werden. Diese kann man dann durch Benutzerfunktionen zur Verfügung stellen, die nur noch wenige Parameter übernehmen können und keine funktionelle Veränderung des Statements mehr zulassen. Die Frontend-API sollte keinen direkten Zugriff mehr auf die Tabellen bekommen. Wenn Du dieses Schema einhältst, hast Du nach dem Stand der Technik alles z. Zt. mögliche für die Sicherheit getan. Glück Auf Tom vom Berg -- Es gibt nichts Gutes, außer man tut es! Das Leben selbst ist der Sinn.