Cloud security

In short

Cloud security is the set of controls, architectures and practices that protect data, workloads, identities and configurations running on shared, on-demand computing infrastructure such as AWS, Microsoft Azure, Google Cloud and India's MeghRaj/NIC cloud. It differs from traditional security because the perimeter is an API, the infrastructure is multi-tenant and virtualised, and responsibility is split between the cloud service provider (CSP) and the customer. In India it is governed by the Digital Personal Data Protection Act, 2023, CERT-In's 2022 cyber-security directions, MeitY's empanelment of cloud providers for government workloads, and sectoral rules from RBI, SEBI and IRDAI. University syllabi examine deployment and service models, virtualisation threats, the shared responsibility model and cloud cryptography; placement rounds at TCS, Infosys, Wipro, Accenture, Deloitte, PwC, Amazon and Microsoft test IAM policies, S3/storage misconfiguration, encryption key management and container security.

Explained

Cloud models and what each means for security

• Service models (NIST SP 800-145): *IaaS* gives virtual machines, storage and networks (EC2, Azure VM); *PaaS* gives a managed runtime/database (App Engine, RDS, Lambda); *SaaS* gives finished applications (Gmail, Salesforce, Zoho).
• Security burden shifts down the stack: in IaaS the customer secures OS, patching, firewalls, apps and data; in PaaS the CSP also owns OS and runtime; in SaaS the customer secures mainly identities, access settings and data handling.
• Deployment models: *public* (shared, multi-tenant), *private* (single organisation, on-prem or hosted — e.g. NIC's government cloud), *community* (shared by similar bodies such as state departments), *hybrid* (orchestrated public + private), and *multi-cloud* (two or more public CSPs, used to avoid lock-in).
• Five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service) each create a risk: self-service enables shadow IT, pooling enables cross-tenant leakage, elasticity enables cost/crypto-mining abuse, and metering data itself is sensitive.
• Cloud actors: consumer, provider, *broker*, *carrier* and *auditor* — exam questions ask for this NIST reference-architecture list.

Shared responsibility model

• Standard formulation: the CSP is responsible for *security of the cloud* (physical data centre, hypervisor, host OS, network fabric, managed service internals); the customer is responsible for *security in the cloud* (data, identities, configuration, guest OS, application code).
• Always the customer's, in every model: data classification, access rights and identity hygiene, acceptable use, and legal/regulatory accountability as the *data fiduciary* under the DPDP Act.
• Inherited controls: the customer can inherit the CSP's physical and environmental controls for an audit, but must obtain evidence — SOC 2 Type II report, ISO/IEC 27001 and 27017/27018 certificates, CSA STAR registry entry.
• Why breaches happen on the customer side: industry breach analyses consistently attribute the large majority of cloud incidents to customer misconfiguration and credential compromise, not to CSP infrastructure failure.
• Contractual layer: SLA, data-processing agreement, breach-notification timelines, right to audit, sub-processor disclosure, data-location clause and an exit/data-portability clause (avoiding vendor lock-in is itself an availability control).

Virtualisation, container and serverless security

• Hypervisor (VMM) types: Type 1 bare-metal (ESXi, Xen, KVM, Hyper-V) used in clouds; Type 2 hosted (VirtualBox). The hypervisor is the trust anchor — compromising it compromises every guest.
• Virtualisation threats: *VM escape / hyperjacking* (guest breaks into the hypervisor), *VM sprawl* (unmanaged, unpatched instances), *dormant-VM risk* (powered-off VMs miss patches), *VM migration interception* (live-migration traffic in clear), *snapshot/image theft* (snapshots contain memory and secrets), and side-channel attacks across co-tenants (cache timing, Spectre/Meltdown, Rowhammer).
• Isolation controls: dedicated/bare-metal hosts, placement groups, SR-IOV, encrypted live migration, hardened golden images, trusted boot and measured launch (TPM/vTPM), confidential computing with hardware enclaves (SGX, AMD SEV).
• Containers: share the host kernel, so isolation is weaker than a VM. Risks: vulnerable base images, --privileged containers, mounting the Docker socket, secrets baked into images, registry poisoning. Controls: minimal/distroless images, image scanning (Trivy, Clair), signing (Cosign/Notary), read-only root filesystems, dropped capabilities, seccomp/AppArmor, non-root users.
• Kubernetes: secure the API server (RBAC, no anonymous auth), use namespaces + NetworkPolicies for segmentation, Pod Security Admission, etcd encryption at rest, short-lived service-account tokens, admission controllers (OPA/Gatekeeper, Kyverno) to enforce policy as code.
• Serverless (FaaS): no OS to patch, but risks move to over-privileged execution roles, event-data injection, dependency vulnerabilities, secrets in environment variables and long function timeouts enabling abuse.

Identity, data protection and network controls in the cloud

• Cloud IAM principles: least privilege, no use of the root/global-admin account for daily work, MFA (hardware keys for admins), role assumption instead of long-lived access keys, workload identity for machines, and periodic key rotation and access review. *(Identity federation and SSO mechanisms belong to the IAM topic; here the focus is the cloud-specific policy object and its blast radius.)*
• Policy evaluation (AWS style): explicit Deny overrides everything; otherwise an Allow is needed from identity policy, resource policy, permission boundary and SCP together. "Action": "*", "Resource": "*" and wildcard principals are the classic audit findings.
• Encryption at rest: CSP-managed keys (SSE-S3 style), customer-managed keys in a KMS (rotatable, auditable, revocable), and *customer-supplied / BYOK / HYOK* keys or a cloud HSM for regulated data. Key policy is as important as the key — whoever can use the key can read the data.
• Encryption in transit: TLS 1.2/1.3 everywhere, private endpoints/VPC service endpoints so traffic never traverses the public internet, and encryption of backups and snapshots.
• Data states and extras: *in use* protection via confidential computing; tokenisation and format-preserving encryption for card data (PCI DSS scope reduction); crypto-shredding (destroy the key to render data unreadable) as the practical answer to "delete my data" in distributed storage.
• Cloud network segmentation: VPC/VNet with public and private subnets, security groups (stateful, instance-level) versus NACLs (stateless, subnet-level), NAT gateway for egress, bastion/jump host or session-manager access instead of open SSH, WAF and DDoS protection at the edge, and private interconnects (Direct Connect, ExpressRoute).
• Secrets management: Secrets Manager/Key Vault/HashiCorp Vault with dynamic, short-lived credentials — never credentials in code, Git history, AMIs or container images.

Threats, misconfiguration and cloud-native defences

• CSA's recurring top threats: misconfiguration and inadequate change control; identity and access mismanagement; insecure interfaces and APIs; lack of cloud security architecture; insecure software development; unsecured third parties; accidental data disclosure; system vulnerabilities; and limited cloud-usage visibility.
• Classic misconfigurations: publicly readable object storage buckets, open database ports (MongoDB/Elasticsearch/Redis), 0.0.0.0/0 security groups, public AMIs/snapshots, disabled logging, unencrypted volumes, unrotated keys.
• Cloud-specific attacks: SSRF against the instance metadata service to steal role credentials (mitigated by IMDSv2 token requirement), *privilege-escalation chains* through IAM PassRole/CreatePolicyVersion, *subdomain takeover* of dangling DNS records, *account takeover* of a CI/CD pipeline, and cryptojacking of stolen credentials.
• Defence tooling: CSPM (posture/config scanning), CWPP (workload protection), CIEM (entitlement analysis), CASB (visibility and control over SaaS use, inline or API mode), SASE/SSE (network security as a cloud service), and CNAPP (converged platform).
• Logging and detection: CloudTrail/Activity Log for control-plane audit, VPC flow logs, GuardDuty/Defender for threat detection, config-change recording, and log export to an immutable, separate account or SIEM. *(SOC/SIEM operations are covered in their own topic.)*
• Architecture principles: zero trust (never trust the network, verify every request), immutable infrastructure, infrastructure-as-code with scanned templates (Terraform + Checkov/tfsec), guardrails via landing zones and multi-account/subscription separation of prod and non-prod, and a shift-left DevSecOps pipeline.
• Business continuity: multi-AZ for high availability, multi-region for disaster recovery, defined RTO/RPO, backups with versioning and object-lock (ransomware resilience), and tested restore drills — a backup never restored is not a backup.

Indian law, standards and compliance practice

