Como aumentar a segurança de Sistema Web (Saas) · hugofg

Esse post tem o intuito de compartilhar um pouco sobre meu conhecimento na criação de barreiras de proteção de um sistema web e também aprender com os feedbacks que irei receber, inclusive com os negativos.

Escrevi abaixo um checklist resumido de ações que podem ser implementadas em 3 camadas diferentes. Cada camada oferece um nivel de proteção, que caso seja vencida poderá ser barrada pela próxima camada.

Nao sou acadêmico, nem especialista e muito menos guru. Apenas um entusiasta humilde que gosta de desenvolver. Não escrevo termos técnicos avançados...

vamos lá...

1° CAMADA - Filtros no DNS do dominio

Apontar o dns do dominio para ferramentas de proteção como google armor, gocache ou cloudflare. Elas detectam as anomalias e impedem ataques antes que cheguem na aplicação saas.
Elas devem conter recursos como waf, botdetection, rate limit, e firewall.
Waf protegerá de ataques como sqlinjection e xss
Bot detection eliminara os malditos bots
Rate limit protegerá ataques ddos
Firewall executara regras de bloqueio como ip blacklist, trafego do exterio, trafego de rede, etc.

2° CAMADA - Proteções no cloud
7) Firewall, regras de bloqueio
8) Isolamento de virtualização, separar banco de dados em uma instância, codigo fonte em outra, imagens e outra.
9) Limitar acesso ao banco de dados apenas ao ip da instancia de codigos fonte.
10) Software de segurança instalado na instância de codigo para varredura/scan de ameaças
11) Criptografia de dados em trânsito

3° CAMADA - Proteções na aplicação
12) Filtros de sqlinjection e xss para sanitização de entradas
13) Google Recaptcha api para identificar pontuação do usuário
14) Google Recaptcha v3 em forms
15) Waf proprio da aplicação
16) Ratelimt proprio da aplicação
17) Blacklist da aplicação
18) Chaleng de acordo com pontuação do usuario ou block
19) Criptografia de dados sensíveis do banco de dados
20) Gerenciamento de sessões com tokens e limites de sessão para evitar sequestro de sessao

Você se propõe a compartilhar conhecimento sobre segurança em SaaS, mas parece mais uma lista de compras sem qualquer explicação sobre o que realmente está sendo recomendado. Não quero ser crítico, mas contribuir com seu artigo!

Vamos explorar as camadas, que, por sinal, parecem mais um empilhado de ideias jogadas sem desenvolvimento.

1ª CAMADA - Filtros no DNS do domínio

Que grande ideia! Apontar o DNS para ferramentas como Google Armor e Cloudflare é tão inovador que quase me faz esquecer que essas opções são apenas o básico do básico. Mencionar WAF, bot detection e rate limiting é ótimo, mas talvez um pouco mais de profundidade sobre como configurá-los adequadamente seria útil. Afinal, “bloquear bots” é um conceito tão vago quanto dizer “proteja-se de ataques”. Um elogio ao esforço por mencionar SQL Injection e XSS, mas uma proteção básica não se resume apenas a filtros. Poderia ter desenvolvido mais!

2ª CAMADA - Proteções na nuvem

Ah, a boa e velha segmentação de recursos. Separar bancos de dados e código-fonte em diferentes instâncias parece uma abordagem segura, mas sem uma explicação sobre como isso deve ser feito na prática, é como dizer para um motorista: “dirija seguro” e esperar que ele saiba como. Além disso, limitar o acesso ao banco de dados pelo IP da instância é como dizer: “tranque a porta, mas deixe a janela aberta”. A criptografia de dados em trânsito é mencionada, mas e a criptografia em repouso? O que, você pensou que só dados em movimento precisavam de proteção?

3ª CAMADA - Proteções na aplicação

Chegamos à camada mais “inovadora”! Filtros para SQL Injection e XSS são novamente mencionados, mas aqui, a cereja do bolo é o Google reCAPTCHA. Perfeito! Nada diz "segurança" como colocar um captcha que, por sua vez, é frequentemente quebrado por bots mais espertos. Além disso, o gerenciamento de sessões com tokens é uma ótima ideia, mas quem precisa de sessões bem gerenciadas quando você pode apenas confiar na “intuição” do programador?

O artigo menciona “monitoramento de logs”, mas como se isso fosse uma solução mágica. Se você não tem uma estratégia para interpretar esses logs, são apenas dados empoeirados que vão para o limbo. E quanto à “blacklist da aplicação”? Uma abordagem tão robusta que parece ter saído diretamente de um livro de receitas de segurança de 1995.

Resumindo...

No geral, seu artigo traz algumas ideias que, quando tiradas de um contexto mais profundo, são apenas frases soltas que poderiam ser desenvolvidas. Faltam informações cruciais, análises e, acima de tudo, uma visão integrada de segurança. Com um pouco mais de trabalho, isso poderia ser um guia útil, em vez de um lembrete do que não fazer. Que tal uma revisão mais técnica e aprofundada da próxima vez?

Outra pergunta? Porque isso só seria necessário em um SaaS? Usou SaaS como tentativa de cliques? Não julgo, mas segurança é necessário para todo tipo de aplicação.