We all have secrets. Of course, some people (and companies) have more secrets than others. For example, consider an oil company. Its messaging system likely contains a wealth of information that has both intrinsic value (e.g., plans for drilling in specific fields) and competitive value (e.g., how much oil the company has in reserve, when it plans to perform preventative maintenance on key facilities). You can easily come up with examples from whichever field your organization is in: government, education, banking, health care--all have sensitive data that needs protection.
Of course, Exchange Server has a ton of features aimed at protecting sensitive data from outside attackers. But what do you do when your data is so sensitive that you need to shield it even from your own administrators? Security experts will chorus, "If you can't trust your administrators, they shouldn't have administrative privileges!" This is absolutely true--and beside the point in many environments. Unfortunately, even when you take care to screen your administrators, sufficiently valuable data can serve as a temptation (or threat) that might exceed a person's ability to resist. Sometimes, it's simply better to be safe than sorry.
One obvious approach is to prevent administrators from opening mailboxes that don't belong to them. By default, Exchange Server 2003 and Exchange 2000 Server add a Deny ACL to Information Store (IS) databases for administrators. Although the Microsoft article "XADM: How to Get Service Account Access to All Mailboxes in Exchange 2000" ( http://support.microsoft.com/?kbid=262054 ) describes how to work around this ACL, each of the described workarounds has a countermeasure. To protect against administrators who add their accounts to the Exchange Domain Servers or Exchange Services security groups, regularly audit those groups' memberships. (Exchange 2003 also removes manually added accounts from the groups, but don't use that as a substitute for a good audit procedure). To protect against changes to the ACL on the mailbox databases, audit object access on those objects, then look for permission or ownership changes.
Another potential approach is to sharpen the distinction between Exchange administrators and Windows administrators. Exchange administrators don't need Windows administrator rights, and vice versa. At many organizations, the same people fill both roles, but if security is a big concern for you, consider separating the roles as often as you can.
After you've reduced the number of people who have administrative privileges, you can gain even more security by preventing lone administrators from accessing data. A common tactic is to create a complex administrative password, split it into two halves, and give each half to a different person so that they must work together to enter the password and log on.
If you're thinking that you could encrypt sensitive data with a key that administrators don't have--for example, by putting the Exchange databases on a partition protected by the Windows Encrypting File System (EFS)--you'll have to think again. Unfortunately, that tactic doesn't work well for Exchange, and Microsoft doesn't officially support the use of Exchange with EFS (although it does support the use of EFS with Microsoft SQL Server 2000). You might be able to make this approach work, but I don't recommend using EFS with Exchange in production. However, you can force the use of Secure MIME (S/MIME) encryption for all users. Doing so will encrypt newly created messages but won't protect existing email and might be difficult to enforce (especially when you need to protect email going to and from the outside world).
The real problem, of course, is that these measures only scratch the surface. A determined administrator might attack in a number of other ways: by sniffing network traffic, grabbing backup tapes and restoring them offsite, or installing keystroke logging software or hardware. The bottom line is that if an untrustworthy administrator gets loose on your network, there's no way to guarantee the security of your systems or data. Still, every effort counts when it comes to protecting your data.
