Delen via

Richtlijnen en beperkingen voor de Azure Storage-firewall

Voordat u netwerkbeveiliging voor uw opslagaccounts implementeert, bekijkt u de belangrijke beperkingen en overwegingen in deze sectie.

Algemene richtlijnen en beperkingen

  • Firewallregels van Azure Storage zijn alleen van toepassing op bewerkingen in het gegevensvlak . Besturingsvlakbewerkingen zijn niet onderhevig aan de beperkingen die zijn opgegeven in firewallregels.

  • Als u toegang wilt krijgen tot gegevens met behulp van hulpprogramma's zoals Azure Portal, Azure Storage Explorer en AzCopy, moet u zich op een computer bevinden binnen de vertrouwde grens die u tot stand brengt bij het configureren van netwerkbeveiligingsregels.

    Sommige bewerkingen, zoals blobcontainerbewerkingen, kunnen worden uitgevoerd via zowel het besturingsvlak als het gegevensvlak. Als u probeert een bewerking uit te voeren, zoals het weergeven van containers uit Azure Portal, slaagt de bewerking, tenzij deze wordt geblokkeerd door een ander mechanisme. Pogingen om toegang te krijgen tot blobgegevens vanuit een toepassing zoals Azure Storage Explorer, worden beheerd door de firewallbeperkingen.

    Voor een lijst met gegevensvlakbewerkingen, zie de Azure Storage REST API-referentie.

    Zie de Azure Storage-resourceprovider REST API-referentie voor een lijst van besturingsvlakbewerkingen.

  • Netwerkregels worden afgedwongen op alle netwerkprotocollen voor Azure Storage, inclusief REST en SMB.

  • Netwerkregels hebben geen invloed op schijfverkeer van virtuele machines (VM's), inclusief koppel- en ontkoppelbewerkingen en schijf-I/O, maar ze helpen wel OM REST-toegang tot pagina-blobs te beveiligen.

  • U kunt niet-beheerde schijven in opslagaccounts gebruiken met netwerkregels die zijn toegepast om een back-up te maken van VM's en deze te herstellen door een uitzondering te maken. Firewall-uitzonderingen zijn niet van toepassing op beheerde schijven, omdat azure deze al beheert.

  • Als u een subnet verwijdert dat is opgenomen in een regel voor een virtueel netwerk, wordt dit verwijderd uit de netwerkregels voor het opslagaccount. Als u een nieuw subnet met dezelfde naam maakt, heeft het geen toegang tot het opslagaccount. Als u toegang wilt toestaan, moet u het nieuwe subnet expliciet autoriseren in de netwerkregels voor het opslagaccount.

  • Wanneer u verwijst naar een service-eindpunt in een clienttoepassing, wordt u aangeraden geen afhankelijkheid te maken van een IP-adres in de cache. Het IP-adres van het opslagaccount kan worden gewijzigd en het vertrouwen op een IP-adres in de cache kan leiden tot onverwacht gedrag. Daarnaast raden we u aan om de time-to-live (TTL) van de DNS-record te respecteren en te voorkomen dat u deze overschrijft. Het overschrijven van de DNS-TTL kan leiden tot onverwacht gedrag.

  • Standaard heeft toegang tot een opslagaccount via vertrouwde services de hoogste prioriteit boven andere netwerktoegangsbeperkingen. Als u openbare netwerktoegang instelt op Uitgeschakeld nadat u deze eerder hebt ingesteld op Ingeschakeld vanuit geselecteerde virtuele netwerken en IP-adressen, blijven alle resource-exemplaren en uitzonderingen die u eerder hebt geconfigureerd, inclusief Toestaan dat Azure-services in de lijst met vertrouwde services toegang hebben tot dit opslagaccount, van kracht. Daardoor hebben die middelen en diensten mogelijk nog steeds toegang tot de opslagrekening.

  • Zelfs als u openbare netwerktoegang uitschakelt, ontvangt u mogelijk nog steeds een waarschuwing van Microsoft Defender voor Storage of van Azure Advisor waarmee u de toegang kunt beperken met behulp van regels voor virtuele netwerken. Dit kan gebeuren in gevallen waarin u openbare toegang uitschakelt met behulp van een sjabloon. De eigenschap defaultAction blijft ingesteld op Toestaan , ook al stelt u de eigenschap PublicNetworkAccess in op Uitgeschakeld. Hoewel de eigenschap PublicNetworkAccess voorrang heeft, rapporteren hulpprogramma's zoals Microsoft Defender ook over de waarde van de eigenschap defaultAction . U kunt dit probleem oplossen door een sjabloon te gebruiken om de eigenschap DefaultActionDeny in te stellen of openbare toegang uit te schakelen met behulp van een hulpprogramma zoals Azure Portal, PowerShell of Azure CLI. Met deze hulpprogramma's wordt de eigenschap defaultAction automatisch gewijzigd in de waarde Deny voor u.

Beperkingen voor IP-netwerkregels

  • IP-netwerkregels zijn alleen toegestaan voor openbare internet-IP-adressen .

    IP-adresbereiken die zijn gereserveerd voor privénetwerken (zoals gedefinieerd in RFC 1918) zijn niet toegestaan in IP-regels. Privénetwerken bevatten adressen die beginnen met 10, 172.16 tot 172.31 en 192.168.

  • U moet toegestane internetadresbereiken opgeven met cidr-notatie in de vorm 16.17.18.0/24 of als afzonderlijke IP-adressen zoals 16.17.18.19.

  • Kleine adresbereiken die gebruikmaken van /31- of /32-voorvoegsels worden niet ondersteund. Configureer deze bereiken met behulp van afzonderlijke regels voor IP-adressen.

  • Alleen IPv4-adressen worden ondersteund voor de configuratie van firewallregels voor opslag.

  • U kunt geen IP-netwerkregels gebruiken om de toegang tot clients in dezelfde Azure-regio als het opslagaccount te beperken. IP-netwerkregels hebben geen invloed op aanvragen die afkomstig zijn van dezelfde Azure-regio als het opslagaccount. Gebruik regels voor virtuele netwerken om aanvragen van dezelfde regio toe te staan.

  • U kunt geen IP-netwerkregels gebruiken om de toegang tot clients in een gekoppelde regio te beperken die zich in een virtueel netwerk bevinden met een service-eindpunt.

  • U kunt geen IP-netwerkregels gebruiken om de toegang tot Azure-services te beperken die zijn geïmplementeerd in dezelfde regio als het opslagaccount.

    Services die zijn geïmplementeerd in dezelfde regio als het opslagaccount, gebruiken privé Azure IP-adressen voor communicatie. Daarom kunt u de toegang tot specifieke Azure-services niet beperken op basis van hun openbare uitgaande IP-adresbereik.

Volgende stappen

  • Last updated on