Shared Responsibility — Who Owns Each Layer
| Layer | On-Premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Physical / data center | Customer | Provider | Provider | Provider |
| Network infrastructure | Customer | Provider | Provider | Provider |
| Hypervisor / virtualization | Customer | Provider | Provider | Provider |
| Operating system | Customer | Customer | Provider | Provider |
| Runtime / middleware | Customer | Customer | Provider | Provider |
| Application | Customer | Customer | Customer | Provider |
| Data | Customer | Customer | Customer | Customer |
| Access management | Customer | Customer | Customer | Customer |
Bold rows are constant across all models — data and access management are always the customer's responsibility. No matter how much the provider manages, the customer owns who can access the data and what happens to it.
Cloud Deployment Model Comparison
Public Cloud
Shared infrastructure, multiple unrelated tenants. Provider manages all hardware. Broadest scalability, lowest cost. Multi-tenancy risk: logical isolation must be enforced by the provider. Examples: AWS, Azure, GCP.
Private Cloud
Dedicated to one organization. Can be on-premises (org-owned hardware) or hosted (provider hardware, org-exclusive). Maximum control and compliance fit. Higher cost. No multi-tenancy isolation concerns.
Community Cloud
Shared among organizations with common requirements (e.g., government agencies sharing FedRAMP infrastructure, healthcare orgs sharing HIPAA-compliant platform). Shared governance, shared trust relationship among members.
Hybrid Cloud
Combination of private + public (and/or community). Sensitive data on private; elastic workloads on public. Most operationally complex — requires secure interconnection, identity federation, and consistent policy enforcement across environments.
Hybrid Cloud Security Challenges
| Challenge | Root Cause | Mitigation |
|---|---|---|
| Inconsistent network protection | On-premises uses physical firewall rules; cloud uses virtual security groups — different systems, different syntax, different teams | Unified security policy document; explicit mapping of on-prem rules to cloud security group equivalents; periodic audit comparing both |
| Authentication management | On-premises AD and cloud IAM are separate systems with separate credentials by default | Identity federation (SAML/OIDC/OAuth) linking AD to cloud IAM; single sign-on; centralized MFA enforcement; automatic account disable propagation |
| Diverse monitoring systems | On-prem SIEM receives on-prem logs; cloud logs stored in provider's proprietary service (CloudTrail, Azure Monitor) in different formats | Cloud log export to SIEM; normalized log format; unified SOC visibility across both environments; cross-environment correlation rules |
| Data transfer risk | Data moving between private and public environments traverses public internet without dedicated connection | AWS Direct Connect / Azure ExpressRoute (dedicated private circuit); encryption of all data in transit; data classification policy limiting which data can traverse the boundary |
IaC Security — Benefits vs. Risks
Security Benefits
- Version control — every infrastructure change tracked and attributed
- Code review — security review before deployment, not after
- Consistency — dev/staging/production environments identical
- Configuration drift prevention — code wins over manual changes
- Repeatability — disaster recovery means running the template
- Audit trail — git history shows who changed what and when
Security Risks
- Secrets hardcoded in templates → exposed in version control
- Misconfigurations deploy at scale — one error affects every environment
- Compromised IaC repo = infrastructure control for the attacker
- Overly permissive IAM roles defined in templates
- Misconfigured security groups opened too broadly
- No IaC template scanning = misconfigurations reach production
Serverless Security Model — Customer Responsibilities
| Responsibility Area | Owner | Risk if Neglected |
|---|---|---|
| Physical hardware, hypervisor, OS, runtime, scaling | Provider | N/A — provider's problem |
| Function code security (injection, auth, logic) | Customer | Exploitable vulnerability in function code regardless of infrastructure security |
| IAM permissions on the function | Customer | Over-privileged function — attacker who exploits function inherits its permissions (may include full account access) |
| Input validation (event payloads) | Customer | Event injection — malicious trigger payload causes unintended function behavior |
| Secrets management (no hardcoding) | Customer | API keys/passwords in deployment package accessible to anyone who can view function code or logs |
| Third-party library security | Customer | Vulnerable dependency compromises function even if function code itself is secure |
Monolith vs. Microservices — Security Comparison
| Dimension | Monolith | Microservices |
|---|---|---|
| Breach impact | A breach in any component potentially exposes all functionality and data | A breach in one service is isolated — attacker must separately compromise each service they want to reach |
| Patching | Security fix requires full application deployment | Vulnerable service patched and redeployed independently |
| Credentials/permissions | All components typically share one credential set with broad permissions | Each service has its own credential with only the permissions it needs (least privilege per service) |
| Internal communication | In-process function calls — no network attack surface between components | Network API calls between services — each call is an attack surface requiring authentication, authorization, and input validation |
| Attack surface | Single application with one entry point | Many services with many API endpoints — larger attack surface requiring consistent API security across all |
| Failure isolation | One component crashing can take down the entire application | Failure in one service does not cascade (if designed for resilience) |
Vendor Risk Assessment Lifecycle
PHASE 1 · PRE-CONTRACT
SOC 2 Type II report review; ISO 27001 certification; penetration test results; vulnerability disclosure policy; data handling practices; sub-processor chain
PHASE 2 · CONTRACT
SLA commitments; breach notification timeline (must meet regulatory minimums — GDPR: 72h); right-to-audit clause; data residency requirements; data deletion on termination; liability terms
PHASE 3 · ONGOING
Annual re-assessment; monitoring for announced vendor incidents; tracking certification renewals; reviewing access scope changes; SIEM alerts for anomalous vendor activity
PHASE 4 · INCIDENT
Vendor escalation contacts in IR plan; defined responsibility split when vendor is the source; tabletop exercises including vendor scenarios; communication plan for customer data breach via vendor