Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #246079 > unrolled thread

Bringt eine verschlüsselte Datenbank Sicherheit?

Back to article view | Back to ger.ct

Contents

  Bringt eine verschlüsselte Datenbank Sicherheit? Jörg Barres <news@traicon.net> - 2016-03-08 20:12 +0100
    Re: Bringt eine verschlüsselte Datenbank Sicherheit? Michael Bode <m.g.bode@web.de> - 2016-03-08 20:36 +0100
      Re: Bringt eine verschlüsselte Datenbank Sicherheit? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-08 20:49 +0100
        Re: Bringt eine verschlüsselte Datenbank Sicherheit? Michael Bode <m.g.bode@web.de> - 2016-03-08 20:58 +0100
          Re: Bringt eine verschlüsselte Datenbank Sicherheit? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-08 21:02 +0100
            Re: Bringt eine verschlüsselte Datenbank Sicherheit? Michael Bode <m.g.bode@web.de> - 2016-03-08 21:08 +0100
              Re: Bringt eine verschlüsselte Datenbank Sicherheit? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-08 21:13 +0100
                Re: Bringt eine verschlüsselte Datenbank Sicherheit? Michael Bode <m.g.bode@web.de> - 2016-03-08 21:27 +0100
                  Re: Bringt eine verschlüsselte Datenbank Sicherheit? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2016-03-08 22:33 +0100
                    Re: Bringt eine verschlüsselte Datenbank Sicherheit? Michael Bode <m.g.bode@web.de> - 2016-03-09 07:27 +0100
    Re: Bringt eine verschlüsselte Datenbank Sicherheit? Hendrik van der Heijden <hvdh@gmx.de> - 2016-03-08 21:19 +0100
      Re: Bringt eine verschlüsselte Datenbank Sicherheit? Jörg Barres <news@traicon.net> - 2016-03-09 09:25 +0100
        Re: Bringt eine verschlüsselte Datenbank Sicherheit? Hendrik van der Heijden <hvdh@gmx.de> - 2016-03-09 21:55 +0100
          Re: Bringt eine verschlüsselte Datenbank Sicherheit? Jörg Barres <news@traicon.net> - 2016-03-10 13:52 +0100

#246079 — Bringt eine verschlüsselte Datenbank Sicherheit?

Hallo liebe ger.ctler,

gerade überlege ich, wie löst man folgendes Szenario:

Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so, 
dass jeder angemeldete Benutzer Zugriff auf die Daten hat.

Ergo muss es ein "Master-Passwort" geben, das für die Verschlüsselung 
verwendet wird.

Woher kennt das System dieses Master-Passwort?

1. Von den Benutzern stehen nur die gehashten und gesalzenen Passwörter 
in der Datenbank, eine Ablage des Master-Passworts bei den 
Benutzerdaten, welches mit dem Benutzer-Passwort codiert ist, geht 
nicht, da das Benutzer-Passwort ja nie bis zum Sever kommt, immer nur 
der Hash davon.

2. Das Master-Passwort mit dem Benutzer-Passwort-Hash zu codieren 
erscheint mir nicht sinnvoll, dann steht ja der Schlüssel direkt neben 
dem Passwort, wenn auch schwer zu erkennen.

3. Das Master-Passwort auf dem Server in eine Textdatei zu legen, 
bringt's ja nun auch nicht so.

Bei Google find ich nichts dazu, wie wird das gelöst?

Schönen Abend euch,

Jörg

[toc] | [next] | [standalone]

#246084

Am 08.03.2016 um 20:12 schrieb Jörg Barres:
> Hallo liebe ger.ctler,
> 
> gerade überlege ich, wie löst man folgendes Szenario:
> 
> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so,
> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.

Am besten gar nicht.

https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7

[toc] | [prev] | [next] | [standalone]

#246085

On 03/08/2016 08:36 PM, Michael Bode wrote:
> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>> Hallo liebe ger.ctler,
>>
>> gerade überlege ich, wie löst man folgendes Szenario:
>>
>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so,
>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>
> Am besten gar nicht.
>
> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>

Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:

 
http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html

  Gerrit

[toc] | [prev] | [next] | [standalone]

