By Cyber Defense Technologies July 28, 2026 4 min read
Cloud platforms offer strong security capabilities, but they also make it easy to make consequential mistakes quickly. A storage bucket can be made public with a single click. An identity can be granted sweeping permissions by a developer in a hurry. A test environment can expose a database to the internet and be forgotten.
Attackers scan continuously for these mistakes. Many cloud security incidents trace back not to a flaw in the cloud provider, but to how a customer configured their environment.
The shared responsibility model
Cloud providers secure the underlying infrastructure: data centers, hardware and the core platform. Customers are responsible for what they build on it: identities and access, configurations, network settings, data protection and application security. The exact division varies by service type, but misconfiguration almost always falls on the customer's side.
Cloud misconfigurations to check first
- Storage buckets or shares open to the public
- Identities with far more permissions than they use
- Long-lived access keys that are never rotated
- Administrative accounts without phishing-resistant MFA
- Management interfaces and databases exposed to the internet
- Audit logging disabled or not retained
- Security alerts generated but never reviewed
- Secrets stored in code, images or configuration files
The misconfigurations attackers look for
Publicly accessible storage
Storage buckets, blobs and file shares open to the internet have exposed enormous volumes of sensitive data over the years. Attackers use automated tools to find them.
Over-permissive identities
Users, roles and service accounts with far more permissions than they need turn a small compromise into a large one. Wildcard permissions and administrator roles granted "temporarily" are common problems.
Long-lived access keys
Static access keys that are never rotated, often embedded in code, scripts or container images, are regularly leaked through public code repositories and compromised developer machines.
Weak authentication for administrators
Cloud administrative consoles and accounts without phishing-resistant multifactor authentication are high-value targets, especially root or global administrator accounts.
Exposed management and data services
Databases, management interfaces, remote access services and development tools exposed directly to the internet invite exploitation.
Missing or disabled logging
Without audit logs of administrative actions and data access, organizations cannot detect attacks or investigate them. Some logging is not enabled by default.
Secrets in the wrong places
Passwords, API tokens and keys stored in code, configuration files, environment variables or images are easily exposed.
Unreviewed security alerts
Cloud providers offer security findings and alerts, but they only help if someone reviews and acts on them.
Why misconfigurations keep happening
- Speed: teams deploy quickly, sometimes bypassing review.
- Complexity: cloud permission models are powerful and intricate.
- Sprawl: multiple accounts, subscriptions and projects are hard to track.
- Defaults: some default settings favor convenience over security.
- Drift: secure configurations change over time as people troubleshoot and experiment.
Prevention and detection
- Configuration as code: define infrastructure in version-controlled templates reviewed like software.
- Policy as code: automatically block or flag risky configurations, such as public storage or unencrypted databases, before deployment.
- Guardrails at the organization level: use the provider's organization-wide controls to prevent the most dangerous actions in any account.
- Least privilege: grant minimal permissions, use roles instead of long-lived keys, and review unused permissions regularly.
- Centralized logging: collect audit and data access logs from every account into a protected location.
- Continuous posture monitoring: scan configurations continuously against secure baselines such as CIS Benchmarks and government guidance like CISA's SCuBA baselines.
- Secrets management: store secrets in a dedicated service and scan code and images for leaked credentials.
Frequently asked questions
Is the cloud less secure than on-premises? Not inherently. Cloud platforms provide powerful security capabilities. The risks differ, and misconfiguration is the most common one.
How often should we review cloud configurations? Continuously, with automated tools, supplemented by periodic expert review and penetration testing of cloud environments.
Where should we start? Enforce phishing-resistant MFA for administrators, find and fix public exposure, enable audit logging everywhere, and remove unused and excessive permissions.
What to do this week
- Search every cloud account for storage and databases reachable from the internet.
- List identities with administrator or wildcard permissions, and confirm each still needs them.
- Find access keys older than 90 days and rotate or remove them.
- Confirm audit logging is enabled in every account and region, and that logs go to a protected location.
- Enforce phishing-resistant MFA on root and global administrator accounts.
- Assign someone to review the provider's security findings every week.
How CDT can help
CDT's penetration testing includes cloud security testing across AWS, Azure and hybrid environments. Our secure systems engineering and DevSecOps teams build guardrails and configuration as code, and our FedRAMP readiness services help cloud providers meet federal requirements.
