Segurança de dados do CRM

​

Dados pessoais sob o GDPR e a LGPD

Toda regulamentação, do GDPR à LGPD, compartilha um princípio: você usa dados pessoais apenas para o propósito com que o usuário concordou. O CRM faz parte do ledger Midaz. Ele lida com fluxos transacionais e não transacionais, então deve proteger os dados sensíveis que esses fluxos carregam. Embora a Lerian não ofereça serviços de cibersegurança, seguimos práticas rígidas de segurança da informação em todo o software que entregamos.

​

Responsabilidades de segurança

---

A Lerian não supervisiona nem impõe as políticas de cibersegurança de nossos clientes. Respeitamos a relação de confiança que cada instituição tem com seus usuários finais. Presumimos que cada cliente segue a LGPD e qualquer outra regulamentação de proteção de dados aplicável à sua região ou setor. A divisão do trabalho de segurança entre a Lerian e você depende do seu modelo de deploy. Veja o modelo de responsabilidade compartilhada. Ainda assim, a Lerian entrega tecnologia que segue práticas de segurança sólidas e alinhadas ao mercado. Essas práticas protegem os dados sensíveis do CRM da seguinte forma:

​

Em trânsito

O ledger do Midaz serve HTTP simples. Termine o TLS na frente dele, no seu ingress ou service mesh, para proteger os dados que você troca com o CRM. O CRM criptografa campos sensíveis antes de gravá-los no banco de dados. Isso vale para toda requisição que cria ou atualiza um titular ou um instrumento.

​

Em repouso

No BYOC, a criptografia de disco e de volume é sua responsabilidade. Recomendamos fortemente essa prática. Ela adiciona mais uma camada de proteção.

​

Como protegemos os dados

---

O CRM usa diferentes métodos de proteção. O método depende do tipo de dado e do uso pretendido.

• Criptografia protege valores que o sistema pode precisar ler novamente, como nomes ou informações de contato.
• Hashing cria um token de busca para alguns campos criptografados, como o document do Titular, para que o CRM encontre um registro por esse valor. O campo em si continua criptografado.

​

Estratégias de criptografia e hashing

O CRM combina várias técnicas criptográficas. Essas técnicas protegem os dados sensíveis e ainda dão suporte à aplicação.

​

Criptografia

O sistema deve ler ou mostrar alguns campos novamente, como nomes pessoais ou e-mails. O CRM criptografa cada um desses valores com criptografia simétrica forte. Mesmo que alguém leia o banco de dados diretamente, os valores originais permanecem ilegíveis sem a chave de criptografia. A criptografia também adiciona um componente aleatório, de modo que valores idênticos nunca produzem a mesma saída criptografada.

​

Hashing

O CRM aplica hash em certos campos para permitir filtragem segura sem expor o valor original. Ele armazena esses hashes em uma estrutura interna separada para buscas rápidas e seguras.

​

Gerenciamento de chaves

O CRM usa chaves de criptografia e chaves de hashing, em um de dois modos que KMS_VENDOR seleciona. Quando KMS_VENDOR não está definido ou é none, o CRM lê as chaves de LCRYPTO_ENCRYPT_SECRET_KEY e LCRYPTO_HASH_SECRET_KEY. Quando KMS_VENDOR é hashicorp-vault, o CRM gera chaves para cada organização e as protege com uma chave do HashiCorp Vault Transit que você opera. Nunca codifique uma chave diretamente ou a exponha em código-fonte ou controle de versão. Com hashicorp-vault, o CRM usa o engine Transit do Vault montado em transit-st. Cada organização tem a própria chave Transit, chamada org-<organization_id>. O Midaz se autentica no Vault com AppRole: defina KMS_VAULT_AUTH_METHOD como approle e defina KMS_VAULT_ROLE_ID e KMS_VAULT_SECRET_ID. Dê a esse AppRole permissão para criptografar e descriptografar com as chaves das organizações em transit-st. O Midaz provisiona as chaves do CRM de uma organização quando ela precisa delas pela primeira vez. Para provisionar as chaves antes, chame POST /v2/organizations/{organization_id}/encryption/provision. Para conferir as chaves, chame GET /v2/organizations/{organization_id}/encryption/status.

​

Campos protegidos

O CRM protege os campos listados abaixo. Você não precisa saber como essa proteção funciona. Não insira dados sensíveis em nenhum campo que não esteja nesta lista.

​

Titular

• 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

​

Instrumento

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

​

Boas práticas e recomendações

---

A criptografia de dados no CRM adiciona uma camada de segurança sólida. Mesmo que um invasor comprometa o banco de dados, os campos protegidos permanecem ilegíveis em sua forma original. O CRM descriptografa dados apenas com uma chave válida, ou por meio de chamadas de serviço autenticadas e autorizadas. Por isso, a segurança das chaves é essencial. Se uma chave vazar, a aplicação não consegue proteger seus dados sozinha. Para manter seu ambiente seguro, recomendamos fortemente:

• Não exponha a API do Midaz diretamente em camadas de borda, como gateways ou aplicações frontend.
• Nunca armazene dados sensíveis em campos de metadados. O CRM não os criptografa.
• Aplique governança sobre o acesso ao ambiente de produção e às ferramentas relacionadas.
• Use gerenciadores de chaves seguros com controles de acesso rigorosos para proteger seus segredos.
• Criptografe discos ou volumes para proteger dados em repouso.