Partilhar via

Considerações de segurança para as condições de atribuição de funções Azure no Azure Blob Storage

Para proteger totalmente os recursos usando o controle de acesso baseado em atributos do Azure (Azure ABAC), você também deve proteger os atributos usados nas condições de atribuição de função do Azure. Por exemplo, se sua condição for baseada em um caminho de arquivo, você deve ter cuidado para que o acesso possa ser comprometido se a entidade de segurança tiver uma permissão irrestrita para renomear um caminho de arquivo.

Este artigo descreve considerações de segurança que você deve levar em conta em suas condições de atribuição de função.

Importante

O controlo de acesso baseado em atributos do Azure (Azure ABAC) está geralmente disponível (GA) para controlar o acesso ao Azure Blob Storage, ao Azure Data Lake Storage Gen2 e às Filas do Azure, usando os atributos request, resource, environment e principal nas camadas de desempenho da conta de armazenamento padrão e premium. Atualmente, o blob de lista inclui o atributo request e o atributo snapshot request para namespace hierárquico estão em PREVIEW. Para obter informações completas sobre o status do recurso ABAC para Armazenamento Azure, consulte Status das funcionalidades condicionais no Armazenamento Azure.

Consulte os Termos de Utilização Complementares das Visualizações Prévias do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão em beta, em pré-visualização ou que ainda não foram lançadas para disponibilidade geral.

Utilização de outros mecanismos de autorização

As condições de atribuição de função só são avaliadas ao usar o RBAC do Azure para autorização. Estas condições podem ser ignoradas se você permitir o acesso usando métodos de autorização alternativos:

Da mesma forma, as condições não são avaliadas quando o acesso é concedido usando listas de controle de acesso (ACLs) em contas de armazenamento com um namespace hierárquico (HNS).

Você pode impedir a autorização de chave compartilhada, SAS no nível da conta e SAS de nível de serviço desativando a autorização de chave compartilhada para a sua conta de armazenamento. Como a SAS de delegação de usuário depende do RBAC do Azure, as condições de atribuição de função são avaliadas ao usar esse método de autorização.

Protegendo atributos de armazenamento usados em condições específicas

Caminho do blob

Ao usar o caminho de blob como um atributo @Resource para uma condição, você também deve impedir que os usuários renomeiem um blob para obter acesso a um arquivo ao usar contas que tenham um namespace hierárquico. Por exemplo, se desejares definir uma condição com base no caminho do blob, também deves restringir o acesso do utilizador às seguintes ações:

Ação Descrição
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action Essa ação permite que os clientes renomeiem um arquivo usando a API de criação de caminho.
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Esta ação permite o acesso a várias operações de sistema de arquivos e caminho.

Tags de índice de Blob

As tags de índice de Blob são usadas como atributos de forma livre para condições no armazenamento. Se você criar quaisquer condições de acesso usando essas tags, você também deve proteger as próprias tags. Especificamente, o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction permite que os usuários modifiquem as tags em um objeto de armazenamento. Você pode restringir essa ação para impedir que os usuários manipulem uma chave ou valor de tag para obter acesso a objetos não autorizados.

Além disso, se as etiquetas de índice de blobs forem utilizadas em condições, os dados poderão tornar-se vulneráveis se os dados e as etiquetas de índice associadas forem atualizados em operações separadas. Você pode usar @Request condições em operações de gravação de blob para exigir que as tags de índice sejam definidas na mesma operação de atualização. Essa abordagem pode ajudar a proteger os dados desde o instante em que são gravados no armazenamento.

Tags em blobs copiados

Por padrão, as tags de índice de blob não são copiadas de um blob de origem para o destino quando se utiliza a API Copiar Blob ou qualquer uma de suas variantes. Para preservar o escopo de acesso para blob após cópia, você deve copiar as tags também.

Tags em instantâneos

As tags em instantâneos de blob não podem ser modificadas. Portanto, você deve atualizar as tags em um blob antes de tirar o instantâneo. Se você modificar as tags em um blob base, as tags em seu snapshot continuarão a ter seu valor anterior.

Se uma tag em um blob base for modificada depois que um snapshot for tirado, o escopo de acesso poderá ser diferente para o blob base e o snapshot.

Marcadores em versões de blob

As tags de índice de Blob não são copiadas quando uma versão de blob é criada por meio das APIs Put Blob, Put Block List ou Copy Blob . Você pode especificar tags através do cabeçalho para essas APIs.

As tags podem ser definidas individualmente em um blob base atual e em cada versão do blob. Quando você modifica tags em um blob base, as tags em versões anteriores não são atualizadas. Se você quiser alterar o escopo de acesso para um blob e todas as suas versões usando tags, você deve atualizar as tags em cada versão.

Limitações de consulta e filtragem para versões e instantâneos

Quando você usa tags para consultar e filtrar blobs em um contêiner, somente os blobs de base são incluídos na resposta. As versões de blob ou instantâneos com as chaves e valores solicitados não estão incluídos.

Funções e permissões

Se estiver a utilizar condições de atribuição de função para funções incorporadas do Azure, deve rever cuidadosamente todas as permissões que a função concede a um principal.

Atribuições de função herdadas

As atribuições de função podem ser configuradas para um grupo de gerenciamento, assinatura, grupo de recursos, conta de armazenamento ou contêiner e são herdadas em cada nível na ordem indicada. O RBAC do Azure tem um modelo aditivo, portanto, as permissões efetivas são a soma das atribuições de função em cada nível. Se um utilizador tiver a mesma permissão atribuída a ele através de múltiplas atribuições de função, o acesso para uma operação usando essa permissão será avaliado separadamente para cada atribuição em cada nível.

Como as condições são implementadas como condições em atribuições de função, qualquer atribuição de função incondicional pode permitir que os usuários ignorem a condição. Digamos que atribua a função Colaborador de Dados de Blob de Armazenamento a um utilizador para uma conta de armazenamento e numa assinatura, mas adicione uma condição apenas à atribuição para a conta de armazenamento. O resultado é que o usuário tem acesso irrestrito à conta de armazenamento por meio da atribuição de função no nível da assinatura.

Portanto, você deve aplicar condições de forma consistente para todas as atribuições de função em uma hierarquia de recursos.

Outras considerações

Operações de condição que gravam blobs

Muitas operações que gravam blobs exigem a Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write ou a Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action permissão. As funções integradas, como Proprietário de Dados de Blob de Armazenamento e Colaborador de Dados de Blob de Armazenamento, concedem permissões a um principal de segurança.

Ao definir uma condição de atribuição de função nessas funções, você deve usar condições idênticas em ambas as permissões para garantir restrições de acesso consistentes para operações de gravação.

Comportamento para Copiar Blob e Copiar Blob a partir da URL

Para as operações Copiar Blob e Copiar Blob da URL, as condições que usam o caminho de blob como atributo na ação e suas suboperações são avaliadas apenas para o blob de destino.

Para condições no blob de origem, @Resource as condições sobre a Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read ação são avaliadas.

Ver também

  • Last updated on