Freigeben über

Richtlinien und Einschränkungen für die Azure Storage-Firewall

Bevor Sie die Netzwerksicherheit für Ihre Speicherkonten implementieren, lesen Sie die wichtigen Einschränkungen und Überlegungen in diesem Abschnitt.

Allgemeine Richtlinien und Einschränkungen

  • Azure Storage-Firewallregeln gelten nur für Datenebenenvorgänge . Steuerungsebenenvorgänge unterliegen nicht den in Firewallregeln angegebenen Einschränkungen.

  • Um mithilfe von Tools wie dem Azure-Portal, Azure Storage-Explorer und AzCopy auf Daten zuzugreifen, müssen Sie einen Computer innerhalb der vertrauenswürdigen Grenze verwenden, die Sie beim Konfigurieren der Netzwerksicherheitsregeln festlegen.

    Einige Vorgänge, wie z. B. Blobcontainervorgänge, können sowohl über die Steuerungsebene als auch über die Datenebene ausgeführt werden. Wenn Sie versuchen, einen Vorgang auszuführen, z. B. das Auflisten von Containern aus dem Azure-Portal, wird der Vorgang erfolgreich ausgeführt, es sei denn, er wird von einem anderen Mechanismus blockiert. Versuche, über eine Anwendung wie Azure Storage-Explorer auf Blobdaten zuzugreifen, werden durch die Firewalleinschränkungen gesteuert.

    Eine Liste der Vorgänge auf Datenebene finden Sie in der REST-API-Referenz zu Azure Storage.

    Eine Liste der Vorgänge auf Steuerungsebene finden Sie in der Referenz zur REST-API des Azure-Speicherressourcenanbieters.

  • Netzwerkregeln werden für alle Netzwerkprotokolle für Azure Storage, einschließlich REST und SMB, erzwungen.

  • Netzwerkregeln wirken sich nicht auf den Datenverkehr von VM-Datenträgern aus – einschließlich Vorgängen zum Einbinden und Aufheben der Einbindung sowie Datenträger-E/A-Vorgängen –, aber sie tragen zum Schutz des REST-Zugriffs auf Seitenblobs bei.

  • Sie können nicht verwaltete Datenträger in Speicherkonten mit angewendeten Netzwerkregeln verwenden, um VMs durch Erstellung einer Ausnahme zu sichern und wiederherzustellen. Firewall-Ausnahmen gelten nicht für verwaltete Datenträger, da Sie von Azure bereits verwaltet werden.

  • Wenn Sie ein Subnetz löschen, das in einer virtuellen Netzwerkregel enthalten ist, wird es aus den Netzwerkregeln für das Speicherkonto entfernt. Wenn Sie ein neues Subnetz mit demselben Namen erstellen, hat es keinen Zugriff auf das Speicherkonto. Um den Zugriff zuzulassen, müssen Sie das neue Subnetz explizit in den Netzwerkregeln für das Speicherkonto autorisieren.

  • Wenn Sie auf einen Dienstendpunkt in einer Clientanwendung verweisen, wird empfohlen, eine Abhängigkeit von einer zwischengespeicherten IP-Adresse zu vermeiden. Die IP-Adresse des Speicherkontos kann geändert werden, und das Vertrauen auf eine zwischengespeicherte IP-Adresse kann zu unerwartetem Verhalten führen. Darüber hinaus empfehlen wir, die Time-to-Live (TTL) des DNS-Eintrags zu beachten und es zu vermeiden, diese zu überschreiben. Das Überschreiben des DNS-TTL kann zu unerwartetem Verhalten führen.

  • Der Zugriff auf ein Speicherkonto von vertrauenswürdigen Diensten hat die höchste Priorität gegenüber anderen Netzwerkzugriffseinschränkungen. Dies ist Absicht. Wenn Sie den öffentlichen Netzwerkzugriff auf Deaktiviert stellen, nachdem Sie ihn zuvor auf Aktivierung von ausgewählten virtuellen Netzwerken und IP-Adressen gestellt haben, bleiben etwaige Ressourceninstanzen und Ausnahmen, die Sie zuvor konfiguriert haben, einschließlich Azure-Diensten auf der Liste der vertrauenswürdigen Dienste den Zugriff auf dieses Speicherkonto erlauben, wirksam. Infolgedessen haben diese Ressourcen und Dienste möglicherweise weiterhin Zugriff auf das Speicherkonto.

  • Auch wenn Sie den Zugriff auf das öffentliche Netzwerk deaktivieren, erhalten Sie möglicherweise weiterhin eine Warnung von Microsoft Defender für Storage oder von Azure Advisor, der empfiehlt, den Zugriff mithilfe von Regeln für virtuelle Netzwerke einzuschränken. Dies kann in Fällen auftreten, in denen Sie den öffentlichen Zugriff mithilfe einer Vorlage deaktivieren. Die defaultAction-Eigenschaft bleibt auf "Zulassen" festgelegt, obwohl Sie die Eigenschaft "PublicNetworkAccess" auf "Disabled" festlegen. Während die PublicNetworkAccess-Eigenschaft Vorrang hat , berichten Tools wie Microsoft Defender auch über den Wert der defaultAction-Eigenschaft . Um dieses Problem zu beheben, verwenden Sie entweder eine Vorlage, um die DefaultAction-EigenschaftDeny festzulegen oder den öffentlichen Zugriff mithilfe von Tools wie Azure-Portal, PowerShell oder Azure CLI zu deaktivieren. Diese Tools ändern die defaultAction-Eigenschaft automatisch in den Wert " Verweigern " für Sie.

