Métodos de autenticação no PostgreSQL

Abaixo estão descritos com mais detalhes os métodos de autenticação.

1. Autenticação de confiança

Quando é especificada a autenticação trust, o PostgreSQL assume que qualquer um que possa se conectar ao servidor está autorizado a acessar o banco de dados como qualquer usuário que seja especificado (incluindo o superusuário do banco de dados). É claro que as restrições especificadas para o usuário e para o banco de dados ainda se aplicam. Este método deve ser utilizado somente quando existe uma proteção adequada no nível de sistema operacional para as conexões ao servidor.

A autenticação trust é apropriada e muito conveniente para conexões locais em estações de trabalho com um único usuário. Geralmente não é apropriada em um máquina multiusuária. Entretanto, é possível utilizar trust mesmo em uma máquina multiusuária, se for restringido o acesso ao arquivo de soquete do domínio Unix do servidor utilizando permissões do sistema de arquivos. Para fazer isto, deve ser definido o parâmetro de configuração unix_socket_permissions (e, possivelmente, unix_socket_group). Também pode ser definido o parâmetro de configuração unix_socket_directory para colocar o arquivo de soquete em um diretório com restrição adequada.

Definir as permissões do sistema de arquivos somente serve para as conexões através dos soquetes do Unix. As conexões locais TCP/IP não são restringidas desta maneira; portanto, se for desejado utilizar permissões do sistema de arquivos para segurança local, deve ser removida a linha host ... 127.0.0.1 ... do arquivo pg_hba.conf, ou mudá-la para que use um método de autenticação diferente de trust.

A autenticação trust somente é adequada para as conexões TCP/IP quando se confia em todos os usuários de todas as máquinas que podem se conectar ao servidor de banco de dados pelas linhas do arquivo pg_hba.conf que especificam trust. Raramente faz sentido utilizar trust para conexões TCP/IP, a não ser as oriundas de localhost (127.0.0.1).

2. Autenticação por senha

Os métodos de autenticação baseados em senha são md5, crypt e password. Estes métodos operam de forma semelhante, exceto com relação à forma como a senha é enviada através da conexão, mas somente o método md5 suporta senhas criptografadas armazenadas no catálogo do sistema pg_shadow; os outros dois métodos requerem que sejam armazenadas senhas não criptografadas neste catálogo.

Se houver preocupação com relação aos ataques de "farejamento" (sniffing) de senhas, então md5 é o método preferido, com crypt como a segunda opção se for necessário suportar clientes pré-7.2. O método password deve ser evitado, especialmente em conexões pela Internet aberta (a menos que seja utilizado SSL, SSH ou outro método de segurança para proteger a conexão).

As senhas de banco de dados do PostgreSQL são distintas das senhas de usuário do sistema operacional. As senhas de todos os usuários do banco de dados são armazenadas na tabela do catálogo do sistema pg_shadow. As senhas podem ser gerenciadas através dos comandos SQL CREATE USER e ALTER USER; por exemplo, CREATE USER foo WITH PASSWORD 'segredo';. Por padrão, ou seja, se nenhuma senha for definida, é armazenado o valor nulo para a senha e a autenticação da senha é sempre mal-sucedida para este usuário.

Para restringir o conjunto de usuários que podem se conectar a um determinado banco de dados, os usuários devem ser relacionados na coluna usuário do arquivo pg_hba.conf, conforme explicado na seção anterior.

3. Autenticação Kerberos

Kerberos é um sistema de autenticação seguro, padrão da indústria, adequado para computação distribuída em redes públicas. A descrição do sistema Kerberos está muito acima do escopo deste texto; de forma geral pode ser bastante complexo (porém poderoso). Existem diversas fontes de distribuição do Kerberos.

Embora o PostgreSQL suporte tanto o Kerberos 4 quanto o Kerberos 5, somente o Kerberos 5 é recomendado. O Kerberos 4 é considerado inseguro, não sendo mais recomendado para uso geral.

Para o Kerberos poder ser utilizado, o seu suporte deve ser habilitado em tempo de construção. São suportados tanto o Kerberos 4 quanto o 5, mas pode ser suportada apenas uma versão por uma construção.

O PostgreSQL opera como um serviço Kerberos normal. O nome do serviço principal é nome_do_serviço/nome_do_hospedeiro@domínio, onde nome_do_serviço é postgres (a menos que seja selecionado um nome de serviço diferente em tempo de configuração utilizando ./configure --with-krb-srvnam=qualquer_coisa). O nome_do_hospedeiro é o nome de hospedeiro da máquina servidora totalmente qualificado. O domínio (realm) do serviço principal é o domínio preferido da máquina servidora.

Os principais dos clientes devem ter seu nome de usuário do PostgreSQL como primeiro componente como, por exemplo, pgusername/outras_coisas@dominio. Atualmente o domínio do cliente não é verificado pelo PostgreSQL; portanto, estando habilitada a autenticação entre domínios, então todo principal de qualquer domínio que puder se comunicar com o que está sendo utilizado será aceito.

Certifique-se de que o arquivo de chaves do servidor seja legível (e preferencialmente somente legível) pela conta do servidor PostgreSQL. O local do arquivo de chaves é especificado pelo parâmetro de configuração em tempo de execução krb_server_keyfile. O padrão é /etc/srvtab se estiver sendo utilizado o Kerberos 4, e /usr/local/pgsql/etc/krb5.keytab (o ou diretório especificado como sysconfdir em tempo de construção) no Kerberos 5.

Para gerar o arquivo keytab deve ser utilizado, por exemplo (com a versão 5):

kadmin% ank -randkey postgres/server.my.domain.org
kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org

Para obter detalhes deve ser lida a documentação do Kerberos.

Ao se conectar ao banco de dados tenha certeza de possuir um tíquete para o principal correspondendo ao nome de usuário do banco de dados. Como exemplo: Para o nome de usuário do banco de dados cecilia, podem ser utilizados tanto o principal cecilia@EXAMPLE.COM quanto cecilia/users.example.com@EXAMPLE.COM para se autenticar no servidor de banco de dados.

Se for utilizado no servidor Web Apache o módulo mod_auth_kerb de Kerberos Module for Apache e o mod_perl, pode ser utilizado AuthType KerberosV5SaveCredentials com um script mod_perl, proporcionando um acesso seguro ao banco de dados através da Web, sem necessidade de senhas extras.

4. Autenticação baseada no Ident

O método de autenticação ident funciona obtendo o nome de usuário do sistema operacional do cliente, e determinando os nomes de usuário do banco de dados permitidos utilizando um arquivo de mapa que lista os pares de nomes de usuários correspondentes permitidos. A determinação do nome de usuário do cliente é o ponto crítico da segurança, funcionando de forma diferente dependendo do tipo de conexão.

4.1. Autenticação Ident através de TCP/IP

O "Protocolo de Identificação" está descrito no RFC 1413. Virtualmente todo sistema operacional da família Unix é distribuído com um servidor ident que escuta a porta TCP 113 por padrão. A funcionalidade básica do servidor ident é responder a perguntas como "Que usuário inicializou a conexão que sai pela sua porta X e se conecta à minha porta Y?". Uma vez que o PostgreSQL conhece tanto X quanto Y quando a conexão física é estabelecida, pode fazer a pergunta ao servidor ident no hospedeiro do cliente se conectando e pode, teoricamente, determinar o usuário do sistema operacional para uma determinada conexão desta maneira.

O problema deste procedimento é que depende da integridade do cliente: se a máquina cliente não for confiável ou estiver comprometida, alguém querendo fazer um ataque pode executar algum programa na porta 113 e retornar qualquer nome de usuário desejado. Este método de autenticação é, portanto, apropriado apenas para redes fechadas onde toda máquina cliente está sob controle rígido, e onde os administradores do sistema e do banco de dados trabalham de forma integrada. Em outras palavras, é necessário confiar na máquina executando o servidor ident. Deve ser observada a advertência: O Protocolo de Identificação não tem por objetivo ser um protocolo de autorização ou de controle de acesso.

4.2. Autenticação Ident através de soquetes locais

Nos sistemas que possuem a opção SO_PEERCRED para os soquetes do domínio Unix (atualmente Linux, FreeBSD, NetBSD, OpenBSD e BSD/OS), a autenticação ident também pode ser aplicada para as conexões locais. Neste caso nenhum risco à segurança é introduzido pela utilização da autenticação ident; na verdade, esta é a escolha preferida para as conexões locais nestes sistemas.

Em sistemas que não possuem a opção SO_PEERCRED, a autenticação ident está disponível somente através das conexões TCP/IP. Para superar este problema, é possível especificar o endereço 127.0.0.1 do localhost, e se conectar a este endereço. Este método é tão confiável quanto o servidor ident local.

4.3. Mapas de Ident

Ao utilizar a autenticação baseada no ident, após determinar o nome de usuário do sistema operacional que iniciou a conexão o PostgreSQL verifica se este usuário pode se conectar como o usuário de banco de dados que está sendo solicitado na conexão. Isto é controlado pelo argumento do mapa de ident que segue a palavra chave ident no arquivo pg_hba.conf. Existe um mapa de ident pré-definido chamado sameuser, que permite todo usuário do sistema operacional se conectar como o usuário de banco de dados com o mesmo nome (se este existir). Os outros mapas devem ser criados manualmente.

Fora o sameuser, os mapas de ident são definidos no arquivo de mapa de ident que, por padrão, se chama pg_ident.conf e é armazenado no diretório de dados do agrupamento. A forma geral das linhas do mapa de ident é:

nome_do_mapa nome_de_usuário_do_ident nome_de_usuário_do_banco_de_dados

Os comentários e os espaços em branco são tratados da mesma maneira que no arquivo pg_hba.conf. O nome_do_mapa é um nome arbitrário a ser utilizado para fazer referência ao mapa em pg_hba.conf. Os outros dois campos especificam qual usuário do sistema operacional pode se conectar como qual usuário do banco de dados. O mesmo nome_do_mapa pode ser utilizado várias vezes para especificar mais mapeamentos de usuários dentro de um único mapa. Não existe restrição com relação a quantos usuários do banco de dados um determinado usuário do sistema operacional pode corresponder, nem o contrário.

O arquivo pg_ident.conf é lido na inicialização e quando o processo servidor principal (postmaster) recebe um sinal SIGHUP. Se o arquivo for editado com o sistema ativo, será necessário enviar este sinal para o postmaster (utilizando pg_ctl reload ou kill -HUP) para fazer o arquivo ser lido novamente.

Um arquivo pg_ident.conf está mostrado no exemplo seguinte. Nesta configuração de exemplo, qualquer usuário autenticado em uma máquina da rede 192.168 que não possua o nome de usuário Unix oliveira, lia ou andre não vai ter o acesso permitido. O usuário Unix andre somente poderá acessar quando tentar se conectar como o usuário do PostgreSQL pacheco, e não como andre ou algum outro. A usuária lia somente poderá se conectar como lia. O usuário oliveira poderá se conectar como o próprio oliveira ou como guest1.

Exemplo: Arquivo pg_ident.conf de exemplo

# MAPNAME IDENT-USERNAME PG-USERNAME

omicron   oliveira       oliveira
omicron   lia            lia
# pacheco possui o nome de usuário andre nestas máquinas
omicron   andre          pacheco
# oliveira também pode se conectar como guest1
omicron   oliveira       guest1

5. Autenticação PAM

Este método de autenticação opera de forma semelhante ao método password, exceto por utilizar o mecanismo de autenticação PAM (Pluggable Authentication Modules). O nome padrão do serviço PAM é postgresql. É possível, opcionalmente, fornecer um outro nome de serviço após a palavra chave pam no arquivo pg_hba.conf.