Restrição de acesso por IP e configuração do pg_hba.conf

pg_hba.conf é o arquivo de configuração do PostgreSQL feito pra controlar conexões e autenticação. HBA significa Host-Based Authentication (autenticação baseada no host). Esse arquivo funciona tipo uma "cancelinha" de rede, que define:

• Quem pode se conectar ao servidor (endereços IP, role, banco de dados).
• Qual método de autenticação é exigido pra conexão.

Se for comparar com a vida real, o pg_hba.conf é tipo o porteiro na entrada do prédio. Ele decide quem entra e quem não entra, conferindo não só seus documentos (senha), mas também seu endereço (IP).

Estrutura do arquivo pg_hba.conf

O arquivo pg_hba.conf é feito de linhas, cada uma descrevendo uma regra de acesso. A estrutura da linha é assim:

<tipo de conexão> <banco de dados> <usuário> <origem> <método de autenticação>

Bora ver os componentes:

Tipo de conexão (connection type): define como o cliente vai se conectar.

• local: conexão via Unix sockets (pra usuários locais no servidor Linux).
• host: conexão via TCP/IP.
• hostssl: conexão via TCP/IP, mas só usando SSL.
• hostnossl: conexão via TCP/IP sem usar SSL.

Banco de dados: lista os bancos de dados que podem ser acessados. Dá pra colocar um banco específico, vários separados por vírgula, ou palavras-chave:

• all: Permite acesso a todos os bancos de dados.

Usuário: diz quais usuários podem se conectar.

• Pode colocar um nome de usuário específico ou usar all pra liberar pra geral.

Origem (address): indica o endereço IP do cliente ou um range de IPs.

• Pra IPv4, usa o formato x.x.x.x ou x.x.x.x/y (onde /y é a máscara de sub-rede, tipo /24).
• Pra IPv6, usa o formato ::/y.
• A palavra-chave all libera pra todos os IPs.

Método de autenticação: mostra qual método de autenticação vai ser usado.

Exemplos:

• trust: libera conexão sem senha (não é seguro, só pra testes).
• md5: usa senha (hash).
• scram-sha-256: autenticação mais segura usando SHA-256.
• reject: bloqueia o acesso.

Exemplos de linha no pg_hba.conf

A configuração do arquivo pode ser bem flexível. Olha só alguns exemplos:

1. Liberar conexões locais via Unix socket

   local   all             all                                     trust
   

   Todo mundo pode se conectar a todos os bancos no servidor local sem senha.

2. Liberar conexões de um IP específico

   host    my_database     my_user        192.168.1.100/32         md5
   

   O usuário my_user pode se conectar ao banco my_database só do IP 192.168.1.100, usando senha.

3. Liberar acesso ao banco pra toda uma sub-rede

   host    my_database     all            192.168.1.0/24           scram-sha-256
   

   Qualquer usuário da sub-rede 192.168.1.0/24 pode se conectar ao banco my_database, mas só com autenticação SHA-256.

4. Bloquear conexões de uma sub-rede específica

   host    all             all            192.168.2.0/24           reject
   

   Conexões da sub-rede 192.168.2.0/24 estão totalmente bloqueadas.

Configurando acesso por endereços IP

Agora que já entendemos a estrutura do arquivo, bora ver como controlar as conexões.

Vamos tentar limitar o acesso ao servidor só pra alguns IPs. Imagina que você tem um servidor PostgreSQL e quer liberar acesso só do localhost (127.0.0.1) e da sub-rede do escritório (192.168.10.0/24). Pra isso, adiciona essas linhas no pg_hba.conf:

# Acesso local
host    all             all            127.0.0.1/32             trust

# Acesso do escritório
host    all             all            192.168.10.0/24          md5

# Bloquear todo o resto
host    all             all            0.0.0.0/0                reject

Aqui, a regra 0.0.0.0/0 significa "todos os IPs". A gente tá bloqueando tudo que não for dos IPs permitidos.

Configurando acesso pra usuários remotos

Se seu servidor PostgreSQL tá na nuvem ou em um servidor remoto, talvez você precise liberar conexão só pra alguns IPs externos. Por exemplo:

# Acesso pro admin de casa
host    all             admin_user     203.0.113.10/32          md5

Nesse exemplo, só o usuário admin_user do IP 203.0.113.10 vai conseguir conectar.

Recarregando a configuração

Depois de mudar o pg_hba.conf, o PostgreSQL precisa aplicar as mudanças. Pra isso, usa o comando:

sudo systemctl reload postgresql

Recarregar é tranquilo e não derruba o servidor.

Se você esqueceu onde tá o pg_hba.conf, dá pra descobrir o caminho via SQL:

SHOW hba_file;

Erros comuns ao mexer no pg_hba.conf

Trabalhar com o pg_hba.conf é de boa, mas quem tá começando às vezes vacila. Tipo:

1. Esqueceu de recarregar o servidor. Todas as mudanças no pg_hba.conf só valem depois de recarregar a configuração.
2. Regras conflitantes. O PostgreSQL lê as regras de cima pra baixo. Assim que uma regra bate, o resto é ignorado. As regras mais gerais têm que ficar embaixo.
3. Máscara de sub-rede errada. Por exemplo, se colocar /0, você libera pra todo mundo, o que é uma baita brecha de segurança.

Exemplos de cenários reais de uso

Testando app no servidor local.

Liberar acesso só do localhost:

local   all   all   trust

Trabalhando com clientes remotos.

Liberar acesso pra um cliente de um IP específico:

host    all   client_user   203.0.113.42/32   scram-sha-256

Restringindo acesso na rede pública.

Bloquear conexões da Internet (mas liberar pro escritório):

host    all   all   0.0.0.0/0   reject
host    all   all   192.168.10.0/24   md5

Nessa altura, você já deve ter sacado como usar o pg_hba.conf pra limitar o acesso ao PostgreSQL. Esse arquivo é uma das ferramentas chave pra garantir a segurança do banco. Fica de olho pra deixar as configs lógicas, testadas e alinhadas com o que o negócio precisa. Afinal, a gente quer viver num mundo onde os dados tão protegidos dos hackers, né? Bom, a não ser que o hacker seja você :)