Acra v0.94 releases: database protection suite

What is Acra

Acra helps you easily secure your databases in distributed, microservice-rich environments. It allows you to selectively encrypt sensitive records with strong multi-layer cryptography, detect potential intrusions and SQL injections and cryptographically compartmentalize data stored in large sharded schemes. Acra’s security model guarantees that if your database or your application get compromised, they will not leak sensitive data or decryption keys.

Acra gives you tools for encrypting the data on the application’s side into a special cryptographic container, storing it in the database, and then decrypt it in a secure compartmented area (separate virtual machine/container). The cryptographic design ensures that no secret (password, key, anything) leaked from the application or database will be sufficient for decryption of the protected data chunks that originate from it.

Acra was built with specific user experiences in mind:

• quick and easy integration of security instrumentation;
• cryptographic protection of data in the threat model where all the other parts of the infrastructure could be compromised, but as long as AcraServer isn’t compromised, the data is safe;
• proper abstraction of all cryptographic processes: you’re safe from the risk of selecting the wrong key length or algorithm padding;
• secure default settings to get you going;
• intrusion detection to let you know early that something wrong is going on;
• high degree of configurability to create the perfect balance between the extra security features and performance;
• automation/ops-friendly: most of Acra’s features were built to be easily configured/automated using a configuration automation environment.
• limited attack surface: to compromise an Acra-powered app, an attacker will need to compromise a separate compartmented server, AcraServer – more specifically – its key storage and database;
• easy to try: you can experience the full might of Acra without committing to its installation using Docker containers.

Acra is a continuously developing security tool. And as any proper security tool, it requires enormous human efforts for validation of the methods, code, and finding possible infrastructural weaknesses. Although we do run Acra in production in several instances, we’re constantly enhancing and improving it as we go. This is done to ensure that the provided security benefits are not rendered useless through implementation problems or increased complexity.

Cryptography

Acra relies on our cryptographic library Themis, which implements high-level cryptosystems based on the best available open-source implementations of the most reliable ciphers. Acra does not contain any self-made cryptographic primitives or obscure ciphers. Instead, to deliver its unique guarantees, Acra relies on the combination of well-known ciphers and smart key management scheme.

How does Acra work?

After successfully deploying and integrating Acra into your application, follow the 4 steps below:

• Your app talks to AcraConnector, local daemon, via PostgreSQL/MySQL driver. AcraConnector emulates your normal PostgreSQL/MySQL database, forwards all requests to AcraServer over a secure channel, and expects a plaintext output back.
• Then AcraConnector forwards it over the initial database connection to the application. It is connected to AcraServer via Secure Session or TLS, which ensures that the plaintext goes over a protected channel. It is highly desirable to run AcraConnector via a separate user to compartmentalize it from the client-facing code.
• AcraServer is the core entity that provides decryption services for all the encrypted envelopes that come from the database and then re-packs the database answers for the application. AcraCensor is a part of AcraServer that allows customizing the firewall rules for all the requests coming to the MySQL database.
• To write the protected data to the database, you can use AcraWriter library, which generates AcraStructs and helps you integrate it as a type into your ORM or database management code. You will need Acra’s public key to do that. AcraStructs generated by AcraWriter are not readable by it — only the server has the right keys to decrypt it.
• You can connect to both AcraConnector and the database directly when you don’t need encrypted reads/writes. However, increased performance might cost you some design elegance (which is sometimes perfectly fine when it’s a conscious decision).

Acra also has additional smaller components like AcraCensor firewall and a lightweight HTTP web server for managing AcraServer’s certain configuration options AcraWebConfig. To better understand the architecture and data flow, please refer to Architecture and data flow section in the official documentation.

The typical Acra workflow looks like this:

• The app encrypts some data using AcraWriter, generating AcraStruct with AcraServer public key and updates the database.
• The app sends SQL request through AcraConnector, which forwards it to AcraServer.
• AcraServer passes each query through AcraCensor (currently only works with MySQL databases), which can be configured to blacklist or whitelist some queries. AcraServer forwards the allowed queries to the database.
• Upon receiving the answer, AcraServer tries to detect the encrypted envelopes (AcraStructs). If it succeeds, AcraServer decrypts payload and replaces the AcraStructs with plaintext answer, which is then returned to AcraConnector over a secure channel.
• AcraConnector then provides an answer to the application, as if no complex security tool was ever working within the system.

Changelog v0.94

Core:

In this release we deprecated Zones functionality and all flags and CLI parameters related to it. These flags will be removed in the next versions. Acra will warn about deprecations.

Acra Community Edition supports separate encryption keys linked to the ClientIDs and allows to manage key switching via TLS certificates.

Acra Enterprise Edition supports more flexible mapping between users/apps and encryption keys via SQL variables.

