7 Cloud Security Fundamentals

7.1 Why Cloud Security Is Shared

A cloud provider runs some of the system you use, but you still make choices that affect its safety. A provider may guard a data center while your team decides who can read a storage bucket. A locked data center will not fix a bucket open to everyone. The contract and service settings define each party’s duties. This chapter builds the core ideas behind that split. For an IoT example, see Cloud Security for IoT.

7.2 Shared Responsibility, Threat Categories, and Security Levels

An application programming interface (API) lets software ask another service for data or actions. Cloud users face data loss, stolen accounts, blocked service traffic, and flaws in these interfaces. An attacker might steal a login and use an API to copy records. Defenses need to cover the network, hosts, and applications. A control at one level does not prove that the others are safe.

At the network level, teams limit access and protect data as it travels. They also work to keep the service available to real users. At the host level, they patch and secure systems that run workloads. The provider usually manages the host in PaaS and SaaS. In IaaS, the customer normally manages the guest operating system, while the provider manages the physical host and hypervisor. A hypervisor flaw can threaten the separation of guests, so the provider’s host controls still matter.

At the application level, the split changes with the service model. In IaaS, the customer builds and secures its app. In PaaS, the provider runs the platform, while the customer secures its code, data, access, and settings. In SaaS, the provider runs the app, but the customer still controls users, tenant settings, data use, and integrations. Check the contract and service documentation for the exact boundary.

The move to shared infrastructure transfers some duties to the provider, but leaves customers responsible for their configuration, identities, workloads, and data. The exact split depends on the service and contract, so request provider evidence and retain records of your own controls.

Some security terms in the table have specific meanings. Key rotation means replacing the key used to lock or unlock encrypted data on a planned schedule or after a suspected exposure. A scoped token is a software credential limited to particular resources or actions. A runbook is a written set of steps for handling a known operational event. Rollback means returning a system or configuration to its earlier working state after a change causes a problem.

For example, a team uses a hosted app to store client records. The vendor patches the app, but the team grants access to staff. If a former staff member can still sign in, the vendor’s patch does not close that gap. The team needs a process to revoke access and check the audit log.

7.3 Data Security by State, and Access Control Layers

Data security seeks three goals. Confidentiality means only allowed parties can read data. Integrity means data is correct and changes are authorized. Availability means those who need the data can reach it when needed. Encryption, identity checks, access rules, and backups help meet these goals together.

Data in transit moves over a network. A secure transport connection can protect it on the way to a cloud service. Data at rest sits on storage, where encryption can limit exposure if a disk or backup is lost. Check both: an encrypted disk does not protect a plain network transfer. Also consider data in use, when a program may need to process plaintext. Limit who can run that program and what they can inspect.

Other data concerns include multitenancy, where tenants share infrastructure; lineage, the record of how data moved and changed; remanence, traces left after deletion; and provenance, evidence of where data came from. Ask how a provider separates tenants, tracks data, and deletes copies, including backups.

Access rules need checks at more than one layer. A team can restrict the cloud account, server, service, database, virtual machine, and objects inside that machine. A private cloud account does not help if a public app gives anyone an unrestricted database query. Trace a real user’s path through each layer and grant only the actions needed for the job.

7.4 Under the Hood: Identity, Trust, and Risk Assessment

Identity and access management (IAM) helps a system decide who may do what. Authentication checks an identity, such as a person signing in with a password and a second factor. Authorization then checks which actions that identity may take. A valid login alone should not grant access to every resource. IAM can centralize these rules, record activity, and help teams review access.

Imagine an analyst who needs to read one report. Give the analyst a role that can read that report, rather than a role that can alter all records. Review the role when the job changes and remove it when the person leaves. Logs help the team check whether the role was used as intended.

Trust is an expectation that another party will act as agreed in a given setting. Reputation is what a wider group believes about that party. A provider’s track record, audit reports, answers to security questions, and service level agreement can all inform trust. None alone proves that the customer’s own setup is safe.

A risk assessment asks what can go wrong, how likely it is, and what harm may follow. Teams can use a formal or informal process, rate risk in words or numbers, and start from either causes or consequences. They can reason from a possible failure to its effects, or start with a feared outcome and trace its causes. State the method and assumptions so others can judge the result.

One cited authentication framework asks what happens, when an attack can occur, where the process sits, and what follows. Its example places a new user’s login at the PaaS layer. If an attacker compromises that process, a fake user may receive private data. This is an example, not a rule that login occurs only in PaaS: all cloud service models need identity checks.

7.5 Check the Boundary in Practice

Before putting a service into use, name an owner for each control and keep evidence that it works. Start with the provider’s published duties and the contract, then map your team’s settings and tests to them. Ask who detects a fault, who acts, and how the two teams will communicate. An access token is a credential software presents to request access. Its scope limits which resources and actions it permits; give each token only the access its task needs.

Test the whole path. A team might encrypt its database yet expose records through an app API. It might also have backups but lack the keys or access needed to restore them. Run a restore test, check the result, and record how long it took. Rehearse a lost credential and agree how to revoke it and notify the provider. A certificate or audit report can inform the decision, but it cannot replace these tests.

7.6 Summary

Cloud security is shared across the provider and customer. The split depends on the service and contract. Protect the network, hosts, and apps; check data in transit, at rest, and in use; and control access at each layer. IAM links identities to allowed actions. Provider evidence and practical tests help a team assess trust and risk.

7.7 Key Takeaway

Name the owner of each control, then test it.

7.8 See Also

Continue with Cloud Platforms: Open-Source and Commercial, Deployment Models and Virtualization, or Cloud Security for IoT.