Server-Level Security - File-Level Security
(Page 5 of 7 )
Files secured on Windows Server 2003 are only as secure as the permissions that are set on them. Subsequently, it is good to know that Windows Server 2003, for the first time in a Microsoft operating system, does not grant the Everyone group full control over share-level and NTFS-level permissions. In addition, critical operating system files and directories are secured to disallow their unauthorized use.
Despite the overall improvements made, a complete understanding of file-level security is recommended to ensure that the file-level security of a server is not neglected.
NT File System Security The latest revision of the NT File System (NTFS) is used in Windows Server 2003 to provide for file-level security in the operating system. Each object that is referenced in NTFS, which includes files and folders, is marked by an Access Control Entry (ACE) that physically limits who can and cannot access a resource. NTFS permissions utilize this concept to strictly control read, write, and other types of access on files.
File servers should make judicious use of NTFS-level permissions, and all directories should have the file-level permissions audited to determine if there are any holes in the NTFS permission-set. Changing NTFS permissions in Windows Server 2003 is a straightforward process; simply follow these steps:
Right-click the folder or file onto which the security will be applied and choose Sharing and Security.
Select the Security tab.
Click the Advanced button.
Uncheck the Allow Inheritable Permissions from the Parent to Propagate box.
Click Remove when prompted about the application of parent permissions.
While you're in the Advanced dialog box, use the Add buttons to give access to the groups and/or users who need access to the files or folders.
Check the Replace Permission Entries on All Child Objects box, as illustrated in Figure 12.7, and click OK.
When prompted about replacing security on child objects, click Yes to replace child object security and continue.
Click OK to close the property page.
Share-Level Security Versus NTFS Security Previous Windows security used share-level permissions, which were independently set. A share is a file server entry point, such as \\sfofs01\marketing, that allows users access to a specific directory on a file server. Older file systems such as FAT, HPFS, and FAT32 did not include file-level security, so the security was set instead on the share level. While share-level security can still be set on files, it is preferable to use NTFS-level security, where possible. Share-level security is not very secure because it cannot secure the contents of subdirectories easily.
Figure 12.7
Setting NTFS permissions.
Note - A common best practice for file servers in Windows Server 2003 is to configure share-level security to be wide open for all domain users but then to set stricter security on the NTFS level. This allows for security to be administered on the NTFS level only, without the fear of share-level restrictions interfering.
Auditing File Access A good practice for file-level security is to set up auditing on a particular server, directory, or file. Auditing on NTFS volumes allows administrators to be notified of who is accessing, or attempting to access, a particular directory. For example, it may be wise to audit access to a critical network share, such as a finance folder, to determine whether anyone is attempting to access restricted information.
Note - Audit Entries are another example of security settings that can be automatically set via security templates in Windows Server 2003. It is wise to consider the use of security templates to more effectively control audit settings.
The following steps illustrate how to set up simple auditing on a folder in Windows Server 2003:
Right-click the folder or file onto which the auditing will be applied and choose Properties.
Select the Security tab.
Click the Advanced button.
Select the Auditing tab.
Uncheck the Allow Inheritable Auditing Entries from the Parent to Propagate box and click Apply.
Using the Add button, enter all users and groups that will be audited. If you're auditing all users, enter the Everyone group.
In the Auditing property page, select all types of access that will be audited. If you're auditing for all success and failure attempts, select all the options, as indicated in Figure 12.8.
Click the OK button to apply the settings.
Check the Replace Auditing Entries on All Child Objects box and click OK twice to save the settings.
Figure 12.8
Selecting what to audit.
Note - An effective way of catching "snoops" in the act is to create serious-looking shares on the network, such as Financial Statements, Root Info, or similar such shares, and audit access to those folders. This technique has been successfully used to identify internal (or external) saboteurs before they could do some serious damage.
Encrypting Files with the Encrypting File Service Windows Server 2003 continues support for the Encrypting File System (EFS), a method of scrambling the contents of files to make them unintelligible to unauthorized users. EFS has proven to be valuable for organizations that desire to keep proprietary data, especially those stored on laptops, out of the wrong hands.
Windows 2000 supports EFS, but it was not until the release of Windows XP that EFS saw strong use as it became accessible through the Windows Explorer menus. From the server side, however, EFS was limited because offline files stored on file servers could not be encrypted. Windows Server 2003 improves upon this design, offering support for offline files to be encrypted via EFS. This added functionality makes EFS a valuable addition to the server-side security available in Windows Server 2003.
Next: Additional Security Mechanisms >>
More MS SQL Server Articles
More By Sams Publishing
|
 This article is excerpted from chapter 12 of MS Windows Server 2003 Unleashed 2nd edition, written by Rand Morimoto (Sams, 2004; ISBN: 0672326671). Check it out at your favorite bookstore. Buy this book now.
|
|
