Unit
- Model overview: The shared responsibility model defines which security tasks are handled by the cloud provider and which remain with the customer. Providers like AWS, Azure, and Google Cloud secure the infrastructure, while customers protect their data, configurations, and access policies.
- Infrastructure layer: The provider secures physical data centers, networking hardware, and hypervisors. This includes environmental controls, hardware maintenance, and network segmentation at the facility level.
- Customer responsibilities: Customers manage identity and access management, encryption of data, network traffic controls, and operating system patches for virtual machines. Misconfigurations here are a leading cause of breaches.
- Service model variations: Responsibility shifts depending on whether you use IaaS, PaaS, or SaaS. For example, in PaaS the provider patches the runtime, but the customer must secure application code and credentials.
- Contractual boundaries: Service Level Agreements (SLAs) define provider guarantees for uptime and security. Customers should review SLAs to understand liability and notification procedures for incidents.
- Compliance implications: Shared responsibility affects audit scope. Customers must ensure their controls align with standards like ISO 27001 or SOC 2, which often require evidence of customer-side protections.
- Real-world application: A typical breach occurs when a storage bucket is left publicly accessible due to misconfigured permissions. The provider infrastructure is secure, but the customer failed to enforce access controls.
- Best practice: Use tools like AWS Config or Azure Policy to continuously audit configurations against security baselines. This automates detection of responsibility boundary violations.
- Identity federation: The customer must manage identity federation and single sign-on integration with the provider's IAM. This includes configuring trust relationships and ensuring that external identity sources meet security requirements for authentication and authorization.
- Incident response handoff: When a security incident occurs, the provider handles infrastructure level events, but the customer is responsible for notifying affected users and investigating application level breaches. Clear communication channels and predefined escalation paths are essential.
- Data residency and sovereignty: Customers must choose cloud regions that comply with data location regulations. The provider offers regional data centers, but the customer configures storage and services to enforce geographic boundaries and prevent cross border data movement.
- Automated compliance monitoring: Tools like AWS Security Hub and Azure Security Center aggregate findings across services and provide compliance scores. Customers should enable these services to continuously track alignment with frameworks such as CIS benchmarks and NIST.
Security Consideration
HIGH RISK
Vulnerability: Misconfigured S3 bucket leading to data exposure.
Mitigation: Enforce bucket policies with least privilege, enable block public access by default, and use AWS Config rules to monitor changes.
Reference: OWASP Cloud Security Top 10, CWE-325
Quick Revision
- The shared responsibility model clearly delineates provider vs. customer security obligations.
- Customers are responsible for data, identity, configurations, and application security.
- Service model type (IaaS, PaaS, SaaS) shifts the boundary of responsibilities.
- Continuous auditing of configurations is essential to prevent misconfiguration incidents.