Requisitos de segurança

Os requisitos vem com o propósito de melhorar a segurança com acesso à API Legacy Bank 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 e a plataforma devem ocorrer pelo protocolo de internet HTTPS.
  • 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 (White List) 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-Security) 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 web, relaxando seletivamente as restrições de origem cruzada.

Backend

As chaves API fornecidas pela Legacy Bank, 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 coringa () 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.

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)

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 contra 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.