Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: iukhdh am 07.02.08 - 18:26:07
-
Hallo Forum,
gibt es die Möglichkeit, eine Notesdatenbank mit einem Passwort zu versehen?
Hintergrund: Wir haben eine sehr kritische Datenbank, die nicht jeder zu Gesicht bekommen sollte, daher sind nur ca 50 Leute dafür zugelassen. Diese haben aber nun teilweise Angst, dass wenn Sie ausm Zimmer gehen und ihren PC nicht sperren, möglicherweise jemand anders an ihren PC hocken und spionieren könnte.
???
Thomas
-
Hallo Thomas,
wer aus dem Zimmer geht und den Schrank offen läßt, darf sich nicht wundern, wenn jemand anderes hinein schaut.
Der Notes Zugang ist doch bei euch mit einem Password gesichert, oder sehe ich das falsch?
Also F5 in Notes (wenn nicht gerade Single Sign On aktiviert ist) oder Strg+Alt+Entf und Enter dürfte da nicht zuviel verlangt sein. Alles eine Erziehungssache.
Hubert
-
gibt es die Möglichkeit, eine Notesdatenbank mit einem Passwort zu versehen?
Nein.
Du kannst aber in den Benutzervorgaben einstellen, das ab einer bestimmten Zeit der Inaktivität die Abmeldung erfolgt und die Notes - Anzeige gesperrt wird.
Alternativ kann man auch den Windows-Bildschirmschoner mit einem Passwort belegen. Hier ist aber die Sicherheit etwas umstritten.
Eine andere Möglichkeit sehe ich nicht.
Axel
-
... dazu gibt es die ACL - wer aus dem Zimmer geht und den Rechner nicht sperrt ist selber Schuld - da kann ich gleich jedem meine ID geben und hoffen daß sie keiner benutzt...
Toni
-
Nun gut,
das deckt sich mit meinem Wissenstand. Bin ich ja beruhigt. ::)
Naja, kann man so oder so sehen. Ich sehe es so wie ihr, kann aber letztlich die Ängste mancher Personen schon verstehen, die einfach befürchten dass Sie es letztlich halt doch hin und wieder vergessen ihren PC zu sperren. Und wenn man ehrlich ist ... sperrt ihr euren PC immer wenn ihr mal kurz aufs Klo geht?
Es wäre halt eine zusätzliche Sicherheit gewesen die die Gemüter beruhigt hätte, so werde ich die DB, die nur ca ein Quartal im Jahr im Einsatz ist, die restliche Zeit halt grundsätzlich sperren lassen, dann braucht keiner unnötig Angst zu haben.
Danke für Eure Rückmeldungen
Thomas
-
Ich halte die Herangehensweise für falsch, Thomas. Wer im Bahnhofsrestaurant seine Autoschlüssel einfach auf dem Tisch liegen lässt, während er für "kleine Programmierer" geht, brauch sich auch nicht zu wundern, wenn er nach der Rückkehr vom Klo die Telefonnummer eines örtlichen Taxiunternehmens erfragen muss.
Wenn man eine DB dahingehend "sperren" will (was komplett gar nicht geht), dass man für jeden Zugriff ein Passwort braucht: Die Leute, die jetzt zu faul / zu vergesslich / zu blöd sind, mit Alt-F4 ihre Kiste zu sperren, werden dann das ganz, ganz grosse Jammern anfangen.
Ich denke, in diesem Thread ist alles gesagt. Der passende Spruch lautet ja: "Ich schliesse den Tresor auf - aber wehe, es geht dann einer hinein, wenn ich nicht aufpasse!". Dummfug ...
Bernhard
PS: Im "normalen Leben" funktionieren diese Leute doch auch ... Warum können sie diese einfachen Prinzipien nicht übertragen?
-
Tja, die Sache ist ein weites Feld, würd ich mal sagen.
Im Grundsatz stimme ich Euch allen zu. Wir haben es in der unserer Abteilung besprochen und die meisten sind ebenfalls der Meinung dass man halt seinen PC sperren soll.
Aber leider, leider muss ich halt aus eigener Erfahrung sagen, dass das Leben halt nicht immer so ist wie man es gerne hätte. Ich sollte auch jedesmal, wenn ich aus dem Zimmer gehe, mein Telefon umschalten ... tja, von 10 mal aus dem Zimmer gehen vergesse ich es halt 5 mal. In der Hektik, in Gedanken usw ... usw.
Aber da es sich bei der DB halt um seeeehr heikle Daten handelt (Mitarbeiterbewertungen) ist es da halt um einiges schlimmer wenn was passiert.
Und egal wie man dazu steht, im Grunde kann ich die Kollegen schon verstehen. Warum um alles in der Welt kann man diese wichtigen Daten nicht einfach mit einem zusätzlichen Passwort, wie z.B. Dokumente in Word schützen und damit den Fall der Fälle etwas unmöglicher machen? Statt zig mal am Tag meinen PC oder Notes zu sperren, einmal eine DB mit Passwort versehen?
Nun gut, wie du sagtest, man könnte diese Diskussion ewig weiter führen, jeder hätte Punkte dafür oder dagegen.
Wichtig war mir eigentlich nur die Aussage das es letztlich nicht geht, was auch unser Wissenstand war, aber man weiss ja nie ...
Leider Gottes sitzen die Betroffenen an höherer Stelle und werden vermutlich keine Ruhe geben. Und da Ober wie überall Unter sticht, werden wir uns wahrscheinlich eine Lösung ausdenken müssen, und die wird dann darauf hinauslaufen, dass ausserhalb der heissen Bewertungszeit den Kollegen einfach die Berechtigung entzogen wird, damit zumindest in den 9 Monaten wo man sie nicht braucht alle ruhig schlafen können ;)
Gute Nacht zusammen
Thomas
-
Grundsätzlich schließe ich mich den Vorpostern an. Vielleicht hilft Dir aber auch schon ein
@Command([ToolsUserLogoff])
im QueryClose der Datenbank (Datenbankscript).
Gruß
Peter
-
Danke für den Tipp,
aber das ist sicherlich keine Lösung, da wir ja nicht nur eine DB haben sondern alles mögliche über Notes abwickeln. Daher müssen die Kollegen ja auf jeden Fall im Notes angemeldet bleiben.
Jetzt schaumermal wie sich das ganze weiterentwickelt, vielleicht wird es ja akzeptiert dass es keine Passwortlösung gibt.
Thomas
-
Wie wäre es denn, wenn Du bei jedem Dokumentöffnen eine "Passwortabfrage" einbaust?!
Ist zwar für den berechtigten Benutzer umständlich, aber so ist das Risiko minimiert, dass unberechtigte Benutzer Dokumente öffnen.
Das Design der DB solltest Du dann aber auch verbergen, damit über die Dokumenteigenschaften keine Inhalte gelesen werden können.
Aber die berechtigten Benutzer müssen, bevor sie das Zimmer verlassen, alle geöffneten Dokumente (Mitarbeiterbewertungen) schließen !!
-
@Thomas:
Das, was Notes mitbringt ( F5 ) und natürlich ein Passwort auf die ID reicht allemal aus. Sich um weitergehende "Programmierungen" überhaupt Gedanken zu machen, ist vergeudete Zeit.
Die Verantwortlichen ( sofern man die im geschilderten Fall überhaupt so benennen darf ) sollen nicht wie die Lemminge den "Best Practice" vieler anderer Unternehmen folgen, und mangelde Organisation durch Technik zu ersetzen.
Wer mit solch heiklen Daten arbeitet und nicht selber soviel Grips mitbringt, die technischen Möglichkeiten des Produkts zur Absicherung der Daten konsequent anzuwenden, dem gehört der Zugriff auf diese Daten entzogen.
Und zwischen dem Umschalten eines telefons bei Abwesenheit und dem Sperren des Zugriffs auf sensible Daten sehe ich immer noch einen riesigen Unterschied.
Und wenn das Telefon so wichtig ist, dann solltet ihr euch schnurlose Dinger anschaffen; die habt ihr dann immer "am Mann / an der Frau"
Ich weiss aus eigener schmerzhafter Erfahrung, daß es sehr schwer ist, manche Betonköpfe von der Idiotie ihres Handelns / Unterlassens zu überzeugen.
In der Vergangenheit habe ich auch vielfach organisatorische Unzulänglichkeiten "wegprogrammiert". Aber irgendwann habe ich einen Schlussstrich gezogen. Hat nicht gerade die Liste meiner Freunde verlängert ...
-
Sorry,
die Angelegenheit lässt mich nicht los.
Ich hab mal im Postopen einer Testdb folgenden Code eingegeben:
Sub Postopen(Source As Notesuidatabase)
Dim uiw As NotesUIWorkspace
Dim num As Integer
On Error Goto schliessen
num% = Cint(Inputbox$("Bitte Passwort eingeben"))
If num% <> "123" Then Goto schliessen
Exit Sub
schliessen:
source.Close
End Sub
Ist leider nur die halbe Wahrheit ... Warum um alles in der Welt gibt es kein Queryopen der Datenbank? :-\
Dumm ist halt nur, dass man im Hintergrund schon Daten sieht. Ich könnte es vielleicht noch dahingehend ändern, dass ich der DB sage, dass sie einen (z.B. leeren) Rahmen öffnen soll, dann würde man im Hintergrund nix mehr sehen.
Aber große Preisfrage an die Fachleute:
Wie würdet ihr diesen Schutz nun umgehen? Ich bin ja fast sicher dass ihr meine tolle Idee aushebeln könnt ;)
Übrigens, bevor wir dahingehend weiterdiskutieren ... im Moment geben sich die entsprechenden Herren mit der F5 Methode zufrieden ... eigentlich interessiert es mich im Moment einfach nur persönlich obs nicht doch ne einigermassen gangbare Lösung gäbe.
Ciao
Thomas
-
Das DatabaseScript-Postopen ist einfachst zu umgehen: Ansicht-gehe zu. Nur als EIN Beispiel.
Bernhard
-
Wie würdet ihr diesen Schutz nun umgehen?
Welcher Schutz ? ;D
Sich um weitergehende "Programmierungen" überhaupt Gedanken zu machen, ist vergeudete Zeit.
Da muss ich Ulrich recht geben.
-
@Bernhard
Sorry, blicks grad nicht ... auf "Ansicht - gehe zu" komme ich doch garnicht, ist beim öffnen der DB beim Ablauf meines Codes gegraut. Und von einer anderen DB kann ich doch damit auch nicht zu meiner "geschützten DB" wechslen? Oder?
-
Das geht auch nur von einer Ansicht aus.
-
Wieso sollte ich Deinen Code überhaupt ausführen? Datenbank markieren - genannten Menüpunkt wählen. Oder Rechtsklick auf das DB-Symbol ...
Bernhard
-
Hallo,
wenns wirklich sicher sein soll geht das meiner Meinung nach nur mit einer "Zugangskontrolle mit rfid", wenn der User weggeht, wird der Rechner automatisch gesperrt, wenn wer wieder zurückkommt die rfid-Karte hinlegt und pin eingibt ist es wieder entsperrt.
Gruß Werner
-
:(
JETZT kapier ich was du meinst ... Kacheloberfläche, mit der wir hier so gut wie nie arbeiten ...
Tja, da geb ich mich natürlich geschlagen. Ohne es auszuprobieren ... da müsste ich dann wohl auch noch in jeder Ansicht so einen Code einarbeiten, und das wäre dann ja zu lästig.
Aber wieder was gelernt. Das man mit sowas das Postopen der DB umgehen kann ist mir nicht bewusst gewesen ... und wenn ich ehrlich bin mir auch nicht ganz eingängig ... wenn ich eine Ansicht öffne, dann öffne ich doch letztlich auch die DB, "aber s isch halt et so", wie wir Schwaben so sagen.
Jetzt geh ich erstmal in die Mittagspause ... Frustfressen :D
Ciao
Thomas
-
Werner, selbst das ist nicht wirklich sicher. Wieviele Kennwörter hängen am gelben Save um den Monitor?
Irisscan mit DNA-Abgleich und Überprüfung auf lebendes Gewebe. Das könnte u.U. reichen um das sicher zu machen... ;D
Das mit dem Postopen der DB kannte ich auch noch nicht. Was ich weiß ist, das das PostOpen nur bei Frontend Aktionen zieht. Aber gerne gelernt.
-
Hallo,
wenns wirklich sicher sein soll geht das meiner Meinung nach nur mit einer "Zugangskontrolle mit rfid", wenn der User weggeht, wird der Rechner automatisch gesperrt, wenn wer wieder zurückkommt die rfid-Karte hinlegt und pin eingibt ist es wieder entsperrt.
Gruß Werner
Wirklich sicher ist das aber auch nur bedingt. Wenn der Anwender seine Karte liegen lässt, dann ist der Rechner auch offen. Das ist im Prinzip das Gleiche wie bei allen bisher angesprochenen Lösungen. Wenn der User sich nicht an gewisse Spielregeln hält, dann kann das nichts werden.
Axel
-
... ich kann mich nur der Meinung von Ulrich anschließen:
Wer mit solch heiklen Daten arbeitet und nicht selber soviel Grips mitbringt, die technischen Möglichkeiten des Produkts zur Absicherung der Daten konsequent anzuwenden, dem gehört der Zugriff auf diese Daten entzogen.
... alles andere rechtfertigt keine Minute Aufwand...
Toni
-
Das INITIALIZE des DB-Scripts wird man kaum umgehen können. Dort kann man zwar nur Script programmieren, aber damit z.B. einen Agenten starten, der beim Starten der DB eine Notes-Abmeldung vornimmt, eben ein @Command([ToolsUserLogoff]) durchführt.
Natürlich - wer den Debug-Modus einschaltet und das Initialize abbricht, kommt dennoch rein, aber das dürften höchstens die Programmierer wissen und kennen - und auch die erst beim zweiten Mal. Und das sollte es nun wirklich nicht geben.
Gruß
Norbert
-
@Norbert,
... das Initialize der DB greift beim Öffnen - da greift auch schon die ACL - und die ist wasserdicht. Wer also die Datenbank schließt, sollte auch in der Lage sein F5 zu drücken - mit dem richtigen Sicherheitsbewußtsein, bzw. Konditionierung ;)...
Toni
-
Hallo,
wenns wirklich sicher sein soll geht das meiner Meinung nach nur mit einer "Zugangskontrolle mit rfid", wenn der User weggeht, wird der Rechner automatisch gesperrt, wenn wer wieder zurückkommt die rfid-Karte hinlegt und pin eingibt ist es wieder entsperrt.
Gruß Werner
Wirklich sicher ist das aber auch nur bedingt. Wenn der Anwender seine Karte liegen lässt, dann ist der Rechner auch offen.
Bei unserem Kunden haben sie so eine Lösung - allerdings mit Smartcard und Leser und nicht mit RFID. Funktioniert recht gut, da die User die Karte auch brauchen, um Türen zu öffnen, etc. Wer die Karte im Rechner lässt, kommt nicht mehr ins Zimmer/Stockwerk, ....
Nach einigen Tagen Chaos hat das recht gut funktioniert - auch bei den Betonköpfen.
BTW: Wer die Karte vergisst, bekommt für den "Zugriff zwischendurch" ein 32 stelliges Passwort - seitdem vergisst kaum noch einer die Karte daheim :D
-
quasi als Schlüssel zum Rechner - ganz schöner Aufwand - und das alles wegen F5 drücken müssen beim Raum verlassen...
*** staun und stutz ***
Toni
-
Frag einmal bei deinen typischen Benutzern, wieviele F5 überhaupt kennen - und dann frag noch einmal, wieviele von denen, die Zugang zu besonders sensitiven Daten haben, F5 kennen.
Danach kann man dann möglicherweise wieder über ein programmgesteuertes F5 beim Betreten einer DB mit sensitiven Daten nachdenken.
Das ist ein pragmatischer Ansatz, nicht zur Schaffung, aber zur Verbesserung der Sicherheit.
Gruß
Norbert