If you do a web search for “Azure Security” you can quickly go down a number of different paths. It is good that there are a number of resources, including a lot from Microsoft. However, it is not so good that sometimes it doesn’t give a specific-enough set of recommendations for one or more Azure services that you may be focused on for your application or deployment.
One way to address this is with the Azure Blueprints. These are a set of resources that can help you with industry-specific (including regulatory compliance) implementations. I found this resource very helpful, and it has the following reference architectures for Azure services:
- Data Analytics
- Data Warehouse
- Infrastructure as a Service
- Platform as a Service
I’m going to take a look at the Infrastructure as a Service offering as this aligns specifically to what I’m implementing. Additionally, there are resources around existing regulations, and I’m going to take the one around PCI-DSS (a financial services standard). For this Azure service, there are five key documents available on the PCI Blueprint page:
As I read the Azure Security and Compliance Blueprint for PCI-DSS IaaS WebApp Overview document (the last one), I felt very good as this aligns very well with what I have been advising on this site already. This includes the Azure Key Vault, using the Activity Log and having an organized approach in using resource groups per application and per deployment that is in-scope of PCI-DSS. The document shows this visual diagram of how an in-scope application should be deployed in Azure in the parent context of a resource group, shown below:
However probably the most valuable part of the Azure Blueprint is the requirement mapping. Again, based on my experience with PCI-DSS, this is gold. The documents in the Azure Blueprint will align to the specific PCI-DSS requirement and tell you where in Azure you need to go to configure to meet the requirement, this sheet is shown here:
In addition to PCI-DSS, there are blueprint documents for FedRAMP, UK OFFICIAL, NIST SP 800-171, AU-PROTECTED, FFIEC, HIPPA / HITRUST and UK NHS. I’m not an expect in those, but I do have experience with PCI-DSS, and if I were deploying a solution in Azure subject to an audit – I would want this as an implementation guideline.
Kudos to Microsoft here. This an outstanding set of resources for Azure-based services subject to an audit. Even if you are not subject to an audit, there are lots of good tips in these documents to harden your deployments. I will find these and write these up as subsequent blogs!
This also proves a point I’ve been saying *forever*. Any one particular technology is not inherently compliant or inherently non-compliant to any requirement. It’s how you implement it that makes the difference.
Trackbacks/Pingbacks