Skip to content

Encryption

Audio file encryption stores recordings encrypted at rest, adding a second protection layer on top of role-based access control: even someone with direct access to the storage (or to a backup archive) cannot play the files without the private key. It supports compliance regimes such as PCI-DSS and HIPAA.

Where: Administration › Storage › File Encryption — in multitenant mode, a per-tenant status table plus the encryption key list.

Architecture

Every recording is encrypted with its own random AES-256 key. That per-file key is in turn encrypted with an RSA key pair (2,048-bit): the public key encrypts, and only holders of the private key can decrypt. Private keys are never stored in plain text — even with direct database access, they cannot be retrieved.

In multitenant mode, each tenant has its own encryption key. A file leaked across tenants is useless to the other tenant. A tenant can even withhold its private key from the service provider entirely: recordings are then encrypted with the tenant's public key, and nobody on the provider side — including root operators — can play them; playback requires importing the files and the private key into the tenant's own MiaRec instance.

Setup checklist

  1. Create an encryption key (or import an existing one) — for the System tenant first, then per tenant in multitenant mode. Recordings can only be encrypted once an active key exists.
  2. Export a backup of the key and store it securely outside MiaRec.
  3. Grant access to the users who must play encrypted recordings.
  4. Enable audio file encryption for the tenant (or system-wide in single-tenant mode).

The System tenant needs a key of its own, but does not need encryption enabled unless calls are recorded into the System tenant (not recommended).

Managing keys

Click Add Encryption Key:

  • Name — a label for the key.
  • Status — "Use this encryption key for new recordings" marks it active.
  • Protection mode:
    • User credentials — the private key is protected by the credentials of the users granted access; decrypting requires one of those users. There is no way to obtain the private key without a user's password.
    • Application credentials — the private key is protected by the application itself, so the platform can decrypt without an individual user's credentials (needed for unattended decryption, for example export jobs that decrypt).
  • Key length — or import an existing key pair in PEM format instead of generating one.

The key list shows Date Created, Name, Fingerprint, Status, and Protection mode.

Export and import

Export (on the key's page) saves a password-protected backup of the key. Export every key and store the backups outside MiaRec — encrypted recordings are unrecoverable if the key is lost (all authorized users forget their passwords, or the database is destroyed).

Import creates a key from an existing exported key pair — used when restoring an archive on a new system, or when a tenant supplies their own key material.

Warning

A lost private key means permanently unplayable recordings. Treat key export backups as part of your disaster-recovery baseline, not an optional extra.

Granting access

With User credentials protection, users must be explicitly authorized per key before they can play or download recordings encrypted with it: on the key's page, select users in the Unauthorized Users list and click Grant access (Revoke access reverses it). An administrator — even a root administrator — can only grant access to keys they themselves have access to.

Enabling encryption

In multitenant mode, open the tenant's row in the File Encryption status table and click Edit Configuration to enable audio file encryption for that tenant (the same setting is available on the tenant profile). In single-tenant mode, the page has a single configuration. From then on, newly captured recordings are encrypted with the tenant's active key — existing files are not retroactively encrypted.

Playback, downloads, and exports

  • Playback and individual downloads are decrypted in flight for authorized users; the file leaves the platform unencrypted.
  • Bulk ZIP downloads are likewise decrypted in flight for users authorized on the relevant keys.
  • Export, relocation, and replication jobs keep files encrypted by default — safe for backups, since the backup utility needs no decryption ability. The export and relocation jobs have an explicit Decrypt files option for when the consumer needs plain audio; see Export and backup.
  • Restoring an encrypted archive on another system requires importing the matching key — see Import recordings.