Atualização de pacotes, talvez, seja o que mais falta as empresas. Conheça as vulnerabilidades
Algumas das mais importantes formas de reduzir riscos estão amparadas em fundamentos de segurança da informação: manter seus sistemas atualizados, prevenir que dados se espalhem, ter a certeza de que os sistemas estão devidamente segmentados e verificar onde você armazena dados estratégicos. Aqui, vão cinco dicas de especialistas sobre ações necessárias para manter uma boa higiene da base de dados:
1. Atualizar com frequência: assim como patches e gestão de vulnerabilidade tomam grande parte da redução de risco no ponto final, esses fundamentos básicos têm o mesmo nível de importância para manter o ambiente de base de dados íntegro. “Talvez a solução mais fácil e efetiva para segurança de bases de dados, instalar os paches de fabricantes tão rápido quanto possível vai ajudar a mitigar ameaças que se baseiam em vulnerabilidades conhecidas”, diz John Linkous, chefe do escritório de segurança e compliance da eIQnetworks. Mas essa alternativa ainda é frequentemente ignorada por usuários. De acordo com a pesquisa 2012 IOUG Enterprise Data Security, publicada em novembro, 28% dos usuários Oracle nunca fizeram – ou, pelo menos, não sabem – uma atualização do tipo crítica. Outros 10% levam um ano ou mais para se adequar a esses boletins. No mesmo caminho, desenvolvedores que implementaram aplicações web que se conectam a esses banco de dados precisam atender de forma mais dura a essas atualizações. “Muitos desenvolvedores implementam uma aplicação web e simplesmente esquecem dela. Elas não devem ser esquecidas. Alguns componentes são parte de um pacote que precisa de uma manutenção e regime para garantir que não serão explorados”, disse Mark Goudie, responsável pelo gerenciamento de segurança da Verizon Enterprise Solutions. “Muitas organizações esperam que as aplicações web que foram implementadas sejam tratadas no estilo ‘se não quebrou, não precisa de conserto’. Há pessoas buscando por vulnerabilidades 24 horas por dia, todos os dias. Não dê a eles a chance de comprometer seus sistemas. Faça a atualização assim que puder.”
2. Prevenir a disseminação de dados: se a sua organização faz um bom trabalho em manter as bases bem monitoradas e os dados propriamente criptografados, não desfaça esse trabalho. Ele é crucial para que suas políticas fiquem em conformidade com a regra de Las Vegas – o que acontece na base de dados fica na base de dados – porque, assim que a produção de informações começa a partir para outros lugares e formatos, as coisas tendem a se tornar bagunçadas e os riscos sobem. Por exemplo, organizações deveriam fazer seu melhor para evitar que haja permissão de acesso de dados em tempo real para ambientes de desenvolvimento. “Fortalecendo a produção da base de dados dentro de seu ambiente de testes ou desenvolvimento, aumenta-se o risco de quebras de privacidade, de requerimento de capacidade de CPU e armazenamento, impedindo a flexibilidade e a agilidade”, explicou Roberto Catterall, especialista do IBM DB2. Da mesma forma, planilhas em pontos finais inseguros que acumulem dados importados podem, efetivamente, corromper os investimentos de segurança feitos na base. Além disso, é preciso ter atenção em como e onde os arquivos são armazenados no caso de backup. “Saiba onde seus arquivos de backup estão armazenados. Garanta que eles não estejam em qualquer root de aplicação web, ou em outro ambiente que possa ser acessado por uma solicitação feita por uma aplicação web”, explicou Chris Weber, cofundador da Casaba.
3. Compartilhar servidores de forma cuidadosa: de acordo com especialistas da Verizon Enterprise Solutions, uma das formas frequentes de ter a base de dados hackeada é por meio de servidores web. “Se há apenas uma aplicação web vulnerável em apenas um website é possível que haja uma quebra de informações de todos os sites e bases associadas”, disse Goudie. “Não há problema em compartilhar servidores, mas é necessário saber quais dados eles podem ter acesso. Essa não é uma análise feita de forma estática, mas precisa ser desempenhada toda vez que há uma mudança no dado acessado pela aplicação web, já que essa mudança pode requerer a necessidade de realização da aplicação web para uma zona diferente de segurança.” E já que os servidores de web costumam ser compartilhados, as empresas deveriam procurar armazenar sua base de dados em outro lugar. “Não coloque ambos na mesma máquina, use fortes métodos de autenticação com, possivelmente, certificados de clientes sobre as senhas.” Mesmo sem o problema de compartilhamento de servidores, empresas geralmente precisam de um melhor trabalho de segurança em servidores de bases de dados, segundo explicou o gerente técnico de marketing da Varonis. “A maior parte das definições de segurança e de risco reside no servidor que hospeda o banco de dados “, avalia.
4. Rédeas no acesso de aplicações: nas empresas típicas, muitas contas de aplicações recebem acesso à base de dados, e para piorar, os detalhes dessas contas são geralmente conhecidos pela forma como os usuários são organizados. Isso pode dar a vantagem de identificar quem é o principal usuário, o que permite que aplicações tenham acesso legítimos e, até mesmo, não legítimos. Especialistas explicam que empresas precisam lidar melhor com a forma como as aplicações acessam os bancos de dados, para prevenir que elas se tornem um canal fácil de ataques internos e externos. “Fortaleça listas de controle de acesso para conexão de aplicações nas bases de dados”, explica Toby Weir-Jones, da BT Assure. “Se você sabe que as questões, inserções e modificações podem somente ser originadas de fontes específicas, construa essas regras em listas de controle de acesso [ACLs, da sigla em inglês] para fortalecê-las. Muito como um firewall, o comportamento padrão deveria bloquear todas as conexões, exceto aqueles que são explicitamente permitidas.”
5. Protegendo configuração de transmissão de arquivos: muito frequentemente, desenvolvedores armazenam em textos simples as informações de transmissão para bases de dados e suas aplicações vão para um arquivo de configuração que inclui nome de usuário e senha. Em situações realmente desordenadas, onde o banco dados está compartilhando um servidor com as aplicações, esses arquivos ficam lado a lado na mesma máquina. “O perigo disso é que o servidor de web fica comprometido, a informação de login é facilmente revelada a partir do arquivo de configuração”, disse Steven Loew, CEO da Innovator, que encoraja organizações a criptografar esses arquivos para proteger melhor as informações e o login. “Criptografar a conexão pode parecer um exagero, mas se o servidor de web estiver comprometido, fica mais difícil para um intruso ter acesso ao banco de dados.”
Fonte: ITWEB
Nenhum comentário:
Postar um comentário