Chapter 16 — Security architecture

Chapter 16 — Security architecture

Lesson map

Lesson 16 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["16.1 One identity provider"]
  N2["16.2 Placing controls"]
  N3["16.3 Keeping it simple"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["16.1 One identity provider"]
  N2["16.2 Placing controls"]
  N3["16.3 Keeping it simple"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]

[Learning outcomes]
    |
    v
[16.1 One identity provider]
    |
    v
[16.2 Placing controls]
    |
    v
[16.3 Keeping it simple]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) describe a target identity architecture for a small organisation; (2) place controls sensibly; (3) keep the design simple.

16.1 One identity provider

Elena's target architecture for Greenhill uses the office suite as the single identity provider. Systems that can, sign staff in through it with single sign-on; those that cannot are listed for replacement or careful separate management. Multi-factor authentication is enforced at the provider, so every connected system benefits. HR records drive account creation and removal. This arrangement follows a common pattern in which identity becomes the central control point, an idea also found in NIST SP 800-207's description of zero trust.

16.2 Placing controls

Controls sit where they work best. Strong sign-in is enforced at the provider. Detailed permissions, such as which tenant records a housing officer can see, stay in the housing system, which understands its own data. Administrator accounts are separate from everyday accounts and need security keys. Logging collects sign-in events from the provider. Elena draws these on a simple diagram, labelling each control with what it protects, so Greenhill's managers can see why each one is there. The diagram is updated whenever a control moves.

16.3 Keeping it simple

A small team needs a simple design. Elena avoids adding a second identity system, complex rules for every situation or many special exceptions. She proposes a few clear policies: everyone uses multi-factor, administrators use security keys, leavers are disabled on their last day, and access is granted by team groups. Simple designs are easier to explain, check and keep working after Elena leaves, which matters more at Greenhill than adopting every advanced feature available. Any new exception must be justified in writing and reviewed yearly.

Worked example

Elena's architecture diagram shows one provider, three single sign-on systems, three systems for replacement or separate management, and four simple policies.

Synthetic case. The architecture and systems are synthetic; NIST SP 800-207 is a real source.

Errors and limits

Adding complex rules and exceptions a small team cannot maintain lets the design decay quickly.

Exercises

• EX046 — Provider choice. What serves as Greenhill's identity provider? Rubric: 3 = the office suite;; 2 = office suite, hedged with another option;; 1 = finance;; 0 = none.
• EX047 — Permission placement. Where do detailed tenant-record permissions stay? Rubric: 3 = in the housing system;; 2 = application;; 1 = provider;; 0 = none.
• EX048 — Four policies. List Elena's four simple policies. Rubric: 3 = MFA for all, admin keys, leaver same-day disable, team groups;; 2 = three;; 1 = one;; 0 = none.

Synthesis

One identity provider, sensibly placed controls and a few clear policies suit a small organisation.

Continue studying — chapter 16 of 40

← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →