Dynamic Access Control Technical Preview

  • Article

Updated: February 29, 2012

Applies To: Windows Server 8 Beta

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

In Windows Server “8” Beta, you can apply data governance across your file servers to control who can access information and to audit who has accessed information. Dynamic Access Control lets you:

  • Identify data by using automatic and manual classification of files. For example, you could tag data in file servers across the organization.

  • Control access to files by applying safety-net policies that use central access policies. For example, you could define who can access health information within the organization.

  • Audit access to files by using central audit policies for compliance reporting and forensic analysis. For example, you could identify who accessed highly sensitive information.

  • Apply Rights Management Services (RMS) protection by using automatic RMS encryption for sensitive Microsoft Office documents. For example, you could configure RMS to encrypt all documents that contain Health Insurance Portability and Accountability Act (HIPAA) information.

This feature set is based on infrastructure investments that can be further used by partners and line-of-business applications, and the features can provide great value for organizations that use Active Directory. This infrastructure includes:

  • A new authorization and audit engine for Windows that can process conditional expressions and central policies

  • Kerberos authentication support for user claims and device claims

  • Improvements to the File Classification Infrastructure (FCI)

  • RMS extensibility support so that partners can provide solutions that encrypt non-Microsoft files

Key benefit

You can comply with business and regulatory standards by using user claims and file classifications to centrally control access, audit access, and use RMS to protect information in files.

Requirements

This feature requires the following:

  • Windows Server “8” Beta

  • Active Directory Domain Services

  • File Server

  • Rights Management Server (required only for the RMS extensibility support scenario)

Technical overview

Windows Server “8” Beta provides the following new ways to control access to your files while providing authorized users the resources they need:

  • Central access control for information governance

  • Policy changes and staging

  • File access auditing for forensic analysis and compliance

  • Access-denied remediation to troubleshoot file and shared folder access problems

  • Classification-based encryption for sensitive Microsoft Office documents

The following sections describe these features in more detail.

Central access control

Central access policies for files allow organizations to centrally deploy and manage authorization policies that include conditional expressions using user claims, device claims, and resource properties. Claims are assertions about the attributes of the object with which they are associated. For example, for accessing high-business-impact (HBI) data, a user must be a full-time employee, obtain access from a managed device, and log on with a smart card. These policies are defined and hosted in Active Directory.

The various organizational access policies are driven by compliance and business regulatory requirements. For example, if an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department that are allowed to view PII information, this is an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. In this example, you need to be able to:

  • Identify and mark the files that contain PII.

  • Identify the group of HR members who are allowed to view PII information.

  • Have a central access policy that can easily be applied to all files that contain PII wherever they are located amongst the file servers across the organization.

The initiative to deploy and enforce an authorization policy may come for many reasons and from multiple levels of the organization. The following are some example policies:

  • Organization-wide authorization policy. Most commonly initiated from the information security office, this authorization policy is driven from compliance or a high-level organization requirement and would be relevant across the organization. For example, HBI files should be accessible to only full-time employees.

  • Departmental authorization policy. Each department in an organization has some special data-handling requirements that they want to enforce. For example, the finance department might want to limit access to finance servers to the finance employees.

  • Specific data-management policy. This policy usually relates to compliance and business requirements, and it is targeted at protecting the correct access to the information that is being managed, such as preventing modifying or deleting files that are under retention or files that are under electronic discovery (eDiscovery).

  • Need-to-know policy. This is an authorization policy type and is typically used in conjunction with the policy types mentioned earlier. Examples include:

    • Vendors should be able to access and edit-only files that pertain to a project they are working on.

    • Financial institutions should implement information walls so that analysts do not access brokerage information and brokers do not access analysis information.

Real-life environments also teach us that every authorization policy needs to have exceptions so that organizations can quickly react when important business needs arise. For example, executives who cannot find their smart cards and need quick access to HBI information can call the Help Desk to get a temporary exception to access that information.

Central access policies act as security umbrellas that an organization applies across its servers. These policies enhance (but do not replace) the local access policies or discretionary access control lists (DACL) that are applied to files and folders. For example, if a DACL on a file allows access to a specific user, but a central policy that is applied to the file restricts access to the same user, the user cannot obtain access to the file.

