Esse comentário parece gerado por IA, mas de qualquer forma são dicas de hardening válidas.

Mas para deixar claro: só hardening não é defesa em profundidade por si só. Fazer hardening é bom, mas isso não é criar uma camada extra de defesa.

Pense em defesa em profundidade como criar várias barreiras de defesa ao invés de confiar na superfície de ataque como sua única barreira de defesa. Comparando:

Sem defesa em profundidade: superfície de ataque -> acesso a sistema.

Com defesa em profundidade: superfície de ataque -> barreira 2 -> barreira 3 -> acesso ao sistema.

Vamos pegar como exemplo a "tua" (ou da IA) dica um: "Usuário dedicado e sem privilégio por aplicação".

Ela é boa e faz sentido. Mas isso não é defesa em profundidade, mesmo que superficialmente possa parecer. Mesmo com limitações de acesso do usuário, ainda assim o atacante já obteve acesso ao sistema. Ele já pode persistir acesso, ele já tem acesso a tua rede interna, já pode tentar explorar uma vulnerabilidade no kernel etc.

Digamos que teu servidor tá hospedado na Google Cloud. Mesmo com um usuário com acesso limitado, o atacante já tem acesso a API de metadados da Google Cloud e, por consequência, já pode obter uma credencial de acesso ao painel da Google Cloud. Com isso ele poderia, potencialmente, obter acesso root não só à esse servidor, mas também todos os outros servidores do projeto. Também obteria acesso à banco de dados e por aí vai.

Para eu realmente considerar como uma "camada de proteção", eu diria que tem que haver isolamento de rede, processos e sistema de arquivos; melhor ainda se houver isolamento de kernel (com MicroVM, por exemplo).

É por isso que mencionei sandboxing e containerezição como exemplos, dá para fazer esse isolamento com os dois. Com SELinux/AppArmor também dá para hardenizar o processo, limitando os acessos dele.

Mas repito: são dicas de hardening válidas. Só queria esclarecer que existe diferença entre hardening e defesa em profundidade.