NTFS 权限讲解 ACL

节选自：Securing Windows Server 2003

4.1 Protecting Files with NTFS File Permissions

The primary technique for protecting data on a hard drive is to use the built-in NTFS file permissions to allow or restrict specific users and groups. A user could allow his user account to access his personal research data while restricting other users. He could also designate some files as readable by all users but writable by only his coworkers and manager. At home, he could restrict certain folders so that only he could read their contents, while allowing only himself and his wife to read others. You may want to share files on Windows Server 2003 and allow only the HR group access. File permissions are configurable and flexible enough to work in many different scenarios.

4.1.1 How File Permissions Work

When a user logs into a Windows system, as described in Chapter 7, an access token is granted to the user’s session, which the operating system uses to prove her identity to local and network resources. Every access token contains the security identifier (SID) of the user as its key component and the SIDs of the groups she belongs to. This information allows operating system components that are concerned about security to simply check to see whether any of the SIDs provided in the access token have been granted or denied access to their data or services.

File permissions simply attach a list of SIDs and the access rights granted or denied for each SID to a file or directory. This list of SIDs is known as an access control list (ACL), and each entry in the list is an access control entry (ACE). An ACL is composed of one or more ACEs. Whenever a user or process makes a request to access a file or directory, NTFS retrieves the corresponding ACL for that object. It then runs down the list of ACEs on the object, comparing each to every SID in the access token of the requesting entity (usually a user). NTFS accumulates the permissions it finds and determines whether the permissions are enough to meet the requested needs of the requester. If the permissions are sufficient, the process succeeds and the requester accesses the object. When all the requested permissions are not granted, the request fails.

Permissions can be set on individual files or on the folders that contain them. When permissions are set on files, there is no effect on the other files in the same folder. Setting permissions on folders allows NTFS to configure all subfolders and files with the same permissions. This also ensures that new files within that folder inherit the same permissions. This can be beneficial when setting up secure file shares and when one wants to ensure that both existing and new files have appropriate permissions configured.

File Security and NTFS

It is worth noting at this point that all Windows operating systems rely on the NT File System (NTFS) for providing file system security. Windows XP and the Windows Server 2003 family also support older versions of the File Allocation Table (FAT) file system in its many variations, including FAT12, FAT16, and FAT32. These file systems were not designed to incorporate access control and security mechanisms in their data storage. They provide no data security whatsoever. You should always use NTFS unless you have a strong need for one of the older file systems, such as a need to boot multiple operating systems on a single computer. Because this configuration is unwise and unsupported, you should avoid it.

Using NTFS also helps to prevent another insecure computer configuration—the dual-boot configuration. Having more than one operating system on a computer at any given time allows an attacker a far greater attack surface. Often one operating system can bypass or ignore security measures implemented by another. Though there are some technical means that you can employ to prevent this configuration, a strong administrative policy and an educated IT staff will most likely prevent such configurations.

Consider our user David Loudon. David has an account in an Active Directory domain that he logs into daily to perform his work. David is a member of several security groups, as shown in Figure 4-1.

Figure 4-1. David Loudon’s group memberships

David wants to open a file on the local hard drive called Super Secret Info.txt. Because David is concerned with security, he sets permissions on it. He doesn’t want any other users, including domain administrators, to access the file. He configures the file with the permissions shown in Figure 4-2.

Figure 4-2. David has restricted the file permissions so that he is the only user with access

David now has full control of the file, and members of the Domain Admins group are explicitly denied access. Notice that there are no other entries in the ACL. Because the default behavior of Windows Server 2003 is to deny permission unless granted, any user that is not on the list will be denied access to Super Secret Info.txt. David doesn’t need to add a Deny ACE for every user or group in the domain. He simply needs to ensure that no unintended users or groups are granted permission.

Let’s assume that at some point David is promoted or transferred into a job that requires him to have different permission on the domain. Don, our security administrator, adds David to the Domain Admins group to ensure he has the proper permissions. David thinks nothing of this change, as he is being granted additional permissions that should allow him to perform any task on any computer within the domain. However, when David attempts to open Super Secret Info.txt, he gets an “Access denied” error message. This is because NTFS considers the Deny permission to be most important. Whenever an ACL is interpreted, an explicitly denied permission takes precedence over all other permissions. If David or any group he is a member of is explicitly denied permission, he is denied permission to access the file, even in the case of conflicting levels of permission.

A good administrative practice is to add groups, not individual users, to permissions for file and folder objects. Then you can rely on proper group maintenance to ensure that access is maintained.

A quick way to verify David’s access to the file is the Effective Permissions tab of the Advanced Security Settings dialog box shown in Figure 4-2. This tab allows an administrator to type a username and view the effective permissions that the user will receive. In this case, providing David’s name would show that he has no access. This tab is currently available only in Windows Server 2003.

To allow David to access his file again, Don temporarily removes him from the Domain Admins group.

Even though David is getting an access denied message, security is working properly. This concept will be detailed later in this chapter.

David may have another file that he wants to share among his peers. He wants to ensure that only his group has access. He also wants to avoid ongoing maintenance of the ACL on this file, allowing users who enter and leave his workgroup to be automatically added and removed from the file permissions. He sets security on the file as shown in Figure 4-3. This security has no permissions for individual users, only the Corporate Accounts Payable group. So as long as the group membership is maintained, the file will be accessible by the appropriate users.

Figure 4-3. File permissions

This configuration works well for David. Because only the Corporate Accounts Payable group is given access to the file, only members of that group can access the file. All other users receive the default permission, which is no access. As users join and leave the corporate accounts payable staff, the group is updated by human resources and the IT department’s Domain Admins groups. David needs to take no action to maintain access on the file now that it is configured correctly.

4.1.2 How to Configure File Permissions

You learned in the previous section that setting appropriate file permissions is not terribly difficult when some basic guidelines are considered. These guidelines can be summarized as follows:

• Apply only granted permissions whenever possible. Avoid Deny permissions, as they override all other permissions and can be difficult to implement when many permissions are assigned to one file.
• Use the Deny—Full Control permission sparingly for the same reason. This is especially true when you think about assigning Deny to Everyone. At that point, you’ve essentially rendered the data inaccessible to anyone except administrators, who can manually take ownership and reestablish the proper permissions on the object.
• Permit groups of users instead of individual users when possible. This permits you to allow and deny user access to files by simply modifying a group’s membership, rather than having to reapply permissions to all files and folders.
• Permit access to folders instead of individual files.

4.1.2.1 Example: setting up a secure file share

Imagine an employee of your company, David, asks you to set up a place where he can share files within his branch office. He plans to store a few spreadsheets and documents on this share, consuming a minimum of space. He wants the files to remain confidential to only the employees at his branch. While he is not the least-savvy computer user in the organization, you do not want him to have to maintain any of this security manually.

To set up the file share and configure it for the appropriate level of security, you would perform these tasks:

1. Create a folder on the appropriate hard drive using Windows Explorer. This can be right off the root directory or in a subdirectory based on organizational boundaries, geographical region of the user, and so on. The location of the directory does not matter.
2. Right-click the folder, click Properties, and then click Security. The default ACL for folders on this drive is displayed as shown in Figure 4-4.

Figure 4-4. Default access control list

1. Click Advanced to display the advanced folder permissions dialog as shown in Figure 4-5.

Figure 4-5. The advanced folder permissions list

1. Deselect the option of “Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here.” Deselecting this option allows explicit ACLs to be set on this folder without inheriting other ACLs from the parent folder. This is not required but allows Don, the administrator, to ensure that even administrators do not have access to this folder.
2. Click Remove on the dialog box that appears for all the existing ACEs. The ACL will now be blank.
3. Add the desired groups and users as shown in Figure 4-6. In our example, David Loudon’s branch users in Valdosta are the only users with access permission. Because this group is administered by the IT and HR departments, we can configure the folder so that it will not require maintenance every time an employee joins or leaves the branch.
4. Click OK to finish configuring the file permissions. Click Sharing to share this folder on the network. Select Share This Folder and click OK.

Figure 4-6. Adding the Valdosta users

You will notice that permissions can also be set on the share. These permissions are similar to the permissions you just set on the folder, although folder permissions are more granular. The difference is that you configured the folder permissions so that access is restricted both locally and on the network. Although share permissions can be set to be similar to the file and folder permissions, it is not required to meet the goal of securing the files.

Deciding whether to use NTFS or share permissions is a bit like deciding which hair color is best. There’s no perfect answer, and whichever option suits you and meets the security goal should be used. The most important thing to remember is that NTFS permissions apply both locally and over the network, while share permissions affect only network access. While many argue that this means NTFS permissions are universally a better practice than share permissions, I leave it to you to decide. Personally, I apply both just to be sure.

Now the folder is secure. David’s group can access the folder and all its files and subfolders. No other users can access the contents, as they are not explicitly granted permissions. The permissions will dynamically change as David’s group grows or shrinks, because the group membership is managed separately. No further security maintenance on this folder is needed to ensure its security.

4.1.2.2 Example: implementing local file security for a shared computer

Frequently, computers are shared by two or more users. This is often the case in manufacturing departments with multiple shifts when it makes no sense to provide individual computers for each shift worker.

Consider a fictional company, Woodgrove Bank. In Woodgrove Bank, two or three receptionists share one computer during the day. One receptionist, Brian Valentine, wants to keep personal data on the local computer but protect it from being accessed by the other receptionists. Because the data is of a personal nature, he wants to ensure that the most security possible is applied to these files.

Brian can use the following procedure to apply strong security to his local folder and its contents:

1. Create a folder on a local hard drive or choose an existing folder with the files already in place. The location of the directory does not matter.
2. Right-click the folder, click Properties, and then click Security. The default ACL for folders on this drive is displayed.
3. Click Advanced to display the advanced folder permissions dialog.
4. Deselect the option to “Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here.” Deselecting this option allows explicit ACLs to be set on this folder without inheriting other ACLs from the parent folder.
5. Select the option to “Replace permission entries on all child objects with entries shown here that apply to child objects.” This ensures that all existing files and subfolders receive the new ACL.
6. Click Remove on the dialog box that appears for all the existing ACEs. The ACL will now be blank.
7. Add only Brian’s account with Full Control configured as Allow. Because Brian is a bit paranoid, also add Domain Admins with Full Control configured as Deny. This is shown in Figure 4-7.
8. Click OK to finish configuring the permissions.

I said earlier that setting Deny permissions on files and folders is a bad idea. If Brian is ever added to the Domain Admins group, he will be denied access to the files in this folder. Because this is highly unlikely, Brian will probably never encounter problems with this permission.

Figure 4-7. Denying the Domain Admins group access

The result of this procedure is that Brian is the only user who has access to his folder and its contents. Any other user attempting to view his data will receive an “Access denied” message. However, an administrator could still gain access by simply adding himself to the ACL list. Because Brian is not a local administrator, he cannot prevent this possibility.