Lesson Overview
In the previous lessons you learnt that identity is the master key, and that accounts are created, changed, and removed through the joiner, mover, leaver lifecycle. This lesson is about the next question. Once a person has proven who they are, what should they actually be allowed to do? That is authorisation, and getting it right is what keeps a small force from quietly handing too much power to too many people.
Most of the damage in a serious breach is not done at the front door. An attacker who steals one credential, or an insider who simply has more access than they need, can reach far if accounts are over-provisioned. The defence is dull, deliberate, and powerful: give each account only what its role requires, grant access by role rather than person by person, split the most sensitive processes so no single person controls them, keep administrative power separate and tightly held, and review access regularly so it does not silently grow. Throughout, one rule from the specialities framework governs everything: access follows appointment, never merely a qualification.
This is the knowledge layer. It teaches you the principles and the vocabulary so that you can reason about access correctly and challenge it when it looks wrong. The hands-on practice, defining a role and its permissions in the identity service, running an access review, raising and approving a change through separation of duties, is done and signed off in person where supervision allows. By the end you will be able to explain authorisation against authentication, apply least privilege and need to know, describe role-based access control and why it is used, recognise where separation of duties is required, describe how privileged access is managed, and explain privilege creep and how reviews remove it.
Key Terms
- Authorisation: what an account is allowed to do once it has been authenticated. It is a different problem from proving who you are, and it has to be decided and enforced separately.
- Least privilege: the principle that an account is given only the access its role needs to do its work, and no more. The default is no access; access is added on purpose.
- Need to know: seeing only the specific data a task requires, even within an area you are otherwise allowed into. Being authorised for a register does not mean reading every record in it.
- Role-based access control (RBAC): granting access to defined roles, and assigning people to roles, rather than granting permissions to individuals one by one. Access becomes consistent and reviewable.
- Permission: a single specific right, for example "read the register of national identity cards" or "approve a vital event". Roles are built from permissions.
- Separation of duties: arranging a sensitive process so that no single person controls it from end to end. The person who requests an action is not the only person who can approve it.
- Privileged access: elevated rights that can change a system, other accounts, or large amounts of data, for example administrator or super-user access. It is powerful and is treated with extra care.
- Privileged access management (PAM): the discipline of keeping administrative accounts separate from everyday ones, granting elevated access only just enough and just in time, and monitoring its use.
- Just-in-time access: granting elevated rights only for the period they are needed for a specific task, then removing them, rather than holding them permanently.
- Privilege creep: the slow accumulation of access as a person moves between roles and tasks, picking up new rights while keeping old ones they no longer need.
- Access review (recertification): a periodic check that everyone still genuinely needs the access they hold, with the excess removed.
- Access follows appointment: the framework rule that access is tied to the post a person holds, not to any qualification, course, or rank they carry. Completing this course grants no access.
Authorisation Against Authentication
It is worth being precise, because the two words sound similar and people muddle them. Authentication answers "are you really who you claim to be?" It is the password, the passkey, the authenticator code. Authorisation answers "now that I know who you are, what may you do?" A perfectly authenticated user can still be wrongly authorised, given access to records that have nothing to do with their work.
A small force tends to put effort into authentication, MFA, strong passphrases, certificates, and then leave authorisation loose, because in a tight-knit team it feels natural to trust everyone with everything. That instinct is exactly the risk. Trust in the person is not the same as access for the account. The account is what an attacker steals, and the account should carry only what the role needs.
So this lesson assumes authentication is already solved (it is the subject of Lesson 01 and of CIS 201) and concentrates entirely on the second question: granting access well.
Least Privilege and Need to Know
Least privilege is the foundation. An account is given only what its role requires, and the starting position is that it has nothing. You add access on purpose, for a reason you could state aloud, never "just in case" or "to be helpful".
Need to know is the same idea applied to data. Being authorised to use the register system does not entitle you to read every national's record in it. You see the records your task touches. A registrar correcting one person's date of birth needs that record, not the whole register exported to a spreadsheet.
The benefit is containment. If an account is compromised, the attacker inherits exactly that account's access and no more. A tightly scoped account is a small blast radius. An over-privileged one is a large one. The figure below contrasts two accounts doing the same job.
LEAST-PRIVILEGE vs OVER-PRIVILEGED (same person, same task: fix one record)
Task: correct one national's address in the register
--------------------------------------------------------------
LEAST PRIVILEGE OVER-PRIVILEGED
--------------------------------------------------------------
Read that record yes yes
Edit that record yes yes
Read whole register no yes (not needed)
Export register no yes (not needed)
Delete records no yes (not needed)
Manage other accounts no yes (not needed)
System admin no yes (not needed)
--------------------------------------------------------------
If this account is stolen, the attacker gets...
one record's edit rights the entire register
+ account control
--------------------------------------------------------------
Blast radius: small, contained large, state-wide
Both accounts complete the task. Only one of them limits the damage when, not if, a credential is eventually lost or phished.
Role-Based Access Control
Granting permissions to individuals one at a time does not scale and does not stay correct. Within a few months you have dozens of accounts each with a slightly different, undocumented bundle of rights that nobody can describe. When someone changes job, no one knows what to remove.
Role-based access control fixes this. You define a small number of roles that match the real jobs people do. Each role is a named bundle of permissions. People are then assigned to roles. Access is granted to the role, never to the person directly. The table below shows a small example mapping.
RBAC: ROLES -> PERMISSIONS (Y = granted, . = not granted)
read edit approve manage system
Role records records events accounts admin
------------------------------------------------------------------
Records Clerk Y Y . . .
Registrar Y Y Y . .
Account Administrator . . . Y .
System Administrator . . . . Y
Read-Only Reviewer Y . . . .
------------------------------------------------------------------
People are assigned to a ROLE; the role carries the permissions:
Private Adesanya -> Records Clerk
Sergeant Okoro -> Registrar
Corporal Vella -> Account Administrator
Three things follow from this, and they are the whole reason RBAC is used:
- Consistency. Everyone who does the same job has the same access. No drift, no special cases that nobody remembers.
- Reviewability. You can read the table and say what any person can do, because you only have to know their role. Access becomes auditable, which Lesson 10 builds on.
- Easy change. When a person moves to a new job, you change their role, and their access changes with them. This is the mover step from Lesson 02 made practical.
Notice that the Account Administrator and System Administrator roles in the table have no records access at all. That is deliberate, and it leads to the next two ideas.
Separation of Duties
Some processes are sensitive enough that no single person should control them from beginning to end. The classic shape is the requester and the approver. The person who asks for an action should not be the only person who can approve it. If one account can both raise a change to a national's record and sign it off, then one compromised account, or one dishonest moment, is enough to do anything with no second pair of eyes.
Separation of duties splits the process across at least two people or two roles, so that a sensitive action requires agreement. It is not about distrust of individuals. It is a control that protects the honest majority, gives every action a witness, and means a single stolen credential cannot complete a sensitive process alone.
In a small force this needs care, because you may genuinely have very few people. The answer is not to abandon the principle but to apply it where it matters most: granting privileged access, changing nationals' records, issuing or revoking credentials and keys, and approving deletions or retention changes. For everyday low-risk work, a single competent person is fine. Reserve the second signature for the actions that would hurt if they went wrong.
Privileged Access Management
Administrative access, the power to change a system, reset other accounts, or read and alter large amounts of data, is the most valuable thing an attacker can reach. So it is held differently from everyday access. Three rules cover most of it.
First, separate accounts. A person who needs administrative power has two accounts: an ordinary one for daily work, email, browsing, routine tasks, and a separate administrative account used only when administrative work is actually being done. You never read email or open links from the admin account. This means a phishing click in everyday work cannot directly hand over the keys to the system.
Second, just enough and just in time. Elevated access is granted at the smallest scope that does the job, and only for the period it is needed. Where the identity service supports it, an administrator requests elevation for a specific task, uses it, and it falls away afterwards, rather than carrying standing administrative rights all the time. Less standing privilege means less for an attacker to steal at any given moment.
Third, monitor its use. Every use of privileged access is logged and reviewed, so that misuse or a stolen admin credential is visible. This connects directly to the audit discipline of Lesson 10.
PRIVILEGED ACCESS: EVERYDAY vs ADMIN, JUST-IN-TIME
Corporal Vella, Account Administrator
----------------------------------------------------------
Everyday account (vella) used all day:
email, browsing, routine tasks
NO administrative rights
----------------------------------------------------------
Admin account (vella-adm) used only to administer:
no email, no web browsing, no links opened
elevation REQUESTED for a task ---> used ---> removed
| |
logged logged
----------------------------------------------------------
Result: a phishing click in the everyday account
cannot directly surrender admin power.
Privilege Creep and Access Reviews
Even with good roles, access tends to grow over time. A person joins, gets the access for their role, then helps with a project and is granted extra rights for it, then moves to a new role and gains its access, but the old rights are rarely taken away because nobody is sure they are safe to remove. This slow accumulation is privilege creep, and after a year or two the most senior, longest-serving, most trusted people often hold the widest and least justified access of anyone, which is precisely the access an attacker would most want.
The cure is the access review, sometimes called recertification. At a regular interval you go through who has what and confirm, for each grant, that the person still needs it for their current appointment. Anything that cannot be justified is removed. Reviews are where the mover step of the lifecycle is actually enforced, because in practice people often gain new access cleanly but shed old access only when a review forces the question. A good review asks of every grant: does this person still hold the appointment this access belongs to, and does that appointment still need it? If the answer is no, the access goes.
This is also where the framework rule does its work. Access follows appointment, not qualification. A member does not keep records access because they passed CIS 220, and does not gain it by holding a certificate or a rank. They have it because they currently hold a post that requires it, and when that appointment ends, the access ends with it, promptly, exactly as Lesson 02 described for the leaver and the mover. The review is the moment you check that this is still true.
In Practice: A Quarterly Access Review
Sergeant Okoro is the Registrar and has been asked to run the quarterly access review for the records system, working with Corporal Vella, the Account Administrator, so that no one is reviewing only their own access.
They pull the current list of accounts and roles from the identity service. Most are clean: clerks hold the Records Clerk role, reviewers hold Read-Only Reviewer, and each maps to a current appointment. Three things stand out.
First, a private who helped with a data-tidying project six months ago still holds an export permission granted for that task. The project ended; the appointment that justified the permission no longer exists. Vella removes it. This is privilege creep caught and corrected.
Second, an administrative account belongs to a member who moved to a non-technical post last month. The everyday account was kept, correctly, but the separate admin account, vella-adm style, was never deprovisioned. A standing admin account with no current appointment behind it is exactly the orphaned risk Lesson 02 warned about. They disable it the same day and note it for the audit log.
Third, Okoro notices that one clerk can both raise and approve corrections to nationals' records, because a permission was bundled in by mistake. That breaks separation of duties on a sensitive process. They split it so corrections now require a second approver, and record why.
None of this is glamorous, and none of it involved a single attack. It is the quiet removal of access that had outlived its appointment, which is most of what keeps a digital state safe.
Check Your Understanding
- Explain the difference between authentication and authorisation, and give one reason a force that has strong authentication can still be at serious risk through authorisation.
- A member is moved from a records post to a logistics post. Using least privilege and the mover step, describe what should happen to their records access and why "just add the new access" is not enough.
- Why are administrative accounts kept separate from everyday accounts, and what does "just enough and just in time" add on top of that separation?
Reflection (write a short paragraph): Think about a system, account, or shared login you currently have access to, in or out of the Army. Honestly, is all of that access still needed for what you actually do today, or has some of it crept in and stayed? Write about how you would decide what to give back, and what makes it uncomfortable to hand access back even when you no longer need it.
Summary
- Authorisation is a separate problem from authentication: once we know who you are, we must still decide, and enforce, what you may do.
- Least privilege and need to know keep each account scoped to exactly what its role and task require, so a stolen credential has a small blast radius.
- Role-based access control grants access to roles, not individuals, making access consistent, reviewable, and easy to change when people move.
- Separation of duties splits sensitive processes so no single person, or single compromised account, controls them end to end; the requester is not the sole approver.
- Privileged access management keeps admin accounts separate from everyday ones, grants elevation just enough and just in time, and monitors its use.
- Privilege creep is the silent accumulation of access over time; regular access reviews remove the excess and enforce the rule that access follows appointment, not qualification.
- This builds directly on Lesson 01 (identity as the master key) and Lesson 02 (joiner, mover, leaver), and leads into Lesson 04 (protecting credentials, keys, and secrets) and Lesson 10 (audit, review, and accountability). It supports PME 210 on custody of records and shares the disciplined mindset of SIG 220 · Communications Security and Digital Discipline.
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia