Securing your CxO's mail file

In a recent customer session the question popped up: How can you really secure your inbox against unauthorized access including access by nosy admins. The admin part can be particularity hard since by definition administrators should have the ability to administrate which can mean to access your file. In Domino you actually can lock down the environment, even if you have to go quite a number of steps. It is a typical case of "who controls the controller" This is my wash-list

1. Encrypt the database on the server
   This encrypts the database, so on the server only the server.id can access this database. On a server this is what actually happens. The server task identified by the server.id is the only one that actually accesses the database (physically). All other server or users get access via that server. Encryption here protects the database from being stolen physically (e.g. when the server is shut down and the NSF is copied or someone gets hands on a backup tape)
2. Set the property: Enforce consistent ACL
   This enables local security. So anybody who might have access to the database in an un-encrypted location can't open it if the name is not in the ACL.
3. Remove any group or wildcard entries from the ACL
   That is a little bit a tricky one (and somehow dangerous). Typically the group LocalDomainServers and LocalDomainAdmins is in the ACL. So an attacker could bribe the admin and get her name added to the group. Without the group entry that is not a possible attack vector anymore. Of course you need to make sure that all servers (especially in a cluster environment) where the mailfile is have access to the database.
4. Ensure that all ACL entries have an entry type
   Since we have removed all groups only the entry types "Person" or "Server" would be feasible. The only 2 entries without a type are -Default- and Anonymous which both are anyway set to "No Access". This setting prevents that someone accesses the mail file as a user using a server id.
5. Limit access to hardware
   As the old rule goes: if you can't touch it, you can't break it. Good practice here is also to give server ids a password, so if someone gets a copy of an server id (stolen backup tape) it wouldn't help.
6. Switch on "Compare Public Keys"
   in the server document. This prevents an attack using a forged or outdated ID file. An ID file can be forged if someone stole the cert.id and the cert.id password. (Which should be fiercely protected anyhow).
7. Secure your certification process
   Several steps here: make sure your cert.id has multiple passwords (I suggest 6 passwords with 2-3 needed). So no single person can create new users on her own. Also implement the CA process and actually remove the cert.id from access of anybody. Move the creation of users into the responsibility of a different group than server administration. This limits temptation to play with black accounts.
8. Set preferences to: Encrypt incoming email.
   With this option set all incoming messages will be encrypted. Even if and admin gets full access.... without the notes.id she can only read the subject lines but not the content of the messages.
   
   Use that with care and proper ID management. If the Notes.id gets lost so go the messages!

In theory that would be all.... If IBM hadn't on pressure from the users introduced the concept of "FullAccessAdmin". As the name nicely goes... the Full Access Admin has full access. So to go full circle measures have to be put in place to safeguard the activation of "FullAccessAdmin" mode. Here you go:

1. Create a special user
   for the sole purpose of being the full access admin. Slap multiple passwords on the ID. Make sure it is locked away and never stays unattended. Make sure only that name is in the full access admin field in the server document.
2. Lock down your name and address book
   Demote access to the NAB or put other measures in place (a loooong topic) to make sure an admin can't change the server document to add him as full access admin.