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 <adam...@gmail.com> escreveu: > Em 2 de março de 2011 17:36, Osvaldo Kussama > <osvaldo.kuss...@gmail.com> 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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
