Data Operations | Permission Issues in Data Operations

In the digital age, data has become one of the most valuable assets of enterprises. How to manage these assets and ensure the security and effective use of data is a challenge that every enterprise must face. This article deeply explores the issue of permissions in data operations, analyzes the complexity of cross-product data permissions, the limitations of permission allocation, and the importance of role division.

As mentioned in the data management section, development-oriented data permissions are mainly authorized and set within the development team and development system. It can be said that they are relatively fixed and have a relatively small scope.

Here we are mainly talking about data permissions in operational scenarios. The data permissions for operations are for the entire company's data consumers, so the scope is larger and therefore needs to be more flexible in terms of functions. But in essence, both are allocations of data access rights.

1. Cross-product integration of data permissions

During the data operation process, data query, data service API, visual reports, and large screens all need to have permission restrictions. What data can an API query? What data can a report or large screen see? The user identity that uses the unified login has already applied for some table permissions. Can these permissions directly obtain the corresponding permissions in other products? If so, how to do it? If not, why do users have to apply for permissions repeatedly? This is actually a problem of connecting data permissions across products.

When facing data consumers, the ideal perspective of a platform provider is that I provide data permission authorization once, so that subsequent users can automatically obtain the corresponding data permissions when using other products provided by my platform, instead of requiring users to go through the process of applying for data permissions in the corresponding product every time they enter a product.

For example, I applied for data permissions for Table A in an ad hoc query. After approval, if a user develops a report based on Table A, then I only need to set permissions for the report, and no longer need to perform permission operations on Table A. Similarly, if a data service API is developed based on Table A, the corresponding data permissions can also be automatically obtained.

The above is an ideal state. The actual situation is much more complicated. The authorization process of permissions in different products is different. Different products use different underlying data storage. Different products have different permission authorization models, etc. All of these make the above ideal state seem less realistic. However, what I want to say is that although the road is tortuous, the goal is indeed clear. We just need to try to get closer to the goal. To eventually build a data permission system centered around metadata. (Of course, it is also possible that this road is a detour, who knows.)

2. Limitations on Permission Allocation

The permissions in the data operation part are mainly the permissions to query data. Although it is only the query permission, the complexity lies in the secondary allocation of permissions.

As for the restrictions on permission allocation, we need to change our perspective. The data developers of the data platform, or the main users, are from the data middle office department. When this department applies for data permissions, data developers may apply for permissions such as creation, modification, deletion, and query. However, data consumers in the data operation process can only apply for query permissions for tables that have been processed by the data middle office.

Moreover, there are many secondary allocation scenarios in the allocation of permissions during data operations. For example, after a business department and a colleague related to department data apply for permissions, they hope to achieve secondary allocation within the department, but cannot allocate permissions outside the department. (In fact, similar permissions are also expected during the development process.) This is what we hope to combine with the organizational structure.

What can be seen and what cannot be seen? After the permissions are allocated, how to redistribute permissions within the product? These are all things that need to be considered. Similar to the RBAC model mentioned in the data management chapter [Data permissions are a big problem], which may not be applicable to all scenarios, the same is true for the allocation of permissions during the operation process, which may not be applicable to all scenarios. It needs to be combined with the internal data usage process, organizational structure, etc.

3. Role Division

Since we are talking about secondary allocation of permissions, we need to allocate permissions to a second-level administrator, and let the second-level administrator make secondary permissions allocation within the corresponding small organization. This is very important and can reduce a large amount of permission allocation on the platform. However, the permissions allocated by the second-level administrator also need to be viewable and revocable.

Off topic: When writing about role division, I suddenly realized that the above series of contents did not involve the function and role description, which is also very important in a platform. But since I have written so far and have not found anything missing, and the users of the platform are also mentioned in the preface, it can be regarded as a rough role division to a certain extent. I will not add this part for the time being, and I will add it later when I have the opportunity.

IV. Conclusion

The ultimate goal of the entire data platform is to support the business. Therefore, data operation is a critical part, which is equivalent to a value export. The authority during the operation process is the gatekeeper of this export. It is necessary to allow data to be exported and to export data safely.