Einschätzung Sicherheitsrisiko Domino Server direkt im Internet

Die Frage, ob ein Server sicher ist oder nicht, ist nur der halbe Weg. Aus meiner Sicht viel wesentlicher ist die Frage, welche Daten drauf liegen und ob, bzw. in welchem Umfang man damit Unfug anstellen kann. Einen Server zu knacken, nur um "Allerwelts-Daten" zu finden, das ist kein großer Gewinn.

Daraus folgt, dass "Sicherheit" auch immer mit der Überlegung des Aufwandes verbunden ist. Gehen wir mal davon aus, dass die Jungs und Mädels bei der CIA und im Pentagon wissen, was sie tun. Dennoch wurden ihre Server geknackt. Ganz sicher auch aus der Motivation heraus, dass es da etwas zu holen gibt.
Hast du als Freiberufler Kundendaten, wie Adressen, Angebote, etc. drauf liegen, ist sicher etwas mehr Aufwand angebracht, als wenn nur deine private Korrespondenz wie Mails deiner besseren Hälfte drüber gehen oder abonnierte Mailinglisten da auflaufen.

Selbst wenn du einen weiteren Server vor deinen Domino stellst, heißt es noch lange nicht, das das Gesamtkonstrukt sicherer wird. Jedes weitere Glied in der Kette erhöht die Komplexität, damit den Aufwand, den benötigten Skill und damit auch die Fehleranfälligkeit. Die Folgerung "mehr Maschinen = mehr DMZs = sicherer" ist so in der Form ganz sicher nicht korrekt.

Und schlussendlich: es spielt nicht wirklich eine Rolle, ob es in der Vergangenheit Angriffe auf einen Service gab oder nicht. Denn es gibt nur zwei Erklärungen, warum es keine oder kaum Angriffe gab: entweder die jeweilige Software ist sicher, dann muss man sich auch keinen Kopf drum machen. Oder potentielle Angreifer wissen, dass mit der feindlichen Übernahme des Services eh nichts zu holen ist. Dann spielt es auch hier keine Rolle.
Allerdings ist die Denke "bisher gab es keine Angriffe auf SMTP" auch nur die halbe Wahrheit. Ein Postfix unterscheidet sich zu einem Exim und der wieder zu einem Domino. Ein Service, der auf Port 25 lauscht kann sicher sein, ein anderer ärgerlicherweise nicht. Insofern ist immer eine Betrachtung der jeweiligen Software angeraten.
Zumal Ports jetzt auch erstmal wenig über die darauf lauschende Software aussagen. Ich kann einem Apache beibringen, auf Port 1352 nach Anfragen zum Ausliefern einer Website zu lauschen. Dass high ports häufiger oder seltener nach Exploits geprüft werden als Standardports, auch das sei einmal dahingestellt.

Sicherheit ist nicht die Anhäufung von Maschinen und die Erhöhung der Komplexität. Sicherheit ist ein Konzept, das oftmals nur auf genau den einen Anwendungsfall zutrifft und bei einem anderen wieder andere Maßnahmen bedingt.

Von daher ist deine Frage so ohne weiteres auch nicht zu beantworten.

Ganz so einfach ist es nicht.
Erstmal muss der Agent ja irgendwo herkommen, das ist Schritt 1. Hier spielen dann Sicherheitsmechanismen eine Rolle, die weiter drunter liegen. Angefangen bei der Netzsicherheit des Hosters bis hin zur Sicherheit der Linux-Basis.

Dann muss er ausgeführt werden. Da das zunächst einmal nicht mit der ID des Servers oder des Admins passieren wird, ist das Schritt 2.

Schritt 3 wäre dann die Config so zusammen zu bauen, dass Agenten ausschließlich mit einer ID laufen dürfen, an die ein potentieller Angreifer nicht heran kommen kann.

Schritt 4 wäre, die Dokumente mit 2 IDs zu verschlüsseln, wobei eine für den Agenten physisch nicht zu erreichen ist.

Und wenn dann immer noch Gefahr zu vermuten ist, bzw. wenn das Kind schon in den Brunnen gefallen ist, bleibt halt nur noch der Austausch aller Zertifikate.

Wie gesagt: Sicherheit ist ein Konzept, hinter dem auch, aber nicht nur, die Frage steht, wie viel Aufwand man betreiben möchte oder muss und wie viel Ressourcen man dafür einsetzen kann.

Im Eigenschaften-Dialog der Form kannst du auf dem letzten Tab kannst du einen oder mehrere "Default Encryption Keys" (oder wie auch immer das im deutschen Client heißen mag) mitgeben. Mit diesen Schlüsseln werden dann neue Dokumente vercryptet.
Weiters kann du via LotusScript über notesDocument.Sign auch noch Dokumente verschlüsseln.
Und selbstverständlich geht das auch auf Feldebene.

Ob der Server Manager sein muss, kommt drauf an. Prinzipiell ist es schon ratsam, einen Adminserver einzutragen. Wenn aber klar ist, dass der AdminP niemals in der Domain gebraucht wird, brauchts eigentlich auch keinen Adminserver und der Task kann deaktiviert werden. Allerdings wäre ich damit vorsichtig. Von Namensänderungen etc. einmal abgesehen, brauchts den AdminP auch noch für andere Dinge. Ob es ratsam ist, den AdminP auszuknipsen, kann ich dir ehrlich gesagt nicht sagen, das hab ich noch nie ausprobiert. Jetzt mal so aus dem Bauch heraus gesprochen würde ich sagen, dass das auch ziemlicher Overkill wäre. Lieber an anderen Stellen ansetzen, die u.a. auch von IBM in den einschlägigen Dokumenten empfohlen wird. Meine Meinung: lieber eine saubere 95%-Lösung, als mit Ach und Krach auf 99% kommen und unvorhersehbare Probleme bekommen.

Für die eine oder andere Frage recht nützlich: Penetration: from Application down to OS