Todos os produtos
Search
Central de documentação

AnalyticDB:Permission management by using views

Última atualização: Jun 27, 2026

As views permitem expor um subconjunto filtrado de uma tabela para contas específicas sem conceder acesso direto à tabela subjacente. Esse mecanismo é eficaz para controle de acesso no nível de linha: cada conta consulta apenas a view sobre a qual possui permissão, e o AnalyticDB for MySQL aplica o filtro definido na view.

Como funciona

Ao criar uma view com SQL SECURITY DEFINER, ela executa com as permissões do criador (o definer), e não da conta que realiza a consulta. Isso significa que:

  • Contas com permissão SELECT em uma view podem consultá-la sem precisar de nenhuma permissão na tabela subjacente.

  • O AnalyticDB for MySQL aplica automaticamente a cláusula WHERE da view, garantindo que as contas visualizem apenas as linhas expostas por ela.

Essa abordagem permite isolar dados entre contas ao criar uma view por partição de dados e conceder a cada conta acesso à sua view correspondente.

Cenário

Uma tabela customer armazena registros de clientes de várias províncias. O objetivo é conceder ao user1 acesso apenas aos registros da Província 1 (province_id=1) e ao user2 acesso apenas aos registros da Província 2 (province_id=2).

Definição da tabela:

CREATE TABLE `customer` (
  `id`          bigint AUTO_INCREMENT,
  `province_id` bigint NOT NULL,
  `user_info`   varchar,
  PRIMARY KEY (`id`)
) DISTRIBUTED BY HASH(`id`);

Dados de teste:

INSERT INTO customer (province_id, user_info)
VALUES (1, 'Tom'), (1, 'Jerry'), (2, 'Jerry'), (3, 'Mark');

A tabela completa contém quatro linhas distribuídas em três províncias:

+---------------------+-------------+-----------+
| id                  | province_id | user_info |
+---------------------+-------------+-----------+
| 1369417242420617216 |           1 | Tom       |
| 1369417242424811520 |           1 | Jerry     |
| 1369417242424811522 |           3 | Mark      |
| 1369417242424811521 |           2 | Jerry     |
+---------------------+-------------+-----------+

Configurar controle de acesso baseado em views

Pré-requisitos

Antes de começar, verifique se você possui:

  • Um cluster AnalyticDB for MySQL com o banco de dados adb_demo

  • Privilégios de administrador para criar views e conceder permissões

  • As contas user1 e user2 já criadas (consulte CREATE USER)

Etapa 1: Crie views para cada província

Crie uma view por província. Cada view filtra a tabela customer para um province_id específico. A cláusula SQL SECURITY DEFINER faz com que a view execute com as permissões do criador, eliminando a necessidade de as contas que consultam a view terem acesso direto à tabela customer.

-- View for Province 1: exposes only rows where province_id = 1
CREATE SQL SECURITY DEFINER VIEW v1 AS
  SELECT * FROM customer WHERE province_id = 1;

-- View for Province 2: exposes only rows where province_id = 2
CREATE SQL SECURITY DEFINER VIEW v2 AS
  SELECT * FROM customer WHERE province_id = 2;

Para obter a sintaxe completa e os parâmetros de CREATE VIEW, consulte CREATE VIEW.

Etapa 2: Conceder acesso de cada conta à sua view

Conceda SELECT na view em vez de na tabela subjacente. Dessa forma, cada conta lê apenas as linhas expostas pela view atribuída, e a tabela customer permanece inacessível para ambas as contas.

-- user1 can query v1 (Province 1 data only).
-- Granting on the view, not on customer, prevents user1 from accessing other provinces.
GRANT SELECT ON v1 TO user1;

-- user2 can query v2 (Province 2 data only).
-- Granting on the view, not on customer, prevents user2 from accessing other provinces.
GRANT SELECT ON v2 TO user2;

Verifique o resultado

Conecte-se ao banco de dados adb_demo com cada conta e execute um SELECT na view atribuída. O exemplo a seguir mostra tanto a consulta permitida quanto a negada para cada conta.

Como user1:

-- user1 has SELECT on v1. This query returns Province 1 rows only.
SELECT * FROM v1;
+---------------------+-------------+-----------+
| ID                  | PROVINCE_ID | USER_INFO |
+---------------------+-------------+-----------+
| 1369417242420617216 |           1 | Tom       |
| 1369417242424811520 |           1 | Jerry     |
+---------------------+-------------+-----------+
-- user1 has no permission on v2. This query is denied.
SELECT * FROM v2;
ERROR 1815 (HY000): [9001, 2021083114191719216818804803453965343] : Access Denied

Como user2:

-- user2 has SELECT on v2. This query returns Province 2 rows only.
SELECT * FROM v2;
+---------------------+-------------+-----------+
| ID                  | PROVINCE_ID | USER_INFO |
+---------------------+-------------+-----------+
| 1369417242424811521 |           2 | Jerry     |
+---------------------+-------------+-----------+
-- user2 has no permission on v1. This query is denied.
SELECT * FROM v1;
ERROR 1815 (HY000): [9001, 2021083114191719216818804803453965343] : Access Denied

Próximos passos

  • Adapte esse padrão para outras províncias criando uma view para cada valor de province_id e concedendo à conta correspondente a permissão SELECT nessa view.

  • Para revogar o acesso, execute REVOKE SELECT ON <view_name> FROM <account_name>.

  • Para referência completa das opções de criação de views, consulte CREATE VIEW.