Cloud Security, Privacy and Ethical Practice

Introduction

Cloud deployment changes the security boundary of a software system. In a traditional data centre, an organisation may control the physical network, servers and operating systems. In a cloud platform such as Heroku or AWS, responsibility is divided between the provider and the customer. The provider secures facilities, core infrastructure and many managed services; the customer remains responsible for identity configuration, application code, data protection, access policies and appropriate use of services. This division is commonly called the shared responsibility model.

Security is therefore not a product that can be added after deployment. It is a continuous management process involving prevention, detection, response and recovery. Privacy and ethics extend this process beyond technical protection: an application must collect and use data lawfully, fairly, transparently and proportionately.

Learning Objectives

By the end of this chapter, you should be able to:

• apply least privilege and role-based access control;
• distinguish IAM users, roles, policies and identity federation;
• select suitable encryption, key-management and secret-management techniques;
• design vulnerability scanning, patching, logging and incident-response practices;
• assess privacy, data residency and supply-chain risks;
• explain responsible disclosure, accessibility, sustainability and ethical use of customer data;
• evaluate a cloud deployment using a structured security and governance case.

1. The Cloud Security Responsibility Model

Cloud security has three interacting dimensions:

1. Confidentiality: preventing unauthorised disclosure.
2. Integrity: preventing unauthorised or accidental alteration.
3. Availability: ensuring authorised users can access services when needed.

Authentication answers “Who are you?” Authorisation answers “What may you do?” Auditing answers “What happened, when, and under whose authority?” These controls must work together. Strong authentication without careful authorisation can still permit excessive access; authorisation without logging makes misuse difficult to investigate.

In infrastructure services, the customer may manage operating systems, networks and applications. In platform services such as Heroku, the provider manages much of the operating environment, but the customer still controls application dependencies, configuration, users and data. Managed services reduce operational burden but do not remove governance obligations.

A useful security lifecycle is:

Identify → Protect → Detect → Respond → Recover

Identification includes asset inventories, data classification and threat modelling. Protection includes secure configuration, access control and encryption. Detection includes logs, alerts and anomaly monitoring. Response contains and investigates incidents. Recovery restores service, removes the cause and incorporates lessons learned.

2. Identity, Access and Least Privilege

2.1 IAM building blocks

Identity and Access Management (IAM) generally contains:

• Principal: an entity requesting access, such as a user, service or federated identity.
• Authentication: verification of identity, ideally using multi-factor authentication (MFA).
• Policy: a set of rules defining permitted or denied actions.
• Role: an assumable identity with temporary permissions, commonly used by workloads.
• Resource: an object being accessed, such as a database, bucket or queue.
• Condition: a contextual restriction, such as source network, time or encryption requirement.

Least privilege means granting only the permissions, resources and duration necessary for a task. It is not the same as “deny everything permanently.” A developer may need deployment permissions but not production database access; an application may need to read one object prefix but not delete the entire storage bucket.

Permissions should be granted to groups or roles rather than individually whenever possible. Human administrators should use named accounts, MFA and short-lived elevated access. Root or owner accounts should be protected with hardware-backed MFA where available and used only for exceptional account-management tasks.

2.2 Federation and workload identity

Identity federation allows an external identity provider—such as an institutional directory—to authenticate users to cloud services. Standards such as SAML 2.0 and OpenID Connect (OIDC) support federated sign-in. Federation reduces password duplication, enables centralised offboarding and improves auditability.

Workloads should also use roles or workload identity rather than embedded access keys. For example, an AWS compute service can assume a role that grants access to a specific storage bucket. A CI/CD system can exchange an OIDC assertion for temporary cloud credentials. This avoids storing long-lived cloud keys in a source-code repository or CI variable.

2.3 Practical access review

An access review should ask:

• Is the identity still required?
• Is each permission used and justified?
• Is access limited to the correct environment and data classification?
• Are administrative actions separately logged?
• Can access be removed quickly when employment or project membership ends?

A permission such as “administrator on all resources” may be convenient but creates a large blast radius. A narrowly scoped role is safer even if it requires more design effort.

3. Encryption, Keys and Secrets

