Cloud Technology, Virtualization and Cloud Security Architecture

NIST SP 800-145 describes five cloud characteristics: self-service provisioning, network availability, pooled resources, elastic capacity and metered use. These ideas help explain operational behaviour; they do not promise instant provisioning or complete logs.

Automation can create, alter or delete resources quickly. Preserve resource identifiers, account/project context and relevant API events before relying on a current inventory to describe the past.

Network access can occur through consoles, command-line tools, SDKs and application services. Logging depends on the actual path and configuration; not every read through every interface is retained.

Pooling and elasticity do not establish the exact physical co-tenants of a workload. Dedicated hosts, bare-metal resources and managed services change the isolation and access model.

Metering and billing can corroborate resource use or cost, but aggregates are not a complete activity or compromise timeline. High availability and automatic backup are separate capabilities, not guaranteed by the cloud label.

Public cloud serves broadly available consumers; private cloud is dedicated to one organisation; community cloud serves organisations with shared concerns; hybrid arrangements link distinct cloud infrastructures. Deployment labels do not decide who may collect evidence.

A region, availability zone, data centre and physical host are different concepts. Service placement, replication, backups, metadata and support access can have different locations. Verify the actual service documentation and configuration.

Private cloud can retain internal tenants and shared resources. It does not eliminate every isolation risk or guarantee full audit access. Public cloud can also provide dedicated infrastructure options.

Hybrid incidents can cross on-premises, provider, identity and SaaS boundaries. Map the source and collection method for each component rather than expect one administrator or API to cover all of them.

Data residency, sovereignty, contractual commitments and legal disclosure are related but distinct. Requirements vary by jurisdiction, sector and data class; choosing a regional endpoint alone does not certify compliance.

Service models describe the abstraction offered to the customer. The actual product can combine features and shift individual responsibilities, so use the current service-specific agreement and controls.

IaaS may permit volume snapshots and authorised guest-memory acquisition, but a disk snapshot is not a RAM capture. Some volatile or provider-internal evidence may be inaccessible through ordinary tenant APIs.

PaaS and SaaS can offer useful audit, version and export data under their retention and licence settings. Endpoint caches, user exports and integrated identity logs can supplement provider sources; an admin console is not the only possible evidence.

Customer management responsibility is not equivalent to unlimited collection authority or legal ownership of every record. Multi-user data, provider terms and investigation scope still need assessment.

Hardware virtualisation and containers enable many cloud services, but cloud definitions do not require every offering to use one universal hypervisor or runtime. Bare-metal and service-specific designs also exist.

Type 1 and Type 2 are useful teaching categories for hypervisors, but real stacks include privileged components and host services. Do not infer zero OS overhead, guaranteed stronger security or a standard memory-export capability from the label.

VM acquisition can require virtual disks, configuration, dependencies and optional memory/saved state. Capture options and permissions determine consistency and available information.

Containers commonly share a host kernel while combining image layers, writable state, configuration, volumes and logs. Runtime and managed execution modes alter where those sources live.

An image commit or filesystem export does not preserve every mounted volume, process memory or orchestrator record. Debugging containers and snapshots change state; record the chosen method and effect.

Infrastructure-as-code repositories, deployment histories and state files can support reconstruction. A difference between declared and live state may reflect approved manual change, failed deployment or stale state as well as tampering. Preserve versions and audit evidence.

Shared responsibility varies by service: a customer-managed VM, managed database and SaaS tenant offer different operational control. Document who can enable logs, preserve data and supply relevant records.

IAM associates principals, policies, resources and conditions. Federated identities and temporary roles can create multi-step relationships between an original identity and a recorded service action. Preserve role/session and token context.

Audit logs generally record an authenticated principal or session under their schema, not automatically a human actor. Compromised tokens, service automation and delegated access are important alternatives.

Encryption at rest can use provider-owned, provider-managed, customer-managed, imported or external key arrangements. “Customer-managed” often describes lifecycle and policy control within a provider KMS; it does not inherently mean the provider stores no key material or cannot perform authorised cryptographic operations.

External key stores and client-side encryption create different dependencies. Assess the actual cryptographic boundary, available key service and policy, rather than draw a provider-disclosure conclusion from BYOK or HYOK terminology.

Preserve ciphertext, key identifiers, relevant policies, grants and audit records. Avoid disabling or deleting key material needed for evidence. Storage permissions and key-use permissions can both affect whether an examiner obtains plaintext.

Network policies, security groups, routes, gateways and application controls provide different boundaries. They are not identical across AWS, Azure and Google Cloud; inspect actual enforcement and logging instead of treating product names as interchangeable.

Multi-tenancy creates isolation and privacy considerations, but is not by itself evidence of compromise. Identity misuse, application flaws and configuration errors can matter independently of hardware co-residency.

Side-channel research demonstrates particular leakage conditions. A generic mention of Spectre or Meltdown does not prove cross-VM theft in an incident. Hardware, mitigations, access and specific evidence must support the claim.

Customer access normally excludes other tenants and much provider-internal infrastructure. Use scoped collection and provider cooperation where needed; a physical-host image can include data outside authority.

Legal requirements may depend on investigating authority, service provider, subject location, sector, data type and where relevant systems or keys are controlled. A region choice does not settle all those questions.

Use a provider/data-location map, preservation request or supported customer export as appropriate. Cross-border production and transfer rules vary by jurisdiction; obtain a specific assessment before claiming a conflict or universal local-storage duty.

The acquisition workflow is developed in Cloud Forensics. Keep named national rules in the legal-framework material and clearly scope any example.