Gerenciar permissões de usuários em pools de SQL sem servidor do Azure Synapse
Para proteger os dados, o Armazenamento do Azure implementa um modelo de controle de acesso que dá suporte ao RBAC (controle de acesso baseado em função) do Azure e às ACLs (listas de controle de acesso) semelhantes a POSIX (Portable Operating System Interface for Unix)
Você pode associar uma entidade de segurança a um nível de acesso para arquivos e diretórios. Essas associações são capturadas em uma ACL (lista de controle de acesso). Cada arquivo e diretório na sua conta de armazenamento tem uma lista de controle de acesso. Quando uma entidade de segurança tenta executar uma operação em um arquivo ou diretório, uma verificação ACL determina se a entidade de segurança (usuário, grupo, entidade de serviço ou identidade gerenciada) tem o nível de permissão correto para executar a operação.
Estes são dois tipos de listas de controle de acesso:
ACLs de Acesso
Controla o acesso a um objeto. Arquivos e diretórios têm ambos ACLs de acesso.
ACLs Padrão
São modelo de ACLs associados a um diretório que determina as ACLs de acesso para todos os itens filho criados nesse diretório. Arquivos não têm ACLs padrão.
As ACLs de Acesso e as ACLs Padrão têm a mesma estrutura.
As permissões em um objeto de contêiner são de leitura, gravação e execução e podem ser usadas em arquivos e diretórios, conforme mostrado na seguinte tabela:
Níveis de permissões
| Permissão | Arquivo | Diretório |
|---|---|---|
| Ler (R) | Pode ler o conteúdo de um arquivo | Requer Ler e Executar para listar o conteúdo do diretório |
| Gravar (W) | Pode gravar ou anexar a um arquivo | Requer Gravar e Executar para criar itens filhos em um diretório |
| Executar (X) | Não significa nada no contexto do Azure Data Lake Storage Gen2 | Necessário para percorrer os itens filhos de um diretório |
Diretrizes na configuração de ACLs
Sempre use os grupos de segurança do Microsoft Entra como a entidade de segurança atribuída em uma entrada de ACL. Resista a oportunidade de atribuir diretamente a usuários individuais ou entidades de serviço. Usar essa estrutura permitirá que você adicione e remova usuários ou entidades de serviço sem a necessidade de reaplicar as ACLs para uma estrutura de diretório inteiro. Em vez disso, você pode apenas adicionar ou remover usuários e entidades de serviço do grupo de segurança apropriado do Microsoft Entra.
Há muitas maneiras de configurar grupos. Por exemplo, imagine que você tenha um diretório chamado /LogData que contém dados de log gerados pelo servidor. O ADF (Azure Data Factory) ingere dados para essa pasta. Usuários específicos da equipe de engenharia de serviço carregarão logs e gerenciarão outros usuários dessa pasta e vários clusters do Databricks analisarão os logs dessa pasta.
Para habilitar essas atividades, você pode criar um grupo LogsWriter e um grupo LogsReader. Em seguida, você pode atribuir permissões da seguinte maneira:
- Adicione o grupo LogsWriter à ACL do diretório /LogData com permissões de rwx.
- Adicione o grupo LogsReader à ACL do diretório /LogData com permissões de r-x.
- Adicione o objeto de entidade de serviço ou MSI (Identidade de Serviço Gerenciado) do ADF ao grupo LogsWriters.
- Adicione usuários na equipe de engenharia de serviço ao grupo LogsWriter.
- Adicione o objeto de entidade de serviço ou MSI para Databricks ao grupo LogsReader.
Se um usuário na equipe de engenharia de serviço sair da empresa, você poderá removê-lo do grupo LogsWriter. Se você não adicionasse esse usuário a um grupo, mas, em vez disso, adicionasse uma entrada ACL dedicada para esse usuário, você precisaria remover essa entrada ACL do diretório /LogData. Você também precisaria remover a entrada de todos os subdiretórios e arquivos na hierarquia de diretório inteira do diretório /LogData.
Funções necessárias para usuários do pool de SQL sem servidor
Para usuários que precisam de acesso somente leitura, você deve atribuir a função chamada Leitor de Dados de Blob de Armazenamento.
Para usuários que precisam de acesso de leitura/gravação, você deve atribuir a função chamada Colaborador de Dados de Blob de Armazenamento. O acesso de leitura/gravação será necessário se o usuário tiver acesso para CETAS (criar tabela externa como seleção).
Observação
Se o usuário tiver um Proprietário ou Colaborador de função, essa função não será suficiente. O Azure Data Lake Storage Gen 2 tem superfunções que devem ser atribuídas.
Permissão no nível do banco de dados
Para fornecer acesso mais granular ao usuário, você deve usar a sintaxe Transact-SQL para criar logons e usuários.
Para permitir acesso a um usuário a um banco de dados do pool de SQL sem servidor individual do SQL sob demanda, siga as etapas deste exemplo:
Criar um LOGON
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;Criar um USUÁRIO
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];Adicionar o USUÁRIO aos membros da função especificada
use yourdb -- Use your DB name alter role db_datareader Add member alias -- Type USER name from step 2 -- You can use any Database Role which exists -- (examples: db_owner, db_datareader, db_datawriter) -- Replace alias with alias of the user you would like to give access and domain with the company domain you are using.
Permissões no nível do servidor
Para permitir acesso completo a um usuário a todos os banco de dados do pool de SQL sem servidor, execute a etapa deste exemplo:
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];