Segurança

Limites claros, por escrito.

Segurança em um sistema de pagamentos é, em grande parte, dizer com precisão o que o sistema faz e o que não faz — e garantir isso no código. Esta página descreve os limites em torno dos quais o GRYPHEM PAY é construído.

Modelo de custódia

Os pagamentos reais são custodiais: os clientes pagam às carteiras da plataforma pela conta Bitcart do GRYPHEM PAY, e o saldo de cada lojista é mantido em um registro contábil append-only.
Os pagamentos reais são ativados quando a conta é verificada e aprovada; até lá, nenhum fundo é guardado para ela.
Os saques vão apenas para endereços previamente cadastrados na lista de permissões, após um período de carência. Por padrão, um segundo membro da equipe aprova cada um, um operador do GRYPHEM sempre o revisa e o Bitcart o envia a partir das carteiras quentes da plataforma.
Nenhuma chave privada ou frase-semente nos bancos de dados, logs, dados de exemplo, capturas de tela ou CI do GRYPHEM PAY. As chaves das carteiras da plataforma ficam na conta Bitcart da plataforma, que assina os saques.
Chaves públicas estendidas e descritores de carteira nunca são retornados pela API pública.

Chaves e segredos

As chaves de API são exibidas uma única vez, armazenadas como hashes HMAC com um pepper no servidor, têm escopo por ambiente e podem ser revogadas.
Os segredos de assinatura de webhooks e as sementes de MFA são criptografados em repouso (AES-GCM) e nunca gravados em logs.
Cabeçalhos Authorization, segredos e dados pessoais completos são excluídos dos logs por design.

Isolamento entre clientes

O tenant é sempre resolvido a partir do principal autenticado, nunca do corpo da requisição.
Defesa em profundidade: consultas restritas ao tenant, restrições no banco de dados e políticas de segurança em nível de linha.
Testes de acesso entre tenants cobrem todos os objetos de lojista.

Entrega de webhooks

Assinaturas HMAC-SHA256 sobre o timestamp e o corpo bruto, com uma janela limitada contra replay.
Proteção contra SSRF no momento da conexão: verificações de DNS e IP, sem faixas privadas, link-local ou de metadados, sem redirecionamentos.
Timeouts e tamanhos de payload limitados; cada tentativa é registrada sem segredos.

Acesso de operadores

Os operadores usam um sistema de identidade separado, com autenticação multifator obrigatória.
Ações de alto impacto, como decisões de KYB, resoluções manuais, feature flags e o modo live, exigem a aprovação de um segundo operador (quatro olhos) e deixam evidência de auditoria imutável.
Nenhum operador pode marcar um pagamento externo como confirmado sem evidência documentada e aprovação dupla.

Requisitos de liberação

A movimentação de fundos em produção e as redes reais ficam desligadas por padrão.
Ativá-las exige que cada requisito de liberação seja aprovado por dois operadores: revisão de segurança independente, aprovação do modelo de ameaças, runbooks de incidentes, exercícios de recuperação de desastres e aprovação jurídica.
Como o modo live é custodial, um dos requisitos jurídicos exige autorização para custodiar e transferir criptoativos de clientes em cada país de lançamento e entidade jurídica, ou um parecer escrito da assessoria jurídica de que nenhuma é necessária.
Contratos usados on-chain, se houver, exigem uma auditoria separada antes do uso na mainnet.

Honestidade

O que não alegamos.

Relatos

Encontrou algo? Conte para nós.

Relate vulnerabilidades pelo formulário de contato com o assunto “Relato de segurança”. Descreva o impacto; responderemos com um canal seguro antes que você compartilhe detalhes de exploração. Não faça testes com dados de outros lojistas.

Relatar um problema Status do sistema