You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/storage/common/storage-network-security-perimeter.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,28 +15,28 @@ ms.author: normesta
15
15
16
16
[Network security perimeter](../../private-link/network-security-perimeter-concepts.md) allows organizations to define a logical network isolation boundary for PaaS resources (for example, Azure Blob Storage and SQL Database) that are deployed outside their virtual networks. The feature restricts public network access to PaaS resources outside the perimeter. However, you can exempt access by using explicit access rules for public inbound and outbound traffic. This helps prevent unwanted data exfiltration from your storage resources. Within a Network Security Perimeter, member resources can freely communicate with each other. network security perimeter rules override the storage account’s own firewall settings. Access from within the perimeter takes highest precedence over other network restrictions.
17
17
18
-
The list of services that have been onboarded to network security perimeter can be found [here](../../private-link/network-security-perimeter-concepts.md#onboarded-private-link-resources). For services that are not on this list, as they have not yet been onboarded to network security perimeter, if you would like to allow access to a specific resource you can use a subscription-based rule on the network security perimeter. All resources within that subscription will then be given access to that network security perimeter. For more information on adding subscription-based access rule, refer [here](/rest/api/networkmanager/nsp-access-rules/create-or-update).
18
+
You can find the list of services that have been onboarded to the network security perimeter [here](../../private-link/network-security-perimeter-concepts.md#onboarded-private-link-resources). If a service is not listed, it has not yet been onboarded. To allow access to a specific resource from a non-onboarded service, you can create a subscription-based rule for the network security perimeter. This will grant access to all resources within that subscription. For details on how to add a subscription-based access rule, see [this documentation](/rest/api/networkmanager/nsp-access-rules/create-or-update).
19
19
20
20
## Access Modes
21
21
22
-
When onboarding storage accounts to a network security perimeter, you can start in Transition mode (formerly Learning mode) or go straight to [Enforced mode](../../private-link/network-security-perimeter-transition.md#access-mode-configuration-point-on-resource-associations). Transition mode (the default) allows the storage account to fall back to its existing firewall rules or [“trusted services”](https://learn.microsoft.com/azure/storage/common/storage-network-security?tabs=azure-portal#exceptions-for-trusted-azure-services) settings if a perimeter rule doesn’t yet permit a connection. Enforced mode strictly blocks all public inbound and outbound traffic unless explicitly allowed by a network security perimeter rule, ensuring maximum protection for your storage account. In enforced mode, even Azure’s “trusted service” exceptions are not honored. Relevant Azure resources or specific subscriptions must be explicitly allowed via perimeter rules if needed.
22
+
When onboarding storage accounts to a network security perimeter, you can start in Transition mode (formerly Learning mode) or go straight to [Enforced mode](../../private-link/network-security-perimeter-transition.md#access-mode-configuration-point-on-resource-associations). Transition mode (the default) allows the storage account to fall back to its existing firewall rules or ["trusted services"](https://learn.microsoft.com/azure/storage/common/storage-network-security?tabs=azure-portal#exceptions-for-trusted-azure-services) settings if a perimeter rule doesn’t yet permit a connection. Enforced mode strictly blocks all public inbound and outbound traffic unless explicitly allowed by a network security perimeter rule, ensuring maximum protection for your storage account. In enforced mode, even Azure’s "trusted service" exceptions aren't honored. Relevant Azure resources or specific subscriptions must be explicitly allowed via perimeter rules if needed.
23
23
24
24
> [!IMPORTANT]
25
25
> Operating Storage accounts in **Transition (formerly Learning)** mode should serve only as a transitional step. Malicious actors may exploit unsecured resources to exfiltrate data. Therefore, it's crucial to transition to a fully secure configuration as soon as possible with the access mode set to **Enforced**.
26
26
>
27
27
28
28
## Network priotiy
29
-
When a storage account is part of a network security perimeter, the relevant [profile's](../../private-link/network-security-perimeter-concepts.md#components-of-a-network-security-perimeter) access rules override the account’s own firewall settings, becoming the top-level network gatekeeper. Access allowed or denied by the perimeter takes precedence, and the account’s “Allowed networks” settings are bypassed when the storage account is associated in enforced mode. Removing the storage account from a network security perimeter reverts control back to its regular firewall. Network security perimeters do not affect private endpoint traffic. Connections via private link always succeed. For internal Azure services (“trusted Services”), only those explicitly [onboarded to Network Security Perimeter](../../private-link/network-security-perimeter-concepts.md#onboarded-private-link-resources) can be allowed through perimeter access rules. Otherwise, their traffic is blocked by default, even if trusted on the storage account firewall rules. For services not yet onboarded, alternatives include subscription-level rules for inbound and FQDNs for outbount access or via private links.
29
+
When a storage account is part of a network security perimeter, the relevant [profile's](../../private-link/network-security-perimeter-concepts.md#components-of-a-network-security-perimeter) access rules override the account’s own firewall settings, becoming the top-level network gatekeeper. Access allowed or denied by the perimeter takes precedence, and the account’s "Allowed networks" settings are bypassed when the storage account is associated in enforced mode. Removing the storage account from a network security perimeter reverts control back to its regular firewall. Network security perimeters do not affect private endpoint traffic. Connections via private link always succeed. For internal Azure services ("trusted services"), only those explicitly [onboarded to Network Security Perimeter](../../private-link/network-security-perimeter-concepts.md#onboarded-private-link-resources) can be allowed through perimeter access rules. Otherwise, their traffic is blocked by default, even if trusted on the storage account firewall rules. For services not yet onboarded, alternatives include subscription-level rules for inbound and FQDNs for outbount access or via private links.
30
30
31
31
> [!IMPORTANT]
32
-
> Private endpoint traffic is considered highly secure and therefore isn't subject to network security perimeter rules. All other traffic, including trusted services, will be subject to network security perimeter rules if the storage account is associated with a perimeter.
32
+
> Private endpoint traffic is considered highly secure and therefore isn't subject to network security perimeter rules. All other traffic, including trusted services, are subject to network security perimeter rules if the storage account is associated with a perimeter.
33
33
34
34
## Feature coverage under network security perimeter
35
-
When a storage account is associated with a network security perimeter, all standard data-plane operations for blobs, files, tables, and queues are supported as long as they don’t fall under the known [limitations](#limitations). All HTTPS-based operations for Azure Blob Storage, Azure Data Lake Storage Gen2, Azure Files (via REST API or SDK), Azure Table Storage, and Azure Queue Storage are supported with network security perimeter enforcement, allowing you to restrict access by network. Access and data transfer via NFS for Azure Blobs and Azure Files, and via SMB for Azure files are not natively covered by network security perimeter and will be blocked when a storage account is associated with a perimeter.
35
+
When a storage account is associated with a network security perimeter, all standard data-plane operations for blobs, files, tables, and queues are supported as long as they don’t fall under the known [limitations](#limitations). All HTTPS-based operations for Azure Blob Storage, Azure Data Lake Storage Gen2, Azure Files (via REST API or SDK), Azure Table Storage, and Azure Queue Storage are supported with network security perimeter enforcement, allowing you to restrict access by network.
36
36
37
37
## Limitations
38
38
39
-
Below is a list of platform features that are not supported when a storage account is associated with a network security perimeter.
39
+
Below is a list of platform features that aren't supported when a storage account is associated with a network security perimeter.
0 commit comments