On Tue, 2010-03-23 at 18:07 -0300, Pablo Sánchez wrote: > Em 23 de março de 2010 08:46, Marco Carnut <k...@tempest.com.br> escreveu: > > "guardar em ambiente seguro, por 5 (cinco) anos, > > para atender a investigação pública, os dados de > > tráfego de que trata o inciso VI do art. 2º da presente lei;" > > > > Aí eu faço aquela minha clássica pergunta: "seguro contra > > *o que*?" A primeira coisa que é dificílima de fazer é tornar > > a coleta dos logs segura contra o próprio admin. > > Esse é o menor dos problemas.
Ao meu ver, esse problema não é tão "menor" assim. Exemplo: é bem provável que, além da retenção dos dados crus, sejam desenvolvidos interfaces de busca para facilitar a vida dos investigadores e até dos próprios provedores em dar vazão aos pedidos. Essas interfaces, por sua vez, são outro vetor de ataque -- e foi exatamente essa que foi atacada no recente "impasse" Google <-> China, só para citar um incidente recente do qual se fez muito estardalhaço. Sem falar nos abusos que tanto admins, quanto investigadores, quanto políticos, historicamente cometem -- do qual o escândalo do painel do senado talvez seja o mais conhecido dos casos. Isso sem também mencionar os precedentes conceituais -- ok, todos já se acostumaram a serem vigiados no sistema financeiro, agora na web, agora vamos vigiar também o histórico de saúde e, afinal, por que não colocar reconhecimento de face em todas as câmeras? É nesse ponto que o meu amigo Pedro Rezende costuma invocar a alegoria do sapo sendo cozido vivo sem perceber. > Esse ponto do PL leva a outro muito > pior: a queda dos pequenos provedores. Porque? Porque armazenar logs > de acesso sai caro, cada coisinha que trafega na rede já é uma linha, > para poder armazenar logs por 5 anos é preciso montar sistemas > relativamente caros de bkp, e quem é que vai bancar isso para os > pequenos? > > Enfim, vão acaba tendo que acrescentar um arquivo digital mantido pelo > governo para isso. Logs de acesso não devem ser guardados por 5 anos, > não é como guardar um arquivo em papel, ou qualquer coisa do gênero. O > custo quem vai ter que bancar é o provedor, e isso tira muita gente do > mercado, simplemente porque as soluções de bkp e storage extrapolam o > que os pequenos podem bancar. Os requisitos técnicos são desafiadores para os padrões caseiros, mas não me parecem nada demais no mundo das soluções de storage. Não creio que dê pra afundar os pequenos provedores só por causa disso. Fazendo aqui uma conta de padaria baseada nos dados que conheço lá da Tempest: processamos uns 200 GB de logs de clientes nossos por dia (firewalls, webservers, FTPs, APs Wifi e outros dispositivos), mas, como a primeira coisa que fazemos é comprimi-los, eles ficam cerca de 20 vezes menores em média, ou uns 10GB/dia. Tomando esse valor como base, isso daria, no caso dos prvedores, ao longo de 365,25 dias * 5 anos, um total de 18,25TB que vou arredondar pra 20TB. Vamos dobrar isso pra colocar minimamente em RAID1 e vamos dobrar de novo pra colocar índices para permitir buscas rápidas. Isso dá 80TB. Vamos supor que um HD de 1TB esteja por R$ 1K (caríssimo só para o disco, mas realista se incluirmos o custo amortizado das máquinas ou backplanes), isso dá um investimento de R$ 80K, que, pelo fato de ter software (que 99% dele pode ser livre, mas costuma ser necessário um ajuste in-house), teste e provavelmente alguém dedicado pra cuidar disso tudo, vou super-arredondar para R$ 200K. Isso, em 60 meses, dá R$ 3,3K/mês, que, pela Lei Universal das Estimativas de Guardanapo, vamos arredondar para R$ 4K/mês. Não é um investimento tão alto e pode ser feito gradualmente. É preciso ser um provedor realmente pequeno pra não poder arcar com isso. É claro, muita gente teria a "brilhante" idéia de tentar guardar essa maçaroca de dados sem compactá-los -- aí os custos ficam umas 20 vezes maiores, ou R$ 66K/mês, que já é o bastante pra chatear muito diretor de TI. Também não duvido que muita gente iria bater cabeça tentando usar a "solução convencional" de colocar esses dados em SGBDs relacionais comuns, que tipicamente não se revelam muito adequados pra esse tipo de tarefa. Também não duvido que muita gente, ao invés de usar as excelente ferramentas livres que existem, optariam por comprar sistemas proprietários caríssimos. Sob essa ótica, talvez você tenha razão, mas ainda acho que, para gente tecnicamente bem informada e competente, esse problema é tratável. Ou seja, isso tudo foi uma justificativa meio longa (talvez longa demais pro gosto de muita gente aqui na lista) de por que eu tenho lá minhas dúvidas se concordo com você que os requisitos técnicos de armazenamento sejam um problema muito maior do que as implicações jurídicas. Mas, vejam, eu pelo menos mostrei que com software livre os requisitos técnicos ficam bem mais tratáveis -- quem sabe assim os moderadores me perdoam pelo provável off-topic. ;) -K. _______________________________________________ PSL-Brasil mailing list PSL-Brasil@listas.softwarelivre.org http://listas.softwarelivre.org/mailman/listinfo/psl-brasil Regras da lista: http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil SAIR DA LISTA ou trocar a senha: http://listas.softwarelivre.org/mailman/options/psl-brasil
