This post was originally written for
Trend Micro .With any public cloud, security is a shared responsibility between the cloud service provider and you, the user of those services. For IaaS offerings, this usually means the division of responsibilities is as follows:
| Cloud Service Provider | You |
|---|---|
| Facilities | Operating System |
| Physical security | Applications |
| Network infrastructure | Data |
| Virtualization layer |
If you’ve done work in the AWS Cloud, this model is probably already familiar to you. AWS has worked hard to popularize this model for the community, and other providers (and partners like Trend Micro) can now take advantage of those education efforts to help raise the bar for everyone in the public cloud.
The key to success under the shared responsibility model is to ensure that you verify the provider’s work and then focus your efforts on securing your areas of responsibility.
Microsoft’s responsibility
Microsoft has established a central clearing house for security in Azure. The Microsoft Azure Trust Center is a fantastic place to start your efforts to verify how Microsoft is fulfilling their responsibilities for security .
The first step is to download and read, “ Security, Privacy, and Compliance in Windows Azure .” This white paper explains their approach to security, current efforts, and their ongoing commitment to continuously improving the security of Azure.
The Trust Center page dedicated to compliance highlights and validates the various third-party certifications that Microsoft has received or is in the application process for. This is a key factor to take into account when verifying your cloud service provider’s security efforts.
Compliance with third-party frameworks like SOC 1 & 2 Type 2 and FedRAMP shows not only a commitment to security, but also one to transparency. Both key aspects in a partner… and that’s exactly how you need to view your relationship with your cloud service provider.
Your responsibilities
Now that you have a good idea of how Microsoft is meeting its security responsibilities, it’s time to look at the best approach to meet yours.
The biggest shift when moving to the public cloud is the loss of boundary controls that you rely on in your data center. You no longer have the luxury of a large firewall and intrusion prevention system sitting on your inbound and outbound links sanitizing all of the traffic.
Similarly, gateway style products tend to fall down quickly due to scaling and configuration challenges in cloud environments.
Just because we lose the controls on the boundary, it doesn’t mean we should simply accept this and move on. It’s always a good practice to implement the SANS Top 20 security controls , and we can’t accept failure to implement #13 (Boundary Defense) and #18 (Secure Network Engineering) right off the bat.
You should be investigating moving controls that used to exist on the boundary to the virtual machine level. This means deploying intrusion prevention systems directly on your Azure VMs.
Similarly, you should be deploying VMs in an Azure Virtual Network . Despite the initial overview, a Virtual Network can be deployed cloud-only and provides more control over the lower layers of your deployment’s configuration.
Just the start
You should now have a better idea of the security model in Azure and your role within it. Armed with this knowledge, you can now start to integrate security into your deployments and ensure that you deliver a high level of security for all of your Azure workloads. What other questions on security in Azure do you have? Let me know in the comments or reach out on Twitter, where I’m @marknca .
