This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Earlier this year, we introduced Microsoft Purview DevOps policies, a simple cloud-based experience to provision access at-scale for IT operations and security auditing personnel. Today, we are announcing the General Availability (GA) of this capability.
Data is at the core of any modern process. To continue to operate, organizations must ensure the integrity and high availability of their databases. At the same time, critical IP, customer, and employee information must be protected by ensuring appropriate visibility and to preserve user privacy. As requirements become more challenging, new solutions are necessary.
Microsoft Purview DevOps policies structure the process of granting and revoking access to system metadata views like DMVs and DMFs. These are SQL queries that return information about model objects, server and database performance, as well as server health. DevOps policies provide IT operations personnel and other DevOps users access to the information they need to keep databases running and secure.
Access is provisioned from the Microsoft Purview portal, replacing the need for administrators with privileged accounts to configure that access locally, that is, at each SQL Server. Limiting the use of privileged accounts is key to reducing the insider threat, arguably one of the most challenging current security threats. Since access is granted centrally, it can be easily reviewed by auditors. Access that is no longer needed can be easily identified and removed.
DevOps policies follow the Principle of Least Privilege (PoLP), which in essence means “grant users the minimum access required to perform their jobs”. DevOps policies have been structured based on a couple of typical IT personas: the “SQL Performance Monitor” and the “SQL Security Auditor”. The first deals with monitoring system health to ensure database integrity and high availability, i.e., the ‘server/database performance state’. The second deals with reviewing the ‘server/database security state’, which includes views on permissions, principals, endpoints, tokens, database encryption keys and firewall rules. The DevOps policies capability maps these two roles to a minimum set of permissions that are needed to execute these IT functions. Neither of these two roles gets access to the user data.
Beyond the security benefits outlined above, DevOps policies:
- Reduce the effort needed to create logins and grant or revoke multiple SQL permissions. Less expertise is required without compromising security. DevOps policies help reduce the potential for mistakes, as humans can miss needed permissions or add ones that are not necessary.
- Support policies on entire resource groups and subscriptions, which means they can be enforced uniformly by all SQL servers inside that resource group or subscription. Also, new logical servers added to the resource group or subscription start enforcing the policy.
- DevOps policies support Azure AD groups. If an IT operator leaves his/her job and gets backfilled, the Azure AD group has to be updated but no updates are needed to the SQL servers or to Microsoft Purview policies.
Currently, DevOps policies are supported on Arc-enabled SQL Server (GA) and Azure SQL Database (Public Preview). You can get started today!