• Digital Personal Data Protection Act, 2023: the *data fiduciary* remains accountable even when a cloud *data processor* handles the data; needs a written contract, security safeguards, breach notification to the Data Protection Board and affected persons, purpose limitation and erasure on withdrawal of consent. Cross-border transfer is allowed to all countries except those the Central Government restricts by notification (a shift from the earlier "whitelist" approach). The subordinate Rules were notified in 2025 with phased implementation — check the current notified text, as obligations and timelines are being brought into force in stages.
• IT Act, 2000: Section 43A (compensation for failure to protect sensitive personal data), Section 72A (disclosure in breach of contract), Section 69 (interception/decryption directions), and the SPDI Rules, 2011 with "reasonable security practices" — ISO/IEC 27001 is named there as an acceptable standard. The DPDP Act omits Section 43A from 13 May 2027 (s.44(2)); until then Section 43A and the SPDI Rules apply.
• CERT-In Directions (April 2022, in force since): report specified cyber incidents within 6 hours of noticing; maintain ICT logs for 180 days within India; cloud/VPS/VPN providers must keep subscriber KYC and records for 5 years; clocks synced to NPL/NIC NTP.
• Government cloud: MeitY's MeghRaj cloud policy, and GI Cloud empanelment — government departments must use MeitY-empanelled CSPs/data centres audited by STQC; a provider's empanelment status should be verified at the time of procurement.
• Sectoral rules: RBI's directions on outsourcing of IT services and on storage of payment system data (payment data to be stored only in India, with limited conditions on foreign processing); SEBI's cloud-adoption framework for regulated entities; IRDAI information and cyber-security guidelines; UIDAI requirements for Aadhaar-related data.
• International standards worth naming in exams: ISO/IEC 27001 (ISMS), ISO/IEC 27017 (cloud security controls), ISO/IEC 27018 (PII in public clouds), ISO/IEC 27701 (privacy), CSA Cloud Controls Matrix and CAIQ/STAR, NIST SP 800-144/145/146, NIST CSF 2.0, FIPS 140-3 for crypto modules, PCI DSS v4.0 for cards, and SOC 2 for assurance reports. India also has IS/ISO/IEC 27001 adopted by BIS.

Key points

• IaaS/PaaS/SaaS - as you move up, the provider secures more of the stack and the customer secures less, but identity and data are never outsourced.
• Shared responsibility - CSP secures *of* the cloud, customer secures *in* the cloud; accountability under law stays with the customer.
• Misconfiguration - the dominant cause of real cloud breaches: public buckets, open ports, disabled logs, over-broad IAM.
• Multi-tenancy - resource pooling creates co-tenant risk; isolation failures appear as VM escape or cache side channels.
• Hypervisor - the single highest-value target in IaaS; Type 1 bare-metal hypervisors run production clouds.
• Containers vs VMs - containers share the host kernel (lighter, weaker isolation); VMs have separate kernels (heavier, stronger isolation).
• Least privilege + MFA + short-lived credentials - the three controls that prevent most credential-driven incidents.
• Explicit deny wins - in AWS-style policy evaluation, any Deny overrides every Allow.
• CMK over CSP-managed keys - customer-managed KMS keys give rotation, revocation and audit; BYOK/HSM for regulated data.
• Crypto-shredding - deleting the key is the practical way to make replicated cloud data unrecoverable.
• Security groups vs NACLs - stateful at instance level versus stateless at subnet level; both are needed.
• IMDS SSRF - a web app flaw can be escalated to steal instance role credentials; enforce IMDSv2.
• CSPM/CWPP/CIEM/CASB/CNAPP - posture, workload, entitlement, SaaS-usage and converged tooling respectively.
• Zero trust + IaC guardrails - verify every request; prevent drift by scanning templates before deployment.
• CERT-In 2022 - 6-hour incident reporting, 180-day logs in India, 5-year KYC retention for cloud/VPN providers.
• DPDP Act, 2023 - fiduciary/processor contract, safeguards, breach notification; transfers allowed except to restricted countries.
• MeitY empanelment / MeghRaj - mandatory route for Indian government cloud workloads, STQC-audited.
• ISO/IEC 27017 and 27018 - the two cloud-specific control standards; CSA CCM/CAIQ is the vendor-assessment questionnaire.

Formulas and examples

Example 1 — SLA downtime and service credit. A CSP promises 99.9% monthly uptime for a VM and gives a 10% credit if uptime falls below 99.9% and 25% below 99.0%. Monthly charge is ₹48,000.

• Allowed downtime at 99.9% = 0.001 × 43,200 = 43.2 minutes/month.
• Actual outage was 6 hours 30 min = 390 minutes → uptime = (43,200 − 390)/43,200 = 42,810/43,200 = 99.097%.
• 99.097% is below 99.9% but above 99.0%, so the 10% band applies → credit = 0.10 × ₹48,000 = ₹4,800.
• Note: the business lost far more than ₹4,800 in those 6.5 hours — SLA credits are not insurance, which is why multi-AZ design matters.

Example 2 — Architecture availability (single AZ vs multi-AZ). An application needs a web tier and a database tier; each instance is 99.5% available.

• Single AZ, one of each in series: A = 0.995 × 0.995 = 0.990025 → 99.0025%, i.e. about 0.009975 × 43,200 ≈ 431 minutes (7 h 11 m) of expected downtime a month.
• Duplicate each tier across two AZs: tier availability = 1 − (1 − 0.995)² = 1 − 0.000025 = 0.999975. Two such tiers in series = 0.999975² = 0.99995 → 99.995%, about 0.00005 × 43,200 ≈ 2.2 minutes a month.
• Conclusion: redundancy within a tier cut expected downtime from roughly 431 to 2.2 minutes — the standard justification for multi-AZ deployment.

Example 3 — Cost-justifying a cloud control (ALE). A fintech stores 2,00,000 customer records in cloud object storage. A public-bucket exposure is estimated to cost ₹1,500 per record in notification, remediation and penalty, but only 20% of records would realistically be exposed (exposure factor 0.2 on an asset value of ₹30 crore). Historical rate: once every 4 years.

• Asset value = 2,00,000 × ₹1,500 = ₹30,00,00,000 (₹30 crore). SLE = 0.2 × ₹30 crore = ₹6 crore.
• ARO = 1/4 = 0.25 → ALE_before = ₹6 crore × 0.25 = ₹1.5 crore per year.
• A CSPM tool plus block-public-access guardrails costs ₹18,00,000 a year and is assessed to cut the ARO to 0.02 → ALE_after = ₹6 crore × 0.02 = ₹12,00,000.
• Benefit = ₹1,50,00,000 − ₹12,00,000 = ₹1,38,00,000 > ₹18,00,000 cost → adopt the control; residual risk ₹12 lakh/year is accepted and documented.

Example 4 — Reading an over-permissive IAM policy.

{ "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:*", "Resource": "*" },
    { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*" }
  ] }

• Finding 1: s3:* on * lets the principal read, overwrite and delete every bucket in the account, including log buckets — breaks least privilege and log integrity.
• Finding 2: unrestricted iam:PassRole plus any compute-launch permission is a privilege-escalation path — launch an instance with an admin role and read its credentials.
• Fix: scope to arn:aws:s3:::app-prod-data/* with the specific actions needed, restrict PassRole to one named role with a iam:PassedToService condition, and add a Deny on log-bucket deletion plus a aws:SecureTransport condition to force TLS.

Example 5 — Envelope encryption key count. A SaaS platform encrypts 50,000 objects. With envelope encryption each object gets its own data encryption key (DEK), wrapped by one customer master key (CMK).

• Keys stored in the KMS = 1 (the CMK); DEKs are stored alongside the ciphertext in wrapped form, so KMS load and cost scale with key *operations*, not key *count*.
• Rotating the CMK re-wraps DEKs rather than re-encrypting 50,000 objects — cheap rotation.
• Contrast with per-tenant pairwise symmetric keys for 500 tenants: 500 × 499/2 = 1,24,750 keys — unmanageable, which is why hierarchical key management is used.

Where it is used

• IT services and consulting: TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Accenture, Deloitte, EY, KPMG and PwC run cloud-migration and cloud-security practices — roles such as cloud security engineer, CSPM analyst, cloud compliance consultant and DevSecOps engineer.
• Banking, payments and fintech: HDFC, ICICI, Axis, Paytm, PhonePe, Razorpay and Zerodha design cloud estates to satisfy RBI payment-data localisation and IT-outsourcing directions, with HSM-backed keys and segregated prod accounts.
• Government and public digital infrastructure: NIC's MeghRaj/national cloud, state data centres, GSTN, UIDAI and DigiLocker-class systems — procurement restricted to MeitY-empanelled, STQC-audited providers.
• Product and platform companies: Flipkart, Zomato, Swiggy, Freshworks, Zoho and Razorpay secure Kubernetes platforms, multi-tenant SaaS data isolation and CI/CD supply chains.
• CSPs and security vendors in India: AWS, Microsoft, Google and Oracle India regions; security roles at Palo Alto, Qualys, Zscaler, CrowdStrike and Indian firms doing cloud audits, VAPT of cloud estates and ISO 27001/27017 readiness.
• Certifications hiring managers look for: AWS Certified Security – Specialty, Azure AZ-500, Google Professional Cloud Security Engineer, CCSP, CCSK and CISA/CISM for GRC-leaning roles.

Interview questions

• Q: Explain the shared responsibility model with an example. A: The CSP secures the infrastructure (data centre, hypervisor, managed-service internals) and the customer secures what it puts in the cloud — data, IAM, configuration and, in IaaS, the guest OS. If an S3 bucket is left public, that is the customer's failure, not AWS's.
• Q: Why are containers considered less isolated than virtual machines? A: All containers on a host share one kernel, so a kernel vulnerability or a privileged container can lead to a breakout; VMs each run their own kernel behind a hypervisor boundary.
• Q: What is a VM escape attack? A: A guest VM exploits a flaw in the hypervisor or virtual device emulation to execute code on the host, after which every co-resident VM is exposed — the most severe class of virtualisation flaw.
• Q: How can SSRF in a cloud-hosted web app lead to account compromise? A: The attacker makes the app fetch the instance metadata endpoint and returns the attached role's temporary credentials, then uses them against the cloud API; requiring IMDSv2's session token (a PUT request returns a short-lived token that every metadata call must then carry) and restricting the role mitigate it.
• Q: Customer-managed keys or provider-managed keys — which and why? A: Customer-managed KMS keys, when you need rotation on your schedule, a key policy you control, revocation (crypto-shredding) and full audit trails; provider-managed keys are simpler but give no independent control.
• Q: Difference between a security group and a network ACL? A: A security group is stateful and attached to an instance/ENI with allow rules only; a NACL is stateless, applies to a whole subnet and supports both allow and deny rules — return traffic must be allowed explicitly.
• Q: What does a CASB do that a firewall cannot? A: It sits between users and SaaS applications to discover shadow-IT usage, apply DLP and access policy per application and action, and detect risky sharing — visibility a network firewall cannot give for encrypted SaaS traffic.
• Q: How do you achieve tenant data isolation in a multi-tenant SaaS product? A: Enforce a tenant identifier in every query path (row-level security or separate schemas/databases), derive per-tenant encryption keys, scope access tokens to a tenant, and test for cross-tenant IDOR in every API.
• Q: What are the CERT-In timelines an Indian cloud customer must meet? A: Report notified cyber incidents within 6 hours of noticing them, retain ICT logs for 180 days within India, and (for cloud/VPS/VPN service providers) keep subscriber KYC and transaction records for 5 years.
• Q: Under the DPDP Act, 2023, who is liable if the cloud provider leaks the data? A: The data fiduciary remains accountable to data principals and the Data Protection Board; the provider acts as a processor under contract, and the fiduciary must have mandated safeguards and breach notification in that contract (DPDP duties enforceable from 13 May 2027; until then IT Act s.43A applies).
• Q: What is zero trust in a cloud context? A: Every request is authenticated, authorised and encrypted regardless of network location, with least-privilege, short-lived credentials and continuous verification of device and identity posture instead of trusting a VPC perimeter.
• Q: Your organisation finds 300 unencrypted volumes across accounts. How do you fix it durably? A: Remediate the existing ones, then prevent recurrence — turn on default encryption at the account level, add an organisation policy/SCP denying unencrypted creation, scan Terraform in CI, and monitor with CSPM so drift is caught, not re-found manually.

Common mistakes

• Believing "the cloud is secure because AWS/Azure is secure" — provider certification does not cover customer configuration, IAM or code.
• Treating the cloud like a data centre: lifting and shifting a VM with the same flat network, long-lived keys and no logging, instead of using cloud-native identity and segmentation.
• Confusing a stateful security group with a stateless NACL, and forgetting the return-traffic rule in exam questions.
• Saying encryption at rest protects against stolen credentials — a valid principal with key access reads the plaintext; encryption defends against media/snapshot theft, not against authorisation failures.
• Hardcoding access keys in code, Git repositories, container images or Postman collections instead of using roles and a secrets manager.
• Equating multi-AZ (high availability within a region) with multi-region disaster recovery, or assuming backups work without ever testing a restore.
• Quoting stale Indian law — citing the 2011 SPDI Rules or a "whitelist" model of data transfer without noting the DPDP Act, 2023 and its phased Rules.

Related topics

Identity and access management · Network security: firewalls, VPN and IDS · IT governance, risk and compliance · Web application security (OWASP Top 10) · Cryptography basics · Security operations: SOC and SIEM