Requisitos de segurança

Os requisitos vem com o propósito de melhorar a segurança com acesso à plataforma Zoop visando mitigar os riscos de ataques cibernéticos, exigindo a implementação de controles mínimos de segurança, independente da tecnologia utilizada pelo parceiro (Web, Mobile ou Application) tendo o cliente como responsável a 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 crie uma lista de permissões de IP’s (WhiteList) para limitar e controlar o acesso apenas de recursos autorizados.

• 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

Backend

As chaves API fornecidas pela Zoop, devem ser usadas para autenticação do cliente. O uso de chaves de API só deve ser permitido quando o TLS está habilitado.

As chaves API não devem ser incluídas no URL ou na string de consulta. As chaves API devem ser incluídas no cabeçalho HTTP, pois as strings de consulta podem ser salvas pelo cliente ou servidor em formato não criptografado pelo navegador ou aplicativo do servidor e serem indexadas pela internet expondo sua chave.

Nunca use URLs curinga () nos cabeçalhos de resposta (ou seja, Access-Control-Allow-Origin:), a menos que o recurso REST seja realmente público e exija pouca ou nenhuma autorização para uso.

Frontend - Web

• Deve ter uma política de senha contendo pelo menos 4 características:

Maiúsculas (A-Z)

Minúsculas (a-z)

Números (0-9)

Caracteres especiais (! @ # $ % ^ & * ( ) _ + - = [ ] { } | ')

• Impedir uso de senhas com sequência numéricas e letras de 3 sequências, Ex: 123, 789, abc, efg

• Obrigar o usuário a trocar a senha no período máximo a cada 180 dias

• Bloquear o usuário na aplicação após 5 tentativas consecutivas de senhas inválidas

• Manter histórico das últimas 5 senhas impedindo sua reutilização

• Bloquear a visualização da senha durante sua inserção na tela

• As senhas devem ser armazenadas em local seguro criptografado

• Senhas de usuários de serviço/aplicação devem possuir no mínimo 12 (doze) caracteres

Frontend - Mobile:

• Senhas de usuários nominais devem possuir no mínimo 06 (seis) caracteres numéricos + MFA

• Obrigar o usuário a trocar a senha no período máximo a cada 180 dias

• Manter histórico das últimas 5 senhas impedindo sua reutilização

• Bloquear a visualização da senha durante sua inserção na tela

• As senhas devem ser armazenadas em local seguro criptografado

• Nunca permita que as credenciais sejam armazenadas diretamente no código do aplicativo.

Manipulação de erros

• A API deve mascarar quaisquer erros relacionados ao sistema por trás de respostas de status HTTP padrão e mensagens de erro, por exemplo, não exponha informações de nível de sistema em sua resposta de erro.

• A API não deve passar detalhes técnicos (por exemplo, pilhas de chamadas ou outras dicas internas) para o cliente.

Registro de logs

Um aspecto importante da segurança é ser notificado quando algo de errado ocorrer e assim poder investigá-lo. é recomendado definir o nível certo de registros e definir os alertas certos para auditoria.

• Grave registros de auditoria de modo seguro antes e depois dos eventos relacionados à segurança que podem acionar os alertas.

• Exibir uma mensagem genérica em todos os casos de falha de autenticação. A mensagem deve informar apenas que: “ocorreu um erro / falha na tentativa de login”. Ou apenas informe “senha e / ou usuário inválido”.

• Registre qualquer autenticação e atividades de gerenciamento . Quaisquer eventos relacionados à segurança devem ser registrados.

• Quaisquer atividades ou ocasiões em que o nível de privilégio de determinado usuário muda deve ser logado.

• Quaisquer atividades administrativas no aplicativo ou em qualquer de seus componentes, devem ser registradas.

• Qualquer acesso a dados confidenciais deve ser registrado.

• Os logs devem ser armazenados e mantidos de forma adequada para evitar perda de informações ou adulteração acidental ou intencional.

• Retenção de log deve também seguir a política de retenção estabelecida pela organização do cliente para atender os requisitos mínimos aqui apresentados e fornecer informações suficientes para o forense e atividades de resposta a incidentes.

• Se possível, tenha um centralizador de logs para melhor gerenciamento e com funcionalidades para correlacionar diferentes logs. Exemplo: SIEM.

• Exemplos de dados que podem ser armazenado, mas não está limitado em:
  A ação. Ex.: transação, Data e hora, ID de usuário ou conta na plataforma, Endereço IP, Geolocalização e Dados do dispositivo.

📘

Nota

Conforme disposto no artigo 6° da Lei Geral de Proteção de Dados (LGPD) n.13.709/2018 , devem ser seguidos e respeitados os 10 princípios de tratamento do dado pessoal, durante todo o ciclo de vida.

http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm

Validação de entrada

A validação de entrada é realizada para garantir que apenas dados devidamente formados e esperados sejam recebidos pelo seu sistema, o que ajuda a prevenir ataques maliciosos:

• A validação de entrada deve acontecer o mais cedo possível, de preferência assim que os dados forem recebidos da parte externa.

• Defina um limite de tamanho de solicitação apropriado e rejeite solicitações que excedam o limite.

• Valide a entrada: por exemplo, comprimento / intervalo / formato e tipo.

• Considere registrar falhas de validação de entrada.

• Restrinja entradas de string com expressão regular.

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

Conceito de “menor privilégio” deve ser aplicado para qualquer modelo de acesso, ou seja, qualquer acesso deve ser concedido apenas no nível necessário para desenvolvimento das atividades.

Conceito de “necessidade de saber” deve ser aplicado para qualquer liberação de acesso, ou seja, o acesso deve ser concedido apenas se realmente existir necessidade dele para desenvolvimento das atividades.

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.

• Se possível, de preferência em utilizar um mecanismo de MFA na seguinte ordem de efetividade: via Mobile Authenticator (TOTP), e-mail ou SMS.

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

• Se possível, implemente Autenticação adaptativa de segundo fator.

  O sistema analisará o comportamento dos usuários para detectar atividades suspeitas e caso as identifiquem, solicitará uma segunda autenticação para prosseguir com as atividades.

Controles de sessões

• Defina um padrão de uso das sessões de log-in

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

• A aplicação deve encerrar a sessão inativa após o período de 5 minutos de ociosidade.

• Não permita conexões simultâneas ativas com mesmo usuário em sessões diferentes.

  Observando que o usuário não pode estar conectado em computadores diferentes com a mesma credencial.

Outras contras medidas:

Sempre que possível use um Captcha na página publica e principal para evitar ataques automatizados.

Cookies:

Implemente em cookies permanentes os atributos, data (Expires) ou depois de um período específico de tempo (Max-Age).

Configure os atributos Secure e HttpOnly para garantir quer as informações trafeguem por protocolos seguros e não sejam consumidas por scripts (JavaScript) não legítimos ao fluxo entre cliente-servidor.

📘

Nota

Mesmo com a implementação total dos Requerimentos de Segurança descritos neste guia (os quais se relacionam única e exclusivamente a critérios mínimos para a operação), ainda existem riscos desconhecidos particulares as tecnologias, processos e pessoas a serem explorados. Dessa forma, a Zoop não se responsabiliza por impactos ou resultados não esperados durante ou após a implementação dos Requerimentos.