#246087

Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
> On 03/08/2016 08:36 PM, Michael Bode wrote:
>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>> Hallo liebe ger.ctler,
>>>
>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>
>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so,
>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>
>> Am besten gar nicht.
>>
>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>
> 
> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
> 
> 
> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html

Aber wie steht da auch nicht.

[toc] | [prev] | [next] | [standalone]

#246088

On 03/08/2016 08:58 PM, Michael Bode wrote:
> Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
>> On 03/08/2016 08:36 PM, Michael Bode wrote:
>>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>>> Hallo liebe ger.ctler,
>>>>
>>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>>
>>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so,
>>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>>
>>> Am besten gar nicht.
>>>
>>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>>
>>
>> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
>>
>>
>> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html
>
> Aber wie steht da auch nicht.

Das will man als Hersteller ja auch nicht unbedingt verraten solange der 
Kunde mit der Performance zufrienden ist.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#246091

Am 08.03.2016 um 21:02 schrieb Gerrit Heitsch:
> On 03/08/2016 08:58 PM, Michael Bode wrote:
>> Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
>>> On 03/08/2016 08:36 PM, Michael Bode wrote:
>>>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>>>> Hallo liebe ger.ctler,
>>>>>
>>>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>>>
>>>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein,
>>>>> aber so,
>>>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>>>
>>>> Am besten gar nicht.
>>>>
>>>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>>>
>>>
>>> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
>>>
>>>
>>> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html
>>>
>>
>> Aber wie steht da auch nicht.
> 
> Das will man als Hersteller ja auch nicht unbedingt verraten solange der
> Kunde mit der Performance zufrienden ist.

Oder wenn die Lösung halt an anderer Stelle teuer wird. Beim RAM z.B.

[toc] | [prev] | [next] | [standalone]

#246092

On 03/08/2016 09:08 PM, Michael Bode wrote:
> Am 08.03.2016 um 21:02 schrieb Gerrit Heitsch:
>> On 03/08/2016 08:58 PM, Michael Bode wrote:
>>> Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
>>>> On 03/08/2016 08:36 PM, Michael Bode wrote:
>>>>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>>>>> Hallo liebe ger.ctler,
>>>>>>
>>>>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>>>>
>>>>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein,
>>>>>> aber so,
>>>>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>>>>
>>>>> Am besten gar nicht.
>>>>>
>>>>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>>>>
>>>>
>>>> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
>>>>
>>>>
>>>> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html
>>>>
>>>
>>> Aber wie steht da auch nicht.
>>
>> Das will man als Hersteller ja auch nicht unbedingt verraten solange der
>> Kunde mit der Performance zufrienden ist.
>
> Oder wenn die Lösung halt an anderer Stelle teuer wird. Beim RAM z.B.

RAM ist billig, man bietet ja schon Lösungen an, die die komplette DB im 
RAM halten. Datenbankserver bei denen das RAM in TB gemessen wird sind 
soo selten nicht.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#246094

Am 08.03.2016 um 21:13 schrieb Gerrit Heitsch:
> On 03/08/2016 09:08 PM, Michael Bode wrote:
>> Am 08.03.2016 um 21:02 schrieb Gerrit Heitsch:
>>> On 03/08/2016 08:58 PM, Michael Bode wrote:
>>>> Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
>>>>> On 03/08/2016 08:36 PM, Michael Bode wrote:
>>>>>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>>>>>> Hallo liebe ger.ctler,
>>>>>>>
>>>>>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>>>>>
>>>>>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein,
>>>>>>> aber so,
>>>>>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>>>>>
>>>>>> Am besten gar nicht.
>>>>>>
>>>>>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>>>>>
>>>>>
>>>>> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
>>>>>
>>>>>
>>>>> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html
>>>>>
>>>>>
>>>>
>>>> Aber wie steht da auch nicht.
>>>
>>> Das will man als Hersteller ja auch nicht unbedingt verraten solange der
>>> Kunde mit der Performance zufrienden ist.
>>
>> Oder wenn die Lösung halt an anderer Stelle teuer wird. Beim RAM z.B.
> 
> RAM ist billig, man bietet ja schon Lösungen an, die die komplette DB im
> RAM halten. Datenbankserver bei denen das RAM in TB gemessen wird sind
> soo selten nicht.

