Educating the users on proper use of EFS is a good step to take before you complete this recipe. Different files may have different users and different DRAs associated with them. These differences can be due to changing DRA policies, different users using EFS, users explicitly encrypting files for multiple users, etc.
The only way to know exactly which users technically, which certificates have access to a given file is to display its information using this recipe. You can use efsinfo.
Right-click the object and click Cut for moving the object or Copy for copying the object. The following command moves a file called Test. The following command copies a file called Test.
Moving or copying an encrypted file or folder is exactly the same as moving or copying any other file or folder.
However, you should know what happens to encryption when files are moved or copied. To most applications, this is essentially the same thing. However, to EFS, the operations are completely different. When an encrypted file is moved, it remains encrypted during its move.
Even if its new folder is not marked for encryption, it will remain encrypted. Similarly, an unencrypted file moved into a folder marked for encryption remains unencrypted.
However, a copied file inherits the encryption attribute from its new parent folder. So copying a file to a folder marked for encryption results in an encrypted file. You want change the default algorithm used by EFS to use stronger encryption. To change the algorithm EFS uses for encrypting files, set the following Registry value:. Refer to Table for the value data that pertains to the algorithm you want to use. EFS can use one of several different encryption algorithms.
By default, each operating system defaults to the best encryption algorithm available when it was released. However, you can directly modify which algorithms are used with this recipe. There are several reasons that might make you consider changing the EFS encryption algorithm.
For example, your company may establish a policy that requires bit encryption on all sensitive data. Another reason might be the breaking of an older algorithm. If an algorithm is broken, you can follow this recipe to ensure that the algorithm is no longer used. Otherwise one client may encrypt using an algorithm that another client cannot use, and the decryption will fail.
For information on operating systems support for various algorithms, see MS KB You want to ensure that offline files are encrypted by EFS to reduce the threat of data compromise in the event of physical computer compromise. Check the Encrypt offline files to secure data option. Offline files offer mobile users a powerful tool for data portability. They essentially mirror copies of files locally and provide the user access to this data when not connected to the network where the files reside. When the computer is reconnected to the network, the files are synchronized to update the network copy.
These files can contain data of any classification. Because this data can be sensitive, using offline files should be carefully considered. When used, confidential data should be protected on the mirrored computer. This is accomplished by encrypting the offline files with EFS.
You want more than one local user to share the same EFS files on a client computer. The file is already encrypted if the file is not yet encrypted, see Recipe 4. Select the certificate of the user you want to share the file with and click OK three times.
This recipe cannot be completed with a command-line interface or through VBScript because it requires interactive browsing for a desired certificate.
Sharing files between users with EFS provides very strong file-level security. However, it does not protect against several threats, including a malicious administrator and physical compromise of the hard drive. An effective measure against these types of attacks is to use EFS to share the files. Regardless of the ACL on the file, if the user does not possess the appropriate private key, she cannot access the data.
If the certificate is unavailable, EFS cannot share files. For recipes on importing certificates, see Chapter From the Start menu, select Run, type certmgr. In the right pane, locate the certificate or certificates that have an Intended Purposes value of Encrypting File System. If you want to password-protect the exported private key, provide a password and then click Next. This step is optional but is strongly recommended. The single biggest problem that users and administrators report with EFS is data loss.
They can no longer decrypt files that have been encrypted. In virtually all cases, they have lost the private key that encrypted the data and did not have a backup or a DRA. Unfortunately, there is little that can be done after the loss of the private key to recover the data. Without a decryption key, the data cannot be decrypted. The procedure to back up a private key is reasonably simple. But it is not done for the user automatically, nor is the user ever prompted to perform such a backup.
Some responsible administrators configure a DRA or a PKI-based RA which can recover keys from the issuing CA to ensure data recoverability, but usually this happens after the first major data loss incident. To help prevent such data loss, you should ensure that you either deploy a DRA or a consistent private key backup strategy for your EFS users. You can also back up DRA keys using this recipe. To do so, select certificates that have an intended purpose of File Recovery in Step 3 of the recipe.
The rest of the steps stay the same. This command-line is somewhat unusual in that it displays a GUI-based dialog box for you to confirm the operation. This is done to help prevent an attacker from exporting your private keys without your knowledge. You are the designated DRA for your company. You possess the current DRA private key and you want to recover data using that key. This is normally done only when a user has lost all copies of their private key and key archival has not been implemented.
This will restore them in their encrypted form. This complex procedure cannot be accomplished through the command line or through VBScript. However, you could assemble several recipes from this and other books to complete the task, including the command-line Ntbackup utility. This is a bad idea. A file's attributes record that the file is encrypted in the same way that a file records that it is compressed discussed earlier in this chapter.
NTFS and EFS have specific interfaces for converting a file from nonencrypted to encrypted form, but user-mode components primarily drive the process. As described earlier, Windows lets you encrypt a file in two ways: by using the cipher commandline utility or by checking the Encrypt Contents To Secure Data check box in the Advanced Attributes dialog box for a file in Windows Explorer.
Advapi32 loads another DLL, Feclient. When Lsasrv receives an RPC message from Feclient to encrypt a file, Lsasrv uses the Windows impersonation facility to impersonate the user that ran the application either cipher or Windows Explorer that is encrypting the file.
Impersonation is described in Chapter 8. This procedure lets Windows treat the file operations that Lsasrv performs as if the user who wants to encrypt the file is performing them. Lsasrv usually runs in the System account.
The System account is described in Chapter 8. In fact, if it doesn't impersonate the user, Lsasrv usually won't have permission to access the file in question.
Lsasrv next creates a log file in the volume's System Volume Information directory into which Lsasrv records the progress of the encryption process. The log file usually has the name Efs0. Typically, the user profile is already loaded because Winlogon loads a user's profile when a user logs on. However, if a user uses the Windows RunAs command to log on to a different account, when the user tries to access encrypted files from that account, the account's profile might not load.
Note that this key doesn't appear in the registry until a file or folder is encrypted. Lsasrv uses the signature to access the user's public key and encrypt FEKs. Lsasrv can now construct the information that EFS stores with the file. EFS stores only one block of information in an encrypted file, and that block contains an entry for each user sharing the file. A collection of multiple key entries is called a key ring because, as mentioned earlier, EFS lets multiple users share encrypted files.
Figure shows a file's EFS information format and key entry format. EFS stores enough information in the first part of a key entry to precisely describe a user's public key. The second part of the key entry contains an encrypted version of the FEK.
Format of EFS information and key entries. Next, Lsasrv creates another key ring that contains recovery key entries. The DRF's purpose is to let designated accounts, or Recovery Agents, decrypt a user's file when administrative authority must have access to the user's data. For example, suppose a company employee forgot his or her logon password.
An administrator can reset the user's password, but without Recovery Agents, no one can recover the user's encrypted data.
Recovery Agents are defined with the Encrypted Data Recovery Agents security policy of the local computer or domain. Lsasrv interprets the recovery policy when it initializes and when it receives notification that the recovery policy has changed. Lsasrv stores the checksum's result in the EFS information header. EFS references this checksum during decryption to ensure that the contents of a file's EFS information haven't become corrupted or been tampered with. Figure illustrates the flow of the encryption process.
After Lsasrv constructs the necessary information for a file a user wants to encrypt, it can begin encrypting the file. Lsasrv creates a backup file, Efs0. Lsasrv uses higher numbers in the backup filename if other backup files exist.
Lsasrv creates the backup file in the directory that contains the file undergoing encryption. Lsasrv applies a restrictive security descriptor to the backup file so that only the System account can access the file's contents. Lsasrv next initializes the log file that it created in the first phase of the encryption process.
Finally, Lsasrv records in the log file that the backup file has been created. Lsasrv encrypts the original file only after the file is completely backed up.
Flow of EFS. Execution returns to Lsasrv, which copies the contents of the file undergoing encryption to the backup file. When the backup copy is complete, including backups of all alternate data streams, Lsasrv records in the log file that the backup file is up to date. After EFS encrypts the file, Lsasrv records in the log file that the encryption was successful and deletes the file's backup copy.
Remotely encrypting files using a share can only be done in a domain because EFS must use Kerberos delegation to impersonate the user. It's important to note that EFS only encrypts data when it's stored on the disk. It does not encrypt data during transmission over the network. For that purpose, you can use IPsec. Also, if you encrypt a file and then copy or move it to a WebDAV folder, it stays encrypted while in transit. There are some potential problems you should be aware of before implementing EFS in a domain.
For example, a user only has to have NTFS modify write permission to a file to be able to encrypt it. This means that if multiple users have permission to access a file, one of them could encrypt it and make it inaccessible to the others.
All users who share the encrypted file must have an EFS certificate on the computer on which it's stored. The EFS domain recovery agent certificate is stored by default on the first domain controller in the domain. It's important to remember this if you're considering demoting the DC or if it is in danger of crashing. You should export the private key to avoid a situation where you are unable to decrypt the files if a user's account is deleted. If a user changes the domain password over a remote access dialup or VPN connection, the DPAPI master key may not be replicated immediately to all domain controllers.
This can cause the user to get an Access Denied message when trying to access local encrypted files after making the password change.
You can solve this problem by creating a registry value named ProtectionPolicy in. Warning: This registry modification will allow the user to access encrypted files after a remote access password change, but it can also expose the user's account to the threat of attack.
When implementing EFS in a domain, by default the Administrator of the first domain controller is the recovery agent. You should create new recovery agent accounts and remove the recovery agent role from the Administrator account. The recovery agent account s should be used only for that purpose. If a computer was previously a standalone system and then joins a domain that uses a CA to issue EFS certificates, you might not be able to open files that were encrypted with a self-signed certificate prior to joining the domain.
You can access these files by logging off the domain and logging back onto the local computer. You should also be aware of EFS security issues.
0コメント