Problems & fixes · Cloud security
Common cloud misconfigurations and how to fix them
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Most cloud exposure comes from a short list of recurring mistakes: publicly reachable storage, overly broad permissions, long-lived access keys, disabled logging, open administrative ports and unprotected secrets in code. Fix them by inventorying accounts, restricting identities, enabling audit logs, then using templates and guardrails so the same errors cannot return.
Who this is for: An engineer or IT manager who suspects their cloud accounts have accumulated risky settings and needs to know what to look for and how to remediate safely.
What to evaluate
Public exposure of data stores
Storage and databases reachable from the internet leak data without any exploit being needed.
How to check: List every storage bucket and database endpoint and confirm access policies deny public reads unless intentionally open.
Excessive permissions
Wildcard permissions let one stolen credential reach nearly everything.
How to check: Review roles granting full access and replace them with permissions tied to a task, using access analysis tools to spot unused rights.
Long-lived credentials
Static access keys get committed to repositories, copied to laptops and forgotten.
How to check: Inventory keys by age and last use, delete unused ones and prefer short-lived role-based access.
Logging and alerting gaps
Without audit logs, you cannot tell what an intruder did or prove what did not happen.
How to check: Confirm account-level audit logging is on in every region and logs are stored in a protected, separate location.
Exposed administrative access
Remote administration ports open to the world are scanned constantly.
How to check: Look for firewall rules allowing wide access to remote login services and replace with brokered or private access.
Secrets in code and images
Credentials embedded in repositories, build logs or container images are easy to harvest.
How to check: Scan repositories and images for secrets, rotate anything found and move to a managed secret store.
Comparison
| Misconfiguration | Typical cause | Safer pattern |
|---|---|---|
| Publicly readable storage | Quick sharing during a project that was never reversed | Block public access at account level, share through time-limited links |
| Wildcard administrator roles | Granting everything to get unblocked | Role per function with periodic review of unused permissions |
| Static keys in repositories | Developers needing programmatic access fast | Short-lived credentials issued through roles and secret scanning in pipelines |
| Open remote login ports | Temporary troubleshooting rule left in place | Private access paths with strong authentication and session logging |
| Audit logging disabled in some regions | Account set up before standards existed | Organisation-wide logging enforced and monitored for tampering |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Public exposure of data stores | |||
| Excessive permissions | |||
| Long-lived credentials | |||
| Logging and alerting gaps | |||
| Exposed administrative access | |||
| Secrets in code and images | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Do we have a complete list of accounts, subscriptions and projects, including ones created by individual teams?
- Who can create or modify access policies, and is every such change logged?
- Which resources are intentionally public and who approved them?
- How would we notice if audit logging were turned off?
- Where are credentials stored, and how often are they rotated?
- What is our process to fix a finding without causing an outage?
- How do we prevent a fixed issue from being reintroduced by the next deployment?
Typical trade-offs
Fixing issues manually versus enforcing through templates
- Upside
- Manual fixes are quick for urgent exposures.
- Downside
- They leave templates unchanged, so the same mistake returns on the next deployment.
Strict account-wide denial rules versus team-level flexibility
- Upside
- Strict rules remove whole classes of error at once.
- Downside
- They can block legitimate use cases and need an exception process that works.
Immediate shutdown of risky resources versus staged remediation
- Upside
- Fast closure limits exposure time.
- Downside
- Unannounced changes can break dependent services and erode trust in the security team.
Common mistakes
- Remediating a public bucket without checking what was exposed. Review access logs to learn whether data was retrieved and treat it as an incident if so.
- Deleting a leaked key but not investigating its use. Examine activity under that credential for the entire exposure period.
- Fixing individual findings while ignoring the root cause. Update shared templates and pipeline checks.
- Granting broad access while troubleshooting and forgetting to revoke it. Use time-limited elevation that expires automatically.
- Assuming development accounts are low risk. They often hold real data and trusted network paths.
Related questions
What should we fix first in a cloud account we inherited?
Start with visibility and the highest-impact exposures. Enable audit logging and make sure it is stored safely, then protect the root or owner identity with strong authentication, and remove unused access keys. After that, find public data stores and administrative access reachable from the internet. Review broad permission roles next. This sequence gives you evidence to investigate, closes the most commonly exploited doors and sets up the later, more detailed permission cleanup.
How do we know if a misconfiguration was already exploited?
Check audit logs and access logs covering the period the setting was wrong. Look for requests from unfamiliar locations, bulk reads, new credentials or roles created, changes to logging and unexpected resource creation. If logs were not enabled, you may be unable to rule exploitation out, which should influence how cautiously you treat the data involved. Follow your incident process and consider legal notification duties in the jurisdictions that apply to your data.
Is it safe to automate remediation?
For well-understood, low-risk rules it is often valuable, such as re-enabling a disabled log or blocking public access on a new storage bucket. For changes that could interrupt service, prefer alerting plus a ticket and human review. Test automation in a non-production account, log every action and include an easy way to pause it. Review automated changes periodically so they do not drift from your intent.
How do we reduce repeat misconfigurations?
Make secure defaults the easy path. Provide approved templates, enforce guardrails at the organisation level, scan templates before deployment and give engineers quick feedback. Run periodic reviews of exceptions and retire those without a current reason. Share anonymised lessons from findings so teams understand the reasoning. Repeated errors usually signal that the secure way is harder than the insecure way, which is a design problem rather than a people problem.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Cloud security guidance — National Cyber Security Centre (UK), retrieved 27 October 2026
- Cloud Security Technical Reference Architecture — Cybersecurity and Infrastructure Security Agency, retrieved 27 October 2026
Related guides
How to choose · Cloud security
How to choose cloud security posture and workload protection tooling
Choose cloud posture tooling by how well it prioritises findings, how it reaches your accounts without excessive permissions, and how it hands work to engineers. Check multi-cloud coverage, identity analysis, infrastructure-as-code scanning and exception handling. A tool that lists thousands of unranked issues creates fatigue; context about reachability and privilege is what makes findings actionable.
Comparison · Cloud security
Cloud provider native security vs third-party tools and the shared responsibility split
Cloud providers secure the underlying infrastructure, while customers remain responsible for identities, configuration, data and applications. Native services are deeply integrated and often sufficient for a single cloud. Independent tools add consistency across providers and separation from the platform you are monitoring. The decision hinges on estate size, number of clouds and the skills you have to run each layer.
Requirements · Cloud security
Foundational requirements for securing a cloud account structure
A secure cloud foundation separates environments into distinct accounts, protects the top-level identity with strong authentication, centralises identity through a single directory, turns on audit logging in a protected location and sets organisation-wide guardrails. Doing these early is far easier than retrofitting them after teams have built on a flat, shared account.
Problems & fixes · Identity and access
Why former employees keep access and how to close the gaps
Orphaned access usually survives because accounts are created outside central identity, ownership is unclear, and offboarding depends on manual steps across many tools. Fix it with a single authoritative trigger from HR, central sign-in for as many apps as possible, regular access reviews, and a reconciled list of accounts that bypass single sign-on, such as shared logins, API keys and personal-email registrations.
How to choose · Artificial intelligence
How to choose a no-code workflow automation platform
Choose by the apps you must connect, the complexity of logic you need, how failures are surfaced, and how pricing scales with volume. Connector coverage and error handling matter more than a polished builder. Also check credential security, team access controls and how easily workflows can be exported if you outgrow the platform.
Problems & fixes · Artificial intelligence
Security and quality problems with AI-generated code
Generated code often looks right while hiding issues: insecure defaults, missing input validation, nonexistent or outdated dependencies, silent error swallowing, copied licensed snippets and tests that assert nothing. Catch these with the same safeguards used for human code: review, static analysis, dependency checks, meaningful tests and secret scanning, applied with extra suspicion toward confident-looking output.
Problems & fixes · Network security
Why firewall rules become unmanageable and how to fix them
Rule sprawl happens when temporary exceptions are never removed, rules lack owners and several people edit without records. It causes hidden exposure, outages when something is changed and slow audits. Fix it by documenting what exists, using hit counters and logs to identify unused rules, consolidating through objects and groups, and putting a change process in place.