Considerações de segurança para condições de atribuição de função do Azure no Armazenamento de Blobs do Azure

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 controle de acesso baseado em atributos do Azure (Azure ABAC) está geralmente disponível (GA) para controlar o acesso ao Armazenamento de Blobs do Azure, ao Azure Data Lake Storage Gen2 e às Filas do Azure usando request, resource, environmente principal atributos nas camadas de desempenho da conta de armazenamento padrão e premium. Atualmente, o atributo de recurso de metadados de contêiner e o atributo de solicitação de inclusão de blob de lista estão em VISUALIZAÇÃO. Para obter informações completas sobre o status do recurso do ABAC para Armazenamento do Azure, consulte Status dos recursos de condição no Armazenamento do Azure.

Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na 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 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

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 você quiser criar uma condição com base no caminho de blob, também deve restringir o acesso do usuário à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 tags de índice de blob forem usadas em condições, os dados poderão ficar vulneráveis se os dados e as tags 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 você usa a API de Blob de Cópia 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.

Tags 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. 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 uma entidade de segurança.

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 uma entidade tiver a mesma permissão atribuída a ela por meio de várias 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 você atribua a função de Colaborador de Dados de Blob de Armazenamento a um usuário para uma conta de armazenamento e em uma assinatura, mas adicione uma condição apenas à atribuição da 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 permissão ou a Microsoft.Storage/storageAccounts/blobServices/containers/blobs/writeMicrosoft.Storage/storageAccounts/blobServices/containers/blobs/add/action permissão. As funções internas, como Proprietário de Dados de Blob de Armazenamento e Colaborador de Dados de Blob de Armazenamento , concedem ambas as permissões a uma entidade 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 da URL

Para as operações Copiar Blob e Copiar Blob da URL , @Request as condições que usam o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write 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.

Consulte também