Gerenciar permissões de usuário em pools 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 controle de acesso baseado em função do Azure (Azure RBAC) e às listas de controle de acesso (ACLs), como a Interface do Sistema Operacional Portátil para Unix (POSIX)
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 lista de controle de acesso (ACL). Cada arquivo e diretório em sua conta de armazenamento tem uma lista de controle de acesso. Quando uma entidade de segurança tenta uma operação em um arquivo ou diretório, uma verificação de ACL determina se essa 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.
Existem dois tipos de listas de controlo de acesso:
ACLs de acesso
Controla o acesso a um objeto. Arquivos e diretórios têm ACLs de acesso.
ACLs padrão
São modelos de ACLs associados a um diretório que determinam as ACLs de acesso para quaisquer itens filho criados nesse diretório. Os arquivos não têm ACLs padrão.
Tanto as ACLs de acesso quanto as ACLs padrão têm a mesma estrutura.
As permissões em um objeto de contêiner são Ler, Gravar e Executar, e podem ser usadas em arquivos e diretórios, conforme mostrado na tabela a seguir:
Níveis de permissões
| Permissão | Ficheiro | Diretório |
|---|---|---|
| Leitura (R) | Pode editar o conteúdo de um ficheiro | Requer Ler e Executar para listar o conteúdo do diretório |
| Escrita (W) | Pode escrever ou acrescentar a um ficheiro | Requer Write and Execute para criar itens filho em um diretório |
| Execução (X) | Não significa nada no contexto do Data Lake Storage Gen2 | Necessário para percorrer os itens filho de um diretório |
Diretrizes na configuração de ACLs
Use sempre os grupos de segurança do Microsoft Entra como a entidade de segurança atribuída em uma entrada ACL. Resista à oportunidade de atribuir diretamente utilizadores individuais ou principais de serviço. A utilização desta estrutura irá permitir-lhe adicionar e remover utilizadores ou principais de serviço sem a necessidade de aplicar novamente ACLs a uma estrutura completa do diretório. Em vez disso, você pode simplesmente 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 Azure Data Factory (ADF) ingere dados nessa 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 Databricks analisarão 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 rwx.
- Adicione o grupo LogsReader à ACL do diretório /LogData com permissões r-x.
- Adicione o objeto principal de serviço ou a Identidade de Serviço Gerenciado (MSI) do ADF ao grupo LogsWriters.
- Adicione usuários da equipe de engenharia de serviço ao grupo LogsWriter.
- Adicione o objeto principal de serviço ou MSI para Databricks ao grupo LogsReader.
Se um usuário da equipe de engenharia de serviço deixar a empresa, basta removê-lo do grupo LogsWriter. Se você não adicionou esse usuário a um grupo, mas em vez disso, adicionou uma entrada ACL dedicada para esse usuário, será necessário remover essa entrada ACL do diretório /LogData . Você também teria que remover a entrada de todos os subdiretórios e arquivos em toda a hierarquia de diretórios do diretório /LogData .
Funções necessárias para usuários do pool SQL sem servidor
Para usuários que precisam de acesso somente leitura, você deve atribuir a função chamada Storage Blob Data Reader.
Para usuários que precisam de acesso de leitura/gravação , você deve atribuir a função chamada Storage Blob Data Contributor. O acesso de leitura/gravação é necessário se o usuário tiver acesso para criar uma tabela externa como selecionar (CETAS).
Nota
Se o usuário tiver uma função de Proprietário ou Colaborador, 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 conceder acesso a um usuário a um único banco de dados de pool SQL sem servidor, siga as etapas neste exemplo:
Criar LOGIN
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;Criar UTILIZADOR
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];Adicionar USER 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ão no nível do servidor
Para conceder acesso total a um usuário a todos os bancos de dados do pool SQL sem servidor, siga a etapa neste exemplo:
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];