Segurança da Informação: a falha do TI em alterar dados do ERP com comandos SQL


As empresas brasileiras, diariamente processam milhões de bytes em informação com os mais variados tipos de dados a serem armazenados nos bancos de dados existentes nas corporações. São utilizados inúmeros aplicativos de informática para gerenciar esse contingente todo de dados que são importantes tanto para o empresário como para o governo.

O mercado está repleto de soluções tecnológicas para suprir a necessidade de se armazenar e gerenciar um conteúdo cada vez mais importante para as atividades empresariais e para tanto, necessita acompanhar a evolução tecnológica garantido a integridade e a confiabilidade de seus sistemas de computadores, transparecendo cuidado e zelo para os clientes e acionistas.

Profissionais de TI são contratados todos os dias para conseguir manter esse ritmo de backup, desenvolvimento de sistemas, análise de vulnerabilidade dos aplicativos e outras funções bem específicas envolvendo banco de dados. Não se imagina mais uma empresa controlando os seus lançamentos contábeis nos históricos “livro caixa” ou algo semelhante. É necessário o uso da informática.

Passamos todo o tempo escutando que devemos criar senhas seguras para evitar um acesso não autorizado nos sistemas e assim, manter as informações confidenciais longe das pessoas que não precisam ter um acesso às informações sigilosas e que possam realizar alguma ação que traga prejuízo para a empresa.

Observamos nas empresas que os softwares de gerenciamento de informação, os conhecidos ERP (Enterprise Resource Planning) que são os sistemas integrados de gestão empresarial, não é qualquer usuário que consegue entrar no software e muito menos tem permissão livre para fazer o que bem entender na plataforma corporativa.

Normalmente, o responsável pelo setor de TI possui uma conta de acesso com permissões mais permissivas que uma conta de um usuário de qualquer outro setor. Entretanto, para efeito da premissa de Segurança da Informação, o responsável de TI deveria ter uma conta de acesso como usuário e sem permissão de alteração, inserção e muito menos conseguir deletar qualquer informação no banco de dados, através do sistema.

Não é função do TI ser usuário do sistema ERP. Na verdade, e esse ponto é muito difícil para que os empresários tenham em mente, é que o TI não faz parte do grupo de pessoas que precisam trabalhar no ambiente do ERP. TI não é usuário de ERP. No máximo é o setor de apoio para a empresa, digamos: Setor de TI é SUPORTE!

Entretanto, cansei de observar grandes gestores da informática recebendo solicitação de departamentos internos na empresa para fazer um “favor” em determinados casos, facilitando a vida dos verdadeiros usuários do ERP. Isso deveria ser crime!

O motivo dessa opinião é que como já disse, o TI não é usuário do sistema, e sim, é apoio. Na segurança da informação, deve existir um mecanismo para identificar as mudanças que ocorrem no banco de dados tais como um log, que fica registrado qual o usuário que alterou uma informação no banco de dados, que dia, que horas, motivo e outras informações importantes para contribuir para uma possível auditoria no futuro.

Contudo, profissionais de TI gostam de demonstrar que tem o “poder” na mão e realizam a façanha de usar as aptidões de SQL (quando o banco de dados é possível ser alterado por sql) e realiza as devidas alterações dos dados conforme solicitação de terceiros. Dessa forma, essa mudança de informação diretamente no banco fere o princípio da inviolabilidade, confidencialidade, integridade e autenticidade.

Uma pergunta que é necessário fazer: qual o sentido de existir um login e uma senha para acesso ao ERP e que cada login tem as suas permissões estabelecidas para configurar o que o usuário pode ou não pode fazer dentro do sistemas corporativo se é mais fácil burlar essas regras pedindo ao setor de TI que faças as alterações cujo usuário comum não pode?

As informações gravadas no banco de dados não são de autoria do pessoal de TI. Eu disse autoria. Não se discute a responsabilidade para atender o princípio da disponibilidade. O que eu tento levantar é que, mesmo tendo um DBA na empresa, ele não altera as informações gravadas pelos usuários. No máximo ele cuida da manutenção do banco de dados, quanto a sua estrutura, índices das tabelas e um possível “roll back” quando ele mesmo erra um comando de manutenção no banco.

Se um DBA que é o especialista em banco de dados não deve alterar os dados inseridos no banco, qual a razão para que os meros mortais em tecnologia o devem fazer?

Nesse caso, eu simplesmente vejo que o sistema ERP não tem mais a segurança devida pois se o setor de TI pode alterar as informações gravadas no banco, como confiar que uma determinada informação foi registrada por um usuário e posteriormente não foi alterada?

Até a próxima!

Anúncios

