12. Security, Privacy, Ethics and Architecture Governance

Introduction and Context

Security in a scalable web architecture is not a feature added after development. It is a property of the whole system: its business rules, identities, APIs, data stores, infrastructure, deployment pipeline, suppliers and operating procedures. A technically available application that exposes personal data, permits privilege escalation or cannot demonstrate regulatory accountability is not a successful architecture.

As systems become distributed across browsers, mobile applications, microservices, cloud platforms, third-party APIs and automated delivery pipelines, the security boundary becomes difficult to locate. Privacy and ethical responsibilities also extend beyond confidentiality. A system may be secure yet unfair, inaccessible, manipulative or excessive in its collection of data. Architecture governance provides the organisational means to make these concerns visible, assign accountability and verify that design decisions remain aligned with law, policy, risk appetite and professional standards.

This chapter develops an integrated approach to threat modelling, zero-trust architecture, identity and access management, cryptography, secrets management, software supply-chain security, privacy engineering, responsible data use, accessibility and governance. The central argument is that security controls should be selected according to risk and embedded in architecture decision-making rather than treated as isolated technical products.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship between security, privacy, ethics and architecture governance.

2. Apply threat-modelling methods to identify assets, trust boundaries, threats and mitigations.

3. Design access controls using zero-trust and identity-centred principles.

4. Distinguish encryption in transit, encryption at rest, hashing and digital signatures.

5. Establish sound practices for secrets, dependencies and software supply chains.

6. Apply privacy-by-design, data minimisation and responsible data-use principles.

7. Evaluate accessibility, ethical risks and governance controls in a web architecture.

8. Make defensible security and governance decisions under competing cost, usability and delivery pressures.

Security as an Architectural Property

A useful security model begins with the CIA triad: confidentiality, integrity and availability. Confidentiality prevents unauthorised disclosure; integrity protects information and operations from unauthorised alteration; availability ensures that authorised users can access services when needed. Modern architectures add authenticity, accountability, privacy and resilience. Authenticity establishes that an actor or message is genuine, accountability enables actions to be traced to responsible identities, and resilience concerns the ability to withstand and recover from failures or attacks.

Security objectives must be expressed in business terms. For an online payment service, integrity of transaction amounts may be more critical than the confidentiality of product descriptions. For a health platform, confidentiality and purpose limitation may dominate. Availability requirements must also be realistic: a public information site and an emergency service should not have identical recovery objectives.

The attack surface includes every interface through which a system receives input or exposes capability. It includes web forms, APIs, authentication endpoints, administrative consoles, cloud metadata services, CI/CD runners, package registries, support tools and human processes. A scalable architecture can increase the attack surface because it introduces more services, credentials, network paths and dependencies. Security architecture therefore requires inventory, classification and continuous review.

Threat Modelling as a Design Discipline

Threat modelling is a structured method for anticipating how a system could be abused or fail. It is most valuable early in design, when changes are cheaper, but it should be revisited when features, suppliers, data flows or deployment environments change.

A practical process has five stages. First, define scope and business objectives. Second, identify assets such as credentials, personal data, payment records, source code and service availability. Third, draw a data-flow diagram showing processes, data stores, external entities and trust boundaries. Fourth, identify threats and estimate their likelihood and impact. Fifth, select mitigations, owners and verification activities.

The STRIDE model classifies common threat types: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. STRIDE is useful for systematic coverage, although it should be supplemented with business-abuse cases. A fraudster may use a legitimate account to exploit refund rules; this may not appear as a conventional unauthorised intrusion but remains a serious threat.

Risk can be expressed qualitatively as a combination of likelihood and impact. A more formal expression is:

Risk = likelihood × consequence.

The formula does not create precision where evidence is weak. Its value is comparative: it helps teams prioritise controls and explain why an expensive mitigation is justified for one asset but not another. Threat records should state the threat, affected asset, assumptions, proposed control, residual risk and accountable owner.

Common modelling errors include focusing only on network attacks, ignoring insiders and suppliers, treating authentication as the same as authorisation, and documenting threats without testing mitigations. A threat model is useful only when it changes design, implementation, testing or operational monitoring.

Zero Trust and Identity-Centred Architecture

Traditional perimeter security assumes that a trusted internal network can be separated from an untrusted external network. Cloud and distributed systems weaken this assumption. A compromised laptop, service account or internal workload may be as dangerous as an external attacker. Zero trust replaces implicit trust with continuous verification and least-privilege access.

Zero trust does not mean that every request must be manually approved. It means that access decisions are based on explicit signals such as identity, device posture, workload identity, requested resource, context and policy. The architecture should assume breach, authenticate and authorise each interaction as appropriate, minimise privileges, segment sensitive services and continuously monitor activity.

Identity and access management (IAM) has four related functions. Identification claims an identity; authentication verifies the claim; authorisation determines permitted actions; and accounting records relevant activity. Role-based access control assigns permissions to roles, while attribute-based access control evaluates attributes such as department, location, data classification, device state and time. Role-based models are easier to administer, whereas attribute-based policies can express fine-grained conditions but require reliable attributes and careful testing.

Strong authentication should use phishing-resistant or multi-factor methods where risk warrants them. Passwords should be stored using a slow, salted password-hashing algorithm rather than reversible encryption. Session tokens should be short-lived, protected against theft and invalidated when necessary. Administrative access should use separate privileged accounts, approval workflows and strong logging. Service-to-service access should use workload identities and narrowly scoped credentials rather than shared static keys.

Authorisation must be enforced on the server and at the object level. A user who may access an order list may not automatically access every order identified by a predictable URL. This insecure direct object reference pattern is prevented by checking ownership or permitted scope for each object request. Deny-by-default policies, explicit resource ownership and centralised policy evaluation reduce inconsistent implementation across services.

Cryptography, Key Management and Secrets

Cryptography protects information but cannot compensate for incorrect access rules or insecure endpoints. Encryption in transit, commonly implemented through modern transport security, protects communication between clients and services. Encryption at rest protects stored data if a disk, backup or storage object is exposed. Application-level encryption may be appropriate for particularly sensitive fields, but it increases key-management and operational complexity.

Hashing is a one-way transformation used for integrity checks and password storage. It is not encryption and should not be used when original data must later be recovered. Digital signatures provide integrity, authenticity and non-repudiation properties under defined assumptions: the signer uses a private key and recipients verify with the corresponding public key.

Key management is often more important than the choice of cipher. Keys require generation, controlled storage, rotation, access restriction, backup, revocation and eventual destruction. A key-management service or hardware-backed system can separate key access from application code. Key rotation does not eliminate compromise, but it limits the useful lifetime of a stolen key when old keys are retired correctly.

Secrets include passwords, API keys, tokens, certificates and database credentials. They must not be placed in source code, container images, tickets or ordinary configuration files. A secrets manager should provide controlled retrieval, audit records, versioning and rotation. Applications should receive only the secrets required for their function. Logging systems must also prevent accidental disclosure through request headers, query strings, exception messages or debug output.

Secure Software Supply Chains

A web application depends on operating systems, language runtimes, libraries, containers, build tools, cloud services and often outsourced components. A vulnerability or malicious change in any dependency can affect the final product. Supply-chain security therefore extends beyond code review.

Important controls include dependency inventories, lockfiles, vulnerability scanning, signed commits or artefacts, protected branches, reproducible or controlled builds, isolated CI runners, minimal build permissions and verification of provenance. A software bill of materials (SBOM) records component identities and versions, helping an organisation respond when a vulnerable library is discovered. Automated scanning is valuable but imperfect: it can produce false positives, miss novel vulnerabilities and fail to assess how a dependency is used.

The pipeline itself is a production system. Build credentials should be short-lived and scoped. Pull requests require review appropriate to risk. Release artefacts should be promoted rather than rebuilt differently for each environment. Secrets should be unavailable to untrusted code paths. Emergency patching procedures should exist for critical dependency vulnerabilities, while exceptions should be documented with expiry dates and owners.

Privacy Engineering and Responsible Data Use

Privacy is the appropriate governance of information about identifiable or reasonably identifiable people. It includes confidentiality but also collection, use, retention, sharing, transparency, access, correction and deletion. Legal obligations differ by jurisdiction and sector; architecture teams must obtain qualified legal and compliance guidance rather than assume that one checklist applies everywhere.

Privacy-by-design integrates privacy into requirements and architecture. Its practical principles include data minimisation, purpose limitation, retention limitation, user control, transparency, security and accountability. Data should be collected because a defined purpose requires it, not because storage is inexpensive. A retention schedule should specify why data is kept, when it is reviewed and how it is securely deleted or anonymised.

A privacy impact assessment is appropriate when processing is likely to create significant risks, such as large-scale profiling, sensitive data processing, monitoring or novel use of personal information. It should describe data flows, purposes, affected people, risks, safeguards and residual issues. Privacy-enhancing techniques include pseudonymisation, aggregation, access separation, tokenisation and, in appropriate analytical settings, differential privacy. Pseudonymisation reduces direct identification but does not make data anonymous if re-identification remains possible.

Responsible data use requires attention to fairness and power. A model trained on historical decisions may reproduce discriminatory patterns. A recommendation system may exploit behavioural vulnerabilities. Consent may be technically obtained but ethically weak if users cannot reasonably understand the purpose or refuse without disproportionate loss of service. Teams should test for disparate impacts, provide explanations appropriate to the context, maintain human review for high-impact decisions and establish appeal or correction mechanisms.

Accessibility, Ethics and Human Consequences

Accessibility is both a professional obligation and a quality attribute. A secure, fast application that cannot be used by people with visual, auditory, motor or cognitive disabilities is not an inclusive design. Accessibility should be addressed through semantic structure, keyboard operation, sufficient contrast, scalable text, captions, meaningful labels, error guidance and compatibility with assistive technologies. Automated tools can identify some defects, but user testing and manual review remain necessary.

Ethical architecture asks who benefits, who bears risk and who may be excluded. Dark patterns—interfaces that manipulate users into disclosure, purchase or continued participation—undermine autonomy. Excessive surveillance can alter behaviour even when data is never publicly disclosed. Security controls can also harm users if account recovery is inaccessible or fraud detection permanently blocks legitimate people without appeal.

Ethical review should be proportionate to impact. High-risk features require explicit assumptions, affected-stakeholder analysis, testing evidence, escalation routes and senior accountability. Engineers should be able to raise concerns without retaliation. Professional judgement is required when legal compliance is a minimum rather than a complete ethical answer.

Architecture Governance and Control Mechanisms

Architecture governance is the system by which architectural decisions are made, recorded, challenged and monitored. It does not mean that a central committee approves every technical choice. Effective governance sets principles, decision rights, control objectives and evidence requirements while allowing teams to deliver within defined boundaries.

A governance model commonly includes:

• security and privacy principles, such as least privilege and data minimisation;
• architecture decision records explaining alternatives, trade-offs and consequences;
• risk classification and control baselines for different data and service types;
• design reviews and threat-model sign-off for high-risk changes;
• policy-as-code for repeatable controls in infrastructure and deployment pipelines;
• independent assurance through audits, penetration tests and compliance reviews;
• operational metrics, incident reporting and periodic control effectiveness reviews.

Governance should distinguish standards, guidelines and exceptions. A standard is mandatory; a guideline permits professional judgement; an exception records a justified deviation, compensating control, owner and expiry. Permanent exceptions usually indicate that a standard or architecture is unrealistic. Governance must also define who can accept residual risk. Developers may identify risk, but acceptance of material organisational risk belongs to an authorised owner.

Useful metrics include the age of unresolved critical vulnerabilities, percentage of privileged accounts using strong authentication, time to revoke leavers, dependency coverage, backup restoration success, privacy-request completion and accessibility defect trends. Metrics should measure outcomes and control effectiveness, not merely activity. The number of security tickets, for example, says little without severity, recurrence and resolution context.

An Illustrative Case: A Multi-Tenant Learning Platform

Background

A fictional company, LearnSphere, operates a cloud platform used by universities and training providers. The platform stores learner profiles, assessment results, accessibility requirements and payment records. It uses a browser application, mobile clients, microservices, a managed database, third-party analytics and an automated deployment pipeline.

Situation and Problem

A planned analytics feature would combine learner activity with assessment data to predict students at risk of withdrawal. Product managers wanted rapid release and broad data access for analysts. A review identified shared service credentials, excessive retention of event data, inconsistent tenant checks in APIs, an analytics provider receiving more fields than necessary and a dashboard that was difficult to use with keyboard navigation.

Analysis

The threat model identified tenant-isolation failure, insider misuse, token theft, supply-chain compromise, unauthorised profiling and denial of service. The most serious risks involved integrity and confidentiality of assessment records and unfair consequences from an inaccurate prediction. The architecture also contained a trust boundary between the core platform and the external analytics provider.

Strategy and Solution

LearnSphere separated tenant identifiers and enforced object-level authorisation in every relevant service. It introduced workload identities, short-lived tokens and deny-by-default policies. Sensitive fields were excluded from analytics events; pseudonymous identifiers and aggregated measures were used instead. A privacy impact assessment defined the prediction purpose, retention period, user notice, access restrictions and human review requirement. Predictions were advisory rather than automatic, and students received a correction and appeal route.

The organisation placed secrets in a managed vault, restricted CI permissions, generated an SBOM and required signed release artefacts. Threat-model findings became architecture decision records with named owners. Accessibility testing added keyboard workflows, semantic headings, focus management and clearer error messages. A governance board approved the residual risks only after evidence of testing and a time-bound review date.

Outcome

