Testa e vê o que acontece é um jeito. Auditoria é outro.
Termos mais procurados:
Histórico de mensagens em pix
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Conceito de Payload Locations no PIX
- Consulta de Chave PIX na API de Envio
- Teste de Status de Pagamento em Ambiente de Homologação
- Repetição do Processo de Criação com txid
- Implementação da SDK do Pix em Next.js ou React
- Autenticação com Certificado em NextJS
- Configuração de URLs para Recebimento de Status
- Problemas com Token em Ambiente de Homologação
- Recebimento de Pagamentos via QR Code e Arduino
- Endpoint para Recuperar Saldo
- Implementação do Módulo Gerencianet no Perfex CRM
- Integrações com o Laravel e SDK de PHP da EFI
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Especificação da URL do Webhook no Exemplo Pix
- Cobrança em Período de Teste Grátis de 7 dias
- Retenção de Pagamento no PIX em Marketplace
- Atualização de informações no Retentiva de Cobrança
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
- Geração de payment_token pelo Postman e teste em homologação
- Utilização de Endpoints e Payload no Pix
- Funcionamento do Webhook em Ambiente de Homologação
- Acionamento de Webhooks em Pagamentos e Devoluções
- Cancelamento de Boleto e Remoção do DDA
EXIBINDO CONVERSAS RECENTES:
Canal: pix
Notar que a Gerencianet não diz que o mTLS não é necessário, e sim que o integrador pode ter outras formas de implementá-lo em camada de aplicação e aí garantir o mesmo nível de segurança. Então quem não estiver validando se o cliente é mesmo a Gerencianet, está em violação da documentação do Pix.
mas "não seguir" mTLS seria não enviar o certificado. se é o EC que valida, qual a responsabilidade do PSP? qual o critério pra saber que o EC não tá validando?
E não seguir o mTLS é uma violação bem evidente na postura de segurança, mesmo não sendo a única.
Assegurar a segurança do desenvolvimento do software cliente85 da API, mesmo que
desenvolvido por terceiros. Sugere-se que o PSP institua e mantenha processo de
homologação dos softwares clientes, estabelecendo critérios mínimos de segurança para que
eles sejam autorizados a interagir com a API. Nesse caso, a API deve negar tentativas de
comunicação de clientes não homologados.
5. Os usuários recebedores, como clientes da API, são um elo importante na segurança do
sistema, e, portanto, recomenda-se que o PSP tome ações para mitigar os riscos do ambiente
computacional dos seus usuários, uma vez que caso um risco se materialize em um incidente,
o próprio PSP poderá ser afetado. Ações recomendadas (sem prejuízo para outras ações que
o PSP julgar importantes):
a. Instituir e acompanhar programa de melhoria contínua da segurança dos usuários
recebedores que utilizam a API;
b. Realizar campanhas de conscientização e compartilhamento de informações de
segurança junto aos usuários;
c. Definir uma política de troca periódica do certificado, senha e outras credenciais
utilizadas no acesso à API;
d. Validar a segurança do ambiente computacional dos usuários nos aspectos de
infraestrutura, implementação e configuração do software cliente da API.
e. Exigir que as empresas e instituições que utilizem a API tenham uma Política de
Segurança da Informação formalmente instituída.
desenvolvido por terceiros. Sugere-se que o PSP institua e mantenha processo de
homologação dos softwares clientes, estabelecendo critérios mínimos de segurança para que
eles sejam autorizados a interagir com a API. Nesse caso, a API deve negar tentativas de
comunicação de clientes não homologados.
5. Os usuários recebedores, como clientes da API, são um elo importante na segurança do
sistema, e, portanto, recomenda-se que o PSP tome ações para mitigar os riscos do ambiente
computacional dos seus usuários, uma vez que caso um risco se materialize em um incidente,
o próprio PSP poderá ser afetado. Ações recomendadas (sem prejuízo para outras ações que
o PSP julgar importantes):
a. Instituir e acompanhar programa de melhoria contínua da segurança dos usuários
recebedores que utilizam a API;
b. Realizar campanhas de conscientização e compartilhamento de informações de
segurança junto aos usuários;
c. Definir uma política de troca periódica do certificado, senha e outras credenciais
utilizadas no acesso à API;
d. Validar a segurança do ambiente computacional dos usuários nos aspectos de
infraestrutura, implementação e configuração do software cliente da API.
e. Exigir que as empresas e instituições que utilizem a API tenham uma Política de
Segurança da Informação formalmente instituída.
e a pergunta oposta: quem disse que o PSP deve mandar request pra URL do webhook no momento do PUT? isso não tá previsto. eu poderia configurar o webhook com o PUT sem a URL estar sequer alcancável
<@!780500321994539068> mas isso não é determinado no manual. Além disso, quem garante que validando no setup, o EC vai continuar validando quando receber os callbacks efetivos?
Que é, na prática, o que acontece qdo não é enviado o novo header, certo? O endpoint PUT /webhook/:chave retorna 403.
<@!780500321994539068> o manual de segurança diz que o callback deve ser enviado por canal mTLS. mas como o PSP pode garantir que o canal é mTLS? não existe isso. ele envia com certificado e o cliente verifica se ele quiser. não tem como a GN saber se o cliente tá validando.
não é bem assim. na verdade, a conexão mTLS não tem como ser validada dos dois lados. quem envia o request manda o certificado e o recebedor é responsável por validar, mas não tem como o emissor impedir que o outro lado "consuma" o request sem validar o certificado enviado. então a norma do BACEN, na prática, obriga o PSP a enviar o certificado e dar meios pro cliente verificar (e rejeitar o request se quiser). mas o EC pode simplesmente ignorar a verificação. o que o novo parâmetro faz é desligar a verificação que a GN faz (por iniciativa dela, não por obrigação) enviando um request sem certificado primeiro para testar se o EC valida. então se vc usa esse parâmetro, você poderá receber callbacks depois, que virão com o certificado, e recebe os dados normalmente mesmo que não valide o certificado (ou seja, sem "fechar mTLS").
pensando aqui nem vejo uma maneira de testar isso localmente, provavelmente tenho que subir o projeto e fazer o apontamento do dns