Gestão de acessos no Azure HorizonDB (Pré-visualização)

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

Gestão de funções

A melhor forma de gerir Azure permissões de acesso à base de dados HorizonDB em larga escala é utilizando 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 possuir os objetos de banco de dados e atribuir privilégios nesses objetos a outras funções para controlar quem tem acesso a quais objetos. Pode conceder a pertença a uma função a outra função, o que permite à função membro utilizar os privilégios atribuídos à outra função. O Azure HorizonDB permite conceder permissões diretamente aos utilizadores da base de dados. Como 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 acesso. Atribua as funções apropriadas a cada usuário. Use funções para impor um modelo de privilégios mínimos para acessar objetos de banco de dados.

Para além dos papéis incorporados que o PostgreSQL cria, o cluster Azure HorizonDB inclui três papéis 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

Quando cria o cluster do Azure HorizonDB, fornece credenciais para um administrator role. Usa isto administrator role para criar mais funções PostgreSQL.

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

CREATE USER exampleuser PASSWORD password123;

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

Em ambientes PaaS baseados na cloud, o acesso a uma conta de superutilizador do Azure HorizonDB está restrito apenas a operações no plano de controlo. O papel azuresu tem privilégios de superutilizador, mas a conta de administrador do cluster Azure HorizonDB não faz parte do papel azuresu.

A função azure_pg_admin existe enquanto conta de pseudo-superutilizador. O login de administrador que configurou ao criar o cluster é membro da azure_pg_admin função.

Pode auditar periodicamente a lista de funções no seu cluster.

Por exemplo, você pode se conectar usando o psql cliente e consultar a pg_roles tabela, que lista todas as funções junto com 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

Gerir o acesso ao esquema

As bases de dados recém-criadas no Azure HorizonDB incluem um conjunto padrão de privilégios no esquema público da base de dados que concedem a todos os utilizadores e papéis da base de dados a capacidade de criar objetos. Para limitar melhor o acesso dos utilizadores da aplicação às bases de dados que cria na sua instância do Azure HorizonDB, considere revogar estes privilégios públicos predefinidos. Depois de revogar esses privilégios, conceda privilégios específicos aos usuários do banco de dados em uma base mais granular. Por exemplo:

• Revogue os privilégios de criação no esquema public da função public para impedir que os utilizadores da base de dados da aplicação criem objetos no esquema público.

  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  

• Crie um novo banco de dados.

  CREATE DATABASE Test_db;
  

• Revogue todos os privilégios do esquema PUBLIC neste novo banco de dados.

  REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
  

• Crie uma função personalizada para usuários do banco de dados do aplicativo.

  CREATE ROLE Test_db_user;
  

• Dê 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 de 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 utilizador utilizador1 pode ligar-se e tem todos os privilégios na base de dados de teste Test_db, mas não em qualquer outra base de dados do cluster. Em vez de conceder a esse usuário ou função TODOS os PRIVILÉGIOS nesse banco de dados e seus objetos, considere fornecer permissões mais seletivas, como SELECT, INSERT, EXECUTEe outros. Para obter mais informações sobre privilégios em bancos de dados PostgreSQL, consulte os comandos GRANT e REVOKE nos documentos do PostgreSQL.

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

No Azure HorizonDB, o esquema público pertence ao papel azure_pg_admin em todas as versões suportadas do PostgreSQL.

Controlo melhorado para azure_pg_admin

No Azure HorizonDB, o azure_pg_admin papel é um papel restrito gerido pelo sistema que não pode ser modificado. Se tentares alterá-la, por exemplo atribuindo-lhe outro papel, recebes um erro como:

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

Esta restrição é uma salvaguarda incorporada 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 em vez disso e conceder as permissões necessárias para essa função.

O Azure HorizonDB melhora as capacidades da azure_pg_admin função em todas as versões do PostgreSQL. Os membros do azure_pg_admin papel podem gerir funções e aceder a objetos pertencentes a qualquer função não restrita, mesmo que esses papéis também sejam membros de azure_pg_admin. Esta funcionalidade garante que os utilizadores administrativos mantenham um controlo consistente e abrangente sobre a gestão de funções e permissões, proporcionando uma experiência fluida e fiável sem necessidade de acesso de superutilizador.

Segurança a nível de linha

Segurança ao nível de linha (RLS) é uma funcionalidade de segurança do Azure HorizonDB que permite aos administradores de bases de dados definir políticas que controlam como linhas específicas de dados são exibidas e operam para uma ou mais funções. A segurança ao nível das linhas adiciona um filtro extra a uma tabela de base de dados do 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 reduzidos 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 , ou DELETEespecificá-las para todos os comandos. Os casos de uso para segurança em nível de linha incluem implementações compatíveis com PCI, ambientes classificados e hospedagem compartilhada ou aplicativos multilocatário.

Apenas os utilizadores com permissões SET ROW SECURITY podem aplicar permissões de segurança ao nível da linha a uma tabela. O proprietário da tabela pode definir a segurança ao nível da linha numa tabela. Tal como OVERRIDE ROW SECURITY, este direito é atualmente um direito implícito. A segurança em nível de linha não substitui as permissões existentes GRANT . Ele adiciona um nível mais refinado de controle. 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 SELECT privilégios na coluna ou tabela em questão.

O exemplo a seguir mostra como criar uma política que garante que apenas os membros da funçãode gerente personalizada 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 gestor não possam realizar operações SELECT, DELETE ou UPDATE em linhas que pertencem a outros gestores, nem possam INSERT novas linhas pertencentes a outro gestor.

Pode eliminar uma política de segurança ao nível da linha utilizando o comando DROP POLICY, como 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 nenhum dado que pertença a nenhum outro gerente. Essa restrição existe porque a diretiva 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 as permissões BYPASSRLS e NOBYPASSRLS que pode atribuir a uma função. Por predefinição, a NOBYPASSRLS permissão é atribuída. No Azure HorizonDB, o privilégio de contornar a segurança ao nível da linha (BYPASSRLS) funciona da seguinte forma:

• Utilizadores não administrativos criados pelo azure_pg_admin papel de administrador podem criar papéis com o BYPASSRLS atributo ou privilégio conforme necessário.

• Utilize o utilizador azure_pg_admin para realizar tarefas administrativas que exijam o privilégio BYPASSRLS.

Conteúdo relacionado

• Proteja o seu Azure HorizonDB (Pré-visualização)