Encryption transforms readable plaintext into ciphertext using a cryptographic key. Proper encryption protects data from parties who obtain storage media or intercept network traffic, but it does not protect data from an authorised application that is already compromised.

3.1 Encryption in transit and at rest

Encryption in transit uses protocols such as TLS to protect communications between browsers, APIs, services and databases. Applications should use HTTPS, validate certificates through standard libraries, disable obsolete protocol versions where supported, and avoid transmitting sensitive data in URLs.

Encryption at rest protects stored databases, disks, backups and object storage. Provider-managed encryption is useful, but regulated or especially sensitive workloads may require customer-managed keys, separation of duties and stronger rotation or access policies.

Encryption is not a substitute for access control. If an application role can decrypt every customer record, compromise of that role may expose the records even though storage encryption is enabled.

3.2 Key-management principles

A key-management service (KMS) typically protects, rotates and audits cryptographic keys. Good practice includes:

• separating key administrators from data users;
• restricting decrypt operations by role and resource;
• recording key-use events;
• planning rotation and revocation;
• maintaining recovery procedures for key loss;
• avoiding the storage of plaintext keys in source code or images.

Rotation limits the useful lifetime of a compromised key, but it does not erase data already exposed. It must be coordinated with re-encryption, application configuration and backup recovery.

3.3 Secrets management

Secrets include database passwords, API tokens, signing keys and private certificates. They should be stored in a dedicated secret manager or protected deployment configuration, injected at runtime and excluded from source control, logs and error messages. A secret accidentally committed to Git should be treated as compromised: revoke or rotate it, inspect access logs and remove it from future history where appropriate. Merely deleting the file in a later commit is insufficient because earlier commits may remain accessible.

Heroku config variables and AWS Secrets Manager or Systems Manager Parameter Store can support runtime configuration. The precise service is less important than applying access restriction, rotation, auditing and safe recovery.

4. Secure Delivery, Vulnerability Management and Patching

Cloud security begins before deployment. A secure software-development lifecycle integrates security into design, coding, testing and operations.

4.1 Threat modelling

Threat modelling identifies assets, trust boundaries, threats, controls and residual risk. STRIDE is one useful model: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. The model should include cloud control planes, CI/CD systems, dependencies, administrative accounts and data exports—not only the public web interface.

4.2 Scanning and dependency risk

A practical pipeline may combine:

• secret scanning for credentials and tokens;
• static application security testing (SAST) for source-code weaknesses;
• software composition analysis (SCA) for vulnerable dependencies and licences;
• infrastructure-as-code scanning for insecure cloud configuration;
• dynamic application security testing (DAST) against a controlled test environment;
• container-image scanning where containers are used.

A scanner produces findings, not automatically correct decisions. Teams must validate false positives, assess exploitability and prioritise remediation using exposure, business impact, data sensitivity and compensating controls. A high-severity vulnerability in an unreachable development package may be less urgent than a moderate flaw exposing production personal data.

4.3 Patching and change control

Patching replaces vulnerable operating-system packages, frameworks or dependencies. Emergency patches should follow an expedited but documented process: identify affected assets, test compatibility, deploy progressively, monitor and record the result. Routine updates should be automated where practical, but automation must include rollback and health checks.

A useful operational measure is vulnerability age:

The result is a duration, usually measured in days. It is meaningful only when discovery and remediation dates use the same time zone and the organisation defines whether the clock begins at vendor disclosure, internal discovery or confirmed exploitability. Averages can conceal dangerous outliers, so teams should also track maximum age and the number of critical findings beyond their service-level target.

5. Logging, Monitoring and Incident Response

Logs should support detection, investigation and accountability. Important events include authentication failures, privilege changes, key use, security-group changes, data exports, deployment actions and administrative API calls. Logs should contain reliable timestamps, request or correlation identifiers and enough context to reconstruct events, while avoiding passwords, payment data and unnecessary personal information.

Centralise logs in a protected account or service. Restrict alteration and deletion, synchronise time, define retention periods and monitor the logging pipeline itself. A system that silently stops sending audit events is a security failure.

Incident response commonly follows:

1. Preparation: define roles, contacts, playbooks, backups and exercises.
2. Detection and analysis: validate the alert, determine scope, timeline and affected assets.
3. Containment: limit spread, such as disabling a token or isolating a workload.
4. Eradication: remove malware, correct misconfiguration and rotate exposed credentials.
5. Recovery: restore trusted service gradually and monitor for recurrence.
6. Lessons learned: document causes, impact, communications and preventive actions.

Do not destroy evidence during containment. Preserve relevant logs and images according to legal, privacy and forensic requirements. Regulatory notification obligations vary by jurisdiction, sector and breach type; legal and privacy specialists should be engaged early.

6. Privacy, Data Residency and Ethical Data Use

Security protects data; privacy governs whether and how data should be collected, used, shared and retained. Important privacy principles include purpose limitation, data minimisation, accuracy, storage limitation, transparency, accountability and appropriate safeguards.

A privacy impact assessment should document:

• what data is collected and why;
• the lawful or authorised basis for processing;
• who receives it, including cloud providers and subprocessors;
• retention and deletion rules;
• cross-border transfers and contractual safeguards;
• risks to individuals and mitigation measures;
• how individuals can exercise applicable rights.

Data residency describes where data is stored or processed. Residency requirements may arise from contracts, national law, sector regulation or institutional policy. Selecting a region is not enough: backups, logs, support access, replicas, content-delivery caches and analytics services may process data elsewhere. Teams should maintain a data-flow map and verify provider terms and service-region behaviour.

Ethical use requires more than legal compliance. A product may technically be allowed to collect behavioural data while still being manipulative, discriminatory or disproportionate. Consent should be informed and freely given where consent is the basis for processing; dark patterns that pressure users into unnecessary disclosure are unethical. Retention should have a defined purpose and deletion should be technically feasible.

Artificial intelligence introduces additional concerns. Training or prompting an external AI service with customer records may disclose confidential information or create secondary use. Before using AI, establish approved data classes, human review, access restrictions, output validation, bias testing and a process for correcting harmful outcomes.

7. Supply-Chain Security and Responsible Disclosure

Modern applications depend on open-source packages, build tools, base images, cloud APIs and third-party SaaS providers. This supply chain can be attacked through malicious packages, compromised maintainers, dependency confusion, poisoned build artefacts or stolen CI credentials.

Controls include pinned and reviewed dependencies, lockfiles, private package namespaces, software bills of materials (SBOMs), signed artefacts, isolated builds, protected branches, dependency update automation and provenance records. These controls reduce risk but do not prove that software is harmless.

A responsible disclosure policy gives security researchers a safe way to report weaknesses. It should provide a contact channel, encryption option where appropriate, expected acknowledgement, scope, non-retaliation language and a process for coordinating fixes. Organisations should not threaten researchers who act within clearly stated boundaries. Researchers should avoid accessing unnecessary data, maintain confidentiality and allow reasonable remediation time.

8. Accessibility, Sustainability and Professional Ethics

Security controls must not unnecessarily exclude users with disabilities. MFA, password recovery, consent interfaces and security warnings should support keyboard navigation, screen readers, sufficient contrast and alternatives to inaccessible biometric or visual challenges. Accessibility is part of quality and equal participation, not a decorative enhancement.

Cloud sustainability involves selecting efficient architectures, right-sizing resources, reducing idle environments, using autoscaling appropriately and choosing lower-carbon regions where contractual and latency requirements permit. Excessive logging, duplicated data and unneeded continuous workloads consume energy and increase cost. Security retention requirements should be balanced against minimisation and environmental impact.

Professional ethics requires honesty about risk. Engineers should not conceal a breach, exaggerate a security claim, collect data merely because it is technically possible, or use production customer data for experimentation without authorisation. Decisions should consider affected individuals, not only the organisation’s immediate convenience.

9. Illustrative Case: A Student Services Platform

Background

A university deploys a student-services application on Heroku. It uses a managed PostgreSQL database, object storage for documents and an external email provider. Students submit identity documents and receive automated notifications.

Problem

An audit finds that a developer’s long-lived cloud key is stored in a private repository, production logs contain document URLs, all developers can access production data, and backups are replicated to a region not approved by the university. A dependency scanner also reports a vulnerable image-processing library.

Analysis

