Das Notes Forum
Domino 9 und frühere Versionen => ND7: Entwicklung => Thema gestartet von: Mirko am 16.03.10 - 07:22:41
-
Guten Morgen liebe Helfer und alle die es werden wollen,
nachdem ich gestern den ganzen Tag hier gesucht habe, werde ich jetzt doch mal anfragen.
Unsere Personalabteilung wünscht sich eine Datenbank mit Mitarbeiterdaten und stellt mich damit vor zwei Probleme.
1.) Um das unbeabsichtigte Öffnen der DB zu vermeiden (wg. Protokolierung) soll das Notes-Passwort nochmals abgefragt werden (... ich weiß, es gibt genügend Beiträge über den Sinn)
2.) soll verhindert werden, dass die Daten in die Zwischenablage kopiert werden können (meiner Meinung nach kann jeder der Lesen kann auch abtippen, aber egal)
Also hat irgend jemand eine Idee oder einen Tip ???
-
1.) Um das unbeabsichtigte Öffnen der DB zu vermeiden (wg. Protokolierung) soll das Notes-Passwort nochmals abgefragt werden (... ich weiß, es gibt genügend Beiträge über den Sinn)
Nicht so einfach, da das Passwort nicht datenbank bezogen vergeben wird.
Evtl richt es aus, einen Dialog beim Öffnen der Datenbank anzuzeigen, in dem der User eine automatisch generieret Phrase eingeben muss, um zum Inhalt der Datenbank zu gelangen. Bricht er ab, wird die Datenbank geschlossen.
Geht er weiter, wird das protokolliert.
Leser- Autorenfelder sind in der Datenbank schon vorhanden, oder ?
2.) soll verhindert werden, dass die Daten in die Zwischenablage kopiert werden können (meiner Meinung nach kann jeder der Lesen kann auch abtippen, aber egal)
Sollte über das Feld $KeepPrivate=1 zu realisieren sein. Bin mir aber nicht sicher. Ausprobieren
-
Punkt 1
Wuerde ich ebenso machen wie Ulrich.
Jedoch frage ich mich auch noch, wenn nur bestimmte Personen die Db oeffnen duerfen, dann kannst Du das doch schoen ueber die ACL regeln.
Leser- und Autorenfelder sind hier fast schon ein MUSS.
Zusaetzlich waere noch zu ueberlegen, ob man noch mit verschluesselten Feldern arbeiten moechte.
Punkt 2
In den Eigenschaften der Texte und der Felder kannst Du doch angeben, dass diese nicht mit in die Zwischenablage kopiert werden duerfen.
Mit $KeepPrivate=1 wuerde ich ungern arbeiten, da hier schoene Nebeneffekte auftreten koennen.
(z.B. Dokument kann nicht gedruckt werden, bei der Replizierung bin ich mir nicht ganz sicher)
Andreas
-
Vielen Dank erst mal für die schnellen Antworten,
Das mit dem unbeabsichtigten Öffnen habe ich erst mal mit einen Button "Ja, ich will" gelöst. Nur wenn man den drückt, bekommt man dann den Button "DB öffnen" gezeigt, damit dann die Ansicht mit den Daten. Ich hatte auf irgend einen API-Befehl gehofft, mit dem man den Passwort-Dialog aufrufen kann und dann ein "Gut" oder "nicht gut" zurückbekommt.
Eine Eigenschaft der Felder die das Kopieren verhindert kann ich nirgends finden, nur in den Maskeneigenschaften den Punkt "Drucke/Weiterleiten/Kopieren deaktivieren". Aber das scheint nciht zu greifen, ich kann trotzdem den Texte eines Feldes markieren, dann Steuerung+C und schon läßt er sich in der Textverarbeitung einfügen :-:
Auch das so eigentlich verhinderte Drucken klappt prima. Oder spielt mir hier die lokale DB einen Streich, ich habe natürlich zum Test noch keine größeren Sicherheitseinstellungen gemacht.
Ansonsten ist das mit den Leser-Feldern und der ACL schon klar.
Das mit dem $KeepPrivate" werde ich mal testen. Allerdings war noch nicht die Rede davon, dass mal was ausgedruckt werden soll. Werde ich wohl noch mal nachfragen.
Viele Grüße
Mirko
-
Du möchtest auch eine konsistente ACL über alle Repliken erzwingen (ACL-Setting).
-
Jetzt habe ich noch mal mit einer Server-DB getestet:
ACL -> Konistente ACL erzwingen angehakt
Maske -> "Drucken/Weiterleiten/Kopieren deaktivieren" angehakt
Vorsichtshalber Client beendet und neu gestartet.
Dann kam die Erleuchtung: die Einstellungen greifen nur bei neu erstellten Dokumenten, die Maskeneigenschaft "Drucken/Weiterleiten/Kopieren deaktivieren" schreibt offensichtlich $KeepPrivate=1 in das Dokument, alles wie es sein soll :D
@ascabg
Wo finde ich diese Einstellung für die Felder?
Bleibt das Problem mit dem Passwort. Trotzdem Dank an alle, die geholfen haben.
Viele Grüße
Mirko
-
Bleibt das Problem mit dem Passwort.
Da wirst du um einen datenbank hook und C-API nicht herumkommen.
Hinterfrage mal bei euch Kosten / Nutzen. Das Zeugs muss entwickelt und getestet werden; zudem muss noch ein Stück Software auf die clients verteilt werden.
WAS soll genau damit erreicht werden?
-
Finden kannst Du diese Einstellung in den Eigenschaften des Feldes bzw. Textes.
Vorletzter Reiter (Hide When)
Hier kannst Du angeben, dass dieses Feld / dieser Text nicht mit in die Zwischenablage kopiert wird.
Jedoch glaube ich nicht, dass Du damit verhinden kannst, dass der Inhalt des betreffenden Feldes per Copy&Paste weiterverwendet werden kann.
Hierbei handelt es sich um eine Funktionalitaet des BS.
Andreas
-
@ Andreas
DANKE!!! Das war's, das habe ich aber irgendwie anders gedeutet. Man kann tatsächlich den "Abschnitt" anzeigen, aber nicht mit in die Zwischenablage kopieren. Toll.
@ Ulrich
Es soll sich jeder bewusst sein, dass Datenbankzugriffe ab diesem Punkt protokolliert werden. Zitat: " Damit diese Handlung bewußt und nicht aus Versehen geschieht..." Aber ich werde mal meine Lösung mit dem Button "Ja, ich will" vorstellen, mal sehen ob das reicht. Notfalls eben Abtippen eines Vorgabetextes.
Vielen Dank noch mal an alle.
Viele Grüße
Mirko
-
"Ja, ich will" vorstellen
Ich denke auch, dass ein aussagekräftiger Dialog hier zielführender ist, als eine simple Passwortabfrage.
Wie gesagt, ich würde einen Dialog bauen, der einen erklärenden text enthält und zudem ein Eingabefeld. Der User wird dann im Dialg aufgefordert, zum Weitermachen ein bestimmtes Wort in das Feld einzugeben. Das sollte meiner Meinung nach bewusst genug geschehen.
-
Hallo Ulrich,
jetzt muß ich hier doch noch mal nachhaken, ich habe gerade einen Klemmer ???
Um ein Wort einzutippen brauche ich ein Feld. Da das nicht auf einer Seite angelegt sein kann, brauche ich eine Maske, soweit hoffentlich richtig.
Wenn ich die dann aber schließe, werde ich gefragt ob ich die Änderungen speichern will. Kann ich das auch unterdrücken??? Oder muß ich auf einen Dialog ausweichen ?
Viele Grüße
Mirko
ps: Personalabteilung hat sich noch nicht entschieden :(
-
Hallo,
Fuege in Deine Maske ein Feld "SaveOptions" (editierbar) mit dem Wert "0" ein.
(siehe auch Designer-Hilfe mit dem Suchwort "reservierte Felder")
Feld sollte natuerlich versteckt sein.
Andreas
-
Vielen Dank,
so macht ein Forum Spaß.
Nach "Save" hatte ich ja in der Hilfe schon gesucht, aber die 857 Dokumente wollte ich nicht alle lesen. Wenn man "options" nicht weiß...
Aber ich werde mir jetzt mal alle reservierten Felder genauer ansehen.
Gemein ist aber, dass SaveOptions nur beim Steuern von Mail-Optionen erklärt wird.
Viele Grüße
Mirko
-
Mir scheint hier der komplette Ansatz falsch. Wie kommen Personen an diese (Personal-)Daten, die diese dann nicht auch kopieren dürften? Das sollte ja wohl nur die Personalabteilung sein. Bei derartigen Daten ein "he, wollen Sie wirklich ..:" zu bringen oder ein erneutes Passwort-Bingo - da läuft doch schon vorher etwas völlig schief.
Wenn Mirko hier weitere Informationen bringt, würde mich das Thema ggf. auch so interessieren, dass ich da antwort- und diskussionsseitig einsteigen würde.
Bernhard
-
Hallo Bernhard,
natürlich erkläre ich das mal ausführlich. Die Personaldaten werden ursprünglich in einem SAP-System gepflegt. Von dort holt sie die Datenbank via Java ab (wenn ich es hinbekomme ;) ) Nun sollen sie für das Katastrophen-Management einer begrenzten Nuteranzahl via Notes zugänglich gemacht werden. Diese Zugriffe sollen protokolliert werden und irgend wann auch auf ihre Notwendigkeit geprüft werden. Damit nun keiner der zugriffsberechtigten Nutzer die Datenbank unbeabsichtigt öffnet, soll das Notes-Kennwort geprüft werden. Das Passwort wäre der Personalabteilung wichtig, damit kein Unberechtigter an einem nicht gesperrten PC in die Daten sehen kann. Für mich ist derjenige, der seinen PC nicht sperrt, selbst schuld wenn er im Protokoll auftaucht. Inzwischen habe ich die Personalabteilung so weit, dass sie eine Lösung mit Captcha akzeptieren würden. Damit wäre das "bewußte Öffnen" der Datenbank sichergestellt.
Eigentlich will die Personalabteilung dann auch noch innerhalb der DB die Zugriffsrechte ändern, aber das werde ich blocken. Dafür haben wir eine Lösung mit einer anderen DB.
Ansonsten will ich es so gestalten, dass ich zuerst einen Frame mit dem Captcha und einem Start-Button öffne, mit diesem dann den "Navigator" der die Ansichten enthält. Das Öffnen der Ansichten will ich protokollieren, so dass auch Zugriffe per "Gehe zu.." geloggt werden. Ich hoffe, das alles so klappt.
Viele Grüße
Mirko
-
Wenn das nur für den Notfall sein soll, wie wäre es denn die Gruppen in der ACL einfach auf "Kein Zugriff" zu setzen und dann nur im Notfall die Rechte hochzudrehen. Das kostet den Admin ein paar Mausklicks und die Sache ist gegessen.
Da wird meiner Meinung nach ein riesiger Aufwand betrieben für etwas, das vermutlich nur ein paar Tage im Jahr mal zum Tragen kommt. Aufwand > Nutzen !
-
Hallo Ingo,
ich definiere mal Notfall mit Erdbeben. Ist zwar in Deutschland selten, aber egal. Mitarbeiter des sogenannten Krisenstabes sind immer anwesend und können dann sofort die notwendigen Mitarbeiter auch zu Hause anrufen. Da ich als Notes-Admin aber nicht rund um die Uhr zugegen sein möchte, könnte ich dann beim Erdbeben auch nicht die ACL der Datenbank verändern.
Wie gesagt, nach meiner Meinung sollte man so was sowieso nur denen zu Verfügung stellen, denen man auch voll vertraut.
Viele Grüße
Mirko
ps: Ich hatte auch nicht gedacht, dass so was riesigen Aufruhr verursacht. Die Lösung mit dem Captcha ist ja schon nicht schlecht.
-
könnte ich dann beim Erdbeben auch nicht die ACL der Datenbank verändern.
Kann man da nicht bei der Erdbeben-Überwachungs-Zentrale einen Webservice abzapfen, und dann in Abhängigkeit vom Wert auf der Richterskala im DDm einen Event triggern, der die ACL freischiesst?
Ist der einfachste Weg und du musst nicht ständig anwesend sein. ;D
Oder über ein Ei-Fön; das hat doch so einen "Schüttel-mich-sensor", oder ?
-
könnte ich dann beim Erdbeben auch nicht die ACL der Datenbank verändern.
Kann man da nicht bei der Erdbeben-Überwachungs-Zentrale einen Webservice abzapfen, und dann in Abhängigkeit vom Wert auf der Richterskala im DDm einen Event triggern, der die ACL freischiesst?
.. den Gedanken sollte ich mal verfolgen ;)
-
Mirko, solange Eure Personal-DB derart offen steht wie ein Scheunentor, nützt Dir auch ein Captcha nichts - Du musst es ja an eine bestimmte Stelle einbauen. Entweder, Du machst das an jeder in Frage kommenden Stelle, oder nur im Database-Script.
Ersteres lässt sich leichtestens überwinden (Database-GoTo), andere mit ähnlich geringem oder etwas mehr Aufwand.
Wenn Du nicht von Notes vorgesehenen Mittel verwendest, dann betreibt Ihr Aufwand .. für absolut nichts. Und da Notes die Mittel zur Verfügung stellt, kann auch niemand sagen, Notes taugt nichts - man hält sich halt nicht an die Spielregeln. (Mein Auto schluckt Super, wenn ich stattdessen Diesel einfülle, kann ich auch nicht sagen "Scheiss-Karre - kann nicht mal Diesel ab").
Bernhard
PS: Wenn Ihr wirklich Angst vor Erdbeben habt, dann würde ich ja eher noch eine weitere (an Daten leere) DB aufbauen, die einen Agent per RunOnServer und vorheriger Eingabe eines "Die-Welt-geht-unter!"-Passworts startet (der dann die erforderlichen (!) Daten aus der produktiven Personal-DB zieht).
-
Hallo Bernhard,
nochmals: Zugriffskontrolle zu DB per ACL, protokollieren der Zugriffe,auch die über Gehe zu ....
Ich habe mir das nicht ausgedacht. Und die Mitarbeiter des Krisenstabes sollen sich noch mal überlegen, ob es wirklich nötig ist, da reinzuschauen.
Falls es andere Möglichkeiten gibt, die ich noch nicht kenne (bin ja noch nicht der totale Notesprofi), dann wäre jetzt der richtige Zeitpunkt für ein paar Tips.
Niemand hat behauptet "Notes taugt nichts", ich muß nur die Suppe auslöffeln, die jemand anderes eingebrockt hat. Laut Programmierangebot an die Personalabteilung ist es wie gewünscht machbar.
Wie ich das einbauen will hatte ich schon beschrieben, bin für jeden besseren Tip dankbar.
Ein QueryOpen-Ereignis der DB finde ich leider nicht, PostOpen halte ich für zu spät, da ja dann wohl schon eine Ansicht offen ist.
Mirko
-
QueryOpen-Ereignis = Initialize im DB Script
Man kann zur Protokollierung der Zugriffe natürlich auch einen ExtensionManager auf dem Server einrichten ( z.B. Trigger Happy v. OpenNTF ).
Damit kannst du dann Zugriffe protokollieren.
Ich bleibe aber bei meinem Vorschlag:
ACL ( obligatorisch ) +
SplashScreen mit Captcha
ich muß nur die Suppe auslöffeln, die jemand anderes eingebrockt hat
kenne ich nur zu gut ...
-
Danke Ulrich,
das waren gerade zwei mittlere Kolbenklemmer: Initialize - logisch nehme ich bei jedem Script, aber noch nie beim Datenbankstart. Und dass der dann auch noch in den Datebankressourcen steckt...
Ist aber auch noch früh am morgen.
Ansonsten ACL = Pflicht.
Viele Grüße
Mirko
-
Mirko, nochmals: DatabaseScript-Initialize wie der ganze andere Code des DatabaseScripts wird nicht immer ausgeführt. Die Idee, über das pure Öffnen der DB und ein "He, wollen Sie wirklich??" ist Quatsch.
Denk mal über die zweite, nur auf "Wollen Sie wirklich? Ja? Wissen Sie, was Sie da tun? Echt? Das wird genau aufgezeichnet - überlegen Sie es sich noch mal! Alos okay .." zu füllende DB nach, die der Server auf Anforderung mit den wirklich (Echt!) erforderlichen Daten füllt.
Bernhard
-
Ich komme mir vor wie bei "Was bin ich :" Gehe ich recht in der Annahme...
... ich soll eine zweite Datenbank erstellen. Das halte ich nicht nicht so für sinnvoll. Die Personalabteilung will ja immer Zugriff auf die Datenbank haben. Das mit der Abfrage im Initialize ist auch nicht so toll, im Hintergrund wird schon der Rest der DB angezeigt.
Ich werde es wie folgt anstellen:
- Grundsätzliche Leseberechtigung per ACL, Leserfelder für die Rollen [PrimärUser] und [Admin]
- Beim Start der DB wird der im Anhang gezeigte Dialog in einer Rahmengruppe dargestellt. Wenn man dort abbricht passiert nichts. Für die Rolle [Admin] gibt es noch einen Button, der die Codeeingabe umgeht. Der Button Öffnen schaltet dann auf eine Rahmengruppe mit Navigator und Ansichten.
Für mich sind die Leute damit ausreichend informiert. Und können immer noch abbrechen, wenn es ihnen zu heiß wird ;-)
- das Öffnen der Ansichten wird protokolliert. (Außer Rolle [Admin])
Damit sollte ich alle Anforderungen der Personalabteilung erfüllt haben. Schließlich haben die nicht gefordert, dass der Krisenstab nur im Notfall Zugriff haben darf, sondern dass dieser die DB nur im Katastrophenfall verwenden darf und Zugriffe protokolliert werden.
Ich habe natürlich immer noch ein offenes Ohr für Vorschläge, aber zu kompliziert will ich es nicht machen.
Jetzt muss ich es nur noch der Personalabteilung verkaufen ;-)
Viele Grüße
Mirko
-
Nur so als Idee.
Der Administration hängt dann der Makel des unprotokollierten an.
Wie wäre es, wenn ein Admin darauf zugreift, was er ja auch nicht aus Langeweile tun sollte, ein Textfeld für eine Begründung eingeblendet bekommt?
-
Danke für den Hinweis,
die Rolle [Admin] hat sich allerdings die Personalabteilung für sich gewünscht, hat also nichts mit dem Notesadmin zu tun. Und die Personaler wollen auch ohne Protokoll zugreifen.
Aber das Feld für die Begründung an sich ist nicht so verkehrt, auch als "Erinnerungshilfe" für den Krisenstabler der die DB "notwendigerweise" öffnen musste.
Viele Grüße
Mirko
-
die Rolle [Admin] hat sich allerdings die Personalabteilung für sich gewünscht,
Dann würde ich die auch so nennen [PA] ( oder neudeutsch HR )
Morgen weiss das dann wieder keiner und dann tritt die Situation ein, die Andre meinte.
-
Mirko, ich habe keinen Plan, warum Du Dir vorkommst wie bei "Was bin ich?". Du kannst das ja so machen, wie Du es beschrieben hast, aber als "Interessierter" und nicht "ganz-auf-der-Wurstsuppe-Dahergeschwommener" würde ich dann eben immer per File-Database-GoTo zu den Ansichten gehen, die mich mal so zwischendurch interessieren. Du wirst dann nichts in Deinem Protokoll finden.
Ich würde bei dieser Anforderung immer noch zu meiner Zwei-Datenbanken-Lösungen tendieren - *diesen* Vorgang "Fülle DB 2 mit den wirklich erforderlichen Informationen aus DB 1" kannst Du immer überwachen, da gibt es kein "Drumherum".
Dein gegenwärtiger Plan ist jedenfalls "security by obscurity" und daher in meinen Augen untauglich.
Bernhard
-
@ Ulrich,
darüber werde ich noch mal nachdenken und den entsprechenden Leuten das so verkaufen. Mit HR weiß ja dann hoffenlich jeder, was gemeint ist.
@ Bernhard,
manche Kommentare sind für mich halt wie Rätselraten, ich brauche Aussagen wie: dieses ist schlecht weil ..., jenes ist besser weil ... So was begreife ich wenigstens ;-)
Aber egal, wenn einer über "gehe zu Ansicht xxx" zu einer Ansicht hüpft, macht er das meiner Meinung nach bewußt und erscheint im Log. Dieses schreibe ich übrigens im Ereignis "Queryopen" der Ansicht selbst. Das wird hoffentlich immer ausgefürt.
Viele Grüße
Mirko