Wie Speicher ich den Schlüssel für verschlüsselte Datenbanken oder Dateien

[QuickAndDirty]

Hallo , das ist keine ausschließliche Firebird-Frage, sondern ehere eine Datenbank und Dateien Frage.

Wenn mein Dienst auf verschlüsselte Daten/Dateien CRUD-operationen ausübt, muss er die ja auch Entschlüsseln/Verschlüsseln können.
Also muss der Dienst den Schlüssel kennen.
Ein Passswort verschlüsselter Key mit Passwortabfrage bei Dienststart geht leider nicht, weil der Dienst nach einem Rechner Neustart laufen muss ohne Menschliches zutun.

Also muss der Symetrische schlüssel Irgendwo gespeichert werden oder?
Aber wo?
Am besten als verteilter schlüssel, falls der Rechner/die VM mal wegkommt?
Wer hat sowas schonmal gemacht? Gibts fertige Lösungen dafür in Delphi?

[Klaus01]

.. den symetrischen Schlüssel asymetrisch verschlüsseln.

Den sym. Schlüssel mit dem priv. Key verschlüsseln.
Der Dienst kann diesen Schlüssel dann mit dem public Key lesen.

Grüße
Klaus

[QuickAndDirty]

Zitat:

Zitat von Klaus01 (Beitrag 1526253)

.. den symetrischen Schlüssel asymetrisch verschlüsseln.

Den sym. Schlüssel mit dem priv. Key verschlüsseln.
Der Dienst kann diesen Schlüssel dann mit dem public Key lesen.

Grüße
Klaus

Und der Public key ist dann wo gespeichert?
Dann kann doch jeder den symetrischen Schlüssel mit dem public Key lesen oder?
Oder ist das einfach nur als zusätzliche Maßnahme gedacht?

Beispielsweise:
\\Rechner1\unverdächtigesverzeichnis1\K1.txt
XOR
\\Rechner2\unverdächtigesverzeichnis2\K2.txt
XOR
\\Rechner3\unverdächtigesverzeichnis3\K3.txt
DECRYPT VIA
c:\unverdächtigesverzeichnis\PUBLIC_KEY.PEM
= Symetrischer Schlüssel für Datenbank

????

[Klaus01]

vielleicht wird es hier deutlicher.

Grüße
Klaus

[jaenicke]

Da keine zusätzliche Information eingegeben werden kann, muss zum Lesen des Schlüssels logischerweise alles direkt zur Verfügung stehen. Daraus folgt auch, dass jemand mit dem entsprechenden Aufwand auch immer an diese Informationen herankommen kann. Man kann den Zugang lediglich erschweren. An der Stelle ist security by obscurity einmal tatsächlich sinnvoll, aber wie immer kein Schutz, sondern nur eine Verzögerung.

Für wirklich sensible Daten ist dies allerdings nicht geeignet. Da braucht man immer eine zusätzliche Informationsquelle, sei es z.B. eine Passworteingabe oder ein Hardwaredongle (der natürlich nicht einfach stecken bleiben darf), oder einen Zugangsschutz zum System, z.B. ein gesichertes Rechenzentrum.

[QuickAndDirty]

Zitat:

Zitat von Klaus01 (Beitrag 1526257)

vielleicht wird es hier deutlicher.

Grüße
Klaus

Ich weiß wie PKI und Verschlüsselung funktioniert.

Ich habe ein anderes Problem. Es geht darum Daten auf einem kompromitierten system zu schützen.
Wenn du den Rechner oder die VM mit nimmst sollst du nicht die Datenbank auslesen können.
Wenn du ein unglücklicher MA bist mit Zugang zum Server, sollst du die Daten nicht (einfach) veröffentlichen können.

Oder übersehe ich da etwas? Misverstehe ich dich?

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1526258)

Da keine zusätzliche Information eingegeben werden kann, muss zum Lesen des Schlüssels logischerweise alles direkt zur Verfügung stehen. Daraus folgt auch, dass jemand mit dem entsprechenden Aufwand auch immer an diese Informationen herankommen kann. Man kann den Zugang lediglich erschweren. An der Stelle ist security by obscurity einmal tatsächlich sinnvoll, aber wie immer kein Schutz, sondern nur eine Verzögerung.

Für wirklich sensible Daten ist dies allerdings nicht geeignet. Da braucht man immer eine zusätzliche Informationsquelle, sei es z.B. eine Passworteingabe oder ein Hardwaredongle (der natürlich nicht einfach stecken bleiben darf), oder einen Zugangsschutz zum System, z.B. ein gesichertes Rechenzentrum.

