Before you start: scope and the shared responsibility model

Choosing a reliable Cloud Service Provider (CSP) with a proven track record of good service and customer support is the first step. AWS, Azure and GCP are the top picks for most teams. For China, Alibaba Cloud, Huawei Cloud and Tencent Cloud are the top picks. For startups and people deploying hobby projects, you can look into DigitalOcean and Vultr (40-50% cheaper for small and mid workloads) or companies like Vercel, Supabase, Cloudflare that offer IaaS (read about it in the next few para). OVHcloud, Hetzner and Scaleway offer European data sovereignty, cheap, reliable, secure but customer support is pretty questionable.

Before onboarding any vendor, do your due diligence: check their certs and third-party audit reports (SOC 2, ISO 27001, 27701 etc), review their SLAs and support promises, and most importantly compliance to any regional laws (think GDPR for EU, California’s CCPA/CPRA, India’s DPDPA China’s PDPL etc).

Now let’s discuss the 4Ws: Who’s paying, what does the provider own, what do you own, and what’s pros/cons. Seriously nothing is 100% reliable and safe so writing what works and what doesn’t really helps to understand who is left with the bill and heavy luggage if things go south.

Let’s answer the remaining 2Ws: what does the provider own and what do you own. The simple answer is IaaS vs PaaS vs SaaS. Simply put cloud works on a shared responsibility model which means the provider and you both take care of certain aspects. This image will help you:

Use IaaS model with PaaS services (this is not either or so you can choose and mix match yaaay! the best of both worlds), when you’re setting up your own ap or creating a SaaS to sell and what we’ll discuss here.

Phew, now to the actual app review. The three things to ask for first: an architecture diagram, a data flow, and a list of who has admin access.

• An architecture diagram should help you understand the components of the app and how they connect with each other. For cloud, usually each service has a separate icon based on the provider. Check out AWS refrences for examples.
• A dataflow diagram shows how the data flows through the app. If there is a logic of user logging into their account, the dataflow would denote: User entering creds -> the creds are sent to IdP or DB -> If creds match an auth token is generated -> token used to access user’s data stored in DB -> final user console visible to user.
• Admin access should be very restricted. Ideally not even one user, once project goes live. Next section gives the details.

Identity and access

In cloud, there are broadly 4 access types: Root, Admin, Contributor and User.

• Root Access is god-tier/full access. Think super admin. You can create subscription, change billing etc. It’s recommended by everyone that this access should only be used for initial setup, billing, new sub-tenant creation or closing the account etc basically very big stuff. If you use it for everything and somehow lose it or attackers get this access, you’re cooked and would need a miracle to save your money and app. So use lower access for 90% of the things.

• Then we have Admin Access, which allows you to do any action on any services or resources. Just not the account level stuff like billing change etc. You can use it for day-to-day operations.

• Contributor is like a Delegated Administrator for a specific role that manages certain services like Security Hub. Usually the best practice is the IT team or 1-2 people have the Admin access for operations and if any dev/project teams need elevated access Contributor access can be given for that specific subscription or a few services in the account.

• User level access is the basic read-write access. You can gives this primarily for dev teams that don’t handle infra.

We know the access levels broadly, so to give them? The answer is IAM User ( not to be confused with user level access). IAM User is the identity created within IAM to represent a person or application. By default, an IAM User has no permissions and must be explicitly granted access via attached policies. The idea is when a user or app is setup on cloud, an ID is created for them which allows them to work and take action on cloud. It’s not your company or personal ID like gmail.com but a specific ID only for your cloud tenant. You can decide what and how much access to be given for user. Single user accounts are used for apps, automations etc and for devs, IT login corporates can enable SSO using SAML 2.0 for user auth on portal.

Securing the IAM

(order: the console, service accounts, cloud service-to-service communication, devs connecting to infra, end user login)

• Set up SSO+MFA for user auth to resource console.
• Make sure service accounts/app accounts have bare minimum permissions to complete tasks essentially least privilege principle.
• Also, make sure each service account has someone responsible for managing it like updating password, storing the password properly so app can call the account etc.
• For authentication of services, try to use managed identities (platform manages the credentials.) or temp cred which are sent straight to compute resource based on role.
• In some cases long-lived keys are unavoidable if that is the case make sure the keys are stored securely in a vault.
• Token based auth (OAuth 2.0 or JWT) is generally used for API. Access tokens should be short-lived. A shorter life shrinks the window in which a stolen token is usable. Also, configure policies for refresh tokens for public clients (SPAs, mobile) like periodic rotation or sender constrained and ensure tokens are out of browser storage.
• For devs to login to connect to the EC2/VM etc usually people use SSH keys (store in a encrypted file on PC). For environments, that need more security go for Session Manager.
• For end users of the app (not devs and IT but actual users), set up SSO or username/password with MFA. Now, just a single username/password isn’t sufficient so MFA, password complexity, max retry attempts need to be setup.
• Lastly but most importantly, give access sparingly. Diligently and religiously follow least privilege principle. When in doubt just give user level access only. This goes for the console, services and the app. For app, implement role-based-access-control (RBAC), check out free software to help with it: Casbin and Casdoor for AI/LLM agents.

Network exposure

Since cloud follows a shared responsibility split, the provider manages the infra but you manage the access. In cloud, networking is based on using virtualized technologies rather than physical hardware. Software-Defined Wide Area Network (SD-WAN), Virtual Private Network (VPN), and Virtual Private Cloud (VPC) are the major technologies that help us secure cloud infra.

• VPN is something you would probably have heard of. VPN is basically encrypted tunnels to secure communication between devices or networks over the internet. In an eg: if a letter is the data, the envelope is the tunnel and the stamp is the auth key. Corporates usually setup their own VPN because it allows them to host and expose internal apps, platforms etc only to their employees. When you have an app that should be only accessed by employees of the company, one of the simplest way to reduce the attack surface is to IP lock the app to the IP range of the VPN. It basically means that employees would have to connect to the corporate VPN to be able to connect to the app. If we follow the letter example, basically IP Range is the postal code by mentioning that we ensure only letters of a certain area come to that post office.
• Virtual Private Cloud ( VPC) is the isolated network environment within a public cloud with it’s own subnet, IP range and route tables. When you request any resources like servers or databases, they’re automatically given to you in a VPC. All your requested resources will be in the same VPC. If you request a new service, you can decide to add it to a existing VPC or a new VPC. Some services are PaaS and when you request the services they come in a separate VPC with it’s own DB, LB, vault etc. To connect a PaaS service with your other resources you have to use VPC peering.
• Consider VPC your app’s home and you need to secure it properly using Network Security Groups (NSGs) and private endpoints. You need to lock it down.
  • Make sure that the app is not accessible to anyone and everyone over the internet (0.0.0.0/0).
  • Open only ports that you actually use like 443 for (HTTPS) or 5432 (PostgreSQL DB).
  • For SSH (22) or RDP (3389) connectivity for devs, use a bastion host or jump box. Never expose these ports directly to the public internet as these protocols allow us to connect to VMs/systems etc remotely.
  • Block access from known malicious IPs. Use AbuseIPDB and Project Honeypot for the list.
• If you’re app is exposed to the internet use a load balancer with WAF. This way the load balancer’s public IP is exposed and not your app. Add an APIM as well, if you have a huge app with loads of APIs.
• Use public endpoints with public IP for public internet facing traffic and private endpoints with private IPs (uses the provider’s backbone network) for all resource/internal traffic.
• What if the frontend of the app is on cloud but the DB is on-prem? In that case, we use the vendor provided direct cloud connectivity service. Think AWS Direct Connect, Azure ExpressRoute and GCP Interconnect. Basically these are network connections managed by the provider that uses a combo of MPLS, IPSec, broadband for good connectivity with SD-WAN for management. Very secure and very expensive so use it with a pinch of salt.

Data protection

Easiest to execute but most important section especially from compliance.

• Encryption at rest and in transit, everywhere data lives and moves. Server-side encryption is enabled by default by major cloud providers. For data in transit use TLS 1.2+ and for data at rest use AES 256 (industry best practice).
• Encryption options based on service:
  • Full-Disk Encryption (FDE) and Encryption at Host: Use for VMs and VDIs. FDE encrypts the entire storage device (e.g., BitLocker, LUKS). Encryption at Host provides end-to-end encryption from the VM host to the storage service.
  • Transparent Data Encryption (TDE): Use for DBs and provider managed DBs. Automatically encrypts database files in real-time without application changes.
  • File/Column-Level Encryption: Use for DBs and provider managed DBs storing PII/PHI data. Targets specific sensitive fields or files for granular control.
• Make sure the keys, certificates and creds for service-to-service auth are stored in a vault or HSM. You can use the CSP’s native vault service or checkout HashiCorp’s free tier license (not opensource so check the license). Also, make sure the whole key lifecycle: creation, usage, rotation, deletion has a policy to be followed.
• The keys can be generated by the provider or you or the client but store it in a vault.
• Passwords, API keys, tokens and connection strings shouldn’t be written directly into source files, config files, Docker images or CI scripts. Inject the passwords etc from the CI platform’s storage directly at runtime.
• If you use GitHub, use their push protection and secret scanning to intercept a push before the secret enters the repository.
• You can use scanners like gitleaks as pre-commit hooks or CI checks.
• Make sure your storage buckets are private and accessible only to authorized members (think devs maintaining the content and app to update records) via DLs . Crosscheck even if public access is disabled by default. If a bucket must be public (static website assets, say), keep it separate and confirm nothing sensitive is in it.

Logging and detection

• If you have a corporate SIEM, make sure all relevant logs are integrated. If you don’t have a SIEM, you can use the provider’s native monitoring service like AWS CloudTrail and Azure Sentinel or free-tier/cheaper vendor options like New Relic, Grafana Cloud , Datadog or open-source solutions (needs some underlying infra)like Grafana Loki and the Elastic Stack (ELK).
• Figure out the logs needed to be monitored like user access logs, admin activity logs, audit logs etc and push it to SIEM.
• Make sure retention is long enough to investigate something that happened months ago.
• Alerts should go to a real person who will see them, not a mailbox nobody checks.

Resilience

• Figure out RTO and RPO for the app. Recovery Time Objective (RTO) is the max acceptable downtime for a system or service after a disruption, basically how quickly operations must be restored. Recovery Point Objective (RPO) is the max acceptable amount of data loss basically the time between the last successful backup and the failure event.
• Once you have this, decide your backup strategy. Eg: backup the DB once a day and VM image once a week etc.
• Backups should be isolated from production, so one bad day can’t take out both.
• A backup you’ve never restored is a rumor. Test your backup copies for successful restoration.
• If your app is very critical, make sure there are at least 2 backups and in two different geographic regions.

Turning findings into fixes

Finally, we’re winding down. Run compliance scans and vulnerability scans on your cloud workloads. Categorize the findings business impact, not just CVSS. Make sure each finding has an owner, a date for closure and someone to check it (who’s not responsible for fixing it).

You don’t need to fix everything in week one. Get the map, follow the data, find the keyholders, then work through the five areas and rank what you find by how much damage it could do. Start with the things that are both easy to exploit and painful to lose.

And if someone says “it’s all fine” without a diagram to back it up, smile politely and ask for the diagram.