Melhores Métodos de Criptografia para Segurança de APIs de IA

Se eu tivesse que resumir em uma linha: o TLS 1.3 é a base, o mTLS prova a identidade da máquina e a criptografia de payload cobre os dados que ainda importam depois que o TLS termina.

Os ataques a APIs de IA saltaram 681% do primeiro semestre de 2022 para o primeiro semestre de 2023. Então, se estou protegendo uma API de IA, não busco uma única correção. Penso em camadas. Este artigo compara 7 métodos de criptografia nos pontos que mais importam:

• escopo de segurança
• custo de desempenho
• esforço de gestão de chaves
• cobertura na camada de transporte vs. de aplicação
• adequação para implantações nos EUA

Aqui está a versão curta:

• A criptografia simétrica é a melhor para grandes payloads e dados armazenados.
• A criptografia de chave pública é a melhor para troca de chaves e assinaturas.
• A criptografia híbrida combina as duas, então se encaixa na maioria dos casos de uso na camada de aplicação.
• O TLS 1.2/1.3 protege os dados em trânsito, com o TLS 1.3 como padrão.
• O mTLS verifica ambos os lados de uma conexão.
• A criptografia por campo protege apenas os campos que devem permanecer ocultos.
• A criptografia por envelope torna a rotação de chaves em larga escala muito mais fácil.

O ponto principal: a segurança de transporte termina no encerramento do TLS. Se prompts, imagens, áudio, logs, filas ou backups ainda precisam de proteção depois desse ponto, preciso de outra camada.

Protegendo dados sensíveis em aplicações de IA

Comparação Rápida

Então, se você quer a resposta curta, aqui está: use TLS 1.3 por padrão, adicione mTLS para identidade de serviço e use criptografia por campo, híbrida ou por envelope quando os dados precisarem permanecer protegidos além da própria conexão.

1. Criptografia Simétrica

A criptografia simétrica é a forma rápida de proteger dados em massa. Mas ela não resolve a troca de chaves por conta própria. Usa uma única chave compartilhada para criptografar e descriptografar, o que a torna uma parte central da segurança de APIs de IA. A escolha usual é o AES-256-GCM porque é rápido e inclui verificações de integridade embutidas ^[4][10].

Escopo de Segurança

O AES-256-GCM funciona bem em dois lugares: dados em repouso e dados em trânsito. Isso inclui conjuntos de treinamento armazenados, pesos de modelos, saídas arquivadas e a criptografia em massa usada dentro do TLS 1.3 ^[3][2]. Como o GCM é um modo AEAD, ele protege o sigilo e adiciona uma tag de autenticação que ajuda a detectar adulterações em prompts ou payloads multimodais ^[4].

Há um limite que você não pode ignorar: a criptografia simétrica só protege os dados até chegarem ao modelo. Durante a inferência, o modelo tem que trabalhar com texto puro. Isso significa que os dados em texto puro ainda podem ficar expostos na RAM ou na memória da GPU ^[7].

Impacto no Desempenho

O AES-256-GCM pode atingir 4,2 GB/s em CPUs de servidor padrão que suportam AES-NI ^[8]. Em bom português, criptografar um pequeno prompt leva microssegundos, o que é muito menos do que o atraso de rede ou o tempo de execução do modelo ^[8].

Em clientes móveis ou dispositivos de borda sem AES-NI, o ChaCha20-Poly1305 costuma ser a melhor opção. Ele é otimizado para desempenho em software, atinge 3,4 GB/s em hardware como o Apple A17 Pro e oferece o mesmo nível de segurança de 256 bits ^[8].

Gestão de Chaves

Aqui está o problema: ambos os lados precisam do mesmo segredo. Então a parte difícil é compartilhar essa chave com segurança, o que geralmente significa recorrer à criptografia assimétrica.

Em escala, as equipes frequentemente envolvem as chaves simétricas com uma KEK para poderem re-chavear os dados sem recriptografar o payload inteiro ^[2][11]. A rotação de KEK deve ser automatizada, e as chaves devem residir em um HSM validado FIPS 140-3 Nível 3 ou em um gerenciador de segredos dedicado - não em arquivos de configuração ou no código-fonte da aplicação ^[11][10].

Esse problema da chave compartilhada é exatamente o motivo pelo qual a criptografia assimétrica vem a seguir.

Melhor Caso de Uso em API de IA

