ADMIN-ECL für Entwickler

[EUWE_MAX]

Ich habe eine Entwickler-ID zum Signieren der inote6.ntf.

Um irritierrende Sicherheitsalarme in Sachen vertrauenswürdig zu vermeiden, möchte ich mit RefreshECL die Entwickler-ID auf die Workstation-ECL übertragen.

Andererseits betrachten unsere User Rechte an 3. immer sehr argwöhnisch.

Welche minimalen Rechte muss ich dem Entwickler in der ADMIN-ECL gewähren, um den gewünschten Effekt sicherzustellen ?

reicht "Zugriff auf aktuelle Datenbank" ?!


Danke Max

[Lossa]

Hallo,

das kommt auf den Code an, der von dem signierten Designelement ausgeführt werden soll.
Am einfachsten kriegst du das Update hin, indem du mit Profildokumenten arbeitest diese kannst du vom Server unterzeichnen lassen, sofern dieser in den ECL's der User drin steht.
Ansonsten solltest du deine Anwender klipp und klar darauf aufmerksam machen was ein Sicherheitsalarm bedeutet, und nur autorisierter code automatisch läuft. Somit ist immer gewährleistet, das nicht falscher oder missbräuchlicher Code im Client ausgeführt wird. Nach dieser Auflklärung kannst du dann eine Signatur in die ECL der Anwender einstellen und dein Problem ist erledigt. Dies ist der offizielle Weg, den ich dir Empfehlen kann, immer mit offenen Karten spielen und den Anwender sensibilisieren für diese Art Meldungen.

[MartinG]

Wobei ganz so einfach ist das in der Praxis ja nicht - klar ist es unter Notes6 am sinnvollsten die ECL per Policy zu verteilen.

Die andere Seite der Geschichte ist das man -zumindest sind das meine Erfahrungen- relativ häufig die ECL so einstellen muss das bei -No Signature- ebenfalls relativ erlaubt wird. Wir haben z.B. diverse Datenbanken über welche exteren Worddokumente geöffnet werden. Bei JAVA Applets genauso... - nur auf die ECL Sicherheit würde ich nicht so sehr setzen.

Gruss
Martin

[Lossa]

@ Martin,
Hi,

Wieso sind die Java-Applets nicht signiert? Ich habe auf diversen Systemen keine Schwierigkeiten mit der ECL und dort ist die ECL komplett dicht und trotzdem läuft alles.
Die ECL ist die einzige möglichkeit Mail-Bomben u.a. aus dem Notes-System fernzuhalten. Das ist ja das tolle an Notes gegenüber hier nicht weiter erwähnten anderen Systemen.
Wir könnnen uns ja einmal über dieses Problem seperat Unterhalten.

[Semeaphoros]

Lossa:
Wie wäre es mit einem Artikel für die Best Practices?

[EUWE_MAX]

"Die ECL ist die einzige Möglichkeit Mail-Bomben u.a. aus dem Notes-System fernzuhalten. Das ist ja das tolle an Notes gegenüber hier nicht weiter erwähnten anderen Systemen."

Hallo Ulrich,   ich versteh nicht, was Du damit meinst..
was kann man da über die ECL steuern ?

Gruss Max

[Lossa]

Hallo,

Mail-Bomben bezeichnen Mails, die beim öffnen Code ausführen und somit alle Arten von Sachen anstellen können.
Da die ECL prüft wer den Code unterzeichnet hat, wird die Ausführung des Codes gestoppt oder der User gewarnt (Standard). Es soll somit also verhindert werden, das irgendwas auf dem Client passiert, das nicht autorisiert worden ist.

[Axel Janssen temp]

Hi Ulrich,

@Martin: unsignierte Applets dürfen bei normalen Sicherheitseinstellungen auf dem Client nichts, was Schaden anrichten könnte (SocketVerbindungen öffnen, JNI-Verbindungen zu OS-Schnittstellen, Zugriff auf Filesystem etc.).

Bei signierten Applets wird der Anwender gefragt, ob er dem Unterzeichner traut oder nicht (ähnlich wie bei Notes).

Bei Java gab es ECL-style Sicherheit (Authentifiziert den Unterzeichner des codes) vor der ACL-style Sicherheit (Authentifiziert den Anwender des codes). JAAS ist erst seit Version 1.4 Bestandteil des J2SE (in J2EE aber schon länger).

Ich kenn mich da nicht wirklich aus, aber ich könnte mir schon sehr gut vorstellen, dass MS.NET oder irgendwelche Linux-Systeme ähnliche Sicherheitsmechanismen kennen.

Gruß Axel