Depois de terminar o processo de instalação do seu servidor de banco de dados PostgreSQL, é necessário protegê-lo antes de entrar em produção. Neste post, mostraremos como fortalecer a segurança em torno de seu banco de dados para manter seus dados seguros e protegidos.
1. Controle de autenticação do cliente
Ao instalar o PostgreSQL, um arquivo chamado pg_hba.conf é criado no diretório de dados do cluster de banco de dados. Este arquivo controla a autenticação do cliente.
A partir da documentação oficial do postgresql podemos definir o arquivo pg_hba.conf como um conjunto de registros, um por linha, onde cada registro especifica um tipo de conexão, um intervalo de endereços IP do cliente (se 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 usado para conexões correspondentes a esses parâmetros. O primeiro registro com um tipo de conexão correspondente, endereço de cliente, banco de dados solicitado e nome de usuário é usado para realizar a autenticação.
Então, o formato geral será algo assim:
# TYPE DATABASE USER ADDRESS METHODUm exemplo de configuração pode ser o seguinte:
# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.94.0/24 rejectExistem muitas combinações que você pode fazer para refinar as regras (a documentação oficial descreve cada opção em detalhes e tem alguns ótimos exemplos), mas lembre-se de evitar regras muito permissivas, como permitir o acesso a linhas usando DATABASE all ou ADDRESS 0.0.0.0/0.
Para garantir a segurança, mesmo que você esteja esquecendo de adicionar uma regra, você pode adicionar a seguinte linha na parte inferior:
# TYPE DATABASE USER ADDRESS METHOD
host all all 0.0.0.0/0 rejectComo o arquivo é lido de cima para baixo para encontrar as regras correspondentes, dessa forma você garante que, para permitir a permissão, você precisará adicionar explicitamente a regra correspondente acima.
2. Configuração do servidor
Existem alguns parâmetros no postgresql.conf que podemos modificar para aumentar a segurança.
Você pode usar o parâmetro listen_address para controlar quais ips terão permissão para se conectar ao servidor. Aqui é uma boa prática permitir conexões apenas dos ips conhecidos ou de sua rede, e evitar valores gerais como “*”,”0.0.0.0:0” ou “::”, que dirá ao PostgreSQL para aceitar conexão de qualquer IP.
Alterar a porta na qual o postgresql escutará (por padrão 5432) também é uma opção. Você pode fazer isso modificando o valor do parâmetro port.
Parâmetros como work_mem, maintenance_work_mem, temp_buffer , max_prepared_transactions, temp_file_limit são importantes para se ter em mente caso você tenha um ataque de negação de serviço. Esses são parâmetros de instrução/sessão que podem ser definidos em diferentes níveis (db, usuário, sessão), portanto, gerenciá-los com sabedoria pode nos ajudar a minimizar o impacto do ataque.
3. Gerenciamento de usuários e funções
A regra de ouro para a segurança em relação ao gerenciamento de usuários é conceder aos usuários a quantidade mínima de acesso de que precisam.
Gerenciar isso nem sempre é fácil e pode ficar muito confuso se não for bem feito desde o início.
Uma boa maneira de manter os privilégios sob controle é usar a estratégia de função, grupo e usuário.
No postgresql tudo é considerado um papel, mas vamos fazer algumas mudanças nisso.
Nesta estratégia, você criará três tipos ou funções diferentes:
- função da função (identificada pelo prefixo r_)
- função do grupo (identificada pelo prefixo g_)
- função do usuário (geralmente nomes pessoais ou de aplicativos)
Os papéis (r_ papéis) serão aqueles que terão privilégios sobre os objetos. Os papéis do grupo ( g_ roles ) serão concedidos com os r_ roles , então eles serão uma coleção de r_ roles. E, finalmente, as funções de usuário serão concedidas com uma ou mais funções de grupo e serão aquelas com o privilégio de login.
Vamos mostrar um exemplo disso. Criaremos um grupo somente leitura para o example_schema e o concederemos a um usuário:
Criamos a função somente leitura e concedemos privilégios de objeto a ela
CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;Criamos o grupo somente leitura e concedemos a função a esse grupo
CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;Criamos a função app_user e a fazemos "ingressar" no grupo somente leitura
CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;Usando esse método, você pode gerenciar a granularidade dos privilégios e pode conceder e revogar facilmente grupos de acesso aos usuários. Lembre-se de conceder privilégios de objeto apenas às funções em vez de fazê-lo diretamente para os usuários e conceder o privilégio de login apenas aos usuários.
Essa é uma boa prática para revogar explicitamente os privilégios públicos nos objetos, como revogar o acesso público a um banco de dados específico e concedê-lo apenas por meio de uma função.
REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;Restrinja o acesso do SUPERUSER, permita conexões de superusuário apenas do domínio localhost/unix.
Use usuários específicos para diferentes propósitos, como usuários de aplicativos específicos ou usuários de backup, e limite as conexões para esse usuário apenas a partir dos ips necessários.
4. Gerenciamento de superusuários
Manter uma política de senha forte é uma obrigação para manter seus bancos de dados seguros e evitar hacks de senhas. Para uma política forte, use preferencialmente caracteres especiais, números, letras maiúsculas e minúsculas e tenha pelo menos 10 caracteres.
Também existem ferramentas de autenticação externas, como LDAP ou PAM, que podem ajudá-lo a garantir a expiração de sua senha e a política de reutilização, além de lidar com o bloqueio de contas em caso de erros de autenticação.
5. Criptografia de dados (na conexão SSL)
O PostgreSQL tem suporte nativo para usar conexões SSL para criptografar comunicações cliente/servidor para aumentar a segurança. SSL (Secure Sockets Layer) é a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor web e um navegador. Esse link garante que todos os dados transmitidos entre o servidor da Web e os navegadores permaneçam privados e integrais.
Como os clientes postgresql enviam consultas em texto simples e os dados também são enviados sem criptografia, eles ficam vulneráveis à falsificação de rede.
Você pode habilitar o SSL configurando o parâmetro ssl como on em postgresql.conf.
O servidor escutará as conexões normais e SSL na mesma porta TCP e negociará com qualquer cliente conectado se deve usar SSL. Por padrão, isso fica a critério do cliente, mas você tem a opção de configurar o servidor para exigir o uso de SSL para algumas ou todas as conexões usando o arquivo de configuração pg_hba descrito acima.
6. Criptografia de dados em repouso (pg_crypto)
Existem dois tipos básicos de criptografia, uma via e duas vias. De certa forma, você nunca se preocupa em descriptografar os dados em um formato legível, mas apenas deseja verificar se o usuário sabe qual é o texto secreto subjacente. Isso normalmente é usado para senhas. Na criptografia bidirecional, você deseja a capacidade de criptografar dados e permitir que usuários autorizados os descriptografem em um formato significativo. Dados como cartões de crédito e SSNs cairiam nesta categoria.
Para criptografia unidirecional, a função crypt empacotada no pgcrypto fornece um nível adicional de segurança acima da forma md5. A razão é que com md5, você pode dizer quem tem a mesma senha porque não há salt (Na criptografia, um salt é um dado aleatório que é usado como uma entrada adicional para uma função unidirecional que "hashe" dados, uma senha ou senha), então todas as pessoas com a mesma senha terão a mesma string md5 codificada. Com a cripta, eles serão diferentes.
Para os dados que você deseja recuperar, você não deseja saber se as duas informações são iguais, mas não conhece essas informações e deseja que apenas usuários autorizados possam recuperá-las. O Pgcrypto fornece várias maneiras de fazer isso, portanto, para ler mais sobre como usá-lo, você pode verificar a documentação oficial do postgresql em https://www.postgresql.org/docs/current/static/pgcrypto.html.
7. Registro
O Postgresql fornece uma ampla variedade de parâmetros de configuração para controlar o que, quando e onde registrar.
Você pode habilitar conexões/desconexões de sessão, consultas de longa duração, tamanhos de arquivos temporários e assim por diante. Isso pode ajudá-lo a conhecer melhor sua carga de trabalho para identificar comportamentos estranhos. Você pode obter todas as opções de log no seguinte link https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html
Para obter informações mais detalhadas sobre sua carga de trabalho, você pode habilitar o módulo pg_stat_statements, que fornece um meio de rastrear estatísticas de execução de todas as instruções SQL executadas por um servidor. Existem algumas ferramentas de segurança que podem ingerir os dados desta tabela e irão gerar uma whitelist sql, a fim de ajudá-lo a identificar consultas que não seguem os padrões esperados.
Para obter mais informações https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
8. Auditoria
A extensão de auditoria do PostgreSQL (pgAudit) fornece registro detalhado de auditoria de sessão e/ou objeto por meio do recurso de registro padrão do PostgreSQL.
O log de instrução básico pode ser fornecido pelo recurso de log padrão com log_statement =all. Isso é aceitável para monitoramento e outros usos, mas não fornece o nível de detalhes geralmente necessário para uma auditoria. Não é suficiente ter uma lista de todas as operações realizadas no banco de dados. Também deve ser possível encontrar declarações particulares que sejam de interesse de um auditor. O recurso de registro padrão mostra o que o usuário solicitou, enquanto o pgAudit se concentra nos detalhes do que aconteceu enquanto o banco de dados atendeu à solicitação.
9. Aplicação de patches
Verifique a página de informações de segurança do PostgreSQL regularmente e com frequência para atualizações e patches de segurança críticos.
Lembre-se de que os bugs de segurança do sistema operacional ou das bibliotecas também podem levar a um vazamento de banco de dados, portanto, certifique-se de manter os patches atualizados.
O ClusterControl fornece um relatório operacional que fornece essas informações e executará os patches e atualizações para você.
10. Segurança em nível de linha
Além do sistema de privilégios padrão SQL disponível por meio do GRANT, as tabelas podem ter políticas de segurança de linha que restringem, por usuário, quais linhas podem ser retornadas por consultas normais ou inseridas, atualizadas ou excluídas por comandos de modificação de dados. Esse recurso também é conhecido como segurança em nível de linha.
Quando a segurança de linha está habilitada em uma tabela, todo o acesso normal à tabela para selecionar ou modificar linhas deve ser permitido por uma política de segurança de linha.
Aqui está um exemplo simples de como criar uma política na relação de conta para permitir que apenas membros da função de gerente acessem linhas e apenas linhas de suas contas:
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);Você pode obter mais informações sobre esse recurso na documentação oficial do postgresql https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
Se você quiser saber mais, aqui estão alguns recursos que podem ajudá-lo a fortalecer melhor a segurança do seu banco de dados…
- https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
- https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
- https://www.postgresql.org/docs/current/static/pgcrypto.html
- http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
- https://github.com/pgaudit/pgaudit
- https://www.postgresql.org/docs/9.6/static/pgstatstatements.html
Conclusão
Se você seguir as dicas acima seu servidor estará mais seguro, mas isso não significa que ele será inquebrável.
Para sua própria segurança, recomendamos que você use uma ferramenta de teste de segurança como o Nessus, para saber quais são suas principais vulnerabilidades e tentar resolvê-las.
Você também pode monitorar seu banco de dados com ClusterControl. Com isso você pode ver em tempo real o que está acontecendo dentro do seu banco de dados e analisá-lo.