Genau an sowas hatte ich gedacht. Wenn man die ganze DB im RAM hält,
kann man die Files auf der Platte leicht verschlüsseln.

[toc] | [prev] | [next] | [standalone]

#246102

On 03/08/2016 09:27 PM, Michael Bode wrote:
> Am 08.03.2016 um 21:13 schrieb Gerrit Heitsch:
>> On 03/08/2016 09:08 PM, Michael Bode wrote:
>>> Am 08.03.2016 um 21:02 schrieb Gerrit Heitsch:
>>>> On 03/08/2016 08:58 PM, Michael Bode wrote:
>>>>> Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
>>>>>> On 03/08/2016 08:36 PM, Michael Bode wrote:
>>>>>>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>>>>>>> Hallo liebe ger.ctler,
>>>>>>>>
>>>>>>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>>>>>>
>>>>>>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein,
>>>>>>>> aber so,
>>>>>>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>>>>>>
>>>>>>> Am besten gar nicht.
>>>>>>>
>>>>>>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>>>>>>
>>>>>>
>>>>>> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
>>>>>>
>>>>>>
>>>>>> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html
>>>>>>
>>>>>>
>>>>>
>>>>> Aber wie steht da auch nicht.
>>>>
>>>> Das will man als Hersteller ja auch nicht unbedingt verraten solange der
>>>> Kunde mit der Performance zufrienden ist.
>>>
>>> Oder wenn die Lösung halt an anderer Stelle teuer wird. Beim RAM z.B.
>>
>> RAM ist billig, man bietet ja schon Lösungen an, die die komplette DB im
>> RAM halten. Datenbankserver bei denen das RAM in TB gemessen wird sind
>> soo selten nicht.
>
> Genau an sowas hatte ich gedacht. Wenn man die ganze DB im RAM hält,
> kann man die Files auf der Platte leicht verschlüsseln.

Man kann die Dateien auf der HD immer verschlüsseln und beim Zugriff die 
Daten on the fly entschlüsseln. Aktuelle CPUs erledigen AES in Hardware, 
das bremst nicht mehr nennenswert.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#246111

Am 08.03.2016 um 22:33 schrieb Gerrit Heitsch:
> On 03/08/2016 09:27 PM, Michael Bode wrote:
>> Am 08.03.2016 um 21:13 schrieb Gerrit Heitsch:
>>> On 03/08/2016 09:08 PM, Michael Bode wrote:
>>>> Am 08.03.2016 um 21:02 schrieb Gerrit Heitsch:
>>>>> On 03/08/2016 08:58 PM, Michael Bode wrote:
>>>>>> Am 08.03.2016 um 20:49 schrieb Gerrit Heitsch:
>>>>>>> On 03/08/2016 08:36 PM, Michael Bode wrote:
>>>>>>>> Am 08.03.2016 um 20:12 schrieb Jörg Barres:
>>>>>>>>> Hallo liebe ger.ctler,
>>>>>>>>>
>>>>>>>>> gerade überlege ich, wie löst man folgendes Szenario:
>>>>>>>>>
>>>>>>>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein,
>>>>>>>>> aber so,
>>>>>>>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>>>>>>>
>>>>>>>> Am besten gar nicht.
>>>>>>>>
>>>>>>>> https://plus.google.com/+KristianKöhntopp/posts/75uf2HS5fz7
>>>>>>>>
>>>>>>>
>>>>>>> Es gibt Hersteller, die behaupten, das Problem gelöst zu haben:
>>>>>>>
>>>>>>>
>>>>>>> http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Aber wie steht da auch nicht.
>>>>>
>>>>> Das will man als Hersteller ja auch nicht unbedingt verraten
>>>>> solange der
>>>>> Kunde mit der Performance zufrienden ist.
>>>>
>>>> Oder wenn die Lösung halt an anderer Stelle teuer wird. Beim RAM z.B.
>>>
>>> RAM ist billig, man bietet ja schon Lösungen an, die die komplette DB im
>>> RAM halten. Datenbankserver bei denen das RAM in TB gemessen wird sind
>>> soo selten nicht.
>>
>> Genau an sowas hatte ich gedacht. Wenn man die ganze DB im RAM hält,
>> kann man die Files auf der Platte leicht verschlüsseln.
> 
> Man kann die Dateien auf der HD immer verschlüsseln und beim Zugriff die
> Daten on the fly entschlüsseln. Aktuelle CPUs erledigen AES in Hardware,
> das bremst nicht mehr nennenswert.

