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

This topic deals with various aspects of managing files and folders,
including attributes, compression, encryption, and various ways of
displaying and manipulating files and folders. For additional
information, see

Disks ,

Permissions , and

Shared
Folders in this chapter.

Attributes

Attributes are


properties
of a file or folder that indicate something about its state. The
attributes you can set for files or folders depend on whether the
underlying partition or volume is formatted using FAT, FAT32, or
NTFS:

Read-only (NTFS and FAT)

When applied to a file, this prevents the contents
of the file from being modified. If applied to a folder, you can
choose to make either the folder alone read-only or the folder and
all its contents (including subfolders) read-only. Making the folder
alone read-only isn't very useful since new files
you create in the folder don't inherit this
attribute. By default, operating-system files are always marked
Read-only, Hidden, and System.

Hidden (NTFS and FAT)

This hides the file or folder from normal view
the next time you view the parent folder's contents.
By default, operating-system files are marked Read-only and Hidden.
To display hidden files in Windows Explorer, select Tools
Folder Options View Show hidden files and
folders.

File/Folder is ready for archiving (NTFS and FAT)

When marked,



this
indicates that the file or folder should be backed up during the next
backup cycle. Once the file or folder has been backed up, the Archive
attribute is automatically cleared. When a file or folder is created
or its contents are modified, this attribute is automatically set.

For fast searching, allow Indexing Service to index this file/folder (NTFS only)

The Indexing Service


works automatically in the background
to build a catalog that speeds up searching for files and folders. By
default, all files and folders on NTFS volumes have this attribute
marked, but the Indexing Service is not started by default on WS2003.

Compress contents to save disk space (NTFS only)

This stores the file or folder in a compressed state on an NTFS
volume.

Encrypt contents to secure data (NTFS only)

This stores the file or folder in an encrypted state on an NTFS
volume.

Compression

Files and folders stored on



NTFS
volumes can be compressed to minimize the amount of disk space they
occupy. When these files are accessed, the operating system
uncompresses them automatically so they can be read or modified; when
the modified files are saved or closed, they are automatically
compressed again. The whole process is transparent to the user. Both
files and folders can be compressed. If a folder is compressed, the
files within it don't need to be compressedor
some may be and others not. When a file is copied from one place to
another, it is uncompressed, copied, and then compressed again. If
there is insufficient disk space to hold the uncompressed file, an
error message will occur and the copy will fail.

Certain file types can be effectively compressed, resulting in
significant gains in disk space, while compressing other file types
shows little gain in space. For example, a compressed bitmap
(

.bmp ) may need only 25% or less of its
uncompressed space, while compressing a binary executable program
file (

.exe ) rarely results in a significant gain
in space. You should not try to compress files that are already
compressed, such as WinZip (

.zip ) files. This
simply results in wasted processing power.

Data that is frequently modified, such as users'
work files in their home folders, generally should not be compressed
due to the overhead of the compression process. In addition, if you
are using disk quotas to manage how much disk space is allocated to
users, these disk quotas are calculated on the basis of the
uncompressed size of users' files. So it really
doesn't make sense to compress frequently accessed
files. Instead, compress data that is relatively static in
naturefor example, archived financial records stored on disk.
This is really the only practical use for compression on NTFS
volumes.

Encryption

NTFS permissions provide


a
way of securing files and folders from unauthorized local access. For
example, if two users share a computer, assigning full control for
each user to their own files prevents the users from accessing each
other's files. However, administrators have the
right to take ownership of any files on the system, but normally,
users with Administrative privileges are considered trustworthy. A
problem could occur if someone illicitly gained access to a
user's computer and removed the hard drive from the
system. The person could then install the NTFS drive in her own
computer, log on as the local Administrator for that computer, and
take ownership of any files on the stolen drive. Therefore, NTFS
permissions themselves can't protect data from the
theft of the hard drive itself. Additionally, third-party utilities
have been developed that allow users to boot their computer from a
floppy disk and access NTFS partitions directly. These utilities,
though of some administrative use in troubleshooting situations,
nevertheless pose a security risk for sensitive data stored on
physically accessible systems.

To prevent such scenarios from occurring, WS2003 includes a
feature called the Encrypting File System (EFS), which allows
encryption of files and folders on NTFS volumes to protect them from
unauthorized local access. When these files are accessed by their
associated application, the operating system decrypts them
automatically so they can be opened for reading or modification. When
the modified files are saved or closed, they are automatically
encrypted again. The whole process is transparent to the user. Both
files and folders can be encrypted or unencrypted. If a folder is
encrypted, the files within it don't need to be
encrypted, or some may be and others not.

When a user encrypts his datafiles, only he can decrypt these files,
and no other user can read them. To share an encrypted
file's contents with another user in order to
collaborate on work, the user must first decrypt the file so the
other user can use it. Members of the Administrators group, however,
have the right to decrypt any encrypted files.

Never encrypt files in the system directory where the WS2003 boot files are located. Since the key for decrypting these files can't be accessed until the operating system has booted and a user has logged on, WS2003 will not be able to start. Of course, WS2003 safeguards against this by preventing you from encrypting files that have the System attribute set. But if you have removed the System attribute from these files using the attrib command (perhaps while troubleshooting startup problems) and failed to reset this attribute on the files afterward, the possibility of encrypting them exists.

How EFS Works

EFS is integrated into NTFS and uses private-key cryptography to
ensure that data encrypted by users can be accessed only by that user
(or by an administrator). For each file that a user encrypts, an
associated private key called the file-encryption key is created,
which can be used later to decrypt the file. This file-encryption key
is itself encrypted in the form of an encryption certificate or EFS
certificate, which is encrypted using both the
user's public key and the public key of an
authorized recovery agent (so the file can be decrypted after
disaster recovery has been performed). The administrator by default
is an authorized recovery agent.

To decrypt an encrypted file, the file-encryption key for the file
must first itself be decrypted. This can be done using either:

• The private key corresponding to the public key that belongs to the
  user who encrypted the file (in other words, by the user herself)

• The private key of an authorized recovery agent (Administrator)

Once the file-encryption key for the encrypted file has been
decrypted, the encrypted file itself can be decrypted.

Strategies for Using Encryption

Encryption is particularly useful for users with portable computers.
Should your laptop be stolen while traveling, encryption provides a
way of keeping your data safe from prying eyes. Otherwise, the
decision to employ encryption on file servers throughout your
enterprise should be weighed carefully. Since encryption results in
additional overhead on file servers, a better solution might be to
secure these servers physically in locked rooms.

On a system where you decide that encryption should be implemented,
the following folders could be encrypted:

• My Documents and any other folders where the
  user regularly stores work

• Temp folders (such as
  

  \Winnt\Temp ), so that any temporary files that
  are created but not deleted by applications are encrypted

You generally should encrypt folders instead of files, since some
applications create temporary files in odd locations that may not be
encrypted.

Recovery Policy

By default, when an

administrator
logs on to the domain for the first time, a recovery policy is
created to enable the administrator to perform the recovery of
encrypted data during disaster recovery. Otherwise, encrypted data
restored from backup media would not be decryptable if the
users' private keys and the encryption certificates
associated with the files happened to be lost when the disaster
occurred. The recovery policy creates a special encryption
certificate and private key that the recovery agent can use to
decrypt files that were created and encrypted by domain users. As
preparation for disaster recovery, the recovery agent should use the
Export command in the Certificates console to make
a copy of the recovery certificate and private key on a floppy disk
and keep this in a safe location. After restoring the crashed system,
this certificate and key can then be imported into the personal
certificate store of the recovery agent, enabling the agent to decrypt
the restored files.