Cloud Security Explained: Complete Guide to Securing Cloud Infrastructure, Data, Identity and Applications
Introduction: What Is Cloud Security?
Cloud security is the collection of technologies, architectures, policies, processes and security controls used to protect cloud-based infrastructure, applications, identities, networks and data.
Unlike traditional data-center security, cloud security operates in an environment where infrastructure can be created programmatically, resources can scale dynamically, users can connect from many locations, workloads can move between environments, and application components may communicate through APIs rather than traditional internal networks.
That changes the security model.
A company migrating an application to AWS, Microsoft Azure or Google Cloud does not simply move its existing firewall rules into the cloud and become secure. Cloud environments introduce new security responsibilities involving identity and access management, cloud networking, API security, encryption, secrets management, workload protection, storage security, container security, logging, monitoring, configuration management and incident response.
NIST’s Guidelines on Security and Privacy in Public Cloud Computing explains the security and privacy considerations organizations should address when moving data, applications and infrastructure into public cloud environments.
For readers who are still building their cloud fundamentals, CorgiNetwork’s Cloud Computing Explained provides the broader foundation before moving into cloud security architecture.
This is why cloud security should be treated as an architecture problem, not simply a product or firewall problem.
Cloud Security vs Traditional IT Security
Traditional infrastructure commonly assumes that an organization controls:
- Physical servers
- Data-center networks
- Storage
- Firewalls
- Operating systems
- Identity systems
- Internal network boundaries
Cloud environments introduce a different model.
A simplified traditional architecture might look like:
Internet
|
Firewall
|
DMZ
|
Internal Network
|
Servers
|
Database
A modern cloud architecture may look more like:
Internet
|
Edge / CDN / WAF
|
Load Balancer
|
-------------------
| |
Web Tier API Tier
| |
-----------+-------
|
Service Layer
|
----------------------
| |
Database Object Storage
|
Backup / DR
At the same time, administrators, developers, applications and automation systems may access these resources through APIs.
The security perimeter therefore becomes distributed across identity, applications, APIs, workloads, networks and data.
This is one reason cloud security works closely with the principles discussed in CorgiNetwork’s Zero Trust Security architecture.
NIST’s Zero Trust Architecture describes a model that moves security away from implicit trust based on network location and toward explicit authentication and authorization of users, devices and resources.
The Shared Responsibility Model
One of the most important concepts in cloud security is the shared responsibility model.
Cloud providers secure the infrastructure they operate, while customers remain responsible for security controls associated with their particular cloud services and configurations.
The exact division depends on the service model.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical infrastructure | Provider | Provider | Provider |
| Data center | Provider | Provider | Provider |
| Hardware | Provider | Provider | Provider |
| Virtualization | Provider | Provider | Provider |
| Operating system | Customer | Usually provider | Provider |
| Applications | Customer | Customer | Provider/service owner |
| Data | Customer | Customer | Customer |
| Identity | Customer | Customer | Customer |
| Configuration | Customer | Customer | Customer |
If you need to understand the differences between these service models first, see CorgiNetwork’s IaaS vs PaaS vs SaaS Explained.
The critical lesson is simple:
Moving a workload to the cloud does not automatically transfer responsibility for securing the workload.
NIST also emphasizes that accountability for security and privacy cannot simply be delegated to a cloud provider. Its public-cloud security guidance discusses the risks and safeguards organizations should consider.
The Core Layers of Cloud Security
A mature cloud security architecture can be divided into several layers:
+--------------------------------------+
| Governance & Compliance |
+--------------------------------------+
| Identity & Access Management |
+--------------------------------------+
| Application & API Security |
+--------------------------------------+
| Workload & Container Security |
+--------------------------------------+
| Network Security |
+--------------------------------------+
| Data & Storage Security |
+--------------------------------------+
| Logging, Monitoring & Detection |
+--------------------------------------+
| Infrastructure & Configuration |
+--------------------------------------+
| Backup, Recovery & Incident Response |
+--------------------------------------+
Security failures often occur when organizations protect one layer while neglecting another.
For example:
- A secure network cannot compensate for stolen administrator credentials.
- Strong IAM cannot protect an accidentally public storage bucket by itself.
- Encryption cannot prevent an authorized compromised application from accessing plaintext data.
- A firewall cannot fix vulnerable application code.
- EDR cannot compensate for missing cloud audit logs.
Cloud security therefore requires defense in depth.
1. Cloud Identity and Access Management
Identity is one of the most important security boundaries in cloud environments.
Instead of asking only:
“Which network can reach this server?”
Modern cloud security must also ask:
“Who or what is requesting access, from where, under which conditions, and to which resource?”
Cloud identities can include:
- Human users
- Administrators
- Developers
- Service accounts
- Virtual machines
- Containers
- Serverless functions
- CI/CD pipelines
- Applications
- APIs
- Automation systems
The CISA Identity and Access Management Recommended Best Practices specifically includes both human and service/system identities and emphasizes inventorying, auditing and tracking their access.
Principle of Least Privilege
Every identity should receive only the permissions required to perform its function.
For example, an application that only needs to read objects from one storage location should not receive:
Administrator
access.
A more appropriate permission model could be:
Application
|
+-- Read
|
+-- bucket/application-data
rather than:
Application
|
+-- Full Cloud Administrator
AWS documents the same principle in its official IAM security best practices, including least privilege, MFA, temporary credentials and regular removal of unused permissions.
2. Multi-Factor Authentication
Passwords alone are insufficient for protecting highly privileged cloud accounts.
Administrative identities should use strong multi-factor authentication, preferably phishing-resistant authentication where supported.
A basic authentication architecture can be represented as:
User
|
| Password / Primary Credential
v
Identity Provider
|
| MFA / Strong Authentication
v
Authorization
|
v
Cloud Resource
MFA does not replace authorization.
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to do?
For AWS environments, the official AWS IAM security guidance recommends MFA and temporary credentials as part of a stronger identity architecture.
3. Privileged Access Management
Cloud administrators can potentially control:
- Networks
- Databases
- Storage
- Encryption keys
- Virtual machines
- Kubernetes clusters
- IAM policies
- Logging
- Security controls
A compromised privileged identity can therefore have a much larger impact than an ordinary user account.
A mature architecture should minimize permanent administrative privileges.
Useful controls include:
- Just-in-time access
- Role-based access control
- Short-lived credentials
- Privileged access workflows
- MFA
- Administrative session logging
- Regular entitlement reviews
- Separation of duties
The AWS least-privilege guidance similarly recommends limiting permissions to the smallest set required and reviewing permissions regularly.
4. Cloud Network Security
Cloud networking is the foundation on which many workloads operate.
Before implementing cloud security controls, it is useful to understand VPCs, subnets, route tables, NAT, firewalls and load balancers. CorgiNetwork’s Cloud Networking Explained covers these concepts in depth.
A secure cloud architecture normally separates workloads according to their exposure and function.
For example:
Internet
|
Firewall
|
Load Balancer
|
Public Subnet
|
-----------------
| |
Web 01 Web 02
| |
------+---------
|
Private Subnet
|
Application Tier
|
Private Database
Databases should generally not be directly exposed to the public Internet merely because an application needs to access them.
5. Network Segmentation
Segmentation limits the ability of an attacker to move through an environment after gaining initial access.
A production environment might use:
Internet
|
Edge
|
Web Zone
|
Application Zone
|
Data Zone
Each zone can apply different controls.
| Zone | Typical Exposure |
|---|---|
| Edge | Internet-facing |
| Web | Restricted public application traffic |
| Application | Private |
| Database | Highly restricted |
| Management | Administrative access only |
For the broader networking principles behind segmentation, routing and traffic control, see CorgiNetwork’s Computer Networking Explained and TCP/IP Explained.
Zero Trust can extend this model beyond traditional network segmentation by incorporating identity and resource-level authorization. NIST’s SP 800-207 Zero Trust Architecture explains this shift toward protecting resources rather than relying on network location alone.
6. Security Groups, ACLs and Firewalls
Cloud platforms commonly provide multiple network-control mechanisms:
- Security groups
- Network ACLs
- Cloud-native firewalls
- Web application firewalls
- Network virtual appliances
- Host firewalls
The correct architecture depends on the cloud provider and workload.
A useful principle is:
Allow only:
Source
+
Destination
+
Protocol
+
Port
+
Required Direction
For example:
Internet
|
HTTPS :443
|
Load Balancer
|
TCP :8080
|
Application
while direct Internet access to the database remains blocked.
These principles complement the concepts explained in CorgiNetwork’s Firewalls Explained guide.
7. Cloud Data Security
Data is one of the primary assets that cloud security must protect.
Important controls include:
- Encryption at rest
- Encryption in transit
- Key management
- Access control
- Data classification
- Backup
- Retention policies
- Data-loss prevention
- Audit logging
- Secure deletion
A basic model is:
Application
|
| TLS
v
Cloud Service
|
| Encryption at Rest
v
Storage
|
+---- Encryption Key
Encryption is particularly important when sensitive information is stored in:
- Databases
- Object storage
- Backups
- Snapshots
- Logs
- Data warehouses
However, encryption alone is not sufficient.
If an attacker obtains valid authorization to access decrypted data through an application, encryption at rest may not prevent that access.
Therefore:
Encryption + IAM + monitoring + application security is stronger than encryption alone.
8. Cloud Key Management
Encryption depends on keys.
Key-management systems must therefore be protected carefully.
Security controls can include:
- Key rotation
- Access policies
- Separation of duties
- Hardware-backed key protection where appropriate
- Audit logs
- Restricted administrative access
- Key lifecycle management
A key should not be treated like an ordinary application password.
For sensitive environments:
Application
|
v
Identity / Authorization
|
v
Key Management Service
|
v
Encrypted Data
NIST maintains a dedicated Cloud Computing Security and Privacy publications collection covering cloud access control, secure microservices and related security topics.
9. Secrets Management
Cloud applications frequently require secrets such as:
Database passwords
API keys
Private keys
OAuth credentials
Service tokens
Encryption credentials
These secrets should not be hard-coded into application source code.
Bad:
DATABASE_PASSWORD = "MySuperSecretPassword"
Better:
Application
|
v
Secrets Manager
|
v
Database Credential
The application receives the secret only when authorized.
Secrets should also be:
- Rotated
- Audited
- Scoped
- Revoked when unnecessary
- Protected from source-control repositories
- Removed from logs
This becomes particularly important when cloud infrastructure is managed through automation and CI/CD pipelines.
10. Cloud Workload Security
Cloud workloads can include:
- Virtual machines
- Containers
- Kubernetes workloads
- Serverless functions
- Managed databases
- APIs
- Background workers
Every workload has an attack surface.
For virtual machines, security includes:
- OS patching
- Host firewall
- SSH/RDP protection
- Endpoint protection
- Least privilege
- Vulnerability management
- Logging
CorgiNetwork’s Linux Server Administration guide provides a deeper foundation for securing and administering Linux-based server workloads.
For filesystem-level permissions, the Linux File System Explained article is also relevant when hardening Linux cloud servers.
11. Container and Kubernetes Security
Containers change how workloads are deployed but do not eliminate security responsibilities.
Security should cover:
Image security
Scan images for:
- Known vulnerabilities
- Malicious packages
- Unnecessary software
- Secrets
- Outdated dependencies
Runtime security
Monitor:
- Unexpected processes
- Privilege escalation
- Network connections
- File-system changes
- Container escape indicators
Kubernetes security
Protect:
- API server
- RBAC
- Service accounts
- Secrets
- Network policies
- Admission controls
- Nodes
- Container images
A Kubernetes cluster should not be treated as a single trusted network.
12. API Security
Cloud infrastructure is heavily API-driven.
Automation systems can create and modify:
- Servers
- Networks
- IAM policies
- Storage
- Databases
- DNS records
- Security controls
This creates enormous flexibility but also creates a large attack surface.
An API request should be evaluated through:
Identity
|
Authentication
|
Authorization
|
Input Validation
|
Rate Limiting
|
Logging
|
Resource Access
Compromising a highly privileged API credential can be equivalent to compromising the administrator console.
13. Cloud Configuration Security
Misconfiguration is one of the most common categories of cloud security problems.
Examples include:
- Public storage
- Open administrative ports
- Excessive IAM permissions
- Disabled logging
- Weak security groups
- Unencrypted databases
- Exposed management interfaces
- Publicly accessible snapshots
- Long-lived access keys
A configuration review should ask:
Is the resource exposed?
|
v
Who can access it?
|
v
What permissions exist?
|
v
Is the access necessary?
|
v
Is the activity logged?
|
v
Can the configuration be continuously monitored?
Cloud security should therefore be integrated into infrastructure provisioning rather than performed only after deployment.
14. Infrastructure as Code Security
Infrastructure as Code allows infrastructure to be defined using configuration files.
Conceptually:
Git
|
v
Infrastructure Code
|
v
Security Validation
|
v
CI/CD
|
v
Cloud
Security checks can identify:
- Public resources
- Excessive IAM privileges
- Insecure network rules
- Missing encryption
This creates an important shift:
Security becomes part of deployment rather than a final manual inspection.
15. Cloud Security Monitoring
A secure cloud environment needs visibility.
Important telemetry can include:
- Authentication events
- Authorization failures
- Administrative operations
- Network flows
- API activity
- DNS activity
- Application logs
- Database events
- Endpoint telemetry
- Configuration changes
A simplified monitoring architecture:
Cloud Resources
|
+---- IAM Logs
|
+---- API Logs
|
+---- Network Logs
|
+---- Application Logs
|
+---- Security Events
|
v
SIEM
|
v
Detection / Alerting
|
v
Incident Response
CorgiNetwork’s SIEM Explained article provides a deeper explanation of centralized security monitoring and event correlation.
For broader intrusion detection concepts, see Intrusion Detection and Prevention Systems.
16. Cloud Detection and Incident Response
Cloud security monitoring is useful only if the organization can respond to detected threats.
A cloud incident may involve:
- Suspicious authentication
- Credential compromise
- Privilege escalation
- Unauthorized API activity
- Data access
- Persistence
- Lateral movement
- Data exfiltration
A response workflow can be:
Detection
|
Validation
|
Containment
|
Credential Revocation
|
Eradication
|
Recovery
|
Investigation
|
Lessons Learned
Because cloud infrastructure is highly programmable, containment can sometimes involve:
- Revoking credentials
- Disabling accounts
- Removing malicious IAM policies
- Isolating workloads
- Blocking network paths
- Rotating secrets
- Restoring infrastructure from trusted definitions
Organizations building an end-to-end security architecture can connect this workflow with CorgiNetwork’s Network Security Basics and Cybersecurity for Beginners resources.
17. Cloud Identity Threats
Identity has become a major security boundary in cloud environments.
Potential threats include:
- Credential theft
- Token theft
- Session hijacking
- Privilege escalation
- OAuth abuse
- Service-account compromise
- API-key leakage
- Forged authentication tokens
The CISA Identity and Access Management Recommended Best Practices emphasizes managing service and system identities as well as human identities.
This is particularly important because modern cloud environments may contain thousands of non-human identities.
A strong identity architecture therefore requires:
Strong Authentication
+
Least Privilege
+
Short-Lived Credentials
+
MFA
+
Continuous Monitoring
+
Rapid Revocation
18. Zero Trust and Cloud Security
Cloud security and Zero Trust complement each other.
Traditional architecture often assumes:
Inside = Trusted
Outside = Untrusted
Zero Trust instead evaluates access according to identity, device, resource, context and policy.
A simplified model:
User
|
Identity Verification
|
Device / Context
|
Policy Evaluation
|
Least Privilege
|
Resource
|
Continuous Monitoring
NIST’s official Zero Trust Architecture explains that Zero Trust removes implicit trust based solely on network location.
This architecture is particularly relevant to cloud environments because cloud resources may exist outside an organization’s traditional network perimeter.
CorgiNetwork’s Zero Trust Security guide expands on identity-based access control, continuous verification, least privilege and network segmentation.
19. Cloud Security Across AWS, Azure and Google Cloud
The exact implementation differs between AWS, Azure and Google Cloud, but the fundamental principles remain similar.
| Security Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Identity | IAM | Microsoft Entra ID / Azure RBAC | IAM |
| Virtual Network | VPC | VNet | VPC |
| Network Filtering | Security Groups / Network controls | NSG / Firewall | Firewall rules |
| Key Management | KMS | Key Vault | Cloud KMS |
| Logging | CloudTrail | Azure Monitor / Activity Log | Cloud Logging / Audit Logs |
For a broader provider comparison, see CorgiNetwork’s AWS vs Azure vs Google Cloud guide.
This distinction is important because cloud security principles are portable, while implementation details vary significantly between providers.
20. Cloud Security Architecture Example
Consider an enterprise application:
INTERNET
|
v
CDN / WAF / Edge
|
v
Public Load Balancer
|
+----------+----------+
| |
Web 01 Web 02
| |
+----------+----------+
|
Private Network
|
Application Tier
|
+-------------+-------------+
| |
Database Object Storage
| |
Encryption Encryption
| |
+-------------+-------------+
|
Backup / Recovery
Around this architecture should exist:
IAM
MFA
Least Privilege
Secrets Management
Logging
Monitoring
Vulnerability Management
Configuration Management
Incident Response
This illustrates an important concept:
Cloud security is not one security appliance. It is a system of interconnected controls.
21. Cloud Security Automation
Manual cloud security becomes increasingly difficult as environments scale.
Automation can continuously evaluate:
- New resources
- New IAM permissions
- Network exposure
- Vulnerabilities
- Encryption status
- Logging configuration
- Public storage
- Security-group changes
For example:
New Cloud Resource
|
v
Security Policy Check
|
+---+---+
| |
Pass Fail
| |
Deploy Alert / Block
Automation can be combined with the networking and infrastructure principles described in CorgiNetwork’s Cloud Networking Explained article.
22. Cloud Security Misconfiguration Example
Suppose a database security policy allows:
Source: 0.0.0.0/0
Port: 5432
This could expose PostgreSQL to the public Internet.
A better design is:
Application Security Group
|
| TCP 5432
v
Database
No direct public route is required.
The principle is:
Do not expose a service simply because another component needs access to it.
Instead, explicitly define the smallest required communication path.
For the underlying firewall and network-access concepts, CorgiNetwork’s Firewalls Explained provides a useful companion guide.
23. Cloud Security Testing
Security testing should occur throughout the lifecycle.
Development
- Dependency scanning
- Secret detection
- Static analysis
- IaC scanning
CI/CD
- Image scanning
- Configuration validation
- Policy checks
- Security tests
Production
- Vulnerability management
- Continuous monitoring
- Threat detection
- Configuration auditing
- Penetration testing where authorized
After deployment
- Continuous validation
- Access reviews
- Log analysis
- Incident exercises
24. Cloud Security Checklist
Identity
- MFA enabled for privileged users
- Least privilege implemented
- Unused accounts removed
- Service identities reviewed
- Privileged access monitored
Network
- Public exposure minimized
- Private subnets used where appropriate
- Firewall rules reviewed
- Administrative ports restricted
- Segmentation implemented
Data
- Sensitive data classified
- Encryption enabled
- Keys protected
- Backups configured
- Storage access reviewed
Workloads
- Operating systems patched
- Images scanned
- Containers run with appropriate privileges
- Unnecessary services removed
- Endpoint/runtime monitoring enabled
Monitoring
- Cloud audit logs enabled
- Security events centralized
- Alerts configured
- Logs retained appropriately
- Incident-response procedures tested
Governance
- Security policies documented
- Compliance requirements identified
- Configuration continuously assessed
- Security ownership assigned
- Third-party risks reviewed
25. Common Cloud Security Mistakes
Mistake 1: Giving everyone administrator access
This dramatically increases the impact of compromised credentials.
AWS’s official IAM guidance specifically recommends least-privilege permissions and regular removal of unnecessary access.
Mistake 2: Treating the cloud as a traditional data center
Cloud infrastructure has different identity, API and automation characteristics.
NIST’s cloud security guidance discusses the architectural and security implications of moving infrastructure and data outside traditional organizational boundaries.
Mistake 3: Making storage public for convenience
Public access should be an explicit architectural decision, not an accidental configuration.
Mistake 4: Hard-coding secrets
Secrets should be stored and managed through appropriate secret-management mechanisms.
Mistake 5: Ignoring service accounts
Non-human identities can have extremely powerful permissions.
CISA’s IAM best-practice guidance explicitly includes service and system accounts within IAM management.
Mistake 6: Disabling logging to save costs
Without logs, investigation and incident response become significantly more difficult.
Mistake 7: Assuming the provider secures everything
Cloud providers secure their part of the platform, but customer responsibilities remain.
Mistake 8: Building security after deployment
Security should be incorporated into architecture, code, infrastructure and deployment pipelines from the beginning.
26. Cloud Security vs Network Security
Cloud security is broader than cloud network security.
| Area | Primary Focus |
|---|---|
| Network Security | Traffic and connectivity |
| IAM | Identity and authorization |
| Data Security | Data protection |
| Workload Security | Servers and applications |
| API Security | Application interfaces |
| Cloud Configuration Security | Resource configuration |
| Monitoring | Visibility and detection |
| Incident Response | Handling security events |
| Governance | Policies and compliance |
For the networking foundation behind these controls, readers can continue to Computer Networking Explained and Network Security Basics.
This is why cloud security should be considered a complete security discipline rather than merely an extension of the firewall.
27. Cloud Security Architecture Principles
A mature architecture generally follows these principles:
1. Least privilege
Give identities the minimum required permissions.
2. Defense in depth
Use multiple independent security controls.
3. Assume breach
Design systems so that one compromised identity or workload does not automatically compromise everything.
4. Secure by default
New resources should start with restrictive security settings.
5. Continuous monitoring
Security should be continuously evaluated rather than checked once.
6. Automation
Automate repetitive security controls wherever possible.
7. Separation of duties
Avoid concentrating every security-critical permission in one identity.
8. Strong identity
Treat identity as a major security boundary.
9. Minimize public exposure
Internet accessibility should be deliberate.
10. Recoverability
Security architecture must include backup and recovery.
28. A Practical Cloud Security Roadmap
Organizations starting cloud security can follow this progression:
Phase 1
Identity
|
v
MFA + Least Privilege
Phase 2
Network
|
v
Segmentation + Firewalls
Phase 3
Data
|
v
Encryption + Key Management
Phase 4
Workloads
|
v
Patching + Vulnerability Management
Phase 5
Visibility
|
v
Logging + SIEM + Detection
Phase 6
Automation
|
v
IaC + Policy as Code
Phase 7
Advanced Security
|
v
Zero Trust + Continuous Validation
This staged approach makes cloud security easier to operationalize.
29. Frequently Asked Questions
What is cloud security?
Cloud security is the collection of technologies, processes and security controls used to protect cloud infrastructure, applications, identities, networks and data.
Is cloud computing secure?
Cloud platforms provide extensive security capabilities, but secure operation depends heavily on architecture, configuration, identity management and operational practices.
Who is responsible for cloud security?
Security responsibilities are shared between the cloud provider and the customer. The exact division depends on the service and deployment model.
What is the biggest cloud security risk?
There is no single universal risk. Common high-impact areas include compromised identities, excessive privileges, insecure configurations, exposed data, vulnerable workloads and insufficient monitoring.
Does encryption make cloud data secure?
Encryption is an important control, but it does not replace IAM, authorization, secure applications, monitoring or proper configuration.
Should cloud databases be public?
A database should not be publicly accessible merely because an application needs to use it. Private connectivity and restrictive access controls are generally preferable when public access is not required.
Is Zero Trust useful in cloud environments?
Yes. Zero Trust principles such as explicit verification, least privilege and continuous monitoring align well with distributed cloud architectures. NIST’s SP 800-207 provides the formal architectural foundation.
How can cloud security be automated?
Security can be integrated into Infrastructure as Code, CI/CD, policy checks, vulnerability scanning, configuration monitoring and automated incident response.
30. Final Cloud Security Architecture
A mature cloud environment can be represented as:
USERS
|
Strong Identity
|
MFA / Conditional
Access
|
v
+------------------+
| Cloud Edge |
| CDN / WAF / DDoS |
+------------------+
|
v
+------------------+
| Load Balancer |
+------------------+
|
+---------+---------+
| |
Web Tier API Tier
| |
+---------+---------+
|
Application Tier
|
+------------+------------+
| |
Database Object Storage
| |
Encryption Encryption
| |
+------------+------------+
|
Backup / Recovery
Security Across Everything:
IAM + MFA + Least Privilege
Firewalls + Segmentation
Secrets Management
Logging + SIEM
Vulnerability Management
Configuration Management
Zero Trust
Incident Response
Conclusion
Cloud security is fundamentally about controlling who can access what, from where, under which conditions, and with what level of privilege.
A secure cloud architecture combines identity security, network segmentation, encryption, workload protection, secure configuration, API security, monitoring, automation and incident response.
The most important architectural shift is moving away from the idea that security is provided by a single perimeter.
In modern cloud environments, security must exist across:
Identity → Network → Application → Workload → Data → Monitoring → Governance
NIST’s Guidelines on Security and Privacy in Public Cloud Computing provides a foundational framework for understanding the security and privacy considerations involved in public-cloud environments.
For the identity layer, the CISA IAM Best Practices and AWS’s IAM Security Best Practices provide practical guidance around identity inventory, least privilege, MFA and access management.
For Zero Trust architectures, NIST’s SP 800-207 provides the underlying architecture and principles.
For CorgiNetwork readers, this article connects directly with the existing Cloud Computing Explained, IaaS vs PaaS vs SaaS, AWS vs Azure vs Google Cloud, Cloud Networking Explained, Network Security Basics, Firewalls Explained, Zero Trust Security, SIEM Explained and Intrusion Detection and Prevention Systems guides.
Together, these articles create a connected topical cluster covering cloud infrastructure, networking, identity and cybersecurity rather than isolated articles.
Authoritative External Resources
The following sources are referenced contextually throughout the article:
- NIST — Guidelines on Security and Privacy in Public Cloud Computing
- NIST — Zero Trust Architecture
- NIST — Cloud Computing Security Publications
- CISA — Identity and Access Management Best Practices
- AWS — IAM Security Best Practices
- AWS — Least-Privilege Permissions
SEO note: These are not intended to be a replacement for the contextual links above. The important internal and external links are deliberately placed inside the relevant paragraphs, so both readers and search engines can understand the semantic relationship between the pages.