Quando um aplicativo cliente se conecta ao servidor de banco de dados especifica o nome de usuário do PostgreSQL a ser usado na conexão, de forma semelhante à feita pelo usuário para acessar o sistema operacional Unix. Dentro do ambiente SQL, o nome de usuário do banco de dados determina os privilégios de acesso aos objetos do banco de dados — Para obter mais informações deve ser visto o Capítulo 17. Portanto, é essencial controlar como os usuários de banco de dados podem se conectar.
A autenticação é o processo pelo qual o servidor de banco de dados estabelece a identidade do cliente e, por extensão, determina se o aplicativo cliente (ou o usuário executando o aplicativo cliente) tem permissão para se conectar com o nome de usuário que foi informado.
O PostgreSQL possui vários métodos diferentes para autenticação de clientes. O método utilizado para autenticar uma determinada conexão cliente pode ser selecionado tomando por base o endereço de hospedeiro (do cliente), o banco de dados ou o usuário.
Os nomes de usuário do PostgreSQL são logicamente distintos dos nomes de usuário do sistema operacional onde o servidor executa. Se todos os usuários de um determinado servidor de banco de dados também possuem conta no sistema operacional do servidor, é recomendável atribuir nomes de usuário do banco de dados correspondendo aos nomes de usuário do sistema operacional. Entretanto, um servidor que aceita conexões remotas pode possuir muitos usuários de banco de dados que não possuem conta no sistema operacional local e, nestes casos, a associação entre os nomes de usuário do banco de dados e os nomes de usuário do sistema operacional não é necessária.
A autenticação do cliente é controlada pelo arquivo que por tradição se chama pg_hba.conf e é armazenado no diretório de dados do agrupamento de bancos de dados. HBA significa autenticação baseada no hospedeiro (host-based authentication). É instalado um arquivo pg_hba.conf padrão quando o diretório de dados é inicializado pelo utilitário initdb. Entretanto, é possível colocar o arquivo de configuração da autenticação em outro local; consulte o parâmetro de configuração hba_file.
O formato geral do arquivo pg_hba.conf é um conjunto de registros, sendo um por linha. As linhas em branco são ignoradas, da mesma forma que qualquer texto após o caractere de comentário #. Um registro é formado por vários campos separados por espaços ou tabulações. Os campos podem conter espaços em branco se o valor do campo estiver entre aspas. Os registros não podem ocupar mais de uma linha.
Cada registro especifica um tipo de conexão, uma faixa de endereços de IP de cliente (se for relevante para o tipo de conexão), um nome de banco de dados, um nome de usuário e o método de autenticação a ser utilizado nas conexões que correspondem a estes parâmetros. O primeiro registro com o tipo de conexão, endereço do cliente, banco de dados solicitado e nome de usuário que corresponder é utilizado para realizar a autenticação. Não existe fall-through (procura exaustiva) ou backup: se um registro for escolhido e a autenticação não for bem-sucedida, os próximos registros não serão levados em consideração. Se não houver correspondência com nenhum registro, então o acesso é negado.
O registro pode ter um dos sete formatos a seguir:
local banco_de_dados usuário método_de_autenticação [opção_de_autenticação] host banco_de_dados usuário endereço_de_CIDR método_de_autenticação [opção_de_autenticação] hostssl banco_de_dados usuário endereço_de_CIDR método_de_autenticação [opção_de_autenticação] hostnossl banco_de_dados usuário endereço_de_CIDR método_de_autenticação [opção_de_autenticação] host banco_de_dados usuário endereço_de_IP máscara_de_IP método_de_autenticação [opção_de_autenticação] hostssl banco_de_dados usuário endereço_de_IP máscara_de_IP método_de_autenticação [opção_de_autenticação] hostnossl banco_de_dados usuário endereço_de_IP máscara_de_IP método_de_autenticação [opção_de_autenticação]
O significado de cada campo está descrito abaixo:
Este registro corresponde às tentativas de conexão feitas utilizando soquete do domínio Unix. Sem um registro deste tipo não são permitidas conexões através de soquete do domínio Unix.
Este registro corresponde às tentativas de conexão feitas utilizando o protocolo TCP/IP. Os registros host correspondem tanto às conexões SSL (Secure Socket Layer), quanto às não SSL.
Nota: Não serão possíveis conexões TCP/IP remotas, a menos que o servidor seja inicializado com o valor apropriado para o parâmetro de configuração listen_addresses, uma vez que o comportamento padrão é aceitar conexões TCP/IP apenas no endereço retornante (loopback) localhost.
Este registro corresponde às tentativas de conexão feitas utilizando o protocolo TCP/IP, mas somente quando a conexão é feita com a criptografia SSL.
Para esta opção poder ser utilizada o servidor deve ter sido construído com o suporte a SSL ativado. Além disso, o SSL deve ser ativado na inicialização do servidor através do parâmetro de configuração ssl (Para obter informações adicionais deve ser consultada a Seção 16.7).
Este registro é o oposto lógico de hostssl: só corresponde a tentativas de conexão feitas através do protocolo TCP/IP que não utilizam SSL.
Especifica quais bancos de dados este registro corresponde. O valor all especifica que corresponde a todos os bancos de dados. O valor sameuser especifica que o registro corresponde ao banco de dados com o mesmo nome do usuário fazendo o pedido de conexão. O valor samegroup especifica que o usuário deve ser membro do grupo com o mesmo nome do banco de dados do pedido de conexão. Senão, é o nome de um banco de dados específico do PostgreSQL. Podem ser fornecidos vários nomes de banco de dados separados por vírgula. Pode ser especificado um arquivo contendo nomes de banco de dados, precedendo o nome do arquivo por @.
Especifica quais usuários do PostgreSQL este registro corresponde. O valor all especifica que corresponde a todos os usuários. Senão, é o nome de um usuário específico do PostgreSQL. Podem ser fornecidos vários nomes de usuário separados por vírgula. Podem ser especificados nomes de grupo precedendo o nome do grupo por +. Pode ser especificado um arquivo contendo nomes de usuário precedendo o nome do arquivo por @.
Especifica a faixa de endereços de IP da máquina cliente que este registro corresponde. Contém um endereço de IP na notação padrão decimal com pontos, e o comprimento da máscara de CIDR (Os endereços de IP somente podem ser especificados numericamente, e não como domínios ou nomes de hospedeiro). O comprimento da máscara indica o número de bits de mais alta ordem que o endereço de IP do cliente deve corresponder. Os bits à direita devem ser zero em um determinado endereço de IP. Não pode haver espaços em branco entre os endereços de IP, a / e o comprimento da máscara de CIDR. [1]
Um endereço_de_CIDR típico seria 172.20.143.89/32 para um único hospedeiro, ou 172.20.143.0/24 para uma rede. Para especificar um único hospedeiro deve ser utilizada uma máscara de CIDR igual a 32 para o IPv4, ou igual a 128 para o IPv6.
Um endereço especificado no formato IPv4 corresponde às conexões IPv6 que possuem o endereço correspondente como, por exemplo, 127.0.0.1 corresponde ao endereço de IPv6 ::ffff:127.0.0.1. Uma entrada especificada no formato IPv6 corresponde apenas às conexões IPv6, mesmo que represente um endereço na faixa IPv4-em-IPv6. Deve ser observado que as entradas no formato IPv6 serão rejeitadas se a biblioteca C do sistema não possuir suporte a endereços IPv6.
Este campo se aplica apenas aos registros host, hostssl e hostnossl.
Estes campos podem ser utilizados como uma alternativa à notação endereço_de_CIDR. Em vez de especificar o comprimento da máscara, a máscara é especificada como uma coluna em separado. Por exemplo, 255.0.0.0 representa uma máscara de CIDR para endereços de IPv4 com comprimento igual a 8, e 255.255.255.255 representa uma máscara de CIDR com comprimento igual a 32.
Estes campos se aplicam apenas aos registros host, hostssl e hostnossl.
Especifica o método de autenticação a ser utilizado para se conectar através deste registro. Abaixo está mostrado um resumo das escolhas possíveis; os detalhes podem ser encontrados na Seção 19.2.
A conexão é permitida incondicionalmente. Este método permite a qualquer um que possa se conectar ao servidor de banco de dados PostgreSQL se autenticar como o usuário do PostgreSQL que for desejado, sem necessidade de senha. Consulte a Seção 19.2.1 para obter detalhes.
A conexão é rejeitada incondicionalmente. É útil para "eliminar por filtragem" certos hospedeiros de um grupo.
Requer que o cliente forneça uma senha criptografada pelo método md5 para autenticação. Consulte a Seção 19.2.2 para obter detalhes.
Requer que o cliente forneça uma senha criptografada através de crypt() para autenticação. Deve-se dar preferência ao método md5 para os clientes com versão 7.2 ou posterior, mas os clientes com versão anterior a 7.2 somente suportam crypt. Consulte a Seção 19.2.2 para obter detalhes.
Requer que o cliente forneça uma senha não criptografada para autenticação. Uma vez que a senha é enviada em texto puro pela rede, não deve ser utilizado em redes não confiáveis. Consulte a Seção 19.2.2 para obter detalhes.
É utilizado Kerberos V4 para autenticar o usuário. Somente disponível para conexões TCP/IP. Consulte a Seção 19.2.3 para obter detalhes.
É utilizado Kerberos V5 para autenticar o usuário. Somente disponível para conexões TCP/IP. Consulte a Seção 19.2.3 para obter detalhes.
Obtém o nome de usuário do sistema operacional do cliente (para conexões TCP/IP fazendo contato com o servidor de identificação no cliente, para conexões locais obtendo a partir do sistema operacional) e verifica se o usuário possui permissão para se conectar como o usuário de banco de dados solicitado consultando o mapa especificado após a palavra chave ident. Consulte a Seção 19.2.4 para obter detalhes.
Autenticação utilizando o serviço Pluggable Authentication Modules (PAM) fornecido pelo sistema operacional. Para obter detalhes deve ser consultada a Seção 19.2.5.
O significado deste campo opcional depende do método de autenticação escolhido, estando descrito na próxima seção.
Os arquivos incluídos pela construção @ são lidos como nomes de listas, que podem ser separadas por espaços em branco ou vírgulas. Os comentários são iniciados por #, como no arquivo pg_hba.conf, sendo permitidas construções @ aninhadas. A menos que o nome do arquivo que segue a @ seja um caminho absoluto, é considerado como sendo relativo ao diretório que contém o arquivo que faz referência.
Uma vez que os registros de pg_hba.conf são examinados seqüencialmente a cada tentativa de conexão, a ordem dos registros possui significado. Normalmente, os primeiros registros possuem parâmetros de correspondência de conexão mais exigentes e métodos de autenticação menos exigentes, enquanto os últimos registros possuem parâmetros de correspondência menos exigentes e métodos de autenticação mais exigentes. Por exemplo, pode-se desejar utilizar a autenticação trust para conexões TCP/IP locais, mas requerer o uso de senha para conexões TCP/IP remotas. Neste caso, o registro especificando a autenticação trust para conexões a partir de 127.0.0.1 deve aparecer antes do registro especificando autenticação por senha para uma faixa mais ampla de endereços de IP de cliente permitidos.
O arquivo pg_hba.conf é lido durante a inicialização e quando o processo servidor principal (postmaster) recebe um sinal SIGHUP. Se o arquivo for editado enquanto o sistema estiver ativo, será necessário enviar um sinal para o postmaster (utilizando pg_ctl reload ou kill -HUP) para fazer com que o arquivo seja lido novamente.
No Exemplo 19-1 são mostrados alguns exemplos de registros do arquivo pg_hba.conf. Para obter detalhes sobre os diferentes métodos de autenticação deve ser consultada a próxima seção.
Exemplo 19-1. Exemplo de registros do arquivo pg_hba.conf
# Permitir qualquer usuário do sistema local se conectar a qualquer banco # de dados sob qualquer nome de usuário utilizando os soquetes do domínio # Unix (o padrão para conexões locais). # # TYPE DATABASE USER CIDR-ADDRESS METHOD local all all trust # A mesma coisa utilizando conexões locais TCP/IP retornantes (loopback). # # TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 127.0.0.1/32 trust # O mesmo que o exemplo anterior mas utilizando uma coluna em separado para # máscara de rede. # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host all all 127.0.0.1 255.255.255.255 trust # Permitir qualquer usuário de qualquer hospedeiro com endereço de IP 192.168.93.x # se conectar ao banco de dados "template1" com o mesmo nome de usuário que "ident" # informa para a conexão (normalmente o nome de usuário do Unix). # # TYPE DATABASE USER CIDR-ADDRESS METHOD host template1 all 192.168.93.0/24 ident sameuser # Permitir o usuário do hospedeiro 192.168.12.10 se conectar ao banco de dados # "template1" se a senha do usuário for fornecida corretamente. # # TYPE DATABASE USER CIDR-ADDRESS METHOD host template1 all 192.168.12.10/32 md5 # Na ausência das linhas "host" precedentes, estas duas linhas rejeitam todas # as conexões oriundas de 192.168.54.1 (uma vez que esta entrada será # correspondida primeiro), mas permite conexões Kerberos V de qualquer ponto # da Internet. A máscara zero significa que não é considerado nenhum bit do # endereço de IP do hospedeiro e, portanto, corresponde a qualquer hospedeiro. # # TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.54.1/32 reject host all all 0.0.0.0/0 krb5 # Permite os usuários dos hospedeiros 192.168.x.x se conectarem a qualquer # banco de dados se passarem na verificação de "ident". Se, por exemplo, "ident" # informar que o usuário é "oliveira" e este requerer se conectar como o usuário # do PostgreSQL "guest1", a conexão será permitida se houver uma entrada # em pg_ident.conf para o mapa "omicron" informando que "oliveira" pode se # conectar como "guest1". # # TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.0.0/16 ident omicron # Se as linhas abaixo forem as únicas três linhas para conexão local, vão # permitir os usuários locais se conectarem somente aos seus próprios bancos de # dados (bancos de dados com o mesmo nome que seus nomes de usuário), exceto # para os administradores e membros do grupo "suporte" que podem se conectar a # todos os bancos de dados. O arquivo $PGDATA/admins contém a lista de nomes de # usuários. A senha é requerida em todos os casos. # # TYPE DATABASE USER CIDR-ADDRESS METHOD local sameuser all md5 local all @admins md5 local all +suporte md5 # As duas últimas linhas acima podem ser combinadas em uma única linha: local all @admins,+suporte md5 # A coluna banco de dados também pode utilizar listas e nomes de arquivos, # mas não grupos: local db1,db2,@demodbs all md5
| [1] |
Classless Internet Domain Routing — O CIDR, definido pela RFC1519, elimina o sistema de classes que determinava originalmente a parte de rede de um endereço IP. Como a sub-rede, da qual é uma extensão direta, o CIDR conta com uma máscara de rede explícita para definir o limite entre as partes de rede e de hospedeiro de um endereço. Exemplo: Comprimento: /20; Bits do hospedeiro: 12; Hospedeiros por rede: 4096; Máscara de rede decimal: 255.255.240.0. Linux Administration Handbook — Evi Nemeth e outros — Prentice Hall PTR. (N. do T.) |
