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.

MemSQL 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 MemSQL that provides enterprise level security. Today, large government agencies and commercial companies count on MemSQL 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 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 MemSQL
  • Most activity occurs at the beginning project stages
  • Shared resource across the organization

At the project level:

1. MemSQL Maintenance and Operations DBA

  • Minimal privileges to operate, maintain and run MemSQL
  • 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 MemSQL 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 MemSQL documentation for details.

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

Visit www.memsql.com/download to try MemSQL today!

Security Insider Threat