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/virtual-network-manager/concept-enforcement.md
+9-6Lines changed: 9 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ In this article, you'll learn how [security admins rules](concept-security-admin
21
21
22
22
With network security groups (NSGs) alone, widespread enforcement on VNets across several applications, teams, or even entire organizations can be tricky. Often there’s a balancing act between attempts at centralized enforcement across an organization and handing over granular, flexible control to teams.
23
23
24
-
Security admin rules aim to eliminate this sliding scale between enforcement and flexibility altogether by consolidating the pros of each of these models while reducing the cons of each. Central governance teams establish guard rails through security admin rules, while still leaving room for individual teams to flexibly pinpoint security as needed through NSG rules. Security admin rules aren't meant to override NSG rules, but rather interact in different ways depending on the type of action specified in the security admin rule.
24
+
Security admin rules aim to eliminate this sliding scale between enforcement and flexibility altogether by consolidating the pros of each of these models while reducing the cons of each. Central governance teams establish guard rails through security admin rules, while still leaving room for individual teams to flexibly pinpoint security as needed through NSG rules. Security admin rules aren't meant to override NSG rules. Instead they interact in different ways depending on the type of action specified in the security admin rule.
25
25
26
26
## Enforcement Models
27
27
@@ -46,11 +46,11 @@ In this model, NSGs are still managed by individual teams. The difference is the
46
46
47
47
| Pros | Cons |
48
48
| ---- | ---- |
49
-
| The individual team has flexible control in tailoring security rules. </br></br> The central governance team can create standard security rules and receive notifications if these are modified. | The central governance team still can't enforce the standard security rules, since NSG owners in teams can still modify them. </br></br> Notifications would also be overwhelming to manage. |
49
+
| The individual team has flexible control in tailoring security rules. </br></br> The central governance team can create standard security rules and receive notifications if rules are modified. | The central governance team still can't enforce the standard security rules, since NSG owners in teams can still modify them. </br></br> Notifications would also be overwhelming to manage. |
50
50
51
51
## Enforcement and flexibility in practice
52
52
53
-
Let’s apply the concepts discussed so far to an example scenario. A company network administrator wants to enforce a security rule to block inbound SSH traffic for the whole company. As mentioned above, having such enforcement was difficult without AVNM’s security admin rule. If the administrator manages all the NSGs, then management overhead is high, and the administrator cannot rapidly respond to product teams’ needs to modify NSG rules. On the other hand, if the product teams manage their own NSGs without security admin rules, then the administrator cannot enforce critical security rules, leaving potential security risks open. Using both security admin rules and NSGs can solve this dilemma. In this case, the administrator wants to make an exception for application as the application team needs more time to make changes to not rely on SSH. The diagram below visualizes how the administrator can achieve the goal of enforcement with security admin rules, while leaving an exception open for the Application 1 team to handle SSH traffic through NSGs.
53
+
Let’s apply the concepts discussed so far to an example scenario. A company network administrator wants to enforce a security rule to block inbound SSH traffic for the whole company. As mentioned above, having such enforcement was difficult without AVNM’s security admin rule. If the administrator manages all the NSGs, then management overhead is high, and the administrator can't rapidly respond to product teams’ needs to modify NSG rules. On the other hand, if the product teams manage their own NSGs without security admin rules, then the administrator can't enforce critical security rules, leaving potential security risks open. Using both security admin rules and NSGs can solve this dilemma. In this case, the administrator wants to make an exception for application as the application team needs more time to make changes to not rely on SSH. The diagram below shows how the administrator can achieve the goal of enforcement with security admin rules, and leave an exception for the Application team to handle SSH traffic through NSGs.
54
54
55
55
:::image type="content" source="media/concept-enforcement/example-rules-enforcement.png" alt-text="Diagram of security admin rules enforcement with network security groups.":::
56
56
@@ -60,15 +60,18 @@ The company administrator can create a network manager with the root management
60
60
61
61
#### Step 2: Create network groups for VNets
62
62
63
-
The administrator creates two network groups – “ALL Network Group,” consisting of all the VNets in the organization, and “App 1 Network Group,” consisting of VNets for Application 1. ALL Network Group in the above diagram consists of VNet 1 to VNet 5, and App 1 Network Group has VNet 4 and VNet 5. Users can easily define both network groups using dynamic membership.
63
+
The administrator creates the following network groups:
64
+
– *ALL Network Group*: consisting of all the VNets in the organization
65
+
-*App 1 Network Group* consisting of VNets for Application 1.
66
+
ALL Network Group in the above diagram consists of VNet 1 to VNet 5, and App 1 Network Group has VNet 4 and VNet 5. Users can easily define both network groups with dynamic membership.
64
67
65
68
#### Step 3: Create a security admin configuration
66
69
67
-
This security admin configuration contains a security admin rule to block inbound SSH traffic for ALL Network Group and another security admin rule to allow inbound SSH traffic for App 1 Network Group with a higher priority.
70
+
This security admin configuration contains a security admin rule to block inbound SSH traffic for *ALL Network Group* and another security admin rule to allow inbound SSH traffic for *App 1 Network *Group* with a higher priority.
68
71
69
72
#### Step 4: Deploy the security admin configuration
70
73
71
-
After the deployment of the security admin configuration, all VNets in the company will have the deny inbound SSH traffic rule enforced by the security admin rule. No individual team can modify this rule, only the administrator. The App 1 VNets will have both an allow inbound SSH traffic rule and a deny inbound SSH traffic rule. The priority number of the allow inbound SSH traffic rule for App 1 Network Group should be smaller so that it's evaluated first. When inbound SSH traffic comes to an App 1 VNet, it will be allowed by this higher priority security admin rule. Assuming there are NSGs on the subnets of the App 1 VNets, this inbound SSH traffic will be further evaluated by NSGs set by the Application 1 team. Using this methodology, the company administrator can effectively enforce company policies and create security guard rails, while product teams can simultaneously react to meet their needs by owning the control of NSGs.
74
+
After the deployment of the security admin configuration, all VNets in the company will have the deny inbound SSH traffic rule enforced by the security admin rule. No individual team can modify this rule, only the administrator. The App 1 VNets will have both an allow inbound SSH traffic rule and a deny inbound SSH traffic rule. The priority number of the allow inbound SSH traffic rule for App 1 Network Group should be smaller so that it's evaluated first. When inbound SSH traffic comes to an App 1 VNet, it will be allowed by this higher priority security admin rule. Assuming there are NSGs on the subnets of the App 1 VNets, this inbound SSH traffic will be further evaluated by NSGs set by the Application 1 team. With this method, the company administrator can effectively enforce company policies and create security guard rails. And the product teams can simultaneously react to meet their needs by owning the control of NSGs.
0 commit comments