Security ->Lokale Kopie einer Server DB nutzlos machen

[Rob Green]

"Shared Mail databases are encrypted locally with a random key, which is in turn encrypted using the public key from the server's ID. If a user defeats local access protection, he must still use the server ID to open the Shared Mail file. Attempts to disable encryption will fail with the error 13:88, and attempts to reencrypt a Shared Mail file with another ID file will generally render the Shared Mail file useless"

Aus diesem obigen Satz (aus den Knowledge Base) leite ich folgendes ab:
- man kann eine Server DB mit einem aus der Server-ID generierten Key verschlüsseln
- alle User, die per Client auf die Server DB zugreifen, können den Content lesen, da wohl der Server den User wg. ACL reinläßt, und dann die Entschlüsselung selbst vornimmt für den User
- wenn User allerdings eine lokale KOPIE dieser DB tätigt, hat er keine Chance mehr, den Content zu lesen...damit auch das Design (?)

Hat das jemand mal so schon getestet?

Warum das Ganze?
Möglicherweise seid ihr zB mit einer Personal DB Aufgabe betraut worden...am wichtigsten ist dabei der Schutz der Daten..zB Stellenausschreibungs Applikationen...bis R5 incl. konnte man nie eine lokale Kopie der Db verhindern und dadurch war die Gefahr eines unerwünschten Aufdeckens von geheimen Informationen groß.
Über eine Verschlüsselung wird zumindest den normal begabten ein Riegel davorgeschoben.

In R6..btw...da kann man eine Kopie endlich verhindern!

[Rob Green]

es scheint zu gehen..mehr Infos auch dazu, wenn mal der Server crashed (vorher wissen..vorher sichern):

"In order to recreate the server, you need 3 things... a copy of the server id (which you have), the notes.ini and the NAB. If you have the NAB and the notes.ini, you can just reinstall the server code. After you reinstall, put the notes.ini in the notes directory, the server.id in the place specified in the notes.ini and the NAB in the data directory. You SHOULD be able to just restart the server. It should recreate the necessary files that you need (log, mail.box, admin4, etc). If you don't have the notes.ini, you can go thru the setup and point to the server.id and the location of the NAB. It should pull the server document and the ID from those locations. These 2 items (server.id and server document), identify the server and are what you would need to be able to read that encrypted database." (von Judy Ory, LDD Forum 4/5)

[klaussal]

... oder so:

@If(@Name([CN]; @Subset(@DbName; 1)) != "" | @Name([Abbreviate]; @UserName) = "Hugo Klotz/DE";@Return(""); @Do(
@Prompt([OK];"Error"; "Database can only run on server. Please open database directly on server, not locally !!! Please delete database from your local harddisk !");
@PostedCommand([FileCloseWindow]) ) )

ist doch viel einfacher, oder ?  

[Rob Green]

sicher, das ist ein Ansatz für User...
aber, schon für Poweruser ist das ein Leichtes zu knacken

[klaussal]

... dann sag mal den knack-code  

[ata]

... das hat aber meiner Meinung nach noch einen anderen Haken

... was passiert, wenn die DB umzieht?
... oder der Server wird neu zertifiziert?
... und hoffentlich bekommen nur die richtigen Personen Zugang zum Server => Server.ID

... also ich hoffe auf R6  

ata

[Rob Green]

ja, das müßten die Nachteile sein, die es zu bedenken gilt.
Mit R6 ist das wie gesagt kein Problem mehr.

[ata]

... wenn ich das Wort Verschlüsselung höre, dann gehen bei mir alle Alarmglocken an - gerade bei so heiklen Dingen wie diese Personal-DB. Ich habe mir angewöhnt solche DB mit hochbrisanten und sensiblen Daten auf spezielle Server auszulagern und den Zugriff entsprechend zu begrenzen. An die Daten werden dann per Backend gezogen...

ata

[klaussal]

... in der o.a. formel wird doch abgefragt, ob die db auf server liegt oder lokal ( db = ""). wenn ich nicht der user hugo klotz bin, öffnet er das ding doch erst gar nicht lokal. was hat das jetzt mit "server zieht um" zu tun, etc.  und wie könne "poweruser" o.a. die sache knacken ?

[Rob Green]

nun ja, wenn Du mal ne DB für 120.000 Mitarbeiter schreiben mußt, in die sich die MA auf Stellen bewerben, dann geht eine Einschränkung auf "wenige" nun mal nicht. Daher meine Frage nach guten Sicherheitsfeatures.

Klausal, es gibt / gab mal ne Möglichkeit eine DB zu knacken, wenn das Design hidden ist und zwar so, daß Du an alles rankommst. Wenn Du das Design hast, hast Du alles....unabhängig vom hidden design ist die ACL..."konsistente...." , egal, was nun dolles in der ACL eingestellt ist, auch das knackt man schnell (was sie eigentlich in meinen Augen zu keinem echten Sicherheitsfeature mehr macht, wenn man andere, doofe Tools hat). Oder noch einfacher, "damals", in R4.6 gab es mal ne kleine Lücke, mit der man konsistente ACLs simpelst über einen Parameter aushebeln konnte. Nicht mehr und nicht weniger in abgehackten Sätzen zu diesem Thema...

