Sicherheit von Datenbanken (Passwort / Zwischenablage)

[Mirko]

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

[eknori]

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

[ascabg]

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

[Mirko]

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

[m3]

Du möchtest auch eine konsistente ACL über alle Repliken erzwingen (ACL-Setting).

[Mirko]

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 

@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

[eknori]

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?

[ascabg]

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

[Mirko]

@ 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

[eknori]

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

[Mirko]

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 

[ascabg]

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

[Mirko]

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

[koehlerbv]

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

[Mirko]

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

[Driri]

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 !

[Mirko]

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.

[eknori]

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.  
Oder über ein Ei-Fön; das hat doch so einen "Schüttel-mich-sensor", oder ?

[Mirko]

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

[koehlerbv]

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