PostgreSQL, o Elefante Encouraçado

3,480 views

Published on

Palestra sobre segurança no PostgreSQL realizada no PGCon Brasil 2008 em setembro de 2008

Published in: Technology

PostgreSQL, o Elefante Encouraçado

  1. 1. PostgreSQL O Elefante Encouraçado por Fábio Telles 26 de Setembro de 2008
  2. 2. Segurança? ● Indisponibilidade dos dados; ● Incapacidade de se recuperar de desastres; ● Acesso não autorizado; ● Alteração não autorizada ou corrompimento dos  dados; ● Anonimato nas transações, fraudes, etc; por Fábio Telles 26 de Setembro de 2008
  3. 3. Linha do Tempo ● 1941 – Z3 na Alemanha ● 1943 – Colossus na Inglaterra ● 1944 – Harvard Mark­1 nos USA ● 1945 – ENIAC nos USA ● 1951 – Ferranti Mark 1 ● 1951 – Whirlwind nos USA por Fábio Telles 26 de Setembro de 2008
  4. 4. Segurança Nacional ● Os computadores nascem como parte  de um esforço de guerra; ● A segurança e informação são valores  inseparáveis na informática; por Fábio Telles 26 de Setembro de 2008
  5. 5. 50's ● Uma tarefa por vez; ● Baixo poder de  processamento; ● Pouca memória; ● Cálculos científicos; por Fábio Telles 26 de Setembro de 2008
  6. 6. 60's e 70's ● Time sharing: um computador /  vários usuários via terminal burro; ● Autenticação de usuários no SO; ● Primeiras redes; ● Memória magnética; ● Primeiros bancos de dados; por Fábio Telles 26 de Setembro de 2008
  7. 7. 80's ● Microcomputadores; ● Primeiros bancos de dados pessoais; ● Disquetes e discos rígidos; ● Usenet, BBS, modems; ● DPLDPC; por Fábio Telles 26 de Setembro de 2008
  8. 8. 90's ● Cliente / Servidor; ● Serviços de Diretório (LDAP); ● Ethernet e Internet; ● RAID e SCSI; ● Bancos de dados relacionais; por Fábio Telles 26 de Setembro de 2008
  9. 9. Hoje ● Sistemas em 3 ou mais camadas; ● Virtualização; ● Memórias de estado sólido; ● Wireless; ● BI; por Fábio Telles 26 de Setembro de 2008
  10. 10. Preocupação com segurança hoje ● Sarbanes­Oxley Act; ● ITIL (ISO 20000); ● COBIT; ● ISO 27000; por Fábio Telles 26 de Setembro de 2008
  11. 11. Alta Disponibilidade Antes de qualquer coisa: ● Bom fornecimento de energia: ● Instalação elétrica dedicada e balanceada; ● Nobreaks redundantes com carga compatível e bateria não vencida; ● Geradores com carga compatível e contrato de manutenção; ● Bom acondicionamento: ● Ar condicionado suficiente e redundante; ● Boa acomodação (racks), bons gabinetes; ● Segurança contra incêndio e desastres naturais; ● Equipe: ● Monitoramento constante dos sistemas; ● Equipe disponível nos horários de operação; por Fábio Telles 26 de Setembro de 2008
  12. 12. Alta Disponibilidade Agora falando em servidores: ● Equipamentos de 1ª linha, c/ 3 ou mais anos de  garantia on­site e tempo de resposta bom; ● Fontes, ventoinhas, discos redundantes e Hot­ Swap; ● RAID 10 > RAID 0+1> RAID 6 > RAID 5 > s/  RAID > RAID 0; ● Fibre Channel > iSCSI; ● Ter peças sobressalentes, Hds Hot Spare,  Servidor de backup, site backup, etc. por Fábio Telles 26 de Setembro de 2008
  13. 13. Alta Disponibilidade Agora falando de Bancos de Dados: ● Cluster shared nothing; ● Cluster shared all; ● Replicação síncrona/ assíncrona; ● Replicação multimaster / master­slave; ● Fail over; por Fábio Telles 26 de Setembro de 2008
  14. 14. Alta Disponibilidade Agora falando em PostgreSQL: ● PL/Proxy (cluster shared nothing); ● PGCluster II (cluster shared all); ● Stand by (replicação master­slave assíncrona); ● Slony I (replicação master­slave assíncrona); ● PGCluster (replicação multimaster síncrona); ● PGPool (fail over + replicação); ● DRDB (replicação de sistema de arquivos); ● Heart Beat + discos compartilhados (fail over) por Fábio Telles 26 de Setembro de 2008
  15. 15. Backup ● Backup lógico; ● Backup físico off­line; ● Backup físico on­line; ● Snapshot; por Fábio Telles 26 de Setembro de 2008
  16. 16. Backup Lógico ● Ótimo para auditorias futuras; ● Ótimo para mover dados; ● Ótimo para alterações estruturais; ● Muito flexível; ● Ocupa pouco espaço (não inclui índices); ● Alto tempo para recuperação (criação de  índices e restrições); ● Uso do pg_dump, pg_restore e psql; por Fábio Telles 26 de Setembro de 2008
  17. 17. Backup Físico off-line ● Exige indisponibilidade do banco de dados; ● Volumoso (exige a cópia de todo o cluster); ● Pouco flexível (não permite edições); ● Recuperação rápida; ● Uso de ferramentas de cópia de arquivos do SO; por Fábio Telles 26 de Setembro de 2008
  18. 18. Backup Físico on-line ● Não exige indisponibilidade do banco de dados; ● Mais volumoso ainda (exige a cópia de todo o cluster e os  logs do WAL); ● Um pouco mais flexível (permite PITR); ● Recuperação um pouco menos rápida (exige recuperação  dos logs do WAL); ● Um pouco mais complexo: ● Uso de ferramentas de cópia de arquivos do SO; ● Uso do BEGIN BACKUP e END BAKCUP; ● Uso de arquivamento de logs do WAL. por Fábio Telles 26 de Setembro de 2008
  19. 19. Stand By = Backup off­line do banco + envio de logs do WAL Tipos de Stand By: ● Cold: Logs são aplicados apenas quando o Stand  By é ativado; ● Warm: Logs são aplicados continuamente, mas o  Stand By permanece em estado indisponível; ● Hot: Logs são aplicados continuamente no Stand  By que fica disponível para consultas; por Fábio Telles 26 de Setembro de 2008
  20. 20. Stand By Pontos críticos: ● Estabilidade da conexão entre os servidores; ● Período máximo entre os arquivamentos do WAL  (archive_timeout); ● Tamanho dos logs do WAL (definido na compilação); ● Volume de transações. Vantagens:  ● Baixo impacto no desempenho; ● Permite posicionar o Stand By a longas distâncias; ● Estabilidade e simplicidade; ● Área sofrendo contínuos melhoramentos no PostgreSQL por Fábio Telles 26 de Setembro de 2008
  21. 21. Stand By Desvantagens: ● A replicação sempre se aplica a todo o cluster; ● Hot Stand By ainda está em desenvolvimento; ● Hoje o Stand By é assíncrono: alterações  realizadas antes do último arquivamento do  WAL são perdidos; ● Replicação síncrona em desenvolvimento; ● Propaga erros dos usuários; ● Não substitui política de backup; por Fábio Telles 26 de Setembro de 2008
  22. 22. Melhorando a disponibilidade ● Crie partições separadas para o SO, Logs do SO e PostgreSQL,  WAL, tablespaces, etc; ● Separe arquivos de controle, configuração e WAL em discos  distintos dos tablespaces; ● Cheque com frequência os seus logs; ● Monitore o comportamento do seu servidor; ● Faça backup dos arquivos de configuração (postgresql.conf e  pghba.conf); ● Documente procedimentos de bakcup e recover; ● Teste várias vezes os procedimentos; ● Faça um teste de restore completo dos backups periodicamente. por Fábio Telles 26 de Setembro de 2008
  23. 23. Autenticando Aplicações no PostgreSQL ● Autenticação Interna: um usuário do PostgreSQL  por usuário da Aplicação; ● Autenticação Externa: um usuário do PostgreSQL  por usuário da Aplicação com autenticação externa  (LDAP, AD, Kerberos, etc); ● Autenticação via Aplicação: um usuário do  PostgreSQL para todos usuários da aplicação; por Fábio Telles 26 de Setembro de 2008
  24. 24. Autenticação Interna ● Auditoria consistente; ● Sempre use ROLEs para agrupar privilégios em objetos; ● DBA precisa criar usuários no banco de dados manualmente,  inclusive a senha inicial; ● Aplicação deve trocar senha do usuário na primeira vez em  que ele se conectar ; ● Um usuário e senha pode ser utilizado em várias aplicações no  mesmo cluster; ● Se a aplicação for Cliente/Servidor,  PostgreSQL não  consegue impedir o usuário de se conectar por fora da  aplicação (psql ou outros); por Fábio Telles 26 de Setembro de 2008
  25. 25. Autenticação Externa Tem as mesmas características da Autenticação  Interna com as seguintes diferenças: ● Administração de senhas fica a cargo do  Administrador de Sistemas; ● Se integra com os demais usuários da rede; ● Um usuário e senha pode ser utilizado para todas  aplicações, login no SO, e­mail, etc; ● É mais complexo para ser configurado; por Fábio Telles 26 de Setembro de 2008
  26. 26. Autenticação pela Aplicação ● Auditoria deve ser implementada pela aplicação; ● Cadastro de usuários, senhas e permissões é de inteira  responsabilidade da aplicação; ● Senha de acesso ao PostgreSQL deve ficar dentro da aplicação; ● O ROLE da aplicação nunca pode ser mesmo que o ROLE do  desenvolvedor ou o dono dos objetos da aplicação; por Fábio Telles 26 de Setembro de 2008
  27. 27. GRANT e REVOKE ● Para cada aplicação crie usuários (autenticação pela aplicação)  ou grupos de usuários (autenticação interna ou externa) com o  mínimo de privilégios para os seguintes perfis: ● DBAs; ● Desenvolvedores; ● Usuários da aplicação; ● Usuários administrativos da aplicação; ● Usuários especiais; por Fábio Telles 26 de Setembro de 2008
  28. 28. pg_hba.conf ● Use IDENT apenas para conexões locais; ● Use TRUST apenas para sistemas mono­usuários; ● Não use PASSWORD ou CRYPT; ● Limite a faixa de IPs aplicações cliente/servidor; ● Limite o IP do(s) servidor(es) de aplicação em aplicações  de N camadas; ● Proíba conexões remotas (local) se o servidor de aplicação  ficar junto do servidor de banco de dados; por Fábio Telles 26 de Setembro de 2008
  29. 29. pg_hba.conf ● Autenticação interna ou externa deve limitar os grupos de  usuários (ROLEs) utilizados por aplicação; ● Autenticação via aplicação devem limitar aos usuários  individuais utilizados pela aplicação; ● A autenticação externa não protege os dados, apenas a  autenticação; ● Use SSL (hostssl) para criptografar o envio de dados  sensíveis em ambiente client/server: ● Nunca use ALL, a não ser para o REJECT. por Fábio Telles 26 de Setembro de 2008
  30. 30. Controle avançado: visões ● O PostgreSQL não tem GRANT e REVOKE no nível de  colunas.... e seria muito chato usar isso! ● Crie visões contendo apenas os campos que o usuário da  aplicação deve acessar; ● De permissão para o usuário acessar a visão; ● Revogue a permissão do usuário para acessar a tabela de  origem; por Fábio Telles 26 de Setembro de 2008
  31. 31. Controle avançado: funções ● Você pode limitar o acesso a registros de uma tabela fazendo  com que uma função retorne apenas as linhas que o usuário  teria permissão: ● Função detecta qual usuário está conectado na sessão e  utiliza o nome do usuário como parâmetro numa cláusula  WHERE ● Você pode encapsular várias etapas de uma transação em  uma função que recebe parâmetros: ● Função faz as operações de UPDATE, INSERT e  DELETE sem o usuário ter permissões diretas nas tabelas; por Fábio Telles 26 de Setembro de 2008
  32. 32. Aumentando a segurança ●  Utilizar no mínimo um tablespace para índices e um para  tabelas; ● Utilize um esquema separado por aplicação; ● Não utilize o esquema public a não ser que os dados lá sejam  realmente públicos; ● Aplique as correções de segurança do seu SO, do PostgreSQL e  demais aplicações com freqüência; ● Use as ferramentas de criptografia do PostgreSQL no contrib; ● Se preocupe com a segurança além do banco de dados:  aplicação, usuários, email, documentos impressos são os  melhores alvos para ataques internos e externos. por Fábio Telles 26 de Setembro de 2008
  33. 33. SE PostgreSQL ● Só roda em Linux ● Realiza o controle de acesso no nível dos arquivos de  dados; ● Exige mais trabalho na implementação; ● Depende da criação de contextos para os dados; ● Muito flexível: ● Permite criar contexto para registros específicos; ● Permite criar contexto para campos específicos; ● Permite a criação de contextos usando SQL; por Fábio Telles 26 de Setembro de 2008
  34. 34. Boa Modelagem = Dados Saudaveis ● Você conhece um bom motivo para não usar chaves primarias? ● Use todas as restrições naturais do banco exaustivamente: PK,  FK, UK, CHECK; ● Use DOMAINs ● Use valores padrão; ● Normalize a base e entenda definitivamente como o NULL  funciona; ● Se tiver que usar chaves artificiais, use sequências; ● Use gatilhos e funções para impor restrições de negócio  avançadas; ● Comentários e documentação nunca são demais; por Fábio Telles 26 de Setembro de 2008
  35. 35. Segurança na aplicação ● Use transações explícitas com BEGIN, COMMIT e  ROLLBACK; ● Use Dollar Quoting ($$). Se não usar, escape as aspas simples; ● Use desconexão automática por ociosidade; ● Use de tratamento de erros especial para erros de violação de  restrições de integridade; ● Nunca usar o dono dos objetos para se conectar pela aplicação; ● Nunca exiba mensagens de erro do banco na tela do usuário; ● Nunca confie em conversões implícitas de tipo de dados; por Fábio Telles 26 de Setembro de 2008
  36. 36. Auditoria ● Usando o WAL: volume absurdo de dados gerados, engloba  todo o cluster; ● Usando logs: volume absurdo de dados gerados, engloba todo o  cluster e tem alto custo; ● Guardando dados na própria tabela:  ● Valores padrão podem ser gerados quando um registro é  criado; ● Operações de UPDATE e DELETE exigem o uso de um  gatilho; ● Guardando dados em uma tabela a parte a partir de gatilhos; por Fábio Telles 26 de Setembro de 2008
  37. 37. Lembre-se ● Defina por escrito qual é o seu SLA; ● Crie métodos para checar se você está seguindo o seu SLA; ● O cofre não pode ser mais caro que o conteúdo a ser guardado; ● Não troque segurança por desempenho sem ter certeza dos riscos  que vai correr; ● Documentação é fundamental para a segurança. Atualiza­la  também; ● Um DBA que trabalha com muito sono está apto a cometer  atrocidades irreversíveis;  ● A preguiça é o inimigo número um da segurança; ● A ignorância é o inimigo número dois! por Fábio Telles 26 de Setembro de 2008
  38. 38. OBRIGADO Dúvidas, sugestões, correções, indignações e  cervejas são bem vindas! Fábio Telles Rodriguez SAVEPOINT: http://www.midstorm.org/~telles  e­mail: fabio.telles@gmail.com por Fábio Telles 26 de Setembro de 2008

×