Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Avoiding Data LossPlanning for Recovery

Before EFS is used, a recovery plan should be developed and put into place. Unfortunately, EFS is enabled by default, and few organizations create and implement an effective EFS policy before users are logged on to the system. Users can easily encrypt and decrypt files without realizing that they should be archiving keys. Using EFS to encrypt and decrypt files is easy. On the other hand, while recovery is not difficult, it requires thought and potentially substantial action. Private keys must be archived and protected.

Recovery Plans for Standalone Systems and Domains Without CAs

It will be difficult to institute a plan for EFS file recovery based on end users' archival of EFS keys. Most users don't back up their data and aren't expected to do so. Data is often stored by policy on network servers and backed up by using automated programs and dedicated staff. When standalone systems are used to encrypt files with EFS, there is no centralized mechanism for archiving keys. (In a domain environment, other options exist.)

Unless EFS is restricted to a few users, it will be impossible to create a workable and sustainable EFS key archival plan.

Classic EFS, as implemented in Windows 2000, attempts to solve this problem by requiring the presence of a recovery agent before encryption can occur. On the standalone machine, this recovery agent is the local administrator. In the Windows 2000 domain, it's the first administrator who signed on after the first DC in the domain was dcpromoed. The recovery agent public key is used to encrypt every FEK; the recovery agent's private key can be used to recover all EFS-encrypted files. In a perfect world, there is no need for archived end-user encryption keys. The recovery agent can be used to recover EFS-encrypted files for which the original end user's keys are damaged or lost. For extra insurance, a recovery plan need only include the archival of the recovery agent keys. However, where all computers are standalone, archival of these keys presents the same problem that archiving end-user keys does: There is a unique recovery agent for each stand alone system. Furthermore, many of the reasons that can cause end-user keys to become damaged and lost can also impact recovery keys, so the archival of these keys is important. Windows XP and Windows Server 2003 standalone systems do not automatically create a recovery agent, and the existence of recovery agent keys is not necessary for encryption. In all cases, the recovery plan depends on the scrupulous archival and maintenance of asymmetric keys.

NOTE: Public Key Policy Resides at the Domain Level

Public key policy is configured at the domain levelthat is, recovery agents are created by default in the PKI policy of the domain. A forest-wide public key policy on recovery can be technically controlled by implementing PKI and controlling the assignment of recovery certificates.

Another problem with this plan is that on the standalone computer, the recovery keys are present on the local hard drive. That means that a Windows 2000 laptop has not only user keys but also recovery keys traveling right along with it. If the laptop is stolen, there are two chances to subvert the process and decrypt the files. If the password to either the user's account or the local administrator's account can be cracked, the thief has access to the file. The legitimate administrator also has free and easy access to encrypted files, either as recovery agent or by changing the password of the user account and logging on as the user.

Windows XP Professional and Windows Server 2003 attempt to correct this issue by removing the requirement for a recovery agent. This means that XP Professional in a domain will use a recovery agent if one is present, but a standalone Windows XP system does not have a recovery agent. Another change in Windows XP Professional and Server 2003 is that on a standalone machine, if an administrator resets the user's password, the association with the public key set is lost. Even though the administrator can now log on as the user, he cannot decrypt the files. (Should this accidentally occur, if the user has a password reset disk, she can use it to reset the password to the original one and thus can decrypt her files.) Ordinary password changes made by the logged on user do not cause a problem with EFS-encrypted files. In a domain, of course, the user's password may be reset with no ill effect.

The fact that there is no recovery agent in a standalone system means there is no fall back if the user's keys are destroyed or if the user forgets his password and doesn't have a password reset disk. The EFS- encrypted files cannot be decrypted. To ensure a recovery strategy, each user's EFS keys must be archived.

Recovery Policy and Disabling EFS

In Group Policy, the Encrypting File System policy can be used to disable EFS or to manage the recovery agent certificates. This policy is located in local or domain-based Group Policy in the Windows Settings, Security Settings, Public Key Polices container. The recovery agent certificate(s), if present, can be viewed in the policy, as shown in Figure 6-15. The certificate information shows the account assigned as the recovery agent. On a standalone Windows Server 2003 and Windows XP Professional computer, by default, there is no Encrypting File System policy recovery agent, as shown in Figure 6-16. However, the property page of the policy can be used to disable or re-enable the use of EFS on the system.