Modelo de controle de acesso no Azure Data Lake Storage
O Data Lake Storage dá suporte aos seguintes mecanismos de autorização:
- Autorização de chave compartilhada
- Autorização de SAS (Assinatura de Acesso Compartilhado)
- RBAC (controle de acesso baseado em função) do Azure
- Azure ABAC (controle de acesso baseado em atributo)
- ACL (listas de controle de acesso)
A autorização de chave compartilhada, conta SAS e serviço SAS concede acesso a um usuário (ou aplicativo) sem exigir que ele tenha uma identidade no Microsoft Entra ID. Com essas formas de autenticação, o RBAC, o ABAC e as ACLs do Azure não têm efeito. As ACLs podem ser aplicadas a tokens SAS delegados pelo usuário porque esses tokens são protegidos com credenciais do Microsoft Entra. Veja Chave compartilhada e autorização SAS.
O RBAC do Azure e a ACL exigem que o usuário (ou aplicativo) tenha uma identidade no Microsoft Entra ID. O Azure RBAC permite o acesso "alta granularidade" aos dados da conta de armazenamento, como acesso de leitura ou gravação a todos os dados na conta de armazenamento. O Azure ABAC permite refinar atribuições de função RBAC adicionando condições. Por exemplo, você pode permitir 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 que você dê acesso "refinado", como acesso de gravação a um diretório ou arquivo específico.
Este artigo se concentra no Azure RBAC, no ABAC e nas ACLs e em como o sistema os avalia em conjunto para tomar decisões de autorização para recursos de conta de armazenamento.
RBAC (controle de acesso baseado em função) do Azure
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, um grupo, uma entidade de serviço ou uma identidade gerenciada que é definida no Microsoft Entra ID. Um conjunto de permissões pode dar a uma entidade de segurança um nível de acesso de "alta granularidade", como acesso de leitura ou gravação a todos os dados em uma conta de armazenamento ou 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 de Dados do Blob de Armazenamento | Acesso completo aos contêineres e dados do Armazenamento de Blobs. Esse acesso permite que a entidade de segurança defina um item do proprietário e modifique as ACLs de todos os itens. |
| Colaborador de dados de blob de armazenamento | Acesso de leitura, gravação e exclusão aos contêineres e blobs do 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 Blob de Armazenamento | Ler e listar contêineres de blobs do 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 dentro dessa conta. No entanto, essas funções (excluindo Leitor) podem obter acesso às chaves de armazenamento, que podem ser usadas em várias ferramentas de cliente para acessar os dados.
Azure ABAC (controle de acesso baseado em atributo)
O ABAC do Azure baseia-se no RBAC do Azure pela adição de 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 adicionar à atribuição de função para obter 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 de como usar o Azure ABAC para controlar o acesso ao Armazenamento do Azure, confira Autorizar o acesso ao Armazenamento de Blobs do Azure usando condições de atribuição de função do Azure.
ACLs (listas de controle de acesso)
As ACLs oferecem a capacidade de aplicar o nível de acesso de "maior granularidade" 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 ACLs (listas de controle de acesso) no Azure Data Lake Storage.
Como as permissões são avaliadas
Durante a autorização baseada em entidade de segurança, as permissões são avaliadas como mostra o diagrama a seguir.
- O Azure determina se existe uma atribuição de função para a entidade de segurança.
- Se houver uma atribuição de função, as condições de atribuição de função (2) serão avaliadas em seguida.
- Se não existir, as ACLs (4) serão avaliadas a seguir.
- O Azure determina se existe alguma condição de atribuição de função do ABAC.
- Se não existir nenhuma condição, o acesso será permitido.
- Se existir, a condição será avaliada para ver se corresponde à solicitação (3).
- O Azure determina se todas as condições de atribuição de função do ABAC correspondem aos atributos da solicitação.
- Se todas corresponderem, o acesso será concedido.
- Se pelo menos uma delas não corresponder, as ACLs (4) serão avaliadas a seguir.
- Se o acesso não tiver sido permitido explicitamente após a avaliação das atribuições de função e das condições, as ACLs serão avaliadas.
- Se as ACLs permitirem o nível de acesso solicitado, o acesso será permitido.
- Caso contrário, o acesso será negado.
Importante
Devido à maneira como as permissões de acesso são avaliadas pelo sistema, você não pode usar uma ACL para restringir um acesso que já foi permitido por uma atribuição de função e suas condições. Isso ocorre porque o sistema avalia primeiro as atribuições de função e as condições do Azure e, se a atribuição conceder permissão de acesso suficiente, as ACLs serão ignoradas.
O seguinte diagrama 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 o RBAC, o ABAC e a ACL do Azure
A tabela a seguir mostra como combinar funções do Azure, condições e entradas de ACL 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ório 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 Portlande um arquivo de texto no diretório Portland chamado Data.txt. A exibição dessas colunas é uma pequena representação abreviada da entrada de ACL necessária para conceder permissões. N/A (não aplicável) aparece na coluna se uma entrada de ACL não for necessária para executar a operação.
| Operação | Função atribuída do Azure (com ou sem condições) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Read Data.txt | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D | |
| Não | --X |
--X |
--X |
R-- |
|
| Append to Data.txt | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | --X |
--X |
--X |
-W- |
|
| Não | --X |
--X |
--X |
RW- |
|
| Delete Data.txt | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | --X |
--X |
-WX |
N/D | |
| Nenhum | --X |
--X |
-WX |
N/A | |
| Criar / Atualizar Data.txt | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | --X |
--X |
-WX |
N/D | |
| Nenhum | --X |
--X |
-WX |
N/D | |
| List / | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D | |
| Nenhum | R-X |
N/D | N/D | N/D | |
| Lista /Oregon/ | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D | |
| Nenhum | --X |
R-X |
N/D | N/D | |
| Lista /Oregon/Portland/ | Proprietário de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D |
| Colaborador de dados de blob de armazenamento | N/D | N/D | N/D | N/D | |
| Leitor de Dados do Blob de Armazenamento | N/D | N/D | N/D | N/D | |
| Nenhum | --X |
--X |
R-X |
N/D |
Observação
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 o Microsoft Entra ID e (no mínimo) ter acesso de leitura (R--) à pasta raiz (\) de um contêiner. Esse nível de permissão dá a eles a capacidade de listar o conteúdo da pasta raiz. Se você não quiser que o conteúdo da pasta raiz fique visível, poderá atribuir a eles a função 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 permitir 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 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.
Existem muitas maneiras diferentes 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
LogsWritergrupo à ACL do diretório /LogData comrwxpermissões. - Adicione o
LogsReadergrupo à ACL do diretório /LogData comr-xpermissões. - 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.
Para criar um grupo e adicionar membros, confira Criar um grupo básico e adicionar membros usando o Microsoft Entra ID.
Importante
O Azure Data Lake Storage Gen2 depende do Microsoft Entra ID 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 para menos de 200. Essa recomendação ocorre devido a uma limitação de JWT (Tokens Web JSON) que fornecem informações de associação de grupo de uma entidade de segurança em aplicativos do Microsoft Entra. Exceder esse limite poderá resultar em problemas de desempenho inesperado com o Data Lake Storage Gen2. Para saber mais, confira Configurar declarações de grupo para aplicativos usando o Microsoft Entra ID.
Limites em atribuições de função do Azure e entradas de ACL
Usando grupos, você tem menor probabilidade de exceder 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 | Escopo | Limites | Nível de permissão com suporte |
|---|---|---|---|
| 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. |
4.000 atribuições de função do Azure em uma assinatura | Funções do Azure (internas ou personalizadas) |
| ACL | Diretório, arquivo | 32 entradas de ACL (efetivamente 28 entradas de ACL) por arquivo e por diretório. As ACLs de acesso e padrão têm seu próprio limite de entrada de ACL 32. | Permissão de ACL |
A autorização de Chave Compartilhada e SAS (Assinatura de Acesso Compartilhado)
O Azure Data Lake Storage também dá suporte a métodos de Chave Compartilhada e SAS para autenticação.
No caso de Chave Compartilhada, o chamador obtém efetivamente acesso de “superusuário”, o que significa acesso completo a todas as operações em todos os recursos, incluindo a definição de proprietário e alteração de ACLs. As ACLs não se aplicam a usuários que usam a autorização de Chave Compartilhada porque 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. O mesmo vale para tokens SAS (assinatura de acesso compartilhado), exceto quando um token SAS delegado pelo usuário é usado. Nesse caso, o Armazenamento do Microsoft Azure executa uma verificação de ACL POSIX na ID do objeto antes de autorizar a operação, desde que o parâmetro opcional suoid seja usado. Para saber mais, confira Construir uma SAS de delegação de usuário.
Próximas etapas
Para saber mais sobre listas de controle de acesso, consulte ACLs (listas de controle de acesso) no Azure Data Lake Storage.