Cloud Security · AWS · Azure · GCP · Kubernetes · India 2026

Everything about Cloud Security for Indian organisations

Cloud is now the default, but cloud security is not on by default. Whether you are running AWS, Azure, GCP, or a multi-cloud stack — this pillar walks through what to lock down, how Indian regulations apply, and links to every RingSafe resource on the topic — services, guides, checklists, free tools, and 30+ practitioner blog posts.

Cloud providers
3
Posture
CSPM
Frameworks
CIS · NIST
Locality
India-aware
01 · Foundations

The shared-responsibility model — and where Indian businesses get burnt

Every major cloud provider operates a shared-responsibility model: they secure the cloud; you secure what's in it. The split is well-documented but routinely misunderstood. Cloud providers handle physical security, hypervisor, host OS patching, backbone network. Customers own: identity & access, data classification & encryption, network configuration in the cloud, application security, OS-level patching for non-managed services, logging & monitoring, compliance-control implementation.

Indian organisations most often get burnt at: (1) IAM — over-permissioned roles and inactive users; (2) public storage — open S3 / Blob / GCS; (3) SSRF / metadata service — instance roles abused via web app vulnerabilities; (4) logging — no CloudTrail / Activity Log / Cloud Audit Logs; (5) localisation — accidentally hosting Indian regulated data in US / EU regions.

Reference frameworks that matter

  • CIS Benchmarks — AWS, Azure, GCP, Kubernetes, EKS, GKE. The de-facto baseline.
  • NIST CSF — broad cyber framework; cloud-applicable.
  • NIST 800-53 / 800-171 — control library mapping.
  • ISO 27001:2022 + ISO 27017 (cloud-specific) + ISO 27018 (cloud PII) — international.
  • SOC 2 — for SaaS selling to US enterprise.
  • CSA STAR / CCM — Cloud Security Alliance Cloud Controls Matrix.
  • RBI / SEBI / IRDAI cloud rules — Indian sectoral cloud guidance.
02 · Real vs theatre

Real cloud security vs theatre

"We have AWS" or "we use Defender" is not a security posture. Use this as a buyer-side check before signing a cloud-security PO or trusting an internal report.

What real cloud security looks like

  • IAM hygiene — least privilege, no long-lived root keys, MFA enforced, regular access reviews.
  • Continuous posture — CSPM running against CIS baselines, drift detected within hours.
  • Centralised logging — CloudTrail/Activity/Audit shipping to a SIEM you can query.
  • Encryption with customer-controlled keys, especially for regulated data.
  • Documented blast-radius per workload, with multi-account segregation.

Cloud security theatre

  • "We turned on Security Hub" — and never read the findings.
  • Public S3/Blob/GCS "for convenience" — full customer datasets exposed.
  • One root account for everything, no organisational unit boundaries.
  • Logging on but no SIEM — no one would notice an attack in real time.
  • "We do CSPM annually" — once-a-year posture is point-in-time noise.
03 · Domains
Cloud security domains

What "cloud security" actually covers

Real cloud security spans nine practitioner domains. Most maturity programmes work through them in this order.

Identity & Access

IAM hygiene, role-based access, federated identity, MFA, key rotation, JIT elevation.

Data Protection

Encryption at rest (KMS/CMK), in-transit TLS, classification, DLP, secrets management.

Network Security

VPC design, security groups, NSGs, private endpoints, transit gateway, WAF, DDoS.

Logging & Monitoring

CloudTrail / Activity Log / Cloud Audit Logs, VPC flow logs, centralised SIEM ingestion.

Configuration & Posture

CSPM, drift detection, hardening baselines, IaC scanning (Checkov, tfsec).

Workload Security

Containers, Kubernetes, serverless, EDR for VMs, image scanning, runtime defences.

SDLC / DevSecOps

SAST/DAST/SCA in pipelines, supply-chain (SBOM, SLSA), IaC review, secrets-in-code.

Detection & Response

Cloud-aware SIEM use-cases, GuardDuty, Defender for Cloud, SCC, automated response (SOAR).

Compliance & Governance

Tagging, SCPs/Azure Policy/Org Policy, multi-account, data residency, audit evidence.

04 · Resources
RingSafe cloud resources

Pillar resources — scope, secure, audit your cloud

Services, guides, free tools, and deep-dive technical content for AWS / Azure / GCP / Kubernetes.

Service

Cloud Security Services — AWS · Azure · GCP · Kubernetes

Practitioner-led cloud security audits, IAM dives, posture remediation, and continuous-monitoring rollouts.

See services →
Practitioner Guide

The Complete Cloud Security Guide for India

Shared responsibility, the nine domains, the RBI/SEBI/IRDAI cloud overlay, and a 90-day cloud-hardening roadmap.

Read the guide →
Free Tool · 5 min

Cloud Audit Readiness Checklist

Twenty practitioner-grade questions on IAM, network, data, logging, posture, and compliance across the three majors.

Take the checklist →
Academy · AWS

AWS IAM Deep Dive

Policy structure, conditions, IAM Roles Anywhere, identity-based vs resource-based, common pitfalls and modern best-practices.

Open the module →
AWS · Blog

AWS IAM Privilege Escalation — 7 Paths

From a leaked low-privilege key to administrator: CreateLoginProfile, AttachUserPolicy, PutUserPolicy, PassRole-Lambda, and more.

Read →
AWS · Blog

AWS EC2 SSRF — One Curl to Cloud Compromise

One missing input filter on SSRF lets an attacker reach 169.254.169.254. From single curl: IAM creds extracted, S3 dumped, customer data gone in 30 minutes.

Read →
AWS · Blog

S3 Misconfigurations Indian Startups Make

Five S3 misconfigurations on every Indian startup audit — Block Public Access disabled, broad bucket-policy Principal, pre-signed URL leakage.

Read →
Academy · Azure

Entra ID — Modern Identity

Conditional access, PIM, application registrations, OAuth grant flows, B2B/B2C distinctions, common attack paths.

Open the module →
Academy · Architecture

Zero Trust Architecture

NIST 800-207 principles, CISA five-pillar maturity model, the reference stack (IdP, MFA, EDR, ZTNA), realistic 12-18 month rollout.

Open the module →
Academy · Foundations

Cloud Data Security Mental Models

Frameworks for thinking about cloud data security — the data-vs-control plane split, data perimeter, blast radius, defense in depth.

Open the module →
Academy · SaaS

CASB & SaaS Data Governance

CASB modes, SaaS-to-SaaS OAuth governance, shadow-IT discovery, sensitive-data inventory across 200+ SaaS apps.

Open the module →
Compliance

RBI Cyber Framework — Cloud rules

RBI's expectations for cloud adoption — board approval, customer-controlled keys, data residency, exit plans, vendor flow-down.

Read RBI →
05 · FAQ
FAQ

Cloud Security — questions we get

Should I use AWS, Azure, or GCP? +

Each is mature enough that none is a security disqualifier. Decision factors: existing skill base, partner ecosystem, geographic regions, sectoral familiarity (Indian banks lean Azure for regulator-comfort; SaaS often AWS; data-analytics often GCP). Multi-cloud is increasingly common but doubles the security tooling and skill requirement. Whichever you pick, treat the security model and IAM baseline seriously from day one.

Where do Indian organisations most often get cloud-breached? +

In our audit data the top patterns are: (1) leaked AWS access keys via developer GitHub repos, (2) public S3/Blob/GCS containing customer data, (3) SSRF in web apps reaching the metadata service to steal IAM creds, (4) over-privileged service accounts no one re-evaluated after a project ended, (5) production data in non-production environments without segregation.

Do I need a CSPM tool? +

If you have more than ~50 cloud resources or process regulated data — yes. CSPM (Wiz, Prisma Cloud, Defender for Cloud, Orca, Lacework) gives you continuous posture across hundreds of CIS-style checks. For very small footprints, free tools like Prowler, ScoutSuite, Steampipe, AWS Config + Security Hub get you most of the value.

What about Indian data localisation in the cloud? +

Sectoral rules apply: RBI / SEBI / IRDAI / NPCI / UIDAI variously require Indian-region storage of regulated data. DPDP §16 follows a negative-list approach (when notified). Practical guidance: pick India regions for primary copies; if cross-border DR or analytics is needed, document board approval, customer-controlled keys, contractual safeguards, and a tested exit plan.

How does Kubernetes change cloud security? +

K8s introduces its own attack surface: cluster RBAC, pod security policies/standards, network policies, secrets management, image scanning, runtime detection (Falco, Sysdig). Treat it as a separate security domain alongside your cloud account hygiene. CIS Kubernetes / EKS / AKS / GKE benchmarks are the working baseline.

What's a cloud security audit and how often? +

An external cloud security audit reviews IAM, network, data, logging, posture, and compliance against a chosen framework (CIS / NIST / your sectoral regulator). Point-in-time audit annually, continuous monitoring (CSPM) ideally always-on. After major changes (new accounts, M&A, multi-cloud expansion, new high-risk services) — out-of-cycle audit.

How do I secure my Kubernetes cluster on a small budget? +

Open-source baseline that gets you 80%: Falco for runtime, kube-bench for CIS scoring, Trivy for image + IaC scanning, OPA/Gatekeeper or Kyverno for policy, kubectl-who-can / RBAC reviews. Layer on the cloud's native (EKS/AKS/GKE) security features — image-scanning in registry, network policies, secrets-store-CSI for cloud secrets.

Can a small team really secure cloud properly? +

Yes — at small scale, lean on managed services (RDS over self-hosted DB, KMS over self-hosted HSM, IAM Identity Center over custom SSO), enforce IaC (Terraform/CDK) for everything to keep config auditable, use one CSPM, and run an external audit annually. The pattern that fails small teams is "we'll secure it later" — by which point IAM is unmanageable and data has spread.

Free 30-min cloud scoping call

Lock down your cloud before someone else does it for you

A 30-minute working call. We map your cloud footprint, identify the highest-leverage gaps, and give you a 90-day hardening roadmap.