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:
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.
As chaves API fornecidas pela Paylogos, 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.
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
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.
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.
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.
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.
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).
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.
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.
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.
📘 NotaMesmo 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.
