[AJUDA] Segurança no sistema SaaS

Meus 2 cents,

Seguranca de um SaaS envolve diversos pontos e depende da tua configuracao, mas algumas dicas mais genericas:

1. Pesquise sobre "hardening" - eh o termo usado sobre ajustes de seguranca. Voce pode pesquisar sobre "hardening vps", "hardening php" ou "hardening php vue"

2. Grosso modo, voce tem 3 superficies de ataque: a VPS, o WEB Server e o frontend.

2.1) Grosso modo, existem 2 tipos de ataque: oportunismo/Spray-and-pray e targeted

2.2) oportunismo/Spray-and-pray: sao ataques automatizados em larga escala, tentando exploits padrao. Sao um saco, consomem banda, mas nada do outro mundo (p.ex. um honeypot imap que tenho recebeu cerca de 177 MIL nos ultimos 3 dias - sao principalmente ataques de forca bruta chutando usuarios e senhas). O fail2ban e modsecurity dao conta destes (abaixo)

3. VPS:

3.1) Dentro do possivel, mantenha autenticacoes 2FA

3.2) Dentro do possivel, troque o acesso root com senha por acesso via "authorized_keys"

3.3) Dentro do possivel, troque a porta do SSH (do padrao 22 para outro, p.ex. 65022)

3.4) Se possivel, utilize o servico 'fail2ban' - eh um daemon que fica observando teus logs e levanta regras de firewall basicas (p.ex. DROP) quando detecta um ataque. So que tem de ser configurado.

4. WEB Server

4.1) Se possivel, utilize o servico 'modsecurity' - eh um WAF (web application firewall), semelhante ao fail2ban - fica olhando o trafego e levanta regras no firewall quando detecta um ataque. Acredite, um SaaS sofre muitos ataques, mas a maior parte inocuos porque visam itens que voce provavelmente nao tem (p.ex. wordpress)

5. Frontend

5.1) Estes ja acho perigosos, pois vao visar as fragilidades do teu codigo.

5.2) Sempre faca "sanitização" dos dados recebidos por formulario - basicamente passar uma funcao que aplique slashes e filtros. Verifique se tem "CORS".

5.3) Nunca confie ou armazene dados sensiveis em cookies: no maximo um ID de sessao - os dados sensiveis tem de estar do seu lado. Lembre-se: cookies podem ser manipulados localmente, entao colocar nome de usuario, nivel de acesso, etc - eh pedir para se incomodar.

5.4) Isso vale especialmente para dados de carrinho e pagamento: nunca confie - o backend sempre tem de revalidar e enviar os dados

5.5) Dentro do possivel, nunca informe dados de recuperacao de senha: no maximo peca para o usuario entrar novamente o email de cadastro e avise que caso existe, um link de recuperacao foi enviado para j***@e**.com.br

5.6) Dentro do possivel, habilite 2FA ou senhas OTP no SaaS. Por exemplo, ao inves do usuario ter uma senha, sempre envie um codigo para o celular dele depois que ele digitou o usuario.

Tem mais coisas, mas acho que ja deu para entender.

Saude e Sucesso !

se você esta desenvolvendo ele, a melhor coisa que eu posso te recomendar é implementar testes automatizados, o teste não é garantia de segurança, mas te faz ser um dev mais cuidadoso... a Esmagadora maioria dos problemas de segurança que os projetos que eu tive envolvido seriam resolvidos por testes automatizados.

se vc não esta usando um framework... Francamente, Por que? o Que vc esta fazendo exatamente? novamente , um framework não é garantia de segurança, mas 99% dos problemas de segurança que vc pode ter vão ser tratados usando as facilidades de um framework

mas se vc quiser ir atrás de estudar sobre segurança e aplicar desde o inicio, um bom lugar pra começar é com o owasp top 10

Tem muitas coisas que podem ser feitas e depende muito de como sua aplicação é executada. Vamos supor que esteja em um VPS que você tem muito controle:

• Configure o firewall para permitir acesso SSH apenas para o IP das pessoas que realmente precisam acessar (os painéis de adm das hospedagem normalmente tem isso de maneira fácil). Se seu IP for dinâmico, então vai ter que editar essa configuração todas as vezes mas é melhor do que deixa a máquina exposta.

• Crie um usuário no sistema operacional específico para a sua aplicação, nada de usar o root ou um usuário com grandes privilégios na máquina, par esse novo usuário só dê permissões nos diretórios da aplicação.

• O ideal é que seu banco de dados de produção esteja em um serviço próprio para isso, e configure para ser acessado apenas pelo IP da hospedagem do servidor de produção.

• No banco de dados, também não use um usuário root ou com grandes privilégios, nada de poder fazer drop ou criar objetos no banco de dados, e se possível remova desse usuário a possibilidade de delete em tabelas importantes. Isso pode fazer com que você precise rever as estratégias de migrations e usar soft delete, é chato mas deixa o banco de dados menos vulnerável.

• Sempre valide as entradas dos usuários, ou seja, certifique-se que os dados estão ok e se o usuário logado tem permissão para acessar os dados que solicitou.

• Estude sobre observabilidade

• Configure o servidor (nginx, apache...) para não enviar cabeçalhos que indiquem, por exemplo, a versão do PHP, do próprio servidor e etc. Antigamente era bem comum isso no PHP, não sei como está hoje em dia.

• Se fosse um projeto Node com Express, iria recomendar o uso de um middleware chamado helmet, como não sei o equivalente em PHP, verifique todas as tratativas que o helmet faz em projetos Node e veja como aplicar no seu projeto. Tem muita coisa viu.

Bom, esses são apenas alguns pontos bem iniciais, segurança de aplicações é bem mais do que isso.