securing the db2 database of your sap system with … · securing the db2 database of your sap...

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 1

Securing the DB2 Database of your

SAP System with Windows

Encrypting File System

Applies to:

All SAP releases on IBM DB2 for Linux, UNIX, and Windows (in the following referred to as DB2 for LUW) on a Windows platform.

Summary

This document describes how to encrypt the database of your SAP system with Windows Encrypting File System (in the following referred to as EFS). You can use this document as a step-by-step guide to enable encryption on your existing SAP system that runs on DB2 for LUW. This document also provides performance data based on a test analysis that was done at the IBM SAP Integration and Support Centre.

Authors: Lili Zhang, Sunny Sun

Company: IBM, SAP (IBM SAP Integration and Support Centre, Toronto)

Created on: November 2010

Author Bio

Lili Zhang is a member of the IBM SAP Integration and Support Centre at the IBM Toronto Lab. Her current activities include testing of SAP applications with DB2 for LUW and helping customers with problem analysis and troubleshooting. She is also a customer advocate, providing support for large customer accounts running SAP and DB2 for LUW.

Sunny Sun is a member of the IBM SAP Integration and Support Centre at the IBM Beijing Lab. His current work is related to SAP on DB2 for LUW product certification, and in his role as a customer advocate, he also works in customer support on SAP DB2 products.

Securing the DB2 Database of your SAP System with Windows Encrypting File System


© 2009 SAP AG 2

Table of Contents

Overview ............................................................................................................................................................. 3

Introduction to Encrypting File System (EFS) ..................................................................................................... 3

Configuring EFS for the Database of Your SAP System .................................................................................... 4

Prerequisites ................................................................................................................................................... 4 Obtaining the EFS certificate ....................................................................................................................................... 4

Planning your data recovery procedure ....................................................................................................................... 4

Space requirements ..................................................................................................................................................... 5

Encrypting Data Files ...................................................................................................................................... 6 Enabling Encryption for a Folder .................................................................................................................................. 6

Enabling Encryption for a Single File ........................................................................................................................... 8

Decrypting Files ............................................................................................................................................ 11

Other Useful Operations ............................................................................................................................... 11 Exporting/Importing EFS certificate and keys ............................................................................................................ 11

Authorizing Additional Users for Access to Encrypted Files (Optional) ...................................................................... 13

Test Results ...................................................................................................................................................... 14

Test overview ................................................................................................................................................ 14

Test 1: Standard SAP SD Benchmark .......................................................................................................... 14

Test 2: Zmerge .............................................................................................................................................. 18

Test 3: Client Copy/Client Delete/SGEN: ...................................................................................................... 21

Test Summary: .............................................................................................................................................. 21

Miscellaneous ................................................................................................................................................... 22

New functions with Windows 2008 ............................................................................................................... 22

File operations on encrypted files across the network .................................................................................. 22

Changing user passwords ............................................................................................................................ 22

Backing up an encrypted file or folder ........................................................................................................... 23

Performing data recovery .............................................................................................................................. 23

Expired certificates (private keys) ................................................................................................................. 23

Summary........................................................................................................................................................... 24

Related Content ................................................................................................................................................ 25

Disclaimer and Liability Notice .......................................................................................................................... 26



© 2009 SAP AG 3

Overview

Data security is crucial in today’s business as the computing environment is subject to malicious attacks and increasing regulatory pressures. The Encrypting File System (EFS) on Microsoft Windows provides NTFS file system encryption which enhances data security for your sensitive data. You can encrypt individual files or folders on NTFS drives. When the files are encrypted, the data is protected even if the attacker has physical access to the machine. Only authorized users and data recovery agents can decrypt the files.

With EFS, you are able to encrypt your database backup image or tablespace container files to protect sensitive data in your database. This document guides you through the steps needed to encrypt the existing database of your SAP system with EFS. You can also use the performance result as a reference when considering encryption using Windows EFS on your system.

Introduction to Encrypting File System (EFS)

EFS was first introduced in version 3.0 of NTFS and supported as of Windows 2000. It uses a combination of public-private key pair and a per-file encryption key to encrypt and decrypt data. To encrypt a file, EFS generates a random symmetric key, also known as file encryption key (FEK) to encrypt the data. The FEK is then encrypted with the user’s public key from the encryption certificate and is added to the file as an EFS attribute named Data Decryption Field (DDF). To access an encrypted file, you must have the private key that corresponds to one of the public keys used to decrypt the FEK first. The decrypted FEK is then used to decrypt the data.

To protect against accidental loss of your data, EFS provides a data recovery capability. The capability is defined by a recovery policy where you can configure one or more data recovery agents (DRAs). A recovery agent is a privileged user account (for example, Administrator) that can recover data from any encrypted file in the event of lost or corrupted keys for authorized users. If a recovery policy is in place, the FEK is additionally encrypted with the recovery agent’s public keys and stored in the Data Recovery Field (DRF) of the file. The recovery agent uses its corresponding private keys to decrypt the FEK, and the encrypted files will be recovered.

Figure 2-1 Structure of an Encrypted Data File

In general, the encryption process involves the following steps:

EFS starts by performing a number of verification checks. These checks include whether the file can be encrypted and whether there is enough disk space to encrypt the file. If the file is marked as a system file or resides in the %systemroot% directory, it cannot be encrypted.

EFS then generates a file encryption key (FEK). By default, EFS uses the Advanced Encryption Standard (AES) algorithm with 256-bit keys for encrypting files on Windows 2003 and Windows 2008 platforms.



© 2009 SAP AG 4

The FEK is encrypted with the current user's public key. If a recovery agent is defined, the FEK is also encrypted with the recovery agent’s public keys.

EFS metadata is created. EFS metadata contains the Data Decryption Field (DDF), which consists of the encrypted FEKs for all users that have been given access to the file. It also contains the Data Recovery Field (DRF), which contains the encrypted FEKs for all defined recovery agents. Other information, such as the EFS version and encryption algorithm, is also stored in the metadata.

A temporary file is created in the current directory. The source file is copied to the temporary file for backup purposes. Each data stream in the original file is then truncated to a length of zero. Its length is then set back to its original size. This essentially deletes all the data in the stream. Next, EFS writes the metadata to the original file. At this point, EFS has the plaintext data in a temporary file and an empty source file that is marked encrypted because of the presence of the EFS metadata.

EFS reads the data streams from the temporary file and writes them to the original file. The data is encrypted before it is written to disk.

After all of the data has been written back to the original file, EFS verifies that the file is encrypted and then deletes the temporary file. If the conversion process fails for some reason, EFS restores the file to its original state.

Since the encrypting and decrypting processes are fully integrated at NTFS file system level, they are totally transparent to the users and applications. From the user’s point of view, encrypting a file is simply a matter of setting a file or a folder’s attribute. Authorized users can work with the files as usual while non-authorized users receive an Access denied error message when trying to open the encrypted file.

Configuring EFS for the Database of Your SAP System

Prerequisites

Obtaining the EFS certificate

Because EFS relies on a public key to encrypt files, you need a public-private key pair and a public key certificate for encryption. If you do not currently have a public key infrastructure (PKI), EFS will generate a self-signed certificate to be used the first time you attempt to encrypt a file or folder. In a domain environment, it is recommended to deliver EFS certificates to users as part of your PKI. Using a certificate authority provides more flexibility for EFS certificate delivery and recovery management. For more information, see “How to Implement Data Recovery Strategies with PKI and How to Implement Key Recovery with PKI”.

Self-signed certificates are valid for 100 years. Certificates issued by certification authorities(CA) are typically valid for a few years. EFS automatically renews a certificate if possible. If the certificate cannot be renewed, it will request a new one from CA or generate a self-assigned certificate.

Planning your data recovery procedure

Encrypting a file bears the risk that the file might become unreadable. Therefore, it is crucial to consider data recovery implementation before encrypting the files.

The most effective way for users to ensure access to encrypted files is to export their EFS certificates and private keys. For more information about how to secure your EFS keys, see Exporting/Importing EFS certificate and keys later in this document.

In addition, you can designate one or more data recovery agents (DRAs) by using the EFS recovery policy. Starting with Windows 2003, DRAs are not mandatory for EFS. However, it is highly recommended to have a recovery policy set up before encryption. In case the original user account that encrypted the file is deleted or its password is lost, the encrypted file can still be recovered by the recovery agents.

In a domain environment, the recovery policy is enabled by default and the domain administrator account is defined as the default recovery agent. When the domain administrator account logs on to the domain controller for the first time, an EFS recovery certificate is generated and stored in the local profile. This certificate is added to the recovery policy and distributed using group policy. This allows organizations to define and enforce a policy to access data stored on company systems.

http://technet.microsoft.com/en-us/library/cc700811.aspx#XSLTsection131121120120




© 2009 SAP AG 5

On a stand-alone machine, no recovery policy is defined by default. Administrators on stand-alone machines have to create a recovery certificate and add it to the recovery policy. Otherwise, there is no way to recover the data if the private keys for authorized users are lost.

For more information about how to add recovery agents for your system, see “Recover files and folders”. Once the recovery agents are defined, it is important to back up the keys for recovery agents as well. To do so, follow the instructions as described in How to back up the recovery agent Encrypting File System (EFS)

private key in Windows Server 2003.

For more information and best practices on data recovery and data protection, see Encrypting File System on Windows XP and Windows 2003.

Space requirements

During the encryption process, a temporary file is created in the same directory as the original file. This is to ensure data integrity in case the encryption process cannot be completed successfully. Before encryption, make sure the free space on the file system is at least as big as the file you are about to encrypt.

http://technet.microsoft.com/en-us/library/cc778009(WS.10).aspx

http://support.microsoft.com/kb/241201


http://technet.microsoft.com/en-us/library/bb457065.aspx




© 2009 SAP AG 6

Encrypting Data Files

You can encrypt files or folders by setting the encryption attribute in the object's Properties dialog box or by using the Ciper.exe command. To encrypt the database of an SAP system, you can choose to encrypt the entire database by encrypting the data path (folder), or perform encryption on a single data container file.

Users with write permission on the files are able to perform encryption. Once the files are encrypted, only the encryptor or authorized users are able to access the encrypted files. On a Windows platform, DB2 processes are run by user db2<sid>. Therefore, you have to log in as user db2<sid> to encrypt the database files.

Enabling Encryption for a Folder

If the encryption attribute is set for a folder, the folder itself is not encrypted. Any files created in or added to the folder are automatically encrypted. All the existing files under this folder can also be encrypted.

You can use this method to encrypt sapdata container folders for your existing database or prior to your SAP installation. In this way, the newly created database will automatically be encrypted during installation.

Procedure:

1. Make sure all the DB2 processes are stopped. Encryption is not allowed when the file is being accessed.

2. Right-click the sapdata folder for your tablespace directory and choose Properties.

3. On the General tab page of the sapdata Properties dialog box, choose the Advanced pushbutton.



© 2009 SAP AG 7

4. In the Advanced Attributes dialog box, select the Encrypt contents to secure data checkbox and choose the OK pushbutton.

Note: Although the NTFS file system supports both compression and encryption, it does not support both at the same

time. This means that you can only select one or the other. A file or folder cannot be both encrypted and

compressed at the same time.

5. In the sapdata Properties dialog box, choose the OK pushbutton again to confirm your selection.

6. Choose the Apply pushbutton in the sapdata Properties dialog box.

A new dialog box is displayed where you have to choose between the following options:

Apply changes to this folder only.

This option does not have any effect on existing files. Files created in or copied to this folder later will be encrypted. The encryption attribute for subfolders will not be changed. If you choose this option, the results are as follows:

File description Encryption status

Already stored in the folder and its subfolders. Unchanged The files remain either encrypted or unencrypted.

Created in or copied to the folder by you later. Protected with your private key.

Created in or copied to the folder by another user (if the folder is shared) later.

Protected with the other user's private key.

Created in or copied to subfolders later. Unchanged

Moved to the folder or subfolders later. Unchanged

Apply changes to this folder, subfolders and files.

If you choose this option, the existing files in the current folder and subfolders are encrypted. Files created later will be encrypted as well.



© 2009 SAP AG 8

The results are as follows:

File description Encryption status

Already in the folder and its subfolders. Protected with your private key if you have Write Attributes permission; otherwise, files remain unchanged.

Later created in or copied to the folder or subfolders by you.

Protected with your private key.

Later created in or copied to the folder or subfolders by another user.

Protected with the other user's private key.

Later moved to the folder or subfolders. Unchanged

7. Select Apply changes to this folder, subfolders and files and choose the OK pushbutton.

Note: If you choose this option, all the files in the current folder will be encrypted, including those that are owned by

others if the folder is shared by multiple users. This will prevent others from accessing their own files.

Enabling Encryption for a Single File

If you want to encrypt a specific data file that contains sensitive data, perform the following steps:

1. Make sure all the DB2 processes are stopped. Encryption is not allowed if the file is being accessed.

2. Identify the tablespace container file that you want to encrypt. To obtain the container file name, you can use the db2 list tablespace containers command.

Example C:\benchmark>db2 list tablespace containers for 30 Tablespace Containers for Tablespace 30 Container ID = 0 Name = E:\db2\ACO\sapdata1\DB2ACO\NODE0000\ACO\T0000030\C0000000.LRG Type = File

3. Right-click the container file in Windows Explorer and choose Properties.



© 2009 SAP AG 9

4. On the General tab page, choose the Advanced pushbutton.

5. In the Advanced Attributes dialog box, select the Encrypt contents to secure data checkbox and choose the OK pushbutton.

6. In the Properties dialog box, choose the Apply pushbutton.

7. In the Encryption Warning dialog box, select Encrypt the file only and choose the OK pushbutton.



© 2009 SAP AG 10

When the files or folders are encrypted, the value E is displayed in the Attributes column in Windows Explorer.

To display the encryption details, you can right-click a file, open its Properties dialog box, and choose the Advanced pushbutton. In the Advanced Attributes dialog box, choose Details.



© 2009 SAP AG 11

Decrypting Files

For the decryption of files, the same procedure applies as for the encryption. This means that you open the Properties dialog box by right-clicking the relevant file and choose the Advanced pushbutton. In the Advanced Attributes dialog box, you disable the encryption attribute by deselecting the Encrypt contents to secure data checkbox and apply the changes.

Only users who have write permission to the file and who have been granted access to the encrypted files are able to decrypt them.

Other Useful Operations

Exporting/Importing EFS certificate and keys

Once a file or folder is encrypted with EFS, it can only be decrypted with the private keys of the authorized user account. If the private key is damaged or missing, even the user that encrypted the file cannot decrypt it.

To ensure continued access to your own encrypted files, you can perform the following steps to export the EFS certificate and private key and store it in a safe place:

1. Open Certificate Manager by clicking Start -> Run, and execute certmgr.msc.

2. Expand the Personal folder and choose the Certificates folder.

3. Choose the certificate that lists Encrypting File System under Intended Purposes. (You might need to scroll to the right to see this.)

4. In the main menu bar, choose Action All Tasks Export.

5. In the Certificate Export Wizard, select Yes, export the private key and then choose Next.



© 2009 SAP AG 12

6. Accept the preselected default settings by choosing Next.

7. Enter the password you want to use and confirm it.

8. Provide the location and the name of the file you want to save and choose the Next pushbutton to finish the process.

Note: Make sure the exported file is copied to a floppy disk, CD, or other removable media and stored in a safe place as

anyone who has access to the file can import the key to his profile and will be able to decrypt the files.

To import a certificate, perform the following steps:

1. Open the Certificates snap-in and expand the Personal folder.

2. Right-click the Certificates folder and choose All Tasks Import. The Certificate Import Wizard starts.

3. Follow the steps of the import wizard and provide the password and location of the certificate you saved previously to import the certificate and private keys.



© 2009 SAP AG 13

Authorizing Additional Users for Access to Encrypted Files (Optional)

Users can share encrypted files with other local or domain users. Before a user is granted access to the encrypted file, EFS first validates if the user’s certificate can be trusted. EFS then decrypts the FEK with the grantor’s private key and uses the new user’s public key to encrypt it. The encrypted FEK is then stored in a data decryption field (DDF) with the file.

To share encrypted files with other users, perform the following steps:

1. Right click the file and open the Properties dialog box.

2. On the General tab page, choose the Advanced pushbutton.

3. In the Advanced Attributes dialog box, choose the Details pushbutton.

4. In the Encryption Details dialog box, choose the Add pushbutton.

5. In the Select User dialog box, any local users that hold EFS certificates are displayed. Select the user you want to grant access to, or choose the Find User pushbutton to add a domain user account.



© 2009 SAP AG 14

Note: Use caution when sharing encrypted files. Any user who has been granted access to the files can authorize others

to access them, too. As the DB2 service is started with user db2<sid>, the tablespace container files need to be accessible to user

db2<sid>. You do not need to share the files with other users.

Test Results

In this section, we will compare the test results of an encrypted database and a non-encrypted database to identify the performance impact on the SAP system using windows EFS.

Test overview

Hardware:

Operating System: Windows 2003 server

SAP release: SAP ECC 6.0 SR3

DB2 release: 9.7 FP2SAP

Database Layout: database size is 80GB with 35 regular tablespaces. All tablespace containers are located in one subdirectory (sapdata1) on ESS storage, and they are all encrypted when the encryption test is conducted.

We will concentrate on evaluating the encryption impact on the runtime and CPU usage. Windows performance monitor is used to collect performance data for analyzing.

Test 1: Standard SAP SD Benchmark

Our benchmark test uses 300 users and 10 loops. The benchmark driver is running on a separate server.

Runtime: Runtime difference is 0.04%

Non-encrypted

Encrypted Difference

Runtime(sec) 4587 4589 0.04%



© 2009 SAP AG 15

The physical CPU usage over runtime is displayed in the following figure:

Benchmark Physical CPU usage

0

10

20

30

40

50

600s

190s

380s

570s

760s

950s

1140s

1330s

1520s

1710s

1900s

2090s

2280s

2470s

2660s

2850s

3040s

3230s

3420s

3610s

3800s

3990s

4180s

4370s

4560s

% C

PU

Non-encrypted Encrypted

At high load intervals, the average number of physical CPU used is 44.3% for the non-encrypted database and 45.0% for the encrypted database.

The following figure provides a system overview for CPU and disk throughput on the non-encrypted database:

Benchmark Non-encrypted

0

10000

20000

30000

40000

50000

60000

70000

80000

0s

195s

390s

585s

780s

975s

1170s

1365s

1560s

1755s

1950s

2145s

2340s

2535s

2730s

2925s

3120s

3315s

3510s

3705s

3900s

4095s

4290s

4485s

Kb

/se

c

0

5

10

15

20

25

30

35

40

45

Read&Write KB/sec System_Time% User_Time%



© 2009 SAP AG 16

System overview for CPU and disk throughput on the encrypted database:

Benchmark Encrypted

0

10000

20000

30000

40000

50000

60000

70000

800000s

255s

510s

765s

1020s

1275s

1530s

1785s

2040s

2295s

2550s

2805s

3060s

3315s

3570s

3825s

4080s

4335s

4590s

4845s

KB

/se

c

0

5

10

15

20

25

30

35

40

45

Read+Write KB/sec System_Time% User_Time%

Comparing the total read&write rate vs. runtime:

Total Disk Read&Write KB/s

0

10000

20000

30000

40000

50000

60000

70000

80000

0s

195s

390s

585s

780s

975s

1170s

1365s

1560s

1755s

1950s

2145s

2340s

2535s

2730s

2925s

3120s

3315s

3510s

3705s

3900s

4095s

4290s

4485s

Kb

/se

c


At high load intervals, the average disk read&write rate is 64038 KB/sec for the non-encrypted database and 63023 KB/sec for the encrypted database.



© 2009 SAP AG 17

Comparing system CPU usage:

System_Time%

0

2

4

6

8

10

12

0s

180s

360s

540s

720s

900s

1080s

1260s

1440s

1620s

1800s

1980s

2160s

2340s

2520s

2700s

2880s

3060s

3240s

3420s

3600s

3780s

3960s

4140s

4320s

4500s


The figure above shows that the system CPU usage is a little bit higher for the encrypted database.

Comparing user CPU usage:

User_Time%

0

5

10

15

20

25

30

35

40

45

0s

180s

360s

540s

720s

900s

1080s

1260s

1440s

1620s

1800s

1980s

2160s

2340s

2520s

2700s

2880s

3060s

3240s

3420s

3600s

3780s

3960s

4140s

4320s

4500s


All in all, the performance impact of encryption is very small in the benchmark test:

The runtime degradation is close to zero.

CPU usage under high workload is increased from 44.3% to 45.0%. The increase comes from the system CPU usage. User CPU usage is about the same.



© 2009 SAP AG 18

Test 2: Zmerge

Zmerge test is an SAP internal test program consisting of several implementations of the BW compression (condense) process:

Insert/Update

Update via Temp Table

Merge statement

Insert/Merge combination

Runtime: Runtime difference is 16.3%

Non-encrypted


Runtime(sec) 9752 11308 15.96%

The increase in CPU and runtime is shown in the following figure:

Physical CPU usage vs. runtime

0

10

20

30

40

50

60

0s

480s

960s

1440s

1920s

2400s

2880s

3360s

3840s

4320s

4800s

5280s

5760s

6240s

6720s

7200s

7680s

8160s

8640s

9120s

9600s

10080

10560

11040

11520

%C

PU


The average physical CPU used is 22.3% on the non-encrypted database and 25.3% for the encrypted database. At certain points, the CPU usage was 20% higher on the encrypted database.



© 2009 SAP AG 19

Overview of CPU and disk throughput on the non-encrypted database:

Zmerge-Non-encrypted

0

10000

20000

30000

40000

50000

60000

70000

800000s

480s

960s

1440s

1920s

2400s

2880s

3360s

3840s

4320s

4800s

5280s

5760s

6240s

6720s

7200s

7680s

8160s

8640s

9120s

9600s

KB

/se

c

0

5

10

15

20

25

30

35

Read+Write KB/sec System_Time% User_Time%

Overview of CPU and disk throughput on the encrypted database:

Zmerge-Encrypted

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

0s

480s

960s

1440s

1920s

2400s

2880s

3360s

3840s

4320s

4800s

5280s

5760s

6240s

6720s

7200s

7680s

8160s

8640s

9120s

9600s

10080s

10560s

11040s

11520s

KB

/se

c

0

5

10

15

20

25

30

35

User_Time% System_Time% Read+Write KB/sec



© 2009 SAP AG 20

Comparing system CPU usage:

System_Time%

0

5

10

15

20

25

30

35

0s

480s

960s

1440s

1920s

2400s

2880s

3360s

3840s

4320s

4800s

5280s

5760s

6240s

6720s

7200s

7680s

8160s

8640s

9120s

9600s

10080s

10560s

11040s

11520s

System_Time%-Non-encrypted System_Time%-Encrypted

System CPU usage is increased. The system CPU usage increased by 20% at the spikes. On average, System_Time% is 2.23% for the non-encrypted database and 8.01% for the encrypted database.

Comparing the disk throughput rate:

Total Disk Read&Write KB/sec

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

0s

480s

960s

1440s

1920s

2400s

2880s

3360s

3840s

4320s

4800s

5280s

5760s

6240s

6720s

7200s

7680s

8160s

8640s

9120s

9600s

10080

10560

11040

11520

KB

/se

c


The average read & write rate for the non-encrypted database is 27199 KB/sec and 27926 KB/sec for the encrypted database.



© 2009 SAP AG 21

All in all, there is a slight impact on runtime and CPU usage for the zmerge test.

There is a 15.96% degradation in runtime.

The average physical CPU usage is increased from 22.3% to 25.3%. System CPU usage is increased from 2.23% to 8.01%.

Test 3: Client Copy/Client Delete/SGEN:

Client Copy and Client Delete are standard SAP transactions to copy or delete client-specific data to or from SAP tables. SGEN is used for SAP code generation.

Runtime difference between encrypted and non-encrypted database:

Non-encrypted


SGEN 7139 7261 1.71%

Client Copy 5144 5201 1.11%

Client Delete 3677 3925 6.74%

Test Summary:

There is a slight performance impact when using EFS for the database of your SAP system.

The runtime difference depends on the amount of disk activities and the number of SAP processes running the job. Zmerge test uses only one SAP process, and the job involves heavy disk read and write activities. In this case, the runtime degradation could be as high as 16%. On the other hand, the runtime difference is negligible for benchmark, sgen, and client copy/client delete tests.

The total CPU usage increased from 1% to 3% which is mainly caused by system CPU usage. At certain points, there was an increase of 20% in CPU usage for a short period of time.

You can choose to encrypt only the tablespaces with sensitive data instead of encrypting the whole database. By doing so, you can save system resources and reduce the performance impact of encryption.



© 2009 SAP AG 22

Miscellaneous

New functions with Windows 2008

With the release of Windows 2008, EFS has been enhanced with the following new functions:

Smart card key storage

EFS encryption keys and certificates can be stored on smart cards. This increases the security of those keys because they cannot be attacked by another user or by someone who steals the computer.

Per-user encryption of offline files

If this option is enabled, each file in the offline cache is encrypted with a public key from the user who cached the file. In previous Windows releases, the encryption of cached offline files is done with system keys.

Increased configurability of EFS through Group Policy

A number of new Group Policy options have been added to help administrators define and implement organizational policies for EFS. These include the ability to require smart cards for EFS, enforce page file encryption, stipulate minimum key lengths for EFS, enforce encryption of the user’s documents folder, and prohibit self-signed certificates.

Encrypting File System Rekeying Wizard

The Encrypting File System Rekeying Wizard allows you to choose a certificate for EFS and select and migrate existing files using the newly chosen certificate. This is more efficient than decrypting and re-encrypting files.

File operations on encrypted files across the network

With EFS file sharing, you can access an encrypted file and perform other file operations across the network. Keep in mind that EFS is not designed to protect data while it is transferred from one system to another. All EFS operations occur on the computer on which the files are stored. If you open an encrypted file on the network drive, the file is decrypted on the computer on which the file is physically stored and then transmitted in plaintext over the network to your computer. Similarly, if the encrypted files are copied or moved to or from a network file share on a remote computer, the files are decrypted locally and re-encrypted on the target volume with a new FEK.

You can reduce or eliminate the risk over network by using IP security with ESP and encryption to secure

data as it is transmitted, or by storing encrypted files on Web folders. For more information, see Using

Encrypting File System, section Remote EFS Operations on File Shares and Web Folders.

Changing user passwords

The private key that is used to decrypt the file encryption key is located in the user profile under RootDirectory\Documents and Settings\username\Application Data\Microsoft \Crypto\RSA. All files in the RSA folder are automatically encrypted using a random symmetric key called user’s master key. The user’s master key is 64 bytes in length and is generated by a strong random number generator. Before master keys are stored, they are 3DES-encrypted using a key derived from the user’s password.

Note: Do not rename or move the RSA folder as this is the only folder where EFS looks for private keys.

If you change your logon password using the ALT+Ctrl+Del and Change Password option, master keys are automatically unencrypted and re-encrypted using the new password. If the password is changed using the Reset password option from the user's account in the Computer Management console either by the user himself or by the administrator, the stored master key cannot be accessed anymore. As a result, the encrypted file cannot be accessed anymore. You may need to import the keys from your previous backup to access the files again. For more information, see EFS, Credentials, and Private Keys from Certificates Are Unavailable After a Password Is Reset”

http://technet.microsoft.com/en-ca/library/bb457116.aspx#EFAA

http://technet.microsoft.com/en-ca/library/bb457116.aspx#EFAA





© 2009 SAP AG 23

To avoid unexpected access errors caused by a password change, use ALT+Ctrl+Del to change the password properly.

Backing up an encrypted file or folder

Backing up encrypted files is as easy as backing up any other regular file. Since the backup does not require the user’s private key, the file remains encrypted, regardless of its destination.

Keep in mind that you can only decrypt a file if the backup is restored to a domain or local computer where authorized user accounts or data recovery agents exist and the private keys for the users are available.

Performing data recovery

You can log in with the data recovery agent account to recover an EFS-encrypted file for a user whose private keys are lost. The recovery agent can open the files normally and save it in non-encrypted format or deselect the encryption attribute in the file’s Properties dialog box.

The most secure mechanism for data recovery is to use a central recovery workstation. You can do so by using a backup utility to perform a raw backup of the encrypted files and then restore those files on a central recovery machine where the private keys for DRAs are stored. You can add extra protection for your recovery procedures by restricting the recovery agent to log on only at this workstation and placing the workstation in a physically secured area.

Expired certificates (private keys)

EFS user certificates

Self-assigned certificates are valid for 100 years. If the certificates are issued by certification authorities, they are typically valid for only a few years. If an EFS certificate expires, users can still access the encrypted files as the private keys are stored with the user profile. However, they cannot encrypt more files with the existing certificate. When the certificate is expired, EFS automatically renews the certificate if possible. If EFS cannot renew the certificate, it requests a new certificate from a trusted enterprise CA if one is known and available. Otherwise, EFS creates a new self-signed certificate the next time the user encrypts a file.

As the renewal process is fully automatic, you may not realize that different certificates are used for your encrypted files. It is important to back up every certificate (and the keys) to ensure the files can be recovered in the future.

Data recovery agent certificate

When the administrator logs on to the domain control for the first time, a default domain recovery agent certificate is created, and the private key is stored in the domain administrator’s profile. The default domain recovery agent certificate is valid for three years only and cannot be renewed.

When the DRA’s certificate is expired, the DRA can still be used to decrypt existing files as the private keys are still valid. However, you receive the error message “Recovery policy configured for this system contains invalid recover certificate” when trying to encrypt new files using an expired recovery certificate. For more information about how to generate a new recovery certificate using the cipher /R command and how to update the Group Policy to reflect the new DRAs, see “Error message when you try to renew the default recovery agent certificate in Windows Server 2003”.





© 2009 SAP AG 24

Summary

Encrypting your sensitive data with EFS adds another layer of security. It is especially useful on portable computers or on computers that are shared by several users. If files are encrypted, the data is protected even if an attacker has full access to the computer’s data storage.

Encrypting the file or folders is a simple process. However, it takes time to plan your recovery procedure and manage the certificate and keys that are used for encryption. If EFS is not used properly, you may not be able to access the encrypted file anymore, or the encrypted data can be easily decrypted by others.

Our tests showed a slight performance hit in terms of CPU usage and runtime. All in alll, the performance impact is acceptable.



© 2009 SAP AG 25

Related Content

How to Use the Encrypting File System

Best Practice for the Encrypting File Systems

Overview of Encrypting filesystem from Microsoft

Encrypting file systems on Wikipedia

Encrypting file system for Windows Vista

Microsoft Encrypting File System in Windows XP and Windows Server 2003

Implementing EFS in a Windows Server 2003 domain

Changes in EFS windows 7 and windows 2008 R2

Using Encrypting Filesystem

http://msdn.microsoft.com/en-us/library/ms995356.aspx



http://en.wikipedia.org/wiki/Encrypting_File_System

http://technet.microsoft.com/en-us/library/cc749610(WS.10).aspx


http://www.computerworld.com/s/article/107454/Implementing_EFS_in_a_Windows_Server_2003_domain

http://technet.microsoft.com/en-us/library/dd630631(WS.10).aspx

http://technet.microsoft.com/en-ca/library/bb457116.aspx#EIAA



© 2009 SAP AG 26

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.