Dimensionar o gerenciamento de atribuições de função do Azure usando condições e atributos de segurança personalizados

O RBAC do Azure (controle de acesso baseado em função do Azure) tem um limite de atribuições de função por assinatura. Se você precisar criar centenas ou até milhares de atribuições de função do Azure, poderá encontrar esse limite. Gerenciar centenas ou milhares de atribuições de função pode ser difícil. Dependendo do cenário, você poderá reduzir o número de atribuições de função e facilitar o gerenciamento do acesso.

Este artigo descreve uma solução para dimensionar o gerenciamento de atribuições de função usando as condições do Azure ABAC (controle de acesso baseado em atributos) do Azure e os atributos de segurança personalizados do Microsoft Entra para entidades.

Cenário de exemplo

Considere uma empresa chamada Contoso com milhares de clientes que querem definir a seguinte configuração:

  • Distribua dados do cliente entre 128 contas de armazenamento por motivos de segurança e desempenho.
  • Adicione 2.000 contêineres a cada conta de armazenamento em que há um contêiner para cada cliente.
  • Represente cada cliente por uma entidade de serviço exclusiva do Microsoft Entra.
  • Permita que cada cliente acesse objetos no respectivo contêiner, mas não em outros contêineres.

Essa configuração pode exigir 256 mil atribuições de função de Proprietário de Dados de Blob de Armazenamento em uma assinatura, um número bem superior ao limite de atribuições de função. Ter tantas atribuições de função seria difícil, se não impossível, de manter.

Diagram showing thousands for role assignments.

Exemplo de solução

Uma maneira de lidar com esse cenário de maneira sustentável é usar condições de atribuição de função. O diagrama a seguir mostra uma solução para reduzir as 256 mil atribuições de função para apenas uma atribuição de função usando uma condição. A atribuição de função está em um escopo de grupo de recursos mais alto e uma condição ajuda a controlar o acesso aos contêineres. A condição verifica se o nome do contêiner corresponde ao atributo de segurança personalizado na entidade de serviço do cliente.

Diagram showing one role assignment and a condition.

Esta é a expressão na condição que faz essa solução funcionar:

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

A condição completa seria semelhante à seguinte. A lista de ações pode ser ajustada apenas para as ações necessárias.

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

Por que usar essa solução?

Há vários mecanismos de controle de acesso que você pode usar para fornecer acesso aos recursos do plano de dados.

As chaves de acesso são uma maneira comum de fornecer acesso aos recursos do plano de dados. As chaves de acesso fornecem permissões de leitura, gravação e exclusão para quem possui a chave de acesso. Isso significa que os invasores poderão obter acesso aos seus dados confidenciais se puderem obter suas chaves de acesso. As chaves de acesso não têm associação de identidade, não têm uma expiração e representam um risco de segurança se armazenadas.

Assim como as chaves de acesso, os tokens SAS (assinatura de acesso compartilhado) não têm associação de identidade, mas expiram regularmente. A falta de associação de identidade representa os mesmos riscos de segurança que as chaves de acesso. Você deve gerenciar a expiração para garantir que os clientes não recebam erros. Os tokens SAS exigem mais código para gerenciar e operar diariamente e podem ser uma sobrecarga significativa para uma equipe de DevOps.

O RBAC do Azure fornece controle de acesso refinado centralizado. O RBAC do Azure tem associação de identidade que reduz o risco de segurança. Usando condições, você pode potencialmente dimensionar o gerenciamento de atribuições de função e facilitar a manutenção do controle de acesso, porque o acesso é baseado em atributos flexíveis e dinâmicos.

Aqui estão alguns dos benefícios dessa solução:

  • Controle de acesso centralizado
  • Mais fácil de manter
  • Não depende de chaves de acesso ou tokens SAS
  • Não exige que você gerencie o acesso em cada objeto
  • Pode potencialmente melhorar sua postura de segurança

Você pode usar essa solução?

Se você tiver um cenário semelhante, execute estas etapas para ver se você poderia usar essa solução.

Etapa 1: Determinar se você atende aos pré-requisitos

Para usar essa solução, você deve ter:

Etapa 2: Identificar os atributos que você pode usar em sua condição

Há vários atributos que você pode usar em sua condição, como os seguintes:

  • Nome do contêiner
  • Caminho do Blob
  • Marcas de índice de blob [Chaves]
  • Marcas de índice de blob [Valores na chave]

Você também pode definir seus próprios atributos de segurança personalizados para usuários, aplicativos empresariais e identidades gerenciadas.

Para obter mais informações, consulte Formato e sintaxe da condição de atribuição de função do Azure e O que são atributos de segurança personalizados na ID do Microsoft Entra?.

Etapa 3: Criar uma condição em um escopo mais alto

Crie uma ou mais atribuições de função que usam uma condição em um escopo mais alto para gerenciar o acesso. Para saber mais, confira Adicionar ou editar condições de atribuição de função do Azure usando o portal do Azure.

Próximas etapas