Security, Privacy, Ethics, and Governance

Introduction

Serverless applications and microservices change the security boundary of software systems. In a traditional application, a small number of servers, networks, and databases may be managed by one organization. In a serverless and microservices architecture, responsibility is distributed across cloud providers, managed services, development teams, third-party libraries, identity systems, APIs, event brokers, and data stores. Functions may be created and destroyed dynamically, while services communicate through networks that are not automatically trusted.

Security is therefore not an isolated technical feature. It is a system of controls, decisions, evidence, and responsibilities. Privacy concerns how personal information is collected, used, shared, retained, and deleted. Ethics concerns whether the system’s purposes and effects are fair, responsible, and respectful of human rights. Governance establishes policies, accountability, risk tolerance, and oversight.

The central principle of this chapter is that security must be designed into the application lifecycle rather than added after deployment. A secure serverless system uses explicit identity, narrowly scoped permissions, protected data, verified software dependencies, observable operations, and documented governance decisions.

Learning Objectives

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

1. Explain zero-trust principles and apply least-privilege access to serverless and microservice environments.
2. Distinguish authentication, authorization, accounting, and auditing.
3. Select suitable controls for encryption, secrets management, APIs, and software supply chains.
4. Design practical privacy controls for personal and sensitive data.
5. Explain security governance, compliance responsibilities, and shared responsibility in cloud computing.
6. Evaluate ethical risks involving surveillance, automated decisions, data use, and artificial intelligence.
7. Construct a security and governance approach for a small cloud-native application.

1. The Security Context of Cloud-Native Applications

A microservice is a separately deployable component that usually exposes an API or consumes events. A serverless function is an execution unit managed by a cloud platform, often invoked by an HTTP request, message, schedule, or database event. Both models provide agility, but they introduce distinctive risks:

• Many identities: users, functions, containers, deployment pipelines, administrators, and external services all require controlled access.
• Ephemeral execution: a function may exist only for milliseconds or seconds, making local investigation and persistent host controls less useful.
• Distributed data flows: information can move through APIs, queues, logs, caches, object stores, and analytics systems.
• Expanded dependencies: applications rely on cloud services, open-source packages, base images, build tools, and external APIs.
• Configuration risk: an incorrect policy, public storage setting, or permissive API gateway rule can expose data without a software defect.
• Shared responsibility: the provider secures its infrastructure and managed service; the customer remains responsible for many configuration, identity, data, and application controls.

A useful security model considers confidentiality, integrity, and availability. Confidentiality prevents unauthorized disclosure. Integrity protects information and code from unauthorized alteration. Availability ensures that legitimate users can obtain services when needed. Modern practice also emphasizes authenticity, accountability, privacy, resilience, and non-repudiation.

Risk can be described conceptually as a combination of likelihood and impact. This is not a universal numerical law, but a decision aid:

Likelihood estimates how probable an undesirable event is, while impact estimates its consequences, such as financial loss, harm to individuals, service disruption, or regulatory penalties. The expression is useful for prioritization, but risk assessments should also consider uncertainty, dependencies, threat actors, and the effectiveness of existing controls.

2. Zero Trust and Least Privilege

2.1 Zero-trust principles

Zero trust rejects the assumption that a request is safe because it originates inside a corporate network or from another internal service. Each request should be evaluated using available evidence, including identity, device or workload context, requested resource, action, data sensitivity, and environmental conditions.

Common zero-trust principles include:

• Verify explicitly: authenticate and evaluate each request using relevant context.
• Use least privilege: provide only the permissions required for a task, for the shortest practical time.
• Assume breach: design controls so that compromise of one account or service does not automatically compromise the whole system.
• Segment systems: isolate workloads, data domains, environments, and administrative functions.
• Continuously monitor: collect and analyze evidence rather than treating authorization as a one-time decision.

Zero trust does not mean that every request must require an interactive password. A workload identity, signed token, certificate, or managed identity can authenticate a service. The important point is that trust is established through verifiable policy and context rather than network location alone.

2.2 Least-privilege IAM

Identity and Access Management (IAM) controls who or what may perform an action on a resource. A permission generally has four parts: a principal, an action, a resource, and conditions. For example, a reporting function may be allowed to read selected objects from one storage bucket, only when invoked through a designated role.

