O PostgreSQL é um dos bancos de dados mais seguros do mundo. A segurança do banco de dados desempenha um papel fundamental nos ambientes de missão crítica do mundo real. É importante garantir que os bancos de dados e os dados estejam sempre protegidos e não sejam submetidos a acesso não autorizado, comprometendo assim a segurança dos dados. Embora o PostgreSQL forneça vários mecanismos e métodos para que os usuários acessem o banco de dados de maneira segura, ele também pode ser integrado a vários sistemas de autenticação externa para garantir que os requisitos de segurança de banco de dados padrão corporativo sejam atendidos.
Além de fornecer mecanismos de autenticação seguros via SSL, MD5, pgpass e pg_ident etc., o PostgreSQL pode ser integrado a vários outros sistemas de autenticação externa de nível empresarial populares. Meu foco neste blog será LDAP, Kerberos e RADIUS com SSL e pg_ident.
LDAP
LDAP refere-se ao Lightweight Directory Access Protocol, que é um sistema de autenticação centralizado popularmente usado. É um armazenamento de dados que armazena as credenciais do usuário e vários outros detalhes relacionados ao usuário, como nomes, domínios, unidades de negócios, etc. na forma de uma hierarquia em formato de tabela. Os usuários finais que se conectam aos sistemas de destino (por exemplo, um banco de dados) devem primeiro se conectar ao servidor LDAP para obter uma autenticação bem-sucedida. O LDAP é um dos sistemas de autenticação populares atualmente usados em organizações que exigem altos padrões de segurança.
LDAP + PostgreSQL
O PostgreSQL pode ser integrado ao LDAP. Na minha experiência de consultoria ao cliente, isso é considerado um dos principais recursos do PostgreSQL. Como a autenticação do nome de usuário e senha ocorre no servidor LDAP, para garantir que os usuários possam se conectar ao banco de dados via LDAP, a conta do usuário deve existir no banco de dados. Em outras palavras, isso significa que os usuários ao tentar se conectar ao PostgreSQL são roteados primeiro para o servidor LDAP e depois para o banco de dados Postgres após a autenticação bem-sucedida. A configuração pode ser feita no arquivo pg_hba.conf para garantir que as conexões sejam roteadas para o servidor LDAP. Abaixo está um exemplo de entrada pg_hba.conf -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"Abaixo está um exemplo de uma entrada LDAP em pg_hba.conf:
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", ou=finance, dc=example, dc=com"Ao usar porta ldap não padrão e TLS:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Compreendendo a entrada LDAP acima
- O LDAP usa vários atributos e terminologias para armazenar/pesquisar uma entrada de usuário em seu armazenamento de dados. Além disso, como mencionado acima, as entradas do usuário são armazenadas em hierarquia.
- As entradas pg_hba.conf ldap acima consistem em atributos chamados CN (Nome Comum), OU (Unidade de Organização) e DC (Componente de Domínio) que, são denominados como Nomes Distintos Relativos (RDN), essas sequências de RDN juntas se tornam algo chamado DN (Nome Distinto). DN é o objeto LDAP baseado no qual a pesquisa é realizada no armazenamento de dados LDAP.
- Valores de atributo LDAP como CN, DC, OU etc. são definidos nas Classes de objetos do LDAP, que podem ser fornecidas pelos especialistas em sistemas que criaram o ambiente LDAP.
Isso tornará o LDAP seguro o suficiente?
Talvez não. As senhas comunicadas pela rede em um ambiente LDAP não são criptografadas, o que pode ser um risco de segurança, pois as senhas criptografadas podem ser hackeadas. Existem opções para tornar a comunicação de credenciais mais segura.
- Considere configurar o LDAP em TLS (Transport Layer Security)
- O LDAP pode ser configurado com SSL, que é outra opção
Dicas para obter integração LDAP com PostgreSQL
(para sistemas baseados em Linux)
- Instale os módulos openLDAP apropriados com base na versão do sistema operacional
- Certifique-se de que o software PostgreSQL esteja instalado com bibliotecas LDAP
- Certifique-se de que o LDAP esteja bem integrado ao Active Directory
- Familiarize-se com quaisquer BUGs existentes nos módulos openLDAP que estão sendo usados. Isso pode ser catastrófico e comprometer os padrões de segurança.
- O Windows Active Directory também pode ser integrado ao LDAP
- Considere configurar o LDAP com SSL, que é mais seguro. Instale os módulos openSSL apropriados e esteja ciente de BUGs como heart-bleed, que podem expor as credenciais transmitidas pela rede.
Kerberos
Kerberos é um sistema de autenticação centralizado padrão do setor usado popularmente em organizações e fornece mecanismo de autenticação baseado em criptografia. As senhas são autenticadas por um servidor de autenticação de terceiros denominado KDC (Key Distribution Center). As senhas podem ser criptografadas com base em vários algoritmos e só podem ser descriptografadas com a ajuda de chaves privadas compartilhadas. Isso também significa que as senhas comunicadas pela rede são criptografadas.
PostgreSQL + Kerberos
PostgreSQL suporta autenticação baseada em GSSAPI com Kerberos. Os usuários que tentarem se conectar ao banco de dados Postgres serão roteados para o servidor KDC para autenticação. Essa autenticação entre clientes e banco de dados KDC é realizada com base em chaves privadas compartilhadas e, após autenticação bem-sucedida, os clientes agora manteriam credenciais baseadas em Kerberos. As mesmas credenciais são submetidas à validação entre o servidor Postgres e o KDC que será feita com base no arquivo keytab gerado pelo Kerberos. Este arquivo keytab deve existir no servidor de banco de dados com as permissões apropriadas para o usuário que possui o processo Postgres.
O processo de configuração e conexão do Kerberos -
-
As contas de usuário baseadas em Kerberos devem gerar um ticket (uma solicitação de conexão) usando o comando “kinit”.
-
Um arquivo keytab deve ser gerado usando o comando “kadmin” para uma conta de usuário totalmente qualificada baseada em Kerberos (principal) e então o Postgres usaria o mesmo arquivo keytab para validar as credenciais. Os principais podem ser criptografados e adicionados ao arquivo keytab existente usando o comando “ktadd”. A criptografia Kerberos oferece suporte a vários algoritmos de criptografia padrão do setor.
O arquivo keytab gerado deve ser copiado para o servidor Postgres, deve ser legível pelo processo Postgres. O parâmetro postgresql.conf abaixo deve ser configurado:
krb_server_keyfile = '/database/postgres/keytab.example.com'
Se você é específico sobre a diferenciação entre maiúsculas e minúsculas, use o parâmetro abaixo
krb_caseins_users which is by default “off” (case sensitive) -
Uma entrada deve ser feita no pg_hba.conf para garantir que as conexões sejam roteadas para o servidor KDC
Exemplo de entrada pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM
Exemplo de entrada pg_hba.conf com entrada de mapa
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Uma conta de usuário tentando se conectar deve ser adicionada ao banco de dados KDC que é denominado como principal e a mesma conta de usuário ou uma conta de usuário de mapeamento também deve existir no banco de dados
Abaixo está um exemplo de um principal Kerberos
[email protected]
pguser é o nome de usuário e “example.com” é o nome do domínio configurado na configuração do Kerberos (/etc/krb5.conf) no servidor KDC.
No mundo kerberos, principais estão em um formato semelhante a e-mail ([email protected]) e os usuários do banco de dados não podem ser criados no mesmo formato. Isso faz os DBAs pensarem em criar um mapeamento de nomes de usuário de banco de dados e garantir que os principais se conectem com nomes mapeados usando pg_ident.conf.
Abaixo está um exemplo de uma entrada de nome de mapa em pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Isso tornará o Kerberos seguro o suficiente?
Talvez não. As credenciais do usuário comunicadas pela rede podem ser expostas, hackeadas. Embora o Kerberos criptografe os principais, eles podem ser roubados, hackeados. Isso traz a necessidade de implementar a segurança da camada de rede. Sim, SSL ou TLS é o caminho a percorrer. O sistema de autenticação Kerberos pode ser integrado com SSL ou TLS. TLS é o sucessor do SSL. Recomenda-se configurar o Kerberos com SSL ou TLS para que a comunicação pela rede seja segura.
DICAS
- Certifique-se de que as bibliotecas krb* estejam instaladas
- As bibliotecas OpenSSL devem ser instaladas para configurar o SSL
- Certifique-se de que o Postgres esteja instalado com as seguintes opções
./configure --with-gssapi --with-krb-srvnam --with-openssl
RAIO
RADIUS é um protocolo de rede de serviço de autenticação remota que fornece
Autenticação, Autorização e Contabilidade (AAA). Os pares de nome de usuário/senha são autenticados no servidor RADIUS. Essa forma de autenticação centralizada é muito direta e simples em comparação com outros sistemas de autenticação, como LDAP e Kerberos, que envolvem um pouco de complexidade.
RADIO + PostgreSQL
O PostgreSQL pode ser integrado ao mecanismo de autenticação RADIUS. A contabilidade ainda não é suportada no Postgres. Isso requer que as contas de usuário do banco de dados existam no banco de dados. As conexões com o banco de dados são autorizadas com base no segredo compartilhado denominado “radiussecret”.
Uma entrada na configuração do pg_hba.conf é essencial para rotear as conexões ao servidor radius para autenticação.
Exemplo de entrada pg_hba.conf
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128Para entender a entrada acima -
“radiusserver” é o endereço IP do host do servidor RADIUS onde os usuários são roteados para autenticação. Este parâmetro é configurado em /etc/radiusd.conf no servidor RADIUS.
O valor “radiussecret” é extraído de clients.conf. Este é o código secreto que identifica exclusivamente a conexão do cliente radius.
“radiusport” pode ser encontrado no arquivo /etc/radiusd.conf. Esta é a porta na qual as conexões de raio estarão escutando.
Importância do SSL
SSL (Secure Socket Layer) desempenha um papel imperativo com os sistemas de autenticação externa instalados. É altamente recomendável configurar o SSL com um sistema de autenticação externo, pois haverá comunicação de informações confidenciais entre clientes e servidores pela rede e o SSL pode aumentar ainda mais a segurança.
Impacto no desempenho do uso de sistemas de autenticação externa
Um sistema de segurança eficaz e eficiente vem à custa do desempenho. Como os clientes/usuários que tentam se conectar ao banco de dados são roteados para sistemas de autenticação para estabelecer a conexão, pode haver degradação do desempenho. Existem maneiras de superar os obstáculos de desempenho.
- Com o mecanismo de autenticação externa implementado, pode haver um atraso ao estabelecer uma conexão com o banco de dados. Isso pode ser uma preocupação real quando há um grande número de conexões sendo estabelecidas com o banco de dados.
- Os desenvolvedores precisam garantir que um número alto e desnecessário de conexões não seja feito com o banco de dados. Várias solicitações de aplicativos sendo atendidas por meio de uma conexão seriam vantajosas.
- Além disso, o tempo que cada solicitação está demorando no banco de dados desempenha um papel importante. Se a solicitação demorar mais para ser concluída, as solicitações subsequentes entrarão na fila. O ajuste de desempenho dos processos e a arquitetura meticulosa da infraestrutura serão fundamentais!
- Banco de dados e infraestrutura devem ser arquitetados de forma eficiente e adequadamente capacitados para garantir um bom desempenho.
- Ao fazer benchmarking de desempenho, certifique-se de que o SSL esteja ativado e o tempo médio de estabelecimento da conexão deve ser avaliado.
Integrando Sistemas de Autenticação Externos com ClusterControl - PostgreSQL
As instâncias do PostgreSQL podem ser criadas e configuradas automaticamente por meio da GUI do ClusterControl. A integração de sistemas de autenticação externa com instâncias PostgreSQL implantadas via ClusterControl é bastante semelhante em comparação com a integração com instâncias PostgreSQL tradicionais e, na verdade, é um pouco mais simples. Abaixo está uma visão geral do mesmo -
- ClusterControl instala bibliotecas PostgreSQL habilitadas com recursos LDAP, KRB, GSSAPI e OpenSSL
- A integração com sistemas de autenticação externos requer várias alterações de configuração de parâmetros no servidor de banco de dados postgresql que podem ser feitas usando a GUI do ClusterControl.
