Continuing with the blog post, Protecting Against the Insider Threat, where the theme was the “Separation of Administrative Duties” as a way to disintermediate the Database Administrator (DBA) from the data, this blog will focus on the need to “Trust, but Verify” your users.
It is always the assumption that employees will act in their best interest for the good of the organization and their customers. But, what if they don’t? Unfortunately, this can be the reality in some organizations and requires extended security in your database to ensure protection against this threat.
MemSQL delivers the extra security you need. Of course, we support all the typical enterprise security features for maintaining data confidentiality, integrity and availability. Features such as Role Based Access Control (RBAC) as discussed in the previous blog, end-2-end SSL TLS 1.2 based encryption, 3rd party encryption stack integration for data at rest, as well as easy-to-configure high availability to guard against data loss and system downtime. However, you always need to know that the administrators and users that connect to your system are trusted.
Let’s discuss two critical principles to address this threat. Specifically, deep database auditing for a 360° view of all session activity along with trusted authentication into the database to maintain confidentiality to prevent sensitive information from being accessed by the wrong people.
MemSQL Deep Database Auditing
MemSQL logs all database activity to an external location. Once written, analysis tools can then be used to perform information security analysis to verify access control policies are enforced, as well as investigate suspicious activity or system outages.
The system also captures the User’s intention in the audit logs BEFORE returning any data back to the user. MemSQL auditing provides configurable filtering to allow for five levels of logging. These levels will capture valid and invalid SQL statements and queries as defined below:
When you remove ‘-INCLUDING-PARSE-FAILS’ from any of the above log levels, only valid SQL statements and queries are logged. This logging enables MemSQL to record administrator and/or user activity along with the results of the query. Should a command contain sensitive data, like a password, MemSQL redacts that information from the audit logs.
An organization must also reliably identify users and provide secure authentication and authorization to support data confidentiality. Using an identity federation standard such as SAML (Security Assertion Markup Language) allows an organization to support this requirement to establish trusted access to their applications and database systems. MemSQL supports SAML, as well as Kerberos, PAM, and native authentication. The process involves establishing user credentials in the identity provider and then mapping those to users inside MemSQL. When a user attempts to authenticate, the security token is validated before granting access. (See SAML Authentication and Kerberos using GSSAPI online documentation for details).
Whether using SAML tokens or Kerberos principals to represent user credentials, the user credentials are mapped to an internal user within MemSQL. Adding and removing users in MemSQL is simple and explained in the Securing MemSQL online documentation.
In this blog series on “Protecting Against the Insider Threat”, we focused on the separation of duties as well as trusted verification of your database users. With MemSQL, enterprises and government organizations get an enterprise quality database that meets the triad of security principles (Confidentiality, Integrity, and Availability) while delivering very high performance. Today, MemSQL meets these requirements and also supports ICD-503 for the highest level data protections. With MemSQL, you will achieve real-time performance and distributed SQL operations with maximum security controls.