The feature was released later than originally planned but with reduced data exposure, stronger tenant isolation and improved accountability. Monitoring detected unusual access patterns, while the review process made it possible to reassess the model when its training data changed. The case illustrates that governance is not merely a barrier to delivery: it clarifies acceptable use, reduces uncontrolled risk and preserves the organisation’s ability to defend its decisions.

Learning Points

Security, privacy, fairness and accessibility were interdependent. A technical control alone could not address the ethical risk of automated educational profiling. The most effective measures were introduced through architecture and delivery processes: data-flow analysis, explicit identity boundaries, least privilege, evidence-based release controls and accountable human oversight.

Challenges and Common Mistakes

Security programmes often fail through fragmented responsibility. Developers assume operations owns security, operations assumes a security team will review everything, and business owners do not recognise their responsibility for risk acceptance. Other common mistakes include purchasing tools without defining control objectives, equating compliance with safety, relying on perimeter firewalls, using long-lived credentials, logging sensitive data, and treating vulnerability counts as risk measurements.

Overly complex controls can create workarounds. Multi-factor authentication that repeatedly locks out legitimate users may encourage unsafe support practices. Excessive approval gates can cause teams to bypass governance. Controls should therefore be risk-based, usable, observable and tested in realistic conditions.

No architecture is perfectly secure. Zero-day vulnerabilities, social engineering, supplier failures and configuration errors remain possible. Resilience requires detection, incident response, backups, recovery exercises, communication plans and post-incident learning. Privacy and ethical commitments also require ongoing review because purposes, models, laws, suppliers and social expectations change.

Current Developments and Best Practice

Current architecture practice is moving toward identity-aware service meshes, passkeys and phishing-resistant authentication, confidential computing, software-signing frameworks, automated provenance, infrastructure policy-as-code and continuous control monitoring. Artificial intelligence is being used to support code review, anomaly detection and threat analysis, but generated code and automated decisions require human review, provenance checks, privacy safeguards and testing for bias or insecure patterns.

A mature organisation generally follows these practices:

1. Maintain an accurate asset, data-flow and dependency inventory.

2. Threat-model high-risk changes before implementation.

3. Use strong, contextual authentication and least privilege.

4. Separate duties and record security-relevant decisions.

5. Encrypt appropriately and manage keys and secrets centrally.

6. Secure dependencies, builds, artefacts and deployment identities.

7. Minimise personal data and define retention and deletion rules.

8. Test tenant isolation, authorisation, accessibility and recovery.

9. Provide human oversight, transparency and appeal for high-impact decisions.

10. Measure control effectiveness and review residual risk regularly.

Chapter Summary

Secure scalable architecture integrates confidentiality, integrity, availability, authenticity, privacy, resilience and accountability. Threat modelling connects assets and data flows to plausible technical and business threats. Zero trust replaces implicit network trust with continuous, context-aware verification and least privilege. IAM must distinguish authentication from authorisation and enforce permissions at the object level. Encryption, hashing, signatures, key management and secrets controls serve different purposes and must be operated correctly.

Software supply-chain security requires dependency visibility, protected pipelines, provenance and controlled artefacts. Privacy-by-design emphasises minimisation, purpose limitation, retention control, transparency and responsible use. Ethical architecture considers fairness, autonomy, accessibility and human consequences. Governance turns principles into decision rights, evidence, metrics, reviews and accountable risk acceptance. The strategic objective is not to eliminate all risk, but to make important risks visible, reduce them proportionately and ensure that remaining risks are consciously owned.

Key Terms

Threat model: A structured representation of assets, threats, vulnerabilities, mitigations and residual risks.

Attack surface: The set of interfaces and components through which a system can be attacked.

Trust boundary: A point where data or control passes between different security assumptions.

Zero trust: An architecture approach that avoids implicit trust and verifies access explicitly.

Identity and access management: Processes and technologies for identifying, authenticating and authorising subjects.

Least privilege: Granting only the permissions necessary for an approved task.

Role-based access control: Access control based primarily on assigned organisational roles.

Attribute-based access control: Access control determined by attributes and contextual policies.

Encryption: Reversible transformation of data using a key to protect confidentiality.

Hashing: One-way transformation commonly used for integrity checks and password storage.

Digital signature: Cryptographic evidence supporting message integrity and signer authenticity.

Secrets management: Controlled storage, retrieval, rotation and auditing of sensitive credentials.

Software bill of materials: An inventory of components included in a software product.

Data minimisation: Collecting and processing only data necessary for a defined purpose.

Pseudonymisation: Replacing direct identifiers while retaining a controlled possibility of linkage.

Privacy impact assessment: A structured assessment of privacy risks, safeguards and residual effects.

