4.5 Cloud, Container, IoT, Edge, and Shared Responsibility Architecture

Architecture When Infrastructure Is Distributed

Cloud, container, IoT, and edge architectures change who operates components, but they do not remove accountability for risk. The organization still owns data classification, access decisions, legal obligations, vendor governance, incident response expectations, and residual risk. A shared platform can be secure only when responsibilities are explicit.

Shared responsibility depends on the service model. In infrastructure as a service, the provider manages facilities, hardware, and core virtualization while the customer usually manages operating systems, applications, identities, data, and many network controls. In platform as a service, the provider manages more of the runtime. In software as a service, the customer still manages data use, identities, configuration, monitoring, and contractual risk.

Do not rely on generic shared responsibility diagrams alone. Translate them into a control responsibility matrix for the actual services in use. Storage encryption, backup retention, key ownership, logging, vulnerability management, endpoint access, administrator roles, data residency, and incident notification may vary by service and contract.

Cloud architecture risk often starts with identity. Overprivileged roles, long-lived access keys, broad service principals, weak federation settings, and unmanaged break-glass accounts can defeat otherwise strong controls. Cloud security architecture should favor least privilege, short-lived credentials, conditional access, separation of duties, and monitoring of administrative actions.

The management plane is a critical trust boundary. It can create networks, disable security controls, read snapshots, change keys, and alter logging. Treat it like production infrastructure, not a convenience console. Require strong authentication, privileged access governance, change control, alerting, and restrictions on where administrative actions can originate.

Storage exposure is another common failure mode. Public object storage, overly broad bucket policies, permissive snapshots, unmanaged sharing links, and weak data lifecycle rules can expose sensitive information. Encryption helps, but access policy, inventory, data classification, monitoring, and deletion rules determine whether storage is truly governed.

Containers introduce a different set of assumptions. A container image packages application dependencies, but it is not a full security boundary by itself. Host kernel sharing, privileged containers, mounted secrets, weak runtime profiles, and vulnerable base images can increase risk. Container security requires controls from build through runtime.

A container control baseline should include trusted base images, image scanning, signed images, minimal packages, non-root execution, read-only filesystems where practical, network policies, secrets outside images, admission control, runtime monitoring, and controlled access to the orchestrator API. The orchestrator is a high-value management plane and deserves strong protection.

Kubernetes and similar platforms require governance. Namespaces do not automatically create hard multitenancy. Role-based access, admission policies, pod security settings, network policy, secret management, audit logging, and cluster upgrade practices determine whether workload isolation is credible. For highly sensitive workloads, dedicated clusters or stronger isolation may be justified.

IoT and edge environments add physical and lifecycle concerns. Devices may be deployed in public, industrial, clinical, retail, or remote locations where attackers can touch hardware. They may have constrained CPU, memory, storage, and battery capacity, limiting traditional endpoint controls. They may also remain in service for years after vendors stop providing updates.

For IoT, secure architecture includes device identity, secure boot, signed firmware, update mechanisms, encrypted communication, least privilege service accounts, network segmentation, telemetry monitoring, and decommissioning procedures. Safety impact matters. A compromised sensor is different from a compromised actuator that can affect people, equipment, or critical operations.

Edge computing pushes processing closer to data sources. This can reduce latency and bandwidth, but it distributes sensitive computation across many sites. Architects should consider local data minimization, tamper resistance, offline behavior, central policy management, secure synchronization, and procedures for lost or replaced devices.

Use this shared responsibility review workflow:

1. Inventory the service, data, identities, regions, integrations, and administrators.
2. Map each control to provider, customer, or shared ownership.
3. Identify inherited trust, management plane privileges, and default configurations.
4. Define logging, monitoring, incident notification, and evidence retention.
5. Test misconfiguration, credential loss, service outage, and recovery scenarios.
6. Record residual risks, exceptions, and business owners.

The managerial goal is clarity. Cloud and edge failures often happen when everyone assumes someone else owns the control. A defensible architecture states who configures it, who monitors it, who pays for it, who approves exceptions, and who acts when it fails.