Berechtigungen für Felder

[musicforever]

Ich möchte div. Felder in einem Tabellenreiter mit 2 Rollen vergeben und damit die Editierrechte für die verschiedenen Felder User-steuern.
Frage: wie können alle User die Felder sehen, aber nur ausgewählte Menschen die Felder editieren?
Muß ich eine Aktion machen oder kann ich das eventuell über die Eigenschaften der Felder regeln?

Vielen Dank schon mal für die Antworten.

Gruß
Yvonne  

[Driri]

Du kannst z.B. für jedes Feld ein zusätzliches Feld (Berechnet zur Anzeige) mit dem Wert des eigentlichen Feldes einbauen.

Das normale Feld und das berechnete Feld verbirgst Du dann abhängig von einer Rolle.
D.h. hat ein Benutzer z.B. die Rolle "[Editor]", wird das normale, bearbeitbare Feld angezeigt und das berechnete verborgen, ansonsten anders herum.

[CLI_Andreas_Schmidt]

Die beste Lösung wäre ein "Zugriffskontrollierter Abschnitt"

Gruss

Andreas

[koehlerbv]

In einer Tabelle ? Da wäre ich aber vorsichtig.
Was Driri schrieb, ist schon die bewährteste und sauberste Lösung.

Bernhard

[TMC]

da kann ich Bernhard und Diri nur zustimmen.

Ich habe alternativ - zwecks Vermeidung doppelter Felder - auch schon mit Berechnetem Text gearbeitet. Ist aber alles andere als toll, wenn man mit dem Dokument mehr vorhat (z.B. forwarden in Mail - bei Formeln wie @DBTitle steht dann im Maildokument der Name des Users im ber.Text).

Ich sehe also auch als sauberste Lösung: 2 Felder.

[koehlerbv]

Erfahrung ist eben durch nichts zu ersetzen  

Bernhard

[animate]

alles andere als sauber ist die Lösung allerdings in "kritischen" Datenbanken!

[Driri]

Stimmt. Die Lösung ist so nicht sicher, da die Inhalte über die Properties ausgelesen werden können und die Felder z.B. per Agent trotzdem manipuliert werden können.

[koehlerbv]

Wie wär's den mit Autorenfeldern und Autorrechten in der ACL ?

[Axel]

Wie wär's den mit Autorenfeldern und Autorrechten in der ACL ?

Hört sich auf den ersten Blick ganz gut an, ich glaube aber nicht, dass es das Problem löst. Denn meines Wissens ging es um einzelne Felder einer Maske und nicht um die gesamte Maske.

Stimmt. Die Lösung ist so nicht sicher, da die Inhalte über die Properties ausgelesen werden können und die Felder z.B. per Agent trotzdem manipuliert werden können.

Wenn man die Gestaltung versteckt, dann werden auch die Felder nicht mehr bei den Properties angezeigt.  Wenn man den User auch noch das Recht entzieht Agenten zuerstellen, sollte man das Ganze erschlagen haben. Oder irre ich mich da?


Axel

[animate]

ich glaube, du irrst dich.
mit einem simplen SmartIcon könntest du beliebige Feldnamen lesen, Feldinhalte schreiben, etc.

Für den 0815-Nutzer mag das mit den berechneten Feldern klappen, aber sicher ist das nicht im geringsten.

[TMC]

Interessanter Aspekt, Thomas.

Hast Du da einen praktikablen Alternativ-Vorschlag (ohne Feld-Verschlüsselung) ?

[koehlerbv]

Bevor wir hier weiter diskutieren, sollten wir unbedingt eine Rückmeldung von Yvonne abwarten. Wir könnten jetzt nämlich vom Hundertsten in Tausendenste ausholen und pur theoretisieren ...

Nur noch ein paar Anmerkungen (ich weiss, das beisst sich mit der Einleitung  ) :
"Doppelte" Felder - einmal editierbar, einmal berechnet - sind natürlich keinerlei Schutz, wenn keine begleitende Massnahmen eingesetzt werden (Autorenfelder zum Bleistift).
Hidden design hilft überhaupt nichts gegen das Ausspähen von Feldinhalten oder die Ermittlung der verwendeten Feld-/Itemnamen. Jeder, der nicht mal programmieren kann, kann sich da diverse Tools aus dem Web herunterladen. Wer programmieren kann, braucht nur wenige Zeilen, um Ergebnisse zu erhalten.
Feldverschlüsselung ist eine harte, sichere, aber auch extrem wartungsunfreundliche Methode. Wehe, ein Mitarbeiter kommt später zu den Berechtigten oder - schlimmer noch - einer soll ausgeschlossen werden (ohne dabei seinen Notes-Account zu verlieren).

