[THOMPSON, 1995] em sua publicação clássica apresenta uma constatação bastante incômoda. Ele trata da confiabilidade de códigos não produzidos localmente ou que não exista a possibilidade de verificação de seu código.
Essa discussão é bastante atual, pois a eterna luta entre a comunidade de software livre e proprietários tem suas raízes baseadas no dilema de como é possível confiar que um software faz exatamente o que se pede, quando não se pode auditar o código.
No Brasil, com a ascensão do Presidente Luiz Inácio Lula da Silva, foi determinado que no âmbito do governo federal softwares de código aberto deviam preferencialmente ser usados. Dentro do contexto de segurança, tal decisão foi extremamente acertada, porém o simples fato de se ter acesso ao software, não é garantia de que o usuário está livre de vulnerabilidades e da ocorrência de falhas de segurança.
Conforme [NIST, 2002] a segurança é um processo onde o fator humano é determinante para seu sucesso. Entre esses fatores pode-se citar como crítico as falhas causadas por usuários internos. Estudos rescentes [MÓDULO, 2003] mostram que um grande número de incidentes de segurança são causados por ações não intencionais de usuários, ou seja, erros ou falhas inseridas pelos próprios funcionários devido ao não conhecimento do sistema usado ou simples falta de disciplina e conscientização no que tange a segurança.
Apesar de a ação de coibir o uso de software proprietário ter sido correta, a forma como o trabalho foi feito apresenta sérias falhas gerenciais. A primeira delas foi a publicidade a migração. Sabe-se que o homem é muito reativo a mudanças, dessa forma uma mudança de seus hábitos diários, se não for devidamente justificada, fará com que ele seja um adversário potencial a idéia. O problema nasce que muitos usuários até hoje não vêem como necessária a migração das aplicações para código aberto, normalmente justicando sua ação em um ponto muito importante: a migração atende apenas aspectos financeiros, sem analisar aspectos produtivos.
Essa visão do problema, apesar de ser bastante simplista, não está equivocada, pois a bandeira levantada pelo Governo Federal em muitas esferas técnicas e gerenciais, apesar de todo a bandeira libertária, foi a que o uso do software livre é bom porque é mais barato que o software proprietário.
Isso não é uma verdade universal, pois os custos mudam de local. O uso de software livre, por ser mais flexível, necessita que seus administradores sejam mais flexíveis também, o que ocasiona que o custo de aquisição seja diluído nos custos de suporte técnico e treinamento. Esse fato não é um problema, pois ao invés de pagar royalts para uma empresa, muitas vezes estrangeira, o dinheiro é gasto no país, aquecendo dessa forma a economia local. Apesar dessa constatação, o que se viu nas repartições públicas não foi essa transferência de dinheiro, mas sim o simples corte de gastos.
A maior vantagem do uso de software livre é a capacidade que dá ao usuário de ter o exato conhecimento do código que está usando. Para isso deve ter conhecimento técnico suficiente para que possa analisar os diversos fontes gerados e verificar que não existem backdoors nem falhas graves de segurança. Porém esse nível de uso do software livre é bastante complicado de ser atingido, pois envolve um conhecimento técnico muito aprofundado, o que muitos órgãos governamentais não estão interessados em pagar.
Uma forma de resolver essa questão seria adotar um modelo similar ao americano, onde alguma entidade seria responsável por auditar todos os códigos utilizados pelo Governo Federal e gerar recomendações e documentos oficiais atestando a segurança da aplicação, ou seja, a não presença de bugs significativos ou cavalos de tróia.
Para que isso fosse possível, seria necessário que houvesse uma padronização dos softwares a serem usados pelas diversas entidades governamentais, o que de certa forma já é feito, pois liberdade não pode significar falta de produtividade.
Porém essa realidade está longe de estar presente. Nossas ações gerenciais e políticas no uso de software livre seja no nível de Política de Estado ou dentro das políticas locais das Instituições, ainda vêem a questão como uma mera questào financeira.
Outro fato que colaboraria para essa questão é que comunidades de software livre muito conhecidas na verdade possuem poucos profissionais com real conhecimento do código fonte que representam. Na maior parte das instituições públicas, a grande parte dos usuários são apenas administradores de sistemas, onde os desenvolvedores de aplicações usam as bibliotecas, linguagens e adaptam o código livre a suas necessidade, não havendo tradição de existirem grandes mantenedores de software básico como compiladores e sistemas operacionais. No Brasil a situação é um pouco melhor, mas não muito diferente.
Essa situação é alarmante, pois a linha de adoção do software livre usada pelo Governo Brasileiro, não resolve o problema do software proprietário, mas sim apenas mascara a questão, pois a visibilidade prometida pelo uso de software aberto está longe de ser alcançada.
Conforme comentado anteriormente, essa questão somente será resolvida quando as autoridades governamentais mudarem sua postura com relação a questão, usando como justificativa para a sua adoção os motivos que permearam o crescimento inicial da comunidade.
Referências Bibliográficas:
[THOMPSON, 1995] Ken Thompson. Reflections oon Trusting Trust. ACM, 1995.
[NIST, 2002] Risk Management Guide for Information Technology System. NIST, 2002.
[MODULO, 2003] 9a. Pesquisa Nacional de Segurança da Informação. Módulo, 2003.
Nenhum comentário:
Postar um comentário