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.