PostgreSQL, o Elefante Encouraçado
Upcoming SlideShare
Loading in...5
×
 

PostgreSQL, o Elefante Encouraçado

on

  • 4,745 views

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

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

Statistics

Views

Total Views
4,745
Views on SlideShare
4,543
Embed Views
202

Actions

Likes
4
Downloads
111
Comments
0

3 Embeds 202

http://www.midstorm.org 173
http://www.slideshare.net 21
http://www.infoblogs.com.br 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

PostgreSQL, o Elefante Encouraçado PostgreSQL, o Elefante Encouraçado Presentation Transcript

  • PostgreSQL O Elefante Encouraçado por Fábio Telles 26 de Setembro de 2008
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Preocupação com segurança hoje ● Sarbanes­Oxley Act; ● ITIL (ISO 20000); ● COBIT; ● ISO 27000; por Fábio Telles 26 de Setembro de 2008
  • 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
  • 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
  • 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
  • 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
  • Backup ● Backup lógico; ● Backup físico off­line; ● Backup físico on­line; ● Snapshot; por Fábio Telles 26 de Setembro de 2008
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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