Frage zur Sicherheit auf Feldebene

[TMC]

Hi,

ich arbeite gerade an einer DB, wo ich sicherstellen muss, dass 1 Feld nur Leute lesen, die das auch dürfen.

Bisherige Vorkehrungen:
- Konsistente ACL
- Leserfeld (wenn "", dann @Username)
- Autorenfeld (wenn "", dann @Username)
- Beim zu sichernden Feld: im Propeller-Tab die 'Security-Options' auf 'Enable encryption for this field' eingestellt

War das schon alles?

Muss ich sonst noch was machen, damit niemand Zugriff hat, der nicht im Leserfeld steht?

[-Michael-]

Ist so leider keinesfalls sicher.

Versuche mal folgendes:
Du trägst in dem Leser- oder Autorenfeld den User "ABC" ein.

Dann schließst Du Notes und installierst eine neue Arbeitsumgebung etc., mit dem User "ABC".
Dieser User kann dann das Dokument lesen. Selbst bei konsistenter ACL, da muss halt dann mal schnell ein Hex-Wert geändert werden um Zugriff auf die DB zu bekommen.

[animate]

Ist so leider keinesfalls sicher.

Versuche mal folgendes:
Du trägst in dem Leser- oder Autorenfeld den User "ABC" ein.

Dann schließst Du Notes und installierst eine neue Arbeitsumgebung etc., mit dem User "ABC".
Dieser User kann dann das Dokument lesen. Selbst bei konsistenter ACL, da muss halt dann mal schnell ein Hex-Wert geändert werden um Zugriff auf die DB zu bekommen.

verstehe ich nicht. natürlich kann der User ABC es lesen, wenn er im Leserfeld steht.
Und wenn ein Feld verschlüsselt ist (wie das genau geht, weiß ich nicht mehr) ,dann braucht jeder, der den Inhalt des Felds lesen will, den Schlüssel dazu in seiner ID. Und das ist sicher.
Ich bin zufällig heute über einen ARtikel über Feldverschlüsselung in IrisToday gestoßen, vielleicht ganz interessant in dem Zusammenhang: http://www.notes.net/today.nsf/f01245ebfc115aaf8525661a006b86b9/24d3f7b03bcaf0c388256abb00730519?OpenDocument

[-Michael-]

Schon klar, aber TMC hat oben die bisherigen Umsetzungen aufgelistet.
Und mein Beispiel sollte zeigen, dass man so trotzdem Zugriff hat, wenn der Username bekannt ist.
Sprich die bisherige Umsetzung war auf Dokumentenebene und nicht Feldebene, auch wenn das eine Feld entsprechend so selektiert wurde.

Ich muss gestehen, selbst auch noch nie eine feldbasierende Verschlüsselung implementiert zu haben, daher kann ich da leider keine Tipps geben.

Und afaik bietet - wie Martin schon richtigerweise erwähnt hat - nur die Feldebene eine sichere Verschlüsselung, Server / DB / Doc - Ebene ist afaik nicht absolut sicher.
** EDIT ** Ups, MartinG hat seinen Beitrag wieder gelöscht

Es geht TMC wohl auch - verständlicherweise - darum, dass z.B. ein Notes-Admin dieses eine Feld nicht lesen darf/kann ohne entsprechender ID.

[Semeaphoros]

Wenn die Interpretation stimmt, dann heisst es tatsächlich Schlüssel generieren und an die berechtigten Personen verteilen. Hab ich selber auch noch nie machen müssen. Es gibt aber zur ganzen Sicherheit in Notes ein Redbook von IBM, weiss grad nicht wie es heisst, da geht es um Security ich glaub im R5, das ganze ist aber nicht wirklich geändert worden und kann somit auf alle gängigen ND-Versionen angewandt werden.

[animate]

also ich habs genau einmal gemacht und ich kann mich daran erinnern, dass es ziemlich einfach ist. Der Schlüssel wird per email verteilt und dann irgendwie in die ID importiert (ging auch ganz einfach).

[Semeaphoros]

Jo, soweit ich mich an die Literatur erinnern kann, ist es wirklich keine Hexerei, der Gegenschlüssel legt sich in der Datenbank selber ab und wird beim Speichern zum Verschlüsseln verwendet.

[TMC]

Danke für Eure Infos etc.

Ich werde mir jetzt erstmal den Artikel von Thomas reinziehen, melde mich wieder....

[TMC]

Many thanks, Thomas, sehr guter und praxisnaher Artikel  

Das hilft sehr weiter.

[koehlerbv]

Ist so leider keinesfalls sicher.

Hallo, Michael,

ich mag das jetzt nicht ganz so stehen lassen

Du trägst in dem Leser- oder Autorenfeld den User "ABC" ein.

Das ist aber schon ein gewisser Unterschied  
Autorenfelder bewirken völlig anderes als Leserfelder.

