-
Notifications
You must be signed in to change notification settings - Fork 0
C. Sugestões de segurança e performance
- Vocês identificaram os recursos confidenciais contidos no sistema?
R: No momento, a aplicação ainda não possui nenhum tipo de login para que cada usuário possua uma senha de acesso. O grupo pretende realizar isso ainda na parte do backend que está incompleto, mas não sabe se conseguirá usar a autenticação jwt pra gerar um token no server side.
Sugestão: Finalizar o backend pelo menos com a arquitetura BASIC para possuir um tipo de login, caso não consiga finalizar a implementação da autenticação jwt.
- Vocês identificaram os conjuntos de entidades (principais) que precisam ter acesso a esses recursos?
R: Sim, o grupo identificou que apenas a entidade usuário possuirá acesso a esse recurso por meio da sua senha de acesso que será implementada.
Sugestão: No caso da aplicação do grupo, como existe o usuário principal que será o paciente, não vejo a necessidade de outras entidades precisarem de acesso a esse recurso. Sem sugestões.
- Vocês identificaram as necessidades do sistema para garantias de integridade da informação?**
R: Sim, cada usuário tem sua conta, por meio disso ele não conseguirá ter acesso a nenhuma informação além da sua própria conta.
Sugestão: adicionar jwt para gerar token de autenticação e garantir maior integridade.
- Vocês identificaram as necessidades de disponibilidade do sistema?**
R: Não foi discutido especificamente, mas foi pensado para funcionar plenamente durante horário comercial (8h – 20h) devido ao o que aplicativo deve entregar.
Sugestão: Fazer o sistema funcionar 24h por dia, pois como é uma aplicação que de certa promete entregar ao usuário funcionalidades como checar agendamentos,, não faz sentido funcionar somente em horários definidos do dia.
- Existe uma política de segurança, incluindo controle de acesso e necessidades de integridade da informação?**
R: Login, porém ainda sem funcionamento completo
Sugestão: Incluir autenticação jwt para proteger a senha do usuário de acesso ao sistema e privar as rotas necessárias.
- A política de segurança é o mais simples possível? Dá para simplificar?**
R: Sim, pois o aplicativo possui a política de segurança mais simples que existe, no caso o login. Não daria, por já utilizar somente o login sem nenhum tipo de autenticação como jwt ou Passport.js.
Sugestão: Para a simplificação, o login propriamente dito, apesar de mais simples não é a tecnologia mais segura para se utilizar. Poderiam ter utilizado o Passport.js, que é bastante utilizado para criar o sistema de segurança do projeto e possui um fácil uso.
- Vocês trabalharam com um modelo de ameaça formal para identificar os riscos de segurança? Ou apenas decidiram as regras de segurança improvisadamente conforme foi desenvolvido o projeto?**
R: Não, o grupo foi decidindo as regras a partir que surgiram as necessidades durante o desenvolvimento do projeto.
Sugestão: O grupo poderia realizar um modelo de ameaças com o intuito de analisar possíveis ameaças para alguns recursos, como, acessar tarefas restritas e obter login de acesso
- Vocês revisaram seus requisitos de segurança com especialistas externos?**
R: Sim, o professor Diogo ensinou a equipe de PSW a utilizar autenticação jwt e com a equipe de arquitetura e padrões.
- Vocês abordaram cada ameaça identificada no modelo de ameaça da maneira necessária? (Caso tenha feito um modelo de ameaça)**
R: Não foi realizado nenhum tipo modelo de ameaça.
Sugestão: Não havia um modelo de ameaças. Os desenvolvedores da aplicação devem verificar esse modelo e implementar as políticas de segurança conforme as necessidades da aplicação
- Vocês usaram o máximo possível de tecnologias de segurança de terceiros, ou produziram os seus?
R: Por enquanto o grupo ainda não utilizou nenhum tipo de tecnologia, seja própria ou de terceiros, porém pretender implementar ainda a autenticação jwt.
Sugestão: Durante o desenvolvimento do back, os desenvolvedores devem tentar implementar ainda a autenticação jwt como foi ensinado ou até mesmo o Passport.js para garantir a segurança do usuário
- Vocês produziram um design geral integrado para a solução de segurança? (Todos os itens de segurança dentro do sistema estão trabalhando juntos? Ou são utilizados e configurados separadamente?)
R: Não, pois a aplicação ainda não possui funcionando plenamente o login, e ainda não implementou o jwt para o usuário ter acesso às rotas privadas.
Sugestão: Realizar ao menos se possível a implementação completa do login seguido de algum método de autenticação para garantir o acesso às rotas privadas
- Vocês consideraram todos os princípios de segurança padrão ao projetar a infraestrutura?
R: Não. Sugestão: Sugerimos implantar pelo menos os princípios de segurança mais reconhecidos, como: não conceder muitos níveis de acesso para o usuário; buscar o que há de mais fraco dentro do sistema de segurança para melhorá-lo, aplicar mecanismos de redundância no sistema, para contornar possíveis falhas em um dos próprios mecanismos, e entre outras táticas que podem ser pesquisadas.
- A sua infraestrutura de segurança é o mais simples possível?
R: Sim, pois aplicação funcionará apenas com um login simples a partir de um usuário e senha. Caso o grupo consiga implementar jwt, a resposta será não, pois o jwt assegura mais informações além de um simples login.
- Vocês definiram como identificar e se recuperar de violações de segurança?
R: Não.
Sugestão: A identificação de violações de segurança pode ser realizada a partir da autenticação de acesso dentro do sistema, caso seja implementada, podendo capturar quem e onde ocorreu o acesso indevido, e também providenciando administração da segurança. Para proteger os dados, poderá ser feito o sigilo e integridade da informação, como por exemplo, liberação de acesso apenas por meio de assinaturas digitais.
- Vocês aplicaram os resultados da perspectiva de segurança a todas as visualizações afetadas? (Planejaram alguma arquitetura para segurança e aplicaram todas elas?)
R: Não.
Sugestão: Como o software não possui nenhuma arquitetura de segurança, a sugestão seria incluir a autenticação jwt e se possível, aderir ao controle de acesso, para bloquear o acesso indevido de usuários que certamente não deveriam ter a autorização de fazer certas ações no sistema.
- Os especialistas externos revisaram seu projeto de segurança?
R: Sim. Os grupos de gerência e arquitetura realizaram testes na aplicação para revisar essas questões ao tentar realizar login.
- Vocês identificaram metas de desempenho, pelo menos em um nível alto, com as principais partes interessadas?
R: Não.
Sugestão: O software não tem uma meta de desempenho definida, então fica a sugestão de uma meta de pelo menos 3 segundos de latência já que de acordo com a pesquisa da Kissmetrics, 40% dos usuários abandonam o sistemas que levam mais de 3 segundos de espera.
- Vocês consideram algumas metas de tempo de resposta e vazão?
R: Não.
Sugestão: O grupo pode realizar a criação de metas de tempo de resposta e vazão. Como a latência mede o tempo necessário para uma mensagem ir a um destino e voltar, levando em consideração o fluxo de transações que o sistema sustentaria, uma meta de até 50 ms em no mínimo de 90% das mediações, poderia ser razoável para o sistema. E na vazão, o cálculo dependerá da quantidade de transações que foram feitas por segundos em um instante, mas ultrapassando cerca de 5 por segundo também poderia ser razoável para o sistema.
- Qual é a distinção entre o desempenho observado (resposta para o usuário, ou seja, as tarefas síncronas) e o desempenho real (levando em consideração a duração total do processamento, ou seja, as atividades assíncronas)?
R: No momento, o grupo ainda não finalizou o backend e não realizou a integração com o frontend, portanto não foi possível responder a essa pergunta.
Sugestão: Como o grupo ainda não realizou os passos citados, não podemos definir as melhorias para a aplicação, porém ficam algumas dicas como, implementar certas questões para poder melhorar ainda mais o desempenho, como a utilização de banco de dados em memória cache e um Redis para poder diminuir a quantidade de acessos. Além disso, caso o sistema venha a crescer, o banco de dados deverá ser carregado a um servidor.
- Vocês avaliaram suas metas de desempenho quanto à razoabilidade?
R: Não.
Sugestão: A sugestão é definir uma meta de desempenho baseada no tempo de resposta em milissegundos das requisições, e ir aplicando testes e ir melhorando o código até chegar a um desempenho agradável.
- Vocês definiram as expectativas das partes interessadas sobre o que é viável em sua arquitetura? (Pediram algum feedback sobre o desempenho da arquitetura feita no software?)
R: Sobre a arquitetura não, pois o grupo não foi questionado em relação à performance do sistema.
Sugestão: O grupo poderia realizar um estudo e questionar as partes interessadas o que seria viável e interessante em melhorar o desempenho da arquitetura do software.
- Vocês definiram metas de desempenho no contexto de uma carga específica no sistema?
R: Não foi decidido meta de desempenho.
Sugestão: É ideal a criação de metas para prever futuros problemas de desempenho no software. Pode ser feitos alguns testes de carga com software específicos para verificar essas metas.
- Vocês identificaram os principais problemas de desempenho em potencial em sua arquitetura?
R: Não especificamente, no caso da listagem de profissionais, o sistema poderá sofrer com o tempo de resposta.
Sugestão: Uma possível melhoria é incluir paginação nessa página específica para obter respostas menores, e o sistema poderia trazer o banco de dados para mais perto da aplicação, diminuir o número de acessos ao banco com grande tempo de resposta e caso a situação escale.
- Vocês sabem até que ponto sua arquitetura proposta pode ser escalada sem grandes mudanças?
R: Não.
Sugestão: Realizar testes para averiguar o que poderia ser melhor considerando a escalabilidade da aplicação.
- Vocês identificaram e validaram as suposições feitas em relação ao desempenho?
R: Não.
Sugestão: A recomendação para os desenvolvedores é implementar testes automatizados, verificando o desempenho das operações, pois sem eles não há uma garantia que o tempo de resposta está de acordo com a especificação ou se não há qualquer atraso de uma operação no software.
- Vocês já procuraram oportunidades para relaxar a consistência transacional, especialmente se vocês já estão projetando um sistema distribuído ou em grande escala?
R: O grupo está utilizando MongoDB, que utiliza o modelo NoSql, mas não aplicaram multithreads nas operações.
- Vocês revisaram sua arquitetura para armadilhas comuns de desempenho?
R: Foi revisado partes do código, utilizando as funções assíncronas tanto no front quanto na api.
- Vocês sabem qual carga de trabalho o sistema de vocês pode suportar? Você priorizou diferentes classes de trabalho?
R: Não.
Sugestão: Os desenvolvedores podem implementar algum testes de carga para medir o quanto de carga o sistema suporta, por meio de testes como Apache JMeter ou Load Runner.