If you’re approaching this from the 7-layer ISO/Open Systems Interconnect model perspective, just draw a circle around the entire stack. For a more vivid image, imagine you’re building a house and you have to paint every brick with security paint before you lay it. Each and every brick. Some more, some less, but they all get security painted on them.
The first thing you’ll need to do, as you always have, is to assess the environment you’re transitioning to Azure. Here are five areas of focus to keep in mind.
In the end, it’s all about the data, so you need to assess each data asset separately. How much is each asset worth? You don’t want to end up spending more to protect certain workloads than they are actually worth. This is how you determine how much paint each brick gets. Additionally, consider where the data will be used most. From a design standpoint, you want to put the data as close to the operation as you can. Also remember to allow for scalability. In your on-prem world, the expansion of data storage resources requires a major installation event during which adjustments will be made manually. In the cloud, most everything is elastic, so your environment needs to anticipate that capacities will fluctuate upward and downward frequently.
Since you’ll be creating policies for each subscription and each resource group you use, it’s vital that you map this out carefully, observing each of the security recommendations related to the Azure Security Center. You’ll also want to develop policies for each user, each user group, and each device type that will be accessing Azure resources. You’ll soon realize that people are the most unpredictable and therefore the most difficult segment of your network to manage, a conclusion also supported in a recent cloud migration report from BitTitan and Osterman research. You’ll be able to use the Microsoft Monitoring Agent to collect security information about each of your virtual machines. Be sure to organize your workspaces and resource groups to take maximum advantage of the data to be found in those logs.
Develop a plan and clear owners in anticipation of anomalies in your infrastructure or situations that require swift and transparent responses. Who will be notified? How will they be notified? How will the actioning of each notification be recorded and closed when done? What constitutes a Level 1, 2, or 3 priority alert? What are your service level agreements (SLA) for response and resolution at each level? How will events be escalated if necessary? Oftentimes it’s the response to the situation, not the situation itself, that determines the full extent of the damage.
Azure uses Role-Based Access Control, which has built-in roles which can be assigned to users, groups, and services in Azure. The size of your organization may or may not make it impractical to establish specific access rights and resource accessibility for each individual user. Groups make it far easier to scale. When using the Azure Security Center, each user or group may be designated as an Owner, a Contributor, or just a Reader.