Chapter 34 — Security architecture and engineering: integration
Lesson map
Lesson 34 published. Map, example, EX100.
flowchart TD
N0["Learning outcomes"]
N1["34.1 Partner integrations"]
N2["34.2 API design for partners"]
N3["34.3 Shared responsibility"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX100"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["34.1 Partner integrations"]
N2["34.2 API design for partners"]
N3["34.3 Shared responsibility"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX100"]
[Learning outcomes]
|
v
[34.1 Partner integrations]
|
v
[34.2 API design for partners]
|
v
[34.3 Shared responsibility]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX100]
Learning outcomes
You will (1) secure integrations with external partners; (2) design API authentication and authorisation for partner access; (3) manage shared responsibility at integration boundaries.
34.1 Partner integrations
Corvia integrates with a payment provider, a regional mobility app that sells Corvia tickets, the energy supplier and a data-analytics consultancy. Each integration crosses a trust boundary and carries contractual and technical obligations. Sofia lists for each the data exchanged, the direction, the authentication method and the party responsible for each control. She finds that the mobility app uses a single long-lived API key shared by all its servers, while the consultancy receives monthly data exports by email. Both are integration weaknesses that the architecture should address.
34.2 API design for partners
Sofia proposes a partner API gateway. Partners authenticate with short-lived tokens obtained using client credentials bound to certificates, rather than static keys. Each token carries scopes limiting what the partner can do: the mobility app may sell tickets and query fares, but not read journey histories. The gateway enforces rate limits, validates schemas and logs every request with partner identity. Data exports to the consultancy move to a secure transfer service with pseudonymised data and access expiry. These choices apply least privilege and complete mediation at the boundary.
34.3 Shared responsibility
At every integration, some controls belong to Corvia and some to the partner. Sofia writes a responsibility matrix: Corvia protects the gateway and validates requests; the partner protects its credentials and its own users; both must report incidents within agreed times. The matrix is attached to contracts. When the mobility app later suffers a breach of its own customer accounts, the matrix makes clear which party notifies which passengers and which tokens Corvia revokes. Clarity about responsibility avoids gaps where each party assumes the other handles a control.
Worked example
Sofia inventories four partner integrations, replaces a shared static API key with certificate-bound short-lived scoped tokens and writes a responsibility matrix used during a partner breach.
Synthetic case. Partners, integrations and the breach are synthetic.
Errors and limits
Gateways become single points of failure and must be resilient. Contracts cannot force partners to secure their own systems.
Exercises
- EX100 — Two weaknesses. Which two integration weaknesses did Sofia find? Rubric: 3 = mobility app's shared long-lived API key; consultancy exports by email;; 2 = both;; 1 = one;; 0 = none.
- EX101 — Scope example. What may the mobility app's tokens allow, and not allow? Rubric: 3 = sell tickets and query fares, not read journey histories;; 2 = both parts;; 1 = all access;; 0 = none.
- EX102 — Matrix in breach. How did the responsibility matrix help during the partner breach? Rubric: 3 = clarified who notifies passengers and which tokens Corvia revokes;; 2 = clarity;; 1 = vague;; 0 = none.
Synthesis
Secure integration combines scoped, short-lived credentials at gateways with written shared responsibility.
Continue studying — chapter 34 of 50
← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →