Intranetanwendung absichern Klient - Webserver - Datenbank
newsgro...@arcor.de
ich stehe vor der Aufgabe, eine Intranetanwendung absichern zu mï¿œssen.
Die Umgebung sieht wie folgt aus:
- Datenbank
- Apache-Webserver
- PHP
Die Verbindung Webbrowser - Webserver wird durch SSL abgesichert, die
Client-Authentifizierung erfolgt durch Zertifikat.
Nun zum Problem:
Der Administrator des Webservers darf nicht auf die Datenbank kommen und
der Administrator der Datenbank darf nicht auf die Daten zugreifen
kï¿œnnen. Dazu kann man die Daten auf der Datenbank verschlï¿œsseln. Dann
stellt sicher allerdings das Problem wie man den Schlï¿œssel vom Klienten
an beiden Administratoren auf die Datenbank bringt. Kurzum, ich mï¿œchte
Daten vom und zum Klienten bringen ohne dass unterwegs jemand mitliest.
Danke fï¿œr Tipps und Hinweise
Carsten Krueger
> Der Administrator des Webservers darf nicht auf die Datenbank kommen und
> der Administrator der Datenbank darf nicht auf die Daten zugreifen
> k�nnen.
Geht nicht.
> an beiden Administratoren auf die Datenbank bringt. Kurzum, ich m�chte
> Daten vom und zum Klienten bringen ohne dass unterwegs jemand mitliest.
Daten auf dem Client verschl�sseln und verschl�sselt in der DB ablegen.
Ein Browser ist dann allerdings ohne Addon ungeeignet, da ein Javaapplet
was das �bernehmen k�nnte auch vom Webserver ausgeliefert wird und daher
manipulierbar w�re.
Gru� Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Bernd Hohmann
> Der Administrator des Webservers darf nicht auf die Datenbank kommen und
> der Administrator der Datenbank darf nicht auf die Daten zugreifen
> können.
So eine Anforderung hab ich das letzte Mal bei Kiddies gehört denen man
einen V-Server für 5 EUR/Monat geschenkt hat und die damit die Homepage
eines WoW-Clans hochziehen wollen und sich nun um die Förmchenverteilung
streiten.
Sollte das eine ersthafte Anforderung eines Unternehmens sein und Du der
externe Dienstleister: ergreife die Flucht.
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
newsgro...@arcor.de
Jan Schejbal
> Der Administrator des Webservers darf nicht auf die Datenbank kommen
> und der Administrator der Datenbank darf nicht auf die Daten
> zugreifen
Der Admin der DB darf nicht an die Daten -> Entweder entsprechende
Zugriffsrechte/Vier-Augen-System oder die Daten vor der Ablage
verschlï¿œsseln (Hardwaresicherheitsmodul im Webserver?)
1. Der Admin des Webservers darf nicht an die DB.
2. Der Webserver darf an die DB.
3. Der Admin des Webservers soll den Webserver vollstï¿œndig verwalten.
Passt nicht. Eine der Sachen wirst du rauswerfen mï¿œssen. Entweder du
verbietest dem Webserver auf die DB zuzugreifen, oder du nimmst dem
Webserveradmin so viele Zugriffsrechte, dass er nicht mehr auf die DB
zugreifen kann, auch nicht indirekt indem er z. B. eine Anwendung
ï¿œndert, die auf die DB zugreifen soll. Beide Maï¿œnahmen dï¿œrften dem Sinn
des Webservers bzw. des Admins entgegenstehen.
Gruￜ
Jan
--
Bitte mï¿œglichst in die Newsgroup antworten.
Blog: http://janschejbal.wordpress.com/
Bei e-Mail-Antworten bitte im Betreff "FROM NG" verwenden,
sonst wird die Mail ungelesen gelï¿œscht! (Danke, Spammer!)
Arno Welzel
> ich stehe vor der Aufgabe, eine Intranetanwendung absichern zu mï¿œssen.
> Die Umgebung sieht wie folgt aus:
>
> - Datenbank
> - Apache-Webserver
> - PHP
>
> Die Verbindung Webbrowser - Webserver wird durch SSL abgesichert, die
> Client-Authentifizierung erfolgt durch Zertifikat.
>
> Nun zum Problem:
>
> Der Administrator des Webservers darf nicht auf die Datenbank kommen und
Das geht prinzipiell nicht, da er als Admin logischerweise an die
Anwendung kann, die auf dem Webserver lï¿œuft - und die muss ja wohl auch
an die DB kommen. Also kann auch der Web-Admin an die DB, da die
Anwendung irgendwie ja auch den Login zur Datenbank kennen muss - und
damit auch der Web-Admin.
> der Administrator der Datenbank darf nicht auf die Daten zugreifen
> kï¿œnnen. Dazu kann man die Daten auf der Datenbank verschlï¿œsseln. Dann
Und wie soll der DB-Admin dann seinen Job machen, wenn er nicht an die
Datenbank herandarf?
> stellt sicher allerdings das Problem wie man den Schlï¿œssel vom Klienten
> an beiden Administratoren auf die Datenbank bringt. Kurzum, ich mï¿œchte
> Daten vom und zum Klienten bringen ohne dass unterwegs jemand mitliest.
Tunnel via SSH, OpenVPN o.ￜ. vom Webserver zum DB-Server und darￜber die
DB-Verbindung aufbauen. Die anderen Anforderungen sind ziemlich unsinnig
- ein Admin fï¿œr irgendetwas muss nun mal ï¿œblicherweise auch Zugriff auf
das irgendetwas haben, dass er administrieren soll.
Carsten Krueger
> Was w�re das beispielsweise f�r ein Addon?
Google: Firefox Addon
newsgro...@arcor.de
* On 17.10.2009 01:16, Bernd Hohmann wrote:
> newsgro...@arcor.de schrieb:
>
>> Der Administrator des Webservers darf nicht auf die Datenbank kommen
>> und der Administrator der Datenbank darf nicht auf die Daten zugreifen
>> kï¿œnnen.
>
> So eine Anforderung hab ich das letzte Mal bei Kiddies gehï¿œrt denen man
> einen V-Server fï¿œr 5 EUR/Monat geschenkt hat und die damit die Homepage
> eines WoW-Clans hochziehen wollen und sich nun um die Fï¿œrmchenverteilung
newsgro...@arcor.de
[...]
>> der Administrator der Datenbank darf nicht auf die Daten zugreifen
>> kï¿œnnen. Dazu kann man die Daten auf der Datenbank verschlï¿œsseln. Dann
>
> Und wie soll der DB-Admin dann seinen Job machen, wenn er nicht an die
> Datenbank herandarf?
Ich sprach davon, dass der Admin nicht auf die Daten zugreifen kï¿œnnen
soll. Wenn beispielsweise ein Attribut verschlï¿œsselt ist, warum sollte
der Admin seine Arbeit nicht mehr machen kï¿œnnen - da fehlt mir der
Zusammenhang.
>> stellt sicher allerdings das Problem wie man den Schlï¿œssel vom
>> Klienten an beiden Administratoren auf die Datenbank bringt. Kurzum,
>> ich mï¿œchte Daten vom und zum Klienten bringen ohne dass unterwegs
>> jemand mitliest.
>
> Tunnel via SSH, OpenVPN o.ￜ. vom Webserver zum DB-Server und darￜber die
> DB-Verbindung aufbauen. Die anderen Anforderungen sind ziemlich unsinnig
> - ein Admin fï¿œr irgendetwas muss nun mal ï¿œblicherweise auch Zugriff auf
> das irgendetwas haben, dass er administrieren soll.
Manchmal will man eben selbst dem Admin nicht den Zugriff erlauben...
Helmut Hullen
Du meintest am 19.10.09:
> Was genau nochmal tr�gt dein Posting zur L�sung meines Problems bei?
Du scheinst die Prinzipien von Newsgroups noch nicht so recht zu kennen.
Erkennbar schon daran, dass Du mit einem kindischen Spitznamen
auftrittst. Das sichert Dir allemal Antworten, die Du nicht haben
willst.
Du kannst nat�rlich, wenn Dir die Antwort nicht passt, Dein Geld
zur�ckfordern.
Viele Gruesse!
Helmut
newsgro...@arcor.de
solche Nebens�chlichkeiten wie Realname und dieses ganze Bla, Bla.
Danach rufen immer die am lautesten, die technisch am wenigsten
beizutragen haben. Mir fehlt immer noch dein Input zum Thema...
Carsten Krueger
> Ich sprach davon, dass der Admin nicht auf die Daten zugreifen k�nnen
> soll. Wenn beispielsweise ein Attribut verschl�sselt ist, warum sollte
> der Admin seine Arbeit nicht mehr machen k�nnen - da fehlt mir der
> Zusammenhang.
Verschl�sseln ist ok, nicht zugreifen k�nnen nicht.
> Manchmal will man eben selbst dem Admin nicht den Zugriff erlauben...
Nein, dann will man 4-Augenprinzip, einen neuen Admin oder die Daten schon
verschl�sselt ablegen.
Carsten Krueger
> Was w�re das beispielsweise f�r ein Addon?
Google: Firefox Addon
Gru� Carsten
PS: Starke Crypto-Algorithmen die man in ein Addon einbauen k�nnte:
http://code.google.com/p/crypto-js/
PPS: Addons auf denen man aufbauen k�nnte:
https://addons.mozilla.org/de/firefox/search?q=aes&cat=1%2C12
foobar
Bernd Hohmann
> Was genau nochmal trägt dein Posting zur Lösung meines Problems bei?
Na da:
>> Sollte das eine ersthafte Anforderung eines Unternehmens sein und Du der
>> externe Dienstleister: ergreife die Flucht.
Denn: wäre die Idee auf Deinem Mist gewachsen, könntest Du das Szenario
so schildern, dass sich eine Lösung finden wird.
So aber hast Du eine Anforderung gestellt, die sich eher nach
"Pointy-Haired Boss" anhört und sofortigen Fluchtreflex auslöst.
Arno Welzel
> * On 18.10.2009 17:45, Arno Welzel wrote:
> [...]
>>> der Administrator der Datenbank darf nicht auf die Daten zugreifen
>>> kï¿œnnen. Dazu kann man die Daten auf der Datenbank verschlï¿œsseln. Dann
>>
>> Und wie soll der DB-Admin dann seinen Job machen, wenn er nicht an die
>> Datenbank herandarf?
>
> Ich sprach davon, dass der Admin nicht auf die Daten zugreifen kï¿œnnen
> soll. Wenn beispielsweise ein Attribut verschlï¿œsselt ist, warum sollte
> der Admin seine Arbeit nicht mehr machen kï¿œnnen - da fehlt mir der
> Zusammenhang.
ï¿œblicherweise muss der DB-Admin auch die Struktur der Datenbank
zumindest grob kennen, wenn es z.B. um die Beseitigung von
Performance-Problemen geht oder wenn beurteilt werden soll, wieviel
Speicherplatz die Datenbank braucht usw.
Daher beschrï¿œnkt man sich bei der Verschlï¿œsselung auch wirklich nur auf
einzelne Angaben, die generell *niemand* ausser den berechtigten
Benutzern kennen sollen - z.B. Passwï¿œrter, PINs etc.
Dass eine Datenbank *komplett* verschlï¿œsselt wird, so dass auch der
DB-Admin mit dem Inhalt nichts anfangen kann, ist absolut unï¿œblich, da
technisch extrem aufwendig - erst recht in PHP.
Konkretes Beispiel:
Man hat ein SQL-Statement, um Daten alphabetisch sortiert auszugeben:
select title, id from articles order by title
So - nun stelle man sich vor, die Daten im Feld "title" wï¿œren komplett
verschlï¿œsselt, damit auch der DB-Admin nicht sehen kann, was da im
Klartext enthalten ist.
Das Ergebnis wird nun eben nach dem verschlï¿œsselten Inhalt sortiert -
passt also gar nicht mehr. Zudem mï¿œsste die Anwendung *jeden* einzelnen
Datensatz wieder entschlï¿œsseln und das Ganze lokal im Speicher oder
temporï¿œr erzeugten Dateien sortieren, was die Leistung auch nicht gerade
verbessert. Zudem sollte die Verschlï¿œsselung schon einigermassen gut
sein und nicht nur ein bisschen ROT13 o.ￜ. - ob PHP das halbwegs schnell
hinbekommt mit einigen hundert oder tausend Eintrï¿œgen, wage ich zu
bewzeifeln.
Gerade deshalb gibt es fï¿œr die Datenbank Login und Passwort und nicht
jeder kann da einfach so reinlangen. Man kï¿œnnte den DB-Server auch
physisch so absichern, dass der DB-Admin nur in Anwesenheit einer
zweiten Person an das System kann.
Wenn es ein Problem ist, dass der Web-Admin zwangslï¿œufig auch Zugriff
auf die DB erlangen kann oder der DB-Admin Daten in der DB sehen kann,
muss man das halt organisatorisch regeln - das ist kein rein technisches
Problem. Irgendjemand hat immer Zugriff auf die Daten.
>>> stellt sicher allerdings das Problem wie man den Schlï¿œssel vom
>>> Klienten an beiden Administratoren auf die Datenbank bringt. Kurzum,
>>> ich mï¿œchte Daten vom und zum Klienten bringen ohne dass unterwegs
>>> jemand mitliest.
>>
>> Tunnel via SSH, OpenVPN o.ￜ. vom Webserver zum DB-Server und darￜber
>> die DB-Verbindung aufbauen. Die anderen Anforderungen sind ziemlich
>> unsinnig - ein Admin fï¿œr irgendetwas muss nun mal ï¿œblicherweise auch
>> Zugriff auf das irgendetwas haben, dass er administrieren soll.
>
> Manchmal will man eben selbst dem Admin nicht den Zugriff erlauben...
Dann macht ihr organisatorisch was falsch.
Bernd Hohmann
> Das Ergebnis wird nun eben nach dem verschlüsselten Inhalt sortiert -
> passt also gar nicht mehr.
Das ist nicht so sehr das Problem: es gibt Datenbanken, welche die Daten
verschlüsselt ablegen und als Indecies neutrale Sortierschlüssel verwenden.
Dekodierung geht dann anhand diverser Module, auch für PHP verwendbar.
Ist aber eher Militärware und zb. über Detica et al zu beziehen.
>> Manchmal will man eben selbst dem Admin nicht den Zugriff erlauben...
>
> Dann macht ihr organisatorisch was falsch.
Ich tippe mal auf die (Lohn)buchhaltung der Geschäftsleitung, damit
keiner sieht wie das Unternehmen ordnungsgemäss geplündert wird.