PostgreSQL, o Elefante Encouraçado

67 %
33 %
Information about PostgreSQL, o Elefante Encouraçado
Technology

Published on November 15, 2008

Author: telles

Source: slideshare.net

Description

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

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

Add a comment

Related presentations

Related pages

PostgreSQL: The world's most advanced open source database

The official site for PostgreSQL, the world's most advanced open source database
Read more

PGBR | Comunidade Brasileira de PostgreSQL

PostgreSQL o Elefante Encouraçado por Fábio Telles ; Consultas aproximadas no PostgreSQL por Euler Taveira ; Replicação Síncrona — "Não existe ...
Read more

PostgreSQL – Wikipedia

PostgreSQL (englisch ... Apple liefert seit der Version Mac OS X Lion („Lion“) PostgreSQL als Standarddatenbank aus. ... PostgreSQL – Ein Elephant ...
Read more

Planet PostgreSQL

Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org. ... the recovery is not free (both in terms of CPU and I/O), ...
Read more

Comunidade Brasileira de PostgreSQL - eventos

O que é? Postgres ou PostgreSQL é um projeto de Sistema Gerenciador de Banco de Dados open-source que foi iniciado em 1986, na Universidade de Berkeley ...
Read more

O elefante sem tromba - Technology

O ELEFANTE SEM TROMBA 2. Um elefante tinha o péssimo costume de botar a tromba onde não era chamado: ... PostgreSQL, o Elefante Encouraçado
Read more

PostgreSQL - Wikipedia, the free encyclopedia

PostgreSQL; Developer(s) PostgreSQL Global Development Group: ... On OS X, PostgreSQL has been the default database starting with Mac OS X 10.7 Lion Server
Read more

Elefante – Wikipédia, a enciclopédia livre

Os elefantes têm, geralmente, cor acinzentada, ... O logotipo do PostgreSQL, gerenciador de banco de dados livre, é a cabeça de um elefante.
Read more