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 ABAC do Azure, você também deve proteger os atributos usados nas condições de atribuição de função do Azure. Por exemplo, se a sua condição for baseada em um caminho de arquivo, você precisa estar ciente de que o acesso pode ser comprometido se a entidade de segurança tiver uma permissão irrestrita para renomear um caminho de arquivo.
Este artigo descreve as observações sobre segurança que você deve considerar em suas condições de atribuição de função.
Importante
O ABAC (controle de acesso baseado em atributos) do Azure tem GA (disponibilidade geral) para controlar o acesso ao Armazenamento de Blobs do Azure, ao Azure Data Lake Storage Gen2 e às Filas do Azure usando os atributos request, resource, environment e principal nas camadas de desempenho das contas de armazenamento Standard e Premium. No momento, 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 VERSÃO PRÉVIA. Para obter informações completas sobre o status do recurso do ABAC para o Armazenamento do Azure, consulte Status dos recursos de condição no Armazenamento do Azure.
Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
Uso de outros mecanismos de autorização
As condições de atribuição de função são avaliadas somente ao usar o RBAC do Azure para autorização. Essas 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 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 de blob como um atributo @Resource para uma condição, você também deve impedir que os usuários renomeie 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 baseada no caminho do 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 Path Create. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
Essa ação permite o acesso a várias operações de caminho e sistema de arquivos. |
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 alguma condição de acesso usando essas marcas, também deverá proteger as marcas. Especificamente, o DataAction Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write 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 ou valor de marca 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 técnica pode ajudar a proteger os dados desde o instante em que eles 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 tags em instantâneos de blob não podem ser modificadas. Portanto, você precisa atualizar as marcas de um blob antes de tirar o instantâneo. 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 marcas 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 as marcas em um blob de base, as marcas nas versões anteriores não são atualizadas. Se você quiser alterar o escopo de acesso de um blob e de 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
Ao usar marcas 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 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, uma assinatura, um grupo de recursos, uma conta de armazenamento ou um contêiner e são herdadas em cada nível na ordem afirmada. O RBAC do Azure é 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 de segurança tiver a mesma permissão atribuída por meio de várias atribuições de função, o acesso para uma operação que use 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 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 as 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 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 nessas duas permissões para garantir restrições de acesso consistentes para operações de gravação.
Comportamento de Copy Blob e Copy Blob from URL
Para as operações Copy Blob e Copy Blob from URL, as condições @Request que usam o caminho do blob como atributo na ação Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write e suas suboperações são avaliadas somente 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.