Transcript
Page 1: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

PostgreSQL

O Elefante Encouraçado

Page 2: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 3: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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

Page 4: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 5: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

50's

●Uma tarefa por vez;●Baixo poder de processamento;

●Pouca memória;●Cálculos científicos;

Page 6: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 7: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

80's

●Microcomputadores;●Primeiros bancos de dados pessoais;●Disquetes e discos rígidos;●Usenet, BBS, modems;●DPLDPC;

Page 8: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

90's

●Cliente / Servidor;●Serviços de Diretório (LDAP);●Ethernet e Internet;●RAID e SCSI;●Bancos de dados relacionais;

Page 9: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

Hoje

●Sistemas em 3 ou mais camadas;●Virtualização;●Memórias de estado sólido;●Wireless;●BI;

Page 10: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

Preocupação com segurança hoje

●Sarbanes­Oxley Act;● ITIL (ISO 20000);●COBIT;● ISO 27000;

Page 11: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

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;

Alta Disponibilidade

Page 12: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

Alta DisponibilidadeAgora 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.

Page 13: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 14: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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)

Page 15: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

Backup

● Backup lógico;● Backup físico off­line;● Backup físico on­line;● Snapshot;

Page 16: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 17: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 18: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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.

Page 19: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 20: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 de Setembro de 2008

Stand ByPontos 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

Page 21: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 22: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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.

Page 23: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 24: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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);

Page 25: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 26: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 27: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 28: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 29: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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.

Page 30: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 31: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 32: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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.

Page 33: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 34: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 35: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 36: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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;

Page 37: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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!

Page 38: PostgreSQL, o Elefante Encouraçado

por Fábio Telles26 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: [email protected]