Gerenciamento de acesso no Azure HorizonDB (versão prévia)

Gerenciar o acesso ao seu Azure HorizonDB é uma parte importante da manutenção da segurança e da conformidade. Este artigo explica como usar as funções do PostgreSQL e os recursos do Azure para controlar permissões e implementar práticas recomendadas para o gerenciamento de acesso.

Gestão de funções

A melhor maneira de gerenciar permissões de acesso de banco de dados Azure HorizonDB em escala é usando o conceito de roles. 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. Você pode conceder a associação em uma função a outra função, o que permite que a função membro use privilégios atribuídos a outra função. Azure HorizonDB permite conceder permissões diretamente aos usuários do banco de dados. Como uma boa prática de segurança, crie funções com conjuntos específicos de permissões com base nos requisitos mínimos de aplicativo e de acesso. Atribua as funções apropriadas a cada usuário. Use funções para impor um modelo de privilégio mínimo para acessar objetos do banco de dados.

Além das funções internas que o PostgreSQL cria, o cluster Azure HorizonDB inclui três funções padrão. Você pode ver essas funções executando o seguinte comando:

SELECT rolname FROM pg_roles;

As funções são:

• azure_pg_admin
• azuresu
• administrator role

Ao criar o cluster Azure HorizonDB, você fornece credenciais para um administrator role. Use isso administrator role para criar mais funções PostgreSQL.

Por exemplo, você pode criar um usuário ou uma função chamada exampleuser.

CREATE USER exampleuser PASSWORD password123;

Não use a função de administrador no aplicativo.

Em ambientes paaS baseados em nuvem, o acesso a uma conta de superusuário do Azure HorizonDB é restrito apenas a operações de plano de controle. A função azuresu tem privilégios de superusuário, mas a conta de administrador de cluster do Azure HorizonDB não faz parte da função azuresu.

A função azure_pg_admin existe como uma conta pseudo-superusuário. O login de administrador que você configurou ao criar o cluster é membro da função azure_pg_admin.

Você pode auditar periodicamente a lista de funções em seu cluster.

Por exemplo, você pode se conectar usando o cliente psql e consultar a tabela pg_roles, que lista todas as funções juntamente com os privilégios, como criar outras funções, criar bancos de dados, replicação e muito mais.

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

Controlar o acesso ao esquema

Os bancos de dados recém-criados no Azure HorizonDB incluem um conjunto padrão de privilégios no esquema público do banco de dados que concede a todos os usuários e funções de banco de dados a capacidade de criar objetos. Para limitar melhor o acesso do usuário do aplicativo aos bancos de dados criados na instância do Azure HorizonDB, considere revogar esses privilégios públicos padrão. Depois de revogar esses privilégios, conceda privilégios específicos aos usuários do banco de dados de forma mais granular. Por exemplo:

• Revogue os privilégios de criação no esquema public da função public a fim de impedir que os usuários do banco de dados do aplicativo criem objetos no esquema público.

  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  

• Criar um 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;
  

• Crie uma função personalizada para os 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;
  

• Crie um usuário do banco de dados.

  CREATE USER user1 PASSWORD 'Password_to_change'
  

• Atribua a 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 1 pode se conectar e tem todos os privilégios no banco de dados de teste Test_db, mas não qualquer outro banco de dados no cluster. Em vez de dar a esse usuário ou função ALL PRIVILEGES nesse banco de dados e nos seus objetos, considere fornecer permissões mais seletivas, como SELECT, INSERT, EXECUTE e outras. Para obter mais informações sobre privilégios nos bancos de dados PostgreSQL, consulte os comandos GRANT e REVOKE nos documentos do PostgreSQL.

Alterações de propriedade de esquema público no Azure HorizonDB

No Azure HorizonDB, o esquema público pertence à função azure_pg_admin em todas as versões do PostgreSQL com suporte.

Controle aprimorado para azure_pg_admin

No Azure HorizonDB, a azure_pg_admin função é uma função restrita e gerenciada pelo sistema que você não pode modificar. Se você tentar alterá-la, como concedendo outra função a ela, receberá um erro como:

GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"

Essa restrição é uma proteção interna para evitar alterações em funções administrativas críticas. Se você precisar atribuir privilégios ou funções, considere criar uma função personalizada e conceder as permissões necessárias para essa função.

Azure HorizonDB aprimora os recursos da azure_pg_admin função em todas as versões do PostgreSQL. Os membros da azure_pg_admin função podem gerenciar funções e acessar objetos de propriedade de qualquer função não restrita, mesmo que essas funções também sejam membros de azure_pg_admin. Esse recurso garante que os usuários administrativos mantenham um controle consistente e abrangente sobre o gerenciamento de função e permissão, fornecendo uma experiência perfeita e confiável sem a necessidade de acesso de superusuário.

Segurança em nível de linha

Segurança em nível de linha (RLS) é um recurso de segurança do Azure HorizonDB que permite que administradores de banco de dados definam políticas que controlam como linhas específicas de dados são exibidas e podem ser acessadas por uma ou mais funções. A segurança em nível de linha adiciona um filtro extra a uma tabela de banco de dados Azure HorizonDB. 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 restritos 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, UPDATEe DELETE, ou especifique-as para todos os comandos. Casos de uso para segurança em nível de linha incluem implementações compatíveis com PCI, ambientes classificados e aplicativos de hospedagem compartilhada ou multilocatários.

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

O exemplo a seguir mostra como criar uma política que garante que somente membros da funçãogerente criada sob medida possam acessar apenas as linhas de uma conta específica. O código no exemplo a seguir é 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, DELETEou UPDATE nas linhas que pertencem a outros gerentes e não podem INSERT novas linhas pertencentes a outro gerente.

Você pode remover uma política de segurança de linha usando o comando DROP POLICY, conforme mostrado neste exemplo:

DROP POLICY account_managers ON accounts;

Embora você possa descartar a política, o gerenciador de funções ainda não pode exibir dados que pertençam a outros gerentes. Essa restrição existe 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, conforme mostrado no exemplo a seguir:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Ignorar a segurança em nível de linha

O PostgreSQL inclui BYPASSRLS e NOBYPASSRLS as permissões que você pode atribuir a uma função. Por padrão, a NOBYPASSRLS permissão é atribuída. No Azure HorizonDB, o privilégio de ignorar a segurança em nível de linha (BYPASSRLS) funciona da seguinte maneira:

• Usuários não administradores criados pela azure_pg_admin função de administrador podem criar funções com o BYPASSRLS atributo ou privilégio, conforme necessário.

• Use o azure_pg_admin usuário para executar tarefas administrativas que exigem o BYPASSRLS privilégio.

Conteúdo relacionado

• Proteja seu Azure HorizonDB (Versão Prévia)