A criptografia simétrica é a escolha certa para payloads em massa. Pense em imagens de alta resolução, arquivos de vídeo, longos clipes de áudio e grandes corpos de requisição JSON ^[4]. Também funciona bem para arquivamento de longo prazo e isolamento por tenant, onde as DEKs são envolvidas com chaves específicas do tenant para manter os dados separados ^[2][10].

Para transporte e troca de chaves, porém, a criptografia simétrica é apenas uma parte da pilha.

2. Criptografia Assimétrica

A criptografia assimétrica cobre a parte que a criptografia simétrica não lida bem: a troca segura de chaves e as verificações de identidade. Ela usa duas chaves vinculadas:

• uma chave pública que qualquer um pode acessar
• uma chave privada que apenas o proprietário guarda

Se os dados são criptografados com a chave pública, apenas a chave privada correspondente pode descriptografá-los.

Escopo de Segurança

A criptografia assimétrica importa porque pode manter payloads sensíveis protegidos depois que o TLS termina. O TLS protege o tráfego naquele primeiro salto. Mas assim que o tráfego passa dele, essa camada desaparece.

É aí que entra a criptografia em nível de mensagem. Quando você criptografa os dados com chaves assimétricas, conteúdo sensível - como PII dentro de um prompt - pode permanecer criptografado enquanto se move por sistemas internos de logging, service meshes e pipelines de rastreamento distribuído ^[4][12].

Ela também suporta assinaturas digitais. Essas assinaturas ajudam a verificar que um prompt veio do remetente alegado e fornecem não repúdio ^[4].

O trade-off é simples: esse nível de proteção custa muito mais em computação.

Impacto no Desempenho

A criptografia assimétrica é lenta demais para grandes payloads como imagens, vídeo ou áudio. Use-a para chaves e assinaturas, não para dados em massa ^[14].

Para assinaturas, o ECC e o Ed25519 têm melhor desempenho que o RSA e são uma escolha melhor para a autenticação moderna de APIs de IA ^[14].

Gestão de Chaves

As chaves privadas devem residir em um HSM validado FIPS 140-3 Nível 3 ou em um Trusted Execution Environment (TEE) ^[10]. As chaves públicas são frequentemente compartilhadas por meio de um endpoint JWKS (JSON Web Key Set), o que permite que os parceiros de API encontrem e verifiquem as chaves automaticamente ^[5].

A rotação de chaves deve ocorrer em um ciclo de 90 dias para limitar o dano caso uma chave seja comprometida ^[5].

A diferença de custo aqui é difícil de ignorar. No AWS KMS, as operações RSA assimétricas podem custar até $12.00 por 10.000 requisições, enquanto as operações simétricas custam cerca de $0.03 por 10.000 requisições ^[14].

Melhor Caso de Uso em API de IA

A criptografia assimétrica funciona melhor para troca de chaves e autenticação. Em APIs de IA multi-tenant, ela é mais frequentemente usada para envolver chaves simétricas e verificar a autenticidade dos prompts ^[4]. Também suporta a autenticação de cliente por meio do mTLS ^[1].

Há outra questão que as equipes precisam planejar agora: a migração pós-quântica. O RSA e o ECC padrão serão vulneráveis a futuros ataques quânticos. O NIST finalizou seus primeiros padrões de criptografia pós-quântica - FIPS 203, 204 e 205 - em agosto de 2024, e os primeiros benchmarks mostram que o ML-KEM adiciona menos de 5% de sobrecarga de desempenho em comparação com o RSA-2048 em hardware de servidor padrão ^[3][10].

Na prática, a criptografia assimétrica protege as chaves, enquanto a criptografia simétrica protege o payload.

3. Criptografia Híbrida

A criptografia híbrida protege o payload com uma DEK simétrica aleatória e, em seguida, envolve essa DEK com uma chave pública assimétrica. Em resumo, ela usa a parte rápida da criptografia para os dados em si e a parte de chave pública para a chave. Isso importa mais depois que o TLS termina, quando os dados ainda podem passar por sistemas internos.

Escopo de Segurança

A criptografia híbrida mantém os payloads criptografados mesmo depois do encerramento do TLS, incluindo dentro de service meshes, proxies e logs. Cada requisição recebe sua própria DEK de curta duração, o que reduz o raio de impacto se uma chave for exposta.

Usar AES-256-GCM também adiciona uma tag de autenticação. Essa tag ajuda a detectar adulterações antes que o sistema de IA toque o payload. Para o transporte, essa camada funciona com o TLS, não no lugar dele.

