Skip to main content

​
Why does this matter?

Every regulation, from GDPR to LGPD, shares one principle: you use personal data only for the purpose the user agreed to. The CRM is part of the Midaz ledger. It handles transactional and non-transactional flows, so it must protect the sensitive data these flows carry. Although Lerian doesn’t offer cybersecurity services, we follow strict information security practices in all software we ship.

​
Security responsibilities

As an on-premise technology provider, Lerian does not oversee or enforce our clients’ cybersecurity policies. We respect the trust-based relationship each institution has with its end users. We assume that each client follows the LGPD and any other data protection regulation that applies to its region or industry. Still, Lerian delivers technology that follows strong, market-aligned security practices. These practices protect sensitive CRM data as follows:

​
In transit

The Midaz ledger serves plain HTTP. Terminate TLS in front of it, at your ingress or service mesh, to protect the data you exchange with the CRM. The CRM encrypts sensitive fields before it writes them to the database. This applies to every request that creates or updates a holder or an instrument.

​
At rest

The CRM runs on-premise, so disk and volume encryption is the client’s responsibility. We strongly recommend it. It adds another layer of protection.

​
How we protect data

The CRM uses different protection methods. The method depends on the type of data and its intended use.
  • Encryption protects values that the system might need to read again, such as names or contact information.
  • Hashing creates a search token for some encrypted fields, such as the Holder document, so the CRM can find a record by that value. The field itself stays encrypted.
The CRM writes the protected fields to the database only in encrypted form.

​
Encryption and hashing strategies

The CRM combines several cryptographic techniques. These techniques protect sensitive data and still support the application.

​
Encryption

The system must read or show some fields again, such as personal names or emails. The CRM encrypts each of these values with strong, symmetric encryption. Even if someone reads the database directly, the original values stay unreadable without the encryption key. Encryption also adds a random component, so identical values never produce the same encrypted output.

​
Hashing

The CRM hashes certain fields to allow secure filtering without exposure of the original value. It stores these hashes in a separate internal structure for fast, secure lookups.

​
Key management

The CRM uses encryption keys and hashing keys, in one of two modes that KMS_VENDOR selects. When KMS_VENDOR is unset or none, the CRM reads its keys from LCRYPTO_ENCRYPT_SECRET_KEY and LCRYPTO_HASH_SECRET_KEY. When KMS_VENDOR is hashicorp-vault, the CRM generates keys for each organization and wraps them with a HashiCorp Vault Transit key that you operate. Never hardcode a key or expose it in source code or version control.
Protect your keys with a dedicated secret manager or secure storage.

​
Protected fields

The CRM protects the fields listed below. You do not need to know how this protection works. Do not enter sensitive data in any field that this list does not include.
Never store sensitive information in the metadata object.

​
Holder

  • name
  • document
  • contact.primaryEmail
  • contact.secondaryEmail
  • contact.mobilePhone
  • contact.otherPhone
  • naturalPerson.motherName
  • naturalPerson.fatherName
  • naturalPerson.monthlyGrossIncome.value
  • legalPerson.representative.name
  • legalPerson.representative.document
  • legalPerson.representative.email

​
Instrument

  • document
  • bankingDetails.account
  • bankingDetails.iban
  • regulatoryFields.participantDocument
  • relatedParties.document

​
Best practices & recommendations

Data encryption in the CRM adds a strong security layer. Even if an attacker compromises the database, the protected fields stay unreadable in their original form. The CRM decrypts data only with a valid key, or through authenticated and authorized service calls. Key security is therefore critical. If a key leaks, the application cannot protect your data on its own. To keep your environment safe, we strongly recommend:
  • Do not expose the Midaz API directly on edge layers such as gateways or frontend apps.
  • Never store sensitive data in metadata fields. The CRM does not encrypt them.
  • Enforce governance over access to the production environment and related tools.
  • Use secure key managers with strict access controls to safeguard your secrets.
  • Encrypt disks or volumes to protect data at rest.
Data security is a shared responsibility. The CRM gives you the building blocks. Make sure your deployment uses them well.