Domino 9 und frühere Versionen > ND9: Entwicklung

Verschlüsseltes Feld PublicEncryptionKeys im Backend aktualisieren

<< < (3/3)

pram:

--- Zitat von: Legolas am 19.02.18 - 11:54:06 ---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.)

--- Ende Zitat ---

Du willst also neu verschlüsseln - also die Verschlüsselung "aushebeln"

In unserer Anwendung, die Verschlüsselung verwendet, bedeutet: "Verschlüsseltes Dokument: höchste Vertrauensstufe"
Da ist es so, dass beim Speichern die Namen aufgelöst werden und der aktuelle Bediener sich im Klaren ist, dass er genau jetzt und für den angezeigten Personenkreis das Dokument verschlüsselt. Sollte sich die Gruppe ändern, wird das Dokument lediglich geflaggt, dass eine erneute Verschlüsselung erforderlich ist. Das Dokument muss dann von einer berechtigten Person geöffnet werden und neu gespeichert werden (auch dabei wird die Person in Kenntnis gesetzt, wer das Dokument jetzt entschlüsseln darf)
Eine Aktualisierung der Verschlüsselung durch den Server erfolgt bei uns nie, da dies ein Sicherheitsrisiko dar stellt, der Admin kann durch Ändern von Gruppen die Verschlüsselung ganz einfach aushebeln. Da ist es besser, man verwendet Lederfelder.

Genau das willst du aber in deinem Fall. D.h. der Server muss das Dokument entschlüsseln und wieder verschlüsseln können. Damit er es entschlüsseln kann, muss der Server mit in PE-Keys stehen, die Verschlüssselung würde in Deinem Fall auch funktionieren, da du die Gruppe (welche in einem anderen Feld steht) einfach aufläöst. Sicherheitstechnisch bringt dir das Ganze aber eher wenig. Da es mit wenig Aufwand von Admins umgangen werden kann.

Was spricht in deinem Anwendungsfall eigentlich gegen Leserfelder?

VG
Roland

Andrew Harder:
Ich denke mal das Leserfelder nicht gewünscht sind, weil mehr Personen das Dokument sehen können sollen, aber nur ein eingeschränkter Kreis dieses eine Feld.
Da hätte ich genau das Gleiche gemacht wie Bernd es getan hat.

Gut die ServerID hätte ich wohl nicht hinzugefügt, aber das mit dem "SuperAdmin" hätte ich genau so gemacht.
Irgendwer muss ja die Leserechte haben, damit er da notfalls wieder was ändern kann.

Es geht jetzt nur noch darum, das ein Feld neu berechnet werden muss und ich gehe davon aus, das bereits das funktioniert.
Beim speichern meckert dann der Agent, das der Server das Dokument nicht entschlüsseln kann.

Jetzt ist die Server ID ja keine normale ID, daher meine Frage hierzu:
Läuft das Ganze ohne Fehler durch, wenn der "SuperAdmin" den Agenten - in der Agentenliste und mit Sicherheitsstufe 2 - von Hand startet?

pram:

--- Zitat von: Andrew Harder am 21.02.18 - 22:18:35 ---Ich denke mal das Leserfelder nicht gewünscht sind, weil mehr Personen das Dokument sehen können sollen, aber nur ein eingeschränkter Kreis dieses eine Feld.
Da hätte ich genau das Gleiche gemacht wie Bernd es getan hat.

--- Ende Zitat ---

ja, so gesehen macht das Sinn


--- Zitat von: Andrew Harder am 21.02.18 - 22:18:35 ---Jetzt ist die Server ID ja keine normale ID, daher meine Frage hierzu:
Läuft das Ganze ohne Fehler durch, wenn der "SuperAdmin" den Agenten - in der Agentenliste und mit Sicherheitsstufe 2 - von Hand startet?

--- Ende Zitat ---

Ich denke, auf sowas wird es raus laufen. Wichtig: (aber ich denke das ist inzwischen schon rüber gekommen) - wenn der Agent periodisch ausgeführt werden soll, muss der Server drin stehen - ein Signieren des Ageneten mit einem anderen Benutzer funktioniert nicht (da der Schlüssel zum Entschlüsseln ja in der BenuterID gespeichert ist)

Legolas:
Hallo Ihr Zwei,

mit Euren Vermutung habt ihr recht.

Starte ich den Agenten im User Kontext. 
--- Code: ---call agent.run()
--- Ende Code ---
funktioniert das Ganze.

Es gibt dann aber zwei große Einschränkungen:
1) Der Agent muss manuell gestartet werden.
2) Es werden natürlich nur die Dokumente aktualisiert, auf die der aktuelle User Zugriff hat.

Das ist zwar eine Lösungsmöglichkeit, die ist aber leider nicht sehr schön. Soweit ich das nun aber überblicken kann, wird es wohl keine andere Möglichkeit geben.

Grüße und Danke für die Unterstützung
Bernd

pram:

--- Zitat von: Legolas am 22.02.18 - 08:56:37 ---2) Es werden natürlich nur die Dokumente aktualisiert, auf die der aktuelle User Zugriff hat.

--- Ende Zitat ---

Das wäre bei einem Serveragenten aber genau so. Du musst in eine Fall sicherstellen, dass der Server im Leserfeld ist, im anderen Fall, dass der SuperAdmin drin ist. (oder dem SuperAdmin ermöglichen, dass er in den Full Access Mode wechseln darf)


--- Zitat ---Das ist zwar eine Lösungsmöglichkeit, die ist aber leider nicht sehr schön. Soweit ich das nun aber überblicken kann, wird es wohl keine andere Möglichkeit geben.

--- Ende Zitat ---

Wie gesagt, könntest du den SuperAdmin durch die ServerID ersetzen, hast halt dann das Problem, dass du alle Dokumente neu verschlüsseln müsstest (was aber dein Agent schon kann *1).
Bedenke aber auch, dass Server einmal ersetzt werden oder auch der SuperAdmin aus dem Unternehmen ausscheidet.

Wäre es vielleicht möglich, für dein Vorhaben eine technische Notes-ID anzulegen. Der SuperAdmin der i. D. R. mit seiner persönlichen ID unterwegs ist, hätte dann keinen Zugriff und die Neuberechnung müsste er dann mit der technischen SuperAdmin ID erledigen.

*1) Falls du wirklich vor hast, die Verschlüsselung vom jetzigen  SuperAdmin zu einer andere ID zu übertragen, beachte bitte Punkt 5 - der SuperAdmin wird das Dokument noch immer entschlüsseln können, wenn er der letzte war, der es verschlüsselt hat.

Beachte bitte auch, falls du weitere Backend-Agenten/Aktionen hast, dass du sicherstellst, dass diese unmittelbar vorm doc.save ein doc.encrypt aufrufen - sonst hinterlassen sie (wegen 6.) möglicherweise das Dokument in einem unverschlüsselten Zustand


Gruß Roland.

Navigation

[0] Themen-Index

[*] Vorherige Sete