Considerações sobre o controle de acesso

Este tópico fornece as práticas recomendadas e considerações importantes para gerenciar o acesso seguro à sua conta Snowflake e aos dados armazenados dentro da conta. Em particular, fornece orientação geral para configurar o controle de acesso baseado em funções, o que limita o acesso a objetos com base na função de um usuário.

Neste tópico:

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

Atenção

Por padrão, quando sua conta é provisionada, ao primeiro usuário é atribuída a função ACCOUNTADMIN. Este usuário deve então criar um ou mais usuários adicionais aos quais é atribuída a função USERADMIN. Todos os usuários restantes devem ser criados pelo(s) usuário(s) com a função USERADMIN ou outra função à qual é concedido o privilégio global CREATE USER.

Controle da atribuição da função ACCOUNTADMIN a usuários

Recomendamos fortemente as seguintes precauções ao atribuir a função ACCOUNTADMIN a usuários:

  • Atribua esta função somente a um número seleto/limitado de pessoas em sua organização.

  • Todos os usuários atribuídos à função ACCOUNTADMIN também devem ser obrigados a usar autenticação multifator (MFA) para login (para detalhes, consulte Configuração do controle de acesso).

  • Atribua esta função a pelo menos dois usuários. Seguimos rigorosos procedimentos de segurança para redefinir uma senha esquecida ou perdida para os usuários com a função ACCOUNTADMIN. Estes procedimentos podem levar até dois dias úteis. Atribuir a função ACCOUNTADMIN a mais de um usuário evita ter que passar por esses procedimentos porque os usuários podem redefinir as senhas uns dos outros.

Dica

Também ajuda se você associar o endereço de e-mail de uma pessoa real aos usuários ACCOUNTADMIN, para que o suporte Snowflake saiba quem contatar em uma situação urgente.

Evite usar a função ACCOUNTADMIN para criar objetos

A função ACCOUNTADMIN é destinada a executar tarefas de configuração inicial no sistema e gerenciar objetos e tarefas em nível de conta no dia a dia. Como tal, não deve ser usada para criar objetos em sua conta, a menos que você absolutamente precise que esses objetos tenham o mais alto nível de acesso seguro. Se você criar objetos com a função ACCOUNTADMIN e quiser que os usuários tenham acesso a esses objetos, deve conceder explicitamente privilégios sobre os objetos para as funções desses usuários.

Em vez disso, recomendamos criar uma hierarquia de funções alinhada com as funções empresariais em sua organização e, em última instância, atribuir essas funções à função SYSADMIN. Para obter mais informações, consulte Alinhamento do acesso a objetos com funções empresariais neste tópico.

Dica

Para ajudar a evitar que os administradores de conta utilizem inadvertidamente a função ACCOUNTADMIN para criar objetos, atribua a esses usuários funções adicionais e designe uma dessas funções como padrão (ou seja, não torne ACCOUNTADMIN a função padrão para qualquer usuário no sistema).

Isto não os impede de usar a função ACCOUNTADMIN para criar objetos, mas os força a mudar explicitamente sua função para ACCOUNTADMIN cada vez que fazem login no sistema. Isto pode ajudá-los a tomar consciência do propósito/função das funções no sistema e encorajá-los a mudar para a função apropriada para executar uma determinada tarefa, particularmente quando precisam executar tarefas de administrador de conta.

Evite usar a função ACCOUNTADMIN para scripts automatizados

Recomendamos o uso de um função diferente de ACCOUNTADMIN para scripts automatizados. Se, como recomendado, você criar uma hierarquia de funções sob a função SYSADMIN, todas as operações de objetos de warehouse e banco de dados podem ser executadas usando a função SYSADMIN ou funções inferiores na hierarquia. As únicas limitações que você encontrará são criar ou modificar usuários ou funções. Estas operações devem ser realizadas por um usuário com a função SECURITYADMIN ou outra função com privilégios de objeto suficientes.

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.

Importante

Por padrão, nem mesmo a função ACCOUNTADMIN pode modificar ou descartar objetos criados por uma função personalizada. A função personalizada deve ser concedida à função ACCOUNTADMIN diretamente ou, de preferência, a outra função em uma hierarquia com a função SYSADMIN como pai. A função SYSADMIN é gerenciada pela função ACCOUNTADMIN.

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:

Nota

Não há diferença técnica entre uma função de acesso a objetos e uma função funcional no Snowflake. A diferença está em como são usadas logicamente para montar e atribuir conjuntos de permissões a grupos de usuários.

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:

Example: Hierarchy of access and functional roles

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 Hierarquia de funções e herança de privilégios. 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;
Copy

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.

Nota

Este comportamento não é conectado ao modelo de controle de acesso do Snowflake para objetos. Mesmo um usuário com a função ACCOUNTADMIN não pode visualizar os resultados de uma consulta executada por outro usuário.

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.