Re: [A2open-diskussion] (no subject)

[Guido S. <wa...@gm...>]

 
> 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...

Sicher. Aber da sehe ich rein technisch kein Problem. Wenn z.B. die Daten verschluesselt 
verschickt werden und  man einen Teil des Schluessels auf dem Schlusselmedium nimmt,  
um die ankommenden Daten zu entschluesseln, muessten wir schon recht viele Fehler
machen, um Missbrauch zu ermoeglichen. 

> 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.

Ok, gegen kostenlos werde ich niemals anargumentieren :-)

Aber eine Alternatividee:
Es gibt ein Frontend zum Datenbankserver. Ein Client loggt sich ein, schickt seinen 
Schluessel an das Frontend. Das macht eine ganz simple Abfrage, ob dieser Schluessl in der 
Datenbank gespeichert ist. Wenn nein: Bye bye. Wenn ja, dann nimmt er die Datenbankanfrage 
des Clients entgegen, uebergibt sie der Datenbank, nimmt die Antwort entgegen, 
verschluesselt die Antwort, und schickt die verschluesselte Antwort an den Client. Der kann 
mit seinem Schluessel die Antwort entschluesseln.
Das ganze natuerlich mit einem asymmetrischen Verfahren.

Theoretisch sehe ich in dieser Loesung nur wenige tausend Zeilen Code. Ob man das aber 
ausreichend skalierend hinbekommen, lasse ich mal offen.  

 
> > 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 gut. Mit Systemen solcher Groessenordnung habe ich keinerlei Erfahrung und verlasse 
mich da auf euch.

> 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. 

Ok.

> 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  

EINEM ist fuer mich das Zauberwort. Wenn eine Kiste das kann, habe ich keine Einwaende. 

> 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?

Naja, Abhoersicherheit wuerde ich hier als etwas weniger wichtig empfinden als 
Einbruchs- und Sabotagesicherheit. Ich nehme an, dass so ein Server nicht bei allen beliebt 
ist. Bei denen nicht, deren Unterstuetzung abgelehnt wurde, bei denen nicht, fuer die 
der Server eine Ohrfeige ist. Ich sehe das System als beliebtes Angriffsziel fuer alle 
moeglichen Gruppen. Daher wuerde ich den Code fuer jedes Teil so simpel wie 
irgend moeglich halten und so wenig Teile wie moeglich verwenden. Wenn auf der einen Seite 
z.B. ein Apache gebraucht wird, ist das schon ein relativ fettes Paket. 

Hi Burkhardt, wenn du aber sicher bist genug Erfahrung zu haben, das mit der Sicherheit 
hinzukriegen, bin ich mit deinem Vorschlag einverstanden.

Gruesse,
Guido