Best Practices
The following sections list recommended best practices for access control. These are only suggestions, but they do lend toward effective administrative practices in securing data and ensuring the right amount of access to your users.
Identifying and Categorizing Accounts
After logging in, view the users who are currently added to your instance of Dremio. If you are new to Dremio and preparing to add user accounts, make a list of all users that will need access to Dremio. From this list of users, you’ll now want to identify who should have administrative or restricted access. Regular users typically require the least privilege, whereas administrators should have heightened levels of access.
For each user or group that will be added to Dremio, you’ll want to create a list of privileges to assign, as well as identify what data objects they should be able to access. When mapping out object access, consider the implications of Dremio’s inheritance model and how to restrict scope.
Creating a Test Account
When implementing access control for the first time, we advise organizations to create a test account. With this user account, you may test the impacts of various privileges as well as see how a user might interact with your data based on the objects assigned to them. This is an excellent way to gain insight into the new privileges available in Dremio and the potential ways by which they might be abused by users.
This is a necessary and often-overlooked step in the process of implementing access control. Administrators need a thorough understanding of how data might be accessed or altered based on the privileges assigned to a user.
Upon creating a test account, apply privileges one at a time and at different object levels to see how a user’s activities might be restricted or enabled.
Creating Emergency Access Accounts
It is possible for an administrator to either be unavailable or otherwise unable to access their Dremio account. If a user finds themselves suddenly unable to complete a task or needing additional access to perform important temporary actions, an administrator must be available.
Emergency access accounts are user accounts with highly privileged access, but aren’t assigned to specific individuals. These accounts are therefore limited in purpose to those scenarios when a regular administrator is not immediately available and either an emergency or high-priority event occurs and a user or group needs augmented access.
Give the login credentials for an emergency account to a trusted individual so that they can make any necessary changes to user access levels. Once the activities have been performed, access to the account may be revoked by simply changing the account password.
Implementing Least Privilege
The principle of least privilege indicates that only the minimum necessary privileges should be assigned to a subject that requests access to an object. Granting privileges beyond their scope of necessary privileges allows the user to potentially alter or acquire data in unwanted ways. There is always the risk that privileges associated with access will be abused. This practice follows the “need to know” rule, where if the subject does not need access to an object to perform a task, it should not have the right to access that object.
When determining privileges to assign to a user or group, only the bare minimum access required to complete their tasks should be granted. If the grantee does not need an access right, they shouldn’t be given that right. For example, if a user needs to be able to see data on a specific object, but not alter it, then they should only be given VIEW access.
Occasionally, a user or group may require that their access be augmented in some way with additional privileges. These extra rights should be relinquished immediately upon completion of the task.
Communicating Access to Users
Communication is an important part of implementing access control for users or groups. If users don’t know what they can or can’t do and with what objects, this may cause some confusion.
We recommend communicating to each user or group the specific privileges they’ve been granted and with what objects they can perform these functions. This way, if a user identifies missing privileges or object access, they can more effectively communicate this need to an administrator.
Completing Regular Access Audits
At regular intervals (between one-to-six months), we recommend performing access audits. This entails reviewing the existing permissions granted to your users and groups and determining if additional access needs to be given or if existing privileges should be revoked.
Take into account the various incidents that may have occurred since you first implemented access control, or held a previous audit. Has a specific user or group regularly had “accidents” like deleting tables? Based on such incidents, consider whether the privileges that enable such problems to occur should be revoked.
On the other hand, consider incidents where additional access has regularly been requested on a temporary basis. Maybe this privilege could be assigned to the user permanently, as this would save you the time of repeatedly granting and revoking privileges.
Regular access audits can help in fixing recurring issues or helping users perform their duties. We do not recommend implementing privileges and then never revisiting your access control again. Like an organism, the needs of your users are constantly changing and need to be regularly revisited and assessed.
Regarding Ownership of Objects
By default, when a user creates an object in Dremio, they become the owner of that object through the OWNERSHIP privilege. Deleting this user can result in “orphan” objects. Whenever possible, it is recommended that the OWNERSHIP of critical objects be granted to a role, rather than a single user. This will prevent “orphan” objects since a role usually includes multiple members.