[Allegro] Sicherheit(?) im Register 11

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Liste,

Herr Eversberg bat mich, diese Frage hier zu diskutieren. Konkreter Anlass
war, dass ich ein Workaround fuer das seinerzeit in acon noch nicht
implementierte "family" suchte, und dabei auf folgendes Verhalten stiess:

>>>
Anders als find kann qrix nicht mit der Registerbzeichnung "|;" umgehen. Auch
nicht ueber den Umweg eines symbolischen Registernamens für Register 11!!!

            (< http://bugzilla.gymel.com/show_bug.cgi?id=538 >)
<<<

Konkret betrifft das den Fall access < 3, und auch nur dann, wenn acon
die Datenbank nicht direkt ueber Schalter -b / -d mitgeteilt bekommt,
sondern sich (wie im Avanti-Kontext) Pfade und Berechtigungen ueber
avanti.con[f] zusammensucht.

Das derzeitige Verhalten, also das scheitern gewisser Zugriffe auf
Register 11 hat seine Wurzeln in der Einfuehrung von Register 10 und
11 fuer ORDER (10) und ALF (11): Personenbezogene Daten sollen damit
besser geschuetzt sein.

Meine Argumente dagegen sind:

* Personenbezogene Daten koennen wirksam nur so geschuetzt werden,
  dass man sie nicht sammelt (Stichwort Ausleihistorie)

* Personenbezogene Daten muessen insbesondere auch vor neugierigen
  Bearbeitern geschuetzt werden, und vor neugierigen Admins, Kopplung
  an access-Level ist also etwas fragwuerdig

* allegro-Datenbanken (die von PRESTO und a99 oder alcarta genutzt werden
  sollen) sind naturgemaess allen Leseberechtigten auch mit Nicht-
  allegro-Methoden zugaenglich, einen Schutz gegen "unberechtigte"
  Nutzung gibt es nicht

* Durch Deklaration eines symbolischen Registers in der Indexparameterdatei
  ist auch mit niedrigen Access-Werten der Zugriff auf Register 11
  moeglich, seit einigen Versionen werden die auch fuer den Index
  angeboten

* Register 11 enthaelt nicht unbedingt personenbezogene Daten, im
  aktuellen Fall waren es sortierfaehig aufbereitete Identnummern

* Die Datensaetze, in denen personenbezogene Daten stecken, sind
  typischerweise auch ueber Schluessel zugreifbar, die nicht im
  Register 11 wohnen, oder ueber Volltextsuchen, oder durch
  Selektion von Satznummern (-bereichen)

* "find" kann zugreifen, die Frage ist, warum das Auflisten der
  Registertreffer mit qrix schutzwuerdiger sein soll als das
  direkte Bilden der Ergebnismenge mit allen Saetzen und der darin
  enthaltenen Information

* Im avanti- (oder auch a30-) Kontext sind die Daten tendenziell
  wesentlich sicherer aufgehoben als unter PRESTO/a99/alcarta:

  a) Die Daten selbst sind ueblicherweise durch restriktivere
     Rechtevergabe auf Dateisystemebene vor menschlichen Benutzern
     der Maschine geschuetzt (und da "Server" sind noch nicht einmal
     alle Bearbeiter der Datenbank legitime Nutzer der Maschine)

  b) Die Job- und Parameterdateien, ueber die der Zugriff erfolgt,
     sind vorgegeben und liegen ebenfalls in einem geschuetzten
     Bereich (des Webservers) [Ich habe jetzt allerdings nicht
     ueberprueft, ob a30 so promisk wie phpac ist und dem Admin
     Konfigurationsaufwand "spart", indem es alle irgendwie
     deklarierten Register aus den Tiefen der .cPI-Datei herbei-
     schaufelt und dem Endbenutzer als recherchefaehiges Register
     andient]

  c) Datenbanken sind u.U. nur eine Kopie einer Produktionsdatenbank,
     und alle personenbezogenen Daten wurden beim Erstellen bereits
     anonymisiert

[Vom Design her finde ich, dass /avanti/ fuer die Auswertung der
avanti.conf zustaendig ist und anschliessend acon entsprechend
aufruft. acon hingegen sollte ueberhaupt keine Mechanismen kennen,
"&virtuelle Aufrufpfade" und "@angemeldete Benutzer von Datenbanken"
aus .conf-Dateien zu ziehen]

Zu diskutieren waere m.E.
- - wo nur scheinbare Sicherheit vorliegt, die deshalb (finde ich)
  besser ganz abzuschaffen waere

- - und wo wirkliche Sicherheit benoetigt wird, und mit welchen technischen
  Mitteln (etwa verschluesselten Indexeintraegen und Datensaetzen) diese
  tatsaechlich erzielt werden koennte.

Die Angelegenheit ist natuerlich durchaus vielschichtiger als hier
dargestellt, es geht ja nicht nur um personenbezogene Daten, sondern
auch um Vorkehrungen, gewisse Daten etwas gegen Veraenderung zu
schuetzen (etwa die kritischen Schluessel zum Hochzaehlen von
Generatoren), und ganz allgemein, wie man es organisiert, dass
Bearbeiter die fuer sie wichtigen Indexabschnitte angeboten bekommen
und diese nicht untergehen in der grossen Menge der fuer andere
Bearbeiter oder rein technisch vorgehaltenen Register (fuer OPACs
/braucht/ man oft allerhand Sonderregister mit aufbereiteten Schluesseln,
diese tauchen dann in "dbinfo" und im Find-Menu und auch im Pulldown-
Menue des Indexfensters auf und irritieren die Bearbeiter und Benutzer...)


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkuCdb4ACgkQYhMlmJ6W47N/2QP+O7Od15CCeG81B0bihCK+B1p6
r6PnYyclr8cljoYIVWy6ZEPBzWsAacBHfmirqcK6jXNaCNNMLWnVxkAW0opxYQxM
jTGFYbRQa+C/iQ5iugaHjs0WpCZOTaj0qlLZJIb/6O5ga056E9D4PGTq+jG/p/d3
BMXFlf+dqQka+lW+ffs=
=rht+
-----END PGP SIGNATURE-----