7 Ways To Set Data-Level Access Controls with a Data Fabric

For the enterprise, controlling who can view, edit, download, and query data is one of the most important aspects of enterprise data security. But as more and more applications and integrations produce more and more copies of data, controlling access becomes an increasingly difficult challenge to meet. The answer is to set access controls in the DNA of the data itself.

Today’s data controls are generally set application by application, which is why today’s “data security” is really an illusion. A typical enterprise could have thousands of applications in use, with each application is making its own copy of the original data.

The end result? It’s almost impossible to truly control who can access your data. Each application manages its own permissions, and every copy of data is a potential security breach waiting to happen.

That’s not the way enterprise Data Security should work.

Data-Level Access Controls

When controls are set at the data layer, user permissions remain the same regardless of how the data is accessed.

Set the controls once, and they’ll be in place whether a user accesses the data directly or uses other applications.

Since you’ll only have the original data (no copies) and the control is at the data level, you’ll always know exactly who and what can access the data. The data controls are enforced regardless of what solution is built on top of that data, or what programs are accessing it—software cannot bypass the data-level controls once they’re in place.

Datal-level control also means that you won’t have to set new access controls every time a piece of software enters the picture. No more coding all those permissions, no more validating and auditing for every new application. All the proper permissions will be right there, automatically.

This all adds up to true control over your data. You’re providing secure access to a single source of data, not copies. The controls are embedded in the data itself, so any solution you build with that data has the same protections right there in its DNA.

This is totally different from setting blunt "who can see and do what" controls across thousands of apps, not to mention the tens of thousands of copies of data created during Data Integrations.

7 Ways To Set Data-Level Access Controls

Remember, data-level controls are set at the data level, so they’ll be the same on any program or solution that uses that data. Here are seven key ways you can control data access.

1. By User

In environments offering data-level access controls, giving data access to a particular user is as easy. Simply go to that user’s profile and set what data you’d like them to have control over. Unlike traditional user access controls, data access set at the data-level will be applied across any solution (customer experience, automation, workflow, data viz) created with that data.

2. By Team

You can give data access to an entire team with no sharing logins and passwords and no making copies of data. All you need to do is set the team controls when you create a Data Table. If you want the marketing team to have access to a particular set of data, then they will—no matter what program is being used to access that data..

3. By Action

Security isn’t just about who can access data, but what they can do with it. This includes view-only access, editing permissions, and more. If, for example, there’s a set of data that should be read-only for everyone in the world but you, all you have to do is set the permission; the data will remain read-only wherever it appears.

4. By Table

For broad control of data, you can adjust controls for an entire data table. This is useful for granting higher-level access, quickly and easily. And, like all data-layer controls, your permissions will persist wherever that data is used.

5. By Column or Row

Need to be a little more specific? Data-level controls can not only be set by table, but by column or row. This provides an incredible amount of flexibility, while still being far faster, easier, and more secure than other methods of data access control.

6. By Cell

For the most granular control, set data access by the individual data cell. You’ll have precise management over exactly who and what can access the data cell, and what they can do with it. This is the sort of precision that used to take huge amounts of time to manage, but with data-level security you’ll only have to set the controls once, and they’ll be the same wherever that data is accessed.

7. By Data

Data-driven access controls are extremely powerful, allowing users to set up dynamic permissions for complex use cases. As an example, take a huge company with thousands of sales leads. You wouldn’t want each salesperson to see every lead, because that just invites confusion and mistakes. With data-level controls, you could easily show someone only the leads assigned to them, or you could show them the leads assigned to their team. This is much more secure than team permissions, because leads are assigned to individuals.

Customizable

All of these controls can be mixed and matched as needed to provide full customization. Need to give your sales team read-only access to a single column within a data table, while the marketing team has full control over the entire table, and one of your IT team members has editing access to a single cell within that table? Done.

Centralized, super-granular, and universal.

That’s how enterprise Data Security should work.