Já faz um tempo que ando investigando a parte de segurança em Bancos de Dados. Passei um tempão estudando a parte de segurança no Oracle e andei investigando algumas questões sobre o assunto aqui e acolá neste blog e na palestra sobre melhores práticas que fiz no FISL 9.0 e no PGCon Brasil 2007. Calhou de ontem eu estar conversando com o Dickson Guedes no IRC e resolvemos escrever um pouco sobre segurança no PostgreSQL. A idéia é para variar um pouco um tanto ambiciosa: fazer uma lista de possíveis melhorias que seriam interessante implementar no PostgreSQL para melhorar a segurança. Uma segunda etapa seria colocar a mão na massa e tentar implementar algum patch no PostgreSQL. Particularmente eu tenho muito receio de abrir o código fonte e sair mexendo. Manjo pouco de C e não tenho tanto domínio assim do funcionamento interno de SGDBs para fazer isso. Mas por outro lado, se eu não fizer o fike nunca vai me deixar em paz… e ao fim e ao cabo, a gente só aprende a fazer fazendo!!! Por fim, existe uma segunda intenção, que é começar a escrever coisas mais detalhadas sobre este assunto, iniciando assim alguns capítulos do livro sobre PostgreSQL que começa a sair do papel entrar no ar. Particularmente, eu acho que só a parte de segurança já é suficiente escrever mais de 100 páginas. Bom, de toda forma, todos aqueles que lerem este texto e sentir que há algum equívoco ou que falta alguma coisa está convidadíssimo a colaborar, seja nos comentários, seja enviando um e-mail ou mesmo no IRC.

Caramba… mas segurança é um tema tão complexo assim? Bom, depende de como você define o que é segurança em SGDB para você. Vamos começar pensando em duas ou três formas de se enarar o problema:

Muito bonito tudo isso… mas enfim, quando falamos em segurança qual é a pauta em questão? Ah sim… muitas coisas, vejamos algumas:

Como se pode ver, ao falar em segurança, temos inúmeros desafios pela frente. Temas consagrados como “Alta Disponibilidade”, “Backup”, “Política de Mínimo Privilégio”, “Trilhas de auditoria” entre outros, fazem parte do dia-a-dia (ou seria noite-a-noite?) dos que se preocupam com segurança. Em grandes equipes de TI, há pessoas especializadas em segurança. Muitas vezes, encontramos Administradores de Bancos de Dados especializados em um ou dois aspectos da segurança, como o controle de acesso e auditoria. Administradores de Dados são especialistas em avaliar problemas de restrição de integridade enquanto os Administradores de Sistemas costumam se preocupar com backup e alta disponibilidade.

Com isso, em mente, vejamos alguns capítulos de deveremos abordar em seguida:

Como se pode ver, temos muito assunto pela frente. Não tenho nenhum ímpeto de escrever seguindo uma órdem específica, provavelmente eu deverei escrever numa ordem caótica e tentar juntar as peças aos poucos.

4 respostas

  1. Já que está fazendo os capítulos de seu livro, está esquecendo que existe também a ISO 27000 que é voltada para segurança da informação, ela é bem abragente e caí na parte de banco de dados.

    Creio que você deva pensar na confiabilidade de um dado como um dos tópicos dessa abordagem pois já que está falando em segurança. Além de tudo acima, de que adianta ter toda política correta de segurança como as descritas acima se seu sistema não garante a confiabilidade de um dado ou valor.

  2. Beleza Fábio!

    Fico me questionando o que o faz fugir dessa “missão” de escrever o livro.

    P.S.: Já viu onde cai o link da Campanha “Eu sei escrever”?

  3. Muito boa sua iniciativa Fabio, sabe me informar se existe alguma maneira de criar uma trigger no Postgree que traga a informação dos usuários que acessam o banco, assim como o host, ip, horário de logon e logoff, eu não encontrei nada na internet que atenda minha demanda.

Deixe uma resposta