Cloud Computing Foundations · Study deck
Cloud Security Fundamentals
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.
Cloud Clara is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Split security responsibility across network, host, and application levels, and across IaaS, PaaS, and SaaS
- Name the cloud threat categories a shared-infrastructure model introduces
- Distinguish data-in-transit from data-at-rest protection and place other data-security aspects around them
- Define identity and access management and describe cloud access-control layers, trust models, and authentication
Major section
Shared Responsibility, Threat Categories, and Security Levels
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.
- In a public cloud, a small change can severely affect the network topology, so proper access control over resource use matters directly.
- Under PaaS and SaaS, the host operating system is hidden from end users and host-security responsibility transfers to the provider.
- Both the cloud service provider and the customer share responsibility here, and exactly how it splits depends on the service model chosen.
Major section
Under the Hood: Identity, Trust, and Risk Assessment
User authentication is where identity, trust, and risk all meet the point of daily use.
- 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").
- During authentication, the process's own safety properties can be invaded by attack, causing severe damage.
- User authentication is done at the PaaS layer.
Major section
Under the Hood: Identity, Trust, and Risk Assessment (continued)
A threat to the authentication process can lead to confidential data being disclosed to a fake, unauthorized user.
- 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.
- IAM answers "who can do what," but a customer still has to decide which provider to trust with that job in the first place.
- 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.
Major section
Current Shared-Responsibility Boundary Check
The contract and the exact service must confirm every row.
- The service-model rule is responsibility transfer, not responsibility disappearance.
- In PaaS the provider also operates more of the runtime, while the customer still owns application behaviour, identities, secrets, data purpose, and many configuration decisions.
- An encrypted database can still leak through an API.
Deck summary
Key takeaways
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.
- User authentication is where identity, trust, and risk all meet the point of daily use.
- A threat to the authentication process can lead to confidential data being disclosed to a fake, unauthorized user.
- The contract and the exact service must confirm every row.
Retrieval practice
Recall check 1 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q1A company runs its email and office-productivity tools entirely through a SaaS product it does not operate any infrastructure for. Per the application-level responsibility split this chapter describes, who is responsible for securing the application itself?
Show answer
Answer: A The application-level responsibility split names three different owners by service model: SaaS providers own the whole application; PaaS providers own the platform plus deployed customer applications; IaaS providers own neither, leaving the customer to arrange application-level security themselves.
Retrieval practice
Recall check 2 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q2A team confirms that their cloud storage bucket encrypts every record while it sits in storage, and concludes their data is fully protected. What gap does this chapter's data-security-by-state framing identify in that conclusion?
Show answer
Answer: A Data-in-transit and data-at-rest are two separate, named aspects of data security; confirming protection for one does not confirm protection for the other, which is exactly the gap in a team that checked only storage-side encryption.
Retrieval practice
Recall check 3 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q3Per the What/When/Where/Consequence framing of cloud user authentication, at which layer does authentication happen, and what specifically is put at risk if the process is compromised?
Show answer
Answer: A The source's own four-part authentication framework is specific, not generic: authentication is placed at the PaaS layer, and a compromised process risks disclosing confidential data to a fake, unauthorized user.
Print reference
Answers 1 of 2
Answer key.
- A · The application-level responsibility split names three different owners by service model: SaaS providers own the whole application; PaaS providers own the platform plus deployed customer applications; IaaS providers own neither, leaving the customer to arrange application-level security themselves.
- A · Data-in-transit and data-at-rest are two separate, named aspects of data security; confirming protection for one does not confirm protection for the other, which is exactly the gap in a team that checked only storage-side encryption.
Print reference
Answers 2 of 2
Answer key.
- A · The source's own four-part authentication framework is specific, not generic: authentication is placed at the PaaS layer, and a compromised process risks disclosing confidential data to a fake, unauthorized user.