As repositories of highly sensitive, confidential, and valuable business data, databases are the crown jewels of every organization. Successful businesses not only supply accurate and timely data, they must protect it as well. Security provides a critical competitive edge for any high functioning database. So database providers must prioritize protecting data in order to gain loyal customers who can trust the systems set in place to properly guard valuable information.
In our latest enterprise release, SingleStoreDB Self-Managed 5.1, we added Role-Based Access Control (RBAC) as a powerful tool to protect customer data. With this new security feature, SingleStore customers can now easily scale users and roles to tens of thousands without compromising performance. RBAC provides high scalability and enhanced control over user access to data that perfectly suits intensive workloads like those generated by the Internet of Things. SingleStoreDB Self-Managed 5.1 brings enterprise level security with optimized scale of performance to real-time analytics to prove that customers should never have to sacrifice security for speed.
Findings in the 2016 Verizon Data Breach Investigations Report underscore the case for RBAC as a robust shield against unauthorized access to secure data. Of the ten incident classification patterns cited in the report, privilege misuse ranks among the most common sources of data breaches along with web app attacks, denial-of-service, crime-ware, and cyber-espionage.
“Incident Classification Patterns”
We sat down with Rick Negrin, one of our principal product managers, to discuss the significance of RBAC, why it matters to real-time data analytics, and how it is implemented in SingleStoreDB Self-Managed 5.1.
Can you tell us a little bit about RBAC?
RN: Role-Based Access Control (RBAC) provides a methodology for regulating an individual user’s access to information systems or network resources based on their role in an organization. RBAC enables security teams to efficiently create, change, or discontinue roles as the unique needs of an organization evolve over time without having to endure the hardship of updating the privileges of individual users.
What are the challenges of applying effective RBAC?
RN: Once you get a critical mass of users that need to be assigned varying levels of access rights to privileged data, you need a higher level of abstraction to quickly and easily assign groups, roles, and customized rules and permissions to individual users. In addition, it is essential to “spread the wealth” of managing databases among multiple authorized administrators – without giving them access to classified data – to prevent individuals from manipulating access rights to systems on their own. In a way, it is not dissimilar from the chain of command on strategic submarines where the Commanding Officer, Executive Officer, and Chief of Boat share launch code responsibilities so no one individual can unilaterally override approved procedures.
How did SingleStore integrate RBAC into its latest release?
RN: RBAC was incorporated into our release of SingleStoreDB Self-Managed 5.1 this past June. To enable this feature, two new objects were added to the security model: roles and groups. Roles are collections of permissions and groups are collections of users. Roles are then applied to groups and users are put into groups. This not only greatly simplifies the process of assigning roles-based access rights, it ensures appropriate information privileges are enforced for individual users throughout the organization.
Why is RBAC particularly important for public sector, financial, and energy companies dealing with private information or applying real-time analytics?
RN: The legal and compliance requirements in these sectors mandate strict security measures when it comes to protecting data. RBAC plays a key role in helping these organizations address potential data breaches through the enforcement of granular information access rights. When it comes to real-time data analytics there is a dearth of sophisticated security mechanisms embedded in big data analytics systems. As a result, while the aforementioned industries are experimenting with some of these technologies, legal barriers and the relative absence of built-in security measures like RBAC create friction when it comes to more widespread adoption. We have embedded RBAC into the enterprise edition of SingleStoreDB Self-Managed 5.1 in order to maintain flexible integration through connectors with technologies including Kafka, Spark, HDFS, S3, MySQL, and business intelligence software.
Performance degradation is commonly associated with strong security measures. How is SingleStore implementing RBAC without exacting a performance penalty?
RN: For most databases, security computation is done on each execution of a query. At SingleStore, instead of repeating this step for each query, we perform the computation during the execution of an RBAC command. For example, a user John is added to the Analytics Users group. This group has access to tables X and Y. When the RBAC command runs to add John to the Analytics Users group, the command also goes through each query in the system that touches table X or table Y and updates the security information on that query so John now has access. Also, all new queries that use table X or table Y that come into the system will see that John has access and save that information away for future executions of that same query. Effectively, SingleStore precomputes the allowed access for all queries ahead of time, saving time while improving security.
To validate the performance quality of RBAC, we engaged an independent third-party security consultancy to run rigorous functional and performance tests, including inside a FIPS 140-2 environment. The results demonstrated that a cluster can have up to 16,000 users occupying 100,000 roles in 100,000 groups without significant degradation in query performance.
What are some good examples that illustrate how to apply RBAC?
RN: Take a financial company for instance. You might need an auditor to go in and see who accessed certain things but not necessarily the data itself. RBAC could restrict that auditor’s access to metadata. Or you might have a security officer who manages user names and passwords, but does not manage the data. You could also assign a storage administrator to manage backups without gaining access to the underlying data. Another good example is an application user who could be restricted to executing per-application DML statements. That is the beauty of RBAC; you can extend the breadth and depth of roles and groups and users as needed.
Try SingleStoreDB Self-Managed 5.1 for yourself: www.singlestore.com/cloud-trial/
