Devemos considerar segurança no escopo do sistema ?
Participo de uma lista de discussão e por estes dias surgiu uma troca de e-mail cujo o assunto final foi a questão da segurança na aplicação. Dentro do acalorado debate, apareceram os que são a favor de considerar a segurança na aplicação e outros que acham que isso é um exagero. Teve até quem disse, que segurança é “manter os funcionários felizes”.
A nossa dependência dos sistemas é cada vez maior. É também cada vez maior a quantidade de informações sobre a nossa pessoa que estão nas “nuvens”. Diante disso é impossível dizer que a segurança da informação não é um assunto importante. Não faltam hacker dispostos a roubar nossas senhas, encher nossas caixas de e-mail com spams, nos infectar com algum “vírus” capaz destruir, etc. O mundo virtual já foi um lugar mais seguro.
Pensando em nossa aplicações …primeiro, temos que evitar as otimizações prematuras… Vejo muito sistema sendo feito por aí em que o time de desenvolvedores acabam se afastando dos requisitos do cliente e criam verdadeiros monstros - do ponto de vista de retorno de investimento, manutenção e etc – que não agradam a ninguém. Nisso eu incluo a questão da segurança. Não pode dar o mesmo peso para segurança para um sistema financeiro e um outro que apenas encurta a Url.
Por isso a discussão é válida desde que a coloquemos dentro do contexto correto. Isso não significa que jamais devemos pensar em fazer sistemas seguros. Quero dizer que devemos dosar. Essa é a mais difícil das tarefas. Pois muitos podem dizer que o esforço de fazer será o mesmo esforço de fazer muito ( exemplo: o esforço para criptografar os dados do banco é tal que se torna interessante fazer também o trabalho de senhas e esquemas também).
Devemos fazer sistemas para o mundo real. Nele, sempre terá alguém mal intencionado capaz de fazer um ação danosa. Por isso, backup, proteção de senha, etc fazem parte da discussão de arquitetura da aplicação, mas novamente, tendo o cuidado de dosar evitando os excessos. Um bom começo seria listar quais ações que podem ser tomadas, quantificá-las, qualificá-las (por complexidade, custo, retorno, etc), e outras coisas afins. Tendo a lista podemos apresentá-la para o cliente e, uma vez que o assunto é mais técnico, tentar mostrar os prós e contra de investir nisso para o cliente. No final a decisão é dele.
Agora, uma coisa que acredito e espero que seja um senso comum, são os problemas de simples solução que já fazem parte de nosso folclore. Coisas do genêro de SQL Injection, senhas fortes, dados de cpf e afins criptografados, no meu entender, devem ser tratados dentro do desenvolvimento mesmo que não haja uma anuência clara do cliente. Esses problemas são conhecidos e por muitas vezes, numa discussão de escopo, eles ficam subentendidos. Ou deixa claro que não irá fazer e explica o motivo e já inclui o esforço nas estimativas.
Questões de diretórios, permissões de escritas, proteção de arquivos de configurações, esses sim podem ser negociados e eu pessoal acho que deve. Lembrando de nunca esquecer de achar a dosagem certa. Como dizem alguns farmacêutico: a diferença entre o remédio e o veneno é a dose.
No fim, o famoso bom senso reina absoluto novamente.