Impacto no Desempenho

Em uma configuração híbrida, a etapa assimétrica apenas envolve a DEK. O AES faz o trabalho pesado do payload em si. Isso faz o modelo funcionar bem para grandes requisições multimodais, como vídeo, imagens de alta resolução e streams de áudio, sem tornar tudo lento em escala.

Gestão de Chaves

Mantenha a KEK em um HSM, gere uma DEK de curta duração para cada requisição e anexe um key_id para que as DEKs possam ser reenvolvidas sem recriptografar o payload. Essa configuração torna a rotação de chaves muito menos dolorosa.

Para plataformas de IA multi-tenant, ela também suporta o crypto-shredding. Se você destruir a chave-mestra de um tenant, todos os payloads criptografados vinculados se tornam ilegíveis, sem precisar tocar cada registro ou backup um por um.

Melhor Caso de Uso em API de IA

A criptografia híbrida faz sentido para caminhos de API de IA onde os dados cruzam um limite de confiança depois que o TLS termina, como:

• arquiteturas multi-hop
• proxies reversos
• balanceadores de carga
• service meshes

Também se encaixa em fluxos de trabalho de conhecimento zero onde o provedor nunca lida com texto puro.

Para a migração pós-quântica, apenas a camada de envolvimento precisa mudar. Substituir o RSA ou o ECDH por ML-KEM (FIPS 203) ajuda a proteger o texto cifrado armazenado que poderia ser descriptografado posteriormente, enquanto a camada simétrica AES-256 permanece a mesma ^[10]. A criptografia híbrida cuida da proteção do payload além do TLS; a próxima camada é a autenticação de transporte com TLS e mTLS.

4. TLS 1.2/1.3

O TLS é a camada de segurança de transporte de base para qualquer API de IA. O TLS 1.3 deve ser o padrão. Se a criptografia híbrida protege os dados além da borda da rede, o TLS protege a viagem pela própria rede. Em resumo: o TLS protege os dados em trânsito, enquanto a criptografia de payload cobre o que ainda pode ficar exposto depois que o TLS termina.

Escopo de Segurança

O TLS 1.3 descarta conjuntos de cifras legadas fracas como RC4, DES e 3DES. O TLS 1.2 ainda pode permiti-las se você não as desativar por conta própria ^[10][18]. O TLS 1.3 também exige Perfect Forward Secrecy (PFS) e criptografa o certificado do cliente durante o handshake, o que torna o monitoramento passivo das relações internas entre serviços muito mais difícil ^[15][17].

Impacto no Desempenho

O TLS 1.3 reduz o handshake de 2 RTTs para 1 ^[15][9]. Isso pode parecer pouco, mas em cargas de alta frequência como streaming de áudio ou vídeo em tempo real, ajuda a reduzir a latência de p99 e alivia a carga da CPU.

O TLS 1.3 também permite a retomada 0-RTT, para que sessões retomadas possam enviar dados imediatamente. Isso é rápido, mas há um trade-off: o 0-RTT tem risco de replay. Para rotas de API sensíveis, desative o 0-RTT ^[16].

Gestão de Chaves

O manejo de certificados é onde muitas equipes ou se mantêm afiadas ou ficam desleixadas. O caminho mais seguro é simples:

• Rotacione os certificados a cada 90 dias ^[16][9]
• Use emissão automatizada para endpoints públicos como o Let's Encrypt ^[1]
• Armazene chaves privadas em HSMs ou TEEs, não em arquivos PEM exportáveis ^[3][10]
• Em configurações regulamentadas, use módulos validados FIPS 140-3 ^[10]
• Se o TLS 1.2 não puder ser atualizado, permita apenas conjuntos de cifras baseados em ECDHE para que o forward secrecy permaneça em vigor ^[10]
• Habilite o stapling de OCSP para que as verificações de certificado sejam mais rápidas e não adicionem outra ida e volta de rede durante o handshake ^[9]

Melhor Caso de Uso em API de IA

O TLS 1.3 é o padrão certo para endpoints públicos, aplicações de navegador e streams WebSocket multimodais em tempo real ^[15][16]. O TLS 1.2 ainda é aceitável como piso de compatibilidade para integrações corporativas mais antigas, mas apenas se estiver restrito a conjuntos de cifras somente-PFS ^[10].

Para tráfego serviço-a-serviço, o mTLS adiciona verificação de identidade.

