I must be missing something obvious here but after taking every precaution to make a database secure, (readers fields, authors fields, encrypted the database on the server, control over access to server and certificate authorities, etc. etc.) a user can simply copy the entire database to their local machine with File/Database/Copy (or just replicate it)!!
I realize that users who have access to the database have access to the information, but having access to the inforamtion while at their place of work is one thing, but being able to copy the database to a note book and walk out the door is another.
Subject: How can a database ever be secure if you can use File/Database/Copy??
Yes it is hard to prevent data from being exported from the server.
Notes/Domino has several security features. It is important to understand what they should be used for, and when.
You have the ACL on the databases that mainly controls access to the database on a server.
There is the possibility to use Readers fields, that will restric who can read/replicate specific documents.
With encryption it is possible to further secure data from unauthorised access.
The problem/feature is that if a user can access a document at the server, he/she will be able to replicate it to a notebook and access it there.
From release 6 you can use the restrict copy/replicate document feature of the ACL, but that will not stop anybody from performing a file copy of the database.
Hopefully this gives you an idea of the concept, or maybe you already know all this.
Subject: RE: How can a database ever be secure if you can use File/Database/Copy??
Hm…
in a normal fileserver environment… a user puts a floppy disk into a floppy disk drive and copies data … and walks away.
in the same environment he uses a USB memory stick and walks away, burns a CD and walks away…
in a paper-only environment the user copies some paper documents and walks away …
So what’s the problem?
In most companies the user can just mail internal data via E-Mail into the whole world!
So a database can’t be considered SECURE ever.
Suggestion: So you want the user only to read documents if he/she’s at work. Document property box works everytime - so data retrieval is always possible.
If you REALLY want to secure the data you have to encrypt it.
It’s time consuming - so be warned. Here’s ONE idea. Let the users make inputs on forms. But don’t save the items clearly readable in a background doc. Eighter you use a second doc just to save the data encrypted or you do it in the same document - encrypted too. You can use the QuerySave Trigger to create the encrypted fields and delete the input fields from the background doc. When opening the doc you have to decrypt the data and put back into editable fields. This prevents the user from getting Info through the document property box.
Now how to prevent the User from reading docs locally? Let the decrypt routine check for server availability, look if the database is on server and so on. You may even consider a session handling where user have to authenticate to a 2nd database manually with your own account/password handling or a timeframe where certain documents can be viewed (only at work time). ONLY if all the criteria are met - decrypt the content.
Of course you will have a very short lifetime of your notes ID’s to make sure they ar not abused and strong passwords and … you know all those little helpers you got.
Good luck!
P.S: But then … replication is a key feature of Notes… Be aware you have to take replication into account when implementing this.
P.P.S: You may consider using a web-driven solution with DOLS disabled databases too. So no replication possible.
P.P.P.S: But again: nobody can prohibit printing the docs from the browser then.
Subject: RE: How can a database ever be secure if you can use File/Database/Copy??
THANKS!!
I’m still getting upto speed on 6.x (been a 4.6 developer for ages). I always wondered why this options was never there from the begining.
As a side question, when the “enforce consistent access across all replicas” is turned on, why isn’t an the individual user’s public key stored in the ACL?
The reason I ask is because one could create a new organizational certifier to match the name of an existing one, create a new ID file with the same name as a manager listed in the ACL, and you can use that new ID file can be used to access the ACL of local replicas and change it. And all users had access to the database/server admin tools so they could quickly create an organizational certifier to do this.
I realize that local security info will not be passed upto the server, but this can then be used to bypass readers fields so that documents that should not be read can be and can be a problem when there are several users using a local replica on a note book for example.
If the public key is stored, then all users are authenticated against that, rather than just the text of their name, and that is obvisouly better.
Subject: RE: How can a database ever be secure if you can use File/Database/Copy??
Hi,
one thing you have to keep in mind while developing applications is a difference between real security mechanisms and only “pseudo” security (which is often used and is in many case sufficient :-)))
For example the “database ACL” ,“Reader fields” or “encrypted/signed fields” are real security features that cant be “broken” wheres “Consistent ACL” or “unsecured document not visible in views”,“Prevent copy/print forward” or “controlled access sections” are not.
To your idea it is true that everybody can creatre a replica/copy of a database and once locally he can get access to all of its documents and modifie them. However documents that are protected from him through reader-fields WONT be copied to his local replica from the server. Therefore he has no chance to get the content… Even if he manages to modifie some of the local documents the ACL will prevent him to get this changes back to the server.(and if he wants to replicate them back he cant use his self-generated id file :-)))
(Interesting idea is a case where someone has access to a reader-field protected document , replicates it locally and then this access is revoked on the server. I dont know exactly if the document is really deleted from the local database on next replication. Worth testing … )
From the above said results:
If you want to protect some content from a users you have to store it in a separate reader-protected document
If you need to store it inside of a document he can access you have to encrypt it
Everything else is NOT secure
One more thing to the idea to use the new ACL attribute “Can Replicate or Copy Documents”.
Be carefull to switch it off as if you do so, all documents that your users create will have automatically a $KeepPrivate field that will prevent the document from printing and drive your users crazy.
Subject: RE: How can a database ever be secure if you can use File/Database/Copy??
[As a side question, when the “enforce consistent access across all
replicas” is turned on, why isn’t an the individual user’s public key stored in
the ACL?]
Now there’s an interesting idea.
Actually, a replication setting on the NSF to force all client replicas to be
encrypted locally would also at least partially address this.
As for your actual business case, I don’t think I’d ever permit a secure
application to be used by multiple users on the same notebook. God help you if
the wrong user replicates with the server.