The key creates a direct credential-compromise risk. Private repositories are not secret stores. Broad developer access violates least privilege and increases the impact of account compromise. URLs in logs may expose personal data through log access or sharing. Unapproved backup residency creates contractual and privacy risk. The vulnerable dependency may permit arbitrary code execution depending on how image files are processed.

Approach

The team first revokes and rotates the key, reviews access logs and checks the repository and CI history. It replaces the key with a workload role or short-lived federated CI credentials. Production access is separated into read-only support, deployment and tightly controlled emergency roles; developers use synthetic data in non-production environments.

The team removes sensitive URLs from logs, restricts object access, enables encryption and configures approved backup regions. It updates or replaces the image library after testing, scans the resulting artefact and deploys progressively. A privacy assessment updates the data-flow map and retention schedule. Finally, the university creates alerts for unusual downloads, privileged-role changes and logging failures, and rehearses an incident-response scenario.

Outcome and learning points

The outcome is not simply a successful deployment. It is a system with reduced blast radius, clearer accountability and better evidence for compliance. The case demonstrates that security, privacy, reliability and ethics are connected: a logging decision can become a privacy problem, while a convenient credential can become an institutional incident.

10. A Practical Governance Checklist

Before production release, teams should verify:

• assets, data classifications and trust boundaries are documented;
• MFA and federation protect human administrators;
• workload identities use short-lived credentials;
• permissions are scoped by action, resource and environment;
• TLS and appropriate encryption at rest are enabled;
• keys and secrets are centrally managed and rotated;
• dependencies, images, code and infrastructure are scanned;
• critical findings have owners, deadlines and tested remediation;
• logs are centralised, protected, monitored and privacy-aware;
• backups are tested and meet residency requirements;
• incident contacts, playbooks and notification procedures exist;
• retention, deletion, consent and data-subject processes are defined;
• suppliers, licences and software provenance are reviewed;
• accessibility and sustainability are considered in design;
• security claims and data uses are communicated honestly.

Challenges and Limitations

No control eliminates risk. Encryption can be undermined by stolen decryption privileges; scanning misses unknown vulnerabilities; logs can be incomplete; federation can centralise failure; and compliance checklists may encourage superficial assurance. Strong security also creates usability, cost and operational trade-offs. Excessive restrictions may lead staff to create unsafe workarounds, while excessive monitoring may violate privacy. Effective governance therefore combines technical controls with risk-based judgement, human review, testing and continual improvement.

Chapter Summary

Cloud security depends on shared responsibility and a lifecycle of identification, protection, detection, response and recovery. Least privilege, MFA, federation and short-lived workload identities reduce unauthorised access and credential exposure. Encryption in transit and at rest protects data, while disciplined key and secret management controls who can decrypt or authenticate. Secure delivery requires threat modelling, dependency and configuration scanning, patching, protected build pipelines and prioritised remediation.

Logging must support detection and accountability without unnecessarily collecting personal data. Incident response requires preparation, evidence preservation, containment, eradication, recovery and lessons learned. Privacy requires purpose limitation, minimisation, transparency, retention control and attention to residency and cross-border processing. Supply-chain security, responsible disclosure, accessibility, sustainability and ethical data use are essential professional responsibilities. The central principle is that a cloud system is trustworthy only when its technical design, operational practice and treatment of people are aligned.

Key Terms

Least privilege: Granting only the access necessary for an authorised task.

IAM: Identity and Access Management; controls identities, authentication and permissions.

Role: A set of permissions that an identity or workload can assume.

Identity federation: Trust between an organisation’s identity provider and an external service.

MFA: Multi-factor authentication using two or more independent authentication factors.

Encryption at rest: Protection of stored data using cryptographic transformation.

Encryption in transit: Protection of data moving between systems, commonly with TLS.

KMS: Key-management service for controlling, auditing and often rotating cryptographic keys.

Secret: Sensitive authentication or cryptographic material such as a password or token.

Threat model: Structured analysis of assets, threats, trust boundaries and controls.

SAST: Static Application Security Testing performed on source or compiled code.

SCA: Software Composition Analysis of third-party components and dependencies.

SBOM: Software bill of materials listing components in a software artefact.

