Confusing cloud availability with secure configuration
Cloud platforms provide capable security services, but customers still make decisions about identities, data, network exposure, workloads and logging. A reliable provider does not automatically make an application well configured. Define responsibilities for the provider, internal platform team, application owner and any managed service partner, then make those responsibilities visible in architecture and operating procedures.
Begin with a small number of guardrails that apply consistently: approved regions and services, identity federation, account ownership, tagging, logging, backup expectations and a route for exceptions. Guardrails should help teams ship safely, not create an opaque approval maze that drives unmanaged work outside the platform.
Allowing privilege and credentials to accumulate
Broad roles, shared administrator accounts and long-lived access keys create durable paths to cloud resources. Centralise workforce identity, require strong authentication, prefer temporary credentials and give people and workloads only the access needed for their role. Review permissions using actual activity where supported, but investigate carefully before removing access that a critical process may still require.
Protect emergency access and root-level credentials separately. Rotate or remove unused keys, keep secrets out of source code and deployment output, and ensure automation identities are scoped to specific tasks. Permissions attached to pipelines, functions and integration services deserve the same scrutiny as human administrator roles.
Exposing services without understanding the path
A public endpoint is not always a mistake; an unexplained public endpoint is. Inventory internet-facing resources, confirm their purpose, restrict management interfaces and understand every path to sensitive data. Security groups, firewall rules, load balancers, storage policies and application authentication should be reviewed together because safe settings at one layer can be undermined by another.
Separate production and non-production environments according to risk, and control connectivity between them. Default networks and permissive test settings often persist into important workloads. Use automated checks for common exposure, but pair them with architecture review so reviewers understand intended traffic and business constraints.
Collecting logs without making them usable
Enable administrative activity, identity, network and workload logs that support investigation. Centralise them in a protected location, define retention and monitor whether sources stop reporting. Logs in the same account as a compromised workload may be altered or deleted. Time synchronisation, clear resource names and ownership make evidence far more useful during an incident.
Detection should focus on actions that matter: privilege changes, disabled safeguards, unusual credential use, new public exposure and access to critical data. Every alert needs an owner, context and an escalation path. A large volume of unreviewed events creates storage cost rather than security capability.
Assuming backup equals recoverability
Backups need protected access, appropriate retention and tested restoration. Consider whether a compromised administrator could delete both the workload and its recovery data, and whether dependencies such as identity, encryption keys, configuration and DNS are included in the recovery plan. Record recovery-time and recovery-point needs in business terms.
Infrastructure as code, policy checks and deployment pipelines can reduce drift and improve review, but they are production systems too. Protect repositories and build credentials, require review for important changes and preserve an audit trail. Validate provider guidance before implementation because services and recommended patterns continue to evolve.
What to do next.
- ✓Document shared responsibilities and named service owners.
- ✓Prefer federated identity and temporary credentials.
- ✓Review all internet-facing resources and management paths.
- ✓Centralise protected logs and monitor source health.
- ✓Keep secrets out of repositories and build output.
- ✓Test restoration with dependencies, not only isolated data.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.
Liam Khumalo
Secure Systems ContributorCovers software, SaaS and infrastructure design with an emphasis on maintainable controls, ownership and safe change.
More from this writer