Most organizations have some form of workload in the cloud, whether it is testing the waters or a full end to end solution generating revenue. Organizations and business leaders have become increasingly sophisticated in identifying and managing risks as well as setting goals through using some common IT governance frameworks. Extending those policies out to Azure can be a painful process without the proper guidance to leverage effective tools and strategies.
The good news is that your development staff is invigorated and delivering faster than ever! The bad news is that deployments have slowed to a crawl to ensure that Azure workloads meet the same standards as your on-premises stack. The best news is that Azure has effective governance solutions that can be implemented to meet the speed of delivery your business is demanding while still maintaining a high degree of trust, and we can leverage mature concepts such as governance as code to create best in class practices for expressing your governance practices in the cloud.
A developer getting started in the Azure portal creating a SQL virtual machine can easily, and naively deploy the VM and allows access via HTTP (port 80), HTTPS (port 443), TDS (port 1433), and RDP (port 3389) to anyone with credentials and potentially even with anonymous access. Mission critical proprietary data now has multiple attack vectors! Onsite, this would have been requested through a self-service portal, and the ports would already have been locked down. It is a trivial exercise in Azure to open these ports in the process of creating a VM in the Azure portal. Obviously, we must have the same protections in Azure that we would have on-premises, or we risk putting internal data, and any custodial data at risk.
Policies can help us define some governance guard rails
We created a simple policy that will make demands during deployment to only allow certain ports to be opened, that all traffic be routed through the azure firewall, and that software patch levels are maintained. This will not only stop an invalid deployment, but the governance policy can also monitor existing deployments, and will continually monitor multiple times per day.
Another insidious example, a key vault has been naively created to store secrets securely in the cloud but has not been securely connected to your azure virtual network. With some simply applied policies we can ensure that all key vaults meet rules around virtual network compliance. While the defined steps are the same as the above, with a different set of rules.
Key Vault Policy Example
{
"properties": {
"displayName": "Audit Key Vault Missing VNET",
"mode": "Indexed",
"parameters": {},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.KeyVault/vaults"
},
{
"anyOf": [
{
"field": "Microsoft.KeyVault/vaults/networkAcls.virtualNetworkRules[*].id",
"exists": "false"
},
{
"field": "Microsoft.KeyVault/vaults/networkAcls.virtualNetworkRules[*].id",
"notLike": "*"
},
{
"field": "Microsoft.KeyVault/vaults/networkAcls.defaultAction",
"equals": "Allow"
}
]
}
]
},
"then": {
"effect": "audit"
}
}
}
}
Policies can be codified just like any other deployable artifact, we can even store our policies in source control allowing for discoverability and auditing, changes to policy can follow the same policies that code artifacts will follow and be deployed in much the same manner.
If you cannot answer yes to all the above questions download our Azure Governance Playbook today!