Chapter 21 — Security architecture and engineering: service integration

Chapter 21 — Security architecture and engineering: service integration

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 A new partner"]
  N2["21.2 Protecting credentials"]
  N3["21.3 Limiting the partner"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 A new partner"]
  N2["21.2 Protecting credentials"]
  N3["21.3 Limiting the partner"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 A new partner]
    |
    v
[21.2 Protecting credentials]
    |
    v
[21.3 Limiting the partner]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) integrate a new partner service securely; (2) protect API credentials; (3) limit what a partner can do.

21.1 A new partner

Brightwater signs a contract with a parcel locker network so customers can collect parcels from lockers. The locker company needs delivery events and receives collection confirmations back. Tomás reviews the integration plan with the developer. Data flows through an application programming interface over HTTPS. He asks what data the locker company truly needs: parcel identifier, locker location and a collection code, but not the customer's home address or phone number. Minimising shared data limits harm if the partner is breached.

21.2 Protecting credentials

The locker API uses keys to authenticate each side. Tomás insists keys are stored in the cloud provider's secrets manager rather than in code or configuration files, are different for test and production, and are rotated every six months. Incoming messages from the locker company are signed so Brightwater can verify their origin. He follows the secure development practices in NIST SP 800-218, which calls for protecting secrets and reviewing third-party components. A leaked key would let an attacker mark parcels as collected.

21.3 Limiting the partner

The locker company's key can only report collection events for parcels assigned to its lockers; it cannot query other parcels or change routes. Tomás tests this by attempting to fetch an unrelated parcel with the partner's test key, which is correctly refused. He documents the integration in the architecture diagram as a new trust boundary and adds alerting for unusual volumes of collection events. Each integration expands the attack surface, so limits and tests should be built in from the first day.

Worked example

Tomás minimises data shared with a locker partner, protects API keys in a secrets manager and tests that the partner key cannot query unrelated parcels.

Synthetic case. The partner and API are synthetic; SP 800-218 is real.

Errors and limits

Partners may change their systems without notice. Secrets managers create a dependency.

Exercises

• EX061 — Data not needed. Which data does the locker company not need? Rubric: 3 = home address and phone number;; 2 = contact details;; 1 = collection code;; 0 = none.
• EX062 — Key leak impact. What could an attacker do with a leaked locker key? Rubric: 3 = mark parcels as collected;; 2 = false collection;; 1 = vague;; 0 = none.
• EX063 — Limit test. How did Tomás test the partner's limits? Rubric: 3 = tried fetching an unrelated parcel with the test key; refused;; 2 = test;; 1 = vague;; 0 = none.

Synthesis

Secure integrations share minimal data, protect keys and enforce tested limits on what partners can do.

Continue studying — chapter 21 of 30

← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →