SlideShare uma empresa Scribd logo
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

Mais conteúdo relacionado

Semelhante a PostgreSQL, o Elefante Encouraçado

Fazendo uma manada de elefantes passar por baixo da porta
Fazendo uma manada de elefantes passar por baixo da portaFazendo uma manada de elefantes passar por baixo da porta
Fazendo uma manada de elefantes passar por baixo da porta
Fabio Telles Rodriguez
 
2019 - Natura MeetUp - Journey to Cloud and Relational Databases
2019 - Natura MeetUp - Journey to Cloud and Relational Databases2019 - Natura MeetUp - Journey to Cloud and Relational Databases
2019 - Natura MeetUp - Journey to Cloud and Relational Databases
Marcus Vinicius Miguel Pedro
 
Planejamento de Capacidade e Desempenho de Backup em Disco
Planejamento de Capacidade e Desempenho de Backup em DiscoPlanejamento de Capacidade e Desempenho de Backup em Disco
Planejamento de Capacidade e Desempenho de Backup em Disco
Kleber Silva
 
Avaliação de arquiteturas de uma solução de backup da nuvem
Avaliação de arquiteturas de uma solução de backup da nuvemAvaliação de arquiteturas de uma solução de backup da nuvem
Avaliação de arquiteturas de uma solução de backup da nuvem
Joao Galdino Mello de Souza
 
Desenvolvendo aplicativos web escaláveis
Desenvolvendo aplicativos web escaláveisDesenvolvendo aplicativos web escaláveis
Desenvolvendo aplicativos web escaláveis
Manuel Lemos
 
High Avaiability Architeture with Oracle Data Guard Broker
High Avaiability Architeture with Oracle Data Guard BrokerHigh Avaiability Architeture with Oracle Data Guard Broker
High Avaiability Architeture with Oracle Data Guard Broker
Jonatan Ritter
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardo
Fabio Telles Rodriguez
 
TDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload Analítico
TDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload AnalíticoTDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload Analítico
TDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload Analítico
tdc-globalcode
 
SQLSat #127
SQLSat #127SQLSat #127
SQLSat #127
Felipe Ferreira
 
TechEd_OFC302
TechEd_OFC302TechEd_OFC302
TechEd_OFC302
Rodolfo Roim
 
MySQL Cluster - visão geral
MySQL Cluster - visão geralMySQL Cluster - visão geral
MySQL Cluster - visão geral
MySQL Brasil
 
Percona XtraBackup
Percona XtraBackupPercona XtraBackup
Percona XtraBackup
Webgoal
 
L'esprit de l'escalier
L'esprit de l'escalierL'esprit de l'escalier
L'esprit de l'escalier
Gleicon Moraes
 
Mulesoft Meetup Latam Summit Brazil
Mulesoft Meetup Latam Summit BrazilMulesoft Meetup Latam Summit Brazil
Mulesoft Meetup Latam Summit Brazil
Guilherme Pereira Silva
 
Plone na nuvem
Plone na nuvemPlone na nuvem
Plone na nuvem
Fabiano Weimar
 
Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.
Thiago Rondon
 
Avaliação de arquiteturas de uma solução de Backup na Nuvem
Avaliação de arquiteturas de uma solução de Backup na NuvemAvaliação de arquiteturas de uma solução de Backup na Nuvem
Avaliação de arquiteturas de uma solução de Backup na Nuvem
Kleber Silva
 
MySQL Cluster - visão geral
MySQL Cluster - visão geralMySQL Cluster - visão geral
MySQL Cluster - visão geral
MySQL Brasil
 
Loren COmpass Computer Of day member political network datastore
Loren COmpass Computer Of day member political network datastoreLoren COmpass Computer Of day member political network datastore
Loren COmpass Computer Of day member political network datastore
edgararrais8
 
Gerenciamento de Backup e Recovery com o Barman
Gerenciamento de Backup e Recovery com o BarmanGerenciamento de Backup e Recovery com o Barman
Gerenciamento de Backup e Recovery com o Barman
Caio Oliveira
 

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

Fazendo uma manada de elefantes passar por baixo da porta
Fazendo uma manada de elefantes passar por baixo da portaFazendo uma manada de elefantes passar por baixo da porta
Fazendo uma manada de elefantes passar por baixo da porta
 
2019 - Natura MeetUp - Journey to Cloud and Relational Databases
2019 - Natura MeetUp - Journey to Cloud and Relational Databases2019 - Natura MeetUp - Journey to Cloud and Relational Databases
2019 - Natura MeetUp - Journey to Cloud and Relational Databases
 
Planejamento de Capacidade e Desempenho de Backup em Disco
Planejamento de Capacidade e Desempenho de Backup em DiscoPlanejamento de Capacidade e Desempenho de Backup em Disco
Planejamento de Capacidade e Desempenho de Backup em Disco
 
Avaliação de arquiteturas de uma solução de backup da nuvem
Avaliação de arquiteturas de uma solução de backup da nuvemAvaliação de arquiteturas de uma solução de backup da nuvem
Avaliação de arquiteturas de uma solução de backup da nuvem
 
