![[HaBo]](/styles/default/logoklein.png)
Ein freundliches Gutes Morgen in die Runde,
Ich hoffe ich bin hier im Berecih des Forums richtig aufgehoben. ?
Ich würde gerne einmal mit euch eine Theorie durchgehen und Machbarkeiten, Möglichkeiten und Prinzipien reintheoretisch abklopfen. Vielleicht gibt es auch schon komplette Lösungen oder Ansätze die an mir vorbeigeflogen sind!? Letztendlich geht es mir aber um das Verständnis und um den theoretischen Ansatz.
In wie weit ist es machbar eine Datenbank in einer Art „black box“ zu integrieren und zu betreiben?
Das Ziel ist es ein Datenbanksystem zu etablieren, welches sensible Daten (public, private) verschlüsselt ablegt, verwaltet oder auch zur Anzeige bringt. Teile aus der Datenbank, sprich Spalten aus einer Tabelle oder auch ganze Tabelle sind in verschlüsselter Form abzulegen, so dass selbst die Administration nicht an diese gelangen kann und ausschließlich Support an dem DB-System durchführen kann. Auch die Entwickler der Applikation (welche die Daten zur Anzeige bringt und den Zugriff auf die DB steuert) dürfen in der Produktionsumgebung nicht an die verschlüsselten Daten kommen. Sprich, ein einfaches „echo“ oder ein Abfangen des Request-Objektes sollte das Passwort oder andere sensible Informationen (UID) im Klartext nicht preisgeben. Auch dürfen die Entwickler und Administratoren das Passwort zur Verschlüsselung nicht besitzen.
Beispiel:
Nutzer 1, gilt als Master und besitzt keine Einschränkungen. Nutzer 1 vergibt Freigaben, Passwörter und besitzt alleine das „SuperMasterPasswort“.
Nutzer 2 und 3 haben eine Projektfunktion und ausschließlich Zugriff auf Daten, die ihre Abteilung betrifft und übergreifend auch auf ein oder zwei Tabellen/ Spalten von Nutzer 1. Das „SuperMasterPasswort“ kann nach dem 4-Augenprinzip, durch die jeweiligen UID‘s von Nutzer 2 und Nutzer 3 reproduziert werden. Als ganz einfaches Beispiel hierzu „SUID = sha1(concat(UID1, UID2))“.
Nutzer 4 und 5 haben ausschließlich Zugriff auf „public“ Bereich der Datenbank und können Daten nur lesend sichten.
Zum Einsatz kommt Server1, ein Webserver (PHP7, MariaDB), welcher einen Service via REST bereitstellt. Server1 dient ausschließlich für die Authentifizierung und Kommunikation vom Client zur Datenbank (Server2).
Damit z.B. fünf Nutzer (jeder Nutzer hat unterschiedliche Privilegien) mit dem System arbeiten können, wird ein Nutzer/Rollen/Rechte-Konzept geplant und implementiert.
Jeder Nutzer der Zugriff auf sensible Daten hat, bekommt einen eigenen, privaten Schlüssel (char48), sowie einen öffentlichen bekannten Schlüssel. Bei einer Authentifizierung wird das übermittelte Passwort vom Nutzer in der DB via sha1(concat(„mein geheimes Passwort“, [salt])); gegengeprüft. Das Passwort steht also nicht im Klartext in der DB!
Id | name | pw | salt |
| Nutzername | jkh87979as7df87s7d…|ksjdhkhfksjdhfkjhsdkj…|
Des Weiteren benötigt der Nutzer für einen schreibenden Zugriff auf das System einen geheimen Schlüssel, welchen nur er selber und das System kennen. Über diesen Schlüssel wird das Request-Objekt verschlüsselt und als HASH im Header abgelegt. Der Server kann nun diesen Hash selber generieren und gegen den übermittelten Hash abgleichen und somit eine zusätzliche Sicherheit bieten.
Die zu verschlüsselnden Daten, welche in der Datenbank nicht lesbar sein dürfen sind mit der Systemfunktion AES_ENCRYPT verschlüsselt. Der Schlüssel für das AES_DECRYPT ist in einer eigenen „krypth_tabelle“ abgelegt und nur in Verbindung mit der eigenen UID zu entschlüsseln.
z.B.
SELECT * from krypth_tabelle where AES_DECRYPT( [COL1], AES_DECRYPT( [COL2], UID)) like‘%mein Suchmuster%‘;
Somit wird das einmalig zu vergebene Passwort, welches ich für die AES_ENCRYPT Funktion benötige, in Verbindung mit der UID in der „krypth_tabelle“ mehrfach hinterlegt, auch wenn es für jeden Nutzer letztendlich das gleiche sein könnte.
Vergeben wird das Passwort durch den Master. Zugriffsberechtigungen, welche die Nutzer auf die Datenbanken haben, werden durch den Master in Verbindung einer Matrix-Tabelle (anonymisiert - wie auch immer) selbst vergeben und zugewiesen. Über diese Tabelle kann Nutzer 1, dem Nutzer4 oder auch Nutzer 5, Zugriffe auf sensible Spalten/ Tabellen gewähren.
Ich bin mir bewusst das es noch viele Lücken existieren über die „Angreifer“ an die Daten gelangen können und es somit keine 100% Lösung gibt. Ich möchte den Ansatz aber abklopfen und gedanklich versuchen das maximale herauszuholen.
Was interpretiere ich falsch, bzw. welche Schrauben könne besser justiert werden. Gibt es gänzlich andere Ideen oder erweiterte Ansätze zu meinem Beispiel? Auch finde ich meinen Ansatz insoweit nicht ausreichend, da die (UIS, SUID) immer in Klartext mitgesendet wird, bzw. leicht abzugreifen ist. Auch ist der Aufwand für eine, ich nenne es mal Passwort vergessen Funktion, für die UID o. ä. etwas schwer umzusetzen.
Gruß
Ich hoffe ich bin hier im Berecih des Forums richtig aufgehoben. ?
Ich würde gerne einmal mit euch eine Theorie durchgehen und Machbarkeiten, Möglichkeiten und Prinzipien reintheoretisch abklopfen. Vielleicht gibt es auch schon komplette Lösungen oder Ansätze die an mir vorbeigeflogen sind!? Letztendlich geht es mir aber um das Verständnis und um den theoretischen Ansatz.
In wie weit ist es machbar eine Datenbank in einer Art „black box“ zu integrieren und zu betreiben?
Das Ziel ist es ein Datenbanksystem zu etablieren, welches sensible Daten (public, private) verschlüsselt ablegt, verwaltet oder auch zur Anzeige bringt. Teile aus der Datenbank, sprich Spalten aus einer Tabelle oder auch ganze Tabelle sind in verschlüsselter Form abzulegen, so dass selbst die Administration nicht an diese gelangen kann und ausschließlich Support an dem DB-System durchführen kann. Auch die Entwickler der Applikation (welche die Daten zur Anzeige bringt und den Zugriff auf die DB steuert) dürfen in der Produktionsumgebung nicht an die verschlüsselten Daten kommen. Sprich, ein einfaches „echo“ oder ein Abfangen des Request-Objektes sollte das Passwort oder andere sensible Informationen (UID) im Klartext nicht preisgeben. Auch dürfen die Entwickler und Administratoren das Passwort zur Verschlüsselung nicht besitzen.
Beispiel:
Nutzer 1, gilt als Master und besitzt keine Einschränkungen. Nutzer 1 vergibt Freigaben, Passwörter und besitzt alleine das „SuperMasterPasswort“.
Nutzer 2 und 3 haben eine Projektfunktion und ausschließlich Zugriff auf Daten, die ihre Abteilung betrifft und übergreifend auch auf ein oder zwei Tabellen/ Spalten von Nutzer 1. Das „SuperMasterPasswort“ kann nach dem 4-Augenprinzip, durch die jeweiligen UID‘s von Nutzer 2 und Nutzer 3 reproduziert werden. Als ganz einfaches Beispiel hierzu „SUID = sha1(concat(UID1, UID2))“.
Nutzer 4 und 5 haben ausschließlich Zugriff auf „public“ Bereich der Datenbank und können Daten nur lesend sichten.
Zum Einsatz kommt Server1, ein Webserver (PHP7, MariaDB), welcher einen Service via REST bereitstellt. Server1 dient ausschließlich für die Authentifizierung und Kommunikation vom Client zur Datenbank (Server2).
Damit z.B. fünf Nutzer (jeder Nutzer hat unterschiedliche Privilegien) mit dem System arbeiten können, wird ein Nutzer/Rollen/Rechte-Konzept geplant und implementiert.
Jeder Nutzer der Zugriff auf sensible Daten hat, bekommt einen eigenen, privaten Schlüssel (char48), sowie einen öffentlichen bekannten Schlüssel. Bei einer Authentifizierung wird das übermittelte Passwort vom Nutzer in der DB via sha1(concat(„mein geheimes Passwort“, [salt])); gegengeprüft. Das Passwort steht also nicht im Klartext in der DB!
Id | name | pw | salt |
| Nutzername | jkh87979as7df87s7d…|ksjdhkhfksjdhfkjhsdkj…|
Des Weiteren benötigt der Nutzer für einen schreibenden Zugriff auf das System einen geheimen Schlüssel, welchen nur er selber und das System kennen. Über diesen Schlüssel wird das Request-Objekt verschlüsselt und als HASH im Header abgelegt. Der Server kann nun diesen Hash selber generieren und gegen den übermittelten Hash abgleichen und somit eine zusätzliche Sicherheit bieten.
Die zu verschlüsselnden Daten, welche in der Datenbank nicht lesbar sein dürfen sind mit der Systemfunktion AES_ENCRYPT verschlüsselt. Der Schlüssel für das AES_DECRYPT ist in einer eigenen „krypth_tabelle“ abgelegt und nur in Verbindung mit der eigenen UID zu entschlüsseln.
z.B.
SELECT * from krypth_tabelle where AES_DECRYPT( [COL1], AES_DECRYPT( [COL2], UID)) like‘%mein Suchmuster%‘;
Somit wird das einmalig zu vergebene Passwort, welches ich für die AES_ENCRYPT Funktion benötige, in Verbindung mit der UID in der „krypth_tabelle“ mehrfach hinterlegt, auch wenn es für jeden Nutzer letztendlich das gleiche sein könnte.
Vergeben wird das Passwort durch den Master. Zugriffsberechtigungen, welche die Nutzer auf die Datenbanken haben, werden durch den Master in Verbindung einer Matrix-Tabelle (anonymisiert - wie auch immer) selbst vergeben und zugewiesen. Über diese Tabelle kann Nutzer 1, dem Nutzer4 oder auch Nutzer 5, Zugriffe auf sensible Spalten/ Tabellen gewähren.
Ich bin mir bewusst das es noch viele Lücken existieren über die „Angreifer“ an die Daten gelangen können und es somit keine 100% Lösung gibt. Ich möchte den Ansatz aber abklopfen und gedanklich versuchen das maximale herauszuholen.
Was interpretiere ich falsch, bzw. welche Schrauben könne besser justiert werden. Gibt es gänzlich andere Ideen oder erweiterte Ansätze zu meinem Beispiel? Auch finde ich meinen Ansatz insoweit nicht ausreichend, da die (UIS, SUID) immer in Klartext mitgesendet wird, bzw. leicht abzugreifen ist. Auch ist der Aufwand für eine, ich nenne es mal Passwort vergessen Funktion, für die UID o. ä. etwas schwer umzusetzen.
Gruß