A central policy rule has the following logical parts:

  • Applicability. A condition that defines which data the policy applies to, such as Resource.BusinessImpact=High.

  • Access conditions. A list of one or more access control entries (ACEs) that define who can access the data, such as Allow | Full Control | User.EmployeeType=FTE.

  • Exception. An additional list of one or more ACEs that define an exception for the policy, such as MemberOf(HBIExceptionGroup).

The following two figures show the moving parts in a central access and audit policy.

 

Image 1

Figure 1   Central access and audit policy concepts

Image 2

Figure 2   Central access policy workflow

 

The central authorization policy combines the following components:

  • Centrally defined access rules that target specific types of information, such as HBI or PII.

  • A centrally defined policy that contains a list of rules.

  • A policy identifier that is assigned to each file on the file servers to point to a specific central list of policies that should be applied during the access authorization.

The following figure demonstrates how you can combine policies into policy lists to centrally control access to files.

Image 3

Figure 3   Combining policies

Policy changes and staging

When you want to change a policy, Windows Server “8” Betaallows you to use a proposed policy that runs parallel to the current access policy so that you can identify the consequences of the new policy without enforcing it. This feature, called policy staging, lets you measure the effects of a new access policy on your production environment.

When policy staging is enabled, Windows Server “8” Beta continues to use the current access policy to authorize user’s access to files. However, if the result of the proposed policy is different than the access result of the current policy, the system logs an event with the details. You can use the logged events to determine whether the policy needs to be changed or is ready to be deployed.

File access auditing

Security auditing is one of the most powerful tools to help maintain the security of an enterprise. One of the key goals of security audits is regulatory compliance. For example, industry standards such as Sarbanes Oxley, HIPAA, and Payment Card Industry (PCI) require enterprises to follow a strict set of rules related to data security and privacy. Security audits help establish the presence or absence of such policies; thereby, they prove compliance or noncompliance with these standards. Additionally, security audits help detect anomalous behavior, identify and mitigate gaps in security policy, and deter irresponsible behavior by creating a record of user activity that can be used for forensic analysis.

Audit policy requirements are typically driven at the following levels:

  • Information security. File access audit trails are often used for forensic analysis and intrusion detection. Being able to get targeted events about access to high-value information lets organizations considerably improve their response time and investigation accuracy.

  • Organizational policy. For example, organizations regulated by PCI standards could have a central policy to monitor access to all files that are marked as containing credit card information and PII.

  • Departmental policy. For example, the finance department may require that the ability to modify certain finance documents (such as a quarterly earnings report) be restricted to the finance department, and thus the department would want to monitor all other attempts to change these documents.

  • Business policy. For example, business owners may want to monitor all unauthorized attempts to view data belonging to their projects.

Additionally, the compliance department may want to monitor all changes to central authorization policies and policy constructs such as user, computer, and resource attributes.

One of the biggest considerations of security audits is the cost of collecting, storing, and analyzing audit events. If the audit policies are too broad, the volume of audit events collected rises, and this increases costs. If the audit policies are too narrow, you risk missing important events.

With Windows Server “8” Beta, you can author audit policies by using claims and resource properties. This leads to richer, more targeted, and easier-to-manage audit policies. It enables scenarios that, until now, were either impossible or too difficult to perform. The following are examples of audit policies that administrators can author:

  • Audit everyone who does not have a high security clearance and yet tries to access an HBI document. For example, Audit | Everyone | All-Access | Resource.BusinessImpact=HBI AND User.SecurityClearance!=High.

  • Audit all vendors when they try to access documents that are related to projects they are not working on. For example, Audit | Everyone | All-Access | User.EmploymentStatus=Vendor AND User.Project Not_AnyOf Resource.Project.

These policies help regulate the volume of audit events and limit them to only the most relevant data or users.

After administrators have created and applied the audit policies, the next consideration for them is gleaning meaningful information from the audit events that they collected. Expression-based audit events help reduce the volume of audits. However, users need a way to query these events for meaningful information and ask questions such as, “Who is accessing my HBI data?” or “Was there an unauthorized attempt to access sensitive data?”

Windows Server “8” Beta enhances existing data access events with user, computer, and resource claims. These events are generated on a per-server basis. To provide a full view of events across the organization, Microsoft is working with partners to provide event collection and analysis tools, such as System Center Operation Manager Audit Collection Service (SCOM/ACS).

Figure 4 shows the moving parts of a central audit policy.

Image 4

Figure 4    Central auditing experiences

Setting up and consuming security audits typically involves the following general steps:

  1. Identifying the correct set of data and users to monitor

  2. Creating and applying appropriate audit policies

  3. Collecting and analyzing audit events

  4. Managing and monitoring the policies that were created

Access-denied remediation

Access-denied remediation in Windows Server “8” Beta provides three processes to grant users access to the resources they need:

  • Self-remediation. If users can determine what the issue is and remediate the problem so that they can get the requested access, the impact to the business is low and no special exceptions are needed in the organization access policy. Windows Server “8” Beta provides a general access-denied message that is authored by the server administrator for users so that they can try to self-remediate access-denied cases. This message can also include URLs to direct the users to self-remediation websites that are provided by the organization.

  • Remediation by the data owner. Windows Server “8” Beta allows administrators to define owners of shared folders in the form of a distribution list so that users can directly connect with the data owners to request access. This is similar to the Microsoft SharePoint model where the data owner gets a request from the user to gain access to the files. In the File Server case, the remediation can range from adding the user rights for the appropriate file or directory to dealing with shared folder permissions. For example, if a DACL on a file allows access to a specific user, but a central policy restricts access to the same user, the user will not be able to gain access to the file and global policies. share lets the user request access to a file or folder, which results in sending an email with the request details to the data owner. Data owners can forward this information to the appropriate IT administrator if they cannot remediate the issues.

  • Remediation by Help Desk and file server administrators. This type of remediation happens when the user cannot self-remediate the issue and the data owner cannot help. This is the most costly and time-consuming remediation. Windows Server “8” Beta provides a user interface where administrators can view the effective permission for users for a file or folder so that it is easier to troubleshoot access issues.

The following figure shows the steps that can be taken to remediate an issue if a user is denied access to a resource.

Image 4

Figure 5  Remediation options

To make it easier on Help Desk and IT administrators, it is important to provide them with all the relevant access details and tools (such as effective access permissions), so that they can determine the issue and then make the configuration changes to satisfy the access request.

For example, users might follow this process to access a file that they currently do not have access to:

  • The user attempts to read a file at \\financeshares, but the server returns an Access Denied error.

  • Windows displays the Access Denied dialog box.

  • Windows retrieves the access remediation information from Remediation Service on the file server.

  • Windows displays access remediation options to the user with an option to request access.

  • The user requests access to the resource.

  • The server sends an email with access request information to the resource owner.

Applications such as those included in Windows Office can also take advantage of the new enhancements by directly using the new Windows UI or by calling the new access-denied remediation API.

Classification-based encryption for Windows Office documents

Protection of sensitive information is mainly about mitigating risk for the organization. Various compliance regulations, such as HIPAA or Payment Card Industry Data Security Standard (PCI-DSS), dictate encryption of information, and there are numerous business reasons to encrypt sensitive business information. However, encrypting information is expensive, and it might impair business productivity. Thus, organizations tend to have different approaches and priorities for encrypting their information.

To support this scenario, Windows Server “8” Beta provides the ability to automatically encrypt sensitive Windows Office files based on their classification. This is done through file management tasks that invoke RMS protection for sensitive documents a few seconds after the file is identified as being a sensitive file on the file server (continuous file management tasks on the file server).

RMS encryption provides another layer of protection for files. Even if a person with access to a sensitive file inadvertently sends that file through email, the file is protected by the RMS encryption. Users who want to access the file must first authenticate themselves to an RMS server to receive the decryption key. The following figure shows this process.

Image 6

Figure 6   Classification-based RMS protection

Support for non-Microsoft file formats is available through non-Microsoft vendors. After a file has been protected by RMS encryption, data management features such as search- or content-based classification are no longer available for that file.