Cloud Security Basics for Small Businesses
A practical introduction to securing your AWS, Azure, or GCP environment — IAM, encryption, logging, and the most common misconfigurations that lead to breaches.
Cloud infrastructure is now the backbone of most small businesses, but the shared responsibility model means your provider secures the platform while you secure everything you put on it. Misconfigurations — not sophisticated attacks — are the leading cause of cloud data breaches.
The Shared Responsibility Model
AWS, Azure, and GCP all operate on the same principle: they secure the infrastructure (physical data centers, hypervisors, networking hardware) and you secure your configuration, data, and access controls. Every breach you read about involving 'an exposed S3 bucket' or 'a public database' is a customer misconfiguration, not a cloud provider failure.
Warning
If you only do one thing after reading this guide, enable MFA on your root/owner account. A compromised root account with no MFA gives an attacker complete control of your entire cloud environment.
Five Fundamentals to Get Right
- Identity and Access Management (IAM) — Follow the principle of least privilege. Every user and service should have only the permissions required for their specific role. Avoid wildcard (*) permissions and never use root/owner credentials for daily operations.
- Encryption — Enable encryption at rest for all storage (S3 buckets, database volumes, backups) and encryption in transit (TLS for all endpoints). Most cloud providers offer default encryption options that cost nothing to enable.
- Logging and Monitoring — Turn on audit logging (CloudTrail in AWS, Activity Log in Azure, Cloud Audit Logs in GCP). Without logs, you cannot detect unauthorized access or investigate incidents after the fact.
- Network Segmentation — Use VPCs/VNets with private subnets for databases and internal services. Only expose what must be public. Security groups and NACLs should default to deny and explicitly allow only required traffic.
- Backup and Recovery — Automate backups, test restores regularly, and keep backups in a separate account or region. A ransomware attack that encrypts your production data and your backups in the same account leaves you with nothing.
Common Misconfigurations That Cause Breaches
- Public S3 buckets or storage blobs — Always block public access unless you explicitly need it (like a static website). Use bucket policies to enforce this at the account level.
- Overly permissive security groups — A security group rule allowing 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP) is an open invitation. Restrict access to specific IP ranges or use a VPN/bastion host.
- Unencrypted databases — RDS instances, Azure SQL, and Cloud SQL all support encryption at rest. There is no good reason to leave database volumes unencrypted.
- Missing MFA on privileged accounts — Root accounts, admin users, and service accounts with broad permissions should all require multi-factor authentication.
- No CloudTrail or audit logging — Without logs, you are flying blind. Enable logging on day one and send logs to a separate, locked-down bucket or log analytics workspace.
Getting Started
If your cloud environment was set up without security in mind, start with an audit. Map every resource, review IAM policies, check encryption settings, and verify logging is enabled. Prioritize the critical items first — root MFA, public access blocking, and audit logging — then work through network segmentation and backup hardening.
Tip
Consider a professional cloud security audit if your team lacks cloud security expertise. A one-time audit with a remediation roadmap is far cheaper than a breach. CitrusCS offers cloud security audits scoped to your environment size.