The most useful cloud security tips are to lock down identity first, then reduce public exposure, turn on logging, protect data and backups, and check the code and dependencies you deploy. Most cloud incidents come from configuration and access mistakes, not exotic attacks, so small checks done consistently go a long way.
Why start with the shared responsibility line?
CISA's Cloud Security Technical Reference Architecture begins with a shared risk model for cloud adoption, then covers building a cloud environment and monitoring it with cloud security posture management. The practical lesson: the provider secures the facilities and underlying platform, and you secure what you configure. A storage bucket left public is your setting, not theirs.
Here are ten checks. Each is small enough for one person to finish in a day.
The ten checks
1. Protect the root account. The account owner login can do everything. Use a hardware key or strong multifactor authentication, store the recovery details safely, and do not use it for daily work.
2. Use single sign-on and multifactor everywhere. Every human login to the console should be through one identity provider with multifactor enabled. Remove local users you do not need.
3. Grant least privilege. Replace broad administrator roles with roles for specific jobs. Review who holds administrator rights and remove the ones nobody can justify.
4. Prefer short-lived credentials. Long-lived access keys sit in laptops and repositories for years. Use roles that issue temporary credentials to workloads, and rotate or delete old keys.
5. List what is public. Find storage, databases and services reachable from the internet. Close what should not be. A scan of your own address space and your provider's own configuration findings both help.
6. Turn on audit logging in every region. Send logs to a separate account or store that normal admins cannot delete. NIST SP 800-137 describes continuous monitoring as ongoing visibility into assets and control effectiveness, and logs are its raw material.
7. Encrypt data and own the keys. Enable encryption at rest by default, and decide who controls key use. Encryption does not stop an authorised identity from reading data, so keep access tight.
8. Test your backups. Store them in a separate account or location, protected from deletion by regular admin accounts. CISA's ransomware guidance stresses regular testing and isolation. Do a restore drill and write down the time.
9. Scan what you deploy. Check dependencies, container images, infrastructure as code and secrets before they reach the cloud. A committed access key or a vulnerable library is a way in that no cloud setting prevents.
10. Watch for drift. Compare actual configuration with your intended baseline on a schedule and alert on differences. Changes made by hand in the console are a frequent cause.
What does a constructed example look like?
A five person startup follows the list on a Friday. They find an old access key belonging to a contractor, still active and with administrator rights. They find a staging database with a public address and the default port open. And they discover that audit logging covers only one of the three regions they use. Three fixes, one afternoon: delete the key, make the database private, enable logging everywhere with a separate destination.
What should you not do?
Do not treat a passing provider dashboard as proof of safety. Do not grant administrator rights to speed up a project and promise to fix it later. Do not copy production data into a test account with weaker controls.
How to check or apply this
- Spend the first hour on checks 1 to 3, since identity is the biggest payoff.
- Spend the second on exposure and logging, checks 5 and 6.
- Schedule a restore test for check 8 this month.
- Add scanning of code, dependencies and secrets to your pipeline, check 9.
- Write the checks into a one page checklist with an owner and a date.
- Rerun the list every quarter and after major changes.
Safeguard scans dependencies, secrets and code in your repositories and in pull requests, which covers check 9. It does not replace your cloud provider's own configuration controls.
Quick check
What is the single most important cloud security step?
Securing identity: multifactor authentication, least privilege and short-lived credentials. Most cloud compromises involve credentials or over-broad access.
Does the cloud provider secure my data?
The provider secures the underlying platform. You are responsible for your configuration, access and data protection settings.
Sources
- CISA, Cloud Security Technical Reference Architecture
- NIST SP 800-137, Information Security Continuous Monitoring
- CISA StopRansomware Guide
- CISA AA21-131A
Last reviewed: 18 October 2026.
