Moving an application to Azure does not move every security decision with it. The shared responsibility model shows where Azure’s responsibility ends and yours begins. That boundary changes with the hosting option: infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS). It concerns seven areas of responsibility—not the seven layers of defense in depth. section 6.2
The more Azure manages, the fewer security tasks remain on your side—but fewer does not mean none:
- IaaS: A virtual machine leaves you responsible for security work that Azure handles for a comparable platform-managed web service. section 6.2.3
- PaaS: Azure manages much of the service security, while you can still configure settings such as public internet access. Identity is shared: you configure identities, the identity provider, and monitoring and logging; Azure provides services such as Entra ID. section 6.2.3
- SaaS: Azure takes on most security responsibility, but you still manage application users. Responsibility for client devices and endpoints is also shared; Azure’s tools do not control what users do. section 6.2.4
A web service or a virtual machine?
Suppose you need to host a web service. On an Azure-managed platform, Azure configures much of the service security, though you still decide whether to allow public internet access. Put the service on a virtual machine instead, and that security work falls to you. The model helps make that trade-off visible before deployment. section 6.2.3
Figure 6.4 The shared responsibility for security and integrity between you and Azure
Compare how the responsibility split changes across the three hosting options and seven areas. section 6.2
Use the model to identify the areas your team must secure, rather than assuming Azure covers everything. Azure’s dedicated security resources can free your team to focus on those remaining responsibilities. section 6.2.6 section 6.9