Einschränkungen für IP-Netzwerkregeln

  • IP-Netzwerkregeln sind nur für IP-Adressen des öffentlichen Internet zulässig.

    Für private Netzwerke reservierte IP-Adressbereiche (wie in RFC 1918 definiert) sind in IP-Adressregeln nicht zulässig. Private Netzwerke enthalten Adressen, die mit 10, 172.16. bis 172.31 und 192.168. beginnen.

  • Sie müssen zulässige Internetadressbereiche in der CIDR-Notation im Format 16.17.18.0/24 oder als einzelne IP-Adressen (beispielsweise 16.17.18.19) angeben.

  • Kleine Adressbereiche, die präfixgrößen /31 oder /32 verwenden, werden nicht unterstützt. Konfigurieren Sie diese Bereiche mithilfe einzelner IP-Adressregeln.

  • Für die Konfiguration von Storage-Firewallregeln werden nur IPv4-Adressen unterstützt.

  • Sie können keine IP-Netzwerkregeln verwenden, um den Zugriff auf Clients in derselben Azure-Region wie das Speicherkonto einzuschränken. IP-Netzwerkregeln haben keine Auswirkungen auf Anforderungen, die aus der Azure-Region stammen, in der sich auch das Speicherkonto befindet. Verwenden Sie VNET-Regeln, um Anforderungen aus der gleichen Region zuzulassen.

  • Sie können keine IP-Netzwerkregeln verwenden, um den Zugriff auf Clients in einer gekoppelten Region einzuschränken, die sich in einem virtuellen Netzwerk mit einem Dienstendpunkt befinden.

  • Sie können ip-Netzwerkregeln nicht verwenden, um den Zugriff auf Azure-Dienste einzuschränken, die in derselben Region wie das Speicherkonto bereitgestellt wurden.

    Dienste, die in derselben Region wie das Speicherkonto bereitgestellt werden, verwenden für die Kommunikation private Azure-IP-Adressen. Daher können Sie den Zugriff auf bestimmte Azure-Dienste nicht basierend auf ihrem öffentlichen ausgehenden IP-Adressbereich einschränken.

Nächste Schritte

  • Last updated on