PostgreSQL, o Elefante Encouraçado

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

Linha do Tempo

● 1941 – Z3 na Alemanha
● 1943 – Colossus na Inglaterra

● 1944 – Harvard Mark1 nos USA

● 1945 – ENIAC nos USA

● 1951 – Ferranti Mark 1

● 1951 – Whirlwind nos USA

por Fábio Telles

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

50's

● Uma tarefa por vez;
● Baixo poder de

processamento;
● Pouca memória;

● Cálculos científicos;

por Fábio Telles

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

80's

● Microcomputadores;
● Primeiros bancos de dados pessoais;

● Disquetes e discos rígidos;

● Usenet, BBS, modems;

● DPLDPC;

por Fábio Telles

90's

● Cliente / Servidor;
● Serviços de Diretório (LDAP);

● Ethernet e Internet;

● RAID e SCSI;

● Bancos de dados relacionais;

por Fábio Telles

Hoje
● Sistemas em 3 ou mais camadas;
● Virtualização;

● Memórias de estado sólido;

● Wireless;

● BI;

por Fábio Telles

Preocupação com
segurança hoje
● SarbanesOxley Act;
● ITIL (ISO 20000);

● COBIT;

● ISO 27000;

por Fábio Telles

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

Agora falando em servidores:
● Equipamentos de 1ª linha, c/ 3 ou mais anos de

garantia onsite 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


Agora falando de Bancos de Dados:
● Cluster shared nothing;

● Cluster shared all;

● Replicação síncrona/ assíncrona;

● Replicação multimaster / masterslave;

● Fail over;

por Fábio Telles

Agora falando em PostgreSQL:
● PL/Proxy (cluster shared nothing);

● PGCluster II (cluster shared all);

● Stand by (replicação masterslave assíncrona);

● Slony I (replicação masterslave 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

Backup

● Backup lógico;
● Backup físico offline;

● Backup físico online;

● Snapshot;

por Fábio Telles

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

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

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

Stand By
= Backup offline 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

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

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

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

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

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

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, email, etc;
● É mais complexo para ser configurado;

por Fábio Telles

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

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

pg_hba.conf

● Use IDENT apenas para conexões locais;
● Use TRUST apenas para sistemas monousuá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

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

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

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

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

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

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

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

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

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. Atualizala

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

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
email: fabio.telles@gmail.com

por Fábio Telles

PostgreSQL, o Elefante Encouraçado

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a PostgreSQL, o Elefante Encouraçado

Semelhante a PostgreSQL, o Elefante Encouraçado (20)

Mais de Fabio Telles Rodriguez

Mais de Fabio Telles Rodriguez (20)

Último

Último (6)

PostgreSQL, o Elefante Encouraçado