A practical permission-design process is:

1. Inventory human, machine, service, and deployment identities.
2. Identify the exact resources each identity needs.
3. Specify required actions, such as read, write, invoke, publish, or administer.
4. Add conditions, such as environment, source service, time, network context, or resource tags.
5. Deny broad or unrelated permissions.
6. Test the policy using expected and unexpected requests.
7. Review permissions periodically and remove unused access.

Avoid using a single powerful role for an entire application. Separate roles for ingestion, processing, reporting, deployment, and administration reduce blast radius. Administrative access should use strong authentication, approval, logging, and preferably just-in-time elevation.

A permission review should ask not only “Can this identity access the resource?” but also “Should it still have access, under what conditions, and what evidence proves that access was appropriate?”

3. Authentication, Authorization, and Accountability

Authentication establishes identity. Authorization determines what an authenticated identity may do. Accounting records actions and supports accountability. These functions are related but not interchangeable.

3.1 Authentication

Human users may authenticate using passwords, multifactor authentication, hardware security keys, or federated identity. Passwords should not be stored in plaintext; systems should use appropriate password-hashing mechanisms and secure recovery procedures. Multifactor authentication reduces the consequences of stolen passwords, especially for administrators.

Service-to-service authentication can use managed identities, short-lived tokens, mutual TLS, or signed requests. Long-lived shared credentials are difficult to rotate and attribute, and should be avoided where stronger mechanisms are available.

Federation allows an application to rely on an identity provider rather than maintaining a separate account database. Standards such as OAuth 2.0, OpenID Connect, and Security Assertion Markup Language are used in different contexts. OAuth 2.0 is primarily an authorization framework; OpenID Connect adds an identity layer. Implementations must validate issuer, audience, signature, expiry, and appropriate scopes or claims.

3.2 Authorization

Authorization should be enforced at the API and service boundary, not only in the user interface. Common models include:

• Role-based access control: permissions are assigned to roles, and users or workloads receive roles.
• Attribute-based access control: decisions use attributes such as department, data classification, location, or time.
• Relationship-based access control: decisions depend on relationships, such as whether a user owns a document or belongs to a project.

An API should validate both the action and the object. A user authorized to view one customer record must not be able to change the record identifier in a request and retrieve another customer’s information. This class of error is often called broken object-level authorization.

3.3 Auditability

Audit records should answer who performed an action, what happened, which resource was affected, when it occurred, where the request came from, and whether it succeeded. Logs should be protected from unauthorized modification and should avoid unnecessary personal or secret data. Time synchronization, correlation identifiers, and consistent event schemas improve investigation.

Logging everything is not automatically good governance. Excessive collection can create privacy risk, increase cost, and obscure important events. Organizations should define retention periods, access restrictions, alert thresholds, and deletion procedures.

4. Encryption and Key Management

Encryption transforms readable data into ciphertext using a key. It supports confidentiality, but it does not replace access control, secure application logic, or data minimization.

• Encryption in transit protects communication between clients, APIs, services, and managed resources. Current implementations should use properly configured TLS and validate certificates.
• Encryption at rest protects stored data such as databases, object storage, backups, and logs.
• Application-level encryption protects selected fields before storage and may reduce exposure to operators or storage administrators, although it complicates searching, rotation, and recovery.

Symmetric encryption uses the same secret key for encryption and decryption. Asymmetric cryptography uses a key pair consisting of a private key and a public key. The security of a cryptographic system depends heavily on key generation, storage, access control, rotation, revocation, and recovery.

A cloud Key Management Service or Hardware Security Module can provide controlled key operations and audit trails. Key separation is important: keys for production data should not be casually reused for development, and highly sensitive domains may require distinct keys. Key rotation must be designed so that historical data remains recoverable during migration.

Encryption has limitations. If an attacker gains authorized application access, the application may decrypt data on the attacker’s behalf. Encryption also cannot correct an incorrect recipient, an exposed token, or an API authorization flaw.

5. Secrets Management

Secrets include passwords, API keys, private certificates, database credentials, signing keys, and tokens. They should not be embedded in source code, committed to repositories, placed in container images, or written to logs.

A secrets-management design should provide:

• centralized storage with encryption;
• access through workload identity rather than hard-coded credentials;
• narrowly scoped permissions;
• versioning and controlled rotation;
• emergency revocation;
• audit records for retrieval;
• separation among development, test, and production secrets.

Where possible, use short-lived credentials and dynamic secret generation. A deployment pipeline should scan commits and artifacts for accidental secrets, but scanning is not a substitute for immediately revoking an exposed credential.

6. Secure APIs and Event-Driven Services

APIs should define explicit contracts, validate input, enforce authentication and authorization, and return controlled error messages. Important controls include:

• schema validation and strict content-type handling;
• rate limiting, quotas, and abuse detection;
• protection against injection, request forgery, replay, and excessive payload size;
• safe serialization and deserialization;
• idempotency for operations that may be retried;
• versioning and deprecation procedures;
• secure defaults and denial of unnecessary methods;
• monitoring for unusual access patterns.

Input validation should be performed on the server because clients cannot be trusted. Validation should address type, length, range, encoding, and business rules. Output encoding and parameterized database operations reduce injection risks.

Event-driven systems require additional controls. Events should include an authenticated producer or trusted signing mechanism, a defined schema, an event identifier, and controlled retention. Consumers should tolerate duplicate delivery where the platform provides at-least-once delivery. Dead-letter queues and replay procedures must be protected because they may contain sensitive data.

A function that handles an event should not automatically receive administrative access to the entire message broker or database. Separate producer and consumer permissions reduce the consequences of a compromised component.

7. Software Supply-Chain Security

A software supply chain includes source code, dependencies, package registries, build systems, deployment tools, infrastructure definitions, container images, and third-party services. An attacker may target any stage rather than the application’s own code.

Core practices include:

1. Use version control with protected branches and reviewed changes.
2. Pin or constrain dependencies and maintain a software bill of materials (SBOM).
3. Scan dependencies and images for known vulnerabilities.
4. Verify package provenance and, where practical, cryptographic signatures.
5. Use isolated, reproducible build environments.
6. Protect build credentials and separate build, test, and production permissions.
7. Sign release artifacts and verify signatures before deployment.
8. Monitor vulnerabilities after release and establish patch priorities.

Automated scanning produces findings, not certainty. A vulnerable package may be unreachable in the deployed code, while an unlisted vulnerability may remain dangerous. Teams should combine automated tools with review, threat modeling, runtime monitoring, and a documented risk-acceptance process.

Infrastructure as Code should be reviewed like application code. Policies can detect public storage, unrestricted network access, unencrypted databases, or excessive IAM permissions before deployment.

8. Privacy and Responsible Data Practices

Privacy is broader than secrecy. A system can expose no data publicly and still violate privacy if it collects excessive information, uses it for an unexpected purpose, or retains it indefinitely.

Important privacy principles include:

• Purpose limitation: collect and use information for specified legitimate purposes.
• Data minimization: collect only what is necessary.
• Accuracy: allow important information to be corrected.
• Storage limitation: retain data only as long as justified.
• Transparency: explain collection, use, sharing, and automated processing.
• Security: protect personal information using appropriate controls.
• Accountability: document decisions and demonstrate compliance.

Personal data may include identifiers, location, online identifiers, health information, financial records, or inferred characteristics, depending on applicable law. Classification should distinguish public, internal, confidential, personal, sensitive, and regulated data.

Privacy by design incorporates privacy at architecture time. Techniques include pseudonymization, tokenization, aggregation, field-level access, regional storage controls, deletion workflows, and separate analytics environments. Pseudonymization reduces direct identification but does not necessarily make data anonymous; re-identification may be possible when datasets are combined.

Retention must be technically enforceable. A policy that says “delete after 90 days” is weak if backups, logs, queues, replicas, and analytical copies are not addressed. Organizations should map data flows and identify controllers, processors, vendors, and cross-border transfers where relevant.

9. Ethics, Artificial Intelligence, and Human Responsibility

Ethical evaluation asks whether a system is acceptable, not merely whether it is technically legal. A cloud application may be lawful yet unfair, manipulative, discriminatory, or harmful.

Relevant questions include:

• Who benefits and who may be harmed?
• Are affected people informed and able to challenge decisions?
• Does the system produce unequal error rates or exclude vulnerable groups?
• Is consent meaningful, or is access conditional on unnecessary data collection?
• Are surveillance and behavioral predictions proportionate to the purpose?
• Can a human intervene when an automated decision is wrong?
• Are the environmental and labor effects of the system considered?

AI services add concerns about training-data provenance, model leakage, prompt injection, hallucination, bias, explainability, and unauthorized disclosure through prompts or logs. Sensitive data should not be sent to an AI service without a documented legal, contractual, and security basis. Human review is especially important for decisions affecting employment, education, credit, health, safety, or access to essential services.

Responsible practice requires an owner for each important decision, documented evaluation criteria, testing on relevant populations, incident reporting, and a mechanism for appeal or correction.

10. Governance, Compliance, and Shared Responsibility

Governance translates organizational objectives into policies, standards, controls, responsibilities, and evidence. A governance program should define:

• asset and data ownership;
• risk appetite and escalation thresholds;
• security architecture standards;
• identity and access review schedules;
• incident response roles;
• vendor assessment procedures;
• retention and deletion rules;
• exception and risk-acceptance processes;
• training and awareness requirements;
• audit and assurance activities.

Compliance frameworks and laws vary by jurisdiction and sector. Examples include privacy laws, payment-card requirements, health-information rules, records-management obligations, and cybersecurity standards. Compliance should not be treated as proof that a system is secure. A control may satisfy an audit requirement while failing to address a new threat, and a technically strong control may require documentation to demonstrate compliance.

Cloud contracts should clarify data location, breach notification, subcontractors, service availability, data return and deletion, audit rights, and responsibilities at termination. The shared-responsibility model must be documented for each service because provider-managed infrastructure does not remove customer responsibility for IAM, configuration, code, data, or users.

A mature governance cycle is continuous: identify assets and risks, select controls, implement them, monitor evidence, test effectiveness, correct weaknesses, and review changes in technology or regulation.

11. Case Study: Secure Serverless Claims Processing

The following is an illustrative case.

Background

A regional insurer plans a serverless claims platform. Customers upload documents through an API. An ingestion function stores files, a scanning service checks them for malware, a processing function extracts information, and a review service presents claims to employees. The organization also uses an analytics warehouse.

Problem

An initial prototype uses one broad cloud role for all functions, stores an API key in an environment variable, logs full uploaded documents for debugging, and allows the review interface to retrieve any claim when a claim identifier is supplied. The design creates risks of privilege escalation, secret exposure, privacy violations, and unauthorized object access.

Analysis

The threat model identifies several actors: external customers, malicious users, compromised dependencies, rogue insiders, and compromised cloud identities. High-value assets include identity documents, medical information, payment details, claim decisions, and audit records. The highest risks arise from overprivileged service roles, insecure direct object access, excessive logs, and weak secret handling.

Approach and Solution

The organization applies the following controls:

• Customers authenticate through a federated identity provider with multifactor authentication where appropriate.
• The API gateway validates tokens, request schemas, size limits, and rate limits.
• Each function receives a separate workload identity. The ingestion function can write only to a quarantine location; the processing function can read approved objects and write structured results; analytics receives pseudonymized data.
• Authorization checks both the employee’s role and the claim’s relationship to the employee’s assigned region or team.
• Documents are encrypted in transit and at rest using managed keys. Key access is logged and separated by environment.
• API keys are replaced with managed identities or secrets-manager references. Exposed credentials are revoked immediately.
• Logs contain claim identifiers or pseudonymous references rather than full documents or medical details.
• Events include schema validation, producer identity, unique identifiers, and controlled retention. Duplicate processing is handled safely.
• Dependencies and infrastructure definitions are scanned, reviewed, and included in an SBOM.
• A deletion workflow addresses primary storage, queues, logs, backups, and analytics copies according to the approved retention schedule.
• Security events are sent to a protected monitoring system, and incident procedures define notification, containment, recovery, and evidence preservation.

Outcome

The revised design reduces the blast radius of a compromised function, improves auditability, and supports privacy obligations. It may increase implementation effort and operational cost, but the organization can now explain who may access each data class, why access is required, and how misuse will be detected.

Learning Points

