Shared Responsibility Model: IaaS, PaaS, and SaaS

The Foundation of Cloud Security

Before diving into the specifics of each service model, it's crucial to grasp the core concept. The shared responsibility model defines the division of security tasks between you (the customer) and Microsoft (the cloud provider). The core idea is that Microsoft is responsible for the security of the cloud, while you are responsible for security in the cloud. What "in the cloud" means, however, changes dramatically depending on the type of service you consume.

To build a strong foundational understanding, let's watch a video from John Savill. He provides an excellent overview of the different service categories and how the line of responsibility shifts as you move from on-premises to SaaS.

The Official Framework: IaaS, PaaS, and SaaS

John Savill's video gave us a great conceptual model. Now, let's look at how Microsoft formally documents these responsibilities. The division of labor is not just a guideline; it's a core part of the service agreement.

Visualizing the Divide

The responsibility matrix from the reading is often visualized to make it easier to understand. The general rule is this: as you move from IaaS to PaaS and then to SaaS, Microsoft takes on an increasing share of the management and security burden, but your fundamental responsibility for your data and access to it never disappears.

Let's break this down with concrete examples relevant to your architectural work.

1. Infrastructure as a Service (IaaS)

• Examples: Azure Virtual Machines, Azure Disk Storage, Virtual Networks.
• Analogy: Leasing an unfurnished apartment. You get the physical structure and utilities (the building, power, water), but you are responsible for everything inside: furniture, appliances, security system, and locking your door.
• Microsoft's Responsibility: The physical infrastructure—datacenters, servers, networking hardware, and the virtualization layer (hypervisor). Microsoft ensures a physical server is running and the network is available.
• Your Responsibility: This is the model that gives you the most control but also the most responsibility. You are responsible for almost everything inside the virtual machine:
  • Operating System: You choose the OS, and you are responsible for patching it, configuring it, and hardening it against attacks.
  • Network Controls: Configuring Network Security Groups (NSGs), Azure Firewall rules, and VNet segmentation.
  • Application & Runtimes: Installing, securing, and maintaining any software, runtimes (e.g., .NET, Java), and your application code.
  • Data: The data itself and database software (e.g., if you install SQL Server on a VM).

2. Platform as a Service (PaaS)

• Examples: Azure App Service, Azure SQL Database, Azure Functions, Azure Storage.
• Analogy: Leasing a furnished apartment. The landlord provides and maintains the furniture and major appliances (the OS, runtimes, database engine). You are responsible for your personal belongings (your code and data) and who you give a key to.
• Microsoft's Responsibility: Everything in IaaS, plus the operating systems, middleware, and runtimes. For Azure SQL, Microsoft handles OS patching, SQL Server engine updates, and high availability. For App Service, Microsoft manages the web servers and the language runtimes.
• Your Responsibility: Your focus shifts from managing infrastructure to managing your application and its configuration.
  • Application: Your code, its dependencies, and any security vulnerabilities within your code.
  • Configuration: Configuring the service itself. For Azure SQL, this means setting firewall rules and managing database users. For App Service, it's configuring custom domains, SSL, authentication settings, and scaling rules.
  • Identity and Access: Managing who and what (e.g., your application's managed identity) can access the service.

3. Software as a Service (SaaS)

• Examples: Microsoft 365, Dynamics 365, Salesforce.
• Analogy: Staying in a hotel. The hotel manages everything—the building, the room, the furniture, the cleaning, and the security of the premises. You are only responsible for your own luggage (your data) and your room key (your identity and access).
• Microsoft's Responsibility: Almost everything. Microsoft manages the entire stack, including the application itself. They are responsible for the infrastructure, the platform, and ensuring the application is running, patched, and available.
• Your Responsibility: This is the model with the least responsibility, but it is not zero. You are still responsible for:
  • Data: The information you put into the service.
  • Users and Access: Managing user accounts, assigning licenses, and configuring access policies (e.g., setting up multi-factor authentication).
  • Service Configuration: Configuring the security and sharing features available within the application.

The Inescapable Responsibilities

Across all service models, there are certain security responsibilities that always remain with you, the customer. A common mistake is to assume that moving to PaaS or SaaS absolves an organization of these duties. As an architect, you must ensure your designs account for them.

This is where services we've discussed in previous modules become critical. Your responsibility for Access management is fulfilled using Microsoft Entra ID with RBAC and Conditional Access. Your responsibility for securing your applications' access to data (a shared PaaS responsibility) is handled via Managed Identities and Azure Key Vault. The shared responsibility model doesn't just exist in a vacuum; it dictates the need for these other services.

An Architect's Dilemma: Control vs. Responsibility

Your experience building software makes the trade-offs here very tangible. Let's consider a common scenario: you need to deploy a PostgreSQL database.

• IaaS Approach: Deploy an Azure VM and install PostgreSQL yourself.

  • Pros: Maximum control. You can choose the exact version of PostgreSQL, install any extension you want, fine-tune OS-level performance parameters, and have root access.
  • Cons: You own the entire security stack above the hypervisor. You are responsible for OS patching, PostgreSQL security updates, configuring backups, setting up high availability, and managing OS-level firewall rules. This is a significant, ongoing operational burden.

• PaaS Approach: Use Azure Database for PostgreSQL (a managed service).

  • Pros: Reduced operational burden. Microsoft handles all the underlying infrastructure, OS, and database engine maintenance and patching. High availability, backups, and security are built-in features you configure, rather than build from scratch. Your team can focus on schema design and query optimization instead of database administration.
  • Cons: Less control. You cannot SSH into the server. The list of supported extensions is managed by Azure, and you can't install arbitrary ones. You are limited to the configuration options exposed by the service.

The decision between these two is a classic architectural trade-off. There is no single right answer. The IaaS approach might be necessary for a legacy application with specific, non-standard dependencies. The PaaS approach is almost always preferable for new development, as it frees up engineering resources to focus on business value rather than infrastructure management. A Principal Engineer must be able to weigh these factors and justify the chosen path based on risk, cost, and operational agility.

Conclusion

In this lesson, we dissected the shared responsibility model, moving from the conceptual level to its practical application in architectural design. Understanding this model is non-negotiable for operating securely and efficiently in Azure.

Key Takeaways:

• The shared responsibility model is a partnership. Microsoft secures the cloud, and you secure what you put in the cloud.
• The line of responsibility shifts significantly between IaaS, PaaS, and SaaS. As you move toward SaaS, Microsoft's responsibility increases, but yours never becomes zero.
• You are always responsible for your data, your endpoints (client devices), your accounts, and access management.
• The choice of a service model (e.g., VM vs. App Service) is a direct choice about which security and operational responsibilities you want to own versus delegate to Microsoft. This is a primary architectural decision.

In our next lesson, we will put this knowledge to use. We will evaluate a sample architecture against the Well-Architected Framework pillars and propose concrete improvements. Your understanding of the shared responsibility model will be crucial for assessing the security posture of that architecture and identifying areas of risk.