Re: [A2open-diskussion] A2Open

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

Am 13.06.2006 um 18:59 schrieb b1sp:

> Hallo Liste,
>
> On Tue, 13 Jun 2006 13:55:57 +0200, Gottwalt Thiersch wrote
>> [Zugriffskontrolle und Zugriffsbeschraenkungen]
>
> Von der Grundidee her nicht =FCbel. Da kann ich ein paar Gedanken
> zu beisteuern:
>
> Wir haben von der Firma her vor kurzem eine vgl. gesicherte Appli-
> kation auf ein neues System migriert: Das ganze l=E4uft als Webappli-
> kation mit Client-SSL-Zertifikaten, die auf Smart-Cards gespeichert
> werden.

Ich waere froh, wenn man auf SmartCard-Reader lokal verzichten =20
koennte. Ich waere wirklich gerne bereit, die zusaetzlichen =20
Sicherheitsluecken in kauf zu nehmen, die man durch Zertifikate auf =20
anderen Datentraegern sich einhandelt. Der Vorteil waere, dass A2Open =20=

nicht darauf angewiesen waere, dass irgendwelche zusaetzliche =20
Hardware angeschlossen und eingerichtet/installiert werden muss.
Deshalb waere ich sehr sehr weitgehend tolerant in dieser Beziehung. =20
Einzige Bedingung: Irgendein externes, schreibgeschuetztes Medium.

> Die prim=E4re Authentifizierung erfolgt dabei =FCber einen
> Apache Webserver, der prim=E4r die verschl=FCsselte Anbindung und
> sekund=E4r die erste Authentifizierung der Client-Zertifikate auf
> ihre G=FCltigkeit und die richtige Zertifizierungsstelle hin bereit-
> stellt.

Hier: Zertifikate wuerden ja durch die Zentrale selbst erstellt, =20
zugesandt und intern den einzelnen Dienststellen schon vor der =20
Zusendung formal zugeordnet. Das heisst: Die Dienststelle Marburg =20
benoetigt 55 Client-Schluessel und 3 Master-Schluessel. Dann bekommen =20=

sie 60 Clients und drei Master. Und diesen Schluesseln sind Nummern =20
zugeordnet, ueber die sie eindeutig einer Dienststelle zugeordnet =20
werden.
Beim Login wird nun das Zertifikat vom Authentizierungsserver =20
ueberprueft und der Zugriff freigegeben, mit entsprechenden =20
Einschraenkungen.

> Aktuell erfordert dieses Projekt, da=DF die User sich selbst ein
> Zertifikat erstellen m=FCssen und dieses bei der Zertifizierungs-
> stelle des Betreibers zum Signieren einreichen.

Zertifikate werden zentral erstellt und uebersendet. Und sie werden =20
gegen Unterschrift und Pfand vom Personalrat ausgehaendigt. Alles =20
andere ist Utopie, vom Ablauf her.

> Die von euch beschriebene Zugriffskontrolle d=FCrfte also am sinn-
> vollsten =FCber LDAP zu realisieren sein.
> Die heiligen K=FChe des Projekts w=E4ren somit der LDAP-Server, der
> Zertifizierungsserver und das zentrale DB-System.

Ja. Und wenn man das Ganze tatsaechlich -wie angedacht- mit IBM im =20
Ruecken realisiert, dann ist das Ganze ein zOS-Server, wo jede dieser =20=

Aufgaben voellig von den anderen abgeschottet ablaufen kann. Und mit =20
zwanzigtausend gleichzeitigen Zugriffen gibts dann auch kein Problem.

> Aus Sicherheitsgr=FCnden 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.

Das waere immer noch erheblich sicherer, wenn diese Zugriffe =20
ueberhaupt geloggt und autorisiert waeren, als beim derzeitigen System.

> Hier m=FCsste also ein entspr. Frontend her, da=DF die Validierung der
> Zul=E4ssigkeit und auch die Protokollierung des Zugriffs der Clients
> =FCbernimmt. Dies h=E4tte auch den Vorteil, da=DF sich kein =
manipulierter
> Client auf Daten zugreifen k=F6nnte, die ihn nichts angehen.
>
> Dies k=F6nnte z.B. so aussehen:
> 1. Client verbindet sich mit dem Frontend
>     -> Pr=FCfung 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=F6nnte
> auch die Schreibberechtigung und der Umfang der Leseberechtigung
> gew=E4hrt werden.

Ja. Und wegen der Einfachheit der Zugriffe ist das auch kein =20
Lastproblem.

>> 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=FCrde SW-Updates auch erleichtern.
> Zus=E4tzlich sollte vor dem Zugriff eines Clients zentral eine
> Versions=FCberpr=FCfung durchgef=FChrt werden, die u.U. (zu alte =
Version)
> den schreibenden/lesenden Zugriff verweigert.

Das hatten wir bereits besprochen: Beim Login erfolgt der =20
Versionsabgleich. Sind Updates vorhanden, so koennen diese =20
"huckepack" mit uebertragen werden ueber die sowieso stehende =20
Verbindung. Und da Updates in den allermeisten Faellen neue =20
Regelungen abbilden, die dank neuer Gesetze oder Verordnungen =20
implementiert wurden, koennen sie sogar im voraus uebertragen werden, =20=

mit entsprechendem Datumsvermerk ("wirksam ab 1.9.2007").

>> Das  Programm an sich laeuft und rechnet dann
>> lokal, die Ergebnisse werden  zentral gespeichert und zentral =20
>> verwaltet.
>
> Klingt vern=FCnftig und d=FCrfte die zentralen Server deutlich ent-
> lasten. Der Nachteil an reinen Webapplikationen ist ja, da=DF dort
> auch i.d.R. die gesamte Rechenpower liegen mu=DF. Zur =DCbertragung
> der abgefragten Daten w=E4re 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=F6nnen.

Da koennte man sogar auf EDIFAKT zurueckgreifen ;-) (keine Sorge, =20
will ich wirklich nicht, aber es ist hierfuer jedes beliebige =20
wohldefinierte Format geeignet). XML ist bestimmt am =20
unproblematischsten und auf jeden Fall hinreichend anpassungsfaehig.

Gruss

Gottwalt=