Re: [A2open-diskussion] A2Open

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

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=