Protecting Against the “Insider Threat” with SingleStore


Mike Mohler

Principal Systems Engineer

Protecting Against the “Insider Threat” with SingleStore

Today, a number of cyber attacks are carried out by malicious insiders or inadvertent actors. Whether a large government agency or commercial company, protecting your data is critical to successful operations. A data breach can cost significant amounts of lost revenue, a tarnished brand, as well as lost customer loyalty. For government agencies, the consequences can be more severe.

SingleStore has a comprehensive security focus, including the ability to protect sensitive data against the “Insider Threat”. Specifically, we this post outlines best practices for security at the database tier.

The first step to secure data infrastructure is a database platform such as SingleStore that provides enterprise level security. Today, large government agencies and commercial companies count on SingleStore to secure their most sensitive data. There are three critical pillars to securing your data in a database.

Separation of Administrative Duties
Data Confidentially, Integrity, and Availability
360° View of all Database Activity

In the rest of this post, we will focus on the Separation of Administrative Duties. The primary goal here is to disintermediate the Database Administrator (DBA) from the data. Central to this is to not allow a DBA to grant themselves privileges without approval by a 2nd Administrator. There should also be special application specific DBAs separate from Operations and Maintenance Administrators. The developers and users should not be able to execute DBA tasks. This can all be done by setting up the following recommended roles.

at-the-organization-levelAt the organization level:

1. Compliance Officer

  • Manages all role permissions
  • Most activity occurs at the beginning project stages
  • Shared resource across the organization

2. Security Officer

  • Manages groups, users, passwords in SingleStore
  • Most activity occurs at the beginning project stages
  • Shared resource across the organization

at-the-project-levelAt the project level:

1. SingleStore Maintenance and Operations DBA

  • Minimal privileges to operate, maintain and run SingleStore
  • Can be shared resource across projects

2. DBA per Database Application (Application DBA)

  • Database and schema owner
  • Does not have permissions to view the data

3. Developer/User per Database Application

  • Read and write data as permitted by the Application DBA
  • Does not have permission to modify database

Once the roles and groups are established, you assign users to these groups. You can then setup row level table access filtered by the user’s identity to restrict content access at the row level. For example, an agency may want to restrict user access to data marked at higher classification levels (e.g. Top Secret) that their clearance level allows. See RBAC User Guide and Row Level Security Guide in SingleStore documentation for details.

Lastly and most importantly, your security environment can be permanently locked down once deployed. This is called “Strict Mode” and is a configuration setting that is irreversible once enabled. This ensures against the rogue admin modifying configuration in a production deployed system. See Strict Mode Guide in the SingleStore documentation for details.

Too frequently data architects have had to compromise on security for select applications. With SingleStore, you can achieve real-time performance and distributed SQL operations while maintaining the utmost in security controls.

Visit to try SingleStore today!