Desenvolvendo aplicativos web escaláveis
Desenvolvendo aplicativos web escaláveisDesenvolvendo aplicativos web escaláveis
Desenvolvendo aplicativos web escaláveis
 
High Avaiability Architeture with Oracle Data Guard Broker
High Avaiability Architeture with Oracle Data Guard BrokerHigh Avaiability Architeture with Oracle Data Guard Broker
High Avaiability Architeture with Oracle Data Guard Broker
 
PostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardoPostgreSQL Tuning: O elefante mais rápido que um leopardo
PostgreSQL Tuning: O elefante mais rápido que um leopardo
 
TDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload Analítico
TDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload AnalíticoTDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload Analítico
TDC2017 | POA Trilha BigData - Utilizando o Apache Kudu como Workload Analítico
 
SQLSat #127
SQLSat #127SQLSat #127
SQLSat #127
 
TechEd_OFC302
TechEd_OFC302TechEd_OFC302
TechEd_OFC302
 
MySQL Cluster - visão geral
MySQL Cluster - visão geralMySQL Cluster - visão geral
MySQL Cluster - visão geral
 
Percona XtraBackup
Percona XtraBackupPercona XtraBackup
Percona XtraBackup
 
L'esprit de l'escalier
L'esprit de l'escalierL'esprit de l'escalier
L'esprit de l'escalier
 
Mulesoft Meetup Latam Summit Brazil
Mulesoft Meetup Latam Summit BrazilMulesoft Meetup Latam Summit Brazil
Mulesoft Meetup Latam Summit Brazil
 
Plone na nuvem
Plone na nuvemPlone na nuvem
Plone na nuvem
 
Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.Cache, Concorrência e Sincronização.
Cache, Concorrência e Sincronização.
 
Avaliação de arquiteturas de uma solução de Backup na Nuvem
Avaliação de arquiteturas de uma solução de Backup na NuvemAvaliação de arquiteturas de uma solução de Backup na Nuvem
Avaliação de arquiteturas de uma solução de Backup na Nuvem
 
MySQL Cluster - visão geral
MySQL Cluster - visão geralMySQL Cluster - visão geral
MySQL Cluster - visão geral
 
Loren COmpass Computer Of day member political network datastore
Loren COmpass Computer Of day member political network datastoreLoren COmpass Computer Of day member political network datastore
Loren COmpass Computer Of day member political network datastore
 
Gerenciamento de Backup e Recovery com o Barman
Gerenciamento de Backup e Recovery com o BarmanGerenciamento de Backup e Recovery com o Barman
Gerenciamento de Backup e Recovery com o Barman
 

Mais de Fabio Telles Rodriguez

Data Hero: Sua carreira na área de dados
Data Hero: Sua carreira na área de dadosData Hero: Sua carreira na área de dados
Data Hero: Sua carreira na área de dados
Fabio Telles Rodriguez
 
Postgres level up
Postgres level upPostgres level up
Postgres level up
Fabio Telles Rodriguez
 
Explain this!
Explain this!Explain this!
Explain this!
Fabio Telles Rodriguez
 
High concurrency with Postgres
High concurrency with PostgresHigh concurrency with Postgres
High concurrency with Postgres
Fabio Telles Rodriguez
 
Aplicações 10x a 100x mais rápida com o postgre sql
Aplicações 10x a 100x mais rápida com o postgre sqlAplicações 10x a 100x mais rápida com o postgre sql
Aplicações 10x a 100x mais rápida com o postgre sql
Fabio Telles Rodriguez
 
Novidades do PostgreSQL 10
Novidades do  PostgreSQL 10Novidades do  PostgreSQL 10
Novidades do PostgreSQL 10
Fabio Telles Rodriguez
 
Migre seu banco de dados para a nuvem. Pergunte-me como!
Migre seu banco de dados para a nuvem. Pergunte-me como!Migre seu banco de dados para a nuvem. Pergunte-me como!
Migre seu banco de dados para a nuvem. Pergunte-me como!
Fabio Telles Rodriguez
 
Trabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQLTrabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQL
Fabio Telles Rodriguez
 
PostgreSQL Rock Star
PostgreSQL Rock StarPostgreSQL Rock Star
PostgreSQL Rock Star
Fabio Telles Rodriguez
 
Oracle x PostgreSQL
Oracle x PostgreSQLOracle x PostgreSQL
Oracle x PostgreSQL
Fabio Telles Rodriguez
 
PostgreSQL Wonderland TDC-SP 2015
PostgreSQL Wonderland TDC-SP 2015PostgreSQL Wonderland TDC-SP 2015
PostgreSQL Wonderland TDC-SP 2015
Fabio Telles Rodriguez
 
Trabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQLTrabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQL
Fabio Telles Rodriguez
 
Postgres Big data
Postgres Big dataPostgres Big data
Postgres Big data
Fabio Telles Rodriguez
 
Postgres Chainsaw Massacre
Postgres Chainsaw MassacrePostgres Chainsaw Massacre
Postgres Chainsaw Massacre
Fabio Telles Rodriguez
 
Postgres Tuning
Postgres TuningPostgres Tuning
Postgres Tuning
Fabio Telles Rodriguez
 
Postgres Wonderland - PGDay CE2013
Postgres  Wonderland - PGDay CE2013Postgres  Wonderland - PGDay CE2013
Postgres Wonderland - PGDay CE2013
Fabio Telles Rodriguez
 
Postgres Wonderland - Campus Party 2013
Postgres Wonderland - Campus Party 2013Postgres Wonderland - Campus Party 2013
Postgres Wonderland - Campus Party 2013
Fabio Telles Rodriguez
 
Alta Concorrência com Postgres
Alta Concorrência com PostgresAlta Concorrência com Postgres
Alta Concorrência com Postgres
Fabio Telles Rodriguez
 
Alta Concorrência com Postgres
Alta Concorrência com PostgresAlta Concorrência com Postgres
Alta Concorrência com Postgres
Fabio Telles Rodriguez
 
Postgres, a "Metamorfose Ambulante"
Postgres, a "Metamorfose Ambulante"Postgres, a "Metamorfose Ambulante"
Postgres, a "Metamorfose Ambulante"
Fabio Telles Rodriguez
 

Mais de Fabio Telles Rodriguez (20)

Data Hero: Sua carreira na área de dados
Data Hero: Sua carreira na área de dadosData Hero: Sua carreira na área de dados
Data Hero: Sua carreira na área de dados
 
Postgres level up
Postgres level upPostgres level up
Postgres level up
 
Explain this!
Explain this!Explain this!
Explain this!
 
High concurrency with Postgres
High concurrency with PostgresHigh concurrency with Postgres
High concurrency with Postgres
 
Aplicações 10x a 100x mais rápida com o postgre sql
Aplicações 10x a 100x mais rápida com o postgre sqlAplicações 10x a 100x mais rápida com o postgre sql
Aplicações 10x a 100x mais rápida com o postgre sql
 
Novidades do PostgreSQL 10
Novidades do  PostgreSQL 10Novidades do  PostgreSQL 10
Novidades do PostgreSQL 10
 
Migre seu banco de dados para a nuvem. Pergunte-me como!
Migre seu banco de dados para a nuvem. Pergunte-me como!Migre seu banco de dados para a nuvem. Pergunte-me como!
Migre seu banco de dados para a nuvem. Pergunte-me como!
 
Trabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQLTrabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQL
 
PostgreSQL Rock Star
PostgreSQL Rock StarPostgreSQL Rock Star
PostgreSQL Rock Star
 
Oracle x PostgreSQL
Oracle x PostgreSQLOracle x PostgreSQL
Oracle x PostgreSQL
 
PostgreSQL Wonderland TDC-SP 2015
PostgreSQL Wonderland TDC-SP 2015PostgreSQL Wonderland TDC-SP 2015
PostgreSQL Wonderland TDC-SP 2015
 
Trabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQLTrabalhando com Logs no PostgreSQL
Trabalhando com Logs no PostgreSQL
 
Postgres Big data
Postgres Big dataPostgres Big data
Postgres Big data
 
Postgres Chainsaw Massacre
Postgres Chainsaw MassacrePostgres Chainsaw Massacre
Postgres Chainsaw Massacre
 
Postgres Tuning
Postgres TuningPostgres Tuning
Postgres Tuning
 
Postgres Wonderland - PGDay CE2013
Postgres  Wonderland - PGDay CE2013Postgres  Wonderland - PGDay CE2013
Postgres Wonderland - PGDay CE2013
 
Postgres Wonderland - Campus Party 2013
Postgres Wonderland - Campus Party 2013Postgres Wonderland - Campus Party 2013
Postgres Wonderland - Campus Party 2013
 
Alta Concorrência com Postgres
Alta Concorrência com PostgresAlta Concorrência com Postgres
Alta Concorrência com Postgres
 
Alta Concorrência com Postgres
Alta Concorrência com PostgresAlta Concorrência com Postgres
Alta Concorrência com Postgres
 
Postgres, a "Metamorfose Ambulante"
Postgres, a "Metamorfose Ambulante"Postgres, a "Metamorfose Ambulante"
Postgres, a "Metamorfose Ambulante"
 

PostgreSQL, o Elefante Encouraçado

  • 1. PostgreSQL O Elefante Encouraçado por Fábio Telles 26 de Setembro de 2008
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. Preocupação com segurança hoje ● Sarbanes­Oxley Act; ● ITIL (ISO 20000); ● COBIT; ● ISO 27000; por Fábio Telles 26 de Setembro de 2008
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. Backup ● Backup lógico; ● Backup físico off­line; ● Backup físico on­line; ● Snapshot; por Fábio Telles 26 de Setembro de 2008
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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