Para a restrição de acesso às paginas de configuração da ferramenta proposta, faz-se necessário o controle através de chave e senha, no qual somente algumas pessoas autorizadas terão acesso. Este mecanismo de autenticação através de chave e senha para a configuração da ferramenta interage diretamente com o sistema de segurança da máquina Unix.

Por questões de segurança no acesso as informações, todas as páginas HTML que são mostradas pela ferramenta são armazenadas em outra área do disco, não fazendo parte da estrutura de diretório do servidor WWW. Estas páginas estão salvas sem a extensão padrão ".html ou .htm", para não serem identificadas. Como elas não possuem a extensão característica das páginas HTML nem fazem parte da estrutura padrão de diretório do servidor WWW, é impossível que elas sejam acessadas diretamente através de um Browser WWW, sendo o seu acesso possível somente através de um programa CGI que monta estas páginas sabendo em quais arquivos elas estão armazenadas e em quais diretórios da máquina Unix é possível encontrá-las. Existe uma exceção para esta regra, isto é, somente a primeira página é acessível diretamente através do servidor WWW, pois será através dela que todas as demais funções são acessadas. As demais páginas da ferramenta só serão acessadas se a chave e a senha do administrador forem informadas.

5. CONCLUSÃO

Por mais que existam ferramentas que consigam bloquear algumas das tecnologias mencionadas neste documento, como é o caso das Firewalls e de alguns anti-vírus, sempre aparecerá uma nova tecnologia ou a combinação delas que serão utilizadas para aplicar ataques aos usuários da Internet.

Para que os resultados destes ataques fossem minimizados, pois um controle efetivo sobre todos os Browsers WWW de uma Intranet é inviável, surgiu a solução exposta no sessão 4 deste documento, que barra o recebimento de conteúdos executáveis na entrada da Intranet, deixando passar somente quando o local de origem do conteúdo executável é conhecido e foi configurado pelo administrador da ferramenta para que o seu recebimento fosse aceito.

Esta não é a melhor solução para o problema uma vez que a melhoria da qualidade dos documentos que utilizam conteúdos executáveis é substancial, e a solução proposta na sessão 4 garante a segurança mas restringe o recebimento destas tecnologias somente de locais conhecidos. Por mais que um conteúdo executável seja confiável, se não fizer parte da relação de locais conhecidos e autorizados, seu recebimento é negado.

Existem alguns estudos que incluem assinaturas digitais nos conteúdos executáveis para os mesmos possam identificar a origem, como é o caso dos controles ActiveX, mas mesmo assim isto não resolve os problemas de segurança gerados pela utilização destas tecnologias, pois por mais que um código tenha uma assinatura digital ninguém garante o resultado de sua execução.

Para resolver os problemas qualquer conteúdo executável que fosse recebido por um Browser WWW deveria passar por Modelos de Segurança padrão criado no Browser WWW para a execução dos mesmos, como é mostrado na figura 5.1. Este modelo de segurança é que iria permitir que um conteúdo executável pudesse ser processado, independe da tecnologia que foi utilizada para a criação do mesmo.

Para isto uma padronização no uso dos conteúdos executáveis é necessária, isto é, os conteúdos executáveis primeiramente seriam executados e analisados pelo Modelo de Segurança para depois sua execução ser aplicada ao Browser WWW.

Isto tira das linguagens que desenvolvem conteúdos executáveis a tarefa de criar mecanismos alternativos para resolver os problemas de segurança gerados por soluções mal projetadas e muitas vezes mal implementadas.

BIBLIOGRAFIA