Share via

Beveiligingsoverwegingen voor azure-roltoewijzingsvoorwaarden in Azure Blob Storage

  • Artikel

Als u resources volledig wilt beveiligen met behulp van op kenmerken gebaseerd toegangsbeheer van Azure (Azure ABAC), moet u ook de kenmerken beveiligen die worden gebruikt in de voorwaarden voor azure-roltoewijzing. Als uw voorwaarde bijvoorbeeld is gebaseerd op een bestandspad, moet u ervoor zorgen dat toegang kan worden aangetast als de principal een onbeperkte machtiging heeft om de naam van een bestandspad te wijzigen.

In dit artikel worden beveiligingsoverwegingen beschreven waarmee u rekening moet houden met de voorwaarden voor roltoewijzing.

Belangrijk

Op kenmerken gebaseerd toegangsbeheer van Azure (Azure ABAC) is algemeen beschikbaar (GA) voor het beheren van de toegang tot Azure Blob Storage, Azure Data Lake Storage Gen2 en Azure Queues met behulp van request, resourceen environmentprincipal kenmerken in de prestatielagen standard en Premium Storage-account. Momenteel zijn het resourcekenmerk voor containermetagegevens en de lijst-blob inclusief het aanvraagkenmerk in PREVIEW. Zie Status van voorwaardefuncties in Azure Storage voor volledige informatie over de functiestatus van ABAC voor Azure Storage.

Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Gebruik van andere autorisatiemechanismen

Voorwaarden voor roltoewijzing worden alleen geëvalueerd wanneer u Azure RBAC gebruikt voor autorisatie. Deze voorwaarden kunnen worden overgeslagen als u toegang toestaat met alternatieve autorisatiemethoden:

Op dezelfde manier worden voorwaarden niet geëvalueerd wanneer toegang wordt verleend met behulp van toegangsbeheerlijsten (ACL's) in opslagaccounts met een hiërarchische naamruimte (HNS).

U kunt gedeelde sleutel, SAS op accountniveau en SAS-autorisatie op serviceniveau voorkomen door autorisatie van gedeelde sleutels voor uw opslagaccount uit te schakelen. Aangezien SAS voor gebruikersdelegering afhankelijk is van Azure RBAC, worden voorwaarden voor roltoewijzing geëvalueerd bij het gebruik van deze autorisatiemethode.

Opslagkenmerken beveiligen die worden gebruikt in voorwaarden

Blobpad

Wanneer u het blobpad gebruikt als een @Resource kenmerk voor een voorwaarde, moet u ook voorkomen dat gebruikers de naam van een blob wijzigen om toegang te krijgen tot een bestand wanneer ze accounts gebruiken die een hiërarchische naamruimte hebben. Als u bijvoorbeeld een voorwaarde wilt maken op basis van het blobpad, moet u ook de toegang van de gebruiker beperken tot de volgende acties:

Actie Beschrijving
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action Met deze actie kunnen klanten de naam van een bestand wijzigen met behulp van de Path Create-API.
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action Met deze actie hebt u toegang tot verschillende bestandssysteem- en padbewerkingen.

Blob-indextags

Blob-indextags worden gebruikt als kenmerken van vrije vorm voor voorwaarden in de opslag. Als u toegangsvoorwaarden maakt met behulp van deze tags, moet u ook de tags zelf beveiligen. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write Met DataAction kunnen gebruikers de tags in een opslagobject wijzigen. U kunt deze actie beperken om te voorkomen dat gebruikers een tagsleutel of -waarde bewerken om toegang te krijgen tot niet-geautoriseerde objecten.

Als er in omstandigheden blobindextags worden gebruikt, zijn gegevens bovendien kwetsbaar als de gegevens en de bijbehorende indextags in afzonderlijke bewerkingen worden bijgewerkt. U kunt voorwaarden voor blob-schrijfbewerkingen gebruiken @Request om te vereisen dat indextags worden ingesteld in dezelfde updatebewerking. Met deze methode kunt u gegevens beveiligen vanaf het moment dat ze naar de opslag worden geschreven.

Tags voor gekopieerde blobs

Standaard worden blob-indextags niet gekopieerd van een bron-blob naar het doel wanneer u De Blob-API of een van de varianten ervan kopieert. Als u het toegangsbereik voor blob bij het kopiëren wilt behouden, moet u ook de tags kopiëren.

Tags voor momentopnamen

Tags op blobmomentopnamen kunnen niet worden gewijzigd. Daarom moet u de tags op een blob bijwerken voordat u de momentopname maakt. Als u de tags op een basisblob wijzigt, blijven de tags op de momentopname de vorige waarde behouden.

Als een tag op een basis-blob wordt gewijzigd nadat een momentopname is gemaakt, kan het toegangsbereik afwijken voor de basis-blob en de momentopname.

Tags voor blobversies

Blob-indextags worden niet gekopieerd wanneer een blobversie wordt gemaakt via de Put Blob, Put Block List of Copy Blob-API's . U kunt tags opgeven via de header voor deze API's.

Tags kunnen afzonderlijk worden ingesteld op een huidige basis-blob en op elke blobversie. Wanneer u tags op een basis-blob wijzigt, worden de tags in eerdere versies niet bijgewerkt. Als u het toegangsbereik voor een blob en alle bijbehorende versies met behulp van tags wilt wijzigen, moet u de tags voor elke versie bijwerken.

Beperkingen voor query's en filteren voor versies en momentopnamen

Wanneer u tags gebruikt voor het opvragen en filteren van blobs in een container, worden alleen de basis-blobs opgenomen in het antwoord. Blobversies of momentopnamen met de aangevraagde sleutels en waarden worden niet opgenomen.

Rollen en machtigingen

Als u voorwaarden voor roltoewijzing gebruikt voor ingebouwde Azure-rollen, moet u zorgvuldig alle machtigingen controleren die de rol aan een principal verleent.

Overgenomen roltoewijzingen

Roltoewijzingen kunnen worden geconfigureerd voor een beheergroep, abonnement, resourcegroep, opslagaccount of een container en worden overgenomen op elk niveau in de opgegeven volgorde. Azure RBAC heeft een additief model, dus de effectieve machtigingen zijn de som van roltoewijzingen op elk niveau. Als aan een principal dezelfde machtiging is toegewezen via meerdere roltoewijzingen, wordt de toegang voor een bewerking met die machtiging afzonderlijk geëvalueerd voor elke toewijzing op elk niveau.

Omdat voorwaarden worden geïmplementeerd als voorwaarden voor roltoewijzingen, kan elke onvoorwaardelijke roltoewijzing gebruikers toestaan om de voorwaarde te omzeilen. Stel dat u de rol Inzender voor opslagblobgegevens toewijst aan een gebruiker voor een opslagaccount en aan een abonnement, maar alleen een voorwaarde toevoegt aan de toewijzing voor het opslagaccount. Het resultaat is dat de gebruiker onbeperkte toegang heeft tot het opslagaccount via de roltoewijzing op abonnementsniveau.

Daarom moet u voorwaarden consistent toepassen voor alle roltoewijzingen in een resourcehiërarchie.

Andere overwegingen

Voorwaardebewerkingen die blobs schrijven

Voor veel bewerkingen die blobs schrijven, is de Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write machtiging of de Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action machtiging vereist. Ingebouwde rollen, zoals eigenaar van opslagblobgegevens en Inzender voor opslagblobgegevens, verlenen beide machtigingen aan een beveiligingsprincipaal.

Wanneer u een voorwaarde voor roltoewijzing voor deze rollen definieert, moet u identieke voorwaarden voor beide machtigingen gebruiken om consistente toegangsbeperkingen voor schrijfbewerkingen te garanderen.

Gedrag voor het kopiëren van blob en het kopiëren van een blob vanuit URL

Voor de bewerkingen Blob kopiëren en Blob kopiëren vanuit URL worden @Request voorwaarden met behulp van het blobpad als kenmerk voor de Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write actie en de bijbehorende suboperations alleen geëvalueerd voor de doel-blob.

Voor voorwaarden op de bron-blob @Resource worden voorwaarden voor de Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read actie geëvalueerd.

Zie ook