Manual de Segurança do SFN — Volume II (Segurança do Pix)

Separação de certificados, gestão de acesso e retenção variam por objeto. Obrigação de proteger chave privada não autoriza incluí-la no histórico; terceirização do site QR mantém responsabilidade PSP.

• Volume II 6.00 trata segurança Pix; Volume I também se aplica com exceções específicas de habilitação/ativação e mensageria. Requisitos abrangem SPI, DICT, QR, sistemas e auditoria, sem eleger fornecedor único. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 6Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 7Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 8Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 10
• Comunicação RSFN usa HTTP 1.1, TLS 1.2 ou superior, autenticação mútua e suite mínima indicada; cliente respeita TTL DNS. IP ICOM deve ser previamente autorizado no módulo SPI SPB-Web em homologação/produção; gestão formal inclui revisão/registro, com IPs efetivos ou de contingência, não toda faixa. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 12
• Mensagens SPI são assinadas pelo direto emissor; DICT só consulta GET dispensa assinatura de requisição, e respostas BC são assinadas. XMLDSig usa RSA-SHA256/SHA-256 e canonicalização exclusiva. SPI assina Document, AppHdr e KeyInfo; DICT raiz e KeyInfo, com referências diferentes. Verificação compara digests e assinatura, retornando erro se falha. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 13Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 14Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 15Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 16Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 19Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 21Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 23
• QR dinâmico do recebedor usa URL HTTPS/TLS e JWS assinado; PSP responde pela segurança/disponibilidade mesmo com prestador contratado. CAA DNS é recomendação adicional. URL sem protocolo tem máximo setenta e sete caracteres; token mínimo cento e vinte bits aleatórios e não dedutível; UUID se escolhido deve ser versão quatro com aleatoriedade real. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 25Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 26
• JWS proíbe HS* e none, admite RS256/ES256 ou superiores e recomenda PS256/PS512. Cabeçalho e JWK Set identificam chave/certificado; assinatura, cadeia, domínio e cadastro do site são validados antes de processar payload. Aplicativo produção rejeita host de homologação com sufixo -h. Otimizar verificação não pode reduzir segurança. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 27Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 28Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 29
• Histórico de QR inclui JWS, certificados e chaves públicas, sem guardar chave privada para esse fim. Aproximação com pagador online exige senha/biometria de acesso, tela de confirmação após aproximação e todos requisitos de segurança QR. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30
• Certificados ICP-Brasil padrão SPB de participante direto são exclusivos Pix e separados por finalidade: CERTPIC canal não assina como CERTPIA e inverso; não usar no SPB/MES. QR site usa EV/domínio sem wildcard/autenticação servidor e exclusivo canal Pix; certificado JWS é exclusivo assinatura QR/Pix e está no JWK, sem ativação própria no Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 31Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32
• Ativação envia PEM ao STA do ambiente correto, sem cadeia e sem chave privada, nos códigos CPIC/CPIA/CQRC. BC tem sete dias para ativar; envio antecipado e comercial é recomendado. Acesso SCERTQRC só autorizados e revisado anualmente. Para site QR, validação completa é do participante e aviso de recebido difere de aceito/ativado do canal/assinatura. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 33
• Arquivo CERTQRC ARQ tem no máximo um download por vinte e quatro horas e cache nesse período; consulta de modificação pode evitar novo download. Pagador verifica revogação que pode ocorrer entre atualizações. Certificados novos ativados são distribuídos aos softwares em até sete dias; recebedor esperar sete dias após cadastro no BC para implementar novo certificado no site de QR é recomendação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34
• Gestão de certificados e proteção de chaves privadas é obrigatória; HSM é recomendado, sem impor produto único. Múltiplos certificados ativos podem coexistir. BC comunica novos com mínimo sete dias e pode ativar gradualmente; participante deve aceitar mais de um válido. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 35Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36
• Certificado desativa automaticamente vinte e quatro horas antes de expirar. Pedido exige BC Correio e posterior contato à Central, com dados e modalidade; prazo conta do contato posterior. Programada ocorre em até dois dias úteis do rito integral, ou data posterior indicada. Incidente é regime contínuo só para comprometimento por ataque/exposição privada; homologação sempre programada. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37
• Revogação BC comprovada exige rejeitar e avisar DEINF; se status BC não verificável por falha, avisar e aceitar temporariamente enquanto não resolvido. QR de outro participante, ao contrário, é rejeitado se revogado ou impossível verificar. Consulta assíncrona frequente de revogação é recomendada; exceção BC não libera QR sem verificação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 38
• Sistemas Pix devem prevenir riscos descritos OWASP e proteger dados. Criptografia/autenticação forte cliente e proteção contra adulteração são obrigatórias; segurança majoritariamente no servidor. mTLS é exemplo nesse recorte de sistemas do participante, distinto da autenticação mútua obrigatória com APIs Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 39Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11
• App recebe só dados necessários. Consulta chave/QR não expõe CPF completo, conta/agência ou dados de segurança de chaves; exceção de dados bancários é inserção manual nos ambientes Pix/Open Finance. Base interna usa Token Bucket igual ou mais restritivo que DICT e limita requisições por software. Site de consultas/transações exige usuário logado e proteção contra robôs; mecanismos listados são possibilidades. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40
• Dados de auditoria têm entradas UTC e, solicitados, são fornecidos descriptografados no formato BC. Retenção ICOM: dez anos de XML completo, PI-ResourceId quando existente e incidentes/fraudes. DICT: consulta dois anos, escrita/sincronismo/MED dez e incidentes dez. APIs próprias: consulta chave e transações dois anos; incidentes/varredura/fraudes dez. Cabeçalhos mínimos quando existentes são obrigatórios, completos recomendados. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 42Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 43
• Certificados inclusive desativados e chaves públicas ficam para validação histórica; armazenamento histórico de privadas é expressamente vedado. Privadas permanecem apenas nos ambientes seguros/restritos para assinatura/decifragem. BC pode alterar prazos de retenção a qualquer tempo; recomendação de criptografar logs não elimina dever de fornecimento legível. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30

O que esta leitura não diz. Não há parecer de conformidade, sanção calculada ou obrigação de comprar fornecedor/HSM específico.

QR e aproximação dependem de validações antes de processar/confirmar. Aproximação tem senha/biometria e tela de confirmação; dados exibidos têm restrições e exceção de inserção manual.

• Volume II 6.00 trata segurança Pix; Volume I também se aplica com exceções específicas de habilitação/ativação e mensageria. Requisitos abrangem SPI, DICT, QR, sistemas e auditoria, sem eleger fornecedor único. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 6Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 7Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 8Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 10
• Comunicação RSFN usa HTTP 1.1, TLS 1.2 ou superior, autenticação mútua e suite mínima indicada; cliente respeita TTL DNS. IP ICOM deve ser previamente autorizado no módulo SPI SPB-Web em homologação/produção; gestão formal inclui revisão/registro, com IPs efetivos ou de contingência, não toda faixa. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 12
• QR dinâmico do recebedor usa URL HTTPS/TLS e JWS assinado; PSP responde pela segurança/disponibilidade mesmo com prestador contratado. CAA DNS é recomendação adicional. URL sem protocolo tem máximo setenta e sete caracteres; token mínimo cento e vinte bits aleatórios e não dedutível; UUID se escolhido deve ser versão quatro com aleatoriedade real. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 25Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 26
• JWS proíbe HS* e none, admite RS256/ES256 ou superiores e recomenda PS256/PS512. Cabeçalho e JWK Set identificam chave/certificado; assinatura, cadeia, domínio e cadastro do site são validados antes de processar payload. Aplicativo produção rejeita host de homologação com sufixo -h. Otimizar verificação não pode reduzir segurança. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 27Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 28Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 29
• Histórico de QR inclui JWS, certificados e chaves públicas, sem guardar chave privada para esse fim. Aproximação com pagador online exige senha/biometria de acesso, tela de confirmação após aproximação e todos requisitos de segurança QR. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30
• Certificados ICP-Brasil padrão SPB de participante direto são exclusivos Pix e separados por finalidade: CERTPIC canal não assina como CERTPIA e inverso; não usar no SPB/MES. QR site usa EV/domínio sem wildcard/autenticação servidor e exclusivo canal Pix; certificado JWS é exclusivo assinatura QR/Pix e está no JWK, sem ativação própria no Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 31Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32
• Arquivo CERTQRC ARQ tem no máximo um download por vinte e quatro horas e cache nesse período; consulta de modificação pode evitar novo download. Pagador verifica revogação que pode ocorrer entre atualizações. Certificados novos ativados são distribuídos aos softwares em até sete dias; recebedor esperar sete dias após cadastro no BC para implementar novo certificado no site de QR é recomendação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34
• Certificado desativa automaticamente vinte e quatro horas antes de expirar. Pedido exige BC Correio e posterior contato à Central, com dados e modalidade; prazo conta do contato posterior. Programada ocorre em até dois dias úteis do rito integral, ou data posterior indicada. Incidente é regime contínuo só para comprometimento por ataque/exposição privada; homologação sempre programada. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37
• Revogação BC comprovada exige rejeitar e avisar DEINF; se status BC não verificável por falha, avisar e aceitar temporariamente enquanto não resolvido. QR de outro participante, ao contrário, é rejeitado se revogado ou impossível verificar. Consulta assíncrona frequente de revogação é recomendada; exceção BC não libera QR sem verificação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 38
• Sistemas Pix devem prevenir riscos descritos OWASP e proteger dados. Criptografia/autenticação forte cliente e proteção contra adulteração são obrigatórias; segurança majoritariamente no servidor. mTLS é exemplo nesse recorte de sistemas do participante, distinto da autenticação mútua obrigatória com APIs Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 39Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11
• App recebe só dados necessários. Consulta chave/QR não expõe CPF completo, conta/agência ou dados de segurança de chaves; exceção de dados bancários é inserção manual nos ambientes Pix/Open Finance. Base interna usa Token Bucket igual ou mais restritivo que DICT e limita requisições por software. Site de consultas/transações exige usuário logado e proteção contra robôs; mecanismos listados são possibilidades. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40
• Dados de auditoria têm entradas UTC e, solicitados, são fornecidos descriptografados no formato BC. Retenção ICOM: dez anos de XML completo, PI-ResourceId quando existente e incidentes/fraudes. DICT: consulta dois anos, escrita/sincronismo/MED dez e incidentes dez. APIs próprias: consulta chave e transações dois anos; incidentes/varredura/fraudes dez. Cabeçalhos mínimos quando existentes são obrigatórios, completos recomendados. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 42Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 43
• Certificados inclusive desativados e chaves públicas ficam para validação histórica; armazenamento histórico de privadas é expressamente vedado. Privadas permanecem apenas nos ambientes seguros/restritos para assinatura/decifragem. BC pode alterar prazos de retenção a qualquer tempo; recomendação de criptografar logs não elimina dever de fornecimento legível. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30

O que esta leitura não diz. Não há garantia absoluta contra fraude, layout integral ou permissão de concluir transação com assinatura QR inválida.

HTTP/TLS, IPs, XMLDSig, JWS e certificados têm requisitos distintos. Certificados são separados por finalidade, QR valida antes de processar e auditoria preserva integridade sem privadas no histórico.

• Volume II 6.00 trata segurança Pix; Volume I também se aplica com exceções específicas de habilitação/ativação e mensageria. Requisitos abrangem SPI, DICT, QR, sistemas e auditoria, sem eleger fornecedor único. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 6Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 7Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 8Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 10
• Comunicação RSFN usa HTTP 1.1, TLS 1.2 ou superior, autenticação mútua e suite mínima indicada; cliente respeita TTL DNS. IP ICOM deve ser previamente autorizado no módulo SPI SPB-Web em homologação/produção; gestão formal inclui revisão/registro, com IPs efetivos ou de contingência, não toda faixa. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 12
• Mensagens SPI são assinadas pelo direto emissor; DICT só consulta GET dispensa assinatura de requisição, e respostas BC são assinadas. XMLDSig usa RSA-SHA256/SHA-256 e canonicalização exclusiva. SPI assina Document, AppHdr e KeyInfo; DICT raiz e KeyInfo, com referências diferentes. Verificação compara digests e assinatura, retornando erro se falha. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 13Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 14Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 15Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 16Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 19Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 21Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 23
• QR dinâmico do recebedor usa URL HTTPS/TLS e JWS assinado; PSP responde pela segurança/disponibilidade mesmo com prestador contratado. CAA DNS é recomendação adicional. URL sem protocolo tem máximo setenta e sete caracteres; token mínimo cento e vinte bits aleatórios e não dedutível; UUID se escolhido deve ser versão quatro com aleatoriedade real. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 25Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 26
• JWS proíbe HS* e none, admite RS256/ES256 ou superiores e recomenda PS256/PS512. Cabeçalho e JWK Set identificam chave/certificado; assinatura, cadeia, domínio e cadastro do site são validados antes de processar payload. Aplicativo produção rejeita host de homologação com sufixo -h. Otimizar verificação não pode reduzir segurança. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 27Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 28Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 29
• Histórico de QR inclui JWS, certificados e chaves públicas, sem guardar chave privada para esse fim. Aproximação com pagador online exige senha/biometria de acesso, tela de confirmação após aproximação e todos requisitos de segurança QR. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30
• Certificados ICP-Brasil padrão SPB de participante direto são exclusivos Pix e separados por finalidade: CERTPIC canal não assina como CERTPIA e inverso; não usar no SPB/MES. QR site usa EV/domínio sem wildcard/autenticação servidor e exclusivo canal Pix; certificado JWS é exclusivo assinatura QR/Pix e está no JWK, sem ativação própria no Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 31Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32
• Ativação envia PEM ao STA do ambiente correto, sem cadeia e sem chave privada, nos códigos CPIC/CPIA/CQRC. BC tem sete dias para ativar; envio antecipado e comercial é recomendado. Acesso SCERTQRC só autorizados e revisado anualmente. Para site QR, validação completa é do participante e aviso de recebido difere de aceito/ativado do canal/assinatura. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 33
• Arquivo CERTQRC ARQ tem no máximo um download por vinte e quatro horas e cache nesse período; consulta de modificação pode evitar novo download. Pagador verifica revogação que pode ocorrer entre atualizações. Certificados novos ativados são distribuídos aos softwares em até sete dias; recebedor esperar sete dias após cadastro no BC para implementar novo certificado no site de QR é recomendação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34
• Gestão de certificados e proteção de chaves privadas é obrigatória; HSM é recomendado, sem impor produto único. Múltiplos certificados ativos podem coexistir. BC comunica novos com mínimo sete dias e pode ativar gradualmente; participante deve aceitar mais de um válido. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 35Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36
• Certificado desativa automaticamente vinte e quatro horas antes de expirar. Pedido exige BC Correio e posterior contato à Central, com dados e modalidade; prazo conta do contato posterior. Programada ocorre em até dois dias úteis do rito integral, ou data posterior indicada. Incidente é regime contínuo só para comprometimento por ataque/exposição privada; homologação sempre programada. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37
• Revogação BC comprovada exige rejeitar e avisar DEINF; se status BC não verificável por falha, avisar e aceitar temporariamente enquanto não resolvido. QR de outro participante, ao contrário, é rejeitado se revogado ou impossível verificar. Consulta assíncrona frequente de revogação é recomendada; exceção BC não libera QR sem verificação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 38
• Sistemas Pix devem prevenir riscos descritos OWASP e proteger dados. Criptografia/autenticação forte cliente e proteção contra adulteração são obrigatórias; segurança majoritariamente no servidor. mTLS é exemplo nesse recorte de sistemas do participante, distinto da autenticação mútua obrigatória com APIs Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 39Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11
• App recebe só dados necessários. Consulta chave/QR não expõe CPF completo, conta/agência ou dados de segurança de chaves; exceção de dados bancários é inserção manual nos ambientes Pix/Open Finance. Base interna usa Token Bucket igual ou mais restritivo que DICT e limita requisições por software. Site de consultas/transações exige usuário logado e proteção contra robôs; mecanismos listados são possibilidades. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40
• Dados de auditoria têm entradas UTC e, solicitados, são fornecidos descriptografados no formato BC. Retenção ICOM: dez anos de XML completo, PI-ResourceId quando existente e incidentes/fraudes. DICT: consulta dois anos, escrita/sincronismo/MED dez e incidentes dez. APIs próprias: consulta chave e transações dois anos; incidentes/varredura/fraudes dez. Cabeçalhos mínimos quando existentes são obrigatórios, completos recomendados. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 42Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 43
• Certificados inclusive desativados e chaves públicas ficam para validação histórica; armazenamento histórico de privadas é expressamente vedado. Privadas permanecem apenas nos ambientes seguros/restritos para assinatura/decifragem. BC pode alterar prazos de retenção a qualquer tempo; recomendação de criptografar logs não elimina dever de fornecimento legível. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30

O que esta leitura não diz. Não há implementação completa, endpoint de toda função ou equivalência de exceção de revogação BC ao QR de outro participante.

Aproximação apresenta confirmação após aproximar, com autenticação de acesso. Chaves/QR têm dados que não chegam ao cliente, com exceção de dados bancários em inserção manual.

• Volume II 6.00 trata segurança Pix; Volume I também se aplica com exceções específicas de habilitação/ativação e mensageria. Requisitos abrangem SPI, DICT, QR, sistemas e auditoria, sem eleger fornecedor único. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 6Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 7Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 8Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 10
• QR dinâmico do recebedor usa URL HTTPS/TLS e JWS assinado; PSP responde pela segurança/disponibilidade mesmo com prestador contratado. CAA DNS é recomendação adicional. URL sem protocolo tem máximo setenta e sete caracteres; token mínimo cento e vinte bits aleatórios e não dedutível; UUID se escolhido deve ser versão quatro com aleatoriedade real. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 25Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 26
• JWS proíbe HS* e none, admite RS256/ES256 ou superiores e recomenda PS256/PS512. Cabeçalho e JWK Set identificam chave/certificado; assinatura, cadeia, domínio e cadastro do site são validados antes de processar payload. Aplicativo produção rejeita host de homologação com sufixo -h. Otimizar verificação não pode reduzir segurança. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 27Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 28Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 29
• Histórico de QR inclui JWS, certificados e chaves públicas, sem guardar chave privada para esse fim. Aproximação com pagador online exige senha/biometria de acesso, tela de confirmação após aproximação e todos requisitos de segurança QR. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30
• Revogação BC comprovada exige rejeitar e avisar DEINF; se status BC não verificável por falha, avisar e aceitar temporariamente enquanto não resolvido. QR de outro participante, ao contrário, é rejeitado se revogado ou impossível verificar. Consulta assíncrona frequente de revogação é recomendada; exceção BC não libera QR sem verificação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 38
• Sistemas Pix devem prevenir riscos descritos OWASP e proteger dados. Criptografia/autenticação forte cliente e proteção contra adulteração são obrigatórias; segurança majoritariamente no servidor. mTLS é exemplo nesse recorte de sistemas do participante, distinto da autenticação mútua obrigatória com APIs Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 39Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11
• App recebe só dados necessários. Consulta chave/QR não expõe CPF completo, conta/agência ou dados de segurança de chaves; exceção de dados bancários é inserção manual nos ambientes Pix/Open Finance. Base interna usa Token Bucket igual ou mais restritivo que DICT e limita requisições por software. Site de consultas/transações exige usuário logado e proteção contra robôs; mecanismos listados são possibilidades. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40
• Dados de auditoria têm entradas UTC e, solicitados, são fornecidos descriptografados no formato BC. Retenção ICOM: dez anos de XML completo, PI-ResourceId quando existente e incidentes/fraudes. DICT: consulta dois anos, escrita/sincronismo/MED dez e incidentes dez. APIs próprias: consulta chave e transações dois anos; incidentes/varredura/fraudes dez. Cabeçalhos mínimos quando existentes são obrigatórios, completos recomendados. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 42Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 43
• Certificados inclusive desativados e chaves públicas ficam para validação histórica; armazenamento histórico de privadas é expressamente vedado. Privadas permanecem apenas nos ambientes seguros/restritos para assinatura/decifragem. BC pode alterar prazos de retenção a qualquer tempo; recomendação de criptografar logs não elimina dever de fornecimento legível. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30

O que esta leitura não diz. Não há texto literal ou liberdade para expor dados internos porque podem ser mascarados apenas na tela.

Envio/ativação, desativação programada e incidente têm ritos e gatilhos próprios. Expiração, revogação e impossibilidade de verificar são casos diferentes; retenção depende do dado.

• Volume II 6.00 trata segurança Pix; Volume I também se aplica com exceções específicas de habilitação/ativação e mensageria. Requisitos abrangem SPI, DICT, QR, sistemas e auditoria, sem eleger fornecedor único. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 6Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 7Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 8Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 10
• Comunicação RSFN usa HTTP 1.1, TLS 1.2 ou superior, autenticação mútua e suite mínima indicada; cliente respeita TTL DNS. IP ICOM deve ser previamente autorizado no módulo SPI SPB-Web em homologação/produção; gestão formal inclui revisão/registro, com IPs efetivos ou de contingência, não toda faixa. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 12
• Mensagens SPI são assinadas pelo direto emissor; DICT só consulta GET dispensa assinatura de requisição, e respostas BC são assinadas. XMLDSig usa RSA-SHA256/SHA-256 e canonicalização exclusiva. SPI assina Document, AppHdr e KeyInfo; DICT raiz e KeyInfo, com referências diferentes. Verificação compara digests e assinatura, retornando erro se falha. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 13Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 14Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 15Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 16Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 19Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 21Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 23
• QR dinâmico do recebedor usa URL HTTPS/TLS e JWS assinado; PSP responde pela segurança/disponibilidade mesmo com prestador contratado. CAA DNS é recomendação adicional. URL sem protocolo tem máximo setenta e sete caracteres; token mínimo cento e vinte bits aleatórios e não dedutível; UUID se escolhido deve ser versão quatro com aleatoriedade real. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 25Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 26
• JWS proíbe HS* e none, admite RS256/ES256 ou superiores e recomenda PS256/PS512. Cabeçalho e JWK Set identificam chave/certificado; assinatura, cadeia, domínio e cadastro do site são validados antes de processar payload. Aplicativo produção rejeita host de homologação com sufixo -h. Otimizar verificação não pode reduzir segurança. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 27Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 28Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 29
• Histórico de QR inclui JWS, certificados e chaves públicas, sem guardar chave privada para esse fim. Aproximação com pagador online exige senha/biometria de acesso, tela de confirmação após aproximação e todos requisitos de segurança QR. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30
• Certificados ICP-Brasil padrão SPB de participante direto são exclusivos Pix e separados por finalidade: CERTPIC canal não assina como CERTPIA e inverso; não usar no SPB/MES. QR site usa EV/domínio sem wildcard/autenticação servidor e exclusivo canal Pix; certificado JWS é exclusivo assinatura QR/Pix e está no JWK, sem ativação própria no Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 31Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32
• Ativação envia PEM ao STA do ambiente correto, sem cadeia e sem chave privada, nos códigos CPIC/CPIA/CQRC. BC tem sete dias para ativar; envio antecipado e comercial é recomendado. Acesso SCERTQRC só autorizados e revisado anualmente. Para site QR, validação completa é do participante e aviso de recebido difere de aceito/ativado do canal/assinatura. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 32Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 33
• Arquivo CERTQRC ARQ tem no máximo um download por vinte e quatro horas e cache nesse período; consulta de modificação pode evitar novo download. Pagador verifica revogação que pode ocorrer entre atualizações. Certificados novos ativados são distribuídos aos softwares em até sete dias; recebedor esperar sete dias após cadastro no BC para implementar novo certificado no site de QR é recomendação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34
• Gestão de certificados e proteção de chaves privadas é obrigatória; HSM é recomendado, sem impor produto único. Múltiplos certificados ativos podem coexistir. BC comunica novos com mínimo sete dias e pode ativar gradualmente; participante deve aceitar mais de um válido. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 34Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 35Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36
• Certificado desativa automaticamente vinte e quatro horas antes de expirar. Pedido exige BC Correio e posterior contato à Central, com dados e modalidade; prazo conta do contato posterior. Programada ocorre em até dois dias úteis do rito integral, ou data posterior indicada. Incidente é regime contínuo só para comprometimento por ataque/exposição privada; homologação sempre programada. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 36Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37
• Revogação BC comprovada exige rejeitar e avisar DEINF; se status BC não verificável por falha, avisar e aceitar temporariamente enquanto não resolvido. QR de outro participante, ao contrário, é rejeitado se revogado ou impossível verificar. Consulta assíncrona frequente de revogação é recomendada; exceção BC não libera QR sem verificação. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 37Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 38
• Sistemas Pix devem prevenir riscos descritos OWASP e proteger dados. Criptografia/autenticação forte cliente e proteção contra adulteração são obrigatórias; segurança majoritariamente no servidor. mTLS é exemplo nesse recorte de sistemas do participante, distinto da autenticação mútua obrigatória com APIs Pix. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 39Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 11
• App recebe só dados necessários. Consulta chave/QR não expõe CPF completo, conta/agência ou dados de segurança de chaves; exceção de dados bancários é inserção manual nos ambientes Pix/Open Finance. Base interna usa Token Bucket igual ou mais restritivo que DICT e limita requisições por software. Site de consultas/transações exige usuário logado e proteção contra robôs; mecanismos listados são possibilidades. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 40
• Dados de auditoria têm entradas UTC e, solicitados, são fornecidos descriptografados no formato BC. Retenção ICOM: dez anos de XML completo, PI-ResourceId quando existente e incidentes/fraudes. DICT: consulta dois anos, escrita/sincronismo/MED dez e incidentes dez. APIs próprias: consulta chave e transações dois anos; incidentes/varredura/fraudes dez. Cabeçalhos mínimos quando existentes são obrigatórios, completos recomendados. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 42Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 43
• Certificados inclusive desativados e chaves públicas ficam para validação histórica; armazenamento histórico de privadas é expressamente vedado. Privadas permanecem apenas nos ambientes seguros/restritos para assinatura/decifragem. BC pode alterar prazos de retenção a qualquer tempo; recomendação de criptografar logs não elimina dever de fornecimento legível. Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 41Manual de Segurança do SFN — Volume II (Segurança do Pix) 6.00, p. 30

O que esta leitura não diz. Não há SLA interno, canal BC Correio disponível sempre ou obrigação de arquivar chave privada como evidência.