Daniel !!!

Isso dá um filme heim, rsrsrs


Marcelo Silva
----------------------------------


From: Daniel Caña 
Sent: Thursday, March 03, 2011 9:02 AM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral]Como evitar autenticação "trust"?

Buenas!

Só pra complementar, o acesso Trust é extremamente necessário para evitar que 
um banco de dados se perca, por exemplo, quando um 'DBA' tenta agir de má fé. 
Vou usar um cenário mirabolante como exemplo:

- Um 'DBA', descontente com o salário que ganha, decide usar um 'artifício' 
para aumentar sua credibilidade e remuneração. Faz um dump na tabela de 
usuários, guarda o dump com ele e cria uma função que detona os dados de 
usuários (menos o seu acesso) disparada por uma rotina no SO. 
- Daí pede pra sair dizendo que recebeu uma proposta melhor. Independente do 
que o dono ofereça como contra-proposta para mantê-lo, sai da empresa, pois 
sabe que a armadilha está montada, sem deixar a senha administrativa de acesso. 
Em princípio, ninguém percebe nada, pois os acessos ao banco e seus dados 
continuam normalmente. De repente, boom! Fim do acesso ao banco. 
- A empresa tenta ligar pro ex-'DBA' que nega o auxílio e afirma que qualquer 
outro DBA poderá resolver o caso em poucas horas. Tentam chamar outro DBA, mas 
este sem acesso administrativo ao banco, nada pode fazer. Mesmo que liguem pro 
'DBA', ele pode fornecer qualquer senha como sendo a de admin que não irá 
funcionar, camuflando assim sua falcatrua.
- Novamente a empresa liga (já em desespero) pro 'DBA' e este vai, resolve o 
problema em algumas horas (diria minutos, afinal, ele sabe exatamente o que 
fazer), deixa todo mundo na empresa feliz e contente, porém deixa uma nova 
bomba similar por garantia, ficando assim com status de FODÃO, pois qualquer 
outro DBA chamado não teria como resolver o problema. 
- Ao se encontrar com o dono, que vem agradecer, diz que gostaria de ter 
permanecido na empresa, mas que o salário estava muito aquem de seu 
conhecimento. Se o dono não cair, a nova bomba já está armada pra uma nova 
tentativa. Do contrário, pede o que quiser (acima da contra-proposta citada 
anteriormente) e certamente será contemplado, afinal, dados são o coração do 
negócio.

Com o acesso Trust, qualquer DBA legítimo pode interromper essa falcatrua ao 
afirmar que a tabela de usuários foi deletada propositalmente, restauraria a 
mesma e eliminaria qualquer rotina mal intencionada que estivesse no SO.

Eu sei que isso é um caso fictício (e seria uma abominação) mas sem o acesso 
Trust seria um cenário completamente possível.

Abraços,

Daniel Caña


Em 2 de março de 2011 19:05, Tiago Adami <[email protected]> escreveu:

  Em 2 de março de 2011 17:36, Osvaldo Kussama
  <[email protected]> escreveu:

  >
  > Repare que o usuário com poderes de super-usuário pode modificar o
  > local do arquivo pg_hba.conf [1], dar um restart do PostgreSQL e dessa
  > forma liberar qualquer tipo de acesso.
  >
  > Creio que a grande falha de segurança é a existência, indevida, de
  > usuários com poderes que não deveriam ter. Se você deu a chave de sua
  > casa a um ladrão então não pode reclamar de ter sido roubado.
  >
  > Osvaldo
  >
  > [1] 
http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html
  >


  A segurança do banco de dados se baseia em 2 práticas impreteríveis:
  1) não dar acesso de root a quem não merece; 2) restringir o acesso ao
  servidor físico (isso mesmo ao hardware) somente aos administradores.

  Certa vez eu não tinha acesso aos arquivos de configuração do servidor
  em um cliente. Mas tinha acesso ao servidor físico. Mudei alguns
  parâmetros no GRUB [1], e... Voilá! Consegui alterar a senha do root.

  Só para que fique registrado: outros SGBDs utilizam os protocolos de
  segurança (por assim se dizer) do sistema operacional, como o IBM DB2.
  Tendo a senha do "root" ou "administrator", você toma conta de tudo.

  [1] http://www.debuntu.org/recover-root-password-single-user-mode-and-grub


  --
  TIAGO J. ADAMI
  http://www.adamiworks.com





--------------------------------------------------------------------------------
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a