Post on 04-Jul-2015
description
por Fábio Telles26 de Setembro de 2008
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;
por Fábio Telles26 de Setembro de 2008
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 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;
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;
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;
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;
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;
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;
por Fábio Telles26 de Setembro de 2008
Preocupação com segurança hoje
●SarbanesOxley Act;● ITIL (ISO 20000);●COBIT;● ISO 27000;
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
por Fábio Telles26 de Setembro de 2008
Alta DisponibilidadeAgora 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 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 / masterslave;● Fail over;
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 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 Telles26 de Setembro de 2008
Backup
● Backup lógico;● Backup físico offline;● Backup físico online;● Snapshot;
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;
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;
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.
por Fábio Telles26 de Setembro de 2008
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 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
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;
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.
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;
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);
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, email, etc;● É mais complexo para ser configurado;
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;
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;
por Fábio Telles26 de Setembro de 2008
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 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.
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;
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;
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.
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;
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;
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;
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;
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. 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 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 email: fabio.telles@gmail.com