Sprint 05 (Edmar): Análise de vulnerabilidades.

[wesleycstr]

Analisar as possíveis vulnerabilidades do sistema.

Edmar, preciso que vc faça uma análise das possíveis falhas que possam acontecer e juntos vamos melhorar o projeto. O foco é evitar que de alguma forma o sistema deixe de exibir os dados ou não consiga enviar os alertas.

[edmarrn]

Tarefa 01: Análise de vulnerabilidades. O propósito desta tarefa é analisar problemas que venham a ocorrer e que possam resultar em falhas. Tais vulnerabilidades devem ser mitigadas para que o processo de monitoramento que estamos propondo funcione minimamente com confiabilidade. Desta forma, após análise das situações, discriminamos estes pontos como sendo os mais relevantes e as possíveis soluções para serem implementadas:

• A interface gráfica está acessível para qualquer usuário que acessar a rede Consequência: Qualquer pessoa estando conectada na mesma rede poderá acessar a página da ferramenta digitando o endereço em um navegador. Pessoas com acesso indevido poderão alterar parâmetros e gerar alertas falsos.

[edmarrn]

Solução: Criar página de login para limitar uso dos recursos. com utilização de autenticação em 2 etapas e definir o nível de permissões de acordo com o tipo de usuários. Ter uma restrição de acesso por IP. ou seja um ACL, poderemos usar uma criptografia.

[wesleycstr]

Solução: Criar página de login para limitar uso dos recursos. com utilização de autenticação em 2 etapas e definir o nível de permissões de acordo com o tipo de usuários. Ter uma restrição de acesso por IP. ou seja um ACL, poderemos usar uma criptografia.

Feito!

[edmarrn]

De acordo que foi pesquisado, foi observado que para o sistema continue funcionando corretamente, mesmo após uma queda da rede, pode se modificar o código hospedado na placa Wemos, para verificar se continuamente a conexão da rede. Se a conexão for perdida, o dispositivo deve se conectar automaticamente.

[edmarrn]

Aí, podemos criar uma estratégia para a reconexão automática, que são a verificação continua de conexão, rotina de reconexão, configuração de timeout, logs e feedbacks.

[edmarrn]

Alguns pontos que podemos melhorar são: Vulnerabilidade o código tentar se conectar apenas 1 vez, na inicialização, se a conexão wi-fi for perdida depois disso, o dispositivo não fará uma nova tentativa, Solução sugerida é uma criação de loop para verificar se o dispositivo ainda está conectado ao wi-fi:

[edmarrn]

Aqui temos a imagem do código que pode ser melhorado.

[edmarrn]

Para garantir que os operadores e administradores possam acompanhar o funcionamento do sistema e identificar rapidamente qualquer problema, é essencial implementar um sistema de registro de logs eficiente.

[edmarrn]

Solução: Criar tabela no banco de dados que seja alimentada com informações de log a cada execução de script. Gerar uma visualização na página web para que os usuários possam acompanhar as mensagens que estão sendo geradas.

[edmarrn]

Não há confirmação do usuário de recebimento de alerta via telefone Consequência: Quando não há confirmação de recebimento de alerta pelo usuário o sistema fica insistentemente gerando chamadas até mesmo nos casos que o destinatário recebeu a ligação.

[wesleycstr]

Adicionei dentro do loop uma verificação de conexão e reconexão caso necessário.

[wesleycstr]

Adicionei uma visualização de tentativa de reconexão pelo ped. Ele apenas estava ficando apagado:

[wesleycstr]

Solução: Criar tabela no banco de dados que seja alimentada com informações de log a cada execução de script. Gerar uma visualização na página web para que os usuários possam acompanhar as mensagens que estão sendo geradas.

Criado um script que armazena os dados de logs

Criada uma página para visualização:

[edmarrn]

As atualizações foram medidas bem assertivas, essas atualizações deixará o sistema mais seguro.

[wesleycstr]

Obrigado Edmar! Issue fechada.