17 respostas em “Segurança da Informação: a falha do TI em alterar dados do ERP com comandos SQL

  1. A partir do momento em que o administrador de bancos de dados for solicitado para efetuar uma alteração em algum dado do sistema, e ele o fizer, passa a ser um criminoso porque ele estará ajudando a manipular algum dado que com certeza é para enganar alguém (fisco principalmente), já perdi oportunidade de emprego por esse motivo, a empresa não queria um administrador, mas sim um flaudador.

  2. Jamil,

    Entendo a sua revolta mas acredito que essa situação é agravada pela falta de um Conselho Federal de Informática ou algo do tipo, que poderia resolver ou pelo manos regulamentar essa situação.

    Abraços,

  3. Gostei do Artigo, concordo com você, mas será que um Firewall de Banco de dados não resolveria tal problema e ajudaria neste desafio ?

    Um grande abraço

    Wendell Bitencourt

  4. Bem,

    Eu não conheço firewall para banco de dados, existe?

    E se mesmo existisse, a questão é que a pessoa tem autorização para entrar dentro do banco de dados, independente de firewall.

    Abraços,

  5. Roney,

    Seu artigo é muito interessante e pertinente. Concordo com a importância de uma necessidade de controle. Só não sei até que ponto é válida a existência de um Conselho Federal, pelo menos não para este caso.
    Como DBA certificado em SQL Server e desenvolvedor com experiência em sistemas de ERP, creio que o melhor seja definir desde o início de qualquer projeto, regras rígidas de controle e registro de atividades (log) diretamente no banco de dados, independente dos controles que venham a existir o se complementar nos sistemas.
    O SQL Server, por exemplo, possui boas ferramentas de logs para auditoria, desde a versão 2005. Na verdade, com um maior esforço, em qualquer versão anterior poderiam ser criados mecanismos de log no próprio banco. Mas hoje isso é bem simples, na verdade, desde que existam políticas claramente definidas. Com isso qualquer atividade, mesmo feita via código T-SQL, pode ser registrada e auditada, inclusive com disparos de e-mails para o DBA e/ou responsável por cada tabela do banco de dados, gerências, etc. Não adianta também criar auditorias e registrar tudo se ninguém for olhar. E além disso não adianta olhar e não haver uma cobrança ou ajuste de permissões para evitar algum acesso que tenha sido prejudicial à empresa ou a confidencialidade das informações.
    É claro que existem situações em que o DBA é solicitado a alteração de alguma informação, via SQL diretamente no banco de dados, até mesmo pela própria diretoria. E nem sempre é para burlar algum controle do sistema ou para fraudar algo; muitas vezes é uma necessidade legítima devido alguma mudança de regra de negócio. Não dá pra querer que os usuários entrem no cadastro de 20.000 clientes para ajustar um indicador devido a uma nova regra que empresa resolveu implantar. É mais sensato neste caso ajustar os registros necessários via SQL, desde que essa informação seja “logada” e bem justificada.

    Enfim, espero haver colaborado com a discussão.

    Abraços.

  6. Bom dia Roney,

    Sim, existe Firewall de Banco de dados, no Brasil ele ainda é pouco conhecido.
    Quanto ao seu comentário de acesso ao banco, é exatamente nesta questão que ele atua, não apenas no acesso (como um Fiewrall de de camada 3 de infra), mas sim na camada de aplicação e logs.
    Um dos fabricantes pioneiros do produto é a Imperva, veja este link abaixo que fala da solução como um todo. se precisar, eu conheço uma revenda que pode fazer uma apresentação detalhada, ok? Abraços

    http://www.imperva.com/products/dsc_database-firewall.html

  7. Wendell,

    Obrigado pelas informações que a partir de um simples artigo já estou aprendendo algo a mais, sobre firewall de banco de dados.

    Vou dar uma lida do funcionamento mais especificamente de como funciona o firewall de banco de dados e servirá como base para um artigo sobre o assunto.

    Obrigado,

  8. Magina Roney !

    Todos nos aprendemos um pouco mais a cada dia.

    Abs,

    Wendell Bitencourt
    (11)993730806

  9. Laércio,

    Concordo plenamente nos pontos apresentados a essa discussão sobre o banco de dados. É justificável realmente a necessidade, em determinados casos, de se utilizar os comandos SQL não somente para título de relatórios e sim, para realizar algumas alterações no banco de forma otimizada.

    Entretanto, o que deveria ser exceção está virando regra. Poucas empresas aqui no Estado, e aí estou falando do pequeno Espírito Santo, possuem um profissional específico de banco de dados, o DBA. Fora as grandes e sérias empresas, a maioria as intervenções no banco são realizadas por administradores de rede, analista de sistemas, analistas de suporte e quem dirá, por Estagiários!

    Realmente é uma briga de gato e rato, não adiante ter controle e logs se ninguém olha, se encontra irregularidades: ninguém é punido. É o tal “para inglês ver” ou simplesmente passar em alguma certificação da qualidade. E olha lá!

    Abraços,

  10. Concordo plenamente.
    Ainda existem empresas que tratam o TI com faz tudo e assim englobam todo tipo de função que o usuário do ERP não consegui fazer, por desconhecimento ou mesmo por falta de permissão. Cobrem a cabeça e descobrem os pés.

    Abraços.

  11. E não consigo entender como as empresas tem esse tipo de funcionário que “faz tudo” e se submete a esse comportamento com salários tão baixos. O pessoal precisa se valorizar no mercado. Depois ficam reclamando que fazem tudo, menos serviço de TI.

  12. Roney,

    É isso mesmo! Concordo contigo que o pessoal acaba abusando das “facilidades” e alterando muita coisa pelo banco. Além da falta de profissionais especializados, que é realidade aqui no MS também, muito provavelmente pior do que no Espírito Santo.
    Pra mim é uma questão cultural difícil de resolver a curto prazo. Não adianta ter as ferramentas; nós sabemos que existem, mas nossos clientes nem sempre sabem. Ou seja, qualquer melhoria desses controles passa por uma mudança de hábitos que deve partir de nós, os profissionais de TI. Os clientes estão preocupados com os seus negócios e que a TI os apoie sempre nisso. Só vão nos cobrar quando algumas dessas práticas viciadas causarem prejuízo a eles, claro! Mas não entendem e não vão resolver.
    Bom, mas essa discussão já é um exemplo de que estamos querendo mudar, não é? Nem todos estão fechando os olhos a esses maus hábitos, ainda bem!

    Abraços!

  13. Laércio, espero que os nossos profissionais de TI realmente queiram mudar essa situação senão… Vai continuar tudo do mesmo jeito.

  14. A maioria dos sistemas ERP tem uma péssima usabilidade e demandam intervenções manuais de tempos em tempos para corrigir determinados erros causados por mau uso ou mesmo por erros de programação nas customizações e integrações.
    A maior parte dos sistemas ERP existentes tem uma péssima UX e por isso são comuns erros sistemáticos dos usuários, como lançamento de um código incorreto em milhares de registros. Outras vezes, mudanças de estrutura ou melhorias de entendimento demandam alterações em massa como a atribuição de um centro de custos diferente para registros de acordo com determinados critérios. Nesses casos, a alteração programática sempre será mais eficiente e exata do que um trabalho manual de alteração registro por registro.
    A maior parte dos ERP trabalham com o conceito de versões, em que alterações em um registro envolvem uma nova cópia do registro alterado, mantendo cópias sucessivas dos registros anteriores para fins de auditoria. Ainda, a maioria dos ERPs usam triggers para implementar esse mecanismo de versões, o que garante que uma alteração, mesmo feita em SQL, irá gerar uma nova versão do registro.
    Normalmente tais alterações em massa são feitas pelos desenvolvedores, e não pelos DBAs, porque ao DBA cabe a manutenção da integridade do banco e sua segurança, mas não a semântica nem o conhecimento das regras de negócio.
    Entretanto, concordo que esse tipo de alteração tem que ser disciplinada, mesmo sendo necessária. É necessário ter uma governança de TI forte, com regras precisas para autorização desse tipo de operação e com total rastreabilidade. É inevitável que determinados profissionais possuam acesso com menores restrições para a manutenção do sistema. O erro está caso esses profissionais não estejam sujeitos a regras e limites claros. Em casos extremos tais profissionais precisariam ser sujeitos aos mesmos critérios de seleção que se emprega, por exemplo, na escolha de profissionais que tomam decisões de risco de crédito. É necessário que eles tenham treinamentos de ética e segurança da informação, bem como terem assinado termos nos quais eles declarem ter plena ciência de suas responsabilidades éticas e legais, bem como das sanções as quais concordam estarem sujeitos em caso de violação das mesmas.
    É importante lembrarmos que os dados no ERP, em última análise, não pertencem nem ao desenvolvedor ou dba, nem ao autor. São propriedade da empresa, a qual, sob sua exclusiva discrição, pode delegar ou revogar direitos de acesso ou modificação à quaisquer colaboradores que ela julgar deverem ter tais direitos em determinado momento.
    Assim como todas as empresas possuem regras muito bem claras para a autorização e liberação de pagamentos. Um funcionário com autorização para assinar cheques o faz dentro de regras muito claras, de maneira auditável e sempre com limites definidos; indo mais longe, sabemos que o poder de assinar cheques pela empresa é um poder dado a poucos, e que esses poucos são cuidadosamente selecionados e além disso, sujeitos a auditorias e controles periódicos. Usando essa analogia é fácil ver que o problema não é alterar o banco em si, mas sim se essa alteração é feita sob parâmetros definidos por uma governança de TI competente.

  15. Entendo o que foi escrito e concordo em partes. Hoje qualquer empresa não possui um planejamento adequado de projetos, então tudo deve ser entregue de forma emergencial e URGENTE. Esse URGENTE acaba gerando alguns pontos de gap após a entrega de um projeto, isso ocorre porque cortaram análises, diminuíram documentações, testes, prazos e treinamentos…

    Se você tem uma falha impeditiva, você deve alterar após analisar a ocorrência, isso voga no processo de disponibilidade e de continuidade das rotinas…
    Em paralelo você deve registrar o que foi feito, e depois da solução de contorno realizar a solução definitiva para a CAUSA do problema.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s