The case demonstrates that security is a system property. Encryption alone would not have prevented an employee from accessing another region’s claims, and an API gateway alone would not have corrected excessive function permissions. Effective protection combines IAM, authorization logic, secure development, privacy engineering, monitoring, and governance.

12. Implementation Roadmap and Best Practices

A practical diploma-level implementation roadmap is:

Phase 1: Discover. Inventory services, identities, data stores, events, dependencies, vendors, and regulatory obligations. Classify data and document flows.

Phase 2: Design. Create trust boundaries, threat models, IAM roles, API contracts, encryption and key strategies, retention rules, and incident responsibilities.

Phase 3: Build securely. Use code review, dependency controls, secret scanning, parameterized operations, secure defaults, infrastructure policy checks, and automated tests for authorization.

Phase 4: Deploy with guardrails. Separate environments, protect pipelines, require approvals for sensitive changes, verify artifacts, and prevent public exposure through policy-as-code.

Phase 5: Operate and improve. Monitor identity use, failures, unusual data access, dependency alerts, and configuration drift. Conduct access reviews, restore tests, incident exercises, privacy reviews, and periodic threat-model updates.

Useful security metrics include the proportion of identities using multifactor authentication, percentage of resources covered by logging, time to revoke compromised credentials, age of critical vulnerabilities, number of excessive permissions removed, and completion of deletion requests. Metrics should support decisions rather than encourage teams to optimize superficial counts.

Challenges and Limitations

Security controls create trade-offs. Fine-grained authorization can increase complexity and latency. Detailed logging improves investigation but can create privacy and storage costs. Encryption may complicate search and recovery. Short-lived credentials require reliable identity infrastructure. Automated scanning can generate false positives and false negatives. Serverless abstractions reduce infrastructure management but can make low-level visibility and forensic investigation more difficult.

No control is permanent. Cloud services change, dependencies become vulnerable, staff roles change, and attackers adapt. Governance must therefore support learning, correction, and proportionate risk decisions rather than relying on a one-time certification.

Chapter Summary

Secure serverless and microservice applications require explicit trust decisions across users, workloads, APIs, data, dependencies, and cloud services. Zero trust verifies requests rather than trusting network location. Least-privilege IAM limits actions, resources, and conditions, reducing blast radius. Authentication identifies principals, authorization controls actions, and auditability supplies evidence.

Encryption protects data in transit and at rest, while effective key management determines whether encryption is operationally trustworthy. Secrets should be centrally managed, narrowly accessible, short-lived where possible, and rapidly revocable. Secure APIs require validation, authorization, rate controls, safe errors, and protection against object-level access failures. Supply-chain security includes dependency governance, provenance, SBOMs, signed artifacts, protected pipelines, and infrastructure checks.

Privacy requires purpose limitation, minimization, transparency, retention control, and accountable data handling. Ethics extends beyond legal compliance to fairness, proportionality, human oversight, and responsibility for automated decisions. Governance establishes ownership, policies, evidence, incident response, vendor controls, and continuous review. The strongest security posture combines technical safeguards with responsible organizational decisions.

Key Terms

Zero trust: A security approach that verifies requests explicitly and assumes that no network location is automatically trusted.

Least privilege: Granting only the access necessary for a task, resource, and period of time.

IAM: Identity and Access Management; controls for identifying principals and granting permissions.

Authentication: Establishing that a user, service, or workload is who or what it claims to be.

Authorization: Determining whether an authenticated principal may perform a requested action.

Accounting: Recording actions and resource use for accountability and analysis.

Multifactor authentication: Authentication using two or more independent evidence categories.

Workload identity: An identity assigned to an application, function, service, or automated process.

Encryption: Transforming plaintext into ciphertext using a cryptographic method and key.

Key management: Generation, storage, use, rotation, revocation, and recovery of cryptographic keys.

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

API gateway: A managed entry point that can route, authenticate, validate, limit, and monitor API requests.

Object-level authorization: Permission checking for the specific record or resource being accessed.

Software supply chain: The code, dependencies, tools, artifacts, and services used to build and deliver software.

SBOM: Software bill of materials; an inventory of components included in a software artifact.

Data minimization: Collecting and processing only the information necessary for a defined purpose.

