Re: [A2open-diskussion] A2Open

[b1sp <b1...@he...>]

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