5. Mutual TLS (mTLS)

O mTLS se baseia no TLS ao verificar ambos o cliente e o servidor com certificados antes que qualquer dado da aplicação seja enviado.

Escopo de Segurança

Isso preenche uma lacuna que as chaves de API deixam para trás. Uma chave de API prova um segredo. Ela não prova qual carga de trabalho está fazendo a chamada.

Para agentes de IA, microsserviços e outras identidades de carga de trabalho, o mTLS limita o acesso a serviços verificados. Isso importa em endpoints de modelo sensíveis e quando os sistemas trocam dados multimodais como imagens e voz ^[15][13][20].

Impacto no Desempenho

A principal desvantagem é o trabalho extra de handshake. O mTLS geralmente adiciona cerca de 1 a 2 milissegundos de latência e 5 a 10% mais tempo de handshake do que o TLS padrão ^[21].

Uma forma comum de reduzir esse impacto é encerrar o mTLS em um API gateway ou firewall de borda. Isso mantém o trabalho de cripto assimétrica longe do runtime do modelo ^[17][15]. Pooling de conexões e cabeçalhos keep-alive também ajudam a distribuir esse custo por muitas requisições em vez de pagá-lo do zero a cada vez ^[21].

Gestão de Chaves

O mTLS precisa de um processo forte de PKI para emissão, rotação e revogação de certificados ^[6][19]. Essa parte não pode ser tratada de forma displicente. Se uma renovação de certificado for perdida, o tráfego serviço-a-serviço pode falhar na hora ^[19].

Use ferramentas de PKI automatizadas para lidar com emissão, rotação e revogação em escala. Para chaves privadas, o armazenamento respaldado por hardware como HSMs ou TPMs por meio do PKCS#11 ajuda a manter as chaves não exportáveis ^[13]. Certificados de curta duração também reduzem o risco. O SPIFFE recomenda tempos de vida tão curtos quanto 1 hora para identidades de carga de trabalho ^[21].

Melhor Caso de Uso em API de IA

O mTLS funciona melhor para tráfego máquina-a-máquina. Pense em agentes de IA chamando bancos de dados internos, microsserviços passando dados multimodais sensíveis e integrações regulamentadas que precisam de prova criptográfica de origem. Nessas configurações, o mTLS atua como uma camada extra de autenticação ao lado da autenticação por chave de API ^[15][20].

Use o mTLS para identidade na camada de conexão. Use a criptografia por campo quando certos campos precisam permanecer protegidos mesmo depois do transporte.

6. Criptografia por Campo

O mTLS diz quem está chamando. A criptografia por campo protege os valores sensíveis dentro do que eles enviam.

A diferença-chave é simples: em vez de criptografar o payload inteiro, a criptografia por campo cobre apenas os campos que devem permanecer ocultos depois que o transporte termina. Isso significa que a proteção ainda importa mesmo depois que o TLS e o mTLS cumpriram sua parte.

Escopo de Segurança

O TLS protege os dados em trânsito. A criptografia por campo protege os dados em si depois que o TLS termina.

Essa abordagem criptografa apenas os campos que precisam de cuidado extra, como números de seguridade social, notas médicas e números completos de cartão de pagamento. Como resultado, esses valores permanecem criptografados em lugares onde os dados costumam ficar, como logs, filas, backups e dumps de banco de dados.

Há um trade-off, porém. O modelo só pode trabalhar com os campos deixados em texto puro. Então, se o modelo precisa de um valor para fazer seu trabalho, esse campo não pode permanecer criptografado no momento da inferência. Na prática, isso significa que você deve criptografar apenas o que o modelo não precisa. Há também um pequeno custo de processamento para cada campo protegido.

Impacto no Desempenho

A criptografia por campo geralmente adiciona 5% a 10% de latência porque cada campo protegido tem que ser criptografado e descriptografado por conta própria.

Esse custo costuma ser aceitável, mas apenas se o manejo de chaves e os IDs de campo forem mantidos limpos. Se não forem, a sobrecarga pode se acumular rapidamente.

Gestão de Chaves

A criptografia por campo vem com três controles que mais importam:

• Use isolamento de chave por tenant. Se todos os tenants compartilham uma chave, um único comprometimento pode expor os dados de todos ^[10].
• Inclua um Key ID ou tag de versão junto a cada campo criptografado para que dados legados ainda possam ser descriptografados após a rotação sem quebrar os registros existentes ^[1].
• Use chaves de campo por tenant para limitar a exposição se um tenant for comprometido.

