a2open-diskussion Mailing List for A2Open

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Bearbeitung in meinen Augen sehr gut, Attachment kam an.

Gruss

Gottwalt

Hi Liste,
teste mal, ob ich mit dieser Liste auch Attachments verschicken kann.
Schaut euch mal den Text an, den ich aus Gottwalts Zusammenfassung 
erarbeitet habe. Noch nicht 100%ig fertig, aber bevor ich evtl. in die
falsche Richtung galoppiere.....

Das soll spaeter auch die Grundlage fuer eine allgemeine 
Projektbeschreibung auf unserer SF-Webseite werden.

Gruesse,
Guido

>> Bei allen erhobenen
>> Daten kann -wie auch auf dem Papierbogen- vermerkt werden, wodurch
>> die Daten belegt wurden und ob eine Kopie des belegenden Dokumentes
>> erstellt und der Akte beigefuegt wurde.
>
> Wird das derzeit schon gemacht?

Weiss ich nicht.

> Ich meine, wird das bereits in der
> vorhandenen A2LL Datenbank abgespeichert? Brauchen wir dazu Freiform,

Ja. Die Arbeitsagentur verwendet festgelegte Kuerzel. Aber diese sind  
mannigfaltig. Und manches muss auch ohne Kuerzel ausgeschrieben  
werden. Man stelle sich z. B. einen Folterbericht von AI als Beleg  
der eingeschraenkten Arbeitsfaehigkeit vor. Den kann man nicht  
standardisiert erfassen... mal so als Extrembeispiel.

> oder koennen wir eine feste Auswahl von Moeglichkeiten, wie ein
> bestimmtes Datum belegt werden kann z.B. per ListBox anbieten?

Bei einigen Punkten ja, bei den meisten nein.

>> Bei "Antrag bearbeiten / Folgeantrag erstellen" werden die zur
>> Vorgangsnummer gehoerenden Daten dem Frontend uebermittelt, in
>> folgenden Abstufungen: Wurden die Daten mit dem jetzt auch
>> verwendeten Schluessel damals gespeichert, so werden sie einfach zur
>> Bearbeitung freigegeben ohne weitere Nachfrage. Werden die Daten von
>> einem anderen Schluessel der selben Dienststelle angefordert, wird
>> nachgefragt, ob man wirklich bearbeiten moechte. Werden die Daten von
>> einem Schluessel einer anderen Dienststelle angefordert, so werden
>> lediglich die Daten lesend angezeigt, die man auch in der
>> Statusabfrage sehen kann.
>
> Kennst du dich so gut aus, dass du beurteilen kannst, dass wir da  
> nicht
> evtl. voellig an den Beduerfnissen der Aemter vorbei designen?

Da ging ich nach meinen letzten Kontakten davon aus, dass das im  
Grossen den Beduerfnissen entspricht. Wir werden unbedingt noch -ggf.  
anonym- wenigstens EINEN Sachbearbeiter einbinden MUESSEN. Da kann  
man das dann mit der Realitaet gegenpruefen.

>> Zur Bearbeitung muss der Sachbearbeiter
>> entweder die Daten durch den zentralen "Masterkey" der Dienststelle
>> freigeben lassen (dadurch wird dieser Vorgang explizit der neuen
>> Dienststelle zugeordnet, die alte Dienststelle erhaelt dadurch nur
>> noch lesenden Zugriff auf die mit der "Statusabfrage" verfuegbaren
>> Daten) oder er schickt eine automatische Anfrage an die bisher
>> bearbeitende Dienststelle. Dort kann dann die Akte von einem
>> Sachbearbeiter explizit fuer die neue Dienststelle freigegeben
>> werden. Auch dann erhaelt die alte Dienststelle nur noch lesende
>> Zugriff auf die in der "Statusabfrage" verfuegbaren Daten.
>> Hintergrund: Im derzeitigen A2LL ist jeder Datensatz von jedem
>> Mitarbeiter frei einsehbar und jederzeit veraenderbar. Diese Zugriffe
>> werden weder eingeschraenkt noch wenigstens kontrolliert.
>
> Ich habe halt Angst, dass es evtl. boeses Blut geben koennte, wenn ein
> MA seine Daten eingibt, 2 Wochen in Urlaub faehrt, und wenn er
> zurueckkommt aus irgendwelchen Gruenden ploetzlich nur noch  
> Lesezugriff
> hat.

Nein, das ist schon ok. Solange der Datensatz seiner Dienststelle  
zugeordnet blieb, kann er sich ja ganz einfach wieder Schreibrechte  
selbst genehmigen. Und wenn der Datensatz die Dienststelle wechselte,  
dann steht ihm auch kein Schreibrecht mehr zu. Offener sollten wir es  
wirklich nicht gestalten.

>> Messaging zu anderen Sachbearbeitern, Dienststellen und Helpdesk
>
> Ist das sinnvoll? Unser Programm ist eines von vielen, die auf den
> Rechnern der Bearbeiter laufen. Muss denn gerade unseres Email-Client,
> Messenger, Kaffeemaschine (ok, Uebertreibung) sein? Messaging sehe ich
> zwar als einen moeglichen, aber doch ganz erheblich aufwendigen
> Nebenkriegsschauplatz an.
> Wie stellst du dir die Realisierung vor? Aus
> dem Programm Emails zu verschicken, halte ich dagegen als relativ  
> gut zu
> implementieren, was das Kosten/Nutzen-Verhaeltnis angeht.

Denke es Dir als Newsserver mit Groups (Dienststellen oder andere  
sinnvolle Einheiten) und Private Messages, aber innerhalb dessen  
quasi "verlinkte" Funktionalitaet. Sprich: Meldung an Dienststelle  
xy: Bitte gebt mir Datensatz sowieso frei. Ein Mitarbeiter der  
entsprechenden Dienststelle klickt dann nur auf "freigeben". Fertig.  
Oder Meldung an Chef vom Dienst: Bitte transferiere mir Datensatz  
sowieso zu unserer Dienststelle. Chef klickt "transferieren". Oder  
"welcher Hornochse hat jetzt Frau sowieso doch den erhoehten Bedarf  
genehmigt?" (bleibt innerhalb der Dienststelle) oder: "Hilfe! Wie  
gebe ich nicht definierte Sonderbedarfe ein?" (geht an Helpdesk).
Bitte korrigiert mich hier, wenn ich mir das idiotisch vorstelle.  
Aber durch die Anonymisierung sehe ich die Notwendigkeit der  
integrierten Korrespondenz an die jeweiligen Schluesselinhaber, mit  
direkt zugreifbarer Funktionalitaet. Dafuer dann ein nett blinkender  
Hinweis auf neue Nachrichten (auch bei Rundschreiben an eine Gruppe.  
Bei Fragen nach Freigabe sollte der "Blink" aufhoeren, wenn der  
Datensatz freigegeben wurde).

> Damit sind wir schon recht weit. Ich veruche mal daraus etwas
> graphisches zu machen, damit wir wenigstens eine einfach Webseite  
> haben,
> auf die wir Interessenten verweisen koennen.

Danke und Gruss

Gottwalt

Hallo.
Das ist ja fast schon ein Lastenheft :-)

> Utopisches Ziel:
> Vollstaendiger Ersatz der derzeitigen A2LL-Software
> Motiv:
> Technologie-Demonstration als Beweis der hoffnungslosen Unfaehigkeit  
> von T-Systems in diesem Projekt

Das stimmt ich 100%ig zu, aber wenn ich (oder ein besserer HTML-Coder) 
unserer Webseite zur Projektpraesentation macht, sollten wir es 
vielleich etwas diplomatischer formulieren. Andererseits.....seit wann 
bin ich diplomatisch? ;-)

> Realistisches Ziel:
> Bereitstellung eines freien Tools zur Nutzung durch ALG-2-Empfaenger  
> zur Bescheidberechnung

Waere schoen, wenn das als wichtiges Teilziel festegelegt wird. 
T-Systems eins auszuwischen, ist ein wunderbares Motiv. Die eigene 
Arbeit real benutzt zu sehen, doch etwas befriedigender. 

> Referenz fuer die Beteiligten
> Kenntniserweiterung und -vertiefung der Beteiligten
> Module:
> Frontend:
> Programm interpretiert Strukturen, die durch xml-Dateien vorgegeben  
> werden. Dadurch wird die benoetigte Funktionalitaet zur Berechnung,  
> Speicherung und Verwaltung der Arbeitslosengeld-2-Antraege und  
> Bescheide zur Verfuegung gestellt.
> Dies beinhaltet insbesondere (schrittweise analog zur gedachten  
> Arbeitsweise):
> Login beim Datenbankserver mit Zugriffsgenehmigung
> ? Ueberpruefung der Antragstellerdaten auf bereits gestellte Antraege  
> oder andere Widerspruechlichkeiten, die sich aus den Daten des  
> Datenbankservers ergeben
> ? Erfassung aller antragsrelevanten Daten
> ? Vorlaeufige Berechnung des Leistungsanspruches
> ? Speicherung der gesamten erfassten Daten und berechneten Ansprueche  
> auf dem zentralen Datenbankserver, ersatzweise voruebergehend lokal
> ? Veranlassung bzw. Verwaltung von Vorschuessen,  
> Berechnungsaenderungen, nachtraeglichen Anrechnungen von  
> Zuverdiensten etc.
> Als Implementierung ist angedacht: Schluessel werden durch den  
> Personalrat an die Mitarbeiter gegen Unterschrift ausgegeben. Die  
> Schluessel sind seitens des Softwarebetreibers einzelnen  
> Dienststellen, aber nicht einzelnen Mitarbeitern zugeordnet, um die  
> Anforderungen des Personalrats an anonymisierte Nutzung des Systems  
> zu gewaehrleisten und gleichzeitig unbefugte Zugriffe zu minimieren.
> Schluessel werden beim ersten Login durch ein frei waehlbares  
> Passwort des Sachbearbeiters "aktiviert". Das heisst: Ab diesem  
> Moment ist das Schluesselmedium nur zusammen mit dem bei jedem Login  
> einzugebenden Passwort nutzbar.
> Nach dem Login stehen folgende Optionen bereit:
> ? Status abfragen (also: Existiert zu bestimmten Personen bereits ein  
> Antrag, ein Bescheid etc.?)
> ? Neuantrag erfassen
> ? Antrag bearbeiten / Folgeantrag stellen
> Bei der Statusabfrage kann mit den Kriterien  
> Rentenversicherungsummer, Vorname, Name, Geburtsdatum, Meldeadresse,  
> Geburtsname, Geburtsort, Namen der Eltern abgefragt werden.
> Hier erhaelt man auch keine weiteren Informationen.
> Beim "Neuantrag" steht die Statusabfrage fuer alle Mitglieder der im  
> Antrag genannten Bedarfsgemeinschaft am Anfang, anschliessend werden  
> mit einem Layout voellig analog zum Antragsbogen alle dort  
> eingetragenen Daten uebernommen. Dabei stehen dem Sachbearbeiter zu  
> den einzelnen Eingabe- und Optionsfeldern jeweils die relevanten  
> Gesetzes- und Verfahrensanordnungstexte hinterlegt zur Verfuegung  
> (dies ist ein erheblicher Sorgfaltsaufwand!).

Nicht mehr oder weniger grosser Sorfaltsaufwand, als fuer die zu 
interpretierenden in XML gegossenen Regeln, die die Berechnung machen. 
Ich finde, das ist eine gute Idee und hilft uns auch bei der Entwicklung 
der Regeln, wenn gleichzeitig der Gesetzestext mit eingebunden wird.

> Bei allen erhobenen  
> Daten kann -wie auch auf dem Papierbogen- vermerkt werden, wodurch  
> die Daten belegt wurden und ob eine Kopie des belegenden Dokumentes  
> erstellt und der Akte beigefuegt wurde.

Wird das derzeit schon gemacht? Ich meine, wird das bereits in der 
vorhandenen A2LL Datenbank abgespeichert? Brauchen wir dazu Freiform, 
oder koennen wir eine feste Auswahl von Moeglichkeiten, wie ein 
bestimmtes Datum belegt werden kann z.B. per ListBox anbieten?

> Zum Abschluss der Erfassung wird der Anspruchsbetrag berechnet, ein  
> vorlaeufiger Bescheid erstellt und die Daten auf dem Datenbankserver  
> gespeichert. Bei Netzwerk- oder Serverausfall entfaellt hierbei die  
> Statusabfrage und die zentrale Speicherung, ersatzweise wird auf dem  
> lokalen Rechner zwischengespeichert. Bei der naechsten Verbindung zum  
> Server werden automatisch die lokal gespeicherten Daten erstmal  
> ueberprueft (automatisierte Statusabfrage aller Personen der  
> Bedarfsgemeinschaft), falls keine Konflikte dabei auftreten werden  
> die Daten vom Sachbearbeiter unbemerkt zentral gespeichert. Ansonsten  
> wird eine Fehlermeldung ausgegeben und die erneute Bearbeitung des  
> Falles verlangt.
> Bei "Antrag bearbeiten / Folgeantrag erstellen" werden die zur  
> Vorgangsnummer gehoerenden Daten dem Frontend uebermittelt, in  
> folgenden Abstufungen: Wurden die Daten mit dem jetzt auch  
> verwendeten Schluessel damals gespeichert, so werden sie einfach zur  
> Bearbeitung freigegeben ohne weitere Nachfrage. Werden die Daten von  
> einem anderen Schluessel der selben Dienststelle angefordert, wird  
> nachgefragt, ob man wirklich bearbeiten moechte. Werden die Daten von  
> einem Schluessel einer anderen Dienststelle angefordert, so werden  
> lediglich die Daten lesend angezeigt, die man auch in der  
> Statusabfrage sehen kann.

Kennst du dich so gut aus, dass du beurteilen kannst, dass wir da nicht 
evtl. voellig an den Beduerfnissen der Aemter vorbei designen? Ich 
wuerde gerne mit jemanden aus einem Arbeitsamt sprechen. Tja, bisher hat 
sich noch niemand auf meine Emails gemeldet. So richtig Interesse 
scheint bei denen nicht zu bestehen.

> Zur Bearbeitung muss der Sachbearbeiter  
> entweder die Daten durch den zentralen "Masterkey" der Dienststelle  
> freigeben lassen (dadurch wird dieser Vorgang explizit der neuen  
> Dienststelle zugeordnet, die alte Dienststelle erhaelt dadurch nur  
> noch lesenden Zugriff auf die mit der "Statusabfrage" verfuegbaren  
> Daten) oder er schickt eine automatische Anfrage an die bisher  
> bearbeitende Dienststelle. Dort kann dann die Akte von einem  
> Sachbearbeiter explizit fuer die neue Dienststelle freigegeben  
> werden. Auch dann erhaelt die alte Dienststelle nur noch lesende  
> Zugriff auf die in der "Statusabfrage" verfuegbaren Daten.
> Hintergrund: Im derzeitigen A2LL ist jeder Datensatz von jedem  
> Mitarbeiter frei einsehbar und jederzeit veraenderbar. Diese Zugriffe  
> werden weder eingeschraenkt noch wenigstens kontrolliert.

Ich habe halt Angst, dass es evtl. boeses Blut geben koennte, wenn ein 
MA seine Daten eingibt, 2 Wochen in Urlaub faehrt, und wenn er 
zurueckkommt aus irgendwelchen Gruenden ploetzlich nur noch Lesezugriff 
hat. 

> Durch den obigen Vorgang koennen die Bearbeitungs-Zugriffe erheblich  
> eingeschraenkt werden, und zwar auf die wirklich zustaendige  
> Dienststelle, und lesende Zugriffe sind ausser bei den von der  
> eigenen Behoerde bearbeiteten Faelle nur auf die "oeffentlichen"  
> Stammdaten moeglich.
> Durch das Logging aller Zugriffe und die indirekt moegliche Zuordnung  
> eines Schluessels zu einem bestimmten Sachbearbeiter (ueber den Umweg  
> Personalrat) ist immerhin bei deliktischen Vergehen auch eine Ahndung  
> moeglich.
> So wird die Schwelle fuer Datenmissbrauch erheblich hoeher gesetzt  
> als bei der derzeitigen Loesung, auch wenn Datenmissbrauch nicht  
> ausgeschlossen wird. Die Schwelle noch hoeher zu setzen erscheint vom  
> Verwaltungsaufwand her und wegen des fehlenden Zugriffs auf die  
> Hardware vor Ort in den Dienststellen nicht umsetzbar.
> Was muss das Frontend noch koennen?

> Messaging zu anderen Sachbearbeitern, Dienststellen und Helpdesk

Ist das sinnvoll? Unser Programm ist eines von vielen, die auf den 
Rechnern der Bearbeiter laufen. Muss denn gerade unseres Email-Client, 
Messenger, Kaffeemaschine (ok, Uebertreibung) sein? Messaging sehe ich 
zwar als einen moeglichen, aber doch ganz erheblich aufwendigen 
Nebenkriegsschauplatz an. Wie stellst du dir die Realisierung vor? Aus 
dem Programm Emails zu verschicken, halte ich dagegen als relativ gut zu 
implementieren, was das Kosten/Nutzen-Verhaeltnis angeht.  

