O formato básico do registro, como está descrito no próprio pg_hba.conf, possui os campos TYPE, DATABASE, USER, CIDR-ADDRESS e METHOD.

# TYPE
#---------------------------

O primeiro parâmetro diz respeito ao tipo de conexão ao que a regra será aplicada: local, host, hostssl e hostnossl.

• local - difícil encontrar o que dizer deste tipo, pois o nome diz tudo; a documentação oficial diz que trata de conexões via socket domain, eu diria, para simplificar, que trata de conexões locais mesmo e que sem um registro destes não há como se conectar localmente. Claro que alguns diriam que podemos formar uma conexão TCP/IP com o próprio servidor, o que é verdade, mas foge do conceito de local.
• host - refere-se às conexões efetivadas via TCP/IP, independentemente se elas são SSL ou não. Aqui cabe uma ressalva, que é feita até na documentação oficial, mas nunca é demais lembrar, que para que o banco de dados aceite conexões TCP/IP é necessário adequar o seu listen_addresses no postgresql.conf colocando o IP do servidor. Ex.: listen_addresses = 'localhost, 192.1.125.3'
• hostssl - o que você identificar com este tipo, só valerá para as conexões do tipo SSL.
• hostnossl - terá validade para conexões não SSL.

Como pode-se ver é bem simples, as conexões podem ser locais (local) ou externas (host), sendo que posso escolher ainda que determinadas configurações se apliquem apenas à conexões seguras (hostssl) ou justamente àquelas não seguras (hostnossl).

# DATABASE
#---------------------------

O segundo parâmetro trata-se do DATABASE ao qual se refere o registro. Não há muito que falar, apenas que muitas pessoas deixam como all, o que não faz muita diferença se você trabalha apenas com um banco, mas se você tiver mais de um no mesmo servidor, vale a pena especificar que os servidores da aplicação A só podem ver o banco A. Não custa nada, é fácil rápido e indolor.

# USER
#---------------------------

Define os usuários a quem se aplica a regra, que pode ser o próprio usuário, um grupo ou uma lista.

O usuário é fácil de entender, o grupo, trata-se de um grupo criado no seu banco de dados e a lista é criada em um arquivo a parte, fora do banco de dados.

Para o grupo, basta criá-lo no seu banco de dados, incluir os usuários nele e indicar o nome do grupo precedido de um + no pg_hba.conf. Ex.:


Você pode ainda criar uma lista de usuários, apesar de não entender um motivo para isso, mas se você conseguir ver uma utilidade para criar uma lista ao invés do grupo diretamente no banco, basta criar um arquivo no mesmo diretório que o pg_hba.conf e indicar como no grupo, mas utilizando o @. Ex.:


# CIDR-ADDRESS
#---------------------------

No campo CIDR (Classless Inter-Domain Routing) são inseridos o IPs que devem ser habilitados e a máscara de rede.

Apenas para registros do tipo "local", não preencha este campo.

Vamos supor que o cliente vai tentar acessar através do IP 192.10.125.50, podemos então representar isso de duas formas:

192.10.125.50/32
ou
192.10.125.50 255.255.255.255

Ambas dizem que apenas este endereço irá acessar o servidor de banco de dados, agora vamos supor que você quer liberar para as máquinas da rede deste usuário, cuja máscara é 255.255.255.0, então você poderia identificar como:

192.10.125.0/24
ou
192.10.125.0 255.255.255.0

Outros exemplos de formação de máscaras podem ser encontradas em:

• Classless Inter-Domain Routing - Wikipedia, the free encyclopedia

# METHOD
#---------------------------

Após ter verificado os outros campos e encontrar um registro que coincida, este campo determina o método a ser utilizado.

Não falarei de todos, até porque isso está documentado no site do PostgreSQL, então mostrarei apenas os mais utilizados.

• trust - é a forma menos segura e deve ser evitada ao máximo em ambiente de produção. Ao utilizar trust não será solicitado sequer senha e o usuário poderá acessar o banco como qualquer outro usuário, inclusive postgres.
• password - um pouco mais seguro que o trust, ele requer o password do usuário que está tentando se conectar. O problema é que esta senha não vem criptografada. Acho que não preciso dizer mais nada, não é?
• md5 - mais um passo rumo a segurança. Neste caso será solicitada a senha que o cliente vai criptografar, logo a senha não trafega aberta na rede. Com certeza é bem mais seguro, e cá entre nós, este é o método mais utilizado no caso de conexões não SSL.
  
  Mas uma vez que trata-se de um algoritmo bem difundido, algumas senhas podem figurar em dicionários facilmente encontrados até na web, como por exemplo em: http://www.matteoweb.it/old/md5_dictionary_hack/index.php
  
  
• ident - um recurso muito interessante, principalmente para acesso local. Neste caso o usuário é obtido a partir do sistema operacional cliente e esse dado é que é passado ao PostgreSQL.
  
  Isso evita que o usuário conectado localmente se passe por outro, fechando uma janela para invasões. Contudo, para conexões de outro servidor, isso pode ser uma grande porta aberta, pois podem ser criados usuários fantasma nos servidores distribuídos, que serão passados como válidos e confiáveis para o seu banco de dados. Portanto, uma opção bacana para local, ruim para os demais.
  
  
• ldap - como o nome sugere, utiliza uma base ldap para validar o usuário.
• reject - o último e mais seguro, afinal o que ele faz é isso mesmo, rejeitar conexões. Através dele você pode criar uma lista de usuários ou domínios de rede que não poderão se conectar ao seu banco.

Não tratarei mais dos métodos, pois como disse essa parte inicial é só para resumir um pouco do que diz a documentação oficial e alguns comentários meus, agora vamos à parte prática.