Sachan & Partners

Cloud security misconfigurations: six gaps worth checking first

Cloud security problems are often not exotic. They arise when access, exposure, data protection or monitoring settings drift away from what an organisation intended. A focused review can help a small team find the risks that matter without treating every scanner alert as an emergency.

Six areas to include in a first review

1. Excessive or dormant access

Look for broad administrator roles, unused accounts, long-lived credentials and service identities with more permissions than their workloads need. Check how privileged access is approved, protected with multi-factor authentication (MFA), reviewed and removed when no longer required.

How to improve it: map identities to owners and purpose, remove stale access, reduce permissions in stages, and prefer short-lived or workload identity mechanisms where the platform supports them. Test service changes before removing credentials that production workloads may still rely on.

2. Publicly reachable services and data

Check internet-facing management ports, permissive firewall rules, public storage and databases, and services that were intended to be private. Public reachability is not automatically a vulnerability, but it should be deliberate, documented and protected.

How to improve it: confirm business need and ownership, restrict network paths, use managed private connectivity where appropriate, and apply provider controls that prevent accidental public access. Verify exposure from the outside as well as from configuration records.

3. Unprotected secrets and keys

Credentials in source code, build logs, local files or untracked infrastructure can give an attacker a route into cloud environments.

How to improve it: move secrets into an approved secrets-management service, rotate exposed credentials, limit who and what can retrieve them, and add secret detection to development workflows. Treat a discovered live credential as a potential exposure until it has been revoked and investigated.

4. Incomplete audit and security logging

Teams may have logs enabled in one project or subscription but not across the organisation, or may lack retention, alert ownership and a way to investigate important events.

How to improve it: decide which administrative, identity and workload events are needed; centralise and protect relevant logs; set retention to meet operational and contractual needs; and test that alerts reach someone who can act.

5. Unpatched or untracked workloads

Virtual machines, containers, images and managed services can fall outside normal patching or asset ownership processes. Unsupported software and internet-facing workloads deserve particular attention.

How to improve it: reconcile cloud inventory with a named owner and lifecycle, establish patch and image-update responsibilities, and test emergency fixes for externally exposed critical vulnerabilities.

6. Missing guardrails and inconsistent configuration

If every project, account or subscription is configured by hand, secure defaults are easily missed and the same gap can return.

How to improve it: use reviewed infrastructure-as-code, policy checks and organisation-level guardrails. Roll them out in stages, monitor exceptions and provide a documented route for teams to request a justified change.

Use cloud-native controls or a CNAPP?

Start by confirming which security capabilities are already included in your cloud services and subscriptions. Native tools can be a good fit for a single-cloud estate or a team that wants a focused baseline. A third-party cloud-native application protection platform (CNAPP), such as Wiz or Palo Alto Networks Prisma Cloud, may help teams correlate findings across cloud environments and development workflows, depending on the licensed features and configured integrations.

Neither option fixes a gap by itself. Review coverage, identity permissions, finding quality, ownership, alert handling and the path from finding to tested remediation. Compare tools against real scenarios in your own environment rather than relying only on a feature checklist.

A practical review and remediation cycle

  1. Agree the environment, business services and review access.
  2. Inventory assets, owners, identities and external exposure.
  3. Collect platform and workload findings, then validate the important ones.
  4. Rank actions by impact, exposure, exploitability and business context.
  5. Assign an owner and due date; implement fixes through a controlled change.
  6. Re-test the control, record evidence and add a guardrail to stop recurrence.

We can carry out a read-only posture review or help implement an agreed remediation plan across Google Cloud, Azure and AWS. See our Posture Snapshot and cloud security services, or talk to us about your environment.

Further reading