Building a Secure Vertica Environment

This blog post was authored by Soniya Shah.

Vertica has a client-server architecture system, where applications that reside on the client access the Vertica cluster through drivers including ODBC, JDBC, OLEDB and ADO.NET. This post discusses secure client to server communications, authenticating access to Vertica, and administrator access.

Method	Vertica Options
Authentication: Validate user credentials	•Hashed Password • LDAP • Kerberos • SSL CA Certs
Authorization: Verify user has access to information	•Schema and tables Privileges • Inherited Privileges • Column Level Access • Row Level Access
Storage Encryption	•Data Protection Voltage

Authentication

Vertica uses the latest TLS protocol to authenticate client and server communications. The authentication mechanisms work with third party certificate authorities. There are two different SSL methods. The difference is in whether the clients have certificates:

• SSL server authentication: Always lets the client confirm the server’s identity. This authentication prevents man-in-the-middle attacks.
• SSL mutual authentication: Lets the server itself confirm the client’s identity using the server’s certificate and public key.

Vertica supports both types of authentication.

Vertica also supports both encryption and data integrity. Encryption significantly reduces the likelihood that data is read if a connection between a client and a server is compromised. However, encryption does not ensure data integrity. Data integrity means that you can verify that the data sent between the client and the server was not altered during transmission.

For example, suppose Alice wants to send confidential data to Bob. Because she wants only Bob to read it, she encrypts the data with Bob’s public key. Even if someone else gains access to the encrypted data, it remains protected. Because Bob is the only person with access to his corresponding private key, he is the only one who can decrypt Alice’s encrypted data.

When managing user accounts, Vertica integrates with common industry security protocols and services, including LDAP and Kerberos. You can use LDAP to manage both user accounts and permissions. You can use Kerberos for single sign-on for multiple services. If you use Vertica to store user credentials, the passwords are hashed using SHA-2(512).

Access Control

Vertica has five built-in roles:

• Superuser
• Dbadmin
• Sysmonitor
• DBDuser
• Public

You can read more about users and roles in this blog post. Roles represent a group of users with a common set of privileges. The dbadmin can grant or revoke permissions to users and roles. Using roles avoids having to manually grant sets of privileges to each individual user. After these roles are created, you can associate users into them, so they have a common set of privileges.

LDAP Link enables synchronization between the LDAP and Vertica servers. This allows the synchronization of LDAP groups and users to Vertica roles and users. You can run this service periodically or on demand. Without this functionality, user-group relationships would have to be manually recreated in Vertica. For more information, see LDAP Link Service in the Vertica documentation.

To minimize repetitive work, you can grant relation privileges at the schema level. This means that if you enable inheritance for a schema, any new tables added to the schema will inherit the common access privileges defined. You can further drill down this access control to a set of users to limit what each user sees within an object.

For example, suppose you have a manager, an HR employee, and a developer, all looking at the same table with customer information. The manager needs to see all the data in the table. The HR employee needs to see most information, but she doesn’t need to see a full social security number. You can allow her to only see the last 4 SSN digits. The developer does not need to see any of the SSN. You can enable a query as follows: => CREATE ACCESS POLICY ON people FOR column ssn case WHEN enabled_role('manager') THEN ssn WHEN enabled_role('hr') THEN substr(ssn, 8, 4) ELSE NULL END ENABLE; Now, each person will see something different in the table when they run SELECT * FROM people.

Monitoring

Monitoring information is located in system tables and DC tables. All the information might not be available to non-superusers, for security reasons. The dbadmin can assign a delegate to the SYSMONITOR role to grant access to system tables without granting full dbadmin access. This role allows the user read-only privileges. They cannot change the database state. This is ideal for a user that needs to monitor Vertica, without granting them full access. For more information, see SYSMONITOR Role in the Vertica documentation.

FIPS Compliance

FIPS stands for Federal Information Processing Standard, and is a requirement set by the National Institute of Standards and Technology. Vertica complies with FIPS standards using the controlled and assured use of a validated version of an OpenSSL library. This is implemented through RHEL’s certified version of OpenSSL.

As of Vertica 8.0, OpenSSL is dynamically linked with the Vertica binary. To upgrade OpenSSL, replace the library. For more information, see Implement FIPS on the Server in the Vertica documentation.