Domino 9 und frühere Versionen > ND6: Entwicklung

Berechtigungen für Felder

<< < (3/4) > >>

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  ;D) :
"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:

--- Zitat von: koehlerbv am 16.06.04 - 23:47:32 ---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.
--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete