The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to implementations of the claimed inventions.
Businesses need the ability to query and to view query results in real time, for large data sets being analyzed, in order to make informed business decisions. An analytics dataset includes a materialized collection of fields that has been optimized for ad-hoc query analysis—to make possible a sub-second query response for any query. Security for the fields of the data set is of paramount importance for the businesses.
Business customers need data security for datasets from both internal content management systems (CRMs), which include many hundreds of custom data fields on some objects, and from external entities—including other enterprise systems. CRM data security is vital in many broad categories of enterprise businesses, including sales, service marketing, social networking communities, analytics, customized applications and the Internet of Things (IoT). Data security is also paramount for data from external sources—which can be received via comma separated value (CSV) files directly uploaded to an analytics platform. Additionally, businesses require effective data security for datasets created by combining existing datasets.
Security requirements, for systems that provide business analytics “live” for large volumes of data, drive the need for the ability to control and restrict user access to data and functionality. Data security can include organization-level features such as when, where and how users can login; object-level permissions that determine what actions (e.g., create, read edit, delete) a user can perform on records of each object; and record-level permissions that grant access through default settings, sharing rules, etc. Additionally folder organization can be used to secure a variety of data for an enterprise, including reports, visualization designs, email templates and documents; folder access can be set to public, or access can be provided on a role-based basis. Field-level permissions specify which fields a user can view and edit on records of an object (e.g., specifying visible and read-only) in one implementation.
When it is desirable to deploy analytics results via a single visualization lens or group of lenses displayed as a dashboard to users with different security profiles, then either field level security (FLS) is needed; or else it becomes necessary to create copies of datasets with varying numbers of fields dependent on the permissions of each user or user profile. This requires a system of creating copies of lenses and modifying for the datasets, and then configuring application sharing to control user access to the datasets and lenses for which the user has security permissions. The second option of creating multiple similar datasets can quickly become a maintenance and security problem, and can cause a significant system performance impact. Alternatively, the first option of using field level security allows a single report to be shared across users with different security profiles, while ensuring that users see only the fields to which they have been granted access.
In an example use case, access to a sensitive field like salary needs to be limited to the employee, a human resources (HR) administrator and executive management, and needs to disallow read access to all other users. Using FLS, a report author with an HR admin profile can create a report that includes employee salaries, and the report author can confidently share the report with all HR users with full assurance that non-HR admins will not see the field or its data.
In another use case, individuals' health data must be protected to comply with Health Insurance Portability and Accountability Act (HIPAA) privacy rules. In this example, critical-information viewers (such as doctors and physicians' assistants) of patient data have profiles that specify that they can view fields that include diagnosis descriptions and prescription information—fields that an accountant in the business office of the medical facility would not have a need to see.
The disclosed technology relates to specifying and enforcing field level security on integrated, heterogeneous data sets.
USPTO Backgrounds
USPTO Backgrounds