-
Notifications
You must be signed in to change notification settings - Fork 45
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #931 from alphagov/review-access-control-page
Update Tracking access control page
- Loading branch information
Showing
1 changed file
with
8 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,23 +1,25 @@ | ||
--- | ||
title: Tracking Access Control | ||
last_reviewed_on: 2022-10-26 | ||
last_reviewed_on: 2024-07-26 | ||
review_in: 6 months | ||
--- | ||
# <%= current_page.data.title %> | ||
|
||
You should track the list of users who have access to secrets by logging the permissions, such as accounts and credentials, associated with a security resource in a single, centralised Access Control List (ACL). | ||
The ACL specifies who or what is allowed to access the resource containing secrets and the operations which are allowed to be performed on the resource. Also see Principle of Least Privilege for authentication and authorisation guidance. | ||
|
||
ACL repositories used to log access to systems for storing and processing secrets should have designated colleagues within each directorate responsible for reviewing access granted on a defined periodic cadence (e.g. monthly, quarterly). | ||
The ACL specifies who or what is allowed to access the resource containing secrets and the operations which are allowed to be performed on the resource. See [Principle of Least Privilege](/standards/principle-least-access.html) for guidance on minimising access rights. | ||
|
||
User access rights must be reviewed when people change roles or teams as part of your joiners, leavers and movers process. ACLs should also be regularly reviewed on a predefined cadence (e.g. monthly, quarterly). | ||
|
||
Identified exceptions should be raised with the colleague responsible for risk management in the directorate for escalation. | ||
|
||
Teams ACL review should be documented to reflect: | ||
|
||
* who (colleague) completed the review | ||
* date review is undertaken | ||
* next review date | ||
* any changes to user status granted access, and the reason for change (if any). | ||
* refer to new joiner, mover and leaver access process to reflect change in access status | ||
* any changes to user status granted access, and the reason for change (if any) | ||
|
||
## Further guidance | ||
- [NCSC - 10 steps to cyber security](https://www.ncsc.gov.uk/collection/10-steps) | ||
- [How to manage access to your third-party service accounts](/standards/accounts-with-third-parties.html) | ||
- [NCSC Cyber Assessment Framework - Principle B2 Identity and Access Control](https://www.ncsc.gov.uk/collection/cyber-assessment-framework/caf-objective-b/principle-b2-identity-and-access-control) |