Cloud Security Basics: IAM, Storage and Network

Cloud providers secure the data centres, hypervisors and managed services; everything you configure on top is your responsibility. This "shared responsibility model" is why most cloud breaches are not exotic exploits but a public bucket, an over-privileged access key, or an SSH port open to the internet. A handful of settings, applied consistently, prevents nearly all of them.

In this lesson you will learn how to structure identity and access management, keep storage private by default, segment the network, and use logging and scanning to catch drift. Examples use AWS names; every major provider has direct equivalents.

Identity and Access Management

IAM decides who can do what to which resource, and it is where least privilege matters most. The sample policy grants an application exactly two capabilities on exactly two resources; compare that with the common shortcut of attaching an administrator policy "to get it working".

Roles, not keys. Compute assumes a role and receives short-lived credentials automatically; no access key is ever created or stored.
No daily use of the root account, hardware MFA on it, and named identities with MFA for administrators.
Scope by resource. "Resource": "*" is a finding, not a policy. Access analysers report unused permissions; remove what is not used within 90 days.

Storage

Object storage is where the biggest leaks happen, because a single setting makes an entire bucket world-readable.

bash

# Enforce private-by-default for the whole account
aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

bash

# Encryption at rest and versioning for recovery from deletion or ransomware
aws s3api put-bucket-encryption --bucket shop-uploads-prod \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'
aws s3api put-bucket-versioning --bucket shop-uploads-prod --versioning-configuration Status=Enabled

Serve user files through short-lived presigned URLs or a CDN with signed access, never by making the bucket public. Apply the same rules to database snapshots, disk images and backups.

Network

Place databases, caches and internal services in private subnets with no route to the internet; only the load balancer is public.
Security groups are allowlists: the database group accepts port 5432 from the application group only, never from 0.0.0.0/0.
Remove SSH and RDP exposure entirely; use the provider's session manager or a bastion behind MFA.
Use VPC endpoints for storage and secrets services so that traffic never crosses the public internet.

Logging, Drift and Images

You cannot detect misuse of an account whose activity is not recorded:

bash

# Account-wide API audit trail into a locked-down bucket, and a config rule that flags public buckets
aws cloudtrail create-trail --name org-trail --s3-bucket-name audit-logs-prod --is-multi-region-trail
aws configservice put-config-rule --config-rule '{"ConfigRuleName":"s3-no-public-read","Source":{"Owner":"AWS","SourceIdentifier":"S3_BUCKET_PUBLIC_READ_PROHIBITED"}}'

Send the audit trail to a separate security account that application roles cannot write to or delete from.
Alert on root logins, IAM policy changes, security group changes and disabled logging.
Set billing alarms; a sudden cost spike is often the first sign of compromised credentials being used to mine cryptocurrency.
Scan container images before deployment (trivy image shop-api:1.4.2) and rebuild them on base-image security releases.

Define all of this as infrastructure as code so every change is reviewed and drift shows up in a pull request, not in an incident.

Key Takeaways

The provider secures the platform; identities, storage settings, networks and logging are your responsibility.
Use roles with short-lived credentials, MFA everywhere, resource-scoped policies and regular unused-permission reviews.
Block public access at the account level, encrypt and version buckets, and serve files through presigned or signed URLs.
Keep data stores in private subnets, allowlist security groups between tiers, and remove direct SSH exposure.
Centralise audit logs in a separate account, alert on IAM and network changes, scan images, manage everything as code.

Next lesson: Privacy and Data Protection: GDPR and DPDP for Developers — the legal side of handling personal data, translated into engineering tasks.