Selbst bei konsistenter ACL, da muss halt dann mal schnell ein Hex-Wert geändert werden um Zugriff auf die DB zu bekommen.

Jetzt bröseln wir das mal auf:
DB hat eine konsistente ACL. Wenn ich mir die DB auf OS-Ebene vom Server (!!!) ziehen kann, habe ich ein paar mehr Chancen (da hat dann aber die Administration versagt). So oder so - die kACL lässt sich knacken.
Ist die kACL lokal geknackt, kann ich Dokumente, die ich eigentlich nicht bearbeiten soll, doch bearbeiten. Nützt mir aber nix: Der Server lehnt diese Änderungen bei der Replikation schlichtweg ab.
Habe ich eine OS-Kopie (!!!), kann ich natürlich dann auch Dokumente lesen, in dem ich nicht als User / Gruppe / Rolle in  einem leserfeld eingetragen wurde.
Der Punkt ist also: Die DB muss auf dem Server geschützt werden. Kann ich "nur" replizieren, bekomme ich auch
- keine Dokumente, die ich nicht lesen darf und
- darf keine geänderten Doks zurück replizieren, bei denen ich kein Autor bin.

Unbeschadet davon ist aber der eigentliche Punkt dieses Threads: Bestimmte items sollen nur im Zugriff (lesend und schreibend) der Berechtigten sein. Wie schon von den verehrten Kollegen vorher beschrieben, bietet Notes hier hinreichend Bordmittel an. Darüber hinaus kann man die Inhalte von Items ja auch selbst verschlüsseln ;-)

Bernhard

[TMC]

@Bernhard:
Ich denke Michael wollte mit seinem Beispiel mehr zeigen, wie unsicher das ganze ist. Und dem kann ich nur zu gut folgen.
Worst Case (bei meiner oben erwähnten Konstellation):
Ein Admin hat sich sämtliche Passwörter (oder TAN-Listen vom Onlinebanking, oder was auch immer) so abgelegt, und repliziert sich die DB aufs Notebook. Für einen Dieb wäre es ein einfaches, so an die Daten zu kommen.
Da hilft die ganze serverseitige Absicherung nix, wenn die berechtigten User replizieren und die DB dann in falsche Hände kommt.

@All:
Ich habe die feldbezogene Verschlüsselung jetzt erfolgreich umgesetzt, u.a. anhand dem von Thomas erwähnten Iris Today - Artikel.

Ist ja im Prinzip verdammt einfach umzusetzen.

Will man Verschlüsselung auf Secret Key - Ebene: Ein Feld "SecretEncryptionKeys" ergänzen.
Will man Verschlüsselung auf Public Key - Ebene: Ein Feld "PublicEncryptionKeys" ergänzen.

Das ist dann auch egentlich schon alles. Die Secret Keys muss man dann über File / Tools / UserID erzeugen und entsprechend verteilen.

In meinem jetzigen Projekt biete ich beides zur Auswahl an (per Radio-Button).

Eine Einschränkung über die ich gestolpert bin: Ich hatte im PostSave zusätzliche call doc.save(false,false) drin, dadurch wird das Dok dann nicht verschlüsselt. Daher hab ich diese ins Querysave verschoben.

[Semeaphoros]

Und was man nicht vergessen darf, mit den Secret Keys ergeben sich logistische Aufgaben: Das Verteilen von Schlüsseln und man denke daran, was man machen muss, wenn ein User nicht mehr drauf zugreifen darf, einen Schlüssel zurückziehen geht nicht, man muss dann neue Schlüssel verteilen

[TMC]

Genau.
Anders herum ist es halt schon verdammt sicher mit Secret Keys zu arbeiten, weil dann nicht mal Admins Zugriff haben, die 'nur' die alte ID mit Passwort des Users haben.

[MartinG]

Da kann ich Dir nur zustimmen - vor allem da ja ab Notes6 die Admins den Full Access Administrator aktivieren können was ich schon für sehr heftig halte. Ab Notes6 hebelt der Admin halt mit einem einzigen Mausklick die ACL, Leser- und Authorenfelder, Rollen etc aus....

Klar kann man immer argumentieren das ein Admin eine Vertrauensperson sein sollte - nur manchmal scheiden auch Admins aus der Firma im Ungroove aus...

Gruss
Martin

[Semeaphoros]

Na ja, Martin, das stimmt schon, IBM hat den Superadmin allerdings nicht ganz freiwillig gemacht, das kam vom Kundendruck und zudem ist das ja sehr konfigurierbar, mit einer einzigen Ini-Variablen kannst Du das Ding abschalten, und um die zu verändern, brauchst Du Betriebssystem-Access. Denkbar ist auch, dass man für den SuperAdmin nur eine ID zulässt, die doppelte Unterschrift trägt (sprich 2 Passwörter) oder noch mehr, man kann das also schon recht gut steuern, aber tun muss man es und vor allem gut planen.