Datenbak in einer "black Box" betreiben

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ß
 
Oben