Dann hat man ein Cryptodateisystem für eine Datei.

[toc] | [prev] | [next] | [standalone]

#246093

Am 08.03.2016 um 20:12 schrieb Jörg Barres:
> Hallo liebe ger.ctler,
> 
> gerade überlege ich, wie löst man folgendes Szenario:
> 
> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so, 
> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.

Der Benutzer hat Zugriff auf verschlüsselte oder entschlüsselte Daten?
Wer soll dabei keinen Zugriff auf unverschlüsselte Daten haben?


Hendrik

[toc] | [prev] | [next] | [standalone]

#246126

Am 08.03.2016 um 21:19 schrieb Hendrik van der Heijden:
>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so,
>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>
> Der Benutzer hat Zugriff auf verschlüsselte oder entschlüsselte Daten?
> Wer soll dabei keinen Zugriff auf unverschlüsselte Daten haben?

Die Benutzer müssen Zugriff auf den (verschlüsselten) Datenbestand haben.
Hintergrund der DB-Verschlüsselung ist der Gedanke, dass jemand die 
Datenbank "klaut", sich also auf den Server hackt und die DB runterzieht.

Deshalb ja auch meine Frage, wie oder wo sich ein Masterpasswort ablegen 
lässt, irgendwo auf dem Server muss das sein, aber wenn der Server 
gehackt wird, bringt's das ja nicht.

Jörg

[toc] | [prev] | [next] | [standalone]

#246268

Am 09.03.2016 um 09:25 schrieb Jörg Barres:
> Am 08.03.2016 um 21:19 schrieb Hendrik van der Heijden:
>>> Die Inhalte einer Datenbank sollen verschlüsselt abgelegt sein, aber so,
>>> dass jeder angemeldete Benutzer Zugriff auf die Daten hat.
>>
>> Der Benutzer hat Zugriff auf verschlüsselte oder entschlüsselte Daten?
>> Wer soll dabei keinen Zugriff auf unverschlüsselte Daten haben?
> 
> Die Benutzer müssen Zugriff auf den (verschlüsselten) Datenbestand haben.
> Hintergrund der DB-Verschlüsselung ist der Gedanke, dass jemand die 
> Datenbank "klaut", sich also auf den Server hackt und die DB runterzieht.

Und wo wird jetzt entschlüsselt und wo soll der Schlüssel herkommen?
Wenn die Entschlüsselung auf dem selben Server passieren soll, kannst
du hier aufgeben.
Wenn der Hacker auf den Server kommt und genug Rechte hat, um die DB-
Datei zu lesen, dann kann er wohl auch den Serverprozess dumpen und
kommt damit an Schüssel und entschlüsselte Daten.


Hendrik

[toc] | [prev] | [next] | [standalone]

#246395

Am 09.03.2016 um 21:55 schrieb Hendrik van der Heijden:
> Und wo wird jetzt entschlüsselt und wo soll der Schlüssel herkommen?
> Wenn die Entschlüsselung auf dem selben Server passieren soll, kannst
> du hier aufgeben.
> Wenn der Hacker auf den Server kommt und genug Rechte hat, um die DB-
> Datei zu lesen, dann kann er wohl auch den Serverprozess dumpen und
> kommt damit an Schüssel und entschlüsselte Daten.

Stimmt, das ist so ein typisches Henne-Ei-Problem.

Da alle Verbindungen über SSL laufen, hat sich mein Kunde jetzt für die 
Variante entschieden, bei der die Daten in der DB verschlüsselt werden 
und das Anmeldepasswort des Benutzers im Klartext an den Server 
geschickt wird.

Nicht perfekt, sicher besser, als das Passwort auf dem Server liegen zu 
haben.

So müsste jemand schon den Traffic kapern, und dazu müsste dann ja ein 
fake-Server aufgesetzt werden und beim Kunden das DNS umgebogen werden.

Jörg

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web