Use Task-Based Permission to Tighten Edtech Security

#Data

Erin Werra

by Erin Werra

Erin Werra Edtech Thought Leader

Read time:

One of the core tenants of FERPA states that student records should only be available to those who have a specific need to see them. On the other side of district operations, sensitive financial information can easily become fodder for fraud if it falls into the wrong hands.

There’s a lot of data to safeguard as a system administrator.

One strategy to explore is task-based roles in your student information system or enterprise resource planning system. How does this strategy keep your data safe? Let’s explore.

Roles vs. tasks

The first step is to define the difference between roles and tasks within the software.

Roles apply to the user and carry a specific set of permissions.

Tasks are actions available to the user, including screens in different areas of the software, and different data sets the user can access.

In some systems, the default method of assigning permissions (whether view or edit permissions) is based on an individual’s role in the organization. But what if users who share a role shouldn’t necessarily share access to the same screens, tasks, and data?

Task-based permission and least privilege

Rather than automatically assign everyone in a similar role the same permissions, consider instead which screens, data, and tasks people in those roles need to view. Consider the concept of least privilege: only the minimum necessary rights should be granted to maintain the highest level of security.

Let’s say, for example, a new administrative assistant needs to access data about demographics, attendance, and create new student profiles. The system administrator can create a role using those exact permissions, and then add the role to the related security group. This might mean all administrative assistants have similar, but not identical, permissions and are all part of the same security group.

Security groups

Security groups may include both role types and individual users. They provide a way for system administrators to group together users with similar permissions. Users can belong to multiple security groups if the tasks required by their roles fit into multiple security groups. Instead of editing the role itself, however, editing the security groups the user is part of keeps all users with similar roles from ending up with too much access throughout the software.

Special permissions

What about the areas of the software that call for top-level security? The limited number of users with access to these secure areas make up their own security group. By adding individual users to this specialty access group, system administrators can keep sensitive information secure and track who has permission to view and edit data.

Cons to task-based security groups

One of the biggest challenges for system administrators is handling the volume of individual changes to permissions. It’s harder to keep track and update individuals than it is to make a broad change to all users with the same role. However, adding users with similar roles or tasks to security groups can help administrators keep track of who is allowed to do what and see which screens in the software.

System administrators take a leap of faith when they grant permission to a new hire. However, by grouping together users with like permissions, administrators have another way to keep track of which users have access to different tasks, screens, processes, and data in the system.