• AcraServer, AcraTranslator, AcraKeymaker, AcraKeys, AcraRotate, AcraAddZone, AcraBackup, AcraLogVerifier, AcraPoisonRecordMaker, AcraRollback:
  • Added new CLI flags for better KMS support (documentation page, #552, #553, #554):
    • --kms_credentials_path=<filepath> – path to configuration file specific for KMS type
    • --kms_type=[aws] – type of KMS provider
  • Added support of encrypting the Acra Master Key using AWS KMS key (key wrapping technique). AWS KMS documentation page, #552.
  • Added support of the several encryption strategies for keys in the keystore (#556) and added new CLI flag:
    • --keystore_encryption_type – specifies type of keys encryption for keystore. Accepts env_master_key, vault_master_key, kms_encrypted_master_key, kms_per_client. Read description of types on documentation pages of appropriate tools, for example AcraKeymaker.
  • Extended configuration of TLS options when storing ACRA_MASTER_KEY in HashiCorp Vault. #578
  • Added 12 flags related to OCSP/CRL support. You can find all of these flags in documentation on pages related to appropriate tool, for example AcraKeymaker.
• AcraServer, AcraTranslator, AcraKeymaker, AcraKeys, AcraRotate, AcraAddZone, AcraTokens:
  • Added TLS support for Redis storage for Keystore. Added new 15 CLI flags related to TLS configuration. Read more on appropriate tool’s page, for example AcraKeymaker. #566, #565
• AcraServer, AcraTranslator, AcraKeymaker, AcraKeys, AcraRotate, AcraAddZone, AcraRollback:
  • Deprecated all Zones related CLI flags and API descriptions #577
• AcraServer, AcraTranslator:
  • Improved resistance against memory leakage: in-memory cache for keystore now uses randomly generated symmetric key for key encryption instead of ACRA_MASTER_KEY. #555
  • Improved reloading on SIGHUP signals. #557
• AcraServer:
  • Added support of HashiCorp Consul as a configuration source for encryptor config. Acra can load configuration from the Consul instead of file. Added new CLI flag (--encryptor_config_storage_type=[filesystem|consul]) to switch source and Consul specific flags. Read more on documentation page about encryptor config and acra-server’s configuration description. #568
  • Improved support of searchable tokenization. AcraServer captures SELECT queries and update WHERE clauses to add support of filtering with consistent tokenization. #581
  • Improved searchable encryption with more complex queries. #586, #592, #598, #599, #594.
  • Improved SQL parser (better compatibility across different SQL databases):
    • Added support of NULLS FIRST/NULLS LAST ordering clauses, joins with subqueries #547
    • Added support of RETURNING clauses. #584
  • Improved processing prepared statement. #580, #593
  • Added new section to encryptor config called database_settings. #532, #590
    • Contains subsections mysql and postgresql
    • Currently mysql subsection has one option, case_sensitive_table_identifiers, boolean, to configure whether table names should be considered case-sensitive when comparing with names in encryptor config
  • Table/column matching now works like this:
    • For PostgreSQL:
      • Raw identifiers are case-insensitive
      • Identifiers wrapped with double quotes are case-sensitive
    • MySQL:
      • Column identifiers are always case-insensitive
      • Table names are case-insensitive by default, could be changed with case_sensitive_table_identifiers option mentioned above
        Case-insensitive means the identifier is converted to lowercase before comparing with values from encryptor config, encryptor config should contain lowercase version of column/table name.
        Case-sensitive means identifiers are compared with values from encryptor config “as is”, encryptor config should contain exactly the same identifier as in database schema.
  • Removed deprecated --tls_db_sni flag. Now only --tls_database_sni is available. #564
  • Added support of separate configuration and specifying of CRL/OCSP settings for connections from database and applications. Added flags: --tls_ocsp_[database|client]_required, --tls_[ocsp|crl]_[database|client]_check_only_leaf_certificate, --tls_[ocsp|crl]_[database|client]_from_cert, --tls_[ocsp|crl]_[database|client}_cache_size, --tls_[ocsp|crl]_[database|client}_cache_time, --tls_[ocsp|crl]_[database|client}_cache_size. You can find all of these flags in documentation on pages related to appropriate tool, for example AcraServer. #564.
• AcraTranslator:
  • Improved HTTP API performance. Refactored HTTP processing core. Now AcraTranslator uses golang’s HTTP server with gin router #550. Added support of:
    • HTTP 2.0 connections additionally to HTTP 1.1
    • Keep alive connections
  • Added TLS support for HTTP API:
    • --http_api_tls_transport_enable=[true|false] new flag added to turn on accepting TLS connections instead of raw TCP. Works only together with --http_api_enable=true. #550

Example projects and demos:

• Python examples: updated to show searchable encryption feature. #548

Install && Use

Copyright 2015 Cossack Labs Limited