Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
NIST SP 800-145 definitions, IaaS/PaaS/SaaS, hypervisors and containers, shared responsibility, IAM and KMS, with DPDP Act 2023, RBI localisation and MeitY-empanelled CSPs for digital forensic examiners.
A digital forensic examiner who treats the cloud as someone else's computer is going to lose the chain of custody on the first acquisition. The cloud is a stack of agreements, APIs, hypervisors, tenant boundaries and encrypted volumes, each with its own log surface and its own legal cooperation pathway. The same EC2 instance an Indian fintech runs in AWS Mumbai is, at the silicon layer, a slice of an EPYC server shared with three other tenants, controlled by a hypervisor the examiner cannot touch, written to a storage backend the examiner cannot image, and reachable only through a control-plane API that returns what the provider decides to return. this topic expects you to know that stack cold before moving on to the cloud forensics topic.
This topic sets the foundation. NIST SP 800-145 gives the working definition. The five characteristics, the three service models and the four deployment models are the spine the rest of cloud forensics hangs off. Virtualization is the engine: bare-metal hypervisors, hosted hypervisors and containers each leave a different forensic footprint. Cloud security architecture is the constraint surface the examiner inherits: shared responsibility, IAM, KMS, network isolation, multi-tenancy. The Indian frame is loaded on top: RBI data localisation, MeitY empanelment, the DPDP Act 2023 cross-border regime, and MeghRaj for government workloads. The next topic, Cloud Forensics: Multi-Tenant, API and Jurisdictional Challenges, builds the acquisition and analysis playbook on top of this architecture.
The definition that every Indian cloud-policy document quotes back at you.
NIST SP 800-145 published in September 2011 is the reference text. Indian regulatory documents, the MeitY cloud strategy, CERT-In advisories and the Indian working syllabus all use its definition verbatim. The five essential characteristics are the test for whether a service counts as cloud.
On-demand self-service means a consumer can provision compute, storage and network without human interaction with the provider. The customer presses a button on the AWS console and an EC2 instance comes up in 60 seconds. There is no ticket queue and no human in the loop. The forensic implication is that resources can be created and destroyed faster than any seizure workflow can catch up, which is why volatility shapes every cloud acquisition.
Broad network access means the service is reachable over the network through standard protocols by thin and thick clients alike. The same S3 bucket is reachable from a browser, a CLI, a mobile SDK and a server backend. Every access path is a different log surface.
Resource pooling is the multi-tenant property. Provider resources are pooled to serve multiple consumers using a multi-tenant model, with physical and virtual resources dynamically assigned. The customer has no control over the exact location of their data beyond the region or availability zone. The pooling is what enables price efficiency and what causes side-channel concerns.
Rapid elasticity means capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward. Auto-scaling groups, serverless concurrency and Kubernetes horizontal pod autoscalers are the operational expressions. For the examiner, elasticity is why a misbehaving workload may have spun up 40 ephemeral worker pods that all wrote logs and then disappeared before the imaging team arrived.
Measured service is the metering layer. Resource usage is monitored, controlled and reported, providing transparency for both provider and consumer. The bill is itself a forensic artifact, often the only surviving evidence that a particular service was provisioned at a particular time in a compromised account.
Public, private, hybrid, community: what each looks like in practice in India.
NIST defines four deployment models. The Indian regulatory frame layers requirements on each.
Public cloud is operated for open use by the general public, owned by an organisation selling cloud services. The big four with Indian regions are AWS (Mumbai ap-south-1 since 2016, Hyderabad ap-south-2 since 2022), Microsoft Azure (Central India in Pune, South India in Chennai, West India in Mumbai), Google Cloud Platform (Mumbai asia-south1, Delhi asia-south2) and Oracle Cloud Infrastructure (Hyderabad and Mumbai). All four hold MeitY empanelment for government workloads in their Indian regions. The RBI data localisation directive of April 2018 mandates that all payment system data of Indian residents be stored only in India, which is why every payments-adjacent fintech in India runs in one of these India regions and not in a foreign region.
Private cloud is provisioned for exclusive use by a single organisation. The technology stack is typically VMware Cloud Foundation, OpenStack or Red Hat OpenShift. Indian banks running RBI-regulated workloads almost always have a private cloud tier behind the regulator-facing firewall. SBI's Meghdoot infrastructure and HDFC Bank's internal private cloud are public examples. Private cloud preserves the resource-pooling and elasticity properties but eliminates the multi-tenant problem at the cost of capital expense.
Hybrid cloud is a composition of two or more distinct infrastructures (private and public, typically) that remain unique entities but are bound together by standardised or proprietary technology. Indian enterprises run hybrid because regulator-controlled workloads sit in private cloud and customer-facing workloads sit in public cloud, connected via direct-connect circuits. The forensic complication is that an incident may cross the boundary, requiring acquisition from both halves of the hybrid under different cooperation regimes.
Community cloud is provisioned for exclusive use by a specific community of consumers from organisations that have shared concerns. The canonical Indian example is MeghRaj, the GI Cloud, run by NIC with shared cloud infrastructure used by multiple government departments. State Data Centres and the National Data Centres are the physical substrate. Community cloud blends the cost efficiency of pooling with the sovereignty preservation of restricted access.
The customer's responsibility shrinks left to right; the forensic surface shrinks with it.
The three service models are concentric layers of abstraction. Each layer hides what is below it from the customer and from the examiner.
Infrastructure as a Service gives the customer raw virtualised compute, storage and network. The reference examples are Amazon EC2, Google Compute Engine and Azure VM. The customer owns the operating system, the patching, the middleware, the runtime, the application data. The provider owns the hypervisor, the physical host, the storage backend, the physical network. Forensically, IaaS is the most cooperative model because the customer can image the VM disk and capture the memory through provider-blessed snapshot APIs, even if they cannot reach the hypervisor.
Platform as a Service gives the customer a managed runtime. Heroku, Google App Engine, Azure App Service and AWS Lambda are reference examples. The customer brings code and data; the provider manages the operating system, the runtime, the auto-scaling, the load balancing. The forensic surface shrinks to logs, code artifacts, environment variables and database snapshots. The OS layer is invisible.
Software as a Service gives the customer an application. Salesforce, Microsoft 365 and Google Workspace are the global anchors. Zoho One and Freshworks are the Indian-origin SaaS giants. The customer brings only data and configuration; everything else is provider-owned. The forensic surface is whatever the SaaS vendor exposes through admin consoles, audit logs and export APIs.
The substrate underneath every IaaS region, every PaaS runtime and every Kubernetes pod.
Virtualization is the enabling technology for everything above. The forensic examiner is expected to know the two hypervisor classes and the container alternative cold.
Type 1 hypervisors run directly on the hardware. VMware ESXi is the dominant commercial example. Xen powers AWS EC2 first-generation hosts and Citrix XenServer. Microsoft Hyper-V Server is the Windows-shop equivalent. KVM is the Linux kernel module that backs OpenStack, Red Hat Virtualization and most modern cloud providers including the Nitro-era AWS hosts that moved past Xen. Type 1 is what cloud providers run because it has no host OS overhead and the attack surface is smaller. The examiner working a private cloud case typically has a vSphere admin who can export VM disks as VMDK and memory as VMSS or VMSN snapshots.
Type 2 hypervisors run on top of a host operating system. VirtualBox, VMware Workstation and Parallels are the desktop reference examples. They are the standard for academic labs, NFSU practical sessions and individual examiner workstations. The forensic relevance is twofold: type 2 VMs are common on suspect endpoints (analysts run them, criminals use them as disposable workstations), and the examiner's own analysis VMs run on type 2 hypervisors. The VMDK and OVA artifacts left behind on the host by type 2 VMs are the subject of Virtual Machine and Cloud-Backed Endpoint Forensics.
Containers are the third path. Docker is the developer-facing toolchain; containerd and runc are the lower-level runtimes; Kubernetes is the orchestration layer. Containers share the host kernel rather than virtualising hardware, which is why they are lighter than VMs. In Indian deployment, AWS EKS in Mumbai, Azure AKS in Pune and Google GKE are the standard managed Kubernetes paths. The forensic surface of a container is fundamentally different from a VM: there is no virtual disk image, only layered overlay filesystems plus a running process namespace. Acquisition is a docker commit plus a docker export, or a kubectl debug ephemeral container, or a node-level disk capture if the kernel is compromised.
| Property |
|---|
Side-channel attacks meet the DPDP Act 2023.
Multi-tenant data isolation is the Achilles heel of public cloud. The same physical server runs VMs from multiple customers, separated by the hypervisor's memory and CPU isolation. Most of the time the separation holds. The exceptions are the side-channel research class of attacks, of which Spectre (CVE-2017-5753 and CVE-2017-5715) and Meltdown (CVE-2017-5754) are the canonical examples. Disclosed in January 2018, both exploit speculative execution to read memory across the user-kernel boundary and, with extensions, across VM boundaries on shared hosts. AWS, Azure and GCP all patched at the hypervisor layer within weeks. Subsequent variants (Foreshadow, ZombieLoad, RIDL, MDS) continued the pattern through 2019. The forensic significance is that a side-channel exploit leaves almost no evidence in the customer's VM, because the data extraction happened from the attacker's VM by reading shared physical memory the hypervisor was supposed to isolate.
The Indian sovereignty frame layers regulatory constraints on multi-tenancy. The provider-side details of capturing snapshot, log and memory state from these multi-tenant environments are covered in Cloud Logging, VM Snapshots and Cloud Incident Response. The DPDP Act 2023 (Digital Personal Data Protection Act, notified November 2023, rules pending as of mid-2026) governs the processing of personal data of Indian residents. Section 16 provides the central government with the authority to restrict cross-border transfer of personal data to specified countries. The practical posture for any India-facing service is that personal data must be processable in an Indian cloud region by an empanelled or contracted provider, with a contractual data residency clause naming the region.
The RBI directive of 6 April 2018 is older and stricter for its narrower scope. All payment system data, including end-to-end transaction details, must be stored only in India. The directive was issued to all System Providers regulated under the Payment and Settlement Systems Act 2007. Compliance is verified through annual System Audit Reports submitted to RBI. The forensic implication is that a payments-related cloud incident must have all relevant logs available in Indian regions, with no cross-border log replication permitted for the in-scope data.
MeitY empanelment is the procurement-side control. The MeitY empanelment framework certifies CSPs whose Indian regions are fit for use by central and state government entities. AWS, Azure, GCP and Oracle have all secured empanelment for their Indian regions through audited compliance with the empanelment standards. For a government cloud workload, only an empanelled provider is permitted. MeghRaj is the Government of India's own cloud initiative, run by NIC under the GI Cloud framework, providing community cloud services to government departments through the National Data Centres at Delhi, Pune, Hyderabad and Bhubaneswar.
Which set is the five essential characteristics of cloud computing as defined in NIST SP 800-145?
| Model | Tenancy | Indian example | RBI/DPDP fit |
|---|
| Public | Multi-tenant on shared hardware | AWS Mumbai ap-south-1, Azure Pune | Fit if data stays in Indian region and contract enforces sovereignty |
| Private | Single tenant, dedicated hardware | SBI Meghdoot, HDFC internal | Strongest sovereignty posture, full control of audit logs |
| Hybrid | Mixed, with boundary controls | Public-sector bank with private regulator tier plus public customer tier | Requires careful data classification at the boundary |
| Community | Multi-tenant within named consortium | MeghRaj, GSTN cloud | Designed for sectoral or government sovereignty needs |
The Indian implication is that the forensic team has to know the model before they know what they can ask for. A Zoho CRM data theft investigation is a SaaS case, where the only acquisition surface is the Zoho audit log export and the admin console history. An EC2-on-Mumbai compromise is an IaaS case, where the team can snapshot the EBS volume and capture memory through SSM-driven volatility. The cooperation envelope is different and the BSA 2023 Section 63 certificate has to reflect what the team actually had access to.
| Type 1 hypervisor |
|---|
| Type 2 hypervisor |
|---|
| Container |
|---|
| Runs on | Bare metal | Host OS | Host OS kernel |
| Isolation boundary | Hardware-assisted virtualization | OS process plus hypervisor | Linux namespaces and cgroups |
| Examples | VMware ESXi, Xen, KVM, Hyper-V Server | VirtualBox, VMware Workstation, Parallels | Docker, containerd, runc |
| Forensic capture | VMDK or VMSN through admin API | Suspend file or live image of guest | Image export plus running process inspection |
| Indian use | Private cloud, AWS Mumbai Nitro hosts | Examiner workstations, NFSU labs | EKS Mumbai, AKS India, GKE asia-south1 |
The deployment infrastructure on top of these substrates is the CI/CD and IaC layer. Terraform, AWS CloudFormation and Pulumi are the standard infrastructure-as-code tools. Auto-scaling groups, load balancers (AWS ALB, Azure Application Gateway, GCP Cloud Load Balancing) and service meshes (Istio, Linkerd) tie the pieces together. From a forensic standpoint, the IaC repository is itself an evidence source. The Terraform state file names every resource that should exist; any drift between state and live is a tampering signal.
The DPDP cross-border posture interacts directly with the cloud forensics workflow described in the companion topic Cloud Forensics: Multi-Tenant, API and Jurisdictional Challenges. When an Indian incident requires logs that the provider holds in a US or EU region (for global services like Microsoft 365 audit logs or Salesforce event monitoring), the conflict of laws between the US CLOUD Act and Indian sovereignty surfaces immediately. The MLAT pathway exists but is slow. The pragmatic answer most Indian DPOs settle on is contractual: name an Indian processing region in the data processing agreement, and require the provider to make logs locally available on request without cross-border egress.