Skip to content

Commit 72e7bbe

Browse files
committed
Fixing capitalization issues
1 parent 10fd2e4 commit 72e7bbe

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

articles/storage/common/storage-network-security-perimeter.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ ms.author: normesta
1313

1414
# Network security perimeter for Azure Storage
1515

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.
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.
1717

1818
You can find the list of services that are onboarded to the network security perimeter [here](../../private-link/network-security-perimeter-concepts.md#onboarded-private-link-resources). If a service isn't listed, it is not onboarded yet. To allow access to a specific resource from a non-onboarded service, you can create a subscription-based rule for the network security perimeter. A subscription-based rule grants 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).
1919

@@ -26,7 +26,7 @@ When onboarding storage accounts to a network security perimeter, you can start
2626
>
2727
2828
## Network priority
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 don't affect private endpoint traffic. Connections via private link always succeed. For internal Azure services ("trusted services"), only services 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 Fully Qualified Domain Names (FQDN) for outbound 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 don't affect private endpoint traffic. Connections via private link always succeed. For internal Azure services ("trusted services"), only services 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 Fully Qualified Domain Names (FQDN) for outbound access or via private links.
3030

3131
> [!IMPORTANT]
3232
> Private endpoint traffic is considered highly secure and therefore isn't subject to network security perimeter rules. All other traffic, including trusted services, is subject to network security perimeter rules if the storage account is associated with a perimeter.

0 commit comments

Comments
 (0)