Domino 9 und frühere Versionen > ND9: Entwicklung

Verschlüsseltes Feld PublicEncryptionKeys im Backend aktualisieren

<< < (2/3) > >>

Legolas:
Hallo Forum,

ich muss nochmals nachhaken, da mir das Thema unter den Nägeln brennt und ich dringend eine Lösung brauche.
Bin ich etwas der Einzige, der mit verschlüsselten Feldern arbeitet?
Falls nein, muss doch jeder schon auf das gleich Problem gestoßen sein.
Wäre toll von Euch, wenn mir noch jemand helfen könnte.

Danke schon mal für die Rückmeldungen
Bernd

pram:

Hier ein paar Infos was ich zur Verschlüsselung weiß:

1. Es werden nur Felder verschlüsselt, die das "SEAL" Flag haben (in der Maske bekommen sie "rote Ecken")
2. Die Felder heißen "PublicEncryptionKeys" und "SecretEncryptionKeys" und steuern lediglich die Verschlüsselung (mittels doc.encrypt bzw. uidoc.save - hier müssen sie in der Maske vorhanen sein, Setzen im Backend reicht nicht) Beim Verschlüsseln mit "PublicEncryptionKeys" werden die öffentlichen Schlüssel aus dem Adressbuch geladen (private befindet sich im ID-File). Die SecretEncryptionKeys hingegen müssen verteilt werden und ebenfalls im ID File abgespeichert werden
3. Man kann in einem verschlüsselten Dokument alle nicht verschlüsselten Felder ändern - selbst wenn man es nicht entschlüsseln kann. Man kann auch den Inhalt in PublicEncryptionKeys und SecretEncryptionKeys ändern Der Inhalt dieser Felder muss nicht dem tatsächlichen Verschlüsselungsstand entsprechen
4. Zum Verschlüsseln muss man ALLE Schlüssel haben (PE-Keys bekommt man automatisch aus dem Adressbuch, SE-Keys sind im ID-File)
5. Wen man ein Dokument verschlüsselt, verschlüsselt man es immer auch für sich selbst. Auch wenn man nicht in PE-Keys steht. (Man kann sich nicht selbst aussperren)
6. Beim Zugriff über die LotusScript-API wird immer versucht, ein verschlüsseltes Dokument zu entschlüsseln
7. Beim Entschlüsseln wird immer auf das ID-File zurück gegriffen (hier sind die privaten schlüssel abgelegt) - es ist deshalb egal mit was für einer ID der Agent signiert ist.


Wegen 6. und 4. musst du dafür sorgen, dass dein LotusScript-Agent keinesfalls das Dokument entschlüsseln kann. D.h. niemals den Server in PE-Keys eintragen. (Sonst hat der Server ein Problem, wenn er das Dokument neu verschlüsseln muss, sobald ein Schlüssel fehlt, weil z.B. eine Person ausgeschieden ist) - 5. ist ebenfalls ein Sicherheitsproblem, da der Besitzer der ServerID fortan berechtigt ist, den Inhalt zu lesen.

Da das Kind meist schon in den Brunnen gefallen ist, und man i.d.R. sowieso nur nicht verschlüsselte Felder ändern will (siehe 1. und 3.) gibt es noch einen Trick:
- Formelagenten verwenden (meist keine Option)
- Mittels Evaluate & @SetDocField-Formel (klappt ganz gut, sofern man nur 'einfache' Werte schreiben möchte)

Funktion aus dem Stegreif getippt, nicht getestet!

--- Code: ---function setValue(doc as NotesDocument, name as String, value as Variant)
  db = doc.parentDatabase()
  dim tmpDoc as new NotesDocument(db);
  tmpDoc.srcUnid = doc.universalId
  tmpDoc.name = name
  tmpDoc.value = value
  x = Evaluate("@SetDocField(srcUnid; name; value)", tmpDoc) ' setzt im Dokument mit der srcUnid das Feld 'name' auf den Wert 'value'
end function

--- Ende Code ---

Viel Erfolg
Roland

Legolas:
Hallo pram,

danke erstmal für die ausführliche Rückmeldung.

Frage zu Punkt 4)
Wenn das so ist würde das ja bedeuten, dass es zu Problemen bei Feldern kommen würde, die mit mehreren ID's verschlüsselt sind (PublicEncryptionKeys).
Z.B.: Wenn einer der Mitarbeiter nicht mehr im NAB vorhanden ist.
Das kann ich mir ehrlich gesagt nicht vorstellen, dass sich Notes hier so verhält. Damit wäre ja jede Verschlüsselung ein potenzielles Risiko.

zu

--- Code: ---Da das Kind meist schon in den Brunnen gefallen ist, und man i.d.R. sowieso nur nicht verschlüsselte Felder ändern will (siehe 1. und 3.) gibt es noch einen Trick:
--- Ende Code ---

Leider ist es bei mir nicht so, ich muss die verschlüsselten Felder ändern. (Neue Berechtigungen hinzufügen, wenn z.B. neue Mitarbeiter eingestellt werden.)

Hast du hierzu noch eine Idee?


Grüße
Bernd

pram:
Hallo Bernd,


--- Zitat ---Wenn das so ist würde das ja bedeuten, dass es zu Problemen bei Feldern kommen würde

--- Ende Zitat ---
Du meinst Dokumente? Dokumente werden verschlüsselt. Dabei werden alle Felder, die das SEAL bit gesetzt haben, verschlüsselt (mit den gleichen Schlüsseln) alle anderen nicht.

Die verschlüsselten Felder werden dann in das $SEAL Feld gepackt. Die Felder kann man nicht in Ansichten ausgeben und ich kann mir auch nicht vorstellen, dass sie als Leser oder Autorenfeld greifen.


Und ja, zum Entschlüsseln reicht ein Schlüssel, zum Verschlüsseln braucht man hingegen alle Schlüssel die in SE-  bzw. PE-Keys stehen.

Scheidet ein Mitarbeiter aus, hat man ein Problem (bzw. Person muss aus PE-Keys entfernt werden)
Hat man einen SE-Key nicht, muss man ihn sich von der Person zukommen lassen, die ihn erstellt hat oder aus SE-Keys entfernen.

Kommt man auf die Idee, sich einfach selbst einen SE-Key mit gleichem Namen zu erstellen, kann man das Dokument zwar verschlüsseln, bekommt aber später einen Support Call warum es der ursprüngliche Autor nicht mehr entschlüsseln kann, ob wohl es mit dem Namen von seinem SE-Key verschlüsselt wurde.


--- Zitat ---ich muss die verschlüsselten Felder ändern. (Neue Berechtigungen hinzufügen, wenn z.B. neue Mitarbeiter eingestellt werden.)


--- Ende Zitat ---

Erkläre mir das bitte. Sollte es sich um Leser-Felder handeln, kann ich mir nicht vorstellen, dass das funktioniert (der Dominoserver sieht die Felder ja nicht)

VG Roland

Legolas:
Hallo pram,

ich versuch es mal zu erklären:

Ein Dokument hat ein Richtextfeld das verschlüsselt wird. (Eigenschaft: "Verschlüsselung für dieses Feld aktivieren" ist aktiviert  -> Rote Eingabefledkennzeichnung)
Der aktuelle Bearbeiter definiert über ein Namensfeld, welche Kollegen/Gruppen ebenfalls Zugriff auf das Feld haben sollen.
Beim Speichern des Dokuments werden dann die Gruppen aufgelöst und in das Notes Systemfeld "PublicEncryptionKeys" (in der Form Abbreviate) eingetragen.
Beim Speichern wird dann noch der Befehl call doc.encrypt aufgerufen. (Mus das überhaupt sein?)
Das wars.

Nun die Herausforderung:
Ändert sich nun die Mitglieder der im Dokument eigetragenen Gruppen, so muss die Berechtigung auf das Richtextfeld neu mit einem Backend Agenten (runonserver) gesetzte werden.
(Gruppen und Einträge die im Namensfeld stehen neu auflösen und in das Feld PublicEncryptionKeys eintragen.)

Anmerkung: Es werden keine Autoren und oder Reader Felder in der Form verwendet.
Alle Anwender dürfen das Dokument öffnen und alle Felder außer dem Richtextfeld sehen. (Das ist ja verschlüsselt und ist somit ausgeblendet. --> Außer sie sind im Namensfeld eingetragen und haben somit auch Zugirff auf das Richtextfeld.)

Ich hoffe das ist verständlich genug!  ???

Grüße
Bernd

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete