Managing a Data Analytics Team with Aunsight¶

Turning big data into business intelligence requires a team of individuals working in a variety of roles. Maintaining a balance between access and restrictions appropriate for each member of the analytics team to ensure data security can be a daunting process. Aunsight helps to ease this balancing act by providing a flexible membership and access management system with control points at many levels:

Member management makes it easy to add or remove member accounts to organizations and projects.
A finely-tuned permissions and policies model permits both granular control (permissions) while maintaining ease of use for frequent use cases (policies).
Member roles help define access profiles tailored to the specific functions certain kinds of users perform in a given project or organization.
Groups can organize specific sets of roles to permit a shared "working group" permissions model
A context-specific access model means data for different projects can be governed separately in each context; users can be granted unlimited access to one project's data, while keeping data segregated in other projects secure.

These tools allow you as an administrator to define an appropriate access model for data in your organization. Before learning how to use these tools in the tutorials that follow, let's take a closer look at what each of them does and how they work together to orchestrate a data access and security model for your team.

Member management¶

User access to data depends upon a member account, so one of the fundamental tasks of managing teams is adding members and editing their roles. More precisely, Aunsight does not directly grant member accounts permission to do anything in a given context. Rather, member accounts are like a driver's license; at its core, the license is simply an identification document, but the actual permission to operate certain kinds of vehicles comes from endorsements added to that ID document.

Managing user permissions through roles enables groups of users to be managed indirectly through their roles. This allows for changes to the underlying role to affect all members who have that role. Roles also allow administrators to shift a member's roles and automatically update that user's permissions appropriately for the given role; for example, if a data analyst temporarily needs to add new members to a project they are leading, the administrator of the parent organization can temporarily add that the "project team manager" role to that member for a time and then remove those extra permissions when the team roster has been set up. A member's permissions will only last for as long as they have a role that grants them those permissions.

Understanding Policies and Permissions¶

The Aunsight authentication service observes a highly-granular permissions model that provides incredible power to fine-tune user access to data. For example, Aunsight can grant permission for a script to edit a specific dataset by resource ID, but not the ability to browse a list of resources. This feature enhances security if a member account or access token is compromised; with such fine-tuned permissions, only a small set of data will ever be exposed in the case of a stolen password. In practice, however, keeping access so tightly monitored can be difficult to manage, so Aunsight provides an intermediate abstraction to administer the system more easily: policies.

Policies are sets of privileges that are often used together. For example, most users want to search for a dataset before browsing it to obtain sample data or make changes to it. For this reason, Aunsight's "Edit Dataset" policy bundles six low-level permissions that allow a user to perform all of these common actions for editing a dataset. Aunsight currently has around thirty such policies that cover a wide variety of common use cases.

Roles¶

By assigning a set of policies and permissions to a role, an administrator can design an access model that helps to streamline the process of managing data analytics teams. Rather than directly setting access permissions for individual users, an administrator can define arbitrary roles like "Data Munger," "Workflow Designer," or "Data Scientist" to grant a specific set of policies and permissions to that role, and then assign certain team members to that role. A team member will then have those permissions in the context in which they have that role.

This system eases access and data security management by helping administrators easily grant and revoke privileges to a group of team members engaging in a similar line of work. For example, a data engineer may usually be engaged in preparing data and designing workflows ("Workflow Designer" and "Data munger" roles) but may eventually need to manage data science models for deployment in a workflow. To that end, an administrator may wish to add the "Data Scientist" role to this member for the duration of the project and at its end, revoke that role when the privileges it grants are not needed.

Groups¶

Just as roles allow administrators to group sets of policies and apply them to a user, groups allow administrators to do the same for specific components of the Aunsight system. For example, rather than administering the permissions for a large number of Sightglass solutions individually, and administrator can define groups and assign those Sightglass solutions to the group. Members can then be added or removed from a group which will automatically add permission to access the solutions that the group has been granted access to.

Context: Organizations and Projects¶

In Aunsight all roles, and by extension, permissions, are context-specific. An administrator with total access to the data in one project may not necessarily even be able to see if a dataset exists in an unrelated project or the parent organization. For that reason, the project structure within an organization forms part of a wholistic approach to data access and security.

Rather than having all of an organization's data and workflows in one context, dividing up resources into projects allows members to have different roles in each context. As a result, a member could be granted liberal access to data in one project, while keeping data from unrelated projects inaccessible. Context can be instrumental in keeping data secure from intentional or unintentional misuse while allowing those who legitimately need access to do so with minimal restrictions over the data they need for their work.

Because each project can define roles differently, there is no hierarchical or "inherited" permissions model. An administrator of the parent organization does not automatically have any roles or permissions in a project unless those roles are granted to them. For that reason, it is important to view each project as its own sandboxed environment and plan the access and security model for each context independently.