Full transport encryption. Support for encrypted storage and in-database transparent data encryption. Authentication, access control, and exception logging.
Aerospike provides internal authentication services and can integrate with an external authentication system – specifically, LDAP – to verify user identity. Aerospike also supports Kerberos authentication. Configuration settings enable administrators to specify which approach the system will use. Rich set of access control options are available including ACLs. White listing, which is one of the most secure forms of access control is also supported. Creating a new Aerospike user account using the command line is simple. Aerospike stores the user names and a hash of corresponding passwords on every node in the cluster. Optionally, administrators can override Aerospike’s default security settings to configure Aerospike for LDAP authentication or “hybrid” authentication, which supports both local and LDAP-based user accounts.
In Aerospike, users (authenticated) can be assigned to various roles, each of which confer a set of privileges. Administrators can also create new roles, essentially combining different collections of privileges under one role that can be assigned to users.
Aerospike offers 7 pre-defined roles that address common collections of privileges that an administrator might want to grant to a user:
If using LDAP, an Aerospike administrator links Aerospike roles to desired LDAP accounts to regulate the behavior of authenticated users.
Aerospike natively supports encryption-in-motion (TLS 1.2), and encryption-at-rest (AES-128 and AES-256)
Aerospike’s TLS implementation addresses network traffic:
Encrypting data-at-rest can have a performance impact, so it’s best to benchmark the potential impact using your own data and deployed hardware. To reduce runtime performance impact, Aerospike encrypts data on a per-record basis rather than a per-disk sector basis. Aerospike ran several tests using Intel Xeon processors, which feature encryption capabilities built into the hardware to accelerate runtime performance. Aerospike observed a 20% performance decrease of transactions per second (TPS) with record sizes smaller than 512 bytes, while there was no measurable performance loss with record sizes of 1 KB or greater.
The ability to track system events provides important security and diagnostic capabilities. Aerospike enables administrators to define and configure audit trails to log attempted and successful database operations to local files, the Aerospike log file, or the default sink.
Aerospike supports granular levels of audit trail definitions to minimize performance impact:
In general, auditing security violations and other seldom-occurring events will have minimal performance impact, while logging every attempted or successful data operation on numerous data sets can slow runtime performance in systems under heavy load as well as increase storage requirements for the logs. It’s best to measure potential performance impact and storage needs in a test environment if you plan to maintain extensive audit records.
Strong security model which provides granular access restrictions at the domain and user level.
Provides role level access controls for reporting into Aerospike but not reading data. Some use cases that are enabled by the above features include deployment configurations that have security domains with different access rights within a single organization. For example, a user can be authorized to write data that is classified as highly secure but is not allowed to read data submitted by others with the same highly secure classification. Individual domains and users can also be selectively restricted to access only certain sets of data. Therefore, these features allow Aerospike to be used for fine grained security models in highly secure organizations.
In Aerospike, configuration information for encryption-at-rest, TLS for network links, LDAP authentication resides in files on the local filesystem. Starting from Aerospike 5.1, selected configuration files can be migrated from the local filesystem to HashiCorp Vault secrets. This reduces the attack surface, solves the distribution problem, and allows IAM policies to be defined and centrally administered independently of Aerospike deployments.
In this block diagram of Aerospike 5.1 components, it can be seen where Vault fits in. Vault has a client-server architecture and Aerospike operates as a Vault client. Aerospike supports Vault V1 & V2 Secrets engines with a RESTful API. Local file accesses are replaced by communication over encrypted network links to Vault servers to retrieve secrets.
Aerospike allows the following classes of parameters to be managed by and stored within Vault:
Customers who have already deployed Vault in their enterprise can take advantage of Aerospike’s integration by creating new Vault secrets using their pre-existing infrastructure. Customers new to Vault would need to define and deploy Vault servers before taking advantage of it in Aerospike 5.1. Having a working knowledge of Vault is essential before attempting to deploy it with Aerospike.