Considerações sobre o controle de acesso¶

Uso da função ACCOUNTADMIN¶

O administrador de conta (ou seja, usuários com a função de sistema ACCOUNTADMIN) é a função mais poderosa no sistema. Esta função é a única responsável pela configuração dos parâmetros no nível da conta. Os usuários com a função ACCOUNTADMIN podem visualizar e gerenciar os dados de faturamento e crédito do Snowflake e podem parar qualquer instrução SQL em execução.

Note que ACCOUNTADMIN não é uma função de superusuário. Esta função só permite visualizar e gerenciar objetos na conta se esta função, ou uma função inferior em uma hierarquia de funções, tiver privilégios suficientes sobre os objetos.

Na hierarquia de funções do sistema, as outras funções de administrador são filhas deste função:

• A função de administrador de usuários (USERADMIN) inclui os privilégios para criar e administrar usuários e funções (assumindo que a propriedade dessas funções ou usuários não tenha sido transferida para outra função).

• O administrador de segurança (ou seja, usuários com a função SECURITYADMIN do sistema) inclui o privilégio global MANAGE GRANTS de conceder ou revogar privilégios sobre objetos na conta. A função USERADMIN é um filho desta função na hierarquia padrão de controle de acesso.

• A função de administrador do sistema (SYSADMIN) inclui os privilégios de criar warehouses, bancos de dados e todos os objetos de banco de dados (esquemas, tabelas, etc.).

Acesso a objetos de banco de dados¶

Todos os objetos de banco de dados protegíveis (tais como TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE, etc.) estão contidos dentro de um objeto SCHEMA dentro de um DATABASE. Como resultado, para acessar objetos de banco de dados, além dos privilégios sobre os objetos específicos do banco de dados, os usuários devem ter o privilégio USAGE no banco de dados e esquema de contêiner.

Por exemplo, suponha que mytable seja criado em mydb.myschema. Para consultar mytable, um usuário deve ter, no mínimo, os seguintes privilégios:

Banco de dados:

USAGE para mydb

Esquema:

USAGE para myschema

Tabela:

SELECT para mytable

Gerenciamento de funções personalizadas¶

Quando uma função personalizada é criada, ela existe isoladamente. A função deve ser atribuída a qualquer usuário que utilize os privilégios de objeto associados à função. A função personalizada também deve ser concedida a qualquer função que irá administrar os objetos criados pela função personalizada.

Para instruções para criar uma hierarquia de funções, consulte Criação de uma hierarquia de funções.

Alinhamento do acesso a objetos com funções empresariais¶

Considere tirar proveito das hierarquias de funções para alinhar o acesso aos objetos do banco de dados com as funções empresariais em sua organização. Em uma hierarquia de funções, são atribuídas funções a outras funções para formar uma relação de herança. As permissões concedidas a funções de nível inferior são herdadas por funções de nível superior.

Para flexibilidade ótima no controle de acesso a objetos de banco de dados, crie uma combinação de funções de acesso com diferentes permissões para os objetos e atribua-as conforme apropriado a funções funcionais:

• Conceda permissões para objetos de banco de dados ou objetos de conta (tais como warehouses) para funções de acesso.

• Conceda funções de acesso a funções funcionais para criar uma hierarquia de funções. Estas funções correspondem às funções empresariais de sua organização e servem como um grupo genérico para quaisquer funções de acesso necessárias para estas funções.

  Quando apropriado, conceda funções funcionais de nível inferior a funções funcionais de nível superior em uma relação pai-filho, onde as funções pais mapeiam as funções empresariais que devem incluir as permissões de funções filhas.

  Seguindo as práticas recomendadas para hierarquias de funções, conceda as funções funcionais de mais alto nível em uma hierarquia de funções ao administrador do sistema (SYSADMIN). Os administradores de sistema podem então conceder privilégios sobre objetos de banco de dados a quaisquer funções nesta hierarquia:

Exemplo¶

Como um exemplo simples, suponha que dois bancos de dados em uma conta, fin e hr, contenham dados da folha de pagamento e dos funcionários, respectivamente. Contadores e analistas em sua organização requerem diferentes permissões sobre os objetos desses bancos de dados para desempenhar suas funções empresariais. Os contadores devem ter acesso de leitura-gravação a fin, mas podem precisar apenas de acesso de leitura a hr porque o pessoal de recursos humanos administra os dados neste banco de dados. Os analistas podem precisar de acesso somente leitura a ambos os bancos de dados.

As permissões para objetos de banco de dados existentes são concedidas através da seguinte hierarquia de funções de acesso e funções funcionais:

Nota

Quando novos objetos forem adicionados em cada banco de dados, considere a possibilidade de conceder automaticamente privilégios para os objetos a funções com base no tipo de objeto (por exemplo, esquemas, tabelas ou exibições). Para obter mais informações, consulte Simplificação do gerenciamento de concessões usando concessões futuras (neste tópico).

Função personalizada	Descrição	Privilégios
db_hr_r	Função de acesso que permite acesso somente leitura às tabelas do banco de dados hr.	USAGE para o banco de dados hr. USAGE para todos os esquemas do banco de dados hr. SELECT para todas as tabelas do banco de dados hr.
db_fin_r	Função de acesso que permite acesso somente leitura às tabelas do banco de dados fin.	USAGE para o banco de dados fin. USAGE para todos os esquemas do banco de dados fin. SELECT para todas as tabelas do banco de dados fin.
db_fin_rw	Função de acesso que permite acesso de leitura-gravação às tabelas do banco de dados fin.	USAGE para o banco de dados fin. USAGE para todos os esquemas do banco de dados fin. SELECT INSERT, UPDATE, DELETE para todas as tabelas do banco de dados fin.
accountant	Função funcional para os contadores em sua organização.	N/A
analyst	Função funcional para os analistas em sua organização.	N/A

O diagrama a seguir mostra a hierarquia de funções para este exemplo:

Para configurar o controle de acesso para este exemplo:

1. Como administrador de usuários (usuário com a função USERADMIN) ou outra função com o privilégio CREATE ROLE para a conta, crie as funções de acesso e funções funcionais neste exemplo:

   CREATE ROLE db_hr_r;
   CREATE ROLE db_fin_r;
   CREATE ROLE db_fin_rw;
   CREATE ROLE accountant;
   CREATE ROLE analyst;
   

   Copy

2. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS para a conta, conceda as permissões mínimas exigidas para cada uma das funções de acesso:

   -- Grant read-only permissions on database HR to db_hr_r role.
   GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
   GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
   
   -- Grant read-only permissions on database FIN to db_fin_r role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
   GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
   
   -- Grant read-write permissions on database FIN to db_fin_rw role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
   GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
   

   Copy

3. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS na conta, conceda a função de acesso db_fin_rw à função funcional accountant, e conceda as funções de acesso db_hr_r db_fin_r à função funcional analyst:

   GRANT ROLE db_fin_rw TO ROLE accountant;
   GRANT ROLE db_hr_r TO ROLE analyst;
   GRANT ROLE db_fin_r TO ROLE analyst;
   

   Copy

4. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS para a conta, conceda as funções analyst e accountant ao administrador do sistema (SYSADMIN):

   GRANT ROLE accountant,analyst TO ROLE sysadmin;
   

   Copy

5. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS para a conta, conceda as funções funcionais empresariais aos usuários que desempenham essas funções empresariais em sua organização. Neste exemplo, a função funcional analyst é concedida ao usuário user1, e a função funcional accountant é concedida ao usuário user2.

   GRANT ROLE accountant TO USER user1;
   GRANT ROLE analyst TO USER user2;
   

   Copy

Gerenciamento de acesso ao objeto de banco de dados usando funções de bancos de dados¶

As funções de banco de dados são essencialmente as mesmas que as tradicionais funções criadas no nível da conta (ou seja, funções de conta personalizadas), exceto por seu escopo: Para permitir ações de SQL em objetos dentro de um banco de dados, podem ser concedidos privilégios a uma função de banco de dados no mesmo banco de dados.

As funções do banco de dados são destinadas a atender aos seguintes casos de uso:

Facilidade de gerenciamento:

Os proprietários de bancos de dados podem gerenciar independentemente o acesso a objetos protegíveis dentro de seus próprios bancos de dados. Os proprietários dos bancos de dados podem realizar as seguintes ações:

• Criar e gerenciar funções do banco de dados.

• Conceder privilégios a funções do banco de dados.

  Os privilégios em objetos concedidos às funções do banco de dados devem ter escopo com objetos contidos no banco de dados onde a função existe. Os privilégios em objetos em um banco de dados (por exemplo, tabelas ou exibições) não podem ser concedidos a funções do banco de dados em outro banco de dados.

  Qualquer privilégio, incluindo OWNERSHIP, pode ser concedido a funções de banco de dados nos objetos em um banco de dados. Observe que somente uma função da conta pode ter o privilégio OWNERSHIP no próprio banco de dados.

• Criar ou ampliar hierarquias de funções. Conceda funções do banco de dados a outras funções dentro do mesmo banco de dados, e então conceda as funções da banco de dados de mais alto nível em um banco de dados para funções de conta. Para obter mais informações, consulte Hierarquia de funções e herança de privilégios.

  Observe que a concessão de uma função de banco de dados a uma função de conta concede implicitamente o privilégio USAGE no banco de dados que contém a função de banco de dados a essa função de conta. A concessão do privilégio USAGE no banco de dados não é explicitamente exigida.

Compartilhamento de dados:

Os provedores de dados no Secure Data Sharing da Snowflake podem segmentar os objetos protegíveis em um compartilhamento, criando múltiplas funções do banco de dados em um banco de dados para compartilhar e conceder privilégios em um subconjunto dos objetos do banco de dados para cada função do banco de dados. Após criar um banco de dados a partir de um compartilhamento que inclui funções de banco de dados, os consumidores de dados concedem cada função de banco de dados compartilhado a uma ou mais funções de nível de conta em sua própria conta.

Sem funções de banco de dados, os administradores de contas em contas de consumidores de dados concedem um único privilégio, IMPORTED PRIVILEGES, para permitir que seus usuários acessem todos os bancos de dados e objetos de banco de dados (tabelas, exibições seguras etc.) em um compartilhamento. Não há opção para permitir que diferentes grupos de usuários em uma conta de consumidor de dados acessem um subconjunto dos objetos compartilhados. Esta abordagem de tudo ou nada exige que os provedores de dados criem várias ações para conceder acesso a diferentes objetos no mesmo banco de dados.

Note que as funções do banco de dados não podem ser ativadas diretamente em uma sessão. Conceda funções de banco de dados para funções de conta, que podem ser ativadas em uma sessão.

Centralização do gerenciamento de concessões usando esquemas de acesso gerenciado¶

Com esquemas regulares (ou seja, não gerenciados) em um banco de dados, os proprietários de objetos (ou seja, funções com o privilégio OWNERSHIP para um ou mais objetos) podem conceder acesso para esses objetos a outras funções, com a opção de conceder a essas funções a capacidade de gerenciar concessões de objetos.

Para maior segurança dos objetos, considere o uso de esquemas de acesso gerenciado. Em um esquema de acesso gerenciado, os proprietários de objetos perdem a capacidade de tomar decisões de concessão. Somente o proprietário do esquema (ou seja, a função com o privilégio OWNERSHIP para o esquema) ou uma função com o privilégio MANAGE GRANTS pode conceder privilégios para objetos no esquema, incluindo concessões futuras, centralizando o gerenciamento de privilégios.

Note que uma função que detém o privilégio global MANAGE GRANTS pode conceder privilégios adicionais à função atual (concessor).

Para obter mais informações sobre esquemas de acesso gerenciado, consulte Criação de esquemas de acesso gerenciado.

Simplificação do gerenciamento de concessões usando concessões futuras¶

As futuras concessões permitem definir um conjunto inicial de privilégios sobre objetos de um determinado tipo (por exemplo, tabelas ou exibições) em um esquema especificado. À medida que novos objetos são criados, os privilégios definidos são automaticamente concedidos a uma função, simplificando o gerenciamento das concessões.

Considere o seguinte cenário, no qual uma determinada função recebe o privilégio SELECT para todas as novas tabelas criadas em um esquema. Em uma data posterior, é tomada a decisão de revogar o privilégio desta função e, em vez disso, concedê-lo a uma função diferente. Usando as palavras-chave ON FUTURE para novas tabelas e a palavra-chave ALL para as tabelas existentes, poucas instruções SQL são necessárias para conceder e revogar privilégios para tabelas novas e existentes. Por exemplo:

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

Para obter mais informações sobre futuras concessões, consulte Atribuição de concessões futuras para objetos.

Visualização de resultados de consultas¶

Um usuário não pode visualizar o conjunto de resultados a partir de uma consulta que outro usuário executou. Este comportamento é intencional. Por razões de segurança, somente o usuário que executou uma consulta pode acessar os resultados da consulta.

Explicação de objetos clonados e privilégios concedidos¶

A clonagem de um banco de dados, esquema ou tabela cria uma cópia do objeto original. O objeto clonado inclui um instantâneo dos dados presentes no objeto original quando o clone foi criado.

Um objeto clonado é considerado um novo objeto no Snowflake. Quaisquer privilégios concedidos para o objeto original não são transferidos para o objeto clonado. Entretanto, um objeto de contêiner clonado (um banco de dados ou esquema) retém quaisquer privilégios concedidos para os objetos contidos no objeto original. Por exemplo, um esquema clonado retém quaisquer privilégios concedidos para as tabelas, exibições, UDFs e outros objetos no esquema original.

Para obter mais detalhes sobre clonagem, consulte Considerações sobre clonagem e CREATE <objeto> … CLONE.