[klaussal]

@rob,

aha, der "poweruser" kommt NUR dran, wenn er den designer hat, sonst nicht. ODER ?

[Rob Green]

und den Designer hat doch mittlerweile jeder, wenn man eine designer.exe hat....nein, nicht die designer.exe  

Eigentlich verstehe ich WFlamme reht gut, der - ok, aus ner anderen Richtung kommend - die mangelnde Security bei Notes beklagt...es ist über das Internet für jeden Poweruser simpelst ohne Ende an Infos zu kommen, DBs zu knacken, alles zu lesen, solange...es nicht verschlüsselt ist ODER man an die Readerfield Einträge rankommt..aber auch da habe ich mir sagen lassen, daß man durchaus die Struktur eines NSF Files recht schnell kapieren kann, wenn man professioneller das ganze angehen möchte...und da interessiert nicht mehr, was die ACL, Design, Readerfields etc machen/verhindern wollen.

So gesehen ist der Zugang zu DBs bis R5 incl. sicherer über den Browser als über Notes Native Clients.

[Jörg P.]

@Rob:
Ich muss dir wiedersprechen:

Eigentlich verstehe ich WFlamme reht gut, der - ok, aus ner anderen Richtung kommend - die mangelnde Security bei Notes beklagt...

Wenn ich wflamme richtig verstanden habe, wird nicht die Notes-Security bemängelt, sondern die mangelnde Konfiguration vieler Dominos, insbesondere im Web.

So gesehen ist der Zugang zu DBs bis R5 incl. sicherer über den Browser als über Notes Native Clients.

Na, Na, Na, übertreiben wir hier nicht etwas. Für den Client spricht hier vor allem die Notes-ID. Ohne ID mit gültiger Zulassung stehe ich ziemlich auf der Rolle.


Natürlich hast du recht, wenn es um die Problematik mit den lokalen Kopien geht. Bis wir R6 im Einsatz haben bleibt daher nur, bei sensiblen Daten Verschlüsselung auf Feldebene und möglichst noch privaten Key zu verwenden.
Wenn jemand weiss, wie das zu knacken ist....


@klaussal:
Deine Prüfung, ob DB lokal liegt, kann nur sicher sein, wenn die Gestaltung verborgen ist und das zugehörige Template in sicheren Händen ist. Mir fällt zumindest nicht ein, wie man das aushebeln sollte. Der Hinweis von Rob mit dem aushebeln der verborgenen Gestaltung funktioniert so nicht. Was sich erreichen lässt ist, das Gestaltungselemente sichtbar werden, aber keinerlei Formeln oder Scripte.


Aber, seeeehr Interessantes Thema.

[klaussal]

@rob,

jetzt aber mal "butter bei die fische"......

[Jörg P.]

@Rob:

man lernt ja nie aus. Gibt's die exe irgendwo frei verfügbar?

Das Thema Security von Notes ist bei uns gerade ganz aktuell, und in einer Sache konnten wir die Aussage eines IBM-Mitarbeiters bereits wiederlegen (so nach dem Motto: Db auf Server lokal verschlüsseln, konsis. ACL, Server ohne Zugriff mit Usertyp Server und dann kommen selbst die Admins nicht mehr ran -> 5 Min haben wir gebraucht, davon vier für die suche nach dem "wie gehts am schnellsten"   )

[Rob Green]

@klaussal, soll ich jetzt die Methoden beschreiben? find ich nit gut..habe schon genug angedeutet, was machbar ist und was nicht. Man findet wenn man sucht, selbst in der Sandbox.

@harvey: soll heissen, die Verchlüsselung bringt auch nix???

[Jörg P.]

@harvey: soll heissen, die Verchlüsselung bringt auch nix???

Nachdem wir die konsistente ACL ausgehebelt hatten, konnten wir über dem auf dem Server installierten Client mit Manager-Rechten auf die DB zugreifen.

[ata]

@Harvey

... die Verschlüsselung auf Feldebene ist das einzigste wirklich sichere Mittel Daten abzuschotten - wer den Schlüssel nicht hat kann das Feld nicht sehen, bzw. darauf zugreifen...

... Verborgenes Design ist kein Sicherheitsmerkmal. Die einschlägigen Wege sind im Internet hinlänglich beschrieben. Zum Aufbohren der DB benötige ich kein Script, da reichen mir die Namen der Masken und felder und deren Eigenschaften

ata

[Rob Green]

ahsoo..das müßte ja eigentlich im Sinne des Erfinders sein, da man mit der ID des Servers die DB öffnet. Oder?

[Jörg P.]

Wenn in der ACL der Server mit "Kein Zugriff" und Benutzertyp "Server" steht und konsistente ACL aktiviert ist, sollte ich eigentlich nicht mehr darauf zugreifen können.