Segurança no PostgreSQL – Parte I: "A Saga"

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:

• Segurança em SGDB não se refere apenas ao seu banco de dados, diz respeito a toda a cadeia tecnologia associada a sua aplicação, uma vez que um único elo fraco da sua solução de TI põe em risco o conjunto como um todo. Então não basta pensar no SGDB isoladamente. Temos que pensar no equipamento onde o SGDB se encontra, no SO, na instalação do SGDB, nos dados contidos no banco de dados, na aplicação acessando o banco de dados e finalmente no usuário que precisa destas informações;
• Todos estão carecas de saber, mas não custa repetir: os bancos de dados guardam um patrimônio valioso: informação. Quando você tem um problema de segurança num SGDB, são os seus dados que estão ameaçados. A pergunta que sempre se faz é “quanto vale a informação guardada nos bancos de dados”. Melhor pergunta seria: “quanto custa a perda destes dados?”.
• Segurança tem haver com coisas com o potencial de tirar o sono/emprego de toda uma equipe de TI. O desempenho é importante. Algumas vezes é muito importante. Mas em geral, a segurança vem em primeiro lugar. Esta importancia hoje tem nome, endereço, telefone, e-mail e tudo o mais. Depois da onda gerada pelo SOx nos Estados Unidos, a segurança passou a ser mais importante ainda. O COBIT e o ITIL e suas normas e regulamentações associadas são representam mais uma pressão na busca por mais segurança em torno das informações.

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

• Integridade: tem muito haver com ACID. Seus dados não podem se corromper, independente do que venha a acontecer. Mesmo que seus dados se tornem indisponíveis durante um certo período (devido a uma queda de energia, falha na rede ou num disco por exemplo) você tem que garantir que uma vez que o problema de indisponibilidade esteja resolvido, todos os dados tem que reaparecer intactos. Integridade também tem muito haver com o uso de restrições de integridade, para que um erro do usuário ou da aplicação não permita que os dados sejam corrompidos. O uso das restrições de integridade devem proteger seus dados contra alterações que não estão de acordo com as suas regras de negócio;
• Perda de dados: a preocupação número 1 de todo administrador de banco de dados é evitar ao máximo a perda de dados. Aí entra em cena a mais tediosa das tarefas: o backup. Ocorre que em bancos de dados, não existe uma única forma de se fazer um backup, existem várias estratégias. De toda forma, é preciso definir antes de mais nada: qual é o volume máximo de dados que admissível perder? Os dados relativos a última semana de operação? Talvez o último dia? A última hora? Nem um segundo sequer? Bom, é claro que ninguém quer perder nada, mas você sabe realmente qual é a o grau de proteção que a sua atual política de backup lhe oferece?
• Disponibilidade: capacidade de manter o acesso às informações de forma contínua. Falhas humanas, falhas de software e falhas de hardware podem gerar indisponibilidade a qualquer momento. A sua tolerância a indisponibilidade vai variar conforme a importância e rítimo de operação das suas aplicações. Algumas não podem parar nunca e trabalham em regime 24/7. Outras só precisam estar ativas em horário comercial, mas não admitem um minuto sequer de indisponibilidade neste período. Seja como for, é importantíssimo definir qual é o SLA agregado aos serviços prestados pelo banco de dados para que se possa traçar uma estratégia adequada para se atingir estes objetivos. Sua estratégia deve garantir que mesmo ocorrendo uma falhas, mesmo graves, os dados devem estar disponíveis no prazo determinado pelo seu contrato de SLA.
• Controle de Acesso: capacidade de que as informações disponíveis no banco de dados estejam disponíveis para as pessoas corretas, que terão permisão de acesso apenas as operações permitidas para o seu perfil. Geralmente o controle de acesso se dá a partir de objetos do banco de dados, mas pode se re referir ao acesso de apenas um parte dos dados de um objeto, como apenas algumas linhas de uma tabela. O controle de acesso pode limitar a quantidade de recursos que você pode utilizar no banco de dados. Os recursos podem ser o número de conexões ativas, memória, processador, volume de dados acessados em disco, etc.
• Auditoria: registro de operações realizadas no banco de dados. O registro pode conter informações sobre quem, realizou que tipo de operação, sobre qual objeto e em qual momento. O registro também pode conter quais foram as alterações realizadas, permitindo reconstruir os dados num estado anterior se necessário. A auditoria também pode significar monitorar outras condições do banco de dados, como picos de utilização, espaço em disco e outros detalhes que se deseje registrar.

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:

• Trabalhando de forma segura:
  • Escrevendo código robusto e flexível;
  • Usando o psql;
  • Documentando o trabalho realizado;
• Ambientes de Trabalho
  • Isolar para proteger
  • Ambiente de Produção
  • Ambiente de Homologação
  • Ambiente de Testes
  • Ambiente de Laboratório
• Integridade
  • Modelagem de Dados;
    • Domínios;
    • Sequências;
    • Chaves Primárias;
      • Chaves Primárias artificiais X naturais;
      • Quando é permitido criar uma tabela sem PK?
    • Chaves Estrangeiras;
    • Restrição UNIQUE;
    • Restrição NOT NULL;
    • Restrição CHECK;
    • Gatilhos;
    • Visões Materializadas;
  • ACID
    • Transações
    • MVCC
    • LOCKs
    • Write Ahead Log
      • Espelhamento dos logs;
      • Arquivamento e Stand By;
      • Recuperação de instância;

• Perda de Dados e Disponibilidade;
  • Backup
    • Backup lógico;
    • Backup físico off-line;
    • Backup físico on-line;
      • Dificuldades com grandes bases;
    • Backup via Snapshot;
  • Técnicas de fail over
    • Hardware Redundante;
      • RAID
    • LVM e RAID por software;
    • Stand By;
    • Heart beat;
    • Replicação X Clusterização;
  • Replicação
    • Replicação Síncrona X Assíncrona;
    • Replicação Multi Master X Master/Slave
    • Replicação via log de transação;
    • Replicação via commit em duas fases;
    • Replicação via gatilhos;
    • Replicação via Midleware;
    • Implementações para PostgreSQL;
  • Cluster
    • Shared Nothing
    • Shared All
    • Implementações para PostgreSQL;
• Controle de Acesso
  • Política do Privilégio Mínimo;
  • SQL Injection;
  • Segurança na autenticação
    • Visões;
    • Funções;
    • Serviços de Diretório;
  • Ferramentas de controle no PostgreSQL;
    • GRANT / REVOKE
    • Roles
    • Limite de acesso aos recursos do servidor;
    • pg_hba.conf
    • SELinux
  • Estratégias de Autenticação da Aplicação;
    • Autenticação Interna;
      • Uso de grupos de usuários;
      • Impedindo os usuários de obterem acesso por fora da aplicação;
      • Lidando com senhas;
    • Autenticação Externa;
    • Autenticação via Aplicação;
      • Pool de Conexões;
• Auditoria
  • Auditoria dos dados:
    • Utilizando campos adicionais em tabelas já existentes;
    • Utilizando tabelas de autitorias alimentadas por RULEs e TRIGGERs;
    • Utilizando o log do PostgreSQL;
    • O problema da identificação do usuário em aplicações com Autenticação via Aplicação;
      • Criando uma variável de sessão;
    • Protetendo as informações de auditoria;
  • Monitorando o seu servidor:
    • Monitorando a disponibilidade;Monitorando a performance;
    • Monitorando o espaço em disco;
      • Dividir para melhor enchergar;
    • Disparando alertas;

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.