Wenn es wirklich happig wird mit den Anforderungen, muss man m.E. auf eigene "Massnahmen" zurückgreifen. Ich arbeite gerade an einer Verschlüsselung von Gehaltsdaten, an die selbst ein Admin nicht mehr herankommt (selbst, wenn er OS-Kopien einer DB ziehen kann) und bei der jeder Wert absolut individuell verschlüsselt wird (will heissen: 50 TEURO per annum bei Mitarbeiter A wird völlig anders verschlüsselt wie die 50 TEURO von Mitarbeiter B). Für einen derartigen Aufwand muss es dann aber auch einen wirklich triftigen Grund geben, und der Aufwand muss entsprechend bezahlt werden.

Yvonne helfen wahrscheinlich schon Autorenfelder weiter. Denke ich mal.

Bernhard

[TMC]

Ich arbeite gerade an einer Verschlüsselung von Gehaltsdaten, an die selbst ein Admin nicht mehr herankommt (selbst, wenn er OS-Kopien einer DB ziehen kann) und bei der jeder Wert absolut individuell verschlüsselt wird (will heissen: 50 TEURO per annum bei Mitarbeiter A wird völlig anders verschlüsselt wie die 50 TEURO von Mitarbeiter B). Für einen derartigen Aufwand muss es dann aber auch einen wirklich triftigen Grund geben, und der Aufwand muss entsprechend bezahlt werden.

Prinzipiell würde da doch das Boardmittel "SecretEncryptionKeys" reichen. Da hat kein Admin die Möglichkeit, da Feldinhalte zu lesen. Alte ID-Kopie hilft dem Admin auch nicht weiter bei Secret Encryption.
Da gibts nette LDD Today Artikel zu dem Thema, ist imho sehr schnell umgesetzt. Außer wenn natürlich die Board-Mittel nicht mehr reichen.

Ich will dass da keiner abgeschreckt wird:
Feldverschlüsselung ist IMHO sehr schnell implementiert. Man muss natürlich ein paar Nachteile in Kauf nehmen (Key wech = Daten wech, keine Anzeige der verschlüsselten Felder in Views, etc.). Und sich im klaren sein, dass PublicKey-Verschlüsselung sehr unsicher sein kann, daher bei kritischen Daten SecretKey verwenden.

[koehlerbv]

Vielleicht bin ich ja auf dem falschen Dampfer und alles ginge viel einfacher: Aber was machst Du bei SecretKey, wenn zum Bleistift ein Mitarbeiter, der bisher Daten lesen konnte, jetzt in eine andere Abteilung versetzt wird und damit keinen Zugriff auf die "geheimen Daten" mehr haben darf ? Dann muss doch nicht nur jedes Doc geändert, sondern auch noch jede betroffene Client-Installation geändert werden ?

Bernhard

[TMC]

Spontane Ideen hierzu, Bernhard:
Per Agent alle Doks ändern und ins SecretEncryptionKeys neuen Key schreiben, der dann an alle verteilt wird per Mail. Kann praktisch fast alles programmatisch erfolgen.

Ist nicht unbedingt der super-elegante Weg, aber wohl praktikabel machbar. Dabei vielleicht noch programmatisch eine Copy ziehen mit altem Key, falls da was schief läuft (nicht dass dann keiner mehr an die Daten kommt)

Ich will nur nicht abschrecken vor der Verschlüsselungsthematik:
Die ausbleibenden Fragen hier im Forum und überhaupt meine Gespräche mit Notes-Leuten zeigen mir, dass Feld-Verschlüsselung im Notes-Umfeld viel zu wenig eingesetzt wird - wohl letztendlich auch mangels Kenntnis wie unsicher manche Anwendungen sind (trotz Einsatz von Leser-Feldern; meines Erachtens sind solche DB's nur vor DAU's sicher. Eine Notebook-Replik genügt ja, um an alle Daten zu kommen, die der NB-User auch sehen darf).

[animate]

Interessanter Aspekt, Thomas.

Hast Du da einen praktikablen Alternativ-Vorschlag (ohne Feld-Verschlüsselung) ?

Nicht so richtig.
Evtl. zugriffsbeschränkte Abschnitte (oder wie die heißen)
Evtl. die Architektur der Anwendung ändern.
Verschlüsselung ist eine Option, aber aus dem unten genannten Punkt sehr schwer zu pflegen, denke ich (vor allem wenn unterschiedliche Felder unterschiedliche Leser/Editoren haben. Also wenn es mehr als eine schreibende und eine lesende Gruppe gibt)