Das habe ich befürchtet. Keine Hoffnung auf magische Sicherheit...

Ich habe über folgendes nachgedacht:
1.Wenn der Vertrauenswürdige da ist , dann ist eine Eingabe eines Geheimnisses notwendig, beim Start des Dienstes.
2.Wenn der Vertrauenswürdige im Urlaub ist, fragt der Dienst einen microservice der bei dem Vertrauenswürdigen gehostet, ist nach dem Geheimnis.
So hätte man eine art Urlaubsmodus mit herabgesetzter Sicherheit....aber was soll man machen?

[johndoe049]

Zitat:

Zitat von QuickAndDirty (Beitrag 1526261)

Zitat:

Zitat von jaenicke (Beitrag 1526258)

Da keine zusätzliche Information eingegeben werden kann, muss zum Lesen des Schlüssels logischerweise alles direkt zur Verfügung stehen. Daraus folgt auch, dass jemand mit dem entsprechenden Aufwand auch immer an diese Informationen herankommen kann. Man kann den Zugang lediglich erschweren. An der Stelle ist security by obscurity einmal tatsächlich sinnvoll, aber wie immer kein Schutz, sondern nur eine Verzögerung.

Für wirklich sensible Daten ist dies allerdings nicht geeignet. Da braucht man immer eine zusätzliche Informationsquelle, sei es z.B. eine Passworteingabe oder ein Hardwaredongle (der natürlich nicht einfach stecken bleiben darf), oder einen Zugangsschutz zum System, z.B. ein gesichertes Rechenzentrum.

Das habe ich befürchtet. Keine Hoffnung auf magische Sicherheit...

Ich habe über folgendes nachgedacht:
1.Wenn der Vertrauenswürdige da ist , dann ist eine Eingabe eines Geheimnisses notwendig, beim Start des Dienstes.
2.Wenn der Vertrauenswürdige im Urlaub ist, fragt der Dienst einen microservice der bei dem Vertrauenswürdigen gehostet, ist nach dem Geheimnis.
So hätte man eine art Urlaubsmodus mit fast gleicher Sicherheit.

Evtl. kann man den Urlaubsmodus zum standard zu erheben?

Zitat:

Ich habe ein anderes Problem. Es geht darum Daten auf einem kompromitierten system zu schützen.
Wenn du den Rechner oder die VM mit nimmst sollst du nicht die Datenbank auslesen können.
Wenn du ein unglücklicher MA bist mit Zugang zum Server, sollst du die Daten nicht (einfach) veröffentlichen können.

Wenn man mit solchem Umfeld zu arbeiten hat, gilt eine einfache Regelung: Niemand ist vertrauenswürdig. Auch nicht der Programmierer, der das zu programmieren hat und die Möglichkeit hat, eine entsprechende Hintertür zu programmieren. In dem Fall sollten das mindestens 2 Programmierer erstellen, die sich gegenseitig überwachen.


Mögliche Lösung:
USB Stick mit dem Passwort an einem USB to Ethernet Router irgendwo in einem Schrank einschließen. Firewall so einstellen, dass die IP nur hausintern geroutet wird. Ist der Server/die VM im Büro ist der Kontakt möglich, ansonsten nicht.


Ansonsten gilt das von jaenicke. Immer da, wo der menschliche Faktor ausgeschaltet/umgangen wird, muss man Sicherheitseinschränkungen akzeptieren. Alles automatisch und absolut sicher geht in der Werbung oder im Film, aber nicht in der Realität. Auch nicht mit KI.

[jaenicke]

Nichtsdestotrotz hat man bei einem Dienst natürlich zumindest die Möglichkeit, dass man zum Zugriff hohe Rechte benötigt. Dann kommt zumindest kein einfacher Benutzer einfach so an die Daten heran.

[QuickAndDirty]

Wenn es wenigstens keine VM wäre dann hätte man bei einem geteilten Schlüssel einen Teil aus dem Hardwareprofil nehmen können. Das wäre nicht gleich ein offensichtlicher Speicherort...leider ist es ne VM...
und da bekommt man höchstens unterschiedliche prozessornamen....
Andererseits habe ich diese Lösung(https://theroadtodelphi.com/2010/12/...i-and-the-wmi/) noch nie ausprobiert.

Der Vertrauenswürdige könnte sich im Urlaub auch von nem Rubber-Ducky vertreten lassen...
Gut aber dann kann man auch gleich auf eine richtige Dongel Lösung setzen.