7 Cloud Security Fundamentals
7.1 Start With a Different Question Than the Applied Security Chapter Asks
This module’s platforms chapter closed on a one-line fact worth expanding into a whole chapter: open-source clouds put security implementation on the user, commercial clouds put it on the provider. That line is a shared-responsibility claim, and this chapter builds the generic version of it in full – who is responsible for what, at which layer, and what categories of threat and protection a shared-infrastructure model introduces in the first place.
Not the same chapter as the applied security chapter. Cloud Security for IoT covers device identity lifecycles, least-privilege message permissions differentiated by device role, and an IoT-specific incident-response sequence – it assumes you already know what “shared responsibility,” a threat category, or identity and access management generically mean, then applies them to a fleet of physical devices, gateways, and operators. This chapter builds that generic foundation instead: cloud security 101 as a computing-systems topic, with no device, gateway, or fleet in the picture yet. Read this chapter first if the underlying security vocabulary is not yet solid, then read that one to turn it into an IoT device-boundary decision.
7.2 Shared Responsibility, Threat Categories, and Security Levels
Moving data and computation onto shared, provider-owned infrastructure is a specific trade: a user gives up direct control over the physical and much of the logical infrastructure, in exchange for the elasticity and cost model the rest of this module has already covered. The source material’s own framing of what that trade puts at risk names four concerns: loss of data, account seizing, service traffic hindrance, and vulnerable APIs (D. Velev and P. Zlateva, “Cloud infrastructure security,” in Open Research Problems in Network Security, J. Camenisch, V. Kisimov, M. Dubovitskaya, Eds., Springer, 2011, pp. 140-148). The response to that risk is not one control – it is a set of secure policies that protect against theft, leakage, and deletion, applied at the right layer.
“The right layer” is itself a named framework. Cloud infrastructure security must be implicitly assured for public or private cloud alike, and for every service model – SaaS, PaaS, and IaaS – and the source material organizes that assurance into three building levels: network-level security, host-level security, and application-level security.
Network Level
In a public cloud, a small change can severely affect the network topology, so proper access control over resource use matters directly. The named goals: confidentiality and integrity of data-in-transit to and from the provider, and availability of internet resources, correctly, to genuine users.
Host Level
Under PaaS and SaaS, the host operating system is hidden from end users and host-security responsibility transfers to the provider. Under IaaS, the primary objective shifts to securing the allocated hosts directly – the source material’s own named threat example is a Blue Pill-class attack against the hypervisor itself, moving a running guest OS into a virtualized state without its knowledge.
Application Level
Both the cloud service provider and the customer share responsibility here, and exactly how it splits depends on the service model chosen.
That application-level split is the clearest, single, generic statement of shared responsibility in the whole source deck, and it is worth stating on its own:
SaaS Providers
Own security of the deliverable application itself, end to end.
PaaS Providers
Own security of the PaaS platform, plus the customer’s deployed applications running on it.
IaaS Providers
Do not provide application-level security at all – the customer arranges their own security mechanism at that layer.
Read those three cards next to the network/host/application table above and a pattern emerges that holds across every layer, not just the application one: the more of the stack a provider manages (moving from IaaS toward SaaS), the more of the security burden moves with it. That single relationship – more managed stack, more managed security – is the generic shared-responsibility model this chapter set out to build, and it is the same relationship this module’s second chapter already drew for functionality rather than security, using the exact same responsibility bracket.
7.3 Data Security by State, and Access Control Layers
Data security is a lifecycle problem with three named objectives – confidentiality, integrity, and availability – addressed through three named solution categories: identity management, encryption, and access control (L. Grandinetti, O. Pisacane, M. Sheikhalishahi, “Cloud Security,” in Pervasive Cloud Computing Technologies: Future Outlooks and Interdisciplinary Perspectives, IGI Global, 2013). Underneath those objectives and solutions, the source material names six specific aspects data security has to account for, and two of them are the ones this chapter is specifically scoped to own:
Data in Transit
Protecting data while it moves across the network – the same confidentiality-and-integrity goal the network-level security section above already named for data crossing to and from the provider.
Data at Rest
Protecting data while it is stored – a separate control from data-in-transit protection, not a substitute for it. Data can be fully encrypted at rest and still cross the network to reach that storage completely unprotected, or the reverse.
Multitenancy, Lineage, Remanence, Provenance
Four further named aspects rounding out the same hexagon: data sharing infrastructure with other tenants, the traceable history of how data moved and transformed, residual data left behind after deletion, and verifiable origin of the data itself.
In-transit and at-rest are two separate checks, not one. The most common data-security gap this hexagon exposes is treating “the data is encrypted” as a single fact rather than two separate, independently-verifiable claims: is it encrypted while stored, and is it separately encrypted while moving across the network to get there? A design can pass one check and silently fail the other.
Data protection does not happen in isolation from who is allowed to reach the data in the first place. The source material names six access-control layers spanning the whole cloud stack, each independently managed by either the provider or the consumer depending on the deployment model chosen:
Cloud Access
Server Access
Service Access
Database Access
Both direct access and access mediated through web-service queries.
VM Access
Access to Objects Within a VM
Notice that this six-layer list is not one control – it is six separate checkpoints, and a system can be well-secured at one layer (cloud-account access, say) while being wide open at another (objects inside a running VM). Just as with the in-transit/at-rest pairing above, treating “access control” as a single fact rather than six separate, independently-verifiable ones is the recurring gap this chapter’s whole practitioner layer is built to close.
7.4 Under the Hood: Identity, Trust, and Risk Assessment
Identity and Access Management (IAM) is the branch of cloud security that lets the legitimate person retrieve the legitimate resource at the legitimate time for the legitimate reason (source: Wikipedia, “Identity Management”). User identities and access permissions are instigated, tracked, administered, and recorded by IAM; authentication, authorization, and evaluation of every user run against a defined set of terms, conditions, and roles. Its own named features:
Single Access-Control Interface
Increased Security
Resource-Level Access Control
Improved Operational Efficiency
Improved Regulatory Compliance Management
IAM answers “who can do what,” but a customer still has to decide which provider to trust with that job in the first place. The source material names two related concepts for that decision: trust, an independent expectancy between two entities for a specific context at a given time, and reputation, an entity’s standing as believed by the wider community (Z. Raghebi, M. R. Hashemi, “A New Trust Evaluation Method based on Reliability of Customer Feedback for Cloud Computing,” Information Security and Cryptology Conf., 2013; S. M. Habib, S. Hauke, S. Ries, M. Muhlhauser, “Trust as a facilitator in cloud computing: a survey,” Journal of Cloud Computing, 1(1), 2012). Trust gets established through named modes: accomplishing a Service Level Agreement, applying recognized audit standards, measuring and rating a provider’s track record, and self-assessment questionnaires.
Once a provider is chosen, the remaining question is how much risk the arrangement carries, and the source material names four ways to categorize a risk-assessment methodology: formal versus informal procedures, qualitative (high/moderate/low) versus quantitative (numeric) techniques, consequence versus cause analysis, and inductive versus deductive techniques (E. Cayirci, A. Garaga, A. S. De Oliveira, Y. Roudier, “A Cloud Adoption Risk Assessment Model,” IEEE/ACM UCC, London, 2014). None of the four is presented as strictly better – they are four independent axes for describing how an assessment was done, which matters when comparing two different risk assessments against each other.
User authentication is where identity, trust, and risk all meet the point of daily use. The source material frames it with a four-part What/When/Where/Consequence structure (H. Chang, E. Choi, “User authentication in cloud computing,” Proc. UCMA CCIS, 151:338-342, 2011):
Placing that framework next to everything earlier in this chapter closes the loop: the network/host/application levels named where a threat can land, the data hexagon named what state data can be caught in, and this four-part authentication frame names the single choke point – one process, at one layer, whose compromise puts the confidentiality of everything behind it at risk. Every named threat, control, and layer in this chapter ultimately routes back to whether that one process can be trusted at the moment it runs.
7.5 Summary
Cloud security starts from a shared-responsibility trade: moving to shared infrastructure introduces named threat categories (data loss, account seizing, service-traffic hindrance, vulnerable APIs) and requires assurance at three levels – network, host, and application – with the application level’s own SaaS/PaaS/IaaS split making the shared-responsibility pattern explicit (more managed stack, more managed security). Data security is a lifecycle of six named aspects built around three objectives (confidentiality, integrity, availability); data-in-transit and data-at-rest are two of those aspects and must be verified separately, never assumed from each other. Access control spans six independent layers from cloud-account access down to objects inside a running VM. Underneath all of that, Identity and Access Management governs who reaches what, trust and reputation govern which provider to rely on, risk-assessment methodology governs how that reliance gets measured, and a four-part What/When/Where/Consequence framework places the sharpest single point of failure at cloud user authentication itself.
7.6 Key Takeaway
Shared responsibility is not one fact – it is a set of independently-verifiable splits: which security level (network/host/application), which service model (IaaS/PaaS/SaaS), and which data state (in transit or at rest). Confirming one split proves nothing about the others; check each one on its own terms before calling a cloud deployment secure.
7.7 See Also
Cloud Platforms: Open-Source and Commercial
The previous chapter in this module: the open-source-vs-commercial “who implements security” line this chapter’s shared-responsibility model generalizes in full.
Deployment Models and Virtualization
The deployment-model and virtualization foundation this chapter’s host-level and hypervisor-adjacent security concerns build on.
The applied companion chapter: turns this chapter’s generic shared-responsibility, threat-category, and identity foundations into a per-device identity lifecycle, least-privilege message policy, and incident-response sequence for an IoT fleet.