What least privilege is

The principle of least privilege is where access is specific to each person’s requirements. Everyone gets the minimum level of access needed to do their job.

Applying the right levels of access

How to implement least privilege

To implement the least privilege, IT leads should check:

• only authorised people can access the system or resources – for example, teachers should not have access to a colleague’s human resource files
• only the permissions required are assigned – for example, students should not have the ability to delete teachers’ comments and posts
• the user management admin role is assigned to a staff member helping managing users instead of the super admin role
• there are a reasonable number of accounts with administrator privileges – for example, 2 to 3 administrators for Google Workspace or Microsoft 365.

Make sure there’s a process to review and check these and implement this approach when you get new software.

CERT NZ has guidance on how to enforce the principle of least privilege and how to decide which permissions to give.

Enforcing the principle of least privilege – CERT NZ

Deciding which permissions to give – CERT NZ

Understanding access based on role

Role-based access control (RBAC) is a method for managing user access to systems by assigning permissions to roles rather than individuals. It is considered good practice to ensure the right level of access is applied.

We recommend putting staff into different groups (organisational units) based on what permissions and access they need. For example:

• staff
• principal and deputy principal(s)
• teachers
• administrative and office staff
• IT lead 
• students and whānau | families
• student
• parents, caregivers, families.

For each group, consider:

• what systems or applications each person needs to access to do their job
• the minimum amount of access they require for each of these systems.

Use this method by giving permission with organisational units (OU) and groups in Google Workspace and groups in Microsoft.

Overview of Microsoft 365 Groups for administrators - Microsoft 365 admin | Microsoft Learn

Add an organisational unit - Google for Education Help

We recommend putting staff into different groups or OU based on what permissions and access they need. If someone needs a slightly different permission set, put them in a new group or give the individual the extra access they need rather than giving the whole group the additional access. Regularly check to see if they still need the additional access.

Least privilege for IT leads and administrators

Limit the number of administrators

Keep the number of accounts with administrator privileges to a minimum.

We recommend having at least 2 super administrator or global administrator accounts but less than 4. This ensures support if an administrator is sick or on leave.

Separate accounts for everyday use and administrator tasks

Administrator accounts are more at risk if they are compromised. IT leads should have separate accounts for everyday use and administrator tasks.

Set up least privilege with Microsoft

The following links provide guidance on how to best implement least privilege for Microsoft 365.

Best practice for Microsoft Entra roles – Microsoft

Enhance security with the principle of least privilege – Microsoft

Set up least privilege with Google Workspace

The following links provide guidance on how to set up admin roles and security best practices on Google Workspace.

Admin roles for business – Google Workspace

Security best practices for administrator accounts – Google Workspace

Set up least privilege with other systems

Review your other systems and applications to make sure least privilege is applied. The vendors of your systems may provide guidance on how to edit and review access and permissions.

Some systems have RBAC groups or templates that can be created to make assigning permissions easier.

Prioritising systems for least privilege

Ideally, least privilege should be implemented for all systems used by your school or kura.

When implementing least privileges, your school should prioritise systems that are:

• used as your school’s Identity Provider (such as Google Workspace and Microsoft 365) and for Single Sign-On (SSO) to other applications
• considered critical to your school’s operation
• hold sensitive information and may raise privacy concerns.

Monitoring and maintaining the right levels of access

Robust processes need to be in place to support the IT lead to implement least privilege. The following processes should be documented and carried out in practice.

Periodic access reviews

Access reviews should determine whether access is right for the user, or if they need permissions removed or added.

They should be done at least every 6 months for all systems and applications. Your IT lead can decide the frequency of these reviews, depending on your school's needs.

When doing access reviews, you should check:

• access and permissions – all access and permissions are still relevant for each role
• last login – assessing whether the user needs access for their role, for example, whether they have logged in during the past 3 months
• When staff leave – you may wish to run through the list of users with the role that oversees the offboarding process (check if any of these users ring a bell as having left the school)
• user activity and reviewing logs – spot checks of audit logs (logs showing a staff member modifying a resource they shouldn’t have access to).

Onboarding and offboarding procedures

Your onboarding or role change process should consider what access and permissions are required when a new staff member starts. A template is provided below.

This template also should be updated to provide a current profile of the list of systems and permissions that are allocated to a staff member. This will make the offboarding process easier for the IT administrator.

Inventory of school systems and recordkeeping

An inventory of systems and applications that your school uses will help aid the implementation of least privileges.

A spreadsheet can be used. The IT lead can keep a track of when an access review was last completed for each system.

Temporary changes

If additional permissions are needed for a fixed amount of time, you can grant additional permissions while they’re needed and then remove them once they’re not needed again.

Requests for administrator privileges need to be reviewed or approved by someone of the appropriate level, such as the staff member’s team leader.

Mechanisms for notification

IT leads should be told in a timely manner about new or departing users and role changes for least privilege to work in practice.

The onboarding and offboarding procedures including notifying the IT lead of:

• new staff and what type of access they require for their role
• changes of role and responsibilities
• departing staff and students.

Calendar invites should be sent to the IT lead to remind them to:

• revoke access if the user is leaving the school, or
• change or revert permissions if access is needed for a fixed amount of time.

Other considerations

Integrations

Any external systems that connect to your school systems should have restrictive permissions. Integrations should be monitored as part of periodic reviews. Access should be revoked when no longer needed.

Guest users

You can invite external users to access your systems to collaborate with your school. This is common for Google Workspace and Microsoft 365.

Only provide guest users with the minimum level of access and permissions they require. Make sure to revoke their access when no longer needed.