> Darstellung der gesamten Historie eines Vorganges
> Mannigfaltige Bearbeitungs- und Gespraechsvermerke
> Leistungsminderungsverwaltung
> Backend:
> Loginserver. An diesem melden sich die Clients mit einem Zertifikat  
> als "Benutzername" und einem "Passwort" an. Der Login-Server  
> uebergibt das Zertifikat zur Ueberpruefung an den Cert-Server und  
> reicht nach dem "ok" die Verbindung an den Datenbankserver weiter.  
> Einen dazwischenliegenden AppServer zur Bearbeitung der Abfragen etc.  
> wuerden wir gerne vermeiden, da es sich ausschliesslich um  
> unabhaengige simple Such- (Lese-) und Schreibprozesse handelt, die  
> einfach abhandelbar sind und die eigentliche Berechnung auf den  
> Clients erfolgt.
> Cert-Server:
> Hier sind die Zertifikate gespeichert und hier werden die abgefragten  
> Zertifikate auf ihre Gueltigkeit hin ueberprueft. Hier erfolgt auch  
> die Gruppen-Zuordnung (dienststellenweise) der einzelnen Zertifikate,  
> und hier wird auch bestaetigt, ob es sich um ein "normales"  
> Zertifikat handelt oder um einen "Masterkey". Diese Information wird  
> an den Login-Server zurueckgegeben, der die Verbindung entsprechend  
> an den Datenbankserver weiterreicht.
> Datenbankserver:
> Dieser speichert alle Antrags- und Bescheiddaten, generiert taegliche  
> "Berichte" als Ueberweisungsauftrag an die Buchhaltungssoftware  
> (anscheinend immer noch EDIFAKT), an die Krankenkassen (ebenfalls  
> anscheinend noch EDIFAKT), an die Rentenversicherer und die  
> Sozialaemter. Diese Berichte werden bereitgestellt und abgeholt.
> Monatlich und jaehrlich werden diverse statistische Auswertungen  
> generiert.
> Laufend werden die Abfragen des Frontends und der Sozialaemter,  
> Optionskommunen, Rentenversicherer ("Statusabfragen") beantwortet  
> sowie die Neuantraege und Aenderungen bestehender Antraege  
> gespeichert. Fuer die Sozialaemter, Optionskommunen und  
> Rentenversicherer muss ein wohldefiniertes Abfrage-Interface  
> bereitgestellt werden, das exakt die Funktionalitaet der  
> Statusabfrage abbildet und in andere Software einfach implementiert  
> werden kann.
> 
> Fuer Berichte, Statistiken und Wartungsarbeiten stehen die Naechte,  
> Feiertage und Wochenenden zur Verfuegung, sodass diese nicht waehrend  
> des laufenden Betriebes zusaetzliche Last oder Ausfallzeit erzeugen.
> 
> Soweit bisher, mit der Bitte um Ergaenzungen

Damit sind wir schon recht weit. Ich veruche mal daraus etwas 
graphisches zu machen, damit wir wenigstens eine einfach Webseite haben, 
auf die wir Interessenten verweisen koennen.

Gruesse,
Guido

On Wed, 14 Jun 2006 10:27:36 +0200, Gottwalt Thiersch wrote

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

Sollte ohne groesseren Aufwand realisierbar sein. Im Prinzip
braucht der Login-Server auch keine direkte Verbindung zum 
Cert-Server: Die CRL kann auch bei Aenderungen im Push-Ver-
fahren auf den Login-Server uebertragen werden. Fuer die Rechte-
Verwaltung koennte anstelle von LDAP auch eine zweite DB-
Instanz auf dem DB-Server verwendet werden.

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

Daher ja auch mein Vorschlag bez. per FW getrennter VLANs: Selbst,
wenn es jemand in den Login-Server schafft, steckt er dort weitgehend
isoliert fest und kann hoechstens den Datenverkehr in Richtung DB-Server
mitsniffen.

Gruss,
Burkhardt

On Wed, 14 Jun 2006 10:48:09 +0200, Gottwalt Thiersch wrote
> > Ansonsten muessten in jeder Dienststelle eine ausreichende Anzahl
> > an Reserverzertifikaten zur Verfuegung stehen...
> 
> Genau dies ist notwendig. Man koennte sich auch noch folgendes  
> Scenario vorstellen: Mitarbeiter kommt zum Personalrat, erhaelt  
> seinen Schluessel, Personalrat traegt zur Schluesselnummer den  
> Mitarbeiternamen ein, der Mitarbeiter unterschreibt, und der  
> Personalrat meldet nun mit einem "Anmeldeschluessel" den  
> Mitarbeiterschluessel an. Dann koennten beliebig viele  
> Vorratsschluessel bereitliegen, die man aber erst nach Freischaltung 
>  nutzen kann. Ich halte das aber fuer zu aufwendig. Man stelle sich  
> eine Behoerde mit z. B. 300 Sachbearbeitern vor, die Schluessel  brauchen...

Naja, das von mir schon beschriebene Projekt ist eine Behoerde
und setzt deutlich mehr als 300 User-Zertifikate ein. AFAIK
kuemmern sich aktuell ganze 2 MAs um die CA. Am Anfang waren es
natuerlich mehr. Weitere Details aus verstaendlichen Gruenden nur
im persoenlichen Gespraech...

> > Die Moeglichkeit der sofortigen Sperrung bei Bekanntwerden des
> > Verlusts bieten beide Varianten. Alternativ koennte dies auch mit
> > anderen Zertifikatstraegern durchgefuehrt werden. Dafuer muessten
> > dann am sinnvollsten Datentraeger der Kategorie Write once, Read
> > many eingesetzt werden.
> 
> Es sind zwei Probleme:
> 1. Wie wird der Zertifikatstraeger vom PC gelesen?

Sollte bei den e-tokens von Aladdin kein größeres Problem sein,
die sind auf einfache Anwendung gestrickt.

> 2. Wieviel kostet der einzelne Zertifkatstraeger und die fuers Lesen 
>  benoetigte Infrastruktur?

Was die Infrastruktur angeht: Gute Frage.
Die reinen USB-Tokens liegen im VK bis 2500 Stueck bei 37 Euronen.
Ich habe zum Vergleich auch mal nach den Preisen fuer SmartCards
und USB-Readern geschaut: Bis 1000 Stueck kommen die Karten und
Reader von Aladdin auf 14 bzw. 36 Euronen.

> Ich wuerde gerne NICHT AIX einsetzen, lieber iOS oder zOS. Aber das  
> ist reine persoenliche Vorliebe (die sich natuerlich auch mit  
> Argumenten untermauern laesst, die allerdings fuer den Einsatzzweck  
> irrelevant sind).

Geht mir nicht anders: Bei AIX schiesst mir sofort wieder der
Gedanke an smitty ins Hirn und anschliessend Brechreiz in den
Magen. Ich liebe Konfigurationsdateien und hasse zentrale Tools,
die einem die Konfig wieder zerschiessen, wenn man sie ohne die
Tools aendert...
Das System laeuft im uebrigen auf SLES 8 fuer Power.

> Voelliger Overkill fuers geplante Projekt. Jetzt steht dort EINE Sun 
>  Enterprise mit Informix als Datenbankserver im einen Rechenzentrum, 
>  einige dutzend x86-Linux-Server als Webserver und ebenso einige 
>  dutzend x86-Windows-Server als AppServer im anderen Rechenzentrum.  
> Und lediglich Administrationszugriffe duerfen nur aus dem eigenen  
> Subnetz erfolgen. Ansonsten werden weder Zugriffe geloggt noch sonst 
>  irgendwie Rechte vergeben und verwaltet.

Naja, die BAfA scheint Datenschutz ja nicht wirklich all zu
ernst zu nehmen... Rein terroristisch koennte man auch auf die
ganze Sicherheitsinfrastruktur in grossen Teilen verzichten.
Ich hatte es halt angebracht, weil es in Enterprise-Umgebungen
mit sensiblen Daten mittlerweile eher Standard ist.

> Wie gesagt: Overkill. Wir brauchen keine 24/7-Redundanz, sondern  
> 10/5. Wartung kann nachts und am Wochenende erfolgen, und wenn der  
> zentrale Server mal fuer drei Stunden unten ist, dann geht zwar 
> alles  nur provisorisch, aber es geht immerhin.

Nachts und am WE bei einer Ex-Behoerde??? Viel Spass... 
Lieber lassen die Entscheider Bundesweit ntausend MAs 
Daeumchen fuer ein paar Stunden drehen, als einen WE-
Einsatz von z.B. 5 Admins zu genehmigen... In der freien
Wirtschaft laeuft das Problemlos, weil da die Entscheider
i.d.R. wissen, dass Zeit Geld ist. Hatte letztes WE erst
wieder Einsatz wg. einem Releasewechsel.

OT: Als ich neulich einen Bericht ueber die SW-Umstellung der
Zulassungsstelle Koeln gesehen habe, dachte ich auch wieder
"Typisch Behoerde", mit Vorankuendigung drei Tage schliessen
fuer eine Sache, die man von Freitag Abend bis Montag Morgen
locker durchziehen koennte. Zu Sicherheit und zum Testen den
Montag noch dicht machen und gut ist...

> Ja ja. Das Problem war: Macht man Rechte-Management und loggt man  
> Zugriffe, kann man darueber feststellen, welcher Mitarbeiter wann 
> was  gemacht hat. Aber das erlaubt der Personalrat nicht, denn 
> darueber  koennte man die Qualitaet und Quantitaet der Arbeit 
> einzelner  Mitarbeiter bewerten. Auch koennte man einzelne 
> Mitarbeiter fuer ihre  Fehler zur Rechenschaft ziehen. Ausserdem: Da 
> ja ARGEn, Optionskommunen und Arbeitsagenturen auf die  Daten 
> zugreifen muessen, haette man allein mit der Verwaltung der  
> Beantragung, Erteilung und Loeschung von Accounts einen riesigen 
>  Wasserkopf beschaeftigt. Loggt man aber ohne Benutzerverwaltung,
>  dann  kommt unter Umstaenden jemand faelschlich in Verdacht, der 
> gar nicht  an seinem Arbeitsplatz sass, waehrend sein Arbeitsplatz 
> von einem  Boesewicht missbraucht wurde. Also, das Problem war: Eine 
> Rechteverwaltung war verwaltungstechnisch  zu aufwendig, die 
> Bedenken des Personalrates nicht auszuraeumen, und  ein Logging der 
> Zugriffe ohne Rechteverwaltung waere vom Personalrat  ebenfalls 
> nicht genehmigt worden. Aus den angefuehrten Gruenden.  Deshalb 
> verzichtet man lieber gaenzlich auf jegliche  Rechteverwaltung. Und 
> deshalb lege ich so viel Wert darauf, dass der  Software-Betreiber 
> nur unter Mitwirkung des Personalrates an Namen  von 
> Zertifikatsinhabern kommen kann und ansonsten Zugriffe zwar  
> zertifiziert aber voellig anonym geloggt werden.

Klingt in der Form nach einer akzeptablen Loesung, die auch den
Segen von jedem Personal- und Betriebsrat erhalten sollte. Unab-
hängig von dem Eingesetzten Mittel zur Authentifizierung.

Gruß,
Burkhardt

Utopisches Ziel:
Vollstaendiger Ersatz der derzeitigen A2LL-Software
Motiv:
Technologie-Demonstration als Beweis der hoffnungslosen Unfaehigkeit =20
von T-Systems in diesem Projekt
Realistisches Ziel:
Bereitstellung eines freien Tools zur Nutzung durch ALG-2-Empfaenger =20
zur Bescheidberechnung
Referenz fuer die Beteiligten
Kenntniserweiterung und -vertiefung der Beteiligten
Module:
Frontend:
Programm interpretiert Strukturen, die durch xml-Dateien vorgegeben =20
werden. Dadurch wird die benoetigte Funktionalitaet zur Berechnung, =20
Speicherung und Verwaltung der Arbeitslosengeld-2-Antraege und =20
Bescheide zur Verfuegung gestellt.
Dies beinhaltet insbesondere (schrittweise analog zur gedachten =20
Arbeitsweise):
Login beim Datenbankserver mit Zugriffsgenehmigung
=95 Ueberpruefung der Antragstellerdaten auf bereits gestellte Antraege =20=

oder andere Widerspruechlichkeiten, die sich aus den Daten des =20
Datenbankservers ergeben
=95 Erfassung aller antragsrelevanten Daten
=95 Vorlaeufige Berechnung des Leistungsanspruches
=95 Speicherung der gesamten erfassten Daten und berechneten Ansprueche =20=

auf dem zentralen Datenbankserver, ersatzweise voruebergehend lokal
=95 Veranlassung bzw. Verwaltung von Vorschuessen, =20
Berechnungsaenderungen, nachtraeglichen Anrechnungen von =20
Zuverdiensten etc.
Als Implementierung ist angedacht: Schluessel werden durch den =20
Personalrat an die Mitarbeiter gegen Unterschrift ausgegeben. Die =20
Schluessel sind seitens des Softwarebetreibers einzelnen =20
Dienststellen, aber nicht einzelnen Mitarbeitern zugeordnet, um die =20
Anforderungen des Personalrats an anonymisierte Nutzung des Systems =20
zu gewaehrleisten und gleichzeitig unbefugte Zugriffe zu minimieren.
Schluessel werden beim ersten Login durch ein frei waehlbares =20
Passwort des Sachbearbeiters "aktiviert". Das heisst: Ab diesem =20
Moment ist das Schluesselmedium nur zusammen mit dem bei jedem Login =20
einzugebenden Passwort nutzbar.
Nach dem Login stehen folgende Optionen bereit:
=95 Status abfragen (also: Existiert zu bestimmten Personen bereits ein =20=

Antrag, ein Bescheid etc.?)
=95 Neuantrag erfassen
=95 Antrag bearbeiten / Folgeantrag stellen
Bei der Statusabfrage kann mit den Kriterien =20
Rentenversicherungsummer, Vorname, Name, Geburtsdatum, Meldeadresse, =20
Geburtsname, Geburtsort, Namen der Eltern abgefragt werden.
Hier erhaelt man auch keine weiteren Informationen.
Beim "Neuantrag" steht die Statusabfrage fuer alle Mitglieder der im =20
Antrag genannten Bedarfsgemeinschaft am Anfang, anschliessend werden =20
mit einem Layout voellig analog zum Antragsbogen alle dort =20
eingetragenen Daten uebernommen. Dabei stehen dem Sachbearbeiter zu =20
den einzelnen Eingabe- und Optionsfeldern jeweils die relevanten =20
Gesetzes- und Verfahrensanordnungstexte hinterlegt zur Verfuegung =20
(dies ist ein erheblicher Sorgfaltsaufwand!). Bei allen erhobenen =20
Daten kann -wie auch auf dem Papierbogen- vermerkt werden, wodurch =20
die Daten belegt wurden und ob eine Kopie des belegenden Dokumentes =20
erstellt und der Akte beigefuegt wurde.
Zum Abschluss der Erfassung wird der Anspruchsbetrag berechnet, ein =20
vorlaeufiger Bescheid erstellt und die Daten auf dem Datenbankserver =20
gespeichert. Bei Netzwerk- oder Serverausfall entfaellt hierbei die =20
Statusabfrage und die zentrale Speicherung, ersatzweise wird auf dem =20
lokalen Rechner zwischengespeichert. Bei der naechsten Verbindung zum =20=

Server werden automatisch die lokal gespeicherten Daten erstmal =20
ueberprueft (automatisierte Statusabfrage aller Personen der =20
Bedarfsgemeinschaft), falls keine Konflikte dabei auftreten werden =20
die Daten vom Sachbearbeiter unbemerkt zentral gespeichert. Ansonsten =20=

wird eine Fehlermeldung ausgegeben und die erneute Bearbeitung des =20
Falles verlangt.
Bei "Antrag bearbeiten / Folgeantrag erstellen" werden die zur =20
Vorgangsnummer gehoerenden Daten dem Frontend uebermittelt, in =20
folgenden Abstufungen: Wurden die Daten mit dem jetzt auch =20
verwendeten Schluessel damals gespeichert, so werden sie einfach zur =20
Bearbeitung freigegeben ohne weitere Nachfrage. Werden die Daten von =20
einem anderen Schluessel der selben Dienststelle angefordert, wird =20
nachgefragt, ob man wirklich bearbeiten moechte. Werden die Daten von =20=

einem Schluessel einer anderen Dienststelle angefordert, so werden =20
lediglich die Daten lesend angezeigt, die man auch in der =20
Statusabfrage sehen kann. Zur Bearbeitung muss der Sachbearbeiter =20
entweder die Daten durch den zentralen "Masterkey" der Dienststelle =20
freigeben lassen (dadurch wird dieser Vorgang explizit der neuen =20
Dienststelle zugeordnet, die alte Dienststelle erhaelt dadurch nur =20
noch lesenden Zugriff auf die mit der "Statusabfrage" verfuegbaren =20
Daten) oder er schickt eine automatische Anfrage an die bisher =20
bearbeitende Dienststelle. Dort kann dann die Akte von einem =20
Sachbearbeiter explizit fuer die neue Dienststelle freigegeben =20
werden. Auch dann erhaelt die alte Dienststelle nur noch lesende =20
Zugriff auf die in der "Statusabfrage" verfuegbaren Daten.
Hintergrund: Im derzeitigen A2LL ist jeder Datensatz von jedem =20
Mitarbeiter frei einsehbar und jederzeit veraenderbar. Diese Zugriffe =20=

werden weder eingeschraenkt noch wenigstens kontrolliert.
Durch den obigen Vorgang koennen die Bearbeitungs-Zugriffe erheblich =20
eingeschraenkt werden, und zwar auf die wirklich zustaendige =20
Dienststelle, und lesende Zugriffe sind ausser bei den von der =20
eigenen Behoerde bearbeiteten Faelle nur auf die "oeffentlichen" =20
Stammdaten moeglich.
Durch das Logging aller Zugriffe und die indirekt moegliche Zuordnung =20=

eines Schluessels zu einem bestimmten Sachbearbeiter (ueber den Umweg =20=

Personalrat) ist immerhin bei deliktischen Vergehen auch eine Ahndung =20=

moeglich.
So wird die Schwelle fuer Datenmissbrauch erheblich hoeher gesetzt =20
als bei der derzeitigen Loesung, auch wenn Datenmissbrauch nicht =20
ausgeschlossen wird. Die Schwelle noch hoeher zu setzen erscheint vom =20=

Verwaltungsaufwand her und wegen des fehlenden Zugriffs auf die =20
Hardware vor Ort in den Dienststellen nicht umsetzbar.
Was muss das Frontend noch koennen?
Messaging zu anderen Sachbearbeitern, Dienststellen und Helpdesk
Darstellung der gesamten Historie eines Vorganges
Mannigfaltige Bearbeitungs- und Gespraechsvermerke
Leistungsminderungsverwaltung
Backend:
Loginserver. An diesem melden sich die Clients mit einem Zertifikat =20
als "Benutzername" und einem "Passwort" an. Der Login-Server =20
uebergibt das Zertifikat zur Ueberpruefung an den Cert-Server und =20
reicht nach dem "ok" die Verbindung an den Datenbankserver weiter. =20
Einen dazwischenliegenden AppServer zur Bearbeitung der Abfragen etc. =20=

wuerden wir gerne vermeiden, da es sich ausschliesslich um =20
unabhaengige simple Such- (Lese-) und Schreibprozesse handelt, die =20
einfach abhandelbar sind und die eigentliche Berechnung auf den =20
Clients erfolgt.
Cert-Server:
Hier sind die Zertifikate gespeichert und hier werden die abgefragten =20=

Zertifikate auf ihre Gueltigkeit hin ueberprueft. Hier erfolgt auch =20
die Gruppen-Zuordnung (dienststellenweise) der einzelnen Zertifikate, =20=

und hier wird auch bestaetigt, ob es sich um ein "normales" =20
Zertifikat handelt oder um einen "Masterkey". Diese Information wird =20
an den Login-Server zurueckgegeben, der die Verbindung entsprechend =20
an den Datenbankserver weiterreicht.
Datenbankserver:
Dieser speichert alle Antrags- und Bescheiddaten, generiert taegliche =20=

"Berichte" als Ueberweisungsauftrag an die Buchhaltungssoftware =20
(anscheinend immer noch EDIFAKT), an die Krankenkassen (ebenfalls =20
anscheinend noch EDIFAKT), an die Rentenversicherer und die =20
Sozialaemter. Diese Berichte werden bereitgestellt und abgeholt.
Monatlich und jaehrlich werden diverse statistische Auswertungen =20
generiert.
Laufend werden die Abfragen des Frontends und der Sozialaemter, =20
Optionskommunen, Rentenversicherer ("Statusabfragen") beantwortet =20
sowie die Neuantraege und Aenderungen bestehender Antraege =20
gespeichert. Fuer die Sozialaemter, Optionskommunen und =20
Rentenversicherer muss ein wohldefiniertes Abfrage-Interface =20
bereitgestellt werden, das exakt die Funktionalitaet der =20
Statusabfrage abbildet und in andere Software einfach implementiert =20
werden kann.

Fuer Berichte, Statistiken und Wartungsarbeiten stehen die Naechte, =20
Feiertage und Wochenenden zur Verfuegung, sodass diese nicht waehrend =20=

des laufenden Betriebes zusaetzliche Last oder Ausfallzeit erzeugen.

Soweit bisher, mit der Bitte um Ergaenzungen

Gruss

Gottwalt=

Am 14.06.2006 um 16:55 schrieb Guido Seifert:

>> Das waere auch bei meiner Variante so. Allerdings waere hier das
>> Passwort beim Login-Server gespeichert.
>
> Kurze Zusammenfassung: Nein, du schreibst kein Unfug. Speicherung auf
> dem Server geht natuerlich. Ich hatte diese Methode nicht in Betracht
> gezogen, da man dann evtl. Probleme mit der geforderten Anonymitaet  
> des
> Sachbearbeiters haette.

Nein. Nur der Login-Server kennt das Passwort, der Zertifikatsserver  
den Schluessel. Somit ist das wieder wunderschoen sortiert. Und das  
ganze Spiel auf einem netten kleinen Server bei Holger im Wohnzimmer...

Gruss

Gottwalt

Hallo Liste,

gerade schickte ich eine explizite Einladung zur Zusammenarbeit an  
Holger Scherer
http://www.holgerscherer.de/

Hoffentlich laesst er sich zur Zusammenarbeit ueberreden...

Gruss

Gottwalt

> Das waere auch bei meiner Variante so. Allerdings waere hier das  
> Passwort beim Login-Server gespeichert.

Kurze Zusammenfassung: Nein, du schreibst kein Unfug. Speicherung auf 
dem Server geht natuerlich. Ich hatte diese Methode nicht in Betracht 
gezogen, da man dann evtl. Probleme mit der geforderten Anonymitaet des 
Sachbearbeiters haette. Mit meiner Methode sieht der Server nicht, wer 
mit ihm arbeitet. Nur aus welcher Gruppe der Zugriff kommt. Bekommt man 
vermutlich auch mit Passwoertern auf dem Server irgendwie hin, ist aber 
irgendwie bedenklich, wenn wir einerseits irgendwo ein Zugangslogging 
brauchen, andererseits eingehende Daten extra filtern muessen, um die 
Personalraete zufrieden zu stellen. Also besser erst gar nicht 
entsprechende Daten sammeln.

> Oder so. Deine Version ist eigentlich die bessere.

Danke :-)

> p.s.: Warum ich keine Umlaute verwende? Aller Codierung zum Trotz  
> zerhaut es mir die Umlaute doch immer wieder, wenn ich die Mails mit  
> pine auf dem Server lese... und dann sehe ich nur Fragezeichen...

Ich habe gar keine Umlaute. Als Programmierer kann man sich mit einer 
deutschen Tastatur schon frueh in einem Spezialzentrum fuer 
Sehenenscheidentzuendungen ein Zimmer mieten. :-)

Gruesse,
Guido

> Und jetzt habe ich doch selbst die Idee: Beim ersten Login gibt der  
> Anwender ein frei waehlbares Passwort ein. Dadurch wird der  
> Schluessel freigeschaltet. Dieses Passwort (das mindestens ein  
> Zeichen sein muss, mehr ist gar nicht zwingend notwendig) wird ab da  
> immer abgefragt, wenn er sich authentizieren muss. Und wird somit  
> Bestandteil des Schluessels.
> 
> Also: Der Schluessel bleibt unveraendert. Aber er ist nur verwendbar,  
> wenn man zusaetzlich in der Applikation das "Passwort" eingibt.
> Das ist dann ebensoviel Schutz wie bei der ec-Karte.

Aber wo steht das Passwort? Doch irgendwo auf dem Schluesselmedium? In 
der Schwierigkeit der Implementation sehe ich nicht viel Unterschied, ob 
irgendwo beim ersten Login ein Schluessel auf die Diskette geschrieben wird, 
oder ob mit einem Schluessel etwas auf dieser Diskette verschluesselt 
wird. In diesem speziellen Fall allerdings mit einem symmetrischen 
Verfahren.

In der Anwendung sehe ich bei der 'Passwort irgendwo auf 
dem Medium' die Gefahr, dass jemand diesen Schluessel einfach 
zuruecksetzt und sich ein neues Passwort geben laesst. Da wir open 
source sind, waere das ueberhaupt kein Problem. 

Oder soll das Passwort im Client verwaltet werden? Dann waere der 
Mitarbeiter an seinen Arbeitsplatz gebunden. Wir haetten individuelle 
Daten in jedem Client. Muessten evtl. Backups vorsehen.

Ich denke das freischalten beim ersten Login ist die richtige Idee, aber 
ich denke das Freischalten sollte durch das Verschluesseln des 
Schluessels mit einem vom Mitarbeiter frei zu waehlenden Passwort 
geschehen. Ein unverschluesselter Schluessel ist ungueltig. Das Passwort 
wuerde nirgendwo gespeichert werden, wenn es vergessen wird, muss der 
Mitarbeiter sich halt ein neues Schluesselmedium geben lassen.

Das alles kann ganz normal an einem Arbeitsplatz passieren. Wird ein 
neues Schluesselmedium eingelegt, uebernimmt eine Routine im Client das 
fertigstellen. Danach ist das Schluesselmedium 'finalisiert' und nur 
noch fuer den Mitarbeiter brauchbar, der das Passwort eingegeben hat und 
kennt.

Schluessel, schluessel, schluessel. Ich kaufe ein 'ue' ;-)

Gruesse,
Guido

Am 14.06.2006 um 13:36 schrieb Guido Seifert:

>> Du beschreibst exakt das, was durch SmartCards mit SmartCard-Reader
>> und PIN gemacht wird. Nur: Wie macht man diese Erst-Aktivierung? Da
>> benoetigte man ja schreibenden Zugriff aufs Schluesselmedium? Oder
>> als Ergaenzung zur Signatur, quasi als "Salz", das beim ersten Login
>> mituebertragen wird?
>>
>
> Ja, schon bei einer CDROM waere das problematisch. Es standen aber  
> auch
> Disketten + USB-Sticks als Schluesselmedien zur Diskussion. Wie
> verhindert man da das Schreiben ueberhaupt? Sind WORM-Systeme fuer uns
> ueberhaupt in 'Budget'? Ansonsten vielleicht ein spezieller Client  
> im Buero
> des Personalrates, der bereitet das Medium wie auch immer vor, der
> Mitarbeiter 'finalisiert' es unbeobachtet . Danach kann man zwar  
> weiterhin
> drauf schreiben, wie gesagt, bei Disketten ist das kaum zu  
> verhindern, aber
> dann wird halt alles ungueltig und unbrauchbar.
>

Und jetzt habe ich doch selbst die Idee: Beim ersten Login gibt der  
Anwender ein frei waehlbares Passwort ein. Dadurch wird der  
Schluessel freigeschaltet. Dieses Passwort (das mindestens ein  
Zeichen sein muss, mehr ist gar nicht zwingend notwendig) wird ab da  
immer abgefragt, wenn er sich authentizieren muss. Und wird somit  
Bestandteil des Schluessels.

Also: Der Schluessel bleibt unveraendert. Aber er ist nur verwendbar,  
wenn man zusaetzlich in der Applikation das "Passwort" eingibt.
Das ist dann ebensoviel Schutz wie bei der ec-Karte.

Gruss

Gottwalt

> Du beschreibst exakt das, was durch SmartCards mit SmartCard-Reader  
> und PIN gemacht wird. Nur: Wie macht man diese Erst-Aktivierung? Da  
> benoetigte man ja schreibenden Zugriff aufs Schluesselmedium? Oder  
> als Ergaenzung zur Signatur, quasi als "Salz", das beim ersten Login  
> mituebertragen wird?

Ja, schon bei einer CDROM waere das problematisch. Es standen aber auch 
Disketten + USB-Sticks als Schluesselmedien zur Diskussion. Wie 
verhindert man da das Schreiben ueberhaupt? Sind WORM-Systeme fuer uns 
ueberhaupt in 'Budget'? Ansonsten vielleicht ein spezieller Client im Buero 
des Personalrates, der bereitet das Medium wie auch immer vor, der 
Mitarbeiter 'finalisiert' es unbeobachtet . Danach kann man zwar weiterhin 
drauf schreiben, wie gesagt, bei Disketten ist das kaum zu verhindern, aber 
dann wird halt alles ungueltig und unbrauchbar.

Gruesse,
Guido

> Rechteverwaltung. Und deshalb lege ich so viel Wert darauf, dass der  
> Software-Betreiber nur unter Mitwirkung des Personalrates an Namen  
> von Zertifikatsinhabern kommen kann und ansonsten Zugriffe zwar  
> zertifiziert aber voellig anonym geloggt werden.

Wie ist dieser Vorschlag. Der Empfaenger bekommt ein Medium mit einem 
Schluessel drauf, der nur das Amt identifiziert. Vor mir aus auch 
Abteilung oder jede noch so kleine Gruppe, aber gerade _nicht_ ein 
Individuum. Dieser Schluessel ist ein Rohschluessel, der noch unbrauchar 
ist. Der Mitarbeiter individualisiert selbstaendig seinen Schluessel mit 
seinem Passwort. Danach kann dieser Schluessel benutzt werden, aber nur 
in Verbindung mit diesem Passwort, d.h. nur von diesem einem 
Mitarbeiter. Das Entschluesseln des eigentlichen Schluessels, der fuer 
den Server notwendig ist, uebernimmt das Client-Programm, aber ohne Daten zu 
loggen, die die Zugriffe auf den Server wieder individualisierbar 
machen. Auf diese Weise hat jeder Mitarbeiter einen individuellen 
Schluessen. Wenn dieser Schluessel geklaut wird, kann keiner was damit 
anfangen, aber der Zugriff auf den Server erfolgt anonym.

> 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

Am 13.06.2006 um 23:15 schrieb b1sp:

> On Tue, 13 Jun 2006 21:25:54 +0200, Gottwalt Thiersch wrote
>> Ich waere froh, wenn man auf SmartCard-Reader lokal verzichten
>> koennte. Ich waere wirklich gerne bereit, die zusaetzlichen
>> Sicherheitsluecken in kauf zu nehmen, die man durch Zertifikate auf
>> anderen Datentraegern sich einhandelt. Der Vorteil waere, dass
>> A2Open  nicht darauf angewiesen waere, dass irgendwelche
>> zusaetzliche  Hardware angeschlossen und eingerichtet/installiert
>> werden muss. Deshalb waere ich sehr sehr weitgehend tolerant in
>> dieser Beziehung.  Einzige Bedingung: Irgendein externes,
>>  schreibgeschuetztes Medium.
>
> Kann ich von der Kostensicht her gut verstehen. Zumal die Key-
> boards mit integrierten Kartenlesern nun wirklich nicht in die
> Kategorie Sonderangebote fallen. Externe Reader mit Keypad sind
> da deutlich guenstiger.

A2Open hat ebenso wie A2LL KEINERLEI Mitspracherecht bei der lokal =20
eingesetzten Hardware.
Also bleibt keine andere Moeglichkeit als die Verwendung "gaengiger" =20
Speichermedien. Im Zweifelsfall tatsaechlich serielle oder USB-Dongles.

> Ansonsten muessten in jeder Dienststelle eine ausreichende Anzahl
> an Reserverzertifikaten zur Verfuegung stehen...

Genau dies ist notwendig. Man koennte sich auch noch folgendes =20
Scenario vorstellen: Mitarbeiter kommt zum Personalrat, erhaelt =20
seinen Schluessel, Personalrat traegt zur Schluesselnummer den =20
Mitarbeiternamen ein, der Mitarbeiter unterschreibt, und der =20
Personalrat meldet nun mit einem "Anmeldeschluessel" den =20
Mitarbeiterschluessel an. Dann koennten beliebig viele =20
Vorratsschluessel bereitliegen, die man aber erst nach Freischaltung =20
nutzen kann. Ich halte das aber fuer zu aufwendig. Man stelle sich =20
eine Behoerde mit z. B. 300 Sachbearbeitern vor, die Schluessel =20
brauchen...

> Die Moeglichkeit der sofortigen Sperrung bei Bekanntwerden des
> Verlusts bieten beide Varianten. Alternativ koennte dies auch mit
> anderen Zertifikatstraegern durchgefuehrt werden. Dafuer muessten
> dann am sinnvollsten Datentraeger der Kategorie Write once, Read
> many eingesetzt werden.

Es sind zwei Probleme:
1. Wie wird der Zertifikatstraeger vom PC gelesen?
2. Wieviel kostet der einzelne Zertifkatstraeger und die fuers Lesen =20
benoetigte Infrastruktur?

>> Ja. Und wenn man das Ganze tatsaechlich -wie angedacht- mit IBM im
>> Ruecken realisiert, dann ist das Ganze ein zOS-Server, wo jede
>> dieser  Aufgaben voellig von den anderen abgeschottet ablaufen kann.
>> Und mit  zwanzigtausend gleichzeitigen Zugriffen gibts dann auch
>> kein Problem.
>
> Kenne ich irgendwo her ;-)
> Das in meiner vorigen Antwort beschriebene Projekt laeuft auf zwei
> P-Series.

Ich wuerde gerne NICHT AIX einsetzen, lieber iOS oder zOS. Aber das =20
ist reine persoenliche Vorliebe (die sich natuerlich auch mit =20
Argumenten untermauern laesst, die allerdings fuer den Einsatzzweck =20
irrelevant sind).

> Die Behoerde hat eine gewisse Affinitaet hin zu Big Blue...
> Zusaetzlich laufen da zur Abschottung der Systeme untereinander
> a) die Systeme je nach Status und Aufgabengebiet in getrennten
> Subnetzen/VLANs, die
> b) durch einen HW-Paketfilter mit IDS/IPS/AV-Scanner, etc. vonein-
> ander abgeschottet sind.

Voelliger Overkill fuers geplante Projekt. Jetzt steht dort EINE Sun =20
Enterprise mit Informix als Datenbankserver im einen Rechenzentrum, =20
einige dutzend x86-Linux-Server als Webserver und ebenso einige =20
dutzend x86-Windows-Server als AppServer im anderen Rechenzentrum. =20
Und lediglich Administrationszugriffe duerfen nur aus dem eigenen =20
Subnetz erfolgen. Ansonsten werden weder Zugriffe geloggt noch sonst =20
irgendwie Rechte vergeben und verwaltet.

> Eine vergleichbare Umgebung kommt in unserem Firmen-RZ zum Einsatz:
> Da dort unterschiedliche Kunden gehostet werden, waeren die defini-
> tiv nicht gluecklich, wenn ein anderer auf die eigenen Daten/Server
> zugreifen koennte. Selbst die Server eines einzelnen Kunden liegen
> in voneinander abgeschotteten, nach Aufgabengebiet getrennten Be-
> reichen.

Wie gesagt: Overkill. Wir brauchen keine 24/7-Redundanz, sondern =20
10/5. Wartung kann nachts und am Wochenende erfolgen, und wenn der =20
zentrale Server mal fuer drei Stunden unten ist, dann geht zwar alles =20=

nur provisorisch, aber es geht immerhin.

>> Das waere immer noch erheblich sicherer, wenn diese Zugriffe
>> ueberhaupt geloggt und autorisiert waeren, als beim derzeitigen =20
>> System.
>
> Bisher keinerlei Kontrolle? Und das haben die allen Ernstes akzep-
> tiert? Ist ja schlimmer wie bei Troll-Collect! Da het die T-Systems
> ja wenigstens noch beim Betrieb strikte Aufgabentrennung. Soviel
> ich wei=DF, gilt das auch f=FCr den Datenzugriff/-Auswertung...

Ja ja. Das Problem war: Macht man Rechte-Management und loggt man =20
Zugriffe, kann man darueber feststellen, welcher Mitarbeiter wann was =20=

gemacht hat. Aber das erlaubt der Personalrat nicht, denn darueber =20
koennte man die Qualitaet und Quantitaet der Arbeit einzelner =20
Mitarbeiter bewerten. Auch koennte man einzelne Mitarbeiter fuer ihre =20=

Fehler zur Rechenschaft ziehen.
Ausserdem: Da ja ARGEn, Optionskommunen und Arbeitsagenturen auf die =20
Daten zugreifen muessen, haette man allein mit der Verwaltung der =20
Beantragung, Erteilung und Loeschung von Accounts einen riesigen =20
Wasserkopf beschaeftigt. Loggt man aber ohne Benutzerverwaltung, dann =20=

kommt unter Umstaenden jemand faelschlich in Verdacht, der gar nicht =20
an seinem Arbeitsplatz sass, waehrend sein Arbeitsplatz von einem =20
Boesewicht missbraucht wurde.
Also, das Problem war: Eine Rechteverwaltung war verwaltungstechnisch =20=

zu aufwendig, die Bedenken des Personalrates nicht auszuraeumen, und =20
ein Logging der Zugriffe ohne Rechteverwaltung waere vom Personalrat =20
ebenfalls nicht genehmigt worden. Aus den angefuehrten Gruenden. =20
Deshalb verzichtet man lieber gaenzlich auf jegliche =20
Rechteverwaltung. Und deshalb lege ich so viel Wert darauf, dass der =20
Software-Betreiber nur unter Mitwirkung des Personalrates an Namen =20
von Zertifikatsinhabern kommen kann und ansonsten Zugriffe zwar =20
zertifiziert aber voellig anonym geloggt werden.

>> Das hatten wir bereits besprochen: Beim Login erfolgt der
>> Versionsabgleich. Sind Updates vorhanden, so koennen diese
>> "huckepack" mit uebertragen werden ueber die sowieso stehende
>> Verbindung. Und da Updates in den allermeisten Faellen neue
>> Regelungen abbilden, die dank neuer Gesetze oder Verordnungen
>> implementiert wurden, koennen sie sogar im voraus uebertragen werden,
>>   mit entsprechendem Datumsvermerk ("wirksam ab 1.9.2007").
>
> Klingt gut, wuerde ich sagen. Im Prinzip bedeuten neue Verw.Ver.Ord.
> und Gesetze ja nichts anderes als Anpassungen/Erweiterungen von
> einzelnen Logikteilen in der Applikation und duerfte somit halb-
> wegs gut realisierbar sein. Bei umfangreichen Neuregelungen sind
> ggf. mehrere Logikteile neu/anders miteinander zu verknuepfen und/
> oder neue Teile hinzuzufuegen.

Ja.

Gruss

Gottwalt=

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

On Tue, 13 Jun 2006 21:25:54 +0200, Gottwalt Thiersch wrote
> Ich waere froh, wenn man auf SmartCard-Reader lokal verzichten  
> koennte. Ich waere wirklich gerne bereit, die zusaetzlichen  
> Sicherheitsluecken in kauf zu nehmen, die man durch Zertifikate auf  
> anderen Datentraegern sich einhandelt. Der Vorteil waere, dass 
> A2Open  nicht darauf angewiesen waere, dass irgendwelche 
> zusaetzliche  Hardware angeschlossen und eingerichtet/installiert 
> werden muss. Deshalb waere ich sehr sehr weitgehend tolerant in 
> dieser Beziehung.  Einzige Bedingung: Irgendein externes,
>  schreibgeschuetztes Medium.

Kann ich von der Kostensicht her gut verstehen. Zumal die Key-
boards mit integrierten Kartenlesern nun wirklich nicht in die
Kategorie Sonderangebote fallen. Externe Reader mit Keypad sind
da deutlich guenstiger.
Die von mir beschriebene dezentrale Lösung haette vom Verwal-
tungsaufwand nach dem Rollout her auch ihre Vorteile: Verliert
ein Mitarbeiter seine Karte oder ist sie defekt, kann einfach
vor Ort ein neues Zertifikat online beantragt und auch online
freigegeben werden. Somit waere der MA recht kurzfristig wieder
arbeitsfähig.
Ansonsten muessten in jeder Dienststelle eine ausreichende Anzahl
an Reserverzertifikaten zur Verfuegung stehen...
Die Moeglichkeit der sofortigen Sperrung bei Bekanntwerden des
Verlusts bieten beide Varianten. Alternativ koennte dies auch mit
anderen Zertifikatstraegern durchgefuehrt werden. Dafuer muessten
dann am sinnvollsten Datentraeger der Kategorie Write once, Read
many eingesetzt werden.

> Ja. Und wenn man das Ganze tatsaechlich -wie angedacht- mit IBM im  
> Ruecken realisiert, dann ist das Ganze ein zOS-Server, wo jede 
> dieser  Aufgaben voellig von den anderen abgeschottet ablaufen kann. 
> Und mit  zwanzigtausend gleichzeitigen Zugriffen gibts dann auch 
> kein Problem.

Kenne ich irgendwo her ;-)
Das in meiner vorigen Antwort beschriebene Projekt laeuft auf zwei
P-Series. Die Behoerde hat eine gewisse Affinitaet hin zu Big Blue...
Zusaetzlich laufen da zur Abschottung der Systeme untereinander
a) die Systeme je nach Status und Aufgabengebiet in getrennten 
Subnetzen/VLANs, die
b) durch einen HW-Paketfilter mit IDS/IPS/AV-Scanner, etc. vonein-
ander abgeschottet sind.

Eine vergleichbare Umgebung kommt in unserem Firmen-RZ zum Einsatz:
Da dort unterschiedliche Kunden gehostet werden, waeren die defini-
tiv nicht gluecklich, wenn ein anderer auf die eigenen Daten/Server
zugreifen koennte. Selbst die Server eines einzelnen Kunden liegen
in voneinander abgeschotteten, nach Aufgabengebiet getrennten Be-
reichen.

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

Bisher keinerlei Kontrolle? Und das haben die allen Ernstes akzep-
tiert? Ist ja schlimmer wie bei Troll-Collect! Da het die T-Systems
ja wenigstens noch beim Betrieb strikte Aufgabentrennung. Soviel
ich weiß, gilt das auch für den Datenzugriff/-Auswertung...

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

Klingt gut, wuerde ich sagen. Im Prinzip bedeuten neue Verw.Ver.Ord.
und Gesetze ja nichts anderes als Anpassungen/Erweiterungen von 
einzelnen Logikteilen in der Applikation und duerfte somit halb-
wegs gut realisierbar sein. Bei umfangreichen Neuregelungen sind
ggf. mehrere Logikteile neu/anders miteinander zu verknuepfen und/
oder neue Teile hinzuzufuegen.

Gruss,

Burkhardt

> 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

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=

Hallo Liste,

On Tue, 13 Jun 2006 13:55:57 +0200, Gottwalt Thiersch wrote
> [Zugriffskontrolle und Zugriffsbeschraenkungen]

Von der Grundidee her nicht übel. 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äuft als Webappli-
kation mit Client-SSL-Zertifikaten, die auf Smart-Cards gespeichert
werden. Die primäre Authentifizierung erfolgt dabei über einen 
Apache Webserver, der primär die verschlüsselte Anbindung und
sekundär die erste Authentifizierung der Client-Zertifikate auf
ihre Gültigkeit und die richtige Zertifizierungsstelle hin bereit-
stellt.
Die eigentliche Applikationslogik und Zuordnung der Rechte erfolgt
bei dem Projekt über einen Java-Applikationserver, der sich die
Rechte des jeweiligen Users aus einem LDAP-Server zieht.
Aktuell erfordert dieses Projekt, daß die User sich selbst ein
Zertifikat erstellen müssen und dieses bei der Zertifizierungs-
stelle des Betreibers zum Signieren einreichen. Anschließend muß
das signierte Zertifikat per Smart-Card-Writer auf die Karte
des Nutzers übertragen werden.

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. 

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.

