Cloud Technology, Virtualization and Cloud Security Architecture

NIST SP 800-145 published in September 2011 is the reference text. Indian regulatory documents, the MeitY cloud strategy and CERT-In advisories 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. A customer can launch an EC2 instance through the AWS console in under a minute, with no ticket queue. 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 both thin and thick clients. The same S3 bucket is reachable from a browser, a CLI, a mobile SDK, and a server backend, each access path producing a distinct 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. Pooling is what enables price efficiency and is the source of side-channel exposure.

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 usage bill is itself a forensic artifact and sometimes the only surviving record that a particular service was provisioned at a specific time in a compromised account.

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 three service models are layers of abstraction. Each layer hides what is below it from both the customer and 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 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.

Virtualization is the enabling technology underlying every cloud service model. The forensic examiner must understand both hypervisor classes and the container alternative.

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 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 differs 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.

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 shared responsibility model defines the security boundary established when a customer contracts with a cloud provider. AWS articulates it as security "of" the cloud (provider) versus security "in" the cloud (customer). The provider is responsible for the physical security of the data centre, the host operating system, the hypervisor, the physical network and the foundational services. The customer is responsible for the guest operating system, network and firewall configuration, identity and access management, application security, and data encryption. The exact boundary shifts as you move from IaaS to PaaS to SaaS, and the forensic team must know where it sits for any given service.

Identity and Access Management is the customer's first line of control and the examiner's first source of evidence. IAM in AWS, Azure AD (now Entra ID) and GCP IAM all share the same conceptual pieces: principals (users, groups, roles, service accounts), policies (allow or deny statements against actions and resources), and conditions (IP, time, MFA state). SAML and OIDC federation links the cloud IAM to an enterprise identity provider, typically Okta, Microsoft Entra or Google Workspace. Conditional access (Azure AD term) or context-aware access (Google term) layers risk-based rules on top. For the examiner, the principal-to-action audit trail is what reconstructs the actor in an incident. IAM Access Analyzer and IAM Credential Report are the AWS pieces that surface drift.

Encryption is the second pillar. Encryption at rest is handled by KMS-managed keys: AWS KMS, Azure Key Vault, Google Cloud KMS. The default option is provider-managed keys (the provider holds the master key entirely). BYOK lets the customer supply the master key material that the provider's KMS then wraps. HYOK keeps the master key entirely in customer infrastructure, with the cloud workload calling out to decrypt. For an Indian fintech bound by RBI's IT framework, KMS-managed keys with customer-supplied master material is the typical posture. Encryption in transit is TLS 1.2 or 1.3 between every pair of services, terminated either at the load balancer or end-to-end at the workload.

Network security in the cloud is the third pillar. AWS uses VPC (Virtual Private Cloud) as the network boundary, security groups as the stateful per-instance firewall, NACLs as the stateless subnet-level firewall, and AWS Network Firewall plus AWS WAF for deeper inspection. Azure mirrors this with VNet, NSGs and Azure Firewall. GCP mirrors with VPC and firewall rules. The shared theme is software-defined network policy, applied at the hypervisor by the provider, audited by the customer through the API.

Multi-tenant data isolation is the principal security exposure 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, enacted August 2023 with Presidential assent on 11 August 2023, commencement notified November 2025, 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.

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.