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

Para proteger totalmente os recursos usando o Azure ABAC (controle de acesso baseado em atributo do Azure), 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, é importante estar ciente de que o acesso pode ser comprometido se o usuário principal tiver uma permissão sem restrições para renomear um caminho de arquivo.

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

Uso 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. Essas condições poderão ser ignoradas se você permitir o acesso usando métodos de autorização alternativos:

• Autorização de chave compartilhada
• Assinatura de Acesso Compartilhado da conta (SAS)
• SAS de serviço.

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

Você pode impedir a chave compartilhada, a SAS no nível da conta e a autorização de SAS no nível do serviço desabilitando 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.

Proteger atributos de armazenamento usados em condições

Caminho do blob

Ao usar o caminho do 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 do blob, também deverá restringir o acesso do usuário às seguintes ações:

Marcas de índice de blob

Marcas 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 marcas, também deverá proteger as próprias marcas. Especificamente, o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction permite que os usuários modifiquem as marcas em um objeto de armazenamento. Você pode restringir essa ação para impedir que os usuários manipulem uma chave de marca ou valor para obter acesso a objetos não autorizados.

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

Marcas em blobs copiados

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

Marcas em instantâneos

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

Se a marca de um blob de base for modificada depois que um instantâneo for tirado, os escopos de acesso do blob de base e do instantâneo poderão ser diferentes.

Marcas em versões de blob

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

As marcas podem ser definidas individualmente em um blob de base atual e em cada versão de blob. Quando você modifica marcas em um blob base, as marcas nas 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 marcas, deverá atualizar as marcas em cada versão.

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

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

Funções e permissões

Se você estiver usando condições de atribuição de função para funções internas do Azure, examine 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 um contêiner e são herdadas em cada nível na ordem declarada. 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 principal 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 todos os níveis.

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 Colaborador de Dados do Blob de Armazenamento a um usuário para uma conta de armazenamento e em uma assinatura, mas adicione uma condição somente à 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 consistentemente 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 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Funções internas, como Proprietário de Dados do Blob de Armazenamento e Colaborador de Dados do 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 a partir da URL, as condições que utilizam o caminho do blob como atributo na ação @Request e suas suboperações são avaliadas apenas para o blob de destino.

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

Consulte também

• Autorizar o acesso a blobs usando condições de atribuição de função do Azure
• Ações e atributos das condições de atribuição de função do Azure para o Armazenamento de Blobs do Azure
• O que é o ABAC do Azure (controle de acesso baseado em atributo do Azure)?