Back to legal centerPolitica de Seguranca
Legal document

Politica de Seguranca

Padroes tecnicos e organizacionais para proteger dados, transacoes e a integridade da plataforma.

Version 1.0 04 de outubro de 2026

1.Principios Gerais

1.1. A seguranca da informacao e pilar fundamental da SymbolPay. Aplicamos o principio da minima privacidade por design, coletando e expondo apenas o necessario para cada operacao.

1.2. Toda arquitetura segue o modelo de defesa em profundidade, com camadas de protecao em rede, aplicacao e dados.

2.Criptografia e Transporte

2.1. Toda comunicacao entre cliente e plataforma ocorre sobre HTTPS/TLS com versoes modernas e cifras seguras.

2.2. Dados sensiveis, como chaves de API e segredos de webhook, sao armazenados de forma criptografada (hash SHA-256), nunca em texto plano.

2.3. Senhas de usuario nunca sao armazenadas em texto plano, utilizando algoritmos de hash com sal.

3.Controle de Acesso

3.1. O acesso a dados e funcionalidades segue o principio do menor privilegio (RBAC), com segregacao entre comerciantes e administradores.

3.2. Row-Level Security (RLS) garante que cada comerciante acessa apenas seus proprios registros de cobrancas, saques e configuracoes.

3.3. Operacoes administrativas sensiveis (ajuste de saldo, aprovacao de contas) sao auditadas e registradas em log imutavel.

4.Seguranca de API e Webhooks

4.1. Chaves de API sao geradas com entropia criptografica segura e armazenadas apenas como hash. A chave completa e exibida uma unica vez no momento da criacao.

4.2. Webhooks utilizam assinatura HMAC-SHA256 para autenticar a origem dos eventos recebidos pela plataforma.

4.3. URLs de webhook sao validadas para prevenir SSRF (Server-Side Request Forgery), exigindo HTTPS e bloqueando hosts internos.

5.Prevencao a Abusos

5.1. O checkout publico possui rate limiting e limite de cobrancas pendentes por link para prevenir esgotamento de cota por spam.

5.2. Ajustes de saldo sao protegidos contra race conditions por meio de transacoes atomicas.

5.3. Erros de backend nao expõem stack traces ou detalhes de arquitetura ao cliente.

6.Resposta a Incidentes

6.1. Incidentes de seguranca sao tratados conforme plano de resposta, com priorizacao por impacto e comunicacao aos afetados quando aplicavel.

6.2. Suspeitas de vulnerabilidade podem ser reportadas pelo canal de suporte e serao analisadas pela equipe de seguranca.

This site uses cookies

We use essential cookies for the site to function and analytics cookies to improve your experience. You can accept all, reject optional ones, or manage your preferences. Learn more in our Cookie Policy