Vulnerability: A weakness that may be exploited to compromise confidentiality, integrity or availability.

Data residency: The geographic location in which data is stored or processed.

Data minimisation: Collecting and retaining no more personal data than necessary.

Responsible disclosure: Reporting vulnerabilities through an agreed process that supports safe remediation.

Shared responsibility model: Division of security duties between cloud provider and customer.

Incident response: Organised detection, containment, eradication, recovery and learning after a security event.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.
2. Why should workload identities generally use temporary credentials?
3. State two differences between encryption at rest and encryption in transit.
4. What is the purpose of an SBOM?
5. Name the major phases of incident response.

Long Answer Questions

1. Explain how least privilege, federation and MFA work together in a cloud organisation.
2. Discuss the responsibilities of a customer under the shared responsibility model when using Heroku or AWS.
3. Describe a secure process for managing secrets from development through production.
4. Explain how privacy, data residency and retention should influence cloud architecture.
5. Evaluate the role of logging in both security investigation and privacy protection.

Analytical / Application Questions

1. A CI pipeline uses a permanent administrator key stored as an encrypted repository variable. Analyse the risks and design a safer replacement.
2. A company discovers that customer documents were included in central logs for six months. Propose an incident-response, privacy and remediation plan.
3. A team wants to deploy an AI feature using historical customer conversations. Assess the ethical, privacy, supply-chain and governance questions that must be answered before approval.

Multiple Choice Questions with Answers

Question 1

Which practice best implements least privilege for an application that only reads invoices from one storage location?

A. Grant administrator access to the application

B. Grant read access to the required invoice objects only

C. Share a developer’s personal access key with the application

D. Allow read and delete access to the entire storage account

Correct Answer: B. Grant read access to the required invoice objects only

Question 2

What is the primary advantage of workload identity federation in CI/CD?

A. It removes the need for authorisation policies

B. It creates permanent credentials for every pipeline

C. It enables short-lived credentials without embedding long-lived keys

D. It makes source-code review unnecessary

Correct Answer: C. It enables short-lived credentials without embedding long-lived keys

Question 3

Which control primarily protects data while it travels between a browser and an API?

A. TLS

B. Database indexing

C. Data retention

D. Static code analysis

Correct Answer: A. TLS

Question 4

A secret is accidentally committed to a Git repository. What should happen first?

A. Rename the variable in the next commit

B. Make the repository private and take no further action

C. Revoke or rotate the secret and investigate its use

D. Delete only the local working copy

Correct Answer: C. Revoke or rotate the secret and investigate its use

Question 5

Which activity is an example of Software Composition Analysis?

A. Reviewing user-interface colour contrast

B. Checking third-party packages for known vulnerabilities

C. Encrypting a database volume

D. Testing disaster-recovery communication

Correct Answer: B. Checking third-party packages for known vulnerabilities

Question 6

Why should security logs be protected from unauthorised alteration?

A. To increase application response speed

B. To preserve their evidential and investigative value

C. To eliminate the need for backups

D. To guarantee that no incident will occur

Correct Answer: B. To preserve their evidential and investigative value

Question 7

Which statement about data residency is most accurate?

A. It concerns only the primary database region

B. It can include backups, replicas, logs and support processing

C. It is identical to encryption at rest

D. It removes the need for privacy assessment

Correct Answer: B. It can include backups, replicas, logs and support processing

Question 8

What is the appropriate ethical response when a researcher reports a vulnerability within a published disclosure policy?

A. Ignore the report unless exploitation is proven publicly

B. Retaliate to discourage future reports

C. Acknowledge, assess and coordinate remediation within the stated process

D. Publish the researcher’s personal information

Correct Answer: C. Acknowledge, assess and coordinate remediation within the stated process

Question 9

Which action best supports sustainable cloud operation?

A. Running all development environments continuously at maximum size

B. Duplicating all data indefinitely

C. Right-sizing resources and removing idle workloads

D. Disabling monitoring and backups

Correct Answer: C. Right-sizing resources and removing idle workloads

Question 10

Which incident-response phase focuses on removing malware and correcting the underlying weakness?

A. Preparation

B. Containment

C. Eradication

D. Recovery

Correct Answer: C. Eradication