Cloud Computing Foundations · Study deck
Cloud Security Fundamentals
The platforms chapter showed that security is shared in both self-hosted open-source and commercial clouds.
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
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.
- IAM answers "who can do what," but a customer still has to decide which provider to trust with that job in the first place.
- In this cited framework, authentication is placed at the PaaS layer.
Major section
Under the Hood: Identity, Trust, and Risk Assessment (continued)
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.
- During authentication, the process's own safety properties can be invaded by attack, causing severe damage.
- A threat to the authentication process can lead to confidential data being disclosed to a fake, unauthorized user.
- A common misconception is that this example's PaaS label restricts authentication to PaaS; the label describes the cited framework.
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.
- 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").
- 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.
- 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 see answers page
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: B 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: C 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 secure the platform while customers secure the applications they deploy; IaaS providers own neither, leaving the customer to arrange application-level security themselves.
- B · 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.
- C · 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.