Azure Sentinel: Enterprise Governance (Part 2 of 3)

 



To read part 1 of 3 please click here
To read part 3 of 3 please click here

Azure Policies

Azure policy is a service you use to create, assign, and manage policies. Azure policies enforce different rules and effects over your resources so that those resources stay compliant with your corporate standards and service level agreements. 

There are three main pillars that help in the functionalities of Azure policy:

The first pillar is about real time enforcement and compliance assessment. For example- a policy would block the creation of resources that are located outside of US regions. The data powers the compliance view which aggregates results across all of the applied policies, that in turn can be used to ensure that resource groups are getting tagged properly and automatically inheriting those tags from the resource group down to the resources.

The second pillar of policy is applying policies at scale by leveraging Management Groups. One can easily impact hundreds of subscriptions and all its reach resources through a single policy assignment by applying policy to a management group. The concept called policy initiative allows you to group policies together so that you can view the aggregated compliance result. You can also exclude either the child management group subscription resource group or resources from the policy assignment.

The third pillar of your policy is remediation by leveraging a remediation policy that will automatically remediate the non-compliant resource so that your environment always stays compliant.You can also create a remediation task to bring the resources to compliance. Azure policy is a free service to use.

Policy permissions and custom policies

Azure policy has several permissions, known as operations in two resource providers i.e. Microsoft.Authorization and Microsoft.PolicyInsights. Many built-in roles grant permissions to Azure policy resources, but if none of the built-in roles have the required permissions, you can create a custom role. before creating a custom policy, you should check the policy samples to determine if the policy that matches your needs already exists. the approach to create a custom policy follows these steps:

  • Identify your business requirements
  • Map each requirement to an Azure resource property
  • map the property to an alias
  • Determine which effect to use
  • Compose the policy definition  

Composing an Azure policy

The steps for composing an Azure policy begins with creating:

  • Policy Definition- Every policy definition have conditions under which it is enforced and it has a defined effect that takes place if the conditions are met.

  • Policy Assignment- A policy definition that has been assigned to take place within a specific scope. The term scope refers to all the resources, resource groups, subscriptions, or management groups that the policy definition is assigned to.

  • Policy parameters- They help simplify your policy management by reducing the number of policy definitions you must create. You can define parameters when creating a policy definition to make it more generic.   

Azure Role Based Access Control (RBAC)

Organizations that are considering using the public cloud are always concerned about ensuring that when people leave the organization, they lose access to resources in the cloud and striking the right balance between autonomy as well as central governance. Azure AD and RBAC make it simple for you to carry out these goals. RBAC enables fine-grained access management for Azure. Using RBAC, you can grant just the amount of access that users need to perform their jobs.

Each Azure subscription is associated with one Azure AD directory. A subscription is associated with only one Azure AD tenant while a resource group can have multiple resources but is associated with only one subscription and can be bound to only one resource group.

Azure RBAC vs Azure Policies

There are a few differences between the two like- RBAC focuses on user actions at different scopes while Azure Policy focuses on resource properties during deployment and for already-existing resources. Unlike RBAC, Azure Policy is a default-allow-and-explicit-deny system.

RBAC

RBAC manages who can have access to Azure resources, what areas they have access to, and what they can do with those resources. Examples of RBAC includes:
  • Allowing a user, the ability to only manage virtual machines in a subscription and not the ability to manage virtual networks
  • Allowing a user, the ability to manage all resources, such as virtual machines, websites, and subnets, within a specified resource group.
  • Allowing a app, to access all resources in a resource group
  • Allowing a DBA group, to manage SQL databases in a subscription 
RBAC can grant users the least amount privileged to get their work done without affecting other aspects of an instance or subscription as set by the governance plan.

Policies

Policies on the other hand play a slightly different role governance. They focus on resource properties during deployment and for already existing resources. For example a policy can be issued to ensure users can only deploy DS series VMs within a specified resource if the users have permission to deploy the VMs.

RBAC and Policies in Azure play a vital role in a governance strategy and they work together to ensure organizational business rules are followed by ensuring the proper access and resource management creation guidelines are met.

Azure Built-in Roles

Azure RBAC has several built-in roles that can be assigned to users, groups, service principles, and managed identities. If the built-in roles don't meet the requirements of your organization, you can always create your own Azure custom roles. The four general built-in roles are:

  • Contributor- Allows you to manage everything except granting access to resources.

  • Owner- Allows you to manage everything including access to resources.

  • Reader- Allows to view everything, but not make any changes.

  • User Access Administrator- Lets you manage user access to Azure resources.  

Role assignments are the way you can control access to Azure resources.



To read part 1 of 3 please click here
To read part 3 of 3 please click here




Comments

Popular posts from this blog

Deployment (Part 3)

Deployment (Part 1)

Design Planning (Part 3)