{"section":"tutorials","requestedLocale":"pt","requestedSlug":"mutual-transport-layer-security-mtls","locale":"pt","slug":"mutual-transport-layer-security-mtls","path":"docs/pt/tutorials/segurança/vtex-shield/mutual-transport-layer-security-mtls.md","branch":"main","content":"> ℹ️ Esta funcionalidade faz parte do produto [VTEX Shield](/pt/docs/tutorials/vtex-shield). Se já é cliente da VTEX e deseja adotar o VTEX Shield no seu negócio, entre em contato com o [Suporte Comercial](/pt/docs/tracks/suporte-comercial). É possível que taxas adicionais se apliquem. Se ainda não é cliente, mas tem interesse nesta solução, preencha o [formulário de contato](https://vtex.com/pt-br/contato/). \n\nEm integrações entre sistemas, especialmente quando há troca de informações sensíveis ou controle de operações de negócio, garantir que ambas as pontas da comunicação sejam confiáveis é essencial. O mTLS é uma solução oferecida pelo [VTEX Shield](/pt/docs/tutorials/vtex-shield) que adiciona um nível avançado de segurança às integrações entre sistemas externos e a VTEX.\n\n## Conceitos-chave\n\nAntes de entender como o mTLS funciona na prática, é importante relembrar dois conceitos fundamentais de integrações entre sistemas: a arquitetura cliente-servidor e o papel dos certificados digitais.\n\n### Arquitetura cliente-servidor\n\nToda comunicação entre sistemas baseada em APIs segue, em essência, uma **arquitetura cliente-servidor**. Nessa arquitetura, um sistema (cliente) faz uma requisição, e o outro (servidor) responde. No modelo tradicional (TLS/HTTPS), apenas o servidor apresenta um certificado digital, que é verificado pelo cliente.\n\n### Certificados digitais\n\nUm certificado digital é como uma identidade eletrônica que um sistema usa para comprovar sua identidade durante uma conexão. Ele é emitido por uma Autoridade Certificadora (CA), que atua como uma terceira parte confiável que valida identidades digitais.\n\n* O servidor apresenta seu certificado, e o cliente verifica se foi emitido por uma CA confiável. \n* No caso do mTLS, o processo é bidirecional: além do servidor, o cliente também apresenta o seu certificado, e o servidor verifica se ele foi emitido pela CA correta.\n\nEssa troca mútua de certificados permite que ambos os lados da comunicação validem a identidade um do outro, aumentando significativamente a segurança da integração.\n\n## Funcionamento do mTLS\n\nEm vez de apenas criptografar o tráfego com base na autenticação do servidor (como no protocolo TLS padrão), o mTLS exige que cliente e servidor apresentem certificados digitais válidos.\n\nCom o mTLS, apenas sistemas confiáveis possam se comunicar, reforçando a segurança das integrações e evitando acessos não autorizados. Ou seja, toda comunicação entre o um storefront headless e a VTEX ou entre um ERP e a VTEX, em qualquer direção, é protegida por autenticação mútua e criptografia, impedindo que conexões não autorizadas acessem dados sensíveis ou manipulem as informações trocadas.\n\nO diagrama abaixo representa o fluxo de autenticação mútua utilizando mTLS, no qual cliente e servidor validam suas identidades antes de qualquer troca de dados:\n\n\n\n1. O cliente inicia a conexão com o servidor. \n2. O servidor apresenta seu certificado TLS. \n3. O cliente verifica se o certificado do servidor é válido. \n4. O cliente, então, apresenta seu próprio certificado TLS. \n5. O servidor verifica o certificado do cliente. \n6. Após a verificação mútua, o acesso é concedido. \n7. A comunicação segue de forma criptografada e segura, com base na confiança estabelecida entre as partes.\n\n### Fluxo do mTLS no contexto da VTEX\n\nEntenda a seguir como o fluxo se aplica à comunicação entre os sistemas da VTEX e o os sistemas do lojista. Em alguns casos, a VTEX atua como cliente, e em outros como servidor.\n\n| Sentido da requisição | Explicação |\n| :---- | :---- |\n| **Loja headless ou ERP/WMS → VTEX** | Quando uma requisição parte da loja para a VTEX, ela é roteada para um **proxy mTLS de entrada** localizado dentro da nossa VPC.
Esse proxy valida o certificado que acompanha a requisição, verificando se foi emitido pela CA da VTEX.
Somente após essa validação com sucesso a chamada é encaminhada aos microsserviços internos. |\n| **VTEX → Loja headless ou ERP/WMS** | No caso da VTEX enviando uma requisição para a loja, o tráfego passa por um **proxy mTLS de saída** dentro da nossa VPC, que injeta o certificado emitido pela CA do lojista.
Isso permite que o ambiente do lojista verifique a autenticidade da requisição e aceite apenas conexões legítimas e seguras. |\n\n## Vantagens\n\nOs principais benefícios do uso do mTLS na VTEX são:\n\n* **Autenticação mútua:** cliente e servidor validam a identidade um do outro antes de qualquer troca de dados, impossibilitando tentativas de acesso não verificadas.\n\n* **Criptografia ponta a ponta:** todos os dados são criptografados, protegendo informações sensíveis de clientes e detalhes de transações contra interceptações.\n\n* **Integração sem fricção:** os lojistas podem integrar o mTLS rapidamente com suas APIs de comércio e aplicações de terceiros, reduzindo complexidade e riscos.\n\n* **Proteção flexível:** é possível habilitar mTLS apenas para as integrações desejadas, como provedores de pagamento ou ERPs, adaptando o nível de segurança conforme o caso de uso.\n\n### Proteção contra ataques\n\nAo autenticar ambos os lados da conexão, o mTLS ajuda a prevenir ataques como:\n\n* **Man-in-the-Middle (MitM):** também conhecido como “on-path”, ocorre quando agentes maliciosos se posicionam entre o cliente e o servidor para interceptar ou alterar comunicações. Com mTLS habilitado, os atacantes não conseguem se autenticar como cliente ou servidor, tornando esse tipo de ataque praticamente impossível.\n\n* **Chamadas de API maliciosas:** o mTLS garante que chamadas de API sejam feitas apenas por usuários legítimos e autenticados. Isso evita que atacantes enviem requisições maliciosas com o objetivo de explorar vulnerabilidades ou manipular o funcionamento da API.\n\n* **Ataques de spoofing:** atacantes podem tentar “falsificar” um servidor web para enganar um usuário (ou o contrário). Com a exigência de autenticação por certificados TLS de ambos os lados, esse tipo de ataque se torna muito mais difícil.\n\n* **Credential stuffing:** cibercriminosos usam combinações de credenciais vazadas para tentar acessos não autorizados. Sem um certificado TLS emitido legitimamente, ataques de credential stuffing são ineficazes contra organizações que utilizam mTLS.\n\n## Requisitos\n\nComo o mTLS é uma proteção para integrações entre sistemas, a ponta oposta à VTEX precisa ser um outro sistema, por exemplo: um middleware que processa o frontend de uma integração headless, ou que processa chamadas para um ERP ou WMS.\n\nPor isso, para utilizar o mTLS, a loja precisa cumprir com pelo menos um dos requisitos a seguir:\n\n- Operar em um modelo headless, no qual todas as interações com a VTEX são feitas por meio de integrações baseadas em API.\n\n > ⚠️ O uso de mTLS não se aplica a implementações com storefront nativo, como [Store Framework](/pt/docs/tracks/cms-vtex-io) e [CMS Portal (Legado)](/pt/docs/tracks/cms-portal-legado). \n\n- Ter uma ou mais integrações via API com serviços externos (ERPs, WMS, sellers externos etc.).\n\n### Requisitos adicionais para integrações com retorno da VTEX\n\nPara qualquer situação em que a VTEX precise enviar requisições de volta ao ambiente do lojista, como em integrações com sellers externos ou fluxos de login, os requisitos a seguir se aplicam:\n\n* O lojista deve possuir uma CA própria. Essa CA é responsável por emitir o certificado que a VTEX apresentará, permitindo que o lojista valide a autenticidade das requisições provenientes da VTEX. \n* O servidor do lojista deve estar configurado para exigir ou solicitar o certificado do cliente durante o *handshake* TLS. Isso normalmente é feito ajustando as configurações de SSL/TLS para habilitar a autenticação mútua. Dessa forma, garante-se que ambos os lados da conexão possam validar suas identidades antes da troca de qualquer dado.\n\n## Modalidades de uso\n\nO mTLS pode ser implementado de forma total ou apenas em integrações específicas, oferecendo flexibilidade conforme as necessidades de segurança da loja. Saiba mais a seguir sobre as modalidades disponíveis para contratação.\n\n### mTLS com cobertura total\n\n* Proteção abrangente por mTLS para todas as comunicações de entrada e saída entre a VTEX e o servidor de destino do lojista. \n* Garante que todas as trocas de dados sejam protegidas por autenticação mútua, assegurando a segurança de cada interação de API em todo o ecossistema.\n\n### mTLS por integração específica\n\n* Proteção mTLS apenas em integrações específicas, em vez de uma cobertura total da plataforma. \n* Protege conexões selecionadas com serviços externos, como ERPs, WMSs/TMSs, sellers externos e outros sistemas de terceiros.\n\n## Saiba mais\n\n* [VTEX Shield](/pt/docs/tutorials/vtex-shield)\n* [mTLS API](https://developers.vtex.com/docs/api-reference/mtls-api#overview)\n* [Implementing Mutual Transport Layer Security (mTLS)](https://developers.vtex.com/docs/guides/implementing-mtls)\n* [Revoking SSL private certificates when using Mutual Transport Layer Security (mTLS)](https://developers.vtex.com/docs/guides/revoking-ssl-private-certificates-when-using-mtls)"}