Dark pattern: An interface design that manipulates or pressures users against their interests.

Architecture decision record: A durable explanation of an important architectural decision and its trade-offs.

Residual risk: Risk remaining after controls have been implemented.

Policy-as-code: Machine-readable rules that automate the enforcement or verification of policies.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.

2. What is the purpose of a trust boundary in a data-flow diagram?

3. Why is password hashing different from encryption?

4. State two principles of privacy-by-design.

5. What information should an architecture decision record contain?

Long Answer Questions

1. Explain how threat modelling can influence the design of a distributed web application.

2. Discuss zero-trust principles and their implications for service-to-service communication.

3. Compare role-based and attribute-based access control, including their operational trade-offs.

4. Explain the controls required for a secure software supply chain.

5. Discuss how privacy, accessibility and ethical design should be incorporated into architecture governance.

Analytical / Application Questions

1. A multi-tenant API checks whether a user is logged in but not whether the requested invoice belongs to that user’s organisation. Identify the threat, explain its likely consequences and propose architectural controls.

2. An organisation wants to retain all user activity indefinitely so that future analytics questions can be answered. Analyse this proposal using minimisation, purpose limitation, retention and ethical principles.

3. A delivery team proposes storing a production database password in a private source repository to accelerate deployment. Evaluate the risks and design a safer pipeline and secrets-management approach.

22. Multiple Choice Questions with Answers

Question 1

A threat model identifies that a logged-in tenant administrator can retrieve another tenant’s invoice by changing an identifier in the URL. Which control most directly addresses this risk?

A. Increasing password length requirements

B. Object-level authorisation that checks tenant ownership

C. Encrypting the browser cache

D. Adding more detailed product analytics

Correct Answer: B. Object-level authorisation that checks tenant ownership

Question 2

Which statement best represents zero-trust architecture?

A. All requests inside the corporate network are trusted

B. A firewall is sufficient once external traffic is blocked

C. Access is explicitly verified using identity, context and least privilege

D. Users authenticate once and retain permanent access

Correct Answer: C. Access is explicitly verified using identity, context and least privilege

Question 3

Which technique is appropriate for storing user passwords?

A. Reversible encryption with one shared application key

B. Plain text storage protected by database permissions

C. A salted, slow password-hashing algorithm

D. Base64 encoding followed by compression

Correct Answer: C. A salted, slow password-hashing algorithm

Question 4

A digital signature primarily provides evidence of which properties?

A. Confidentiality and data minimisation

B. Integrity and signer authenticity

C. Availability and disaster recovery

D. Anonymity and irreversible deletion

Correct Answer: B. Integrity and signer authenticity

Question 5

Which practice most effectively reduces the risk of secrets leaking through a CI/CD pipeline?

A. Embedding credentials in container images

B. Using long-lived credentials shared by all build jobs

C. Using short-lived, scoped identities and a managed secrets service

D. Printing credentials in build logs for auditability

Correct Answer: C. Using short-lived, scoped identities and a managed secrets service

Question 6

What is the principal purpose of a software bill of materials?

A. To record the visual design of an application

B. To inventory components and support vulnerability response

C. To replace all penetration testing

D. To define employee job descriptions

Correct Answer: B. To inventory components and support vulnerability response

Question 7

Which proposal best follows privacy-by-design?

A. Collect every available field because storage is inexpensive

B. Retain personal data indefinitely in case a future purpose emerges

C. Collect only necessary data, define its purpose and enforce retention limits

D. Transfer raw user events to every analytics supplier

Correct Answer: C. Collect only necessary data, define its purpose and enforce retention limits

Question 8

Why might pseudonymisation fail to provide anonymity?

A. Pseudonymised data cannot be stored securely

B. A controlled or available link may permit re-identification

C. Pseudonymisation always removes data integrity

D. Pseudonymised data cannot support any analysis

Correct Answer: B. A controlled or available link may permit re-identification

Question 9

Which is the strongest example of effective architecture governance?

A. A committee approves every line of application code

B. Teams make undocumented decisions to maximise speed

C. High-risk decisions record alternatives, owners, evidence and residual risk

D. Compliance certificates replace technical testing

Correct Answer: C. High-risk decisions record alternatives, owners, evidence and residual risk

Question 10

An educational prediction model may disadvantage a group of students. Which response is most consistent with responsible data use?

A. Automatically deny services to students classified as high risk

B. Ignore fairness because the model is statistically accurate overall

C. Test disparate impacts, provide human review and offer correction or appeal

D. Hide the model’s purpose to prevent users from challenging it

Correct Answer: C. Test disparate impacts, provide human review and offer correction or appeal