Melhor Caso de Uso em API de IA

A criptografia por campo funciona melhor quando apenas uma pequena parte do prompt deve permanecer secreta, enquanto o restante ainda precisa continuar utilizável pelo modelo.

• SaaS de IA multi-tenant - chaves por tenant limitam o raio de impacto se um tenant for comprometido.
• Pipelines de logging externos - a PII permanece criptografada mesmo quando os logs são enviados para fora da plataforma.
• APIs de IA de saúde ou financeiras - campos sensíveis permanecem criptografados em logs, dumps de banco de dados, filas e backups.
• Fluxos de trabalho de inferência parcial - o modelo lê apenas os campos não sensíveis.

7. Criptografia por Envelope

A criptografia por envelope é uma forma prática de proteger grandes payloads sem transformar a rotação de chaves em um pesadelo. A ideia é simples: você criptografa os dados com uma DEK e, em seguida, criptografa essa DEK com uma KEK.

Veja como funciona em bom português. Uma Data Encryption Key (DEK) aleatória criptografa o payload de IA real, seja texto, uma imagem ou um arquivo de vídeo, usando criptografia simétrica rápida como o AES-256. Em seguida, uma Key Encryption Key (KEK), mantida em um KMS ou HSM, criptografa a própria DEK. O objeto que você armazena ou envia inclui duas coisas: o payload criptografado e a DEK envolvida. Essa configuração torna a criptografia por envelope uma boa opção quando o tamanho do payload e a rotação de chaves importam mais do que o controle por campo.

Escopo de Segurança

A criptografia por envelope protege os dados na camada de aplicação. Então, mesmo depois que o TLS termina, o payload permanece protegido em lugares como logs, filas e backups.

Há um limite que você não pode ignorar: os dados ainda têm que ser descriptografados na memória durante a inferência de IA. A menos que você combine a criptografia por envelope com Computação Confidencial, como TEEs, ainda há uma janela em que o texto puro existe na memória da GPU ou CPU ^[3][7]. Esse é o trade-off. A grande vantagem aparece quando você está lidando com dados em escala e não quer recriptografar quantidades enormes deles toda vez que uma chave muda.

Impacto no Desempenho

A criptografia por envelope é muito mais prática do que a criptografia assimétrica direta. Por quê? Porque o AES-GCM cuida do trabalho pesado do payload, enquanto a cripto assimétrica protege apenas a pequena DEK.

Essa configuração adiciona cerca de 3% a 7% de sobrecarga em alguns ambientes ^[5].

Para APIs de IA multimodais que processam imagens de alta resolução ou vídeo, o AES-GCM é uma escolha forte porque fornece criptografia autenticada, ou AEAD. Em resumo, ele ajuda a confirmar que o payload não foi alterado em trânsito ^[4].

Gestão de Chaves

É aqui que a criptografia por envelope brilha. Os corpora de treinamento de IA podem crescer para terabytes ou até petabytes ^[2]. Recriptografar um conjunto de dados inteiro toda vez que uma chave muda seria uma tarefa operacional brutal.

Com a criptografia por envelope, você não toca no payload. Você apenas reenvolve a pequena DEK com uma nova KEK ^[2].

Algumas regras básicas importam aqui:

• Armazene as KEKs em um KMS ou HSM nativo de nuvem, não em variáveis de ambiente da aplicação.
• Adicione metadados de versão a registros de longa duração para que dados mais antigos ainda possam ser descriptografados após uma mudança de chave ^[1].

Melhor Caso de Uso em API de IA

A criptografia por envelope funciona bem para grandes payloads, isolamento multi-tenant e dados armazenados de longa duração onde a rotação de chaves precisa permanecer sã. Se o payload é grande, armazenado por muito tempo ou caro de reprocessar, esse padrão geralmente faz sentido.

Prós e Contras por Cenário de Implantação

Nenhum método de criptografia isolado se encaixa em todos os casos. A escolha certa depende de o que você está protegendo - texto, imagens, áudio, vídeo e metadados regulamentados - para onde esses dados se movem e quanta latência você consegue tolerar. A matriz abaixo usa a mesma lente da seção anterior: escopo, latência, gestão de chaves e se a proteção ainda se mantém após o encerramento.

Esta tabela transforma a comparação método por método anterior em escolhas de implantação.

Esses cenários deixam uma coisa clara: a segurança de transporte tem um ponto de parada, e a proteção na camada de aplicação começa onde o transporte termina.

Use proteção apenas de transporte somente quando os dados permanecem dentro de um limite confiável e não precisam de proteção depois do encerramento do TLS. Uma vez que o TLS termina, o texto puro alcança os serviços que o processam. Essa é a lacuna que a criptografia na camada de aplicação pretende fechar.

Para cargas de trabalho multimodais regulamentadas, a pilha padrão costuma ser:

• TLS 1.3 para transporte
• mTLS para identidade
• Criptografia por campo ou por envelope para dados que devem permanecer protegidos após o encerramento

Essa pilha em camadas é o padrão prático para APIs de IA regulamentadas.

Use mascaramento, não criptografia, quando o modelo precisa do contexto do campo, mas não do valor bruto em si. O mascaramento preserva o significado. A criptografia o remove. Por exemplo, substituir [email protected] por [EMAIL] ainda permite que o modelo leia a frase corretamente sem nunca ver o endereço real.

Conclusão

Nenhum método de criptografia isolado faz tudo. A escolha se resume a escopo, latência e uma pergunta simples: onde seus dados ainda estão expostos depois que o TLS termina? Na prática, a decisão se divide em três camadas: transporte, identidade e proteção de payload.

O TLS 1.3 é a camada de transporte padrão para APIs de IA. O TLS 1.2 deve ser usado apenas como fallback para sistemas legados. A partir daí, outros métodos entram para cobrir as lacunas que o TLS deixa para trás. A criptografia híbrida é o modelo mais prático na camada de aplicação porque resolve a distribuição de chaves sem tornar lenta a criptografia em massa. Use o mTLS para verificar a identidade da máquina. Depois use a criptografia por campo ou por envelope para dados que precisam permanecer protegidos mesmo depois que o TLS termina. A criptografia por envelope é especialmente útil para grandes cargas de trabalho de IA porque rotacionar uma KEK evita recriptografar petabytes de dados ^[2].

Quando você junta essas camadas, elas protegem todo o caminho da requisição. Em implantações de alta segurança, as camadas não são opcionais: o TLS cuida do transporte, o mTLS cuida da identidade, e a criptografia por campo ou por envelope protege os dados que devem permanecer seguros depois que o TLS termina.

Perguntas Frequentes

Quando o TLS 1.3 não é suficiente?

O TLS 1.3 ajuda a proteger os dados enquanto eles se movem entre sistemas. Mas essa proteção para no limite do servidor.

Uma vez que os dados chegam a um servidor de IA, eles têm que ser descriptografados para que o modelo possa processá-los. E isso cria uma lacuna: os dados podem então ficar expostos na memória, em logs ou em caches.

É por isso que o TLS 1.3 sozinho não é suficiente quando os dados precisam de proteção além do trânsito.

Ele também não lida com algumas outras questões:

• Integridade dos dados ao longo de todo o ciclo de vida do payload
• Autenticidade da parte que computa, para que você saiba quem está processando os dados
• Proteção de longo prazo contra ataques baseados em quântica

Então, se você precisa de controles mais rígidos, vai querer camadas extras sobre o TLS 1.3, como criptografia em nível de payload e tokens assinados.

Devo usar mTLS para toda API de IA?

Nem sempre. Se você deve usar o mTLS para toda API de IA depende das suas necessidades de segurança e de quanta complexidade sua configuração consegue lidar.

Ele faz mais sentido para conexões de alto valor. Isso inclui tráfego interno serviço-a-serviço, APIs administrativas e transferências que envolvem dados sensíveis. Em muitos casos, uma configuração em camadas funciona melhor: use o TLS 1.3 padrão para o tráfego geral e exija o mTLS apenas em rotas sensíveis.

Como escolho entre criptografia por campo e por envelope?

Escolha a criptografia por campo quando você precisa de proteção rígida para valores sensíveis específicos, como tokens de API ou identificadores pessoais. Ela mantém esses valores criptografados mesmo quando aparecem em logs, caches ou backups. Isso ajuda a limitar o dano de uma violação e pode apoiar necessidades de conformidade.

Escolha a criptografia por envelope quando você precisa de proteção eficiente para payloads maiores. Ela criptografa os dados com uma DEK e depois envolve essa chave com uma KEK. Essa configuração torna a rotação e a gestão de chaves mais fáceis.