◇ OpenCyber Academy
Technical · Chapter 3 · English

Chapter 3 — Operating systems and identities

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 3 — Operating systems and identities

Lesson map

Lesson 03 published. Map, example, EX009.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Users and groups"]
  N2["3.2 Cloud IAM"]
  N3["3.3 Least privilege"]
  N4["3.4 Service identities"]
  N5["3.5 Role-based access"]
  N6["Reviewing permissions"]
  N7["Leavers"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX009"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Users and groups"]
  N2["3.2 Cloud IAM"]
  N3["3.3 Least privilege"]
  N4["3.4 Service identities"]
  N5["3.5 Role-based access"]
  N6["Reviewing permissions"]
  N7["Leavers"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX009"]

[Learning outcomes]
    |
    v
[3.1 Users and groups]
    |
    v
[3.2 Cloud IAM]
    |
    v
[3.3 Least privilege]
    |
    v
[3.4 Service identities]
    |
    v
[3.5 Role-based access]
    |
    v
[Reviewing permissions]
    |
    v
[Leavers]
    |
    v
[Worked example] --> [Exercise EX009]

Learning outcomes

You will (1) explain users, groups and service identities; (2) describe cloud identity and access management; (3) apply least privilege to storage.

3.1 Users and groups

Operating systems grant permissions to users and groups. Cloud platforms do the same with identities, roles and policies, but over the internet and across many services. On a single server, Tomás would check which users belong to which group and what files the group can read. In Fairway's cloud account the same question becomes which identities, human or service, can act on each bucket and its policy. The idea is familiar, but the reach is wider, because one identity can touch every service in the account.

3.2 Cloud IAM

Each provider's identity and access management service decides which identity may perform which action on which resource. The developer, dev-sam, had permission to change bucket policies, which is why he could make the bucket public. Nothing in the provider's logs suggests misuse of credentials; dev-sam used a permission he had been given. That is an important point for the review, because the fix lies in what identities are allowed to do, not in catching an intruder. The permission list he shared with other developers is the first thing Tomás exports.

3.3 Least privilege

Developers need to upload objects, not change bucket policies. Removing that permission would have prevented the incident. For Fairway, least privilege means developers can upload and read objects in the buckets they work on, while changing a bucket policy needs the operator role. dev-sam's need to share a file would then have reached an operator, who could have arranged a safer method. Tomás proposes the change and agrees it with the developers before it is applied, since removing access can break routine work.

3.4 Service identities

The CI deploy pipeline uses its own identity to upload website assets. It should be limited to the assets bucket. His permission list shows CI deploy could write to every bucket, including manifests and backups, although it only ever uploads website assets. A compromised pipeline token could therefore overwrite or plant files in sensitive buckets. Limiting it to site-assets removes that risk without affecting deployments, and the later troubleshooting work shows exactly which extra permission it still needs. Grace approves the narrowed scope before it is applied in staging.

3.5 Role-based access

Sandhu et al. (1996) describe role-based access control. Fairway defines roles such as developer, operator and auditor with set permissions. Roles let Fairway grant permissions to a job rather than to each person. The developer role carries object upload and read, the operator role carries policy changes, and the auditor role can read settings and logs but change nothing. Tomás uses the auditor role for his own review work, which keeps his access read-only, as the written scope requires. Each identity is assigned exactly one role, recorded in the permission list.

Reviewing permissions

Permission reviews compare what each identity is allowed to do with what it actually does. Provider tools can list unused permissions, and Fairway's own audit logs show which actions were used in the last ninety days. dev-sam had never changed a bucket policy before March, which supports removing the permission: it was not needed for normal work. Tomás schedules a quarterly review using the same method.

He also checks that Grace's administrator account uses multi-factor authentication and is used only for administrative tasks, not daily work.

Leavers

Accounts of staff who leave are disabled on their last day.

Worked example

Tomás lists permissions for three identities. Developer: upload, read and change policies on all buckets. CI deploy: write to all buckets. Grace: administrator. He proposes removing policy changes from developers and limiting CI deploy to site-assets.

Synthetic case. Identities are synthetic.

Errors and limits

Removing permissions can break workflows; agree changes with the people affected.

Exercises

Synthesis

Give identities only what their work requires.

Continue studying — chapter 03 of 18

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →