Requisitos de segurança

A segurança é um aspecto crítico no design e na implementação de APIs, assegurando que apenas usuários autorizados tenham acesso aos recursos e que as informações sejam transmitidas e armazenadas de forma segura.

Os requisitos têm como objetivo fortalecer a segurança no acesso à plataforma Paytime, buscando mitigar os riscos de ataques cibernéticos. Para isso, é exigida a implementação de controles mínimos de segurança, independentemente da tecnologia utilizada pelo parceiro (Web, Mobile ou Aplicativo). O cliente é responsável pela implementação dos seguintes requisitos mínimos em sua plataforma:

Transporte

Todas as comunicações entre o cliente o a plataforma devem ocorrer por HTTPS usando a versão a partir do TLS 1.2.
Todas as interfaces acessíveis ao público na internet, devem usar um Certificado Digital que tenha sido assinado por uma autoridade de certificação aprovada e legítima.
Sempre que possível, utilize soluções para controlar o acesso da rede como Firewall e WAF (Web Application Firewall).
Implemente o cabeçalho de resposta HTTP X-XSS-Protection, sempre que possível implemente a opção 1; mode=block
Sempre que possível, habilite o header STS Strict-Transport-Securty para garantir que o navegador não converse com o servidor usando protocolo HTTP e sim apenas HTTPS.
Os cabeçalhos CORS devem ser usados, pois reduzem os mecanismos gerais de segurança integrados aos navegadores da web, relaxando seletivamente as restrições de origem cruzada.

Autenticação e autorização

As chaves de API fornecidas pela Paytime devem ser utilizadas para autenticar o cliente, sendo seu uso permitido apenas quando o TLS estiver habilitado.

Essas chaves não devem ser incluídas no URL ou em strings de consulta. Elas devem ser inseridas no cabeçalho HTTP, uma vez que strings de consulta podem ser armazenadas em formato não criptografado pelo cliente ou servidor, além de poderem ser indexadas na internet, expondo sua chave.

Evite utilizar URLs curinga nos cabeçalhos de resposta (por exemplo, 'Access-Control-Allow-Origin: *'), a menos que o recurso REST seja totalmente público e não requeira autorização significativa.

Manipulação de erros

A API deve ocultar qualquer erro relacionado ao sistema, retornando apenas códigos de status HTTP padrão e mensagens de erro genéricas. Não exponha informações internas do sistema nas respostas de erro.

Além disso, a API não deve fornecer detalhes técnicos, como pilhas de chamadas ou outras informações internas, ao cliente.

Proteção de dados e criptografia

Aplique criptografia em todos os dados sensíveis ou críticos antes de armazená-los.

Utilize algoritmos complexos de criptografia, como por exemplo:
RSA: Um algoritmo assimétrico altamente seguro porem lento. Este possui 2 chaves para o processo de criptografia (1 publica e 1 privada).
AES-256: Um algoritmo simétrico seguro e rápido . Este possui 1 chave para o processo de criptografia, ou seja, realiza a criptografia e descriptografia com a mesma chave.

Em ultimo caso, quando não disponibilizar de mecanismos ou recursos para uso da criptografia, utilize proteção por HASH, dando preferência para os mais fortes: Ex.: SHA-256 ou SHA-512 ou SHA-3.

Gestão de acessos

A aplicação deve conter perfis para controlar tipos de acessos diferenciados.

Os acessos devem ser gerenciados a partir de grupos de usuários que desempenham as mesmas funções e/ou permissões específicas, assim sua gestão serão mais eficaz e eficiente.

Evite usar usuários genéricos para acesso administrativo como por exemplo root ou administrador.

Em caso de acesso administrativo sempre implemente um sistema de segunda autenticação (MFA).

Segunda autenticação MFA

Implemente uma segunda autenticação MFA (Autenticação Multifator), para mitigar acessos indevidos de credenciais vazadas, compartilhamento indevido de senha ou ataques cibernético.

Implemente MFA também em transações críticas para inibir falhas acidentais ou intencionais.

Controles de sessões

Defina um padrão de uso das sessões de login.

Tempo total para navegação até solicitar uma nova autenticação.

Outras medidas

Sempre que possível use um captcha na página pública e principal para evitar ataques automatizados.

Mesmo com a implementação completa dos Requisitos de Segurança descritos neste guia — que se referem exclusivamente aos critérios mínimos necessários para a operação — ainda podem existir riscos desconhecidos relacionados a tecnologias, processos e pessoas. Por isso, a Paytime não se responsabiliza por eventuais impactos ou resultados inesperados que possam ocorrer durante ou após a implementação desses Requisitos.