Security hardening guide¶
This guide explains how to enhance security in your Tarantool Enterprise cluster using built-in features and provides general recommendations on security hardening. If you need to perform a security audit of a Tarantool Enterprise cluster, refer to the security checklist.
Tarantool Enterprise does not provide a dedicated API for security control. All the necessary configuration can be done via an administrative console or initialization code.
Built-in security features¶
Tarantool Enterprise has the following built-in security features:
- access control,
- audit log;
And backup functionality:
The following sections describe the features and provide links to detailed documentation.
Tarantool Enterprise supports password-based authentication and allows for two types of connections:
- via an administrative console and
- over a binary port for read and write operations and procedure invocation.
For more information on authentication and connection types, see the security section of the Tarantool manual.
In addition, Tarantool provides the following functionality:
- sessions – states which associate connections with users and make Tarantool API available to them after authentication,
- authentication triggers which execute actions on authentication events.
- third-party (external) authentication protocols and services such as LDAP or Active Directory – supported in the web interface, but unavailable on the binary-protocol level.
Tarantool Enterprise provides the means for administrators to prevent unauthorized access to the database and to certain functions.
- different users (guests and administrators),
- privileges associated with users,
- roles (containers for privileges) granted to users;
And divides system space into:
_userspace to store usernames and hashed passwords for authentication,
_privspace to store privileges for access control.
For more information, see the access control section of the Tarantool manual.
Users who create objects (spaces, indexes, users, roles, sequences, and functions) in the database become their owners and automatically acquire privileges for what they create. For more information, see the owners and privileges section of the Tarantool manual.
Tarantool Enterprise has a built-in audit log that records events such as:
- authentication successes and failures;
- connection closures;
- creation, removal, enabling, and disabling of users;
- changes of passwords, privileges, and roles;
- denials of access to database objects;
Audit log contains:
- usernames of users who performed actions,
- event types (e.g.
Audit log has two configuration parameters:
audit_log = <PATH_TO_FILE>which is similar to the log parameter; it tells Tarantool to record audit events to a specific file;
audit_nonblockwhich is similar to the log_nonblock parameter.
For more information on logging, see the following:
- logs section of the Tarantool manual,
- logging section of the configuration reference,
- appendix A in this document.
Access permissions to audit log files can be set up as to any other Unix file
system object – via
Recommendations on security hardening¶
This section lists recommendations that can help you harden the cluster’s security.
Tarantool Enterprise does not encrypt traffic over binary connections (i.e., between servers in the cluster). To secure such connections, consider:
- setting up connection tunneling, or
- encrypting the actual data stored in the database.
For more information on data encryption, see the crypto module reference.
The HTTP server module provided by rocks does not support the HTTPS protocol. To set up a secure connection for a client (e.g., REST service), consider hiding the Tarantool instance (router if it is a cluster of instances) behind a Nginx server and setting up an SSL certificate for it.
To make sure that no information can be intercepted ‘from the wild’, run Nginx on the same physical server as the instance and set up their communication over a Unix socket. For more information, see the socket module reference.
To protect the cluster from any unwanted network activity ‘from the wild’, configure the firewall on each server to allow traffic on ports listed in network requirements.
If you are using static IP addresses, whitelist them, again, on each server as the cluster has a full mesh network topology. Consider blacklisting all the other addresses on all servers except the router (running behind the Nginx server).
Tarantool Enterprise does not provide defense against DoS or DDoS attacks. Consider using third-party software instead.
Tarantool Enterprise does not keep checksums or provide the means to control data integrity. However, it ensures data persistence using a write ahead log, regularly snapshots the entire data set to disk, and checks the data format whenever it reads the data back from the disk. For more information, see the data persistence section of the Tarantool manual.