UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 8.5 Free with a free account
The Cloud Security Model
Ethics in Technology · Chapter 8: Guarding the Data Vault: Database Protection, Cloud Risks, and Intrusion DetectionSection 8.5 · lesson 39 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Risks of Moving Data to the Cloud →← Data Tampering and Integrity ProtectionNext lesson: Risks of Moving Data to the Cloud →
In this lesson
Service boundaries, access decisions, data states, keys, and assurance.
- Distinguish service models from deployment arrangements
- Map provider, customer, and shared control duties
- Evaluate identity rules, encryption boundaries, and key custody
- Read assurance evidence within its scope and apply the model
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,767 words). Read along, or search it.
Chapter 8
The Cloud Security Model
Renting computing from a provider changes the operating duties and exposure paths that need protection. Provider expertise, maintained layers, and physical facilities can offer substantial benefits. Customers still need owners for their applicable data decisions, access, devices, integrations, and settings. This lesson distinguishes infrastructure, platform, and software services by the operation each party performs. Deployment arrangements describe another dimension, including public, private, hybrid, and multiple-provider use. A private arrangement is not automatically safer, and it need not be operated entirely by the customer. We map shared duties, then examine how identity and policies shape effective access. Next, we distinguish data at rest, in transit, and in use, together with their protection limits. Key custody adds control choices and recovery dependencies, without automatically excluding every provider plaintext path. Independent reports and certifications supply useful evidence within a defined scope. Finally, we apply the model to a marketing team's application, starting with who can actually reach its records.
Changing the Operating Model
Renting Capability Changes Duties and Exposure Paths
Providers can supply specialists, maintained infrastructure, physical protection, and tools that would be expensive to build internally. Those benefits depend on the chosen provider, service, configuration, and operating arrangements. The customer retains work for the layers and decisions under its control. Relevant responsibilities include data choices, accounts, access, devices, integrations, and configuration. A public sharing setting can expose information remotely without defeating the provider's encryption or infrastructure controls. That does not mean every cloud service is publicly reachable or public by default. Stolen identities, unsafe code, supplier incidents, and provider failures can also contribute to exposure. Avoid claiming that configuration explains nearly every incident without appropriate evidence. Ask which party operates and protects each relevant layer. Then ask what has actually been configured in the layers the customer controls. Published duties, contractual terms, and applicable law help turn those questions into clear operating decisions.
Illustrative Responsibility Matrix
More Managed Service Transfers More Operation, While Customer Decisions Remain
The source's responsibility matrix shows a sliding operating boundary across typical service models. In a classic self-managed arrangement, the organization operates the infrastructure and software layers. Infrastructure services transfer physical facilities, infrastructure, and virtualization operation to the provider. The customer commonly operates the guest system, runtime, application, and its applicable configuration. Platform services transfer more of the operating environment, while customers deploy their applications. Software services transfer application operation too, leaving supported customer data and access decisions. This is a simplified comparison, rather than a complete contract for every product. Shared controls and provider duties for implemented protections still exist around customer decisions. Customer devices and integrations also remain relevant, even though the source matrix omits them. A managed database differs from the same database installed on a rented virtual machine. Check the specific product before assuming a maintenance duty has transferred or an access setting is safe.
Three Service Models
Infrastructure, Platform, and Software Leave Different Customer Work
Infrastructure as a Service rents computing, storage, and networking resources. Customers commonly operate guest software and must address applicable updates and configuration. An unpatched guest system or unsafe storage access is an illustrative exposure in that model. Platform as a Service supplies a managed environment for deploying applications. Customers still need to manage their code, applicable dependencies, data, access, and supported settings. A vulnerable application library or exposed secret illustrates that continuing work. Software as a Service provides a finished application through its supported interfaces. Customer membership, permissions, sharing, and data handling remain important. A broadly shared document or departed user with active access illustrates that risk. These examples are not exclusive failure categories, and each product has its own boundary. Identify who patches components and how configuration, backups, and incident evidence work in the chosen service.
Deployment Arrangements
Exclusive Infrastructure Is a Design Choice, Not Proof of Better Security
Service models describe operation, while deployment arrangements describe another dimension of infrastructure use. Public cloud infrastructure is offered for broad use, with appropriate tenant separation and customer configuration. Public infrastructure does not automatically make the customer's data public. Private cloud serves one organization's exclusive use and can be operated internally, externally, or jointly. It is not necessarily on premises, and it does not automatically return every task to the customer. Hybrid cloud connects distinct environments, making the joins, policies, and trust boundaries important. Multiple-provider arrangements need coordinated inventory, identities, controls, and evidence across the services used. They can arise deliberately or when departments adopt services independently. NIST's deployment taxonomy also includes community cloud for organizations with shared concerns. Multiple-provider use is a related arrangement, rather than a substitute for that community category. Evaluate isolation, regulation, latency, existing investment, skills, cost, maintenance, and resilience before calling an arrangement more secure.
Shared Duties in Practice
Published Boundaries Need Named Owners, Evidence, and Incident Arrangements
Shared responsibility maps the provider's operated layers and the customer's applicable use. Some controls are inherited, some are shared in different contexts, and some concern customer-specific configuration. Begin by identifying who maintains each infrastructure, guest, runtime, application, and dependency layer. Then identify who creates identities, approves privileges, reviews sharing, and removes obsolete access. Confirm the arrangements for evidence, monitoring, backup, restoration, and keys. Incident work needs notice, escalation, response, cooperation, and relevant contractual and legal responsibilities. These duties can move between individual services from the same provider. An uncertain answer does not automatically transfer an obligation to either party. Resolve the actual terms and assign an owner instead of leaving the work unclaimed. A responsibility diagram alone does not decide every notification, liability, or compensation outcome. Clear duties need practical evidence that both sides perform the work expected of them.
Access Evaluation
A Valid Identity Still Needs an Applicable Permission for the Requested Action
Access evaluation considers who is asking, the requested action and resource, and applicable policies. Authentication alone does not establish permission for every action. In a simplified AWS identity-policy example, missing applicable permission produces an implicit denial. An applicable explicit denial overrides an allowance under the relevant evaluation rules. An allowance can permit the action where no overriding restriction applies. The full result depends on policy types, the principal, resource, context, and account relationships. Identity and resource policies can combine differently from permission boundaries or organizational controls. Other cloud platforms also have their own evaluation systems, so do not generalize one diagram universally. Broad permissions can be deliberately granted by mistake when narrowing them is inconvenient. Default denial does not make accidental over-permission or software flaws impossible. Review actual effective reach and the particular product's rules, rather than assuming every accepted request is appropriate.
Identity Practices
Narrow Authority, Shorter Credential Lifetimes, and Review Reduce Exposure
Least privilege limits the actions and resources available to each account or role. Temporary roles and credentials can reduce reliance on long-lived secrets. Expiry limits a credential's lifetime, but misuse during that lifetime still matters. Strong second-factor protection is especially useful for privileged sign-in, with phishing resistance and sessions also important. Separate development, testing, production, and relevant recovery authority to reduce unwanted paths between them. Review continuing access and remove obsolete identities, privileges, and sharing settings. Use an appropriate managed secrets store, rather than placing passwords or keys in source code. Protect how applications receive and use those secrets as well. Identity is central, while network controls, key permissions, monitoring, session revocation, and endpoint protection still matter. Protected copies and separated authority can also reduce consequences after an account is stolen. Least privilege is valuable, but it is not the only control that can still help after credential theft.
States of Data
Storage, Communication, and Processing Need Different Protections
Data at rest is stored information, including covered copies and recovery material. Suitable encryption and key controls protect it against particular storage-access threats. Ordinary authorized service requests may still receive plaintext according to their permissions. Data in transit moves through communications paths and needs appropriate protection for those paths. Include relevant internal service hops, rather than protecting only the external connection. Data in use is processed information, often including values present in memory. Confidential computing or other suitable designs can protect selected processing boundaries, with workload-specific limits. Follow where plaintext exists, which identity can request decryption, and which keys or protected environments are involved. Default settings and the availability of these protections vary by service. An overbroad account remains a serious risk, but encryption can still help against other threats. Verify the complete path instead of treating the word encrypted as a complete description of protection.
Key Custody
Location and Administrative Control Do Not Alone Define Plaintext Access
Provider-managed keys can simplify operations through the provider's managed key system. Customers still need to understand permitted decryption and relevant privileged-access controls. Customer-managed keys within the provider's service add permissions, lifecycle choices, and applicable key-use evidence. The provider still operates machinery, and supported revocation and recovery details vary. Externally managed keys can add separation and control over external key use. They also introduce compatibility, latency, availability, and recovery considerations. External custody alone does not mean a cloud workload never receives plaintext through an approved operation. If excluding provider plaintext access is the goal, assess the complete client-side or confidential-processing architecture. The arrangement does not promise immunity from lawful demands, and revocation may not erase plaintext already obtained. Losing all usable keys can make a dependent copy unrecoverable without another recovery route. Plan protected key recovery and service availability alongside the intended access-control benefit.
Assurance Evidence
Read What Was Examined, Which Service Is Covered, and What You Must Operate
Assurance reports and certifications provide evidence about specified controls and boundaries. A SOC two Type One report addresses control design at a specified date. Type Two also addresses operating effectiveness over a period. Read criteria, exceptions, subservices, and complementary controls expected from the customer. ISO certification concerns conformity of a scoped information security management system, rather than every customer setting. Payment-card assessment likewise concerns its assessed environment and leaves applicable customer duties. Under the current federal program, FedRAMP certifies a cloud service offering as reusable agency evidence. An agency still authorizes its own system and specific use of the service. Confirm the certified version, boundary, relevant information, configuration, and integrations. HIPAA arrangements require an appropriate business associate agreement and applicable safeguards where those duties apply. A marketing badge or agreement alone does not establish lawful handling of protected health information. Check scope, timing, ongoing status, and your own duties; useful evidence is not a guarantee of every current configuration.
Marketing-Team Scenario
Start with Actual Access, Then Verify Ownership and the Supporting Evidence
The marketing team uses a finished application that it configured without the technology team's involvement. Provider expertise, audited controls, and encryption are real benefits worth considering. They do not alone settle the safety of the team's particular setup. First ask which people and links can actually reach the campaign records, and who reviews that access. Then assign business and technical ownership for sharing, departures, monitoring, retention, and recovery. Assess the sensitivity of the records, appropriate purpose, and any integrations that can obtain them. Identify key custody, permitted decryption, relevant data states, and recovery dependencies. Read the assurance evidence for service scope, timing, findings, and complementary customer controls. Confirm maintenance duties, incident arrangements, and any applicable contractual or legal requirements. The same reasoning applies to a supplier that answers a questionnaire with only encryption and certification claims. Review service models, deployment arrangements, shared duties, effective permissions, data states, keys, and assurance as connected decisions.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About The Cloud Security Model
What is the shared responsibility model in cloud security?
What is the difference between IaaS, PaaS and SaaS in terms of security?
What is the difference between public, private and hybrid cloud?
What is the difference between a SOC 2 Type I and Type II report?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →