Security Architecture · Topic 9 of 12
Cloud Security Design
Secure enterprise cloud use with shared responsibility, CASB, CSPM, identity federation, key control, containers, serverless and infrastructure as code.
- 6 min
- Includes a diagram
- Shared responsibility: the customer always owns data, identities and access configuration.
- IaaS gives the most customer responsibility, SaaS the least.
- Misconfiguration is a leading cloud risk, and CSPM detects it.
What it is
Cloud computing lets an organization rent infrastructure, platforms or software instead of owning them. Security does not disappear. It is shared, and many cloud incidents come from customer side misconfiguration rather than from a provider failure.
An architect decides which cloud model fits, where responsibility lies, and which controls bring cloud use under the same policy as on premises systems.
How it works
Service and deployment models
| Model | You manage | Provider manages |
|---|---|---|
| Infrastructure as a service (IaaS) | Operating system, applications, data, network rules | Hardware, virtualization, facilities |
| Platform as a service (PaaS) | Applications, data, access | Operating system, runtime, platform |
| Software as a service (SaaS) | Data, users, configuration | Almost everything else |
The customer is always responsible for its data, identities and access, whatever the model. As you move from IaaS to SaaS, the provider takes on more of the stack, but the customer's duty for configuration and users remains.
Deployment can be public, private, hybrid (a mix tied together) or multicloud (more than one provider). Multicloud reduces lock in and dependency on one provider, but adds skills, tooling and policy consistency work.
Identity and access
Federate the corporate identity provider to cloud services, so one lifecycle and multi factor authentication (MFA) policy cover them. Use roles with short lived credentials in place of long lived access keys.
Apply least privilege to both users and workloads. Protect the root or owner account of every cloud tenant with strong MFA and almost no daily use.
Visibility and posture tools
| Tool | Purpose |
|---|---|
| Cloud access security broker (CASB) | Sits between users and cloud services to enforce policy, find shadow IT, apply data loss prevention (DLP) and detect risky behavior. Works inline as a proxy or through provider APIs |
| Cloud security posture management (CSPM) | Continuously checks cloud configuration against best practice and compliance rules and flags misconfigurations |
| Cloud workload protection | Protects workloads such as virtual machines and containers at runtime |
| Cloud native logging | Records control plane and data plane events for monitoring |
CASB answers who uses which service and with what data. CSPM answers whether the cloud is configured safely. Use both, since they see different things.
Network and data controls
Use virtual networks with segmentation, security groups and private endpoints so services are not exposed to the internet by default. Control egress to limit data exfiltration. Encrypt data at rest and in transit, and choose who holds the keys: the provider, the customer in a managed key service, or the customer in its own hardware module, depending on trust and compliance.
Data residency requirements affect region choice. Backups and replicas must follow the same rules.
Connecting customers and systems to the cloud
| Option | How it works | Security trade off |
|---|---|---|
| Site to site IPsec VPN | Encrypted tunnel between your network and the cloud network over the internet | Quick and cheap, but depends on internet quality |
| Dedicated private link (Direct Connect or ExpressRoute style) | Private circuit from your site to the provider | Predictable and off the public internet, but not encrypted automatically, so add encryption where required |
| Client VPN | Individual users or devices connect into the cloud network | Needs strong authentication and device checks, and gives broad network access if not restricted |
| Private endpoint | Gives a cloud service a private address inside your virtual network | Keeps traffic off the internet, and works with access policies on the service |
Redundant paths avoid a single point of failure. Even on private links, apply segmentation and least privilege, because "private" does not mean trusted.
Containers and serverless
Containers package applications with dependencies. Secure them by scanning images, using minimal trusted base images, avoiding running as root, limiting container privileges, and controlling secrets and network paths in the orchestrator. Orchestrator role based access and application programming interface (API) protection are as important as the containers themselves.
In serverless functions the provider runs the platform, so the customer focuses on code, permissions and event inputs. Give each function its own narrow role, validate every event input, and keep dependencies updated.
Infrastructure as code
Infrastructure as code (IaC) defines cloud resources in text files that are version controlled and deployed automatically. Scan templates before deployment, review changes, and prevent manual changes that cause drift from the approved state. Done well, IaC makes secure configuration repeatable.
Cloud API security
Everything in the cloud is controlled through APIs. Protect them with authentication, authorization, rate limiting and logging, and place an API gateway in front of your own services.
Cloud service integration
Software as a service tools and on premises systems are often connected to each other, and each connection is a trust relationship that an attacker can abuse.
- OAuth app consent: users can grant a third party app access to their data. Limit who may consent, require admin approval for broad scopes, and review granted permissions.
- API keys: long lived secrets, so scope them narrowly, store them in a vault and rotate them.
- Service principals and workload identities: non human accounts used by integrations. Give each one least privilege and an owner, and prefer short lived credentials.
- Webhooks and events: verify that the sender is genuine, for example through signed payloads, and validate the content before acting on it.
Keep an inventory of integrations and review it on a schedule. Remove unused connections and revoke access when a vendor relationship ends.
What to remember for the exam
- Shared responsibility: the customer always owns data, identities and access configuration.
- IaaS gives the most customer responsibility, SaaS the least.
- Misconfiguration is a leading cloud risk, and CSPM detects it.
- CASB enforces policy on cloud use and can work inline or through APIs.
- Federate identity and use roles with short lived credentials in place of long lived keys.
- Key control choices range from provider managed to customer managed hardware.
- Scan IaC templates and container images before deployment.
- Multicloud reduces lock in but increases complexity.
If a scenario describes a publicly exposed storage bucket, the root cause is configuration, and the fix is policy plus continuous posture checks.
Common mistakes
Assuming the provider secures everything. Even in SaaS the customer must manage users, sharing settings and data.
Mixing up CASB and CSPM. CASB governs user and data activity with cloud services. CSPM audits resource configuration.
Using long lived access keys in code. Keys leak through repositories, so use roles and short lived tokens.
Ignoring the control plane. Admin consoles and APIs can change everything, so protect and log them.
Exposing a management interface or storage service to the internet by default is a design failure, not an accident to fix later.
Check yourself
Work through these three questions.
Who is always responsible for data and identity configuration in the cloud?
The customer, in every service model.
What does CSPM do that a CASB does not?
It continuously checks cloud resource configuration against best practice and compliance rules to find misconfigurations.
Why scan infrastructure as code templates?
Insecure settings can be caught and fixed before deployment, and every deployment from the template stays consistent.
Topic 9 of 12 in Security Architecture
Test yourself on Security Architecture
The full CompTIA SecurityX CAS-005 question bank has 654 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.