◇ OpenCyber Academy
Engineering · Chapter 26 · English

Chapter 26 — Information security: architecture alternatives

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 26 — Information security: architecture alternatives

Lesson map

Lesson 26 published. Map, example, EX076.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Perimeter models"]
  N2["26.2 Identity-centred models"]
  N3["26.3 Cloud and on-premises"]
  N4["26.4 Choosing"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX076"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Perimeter models"]
  N2["26.2 Identity-centred models"]
  N3["26.3 Cloud and on-premises"]
  N4["26.4 Choosing"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
    |
    v
[26.1 Perimeter models]
    |
    v
[26.2 Identity-centred models]
    |
    v
[26.3 Cloud and on-premises]
    |
    v
[26.4 Choosing]
    |
    v
[Worked example] --> [Exercise EX076]

Learning outcomes

You will (1) compare perimeter and identity-centred architectures; (2) evaluate cloud and on-premises options; (3) choose an architecture with recorded reasons.

26.1 Perimeter models

Saltmarsh's traditional architecture trusts devices inside the network and defends the edge with firewalls. Lindiwe notes that this model weakens when staff work remotely, applications move to cloud services and attackers enter through phishing. Once inside, an attacker inherits trust. Prof. Hale explains that the perimeter remains useful but is no longer sufficient, because the line between inside and outside has blurred for most organisations. Lindiwe illustrates this with a synthetic incident in which a phished laptop on the internal network reached a file share holding payroll exports, because nothing inside the firewall checked who was asking.

26.2 Identity-centred models

An alternative checks identity, device health and context for every request, regardless of network location. Lindiwe sketches how Saltmarsh's dispatch application would work: each request is authenticated, the device is checked for current patches and access is limited to the user's role. This approach follows Saltzer and Schroeder's complete mediation principle. She notes it requires mature identity management, device inventory and logging, which Saltmarsh only partly has. She lists the missing capabilities: a complete device inventory, consistent device health reporting and logging for every application access decision.

26.3 Cloud and on-premises

Saltmarsh is considering moving payroll to a cloud service. Lindiwe compares security responsibilities: the provider secures its infrastructure, while Saltmarsh remains responsible for user accounts, configuration and data. She lists questions for the provider about encryption, logging, certifications and incident notification. Prof. Hale warns that cloud services shift responsibilities but do not remove them, and that misconfigured cloud storage has caused many exposures. She drafts the provider questionnaire with twelve questions, and the procurement team agrees to send it with the tender documents.

26.4 Choosing

Lindiwe recommends a staged approach: keep segmentation and firewalls, move high-value applications behind identity-aware access first and evaluate cloud payroll with a contract review. She records the decision with reasons: risk reduction for remote access, feasibility given current identity maturity and cost. Prof. Hale notes that architecture choices are rarely all-or-nothing, and that a staged path lets an organisation build the capabilities each step requires. The managing director approves the first stage, starting with dispatch and payroll. Lindiwe sets a review after six months to decide whether the next stage should proceed.

Worked example

Lindiwe compares perimeter and identity-centred models, lists shared responsibilities for cloud payroll and recommends a staged transition with recorded reasons.

Synthetic case. Architectures are synthetic.

Errors and limits

Moving to a cloud service does not transfer responsibility for accounts and configuration.

Exercises

Continue studying — lesson 26 (chapter 26 of 50)

← Chapter 25 · Course chapter index · Chapter 27 →

Continue to the next authored lesson.