Modelo de controle de acesso no Azure Data Lake Storage Gen2
O Data Lake Storage Gen2 suporta os seguintes mecanismos de autorização:
- Autorização de chave compartilhada
- Autorização de assinatura de acesso compartilhado (SAS)
- Controle de acesso baseado em função (Azure RBAC)
- Controle de acesso baseado em atributos (Azure ABAC)
- Listas de controlo de acesso (ACL)
A autorização de Chave Compartilhada e SAS concede acesso a um usuário (ou aplicativo) sem exigir que ele tenha uma identidade no Microsoft Entra ID. Com essas duas formas de autenticação, o Azure RBAC, o Azure ABAC e as ACLs não têm efeito.
O RBAC do Azure e a ACL exigem que o usuário (ou aplicativo) tenha uma identidade na ID do Microsoft Entra. O RBAC do Azure permite conceder acesso "grosseiro" aos dados da conta de armazenamento, como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento. O Azure ABAC permite refinar as atribuições de função RBAC adicionando condições. Por exemplo, você pode conceder acesso de leitura ou gravação a todos os objetos de dados em uma conta de armazenamento que tenham uma marca específica. As ACLs permitem conceder acesso "refinado", como acesso de gravação a um diretório ou arquivo específico.
Este artigo se concentra no RBAC, ABAC e ACLs do Azure e como o sistema os avalia juntos para tomar decisões de autorização para recursos de conta de armazenamento.
Controle de acesso baseado em função (Azure RBAC)
O RBAC do Azure usa atribuições de função para aplicar conjuntos de permissões a entidades de segurança. Uma entidade de segurança é um objeto que representa um usuário, grupo, entidade de serviço ou identidade gerenciada definida na ID do Microsoft Entra. Um conjunto de permissões pode dar a uma entidade de segurança um nível de acesso "grosseiro", como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento ou a todos os dados em um contêiner.
As funções a seguir permitem que uma entidade de segurança acesse dados em uma conta de armazenamento.
| Função | Descrição |
|---|---|
| Proprietário dos Dados do Armazenamento de Blobs | Acesso total a contêineres e dados de armazenamento de Blob. Esse acesso permite que a entidade de segurança defina um item para o proprietário e modifique as ACLs de todos os itens. |
| Contribuinte de Dados do Armazenamento de Blobs | Leia, escreva e elimine o acesso a contentores e blobs de armazenamento de Blobs. Esse acesso não permite que a entidade de segurança defina a propriedade de um item, mas pode modificar a ACL de itens que pertencem à entidade de segurança. |
| Leitor de Dados do Armazenamento de Blobs | Leia e liste contêineres e blobs de armazenamento de Blobs. |
Funções como Proprietário, Colaborador, Leitor e Colaborador da Conta de Armazenamento permitem que uma entidade de segurança gerencie uma conta de armazenamento, mas não fornecem acesso aos dados dessa conta. No entanto, essas funções (excluindo o Reader) podem obter acesso às chaves de armazenamento, que podem ser usadas em várias ferramentas de cliente para acessar os dados.
Controle de acesso baseado em atributos (Azure ABAC)
O Azure ABAC baseia-se no RBAC do Azure adicionando condições de atribuição de função com base em atributos no contexto de ações específicas. Uma condição de atribuição de função é uma verificação adicional que você pode, opcionalmente, adicionar à sua atribuição de função para fornecer um controle de acesso mais refinado. Não é possível negar explicitamente o acesso a recursos específicos usando condições.
Para obter mais informações sobre como usar o Azure ABAC para controlar o acesso ao Armazenamento do Azure, consulte Autorizar o acesso ao Armazenamento de Blobs do Azure usando as condições de atribuição de função do Azure.
Listas de controlo de acesso (ACL)
As ACLs oferecem a capacidade de aplicar um nível "mais refinado" de acesso a diretórios e arquivos. Uma ACL é uma construção de permissão que contém uma série de entradas de ACL. Cada entrada de ACL associa a entidade de segurança a um nível de acesso. Para saber mais, consulte Listas de controle de acesso (ACLs) no Azure Data Lake Storage Gen2.
Como são avaliadas as permissões
Durante a autorização baseada em entidade de segurança, as permissões são avaliadas conforme mostrado no diagrama a seguir.
- O Azure determina se existe uma atribuição de função para a entidade de segurança.
- Se existir uma atribuição de função, as condições de atribuição de função (2) serão avaliadas em seguida.
- Caso contrário, as LCA (4) são avaliadas em seguida.
- O Azure determina se existem condições de atribuição de função ABAC.
- Se não existirem condições, o acesso é concedido.
- Se existirem condições, são avaliadas para ver se correspondem ao pedido (3).
- O Azure determina se todas as condições de atribuição de função ABAC correspondem aos atributos da solicitação.
- Se todos corresponderem, o acesso é concedido.
- Se pelo menos um deles não corresponder, as LCA (4) são avaliadas em seguida.
- Se o acesso não tiver sido explicitamente concedido após a avaliação das atribuições e condições de função, as ACLs serão avaliadas.
- Se as ACLs permitirem o nível de acesso solicitado, o acesso será concedido.
- Caso contrário, o acesso é negado.
Importante
Devido à maneira como as permissões de acesso são avaliadas pelo sistema, não é possível usar uma ACL para restringir o acesso que já foi concedido por uma atribuição de função e suas condições. Isso ocorre porque o sistema avalia as atribuições e condições de função do Azure primeiro e, se a atribuição conceder permissão de acesso suficiente, as ACLs serão ignoradas.
O diagrama a seguir mostra o fluxo de permissão para três operações comuns: listar o conteúdo do diretório, ler um arquivo e gravar um arquivo.
Tabela de permissões: combinando RBAC, ABAC e ACLs do Azure
A tabela a seguir mostra como combinar funções, condições e entradas de ACL do Azure para que uma entidade de segurança possa executar as operações listadas na coluna Operação . Esta tabela mostra uma coluna que representa cada nível de uma hierarquia de diretórios fictícia. Há uma coluna para o diretório raiz do contêiner (/), um subdiretório chamado Oregon, um subdiretório do diretório Oregon chamado Portland e um arquivo de texto no diretório Portland chamado Data.txt. Aparecem nessas colunas representações de forma curta da entrada ACL necessária para conceder permissões. N/D (Não aplicável) aparece na coluna se uma entrada ACL não for necessária para executar a operação.
| Operação | Função do Azure atribuída (com ou sem condições) | / | Oregon/ | Portland/ | Dados.txt |
|---|---|---|---|---|---|
| Leia os dados.txt | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| None | --X |
--X |
--X |
R-- |
|
| Anexar aos dados.txt | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | --X |
--X |
--X |
-W- |
|
| None | --X |
--X |
--X |
RW- |
|
| Excluir dados.txt | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | --X |
--X |
-WX |
N/A | |
| None | --X |
--X |
-WX |
N/A | |
| Criar dados.txt | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | --X |
--X |
-WX |
N/A | |
| None | --X |
--X |
-WX |
N/A | |
| Lista / | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| None | R-X |
N/A | N/D | N/A | |
| Lista /Oregon/ | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| None | --X |
R-X |
N/A | N/A | |
| Lista /Oregon/Portland/ | Proprietário de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A |
| Contribuidor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| Leitor de Dados de Blobs de Armazenamento | N/A | N/D | N/D | N/A | |
| None | --X |
--X |
R-X |
N/A |
Nota
Para exibir o conteúdo de um contêiner no Gerenciador de Armazenamento do Azure, as entidades de segurança devem entrar no Gerenciador de Armazenamento usando a ID do Microsoft Entra e (no mínimo) ter acesso de leitura (R--) à pasta raiz (\) de um contêiner. Este nível de permissão dá-lhes a capacidade de listar o conteúdo da pasta raiz. Se não quiser que o conteúdo da pasta raiz fique visível, pode atribuir-lhes a função de Leitor . Com essa função, eles poderão listar os contêineres na conta, mas não o conteúdo do contêiner. Em seguida, você pode conceder acesso a diretórios e arquivos específicos usando ACLs.
Grupos de segurança
Sempre use grupos de segurança do Microsoft Entra como a entidade de segurança atribuída em uma entrada ACL. Resista à oportunidade de atribuir diretamente usuários individuais ou entidades de serviço. O uso dessa estrutura permitirá que você adicione e remova usuários ou entidades de serviço sem a necessidade de reaplicar ACLs a uma estrutura de diretórios inteira. 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.
Existem muitas maneiras diferentes de criar 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 e um LogsWriter LogsReader grupo. Em seguida, você pode atribuir permissões da seguinte maneira:
- Adicione o
LogsWritergrupo à ACL do diretório /LogData comrwxpermissões. - Adicione o
LogsReadergrupo à ACL do diretório /LogData comr-xpermissões. - Adicione o objeto principal de serviço ou a Identidade de Serviço Gerenciado (MSI) do ADF ao
LogsWritersgrupo. - Adicione usuários da equipe de engenharia de serviço ao
LogsWritergrupo. - Adicione o objeto principal de serviço ou MSI para Databricks ao
LogsReadergrupo.
Se um usuário da equipe de engenharia de serviço deixar a empresa, você pode simplesmente removê-lo do LogsWriter grupo. Se você não adicionou esse usuário a um grupo, mas em vez disso, adicionou uma entrada ACL dedicada para esse usuário, você teria que 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 .
Para criar um grupo e adicionar membros, consulte Criar um grupo básico e adicionar membros usando a ID do Microsoft Entra.
Importante
O Azure Data Lake Storage Gen2 depende da ID do Microsoft Entra para gerenciar grupos de segurança. O Microsoft Entra ID recomenda que você limite a associação de grupo para uma determinada entidade de segurança a menos de 200. Esta recomendação deve-se a uma limitação de JSON Web Tokens (JWT) que fornecem informações de associação de grupo de uma entidade de segurança em aplicativos Microsoft Entra. Exceder esse limite pode levar a problemas de desempenho inesperados com o Data Lake Storage Gen2. Para saber mais, consulte Configurar declarações de grupo para aplicativos usando a ID do Microsoft Entra.
Limites nas atribuições de função do Azure e entradas de ACL
Ao usar grupos, é menos provável que você exceda o número máximo de atribuições de função por assinatura e o número máximo de entradas de ACL por arquivo ou diretório. A tabela a seguir descreve esses limites.
| Mecanismo | Âmbito | Limites | Nível de permissão suportado |
|---|---|---|---|
| RBAC do Azure | Contas de armazenamento, contêineres. Atribuições de função do Azure entre recursos no nível de assinatura ou grupo de recursos. |
4000 atribuições de função do Azure em uma assinatura | Funções do Azure (internas ou personalizadas) |
| ACL | Diretório, arquivo | 32 entradas ACL (efetivamente 28 entradas ACL) por arquivo e por diretório. Cada uma das ACLs de acesso e de predefinição tem o seu próprio limite de 32 entradas ACL. | Permissão de ACL |
Autorização de Chave Partilhada e Assinatura de Acesso Partilhado (SAS)
O Azure Data Lake Storage Gen2 também suporta métodos de Chave Partilhada e SAS para autenticação. Uma característica desses métodos de autenticação é que nenhuma identidade está associada ao chamador e, portanto, a autorização baseada em permissão da entidade de segurança não pode ser executada.
No caso da Chave Compartilhada, o chamador efetivamente ganha acesso de "superusuário", o que significa acesso total a todas as operações em todos os recursos, incluindo dados, proprietário da configuração e alteração de ACLs.
Os tokens SAS incluem permissões permitidas como parte do token. As permissões incluídas no token SAS são efetivamente aplicadas a todas as decisões de autorização, mas nenhuma verificação adicional de ACL é executada.
Próximos passos
Para saber mais sobre listas de controle de acesso, consulte Listas de controle de acesso (ACLs) no Azure Data Lake Storage Gen2.