Pseudonymization: Replacing direct identifiers with substitutes while retaining a controlled possibility of linkage.

Governance: Policies, responsibilities, oversight, and decision processes used to direct and control technology.

Shared responsibility: The division of security duties between a cloud provider and its customer.

Threat model: A structured analysis of assets, actors, attack paths, impacts, and controls.

Review Questions

Short Answer Questions

1. What is the difference between authentication and authorization?
2. State three principles of zero-trust security.
3. Why should secrets not be stored in source code?
4. What is the purpose of a software bill of materials?
5. Explain the difference between encryption in transit and encryption at rest.

Long Answer Questions

1. Explain how least-privilege IAM can be implemented for a serverless application with several functions and data stores.
2. Discuss the security and privacy controls required for a secure API and event-driven architecture.
3. Explain how privacy by design affects data collection, storage, processing, logging, and deletion.
4. Describe the major responsibilities of a cloud customer under the shared-responsibility model.
5. Compare technical security compliance with broader ethical responsibility, using automated decision-making as an example.

Analytical / Application Questions

1. A reporting function can read and write every production database table, although it only needs read access to two tables. Analyze the risks and propose a revised IAM design.
2. A healthcare application records complete patient documents in application logs for debugging. Evaluate the design and propose safer observability and retention practices.
3. Design a security and governance plan for a serverless student-records application. Identify identities, trust boundaries, data controls, privacy obligations, monitoring requirements, and incident-response actions.

Multiple Choice Questions with Answers

Question 1

Which statement best describes zero-trust security?

A. Internal network traffic is trusted by default.

B. Every request is evaluated using identity and relevant context.

C. Only external users must authenticate.

D. Encryption removes the need for authorization.

Correct Answer: B. Every request is evaluated using identity and relevant context.

Question 2

What is the primary purpose of least-privilege IAM?

A. To maximize the number of permissions available to each service

B. To eliminate the need for audit logs

C. To limit access to what is necessary for an approved task

D. To make all services share one administrative role

Correct Answer: C. To limit access to what is necessary for an approved task

Question 3

Which mechanism is most appropriate for avoiding long-lived credentials for a cloud function?

A. A password embedded in source code

B. A shared API key in a container image

C. A managed workload identity with short-lived access

D. A credential copied into every environment variable

Correct Answer: C. A managed workload identity with short-lived access

Question 4

Which control directly helps prevent unauthorized retrieval of another customer’s record by changing an identifier in a request?

A. Object-level authorization

B. Increasing log retention

C. Compressing API responses

D. Encrypting a backup

Correct Answer: A. Object-level authorization

Question 5

What is a software bill of materials?

A. A list of cloud provider invoices

B. An inventory of components included in a software artifact

C. A database encryption key

D. A user authentication protocol

Correct Answer: B. An inventory of components included in a software artifact

Question 6

Which practice is most consistent with data minimization?

A. Collecting every available field for possible future use

B. Keeping personal data indefinitely

C. Collecting only information necessary for a defined purpose

D. Copying production data into all development environments

Correct Answer: C. Collecting only information necessary for a defined purpose

Question 7

What does encryption in transit primarily protect?

A. Data while it moves between communicating systems

B. The correctness of business rules

C. The availability of a database during an outage

D. The removal of outdated dependencies

Correct Answer: A. Data while it moves between communicating systems

Question 8

Which statement about pseudonymization is correct?

A. It always makes data permanently anonymous.

B. It replaces direct identifiers but may allow controlled re-identification.

C. It removes the need for access control.

D. It prevents all privacy obligations from applying.

Correct Answer: B. It replaces direct identifiers but may allow controlled re-identification.

Question 9

Why should a dead-letter queue be protected?

A. It can contain failed events and potentially sensitive data.

B. It automatically grants administrator access.

C. It replaces all encryption keys.

D. It prevents dependency vulnerabilities.

Correct Answer: A. It can contain failed events and potentially sensitive data.

Question 10

Which activity is primarily a governance function?

A. Defining ownership, policies, risk acceptance, and oversight

B. Changing a function’s variable name

C. Compressing an image before upload

D. Increasing a database index size

Correct Answer: A. Defining ownership, policies, risk acceptance, and oversight