Re: [A2open-diskussion] A2open-diskussion

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

> Aus A2open ?bertragen k?nnte es so aussehen, da? z.B. die Master-
> Zertifikate zentral erstellt und via Kurier ?bermittelt werden.
> Die 'normalen' Client-Zertifikate k?nnen dann mittels der Master-
> Zertifikate erstellt und beantragt werden. Somit w?re jedes Client-
> Zertifikat der jeweiligen Stelle direkt zuzuordnen, die hierzu
> auch ?ber einen entpsr. Smart-Card-Writer verf?gen m?sste.
> Der Vorteil der SSL-Zertifikats/LDAP-Architektur w?rde darin liegen,
> da? Zugriffe durch zwei verschiedene Systeme eingeschr?nkt und bei
> Bedarf entspr. unterbunden (Durch widerrufen eines/aller einem
> Master-Zertifikat untergeordneten Client-Zertifikate und zus?tzlich
> durch ?nderung der Rechte im LDAP) werden k?nnen.
> 
> Die von euch beschriebene Zugriffskontrolle d?rfte also am sinn-
> vollsten ?ber LDAP zu realisieren sein.
> Die heiligen K?he des Projekts w?ren somit der LDAP-Server, der
> Zertifizierungsserver und das zentrale DB-System.
> Aus Sicherheitsgr?nden wird wohl kein Projektverantwortlicher einer
> Kommunikationsmatrix zustimmen, die einen direkten Zugriff der
> Clients auf den LDAP-Server und davon weitergehend auf den/die
> DB-Server vorsieht.
> 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. 
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. Wo landen wir mit einem LDAP-Server + 
Zertifizierungsserver ausreichender Groesse + zusaetzlicher Wartung   

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

> > [Backend]
> > Die Verwaltung der Zielvereinbarungen, 1-EUR-Jobs,  
> > Vermittlungstaetigkeit etc. erfolgt in separaten Loesungen. Das kann 
> >  man zwar Schritt fuer Schritt mit uebernehmen, theoretisch. Aber 
> > hier  gehts erstmal nur um den Funktionsumfang von A2LL.
> 
> Soweit ACK. Alles andere w?rde f?r den Anfang auch mehr als den
> Rahmen sprengen... ;-)

Plugins fuer spaeter einplanen. :-)

> > Ich bin der zuversichtlichen Ansicht, dass Guidos Idee, ein  
> > Grundprogramm zu erstellen, das seine konkrete Erscheinungsform 
> > durch  definierende Konfigurationsfiles erhaelt, voellig richtig 
> > ist. Und  diese Files koennen meinetwegen als .xml-Files oder in 
> > einem anderen  sinnvollen Format vorliegen. Das muss man nur 
> > einmalig festlegen.
> 
> Klingt soweit gut und w?rde SW-Updates auch erleichtern.
> Zus?tzlich sollte vor dem Zugriff eines Clients zentral eine
> Versions?berpr?fung durchgef?hrt werden, die u.U. (zu alte Version)
> den schreibenden/lesenden Zugriff verweigert.

Klar. Muss alles noch etwas komplizierter werden, z.B. schon Regeln an Clients verteilen, die erst 
nach einer gewissen Zeit spaeter wirksam werden, u.ae.

> > Das  Programm an sich laeuft und rechnet dann 
> > lokal, die Ergebnisse werden  zentral gespeichert und zentral verwaltet.
> 
> Klingt vern?nftig und d?rfte die zentralen Server deutlich ent-
> lasten. Der Nachteil an reinen Webapplikationen ist ja, da? dort
> auch i.d.R. die gesamte Rechenpower liegen mu?. 

Ich wuerde wirlich liebend gern auf Webapplikationen verzichten. Ausnahmen evtl. fuer die 
Schlusselverwaltung am DB-Server. Aber auch da wuerde ich lieber etwas anderes haben. Mangelndes 
Vertrauen, was die Sicherheit von Webapplikationen angeht. Ist aber vermutlich nur ein zu 
ueberwindendes Vorurteil. :-)

> Zur ?bertragung
> der abgefragten Daten w?re XML wahrscheinlich auch hervorragend
> geeignet, da ja alle vorhandenen Parameter definiert sind und 
> durch ein SW-Update des Clients/der DB ggf. nachgepflegt werden
> k?nnen.

Ja, sollten wir grundsaetzlich nehmen. Dafuer wurde es erfunden. Evtl. komprimiert und 
verschluesselt, aber Datenaustausch zwischen verschiedenen Plattformen sollten grundsaetzlich XML 
basiert sein. 'Grundsaetzlich' im juristischen Sinne.



Gruesse,
Guido