Autenticação no PostgreSQL - com exemplos

fdmarp

Apesar de ser de simples configuração, noto diversas vezes em fóruns dúvidas sobre o pg_hba.conf, que é o principal arquivo de controle de autenticação de usuários no servidor. Este texto dá uma introdução dos parâmetros e passa para a prática uma configuração passo a passo.

[ Hits: 60.494 ]

Por: DAVISON MARCEL PASQUALINI em 08/10/2009

0 0

Denuncie Favoritos Indicar Impressora

Exemplos

Vamos montar então um pg_hba.conf aceitável:

1) Para não guardar a senha do postgres em um .pg_pass, sem criptografia etc, você pode usar:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         postgres                          ident sameuser

Liberamos o usuário postgres desde que ele seja o postgres no sistema operacional, neste caso scripts na CRON deste usuário vão funcionar belezinha.

Ou mesmo:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                               ident sameuser

Todos os usuários localmente serão "ident sameuser", ou seja, o usuário do sistema operacional irá para o banco (opcionalmente usando map).

2) Liberar interface do loop back

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                               ident sameuser
host    all         all          127.0.0.1/32         md5

Ou "ident sameuser" caso necessite utilizar o pg_admin ou outra aplicação que estabeleça um socket local.

3) Liberar acesso para os servidores de aplicação:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                               ident sameuser
host    all         all          127.0.0.1/32         md5
host    banco1      aplicacao1   192.160.50.22/32     md5

Libera conexão TCP/IP para o usuário da aplicação, do IP do servidor e apenas para o seu banco. Legal se conseguir passar a senha via MD5, caso contrário use o ident e em último caso o trust.

4) Liberar para a subrede de estações de trabalho dos DBAs:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                               ident sameuser
host    all         all          127.0.0.1/32         md5
host    banco1      aplicacao1   192.160.50.22/32     md5
host    all         +admins      192.160.55.0/24      md5

Liberamos aqui o acesso para a sub-rede 192.160.55.*** para os usuários cadastrados no grupo admins.

5) Excluir uma máquina que está no range, mas é de desenvolvimento, por exemplo:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                               ident sameuser
host    all         all          127.0.0.1/32         md5
host    banco1      aplicacao1   192.160.50.22/32     md5
host    all         all          192.160.55.12/32     reject
host    all         +admins      192.160.55.0/24      md5

Isso mesmo, colocar o reject antes da liberação, isso é muito importante. Lembre-se do que eu disse, primeiro feche as portas e depois vá liberando aos poucos, pois uma vez autorizado, não adianta nada o que dizem os próximos registros.

Lembrando que a configuração acima também pode ser representada assim:

# TYPE  DATABASE    USER        IP                  MASK                    METHOD
local   all         all                                                     ident sameuser
host    all         all          127.0.0.1          255.255.255.255         md5
host    banco1      aplicacao1   192.160.50.22      255.255.255.255         md5
host    banco1      aplicacao1   192.160.55.12      255.255.255.255         reject
host    all         +admins      192.160.55.0       255.255.255.0           md5

Simples!? Isso mesmo, simples... e é ai que mora a beleza.

Liberamos o acesso local para os usuários conforme sua autenticação no SO (scripts na crontab funcionarão sem problemas, inclusive os agendados para manutenção com user postgres).

Liberamos também a interface loop back, desde que o usuário digite sua senha. A aplicação informa o password para conectar ao banco e só pode fazê-lo do servidor especificado (se mudar para ident, você deve confiar na segurança do servidor de aplicação).

Por fim liberamos um range de IPs de onde nossos DBAs poderão efetuar seu logon e proibimos um endereço indesejado.

O resto automaticamente será negado, não tem mistérios.

Existem adeptos que dizem que é mais fácil ser menos exigente nesta etapa e cercar o ajuste fino das permissões, nos GRANT fornecidos. Não deixa de ser uma opção e até que não é ruim, mas é uma camada de segurança extra da qual você está abrindo mão, por isso, particularmente, acho que vale a pena gastar um tempinho aqui sim.

Página anterior

Páginas do artigo

   1. Introdução
   2. Campos dos registros
   3. Exemplos

Outros artigos deste autor

Nenhum artigo encontrado.

Leitura recomendada

Vacuum - otimizando sua base de dados PostgreSQL

Replicando banco de dados PostgreSQL

Replicação de dados síncrona com Postgres

PostGIS no Slackware

Pool de Conexões Transparentes no Postgres usando o pgpool

Comentários

[1] Comentário enviado por wryel em 09/10/2009 - 11:01h

Rapaz, obrigado por compartilhar estas informações!
Com a bagunça e incertezas que anda em volta do Mysql, de uns tempos para cá, acho que o postgre vai ganhar cada vez mais usuários dele :P

0 0

[2] Comentário enviado por fdmarp em 13/10/2009 - 13:20h

Valeu pela visita wryel.
Concordo plenamente ... e sabe, tenho usado o postgres e ele tem atendido bem nossas espectativas. Um dos maiores problemas é a quantidade de pessoas que lidam com ele. Quer dizer, problemas do ponto de vista de empresa, do ponto de vista técnico ... é uma oportunidade e tanto.

0 0