Selective Decryption for Specific Columns in AcraServer

[hsarena]

Hi Acra team,

Thanks for the great work on Acra!

I've configured an AcraServer (version 0.95.0) to encrypt specific fields in the customers table using acrablock as the crypto envelope. The backend database is MariaDB. Here is a snippet from my encryptor.yaml configuration:

database_settings:
  defaults:
    crypto_envelope: "acrablock"
schemas:
  - table: customers
    columns:
      - id
      - email
      - fullname
      - cellphone
      - created_at
      - updated_at
    encrypted:
      - column: email
        searchable: true  
      - column: fullname
        searchable: true  
      - column: cellphone
        searchable: true

Now, I want to deploy another AcraServer instance for a different team and configure it in a way that only decrypts the cellphone field — not email or fullname, as follows. However, it seems like Acra decrypts all encrypted fields by default when serving a SELECT query.

database_settings:
  defaults:
    crypto_envelope: "acrablock"
schemas:
  - table: customers
    columns:
      - id
      - email
      - fullname
      - cellphone
      - created_at
      - updated_at
    encrypted:
      - column: cellphone
        searchable: true

Acra version: 0.95.0
Database: MariaDB 11.4.3
Installed components:

• AcraServer
• AcraTranslator

Data-in-transit encryption between Acra and the client-side application:

• TLS
• AcraConnector
• no transport encryption

Installation way:

• via Docker
• via package manager

---

❓ My Question:

Is there a way to configure Acra so that a particular AcraServer instance only decrypts specific fields (e.g., cellphone) and leaves other encrypted fields untouched in SELECT query responses?

This would be very useful for applying different decryption access policies across teams.

Thanks for any guidance or best practices!

[Lagovas]

Sorry for the late response. Glad to hear that you have successfully deployed AcraServer and it works for half of your requirements)

Yes, AcraServer uses keys from the TLS certificates by default or explicitly specified client_id in the encryptor config. And you are right, AcraServer transparently tries to decrypt all recognized AcraBlocks by default, even if they are not specified in the encryptor config. Config configures encryption and some parts of decryption (masking, searching, etc).

To give more accurate advice, we need to understand data flow. Who writes, who reads, who needs to have access, and who doesn't?

From your question, I see that you have 2 teams. One has full access to data, the second has only part of it. Unclear who can insert and update data. It is essential because one team can overwrite data and the second will not have access to this data anymore.

What we can advise having only this information. The user has access to data only if has access to an encryption key. Acra maps the user's TLS certificate to an encryption key. One more way is to set up a separate Acra instance with --client_id=<identifier> where all connections will be mapped to the encryption key related to this identifier.

So, to split access between 2 teams you need to use 2 separate keys. Acra doesn't yet support encryption of the same data record for several users. As a solution, application can save data for different teams to separate columns or tables.
If team2 need access only to cellphone, application can save it to cellphone_team2, and you configure encryptor config to encrypt data into this column with different key:

schemas:
  - table: customers
    columns:
      - id
      - email
      - fullname
      - cellphone
      - created_at
      - updated_at
    encrypted:
      - column: email
        searchable: true
      - column: fullname
        searchable: true
      - column: cellphone
        searchable: true
      # HERE IS DIFFERENCE
      - column: cellphone_team2
        searchable: true
		client_id: team2

If you deploy the second Acra instance with --client_id=team2, then all connections through this instance will have access to data encrypted only with key team2. JFYI, to simplify processing encrypted data on the application side, you can configure the default value (docs) for such cases:

schemas:
  - table: customers
    encrypted:
      - column: cellphone
        searchable: true
        data_type: str
        response_on_fail: default_value
        default_data_value: "Decrypted"

If your data is STRING (used by data_type: str), then this configuration will return valid STRING instead of BLOB (more about mapping look here) and return "Decrypted" string when data cannot be decrypted.

[Lagovas]

Any update folks?

did you read the comment above? Without new information, we can't help more fully

[hsarena]

Hi,

Sorry for missing your previous response that was my bad.

To clarify our setup:

• Both teams are currently using the same client_id and therefore share the same encryption keys.
• Team 2 only needs read access to specific fields. Our assumption was that if a field is not marked as encrypted in the encryptor.yaml, AcraServer would not attempt to decrypt it.
• However, we've observed that AcraServer decrypts all encrypted fields, even those not listed in the encryptor.yaml file.
• Additionally, we are not using TLS authentication at this time.

For now, we've resolved the access issue by restricting Team 2's permissions at the database level. This workaround is functional, but it would be great if Acra supported selective field-level decryption behavior in future versions.

---

We’ve also encountered another issue related to searchable fields:

When performing queries like the following:

SELECT id FROM customers WHERE cellphone_enc = '0123456789';

We observe significant performance degradation, each query takes around 1 second, which is quite high given our volume.

I’ll open a separate issue for this, but if you have any quick advice or insight into this performance behavior with searchable fields, it would be greatly appreciated.

Thanks again for your support and for such a great tool.

[Lagovas]

We observe significant performance degradation, each query takes around 1 second, which is quite high given our volume.

We have advice on database indexes for searchable fields, which you can find in the documentation. Under the hood, the query has been changed to a comparison of part of the value to the literal. So you can improve it with functional indexes