Segurança no Banco de Dados do Azure para PostgreSQL – Servidor Flexível

Artigo
04/28/2024

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

Há várias camadas de segurança disponíveis para ajudar a proteger os dados em sua instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Este artigo descreve essas opções de segurança.

Proteção e criptografia de informações

O Banco de Dados do Azure para PostgreSQL - Servidor Flexível criptografa os dados de duas maneiras:

Dados em trânsito: o Banco de Dados do Azure para PostgreSQL - Servidor Flexível criptografa os dados em trânsito com os protocolos SSL e TLS. A criptografia é imposta por padrão. Para obter informações mais detalhadas sobre segurança de conexão com SSL\TLS, consulte esta documentação. Para obter uma melhor segurança, você pode optar por habilitar a autenticação SCRAM no Banco de Dados do Azure para PostgreSQL – Servidor Flexível.

Embora seja altamente não recomendado, se necessário, devido à incompatibilidade do cliente herdado, você tem a opção de desabilitar o TLS\SSL para conexões com o Banco de Dados do Azure para PostgreSQL – Servidor Flexível atualizando o parâmetro do servidor require_secure_transport para DESATIVADO. Você também pode definir a versão do TLS definindo os parâmetros do servidor ssl_max_protocol_version.
Dados inativos: para criptografia de armazenamento, o Banco de Dados do Azure para PostgreSQL - Servidor Flexível usa o módulo criptográfico validado pelo FIPS 140-2. Os dados, incluindo backups, são criptografados no disco, assim como os arquivos temporários criados durante a execução de consultas.

O serviço usa a criptografia AES de 256 bits incluída na criptografia de armazenamento do Azure e as chaves são gerenciadas pelo sistema. Isso é semelhante a outras tecnologias de criptografia de dados inativos, como a TDE (Transparent Data Encryption) em bancos de dados do SQL Server ou Oracle. A criptografia de armazenamento está sempre ativada e não pode ser desabilitada.

Segurança de rede

Ao executar o Banco de Dados do Azure para PostgreSQL – Servidor Flexível, você tem duas opções de rede principais:

Acesso privado: você pode implantar seu servidor flexível em uma rede virtual do Azure. As redes virtuais do Azure fornecem comunicação de rede privada e segura. Os recursos em uma rede virtual podem se comunicar por meio de endereços IP privados. Para mais informações, confira Visão geral da rede – Banco de Dados do Azure para PostgreSQL – Servidor flexível.

As regras de segurança em grupos de segurança de rede permitem filtrar o tipo de tráfego de rede que pode fluir para dentro e fora das sub-redes da rede virtual e dos adaptadores de rede. Para saber mais, confira Visão geral dos grupo de segurança de rede.
Acesso público: o servidor flexível pode ser acessado por meio de um ponto de extremidade público. O ponto de extremidade público é um endereço DNS que poderia ser resolvido publicamente. O acesso a ele é protegido por meio de um firewall que bloqueia todas as conexões por padrão.

As regras de firewall de IP permitem acesso ao servidor com base no endereço IP de origem de cada solicitação. Para obter mais informações, consulte a visão geral de regras de firewall.

Suporte para o Microsoft Defender para Nuvem

O Microsoft Defender para bancos de dados relacionais de código aberto detecta atividades anômalas que indicam tentativas incomuns e potencialmente prejudiciais de acessar ou explorar bancos de dados. O Defender para Nuvem fornece alertas de segurança sobre atividades anômalas para que você possa detectar possíveis ameaças e responder a elas à medida que ocorrem. Quando você habilita esse plano, o Defender para Nuvem fornece alertas quando detectar padrões anômalos de consulta e acesso a banco de dados e atividades suspeitas no banco de dados.

Esses alertas aparecem na página de alertas de segurança do Defender para Nuvem e incluem:

Detalhes da atividade suspeita que os disparou
A tática associada do MITRE ATT&CK
Ações recomendadas sobre como investigar e mitigar a ameaça
Opções para continuar as investigações com o Microsoft Sentinel

Microsoft Defender para Nuvem e ataques de força bruta

Um ataque de força bruta está entre os métodos de hacking mais comuns e bastante bem-sucedidos, apesar de serem métodos de hacking menos sofisticados. A teoria por trás de tal ataque é que, se você fizer um número infinito de tentativas de adivinhar uma senha, só poderá estar certo eventualmente. Quando o Microsoft Defender para Nuvem detecta um ataque de força bruta, ele dispara um alerta para conscientizá-lo de que ocorreu um ataque de força bruta. Ele também pode separar o ataque de força bruta simples do ataque de força bruta em um usuário válido ou um ataque de força bruta bem-sucedido.

Para receber alertas do plano do Microsoft Defender, primeiro você precisa habilitá-lo, conforme mostrado na próxima seção.

Habilitar a segurança aprimorada com o Microsoft Defender para Nuvem

No portal do Azure, navegue até o menu Segurança no painel esquerdo
Escolha Microsoft Defender para Nuvem
Selecione Habilitar no painel direito.

Observação

Se você tiver o recurso "bancos de dados relacionais de software livre" habilitado em seu plano do Microsoft Defender, observará que o Microsoft Defender está habilitado automaticamente por padrão para o recurso de servidor flexível do Banco de Dados do Azure para PostgreSQL.

Gerenciamento de acesso

A melhor maneira de gerenciar as permissões de acesso ao banco de dados do Banco de Dados do Azure para PostgreSQL - Servidor Flexível em escala é usar o conceito de funções. Uma função pode ser um usuário de banco de dados ou um grupo de usuários de banco de dados. As funções podem ser proprietárias dos objetos de banco de dados e atribuir privilégios nesses objetos a outras funções para controlar quem tem acesso a quais objetos. Também é possível conceder a associação de uma função a outra função, permitindo assim que a função membro use privilégios atribuídos a outra função. O Banco de Dados do Azure para PostgreSQL - Servidor Flexível permite conceder permissões diretamente aos usuários do banco de dados. Como uma boa prática de segurança, recomendamos que você crie funções com conjuntos específicos de permissões com base nos requisitos mínimos de acesso e do aplicativo. Em seguida, você pode atribuir as funções apropriadas a cada usuário. As funções são usadas para impor um modelo de privilégios mínimos para acessar os objetos de banco de dados.

A instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível é criada com as três funções padrão definidas. Você pode ver essas funções executando o comando:

SELECT rolname FROM pg_roles;

azure_pg_admin
azuresu
função de administrador

Ao criar a instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível, forneça credenciais para uma função de administrador. Essa função Administrador pode ser usado para criar funções adicionais do PostgreSQL.
Por exemplo, abaixo podemos criar um usuário/função de exemplo chamado demouser,

postgres=> CREATE USER demouser PASSWORD 'password123';

A função Administrador nunca deve ser usada pelo aplicativo.

Em ambientes PaaS baseados em nuvem, o acesso a uma conta de superusuário do Banco de Dados do Azure para PostgreSQL - Servidor Flexível é restrito a operações de plano de controle apenas por operadores de nuvem. Portanto, a conta azure_pg_admin existe como uma conta de pseudo-superusuário. Sua função de administrador é um membro da função azure_pg_admin.
No entanto, a conta de administrador do servidor não faz parte da função azuresu, que tem privilégios de superusuário e é usada para executar operações de plano de controle. Como esse serviço é um serviço gerenciado de PaaS, somente a Microsoft faz parte da função de superusuário.

Observação

Várias permissões exclusivas de superusuário, como a criação de determinadas conversões implícitas, não estão disponíveis no Banco de Dados do Azure para PostgreSQL - Servidor Flexível, pois a função azure_pg_admin não está alinhada às permissões da função de superusuário do PostgreSQL.

Você pode auditar periodicamente a lista de funções no servidor. Por exemplo, você pode se conectar usando o cliente psql e consultar a tabela pg_roles que lista todas as funções junto com os privilégios, como criar funções adicionais, criar bancos de dados, replicação etc.

postgres=> \x
Expanded display is on.
postgres=> select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

O Log de auditoria no Banco de Dados do Azure para PostgreSQL – Servidor Flexível também está disponível no Banco de Dados do Azure para PostgreSQL – Servidor Flexível para acompanhar a atividade em seus bancos de dados.

Controlar o acesso ao esquema

Os bancos de dados recém-criados no Banco de Dados do Azure para PostgreSQL - Servidor Flexível têm um conjunto padrão de privilégios no esquema público do banco de dados que permite que todos os usuários e funções do banco de dados criem objetos. Para limitar melhor o acesso do usuário do aplicativo aos bancos de dados que você cria na instância do Banco de Dados do Azure para PostgreSQL - Servidor Flexível, recomendamos que você considere revogar esses privilégios públicos padrão. Depois de fazer isso, é possível conceder privilégios específicos aos usuários do banco de dados de forma mais granular. Por exemplo:

Para evitar que os usuários do banco de dados do aplicativo criem objetos no esquema público, revogue os privilégios de criação de esquema public da função public.
```
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
```
Em seguida, crie o novo banco de dados.
```
CREATE DATABASE Test_db;
```
Revogue todos os privilégios para o esquema PUBLIC neste novo banco de dados.
```
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
```
Criar função personalizada para usuários do banco de dados do aplicativo
```
CREATE ROLE Test_db_user;
```

Conceda aos usuários do banco de dados com essa função a capacidade de se conectar ao banco de dados.

GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;

Criar usuário do banco de dados

CREATE USER user1 PASSWORD 'Password_to_change'

Atribuir função, com seus privilégios de conexão e seleção, ao usuário
```
GRANT Test_db_user TO user1;
```

Neste exemplo, o usuário user1 pode se conectar e tem todos os privilégios em nosso banco de dados de teste Test_db, mas não em qualquer outro banco de dados no servidor. Além disso, seria recomendável, em vez de conceder a esse usuário\função ALL PRIVILEGES para o banco de dados e seus objetos, você conceda a ele permissões mais seletivas, como SELECT, INSERT, EXECUTE etc. Para obter mais informações sobre privilégios em bancos de dados PostgreSQL, consulte os comandos GRANT e REVOKE na documentação do PostgreSQL.

Alterações do PostgreSQL 16 com segurança baseada em função

Na função de banco de dados do PostgreSQL pode ter muitos atributos que definem seus privilégios. Um desses atributos é o atributo CREATEROLE, que é importante para o gerenciamento de banco de dados do PostgreSQL de usuários e funções. No PostgreSQL 16, foram introduzidas alterações significativas nesse atributo. No PostgreSQL 16, os usuários com o atributo CREATEROLE não têm mais a capacidade de distribuir a associação em qualquer função para qualquer pessoa; em vez disso, como outros usuários, sem esse atributo, eles só podem distribuir associações em funções para as quais possuemADMIN OPTION. Além disso, no PostgreSQL 16, o atributo CREATEROLE ainda permite que um não superusuário provisione novos usuários, mas ele só pode remover usuários que ele mesmo criou. As tentativas de remover usuários, que não foram criados por um usuário com o atributo CREATEROLE, resultarão em um erro.

O PostgreSQL 16 também apresentou funções internas novas e aprimoradas. A nova função pg_use_reserved_connections no PostgreSQL 16 permite o uso de slots de conexão reservados via reserved_connections. A função pg_create_subscription permite que os superusuários criem assinaturas.

Segurança em nível de linha

A RLS (segurança em nível de linha) é um recurso de segurança do Banco de Dados do Azure para PostgreSQL - Servidor Flexível que permite aos administradores de banco de dados definir políticas para controlar como linhas específicas de dados são exibidas e operadas para uma ou mais funções. A segurança em nível de linha é um filtro adicional que você pode aplicar a uma tabela de banco de dados do Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Quando um usuário tenta executar uma ação em uma tabela, esse filtro é aplicado antes dos critérios de consulta ou outra filtragem, e os dados são restringidos ou rejeitados de acordo com sua política de segurança. Você pode criar políticas de segurança em nível de linha para comandos específicos, como SELECT, INSERT, UPDATE e DELETE ou especificá-las para TODOS os comandos. Os casos de uso para segurança em nível de linha incluem implementações em conformidade com PCI, ambientes classificados e aplicativos de hospedagem compartilhada/multilocatários.

Somente os usuários com direitos SET ROW SECURITY podem aplicar direitos de segurança de linha a uma tabela. O proprietário da tabela poderá definir a segurança de linha em uma tabela. Como OVERRIDE ROW SECURITY, atualmente, esse é um direito implícito. A segurança em nível de linha não substitui as permissões GRANT existentes, mas adiciona um nível de controle mais refinado. Por exemplo, a configuração ROW SECURITY FOR SELECT para permitir que um determinado usuário forneça linhas só dará acesso a esse usuário se ele também tiver privilégios SELECT na coluna ou na tabela em questão.

Este é um exemplo que mostra como criar uma política que garante que apenas os membros da função"gerente" criada personalizada possam acessar somente as linhas de uma conta específica. O código do exemplo a seguir foi compartilhado na documentação do PostgreSQL.

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);

A cláusula USING adiciona implicitamente uma cláusula WITH CHECK, garantindo que os membros da função de gerente não possam executar operações SELECT, DELETE ou UPDATE em linhas que pertencem a outros gerentes e não possam executar INSERT em novas linhas pertencentes a outro gerente. Você pode eliminar uma política de segurança de linha usando o comando DROP POLICY, como em seu exemplo:



DROP POLICY account_managers ON accounts;

Embora você possa ter descartado a política, o gerente de função ainda não consegue visualizar nenhum dado que pertença a qualquer outro gerente. Isso ocorre porque a política de segurança em nível de linha ainda está habilitada na tabela de contas. Se a segurança em nível de linha estiver habilitada por padrão, o PostgreSQL usará uma política de negação padrão. Você pode desabilitar a segurança em nível de linha, como no exemplo abaixo:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Como ignorar a Segurança em Nível de Linha

O PostgreSQL tem as permissões BYPASSRLS e NOBYPASSRLS, que podem ser atribuídas a uma função. NOBYPASSRLS é atribuído por padrão. Com servidores recém-provisionados no Banco de Dados do Azure para PostgreSQL – Servidor Flexível, é possível implementar o recurso para ignorar o privilégio da Segurança em Nível de Linha (BYPASSRLS) da seguinte maneira:

Para os servidores Postgres 16 e superior, seguimos o comportamento padrão do PostgreSQL 16. Os usuários não administrativos criados pela função de administrador azure_pg_admin permitem que você crie funções com o atributo BYPASSRLS\privilege, conforme necessário.
Para servidores Postgres 15 e com versões inferiores. , você pode usar o usuário azure_pg_admin para realizar tarefas administrativas que exigem o privilégio BYPASSRLS, mas não pode criar usuários não administradores com o privilégio BypassRLS, pois a função de administrador não tem privilégios de superusuário, comum em serviços de PostgreSQL PaaS baseados em nuvem.

Atualizar senhas

Para maior segurança, é uma boa prática alternar periodicamente a senha do administrador e as senhas dos usuários do banco de dados. Recomendamos usar senhas fortes usando letras maiúsculas e minúsculas, números e caracteres especiais.

Usar SCRAM

O SCRAM (Mecanismo de Autenticação de Resposta do Desafio Salted) melhora muito a segurança da autenticação de usuário baseada em senha adicionando vários recursos de segurança importantes que impedem ataques de tabela arco-íris, ataques man-in-the-middle e ataques de senha armazenados, ao mesmo tempo em que adiciona suporte para vários algoritmos de hash e senhas que contêm caracteres não ASCII.

Se o driver cliente der suporte ao SCRAM, você poderá configurar o acesso ao Banco de Dados do Azure para PostgreSQL – Servidor Flexível usando SCRAM como scram-sha-256 versus padrãomd5.

Redefinir a senha de administrador

Siga o guia de instruções para redefinir a senha de administrador.

Atualizar a senha de usuário do banco de dados

Você pode usar ferramentas de cliente para atualizar as senhas de usuário do banco de dados.
Por exemplo,

postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE