West Monroe Partners recently completed a nine-month effort to help a client migrate a large custom SaaS platform with regulatory requirements (PCI DSS v3.1, SSAE16). The engagement involved migrating on-premises systems to Microsoft Azure’s IaaS platform, and in the coming weeks, we’ll be detailing our methodology for designing and securing that environment in a series of blog posts. The architecture we developed and considerations we made can be extended to any industry that wants to explore what it will take to migrate to the cloud while keeping security a priority. The topics you can look forward to reading more about are:
- How To Talk To The Cloud
- How and why we architected our networks the way we did
- Securing Cloud Networks
- How we secured and controlled traffic flow in Azure with PCI DSS at top of mind
- Encrypting Data at Rest in Azure
- How we implemented BitLocker for Azure VMs
- Transparent Database Encryption with the Azure Key Vault
- How we leveraged the Azure key vault to manage database encryption keys
- Implementing Certificate Authorities in Azure
- How to keep Microsoft’s Auto Delete from deleting your offline root CA
- Cloud Proxy Requirements
- How to proxy traffic in and out of a PCI DSS compliant environment
- Managing Administrative Access to an Azure-based PCI Environment
- How enabling MFA and using Remote Desktop Gateways helped meet PCI DSS requirements
- Backing Up To the Cloud From the Cloud
- How to use native Azure tools to backup new objects using the old model
It’s important to note that although we architected for PCI DSS version 3.1, version 3.2 has been recently released. For more information on the key changes between 3.1 and 3.2, click here. That post is the first in a series of PCI-related topics that correlate to many of the areas listed above, so look for cross references between the blog series in future posts.
Before designing and building the new environment, we had to give consideration to licensing and subscription models for Azure.
Azure Licensing and Subscriptions
For Enterprise Agreement customers, Microsoft will grant percentage discounts on Azure object costs based on the amount of money you’re willing to spend in Azure on a yearly basis, called your “Azure commit”. Here, the delicate balance is how to get the highest discount on services by setting your commit as high as possible, while not leaving money on the table by failing to use the entire commit. Some important notes on how Azure commit is used:
- Azure commit can be used throughout the entire year – it’s not a monthly spend. You can spend it all on day 1, save it until day 365, or spend it spread across the entire year.
- Spend across all of enterprise subscriptions is billed against the Azure commit. Notably, some Azure Marketplace spend does not bill against the commit, and is invoiced separately.
- The level of Azure commit can be adjusted each year. So if you undercommit or overcommit, you can adjust the commit appropriately to gain more discount or eliminate lost money in the next year.
- If you exceed your Azure commit in a given year, the same discount level is applied to subsequent spend, but you are invoiced separately for that spend.
The approach we took when calculating a commit amount was to get a full inventory of systems from the source environment and translate those systems to Azure objects. We then used Microsoft’s Azure pricing calculator to determine approximately what we expected to spend based on the number and size of VMs provisioned, how much standard storage we required, how much premium storage we allocated, how much network traffic we expected, etc. This became our “base spend”. From there we tweaked a few line items to increase cores, RAM, storage performance and so on, in anticipation of some changes to the environment that our client wanted to make. We intentionally did not account for some possible future needs that weren’t certainties. Even though this meant our discount wasn’t as high as it might have been, it avoided leaving unspent commit if those needs didn’t materialize.
With our Azure commit number in hand, the next step was identifying how to organize our Azure environment into subscriptions to meet regulatory obligations, while also keeping ease of management in mind. Since our client needed to comply with PCI DSS, the cardholder data environment (CDE) needed to essentially be air-gaped from the other environments, and theoretically the rest of the world. Standing up different subscriptions for our “Internal IT”, “Development”, and the CDE allowed us to create “islands” of resources that could still interact if the design dictated, but via tightly controlled Azure-to-Azure VPNs and network security groups.
In the coming weeks, we’ll cover not only how we segmented our environment to achieve PCI DSS compliance, but also how we implemented data encryption, certificate services, and backups in the Azure environment. Be sure to check back for more detail!