Protecting Against the “Insider Threat” With MemSQL

DZone 's Guide to

Protecting Against the “Insider Threat” With MemSQL

You can set up your organization for success by filling the right positions and using the right tools. MemSQL has functionality that protects databases from rogue DBAs.

· Security Zone ·
Free Resource

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 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.

Final Thoughts

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 the configuration in a production deployed system. See Strict Mode Guide in the MemSQL documentation for details.

database security, insider threats, memsql, security

Published at DZone with permission of Mike Mohler , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}