Implementing a cloud governance model in Azure: Corner Pieces

Previously we have taken a high level look at how the governance models differ between a more traditional, and cloud approach, as well as the most pressuring factors which is shared between the models.

Since each of the following items is specializations in their own right, I’ll summarize each item, and references for further reading can be found at end of this post.

Security Baseline Summary

The security baseline is typically laid out as follows:

    • Identified business risks which is translated into security/IT requirements
    • Risk tolerance for the business
    • Policies and compliance for mitigation
    • Monitoring and reporting

The agility which is associated with cloud computing, is the major differentiator between an on premises deployment, and a cloud deployment. This is due to resources that can be created, modified, or deleted much faster. This increase in risk, and the potential for adding vulnerabilities requires that we iterate over the our security baseline faster in order to successfully secure assets and data.

Seeing that this series is focused on Azure, lets look at some of functionality that can be incorporated into our tool chain:

Control Azure Tooling
Preemptive detection for vulnerabilities, and complianceAzure Security Center
Secure virtual networksAzure Resource Manager
Azure Firewall
Azure DDoS
Access control, and identity managementAzure AD
Azure AD Domain Services
Activity monitoring and alertingAzure Monitor
Activity Log
Data classificationAzure Information Protection
Security Information and Event Management (SIEM)Azure Sentinel
Connecting to on premisesAzure VPN Gateway
Azure Private Link

Identity Baseline Summary

I am going to quote the Microsoft Cloud Adoption Framework on the subject of identity baseline since it is a very accurate statement in our technological landscape today, and doesn’t only apply to Azure:

Identity is increasingly considered the primary security perimeter in the cloud, which is a shift from the traditional focus on network security. Identity services provide the core mechanisms supporting access control and organization within IT environments

To successfully migrate to Azure, is to establish the key areas as follows:

    • Assessing all existing identity providers currently in use, to determine whether a hybrid identity system can be used
    • Dealing with privileged access
    • Applying the principle of least privilege
    • Ensuring that all accounts are secured
    • Monitoring for suspicious activity
    • Complying with policy and external compliance (example, GDPR)

Mapping the controls to some of the available functionality in Azure will be as follow:

ControlAzure Tooling
Authorization and authenticationAzure AD
Azure AD B2B
Azure AD B2C
Privileged accessAzure AD PIM
Azure Managed Identities
Principle of least privilegeAzure AD (RBAC)
Suspicious account activitiesAzure Security Center
Azure Sentinel
Azure Monitor
Securing of accountsAzure AD Conditional Access
Azure AD MFA
Hybrid identityAzure AD Connect
Additional support for Google accounts, social accounts

Deployment Acceleration Summary

The deployment acceleration discipline, is to define, capture, and report on configurations, and the drift within configurations as application and infrastructure deployments progress.

On premises, deployments are done against a baseline configuration, VM images, scripts, and so forth. For the cloud, this changes to either infrastructure as code, or primarily script base deployments as you don’t manage any physical infrastructure. This discipline can therefore be seen, as how you tie your DevOps (or DevSecOps) into your governance strategy.

High level areas which this discipline attempts to address is the following:

    • Service disruption due to unmanaged configurations, unpredictable deployments
    • Deployment inefficiencies because a unified cloud deployment model is not adopted

Mapping out a few of the controls to Azure would be as follows:

ControlAzure Tooling
Configuration discoveryAzure Graph
Managing configuration driftAzure Policy
Azure DevOps
Manual deployment of assetsAzure Portal
Azure Resource Manager
Azure Site Recovery
Automated deployment of assetsAzure Resource Manager
Azure DevOps
Azure Site Recovery
Updating configurations for multiple assetsAzure Policy
Azure DevOps
Azure Resource Manager
Azure Site Recovery

Resource Consistency Summary

The resource consistency discipline, on face value, takes a second to tie in to what it is about. It is focused on operational management, adapted to cloud resources.

The primary areas for this discipline is summarized as follows:

    • Asset utilization for monitoring of over or under utilization.
    • Asset classification (tagging of resources) for cost monitoring, identifying resources for SLA’s, RTO and RPO, etc.
    • Backup and recovery monitoring

Mapping controls to Azure services for resource consistency will look like this:

ControlAzure Tooling
Resource deployment and managementAzure Portal
Azure Resource Manager
Azure Blueprints
Azure Automation
Deployment orchestrationAzure Blueprints
Application and data recovery for outages or SLA violationsAzure Site Recovery
Azure Backup
Telemetry logging for resourcesAzure Monitor
Azure Log Analytics
Application Insights
3rd Party tool integrationAzure Monitor REST API

Cost Management Summary

Cost management is considered its own discipline in cloud environments for simple reason, instead of relying on capital expenditure (CAPEX) processes, it follows an operational expenditure (OPEX) model.

There is no hardware or data center acquisition process to follow, deployment(s) can happen in minutes to hours for services that could take months to deploy on premises. The obvious downside to this, is it can lead to cost spiraling out of control, instead of seeing a decrease in costs. Misconfigured deployments can quickly eat through any budget, or go unnoticed wasting capital.

This discipline is built on the previous ones, and each small part essentially makes up the cost management discipline.

The primary area of focus is quite straightforward, and not onerous to achieve:

    • Monitor for unused resources
    • Ensure classification (tagging) of all resources to allocate costs accordingly
    • Under utilized services is wasteful expenditure
    • Consider reserved capacity where feasible

The control to Azure tool mapping as follows:

ControlAzure Tooling
Budget controlAzure Cost Management
Azure Policy
Azure Blueprints
Monitor spendingAzure Cost Management
Azure Content Pack (Enterprise agreement required)
Azure Portal
Cost analysisAzure Cost Management
Azure Content Pack (Enterprise agreement required)
Enforce accounting metadata and spending rulesAzure Policy
Azure Blueprints

Further Reading

As previously stated, this series is based on Azure, although the topics can relate to other cloud platforms as well. Below is the link to Microsoft Cloud Disciplines which goes into a lot more detail than the summaries above:

Next Steps

You might have noticed in this post that the most mentioned Azure services are Azure Policy and Azure Blueprints. Although Azure Policy can stand on its own, Azure Blueprint doesn’t, as it depends on Azure Policy, RBAC, and ARM quite a bit. The next post will start delving into the details on implementing Azure Blueprints, and how it assists with governance and compliance for Azure workloads.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s