> [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... ;-)

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

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

Gruß,
Burkhardt

Ich habe den Beitrag von Gottwalt schon vor Stunden akzeptiert, aber zu 
mir ist er danach noch nicht angekommen, Auch stimmt noch etwas mit dem 
Listenarchiv nicht. Da sind zwei Messages drin, aber es gibt wohl ein 
Problem mit dem Server. Naja, wird bei SF eigentlich recht flott 
behoben. Diese Mail ist nur zum anfaenglichen 'Hallo' und um die 
Verbindung zu testen da. 

Gruesse,
Guido

Hallo Liste,

ein paar grundsaetzliche Ueberlegungen und Anmerkungen zu Burkhardt:

Wir sind inzwischen nicht mehr stehengeblieben bei dem Gedanken an  
lokale Server. Und das, obwohl dort die von mir so geschaetzten  
"Pralinenschachteln" (also simple Minirechner mit Flash-Laufwerken,  
ohne aktive Kuehlung etc. mit Via-Chipsatz) ausgereicht haetten,  
gerade auch, weil die Via-Loesung die ganze Verschluesselung in  
Hardware geliefert haette. Da waere dann ein fertig konfigurierter  
Server etwa bei 500 EUR gelegen, aber das wenigstens 700 mal macht  
immerhin auch 350000 EUR zzgl. Wartung etc., das ist schlicht zu viel.

Zur Zugriffskontrolle auf den zentralen Datenbankserver hatten wir  
bisher jetzt folgende Ueberlegung:
Es werden Schluessel ausgegeben, wahlweise (je nach installierter  
Hardware vor Ort) auf Diskette, CD oder USB-Stick. Zugriff ist immer  
nur moeglich mit lokal zugreifbarem Schluessel. Da bekommen wir im  
Ernstfall Probleme, wenn irgendwann in einer Dienststelle  
tatsaechlich keine externen Laufwerke mehr ansprechbar sein sollten.  
Dann muessen wir zwangslaeufig auf USB- oder serielle oder ps2- 
Dongles ausweichen, die zwischen Tastaturkabel und Rechner gesteckt  
werden. Auch die kosten nicht die Welt.

Die Schluessel sind eindeutig einer Dienststelle zugeordnet, und jede  
Dienststelle erhaelt zwei "Masterschluessel". Die Schluessel werden  
anbieterseitig nicht Personen zugeordnet (wichtig, da eine indirekte  
Arbeitskontrolle bei vielen Mitarbeitern des oeffentlichen Dienstes  
nicht zulaessig ist), aber die Schluessel werden gegen Unterschrift  
und Pfand durch den Personalrat ausgegeben. Dadurch ist indirekt doch  
eine (auch strafrechtliche) Ahndung bei missbraeuchlichen Zugriffen  
moeglich. Abhandengekommene Schluessel werden zentral gesperrt.

Zugriffsbeschraenkungen:
Schreibenden Zugriff auf einen Datensatz erhaelt ohne irgendwelche  
Einschraenkungen immer der Ersteller (also der mit dem  
Erstellerschluessel autorisierte Rechner).
Vollstaendigen lesenden Zugriff erhalten alle mit einem Schluessel  
der selben Dienststelle autorisierten Rechner. Will einer dieser  
Rechner schreibenden Zugriff, so ist dieser extra anzufordern  
(lediglich ein Klick, aber immerhin eine erste Schwelle). Jeder  
lesende und schreibende Zugriff wird geloggt.

Mitarbeiter anderer Dienststellen erhalten lediglich lesenden Zugriff  
auf die Stammdaten aller Antragsteller (also: Name, Vorname,  
Geburtsname, Geburtsort, vollstaendige Anschrift, Eltern,  
Rentenversicherungsnummer und betreuende Dienststelle). Wollen sie  
weitergehenden Zugriff (z. B. weil jemand dorthin gezogen ist), so  
erhalten sie diesen entweder, indem sie ihn beim Ersteller des  
Datensatzes anfordern (der Ersteller erhaelt eine Nachricht  
"Mitarbeiter xyz der Dienststelle nop will die Bearbeitung des  
Datensatzes von Frau abc uebernehmen. Genehmigen?") oder indem sie  
sich den Zugriff durch den "Masterkey", der zweifach in jeder  
Dienststelle vorliegt. Ab dem Moment wird der entsprechende Antrag  
vollstaendig der neuen Dienststelle zugeordnet, die alte Dienststelle  
hat nun nur noch lesenden Zugriff auf die Stammdaten.

Dies ist keine lueckenlose Zugriffs- und Missbrauchsabsicherung, aber  
eine pragmatische Erschwernis, die es verhindern kann, dass tausende  
Datensaetze illegal genutzt werden. Einfach, weil das zu muehsam  
waere. Und es ermoeglicht im Ernstfall die Ahndung strafrechtlich  
relevanten Missbrauchs.

Zur Software an sich: Zur Erfassung werden im Grunde stur die Daten  
des Antragsbogens erfasst. Dabei wird zu Anfang bei jeder Person, die  
im Antrag steht, ein Datenabgleich durchgefuehrt, um sicherzustellen,  
dass Kinder nicht bei beiden geschiedenen Eltern der  
Bedarfsgemeinschaft angerechnet werden etc.
Dann werden stur die Daten erfasst, bei den einzelnen entsprechenden  
Feldern wird vermerkt, in welcher Form die entsprechenden Daten  
nachgewiesen wurden (z. B. Miete gem. Mietvertrag,  
Unterhaltsverpflichtung gem. duesseldorfer Tabelle bzw. gem. Urteil,  
Mehrbedarf gem. aerztlichem Attest etc. pp.). Und immer der Vermerk,  
ob das Nachweis-Dokument als Kopie der Akte beigefuegt wurde. Bei  
jedem einzelnen Punkt koennen die relevanten Gesetzes- und  
Verfahrensanordnungstexte aufgerufen werden (die muessen also jeweils  
hinterlegt sein) und zum Schluss wird das Ergebnis berechnet. Daraus  
wird ein vorlaeufiger Bescheid erstellt und die gesamten erfassten  
Daten werden auf dem zentralen Server gespeichert.
Was bietet das Frontend noch?
Die Eingabe von Aenderungen mit dem Datum, ab wann (und bis wann) die  
Aenderung wirksam wird (z. B. Zuverdienst, Heirat, Auszug der Kinder  
usw.).
Verwaltung von Bar-, Ueberweisungs- oder Scheckvorschuessen.
Verwaltung von Rueckforderungen, Kuerzungen, Nachzahlungen.
Messaging zwischen den Mitarbeitern und den Dienststellen zu den  
einzelnen Faellen (wie oben schon beschrieben z. B. bei der  
Uebernahme eines Falles)
Darstellung eines Falles im Verlauf (also: Historie eines  
Antragstellers, z. B.).
Anmerkungen und Notizen zum jeweiligen Fall.

Was macht das Backend?
Erfassung und Speicherung der eingegebenen Faelle
Abgleich mit den Rentenversicherungen als Kontrolle wg. paralleler  
meldepflichtiger Beschaeftigung
Abgleich mit den Sozialaemtern (sind beides wohldefinierte  
Schnittstellen, laeuft jeweils ueber die Rentenversicherungsnummer)
Ausloesung der Ueberweisungen (taeglicher "Bericht", der an die  
Buchhaltungssoftware geleitet wird, wohldefinierte Schnittstelle)
Statistik
Historie der einzelnen Verlaeufe
regelmaessiger Bericht an die Rentenversicherungstraeger und  
Krankenkassen

Im Grunde war es das.

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.

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. Das  
Programm an sich laeuft und rechnet dann lokal, die Ergebnisse werden  
zentral gespeichert und zentral verwaltet.
Voraussetzen koennen wir Rechner mit Windows NT ab NT 4 bis NT 5.1  
mit Netzwerkanschluss, entweder ueber Internet oder ueber das  
separate Arbeitsamtsnetz. Es muessen maximal zwanzigtausend Clients  
lesenden Zugriff auf den zentralen Datenbankserver erhalten (ARGEn,  
Dienststellen, Optionskommunen) zum Abgleich, und es existieren  
einige explizite Abfrage- bzw. Datenuebergabeschnittstellen fuer  
andere Software (Rentenversicherungen, Krankenkassen, Sozialaemter,  
Buchhaltungssoftware).

Ist das soweit klar und vernuenftig?

Gruss

Gottwalt

Hallo Liste,

ein paar grundsaetzliche Ueberlegungen und Anmerkungen zu Burkhardt: