In the first week of June, Microsoft released a near-final version of Windows Server 2012 alongside its client brother, Windows 8. In the days since that release, I've been spending time thoroughly examining some of the new features in the 2012 edition. Here's a preview of a few that I find particularly compelling. See our previous Windows Server review: Windows Server 8 review.
These are in addition to those I've already described in my earlier review of the Windows Server 2012 beta version -- multimachine management, numerous Hyper-V improvements, improved security and others. And it's worth noting, too, that the UI is still set to change by the time the software hits the "release to manufacturing" (RTM) stage, so I'll reserve my final judgment until then. At this point, I still believe that Metro is the wrong way to go for a server operating system aimed at professional systems administrators. Visit: Business Advisor.
Windows Server 2012: Dynamic access control
In Windows Server 2012, dynamic access control (DAC) is a suite of features and utilities that work together to augment the file system security that has been a part of Windows since the NT days. It joins classification, policy enforcement, auditing and encryption as another way to protect all sorts of data from unauthorized access and tampering.
Let's take a look at how this works, starting with a couple of different types of policies.
First are the central access policies, which make up a layer of security that complements the existing access control list (ACL) entries that we've come to know and love about the NT File System. These policies ride on top of ACLs and add an additional layer of authorization to file and object access. They also pertain to all servers in an organization, so they're applied very broadly and affect the entire business.
They also are more granular than specific file or folder ACLs and better translate to some of the business requirements you're likely to face. These policies take into account the identity of the user, what type of device the person is using for the access attempt and what kind of data is being accessed. It's more than just the yes-or-no choice that ACLs force you to make.
This is one of the spots in Active Directory Domain Services where you can set up dynamic access control policies.
For example, businesses could create policies that restrict access to a certain file or folder based on the nature of the information. This assists in overall organizational compliance with government and industry regulations.
Additionally, you can create policies to restrict access based on the current department a user is assigned to (as opposed to explicit security groups that would have to be updated regularly). Finally, you could create a scenario where certain sectors of one organization could access only information pertaining to their work, a situation that is common in financial institutions.
Central access policies work with the strategic placement of central audit policies, which basically back up the access policies and prove an organization is in compliance. When you take any government or industry compliance mandate and enter the conditions of that mandate into an audit policy, you can then retrieve instant reports to prove that you're applying and maintaining a policy that accrues to the spirit of the regulation.
You can also see instances where access was granted inappropriately and, from there, fine-tune your policy assignments to ensure those holes don't happen again. You can also spot scenarios where users or groups attempt to access information (and are unsuccessful at it) -- which is helpful from a security standpoint, since it shows where users need further education or consequences.
Access and audit policies work with the file classification infrastructure, which was introduced in Windows Server 2008 R2 and enhanced in this latest build. By classifying files, you apply tags that indicate various properties about them. The tags could be for the type of data, the type of regulation applying to the data, the time limit the data could be valid for, the expiration date of any confidentiality restrictions on the data and so on.
The central access and audit policies work with these tags to determine, along with the file system ACLs, what access can be granted to whom and on what conditions. For example, if you classify a certain folder as HIPAA-sensitive because it contains patient medical data, then the central access policy would glom on to that tag and activate when users attempt to access HIPAA information that the policy says should be restricted.
The audit policy would also key in to this activity and record the attempts, either successful or unsuccessful, for further monitoring. In addition, Windows Server 2012 can now encrypt files automatically based on their classification, so that all files with the HIPAA tag get encrypted automatically as soon as the tag is applied. That encryption is maintained and can also be audited for compliance purposes.
This suite of facilities really enhances the way you can control access to information. It's no longer about taking files or folders and making decisions about "yes, these people can" and "no, these people can't."
It's about abstracting away the individual data and making larger assignments about the types of data that live on your system, and the types of users that should and should not have access to it. It's a new way of thinking that very much complements the strong abilities of the file system to secure data.
To take full advantage of these additions, you'll need to make minimal schema additions to Active Directory. You can begin using the lion's share of the feature set of DAC with just a Windows Server 2012 file server and a domain controller - it's not a wholesale upgrade. It's a helpful addition to Windows Server 2012.