Das Notes Forum
Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: skywook am 15.06.12 - 09:18:46
-
Hallo,
wie stelle ich das an, dass wenn ich ein Dokument in der Ansicht markiert habe und die Eigenschaften abrufe (mit rechter Maustaste) und der zweite Reiter (mit den Feldnamen) leer ist? Die Felder des Dokumentes werden nicht angezeigt.
Geht das nur wenn ich das Design verborgen habe?
Für einen Tipp wäre ich dankbar.
-
Ja, oder du setzt $keepPrivate im Dokument auf "1", dann kann man nicht mehr scrollen, Inhalte kopieren oder das Dokument drucken (die Feldnamen sieht man aber)
Gruß
Roland
-
Falls Du das Verbergen des Designs und damit das Nichtanzeigen der Felderliste als Sicherheitsfeature nutzen willst, um nicht berechtigten Usern den Einblick in die Feldinhalte zu verwehren (weil Du vielleicht im Dokument die Felder mittels
eines zugriffsgesteuerten Abschnitts (Quatsch) einer Verbergeformel geschützt hast), vergiss es.
Ein Dokument in einer Datenbank mit verborgenem Design zeigt nicht die Felderliste. Aber: Kopiert in eine andere Datenbank mit offenem Design (z.B. der persönlichen Maildatenbank) sind die Felder wieder sichtbar.
Wenn das mit $KeepPrivate so funktioniert (ich hab das noch nicht probiert, glaube aber alles, was Roland sagt ;)), ist das zwar eine Hürde (das Dokument kann dann nicht kopiert werden), aber ein Autor auf dem Dokument entfernt mit einem simplen Smarticon oder einem Agenten das Feld, und alles ist wieder offen.
Oder man erstellt sich einen kleinen Agenten, der alle Felder des Dokuments ausliest (Forall item in doc.Items ...), dann reichen auch Leserechte (der Agent muss ja nicht in der gleichen Datenbank sein. Lokale Datenbank erstellen, Agent erstellen, fertig. Dazu braucht man noch nicht einmal einen Designer).
Wenn Du wirklich schützenswerte Daten hast, kannst Du das nur über Leserfelder in Dokumenten erreichen, Teilinformationen in allgemein sichtbaren Dokumenten musst Du dann auslagern.
Beispiel: Du hast Mitarbeiterdokumente, die jeder lesen kann. Darin enthalten sind die Gehaltsdaten, die nicht jeder lesen darf. Sind die Daten im Mitarbeiterdokument, gibt es keine sichere Methode, die zu schützen. Unwissenheit der "gewöhnlichen" Benutzer ist kein Schutz. Einzige wirklich funktionierende Lösung ist, die Gehaltsdaten in ein separates Dokument auszulagern, dieses Dokument mittels Leserfeld zu schützen und die Daten berechnet zur Anzeige (!!!) im Mitarbeiterdokument anzuzeigen. Berechtigte Benutzer sehen dann die Gehaltsdaten, nicht berechtigte nicht.
-
Wie Peter schon sagt, ist $keepPrivate lediglich eine Hürde und stimme Peter in allen Punkten zu. Lediglich zum letzten Punkt möchte ich noch ergänzen, dass man im "Gehaltsdaten"-Feld das "SEAL"-Flag (-> item.isEncrypted=true) setzen kann und das Dokument verschlüsseln kann.
Verschlüsselte Felder sehen dann nur Personen, die den entsprechenden Schlüssel haben.
Alle anderen Personen (die leseberechtigt sind) sehen dann nur die unverschlüsselten Felder (sowie ein Feld mit Namen $seal und $sealdata, welche als "Container" für alle verschlüsselten Felder dienen)
Personen die das Dokument nicht entschlüsseln können, können im Backend sogar Felder im Dokument ändern (z.B. Flags setzen)
Man muss aber höllisch aufpassen, dass man nicht "aus versehen" ein Dokument, welches eigentlich verschlüsselt sein sollte, unverschlüsselt ablegt.
Man muss UNMITTELBAR vorm doc.save ein doc.encrypt aufrufen, wenn das Dokument von einer Person gespeichert werden soll, die es entschlüsseln konnte.
Gruß
Roland
-
Zum Verschlüsseln ist noch zu sagen:
Ein einmal verteilter Schlüssel kann nicht "einfach so" zurückgezogen werden.
Bernhard
-
Stimmt, Verschlüsseln ginge auch. Noch ein Feature, dass ich persönlich nicht mag und deshalb nie nutze, muss aber der Vollständigkeit halber erwähnt werden ...
-
... Verschlüsseln ist zwar ein Weg, aber da gibt es einiges zu beachten - da sind die Auswirkungen unbedingt mit zu beachten - sonst heißt es später "... ja wenn ich das gewußt hätte..." - das kann auch ein böses Erwachen geben...
Toni
-
Danke an Alle,
hab mal wieder was dazugelernt :D
Habs jetzt so gelöst:
- In der ACL (für den "normalen User") das Drucken und Kopieren deaktiviert
- Autoren/Leserfelder im Dokument
- Design verborgen
denke so habe ich alle Varianten beachtet.
-
... keine Ansichten und Agenten erstellen lassen fehlt noch
-
@ata, das braucht er aber dann in allen Datenbanken, sonst kann er über db.allDocuments immer noch eine Kopie mit veränderter ACL anlegen
(soweit ich weiß greifen all die "Kopieren verboten" Einstellungen nicht im Backend)
Gruß
Roland
-
Und genau das geht nicht, denn niemand kann jemandem verbieten, in einer lokal selbst erstellten Datenbank einen Agenten zu schreiben. Allerdings schreibt skywook, dass er jetzt auch mit Leserfeldern arbeitet, das hört sich schon mal gut an.
EDIT: Und selbst wenn das Erstellen eigener lokaler Datenbanken mit Hilfe irgendwelcher Policies zu unterbinden sein sollte, dann erstellt man sich halt einen Button in einer Mail, oder ein Macro in Excel ...
Neben der erwähnten (zumindest von mir nicht geliebten) Verschlüsselung gibt es also nur zwei wirklich sichere Verfahren:
Leserfelder oder Strom abschalten.
-
N'abend,
nur damit es nicht untergeht. Leserfelder helfen beim FullAccessAdmin nicht !
CU,
Axel
-
... und natürlich auch nicht, wenn man physischen Zugang zum Server hat (oder sonst einen Lesezugriff auf die Festplatte des Servers)
-
Hallo Zusammen,
zum Thema Leserfelder meine ich mich zu erinnern, dass dies auch kein absolutes Sicherheitskriterium ist.
Denn wenn man die NSF Datei in einem gewöhnlichen Texteditor öffnet, kann man die mit Leseberechtigungen ausgeblendeten
Dokument im klartext lesen. Diese Dokumente werden ja nicht verschlüsselt sondern nur von Notes in den Ansichten usw. nicht Anzeige.
Wenn man absolute Sicherheit haben will, kommt man daher um verschlüsselte Felder bzw. Dokument nicht rum!
Grüße
Bernd
-
Aber auch dazu brauchst Du die Datenbank als physische Datei. Wenn ich die Datenbank lokal repliziere, werden m.W. nur die Dokumente repliziert, die ich lesen darf, somit dürften die nicht in meiner lokalen Datei vorhanden sein, wenn ich die mit dem Editor lese.
Zumindest habe ich das bisher geglaubt. Ich werde das mal ausprobieren und berichten ...
-
Wenn ich die Datenbank lokal repliziere, werden m.W. nur die Dokumente repliziert, die ich lesen darf
das ist richtig
-
Wenn ich die Datenbank lokal repliziere, werden m.W. nur die Dokumente repliziert, die ich lesen darf
das ist richtig
Und wenn einem später Rechte auf Dokumente via Readers Items entzogen werden, dann werden bei der Replikation sogar die betroffenen Dokumente gelöscht. Das gilt natürlich auch für die Server-Server-Replikation.
Bernhard
-
Da habt Ihr ja auch völlig recht!
Ohne die physikalische Datei kann ich diese auch nicht in einem Editor öffnen. (Zumindest noch nicht im Jahr 2012 ;D)
Nur wenn es z.B. wirklich darum gehen soll, Gehaltsdaten o. ä. in den Dokumenten zu hinterlegen, kann per Editor jeder Admin darauf zugreifen.
Und wäre sicherlich bei so sensiblen Daten nicht gewollt!
Grüße
Bernd
-
Es ist so, wie ich es bisher erwartet hatte (zum Glück !!!)
Eine Datenbank auf dem Server, ein Dokument mit einem Text- und einem Leserfeld. Im Leserfeld steht "Niemand", im Textfeld "Das ist mein Dokument".
Dokument gespeichert, ist sofort nicht von mir lesbar (bin ja schließlich nicht Niemand ;))
Datenbank lokal geöffnet (direkt vom Server, also nicht repliziert)
- Das Dokument ist da, ich kann es öffnen und lesen
- im Editor finde ich auch mein Textfeld
Datenbank lokal repliziert
- Das Dokument ist nicht da
- im Editor finde ich nicht mein Textfeld
Eine weitere Möglichkeit wäre nun, als Unberechtigter an einem Rechner die Datenbank zu öffnen, auf dem ein berechtigter Benutzer eine lokale Replik liegen hat. Dort sind die Daten im Editor nur lesbar, wenn die lokale Replik nicht verschlüsselt ist (auch getestet). Unverschlüsselt braucht er aber keinen Editor, da Notes selbst die Dokumente anzeigt, die in der Datenbank enthalten sind.
Ich denke, besser kann man das nicht lösen. "Schwachstellen" bei Leserfeldern sind also lokaler Zugriff auf den Server und lokal unverschlüsselte Repliken. Dass Admins immer an alle Informationen herankommen, ist selbstverständlich, dafür sind es Admins. Der "gewöhnliche" User kommt nicht unberechtigt an Informationen, wenn das System korrekt betrieben wird. Ein Server sollte schließlich nicht in der Kaffeeküche stehen.
-
Hallo Peter,
da gebe ich dir ja auch völlig Recht!
Für den Normalgebrauch ist das für große Teile des Anwendungsspektrums auch ausreichend.
Aber....
ich glaube nicht, dass dieser Sicherheitsmechanismus für sehr sensible Daten ausreicht.
Auch Admins sind nur Menschen und manchmal seeeehr neugierig! ;)
Und wenn man nun mal vertrauliche (Sprich Geheime) Daten in einer Notesanwendung ablegen will, führt meiner Meinung nach nichts an verschlüsselten Feldern vorbei.
Hier muss eben jeder für sich entscheiden, wie hoch er die Messlatte für Sicherheit legen will.
Grüße
Bernd
-
Hallo Bernd,
ja, wenn es wirklich so sensibel ist, ist Verschlüsselung sicherlich eine Lösung, möchte auch generell nicht mehr dagegen sagen, als dass ich persönlich es (noch) nicht mag (was nichts zu bedeuten hat). Das muss dann aber wohl gut organisiert werden. Wer erstellt und verteilt die Schlüssel, was passiert bei Wegnahme eines Zugriffsrechts, wie rettet man Daten bei Verlust des Schlüssels usw.?
Vermutlich wird es auch dabei wieder eine administrierende Instanz geben müssen, die im Zweifelsfall (unberechtigt?) Zugriff hat.
-
Zur Verschlüsselung: Ich habe recht gute Erfahrungen damit gemacht, statt mit PrivateEncryptionKeys mit dem Feld PublicEncryptionKeys zu arbeiten. Damit entfällt der "lästige" Umgang mit den Key-Files und ich bestimme dynamisch im Dokument, wer die verschlüsselten Inhalte sehen kann. So haben wir z.B. für den Zugriff auf Dateien im Filesystem (Server) die Möglichkeit geschaffen, dass ein Benutzer Anmelde-Infos verschlüsselt hinterlegt. Der Server hat nachts Attachments aktualisiert und dabei diese Login-Daten genutzt. Damit er sie "sieht", musste er natürlich auch im o.g. Feld aufgeführt werden, damit sein öffentlicher Schlüssel für die Verschlüsselung herangezogen wird.
-
Das hört sich gut an, werde ich mir mal merken ...