Re: [A2open-diskussion] (no subject)

[Gottwalt T. <got...@ma...>]

Am 13.06.2006 um 22:37 schrieb Guido Seifert:

>> Hier m?sste also ein entspr. Frontend her, da? die Validierung der
>> Zul?ssigkeit und auch die Protokollierung des Zugriffs der Clients
>> ?bernimmt. Dies h?tte auch den Vorteil, da? sich kein manipulierter
>> Client auf Daten zugreifen k?nnte, die ihn nichts angehen.
>
> Ich frage mich, ob das nicht etwas Overkill ist. Ich dachte eher,  
> dass wir ja ohnehin einen
> Zentralserver fuer das zentrale DB-System haben. Die Datenbank dort  
> braeuchte nur eine
> zusaetzliche Tabelle mit Schluesseln. Wenn sich ein Client mit dem  
> Server verbindet, wird geguckt,
> ob ein Schluesselmedium mit gueltigem Schluessel vorhanden ist.  
> Minimal Code neue Schluessel zum
> Server hinzuzufuegen, alte zu entfernen.

Hier hat Burkhardt eigentlich recht: Wenn schon, dann muss dieser  
Schritt _vor_ dem eigentlichen Zugriff erfolgen. Ansonsten laesst  
sich ggf. durch die reale, ja nicht immer voellig fehlerfreie  
Implementierung so eines Mechanismus derselbige aushebeln...

> Kuriere, zwei zusaetzliche Server, die entsprechend redundant  
> ausgelegt sein muessen,
> Backup-Konzepte fuer mehr als den DB-Server. Landen wir da nicht  
> wieder in Preisregionen, die das
> ganze problematisch werden lassen? Bitte bedenke, dass Gottwalt  
> fuer die lokale Server-Loesung ca.
> 350000 Euro abgeschaetzt hat.

Das war _minimal_.
Ein Zertifizierungsmechanismus koennte meiner Vorstellung nach wie  
folgt aussehen:
Client meldet sich beim Login-Server. Der ueberprueft das Zertifikat  
und uebergibt den Connect an den Datenbankserver mit entsprechender  
Anweisung ("darf sich einloggen, ist Schluessel Nr. sowieso, hat  
entsprechende Zugriffsrechte"). Wenn tatsaechlich eine iSeries oder  
zSeries dahintersteht, dann ist das hardware- und softwareseitig  
kostenlos mitgeliefert. Da waere lediglich die reale Implementierung  
zu loesen.

> Wo landen wir mit einem LDAP-Server +
> Zertifizierungsserver ausreichender Groesse + zusaetzlicher Wartung

Siehe oben.

>> Dies k?nnte z.B. so aussehen:
>> 1. Client verbindet sich mit dem Frontend
>>     -> Pr?fung des Zertifikats durch den SSL-Server
>> 2. Das Frontend holt sich anhand der Seriennummer des Zertifikats
>> die UID um auf die Datenbank zuzugreifen - Anhand der UID k?nnte
>> auch die Schreibberechtigung und der Umfang der Leseberechtigung
>> gew?hrt werden.
>
> Ich hatte auch schon eine Idee, das ganze sicherer zu machen, indem  
> ein Schluessel aus einem
> Sachbearbeiterschluessel + einem Rechnerschluessel besteht. Wenn  
> z.B. ein Schluesselmedium geklaut
> wird, kann man damit nichts anfangen, weil nur bestimmte,  
> registrierte Rechner sich verbinden
> duerfen. Aber da bin ich wohl auch ueber das Ziel hinnausgeschossen.

Und dies ausschliesslich wegen des Verwaltungsaufwandes.

> Jetzt gibt es gar keine
> Authentifizierung. Die Verantwortlichen sind also zufrieden damit.  
> Sie sind sicherlich zu
> ueberzeugen, dass sie Geld fuer den DB-Server ausgeben muessen.  
> Machen sie ja auch jetzt
> schon. Dessen Notwendigkeit ist offensichtlich. Aber Geld (viel  
> Geld) ausgeben, um
> die Privatsphaeren von ein paar Arbeitslosen zu schuetzen? Nur mit  
> sehr viel oeffentlichen Druck,
> der gleichzeitig so viel Widerstand gegen unser Projekt erzeugen  
> wuerde, dass niemand sich es auch
> nur ansehen wird.  Wir sollten versuchen es besser zu machen als  
> jetzt, aber nicht unbedingt nach
> Perfektion streben. Ich denke, dass der Zugriffsvorschlag von  
> Gottwalt auch sehr viel einfacher,
> wenn auch nicht perfekt, mit etwas Code in den einzelnen Clients  
> und dem Backend, oder dem
> DB-Frontend realisiert werden kann.

Ja. Man kann das Zugriffs-System der DB durchaus zweischrittig  
realisieren, das ist auf keinen Fall verkehrt. Und eine grosse  
iSeries oder zSeries hat genuegend io-Kapazitaet, um da den  
Zwischenschritt "Authentizierung" als isolierte Instanz handhaben zu  
koennen, und ein Zertifikats-Server (ebenfalls als Datenbank) kann  
auch noch "nebenher" isoliert mitlaufen. Auch bei max. 200000 Connects.
Im Hinterkopf behalten koennen wir ausserdem: Wir brauchen keine 24/7- 
Redundanz. Wartungsarbeiten, Updates etc. koennen nachts und am  
Wochenende geschehen. Und wenn das Backend fuer drei Stunden vom Netz  
muss waehrend normaler Bureauzeit, so bedeutet dies nur  
eingeschraenkte Nutzbarkeit, nicht Totalausfall.

Also, Vorschlag: Connect erfolgt zum Login-Server ueber SSL- 
Verbindung. Der fragt die Gueltigkeit des Zertifikats beim Cert- 
Server ab (dieser ist NUR intern erreichbar, vom Login-Server) und  
gibt dann die bestaetigte Verbindung an den Datenbankserver weiter,  
mit den entsprechenden Regeln. Der ganze Vorgang kann auf EINEM Hobel  
laufen, mit isolierten Instanzen. Das hat im Uebrigen einen  
Sicherheitsvorteil: Man kann keine Leitungen kapern und abhorchen,  
keinen MidM versuchen ;-) Ich weiss, dass ist Denke der Neunziger.  
Aber eigentlich immer noch praktikabel, oder?

Gruss

Gottwalt