Defaults

Recentemente tive a oportunidade de aprender um pouco mais sobre o que a Microsoft chama de Computação Confiável. Resumidamente, esse programa e filosofia visa obedecer os princípios básicos de segurança (Disponibilidade, Integridade e Confidencialidade), e para tal eles visam melhorias em quatro áreas, o chamado SD3+C:

• Security by Design
• Security by Default
• Security by Deployment
• Communications

Não vou discorrer sobre todos nesse momento, mas gostaria de compartilhar alguns pensamentos sobre os “defaults”. Nesse âmbito, a Microsoft pretente mudar as configurações padrões dos softwares de modo que, por padrão (ou seja: na instalação “next-next-finish” e sem nenhuma grau de parametrização), o software esteja o mais seguro possível, com o mínimo de serviços necessários atividos, possibilitando ao usuário habilita-los, passo-a-passo, explicando os níveis de segurança envolvidos em cada novo recurso ativo.

Parece uma daquelas: “Por que não pensei nisso antes?”, afinal, é um tanto quanto óbvio, não? Mas não é o que ocorre na maioria dos softwares por aí.

Os parâmetros default não estão presentes apenas na segurança, mas em todo o aspecto de um software. É frequente escutarmos coisas do tipo:

“Meu serviço x está ocupando 100Mb de RAM.”
“Ah, o meu está ocupando 500Mb! Que absurdo!”

ou…

“Se você instalou no Windows, ele estará rodando na porta 80, não na 8500!”

E depois ouvir reclamações sobre o software ou o mal gerenciamento de memória do sistema operacional. Em inúmeras vezes que escutei alguns dos diálogos acima, tinha certeza de que o software relacionado oferecia meios para configurar o recurso em questão, seja a memória ou a porta.

Desenvolvedores experientes, que têm mais confiança em seu trabalho e sua habilidade, podem freqüentemente achar e questionar por que o compilador está compilando errado, enquanto eles estavam digitando o código que fazia do modo certo. Bastam alguns minutos de revisão para ver que o compilador não está tão errado assim.

Ou justamente o contrário, desenvolvedores menos experientes ficarem contentes por suporem que acharam um bug no software. Afinal, “desse jeito não funciona. Então é um bug!!”, enquanto na verdade é um mal uso da ferramenta, da função de programação, ou algum parâmetro mal configurado.

Portanto, é importante conhecer o software e linguagem de programação que se está utilizando, seja através do hábito de ler APIs e documentações sobre o software e da humildade de poder estar errado, e o software agindo corretamente, de acordo com os parâmetros configurados. Infelizmente, nem sempre estes vêm de uma forma segura e funcional, muito menos oferecem meios simples e evidentes de configura-los (nada de arquivos em texto puro com nomes de variáveis que só os programadores daquele produto entendem), o que também nos lembra de também construirmos nossos softwares dessa maneira, facilitando a parametrização e configurando-o da melhor maneira possível para um “default”.