◇ OpenCyber Academy
Professional · Chapter 2 · English

Chapter 2 — Cloud and container security: service and stakeholder context

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 2 — Cloud and container security: service and stakeholder context

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 The service"]
  N2["2.2 Stakeholders"]
  N3["2.3 Concerns"]
  N4["2.4 Agreeing priorities"]
  N5["2.5 Communication plan"]
  N6["Mapping data"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 The service"]
  N2["2.2 Stakeholders"]
  N3["2.3 Concerns"]
  N4["2.4 Agreeing priorities"]
  N5["2.5 Communication plan"]
  N6["Mapping data"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 The service]
    |
    v
[2.2 Stakeholders]
    |
    v
[2.3 Concerns]
    |
    v
[2.4 Agreeing priorities]
    |
    v
[2.5 Communication plan]
    |
    v
[Mapping data]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

You will (1) describe the permit service and its components; (2) identify stakeholders and their concerns; (3) agree priorities.

2.1 The service

The permit service has a public web front end (permits-web), a background worker that issues permits (permits-worker), a reporting job used by the parking team, a managed database and a storage bucket for uploaded documents such as proof of address. A deployment bot builds and deploys images. Each part has its own identity, and the audit found excess permissions on several of them. The worker and web front end share the permits-app role, which matters because a weakness in the internet-facing front end would give an attacker the worker's permissions too. Hannah draws a simple diagram of the parts, roles and data flows before collecting evidence.

2.2 Stakeholders

Residents want a working, private service. The parking team wants accurate reports. The digital team builds the application. Internal audit wants findings closed with evidence. The data protection officer cares about uploaded documents. Dev cares about stability. Each stakeholder judges the project by a different result, so Hannah writes their interests down at the start. Residents never attend meetings, so she represents their interest through the security goals. The data protection officer reviews anything touching the document bucket, and audit receives evidence in the form it asked for. Dev's concern for stability shapes the decision to change one thing at a time.

2.3 Concerns

Developers worry that removing permissions will break deployments. Audit wants dates. The parking team fears losing reports during changes. Each concern is reasonable and points to a safeguard. Developers' fear of breakage leads to testing every permission removal in staging first. Audit's need for dates leads to a timeline with a deadline for each finding. The parking team's worry about reports leads Hannah to schedule changes to the reporting job outside the times when reports are run. She records each concern with the safeguard that answers it, so stakeholders can see that their worries shaped the plan.

2.4 Agreeing priorities

Hannah holds a short meeting where each stakeholder states their main concern. They agree: protect resident data first, keep the service available, close audit findings within three months. The order matters when concerns conflict: if a fix risks breaking the service, it is tested and scheduled carefully rather than rushed, but resident data still comes first. Hannah writes the agreed priorities into her method note, so later decisions can refer to them. The three-month target becomes the deadline in the audit plan, and each finding is given an owner and a date.

2.5 Communication plan

A fortnightly update goes to all stakeholders, in plain language, showing progress and planned changes. The update lists what changed since the last one, what is planned before the next, and any decisions needed. Writing in plain language matters because the parking team and data protection officer are not cloud specialists. Hannah keeps each update to one page and sends it on the same day each fortnight, so stakeholders know when to expect it. Questions raised in replies are answered in the next update for everyone to see.

Mapping data

Hannah lists what data each component handles. Permits-web and the worker handle names, addresses and vehicle registrations. The bucket holds uploaded proof-of-address documents, the most sensitive data in the service. Reporting reads aggregated counts for the parking team and needs no personal details. This map tells her which roles and images matter most: anything touching the bucket or the database comes first.

She confirms the map with the data protection officer, who adds that uploaded documents must be deleted after twelve months.

Worked example

The digital team lead asks whether security changes will slow releases. Hannah proposes that each permission removal is tested in staging with the team, and that she will be available on change days. The lead agrees to a trial.

Synthetic case. Synthetic.

Errors and limits

Ignoring a stakeholder's concern often turns them into an obstacle later.

Exercises

Synthesis

Understand the service and its people before changing it.

Continue studying — chapter 02 of 12

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →