Skip to content

Latest commit

 

History

History
75 lines (71 loc) · 3.45 KB

File metadata and controls

75 lines (71 loc) · 3.45 KB

IMPORTANT: DevOps Kit (AzSK) is being sunset by end of FY21. More details here


VirtualNetwork

Description & Rationale ControlSeverity Automated Fix Script
Minimize the number of Public IPs (i.e. NICs with PublicIP) on a virtual network
Public IPs provide direct access over the internet exposing the VM to all type of attacks over the public network.
High Yes No
Use of IP Forwarding on any NIC in a virtual network should be scrutinized
Enabling IP Forwarding on a VM NIC allows the VM to receive traffic addressed to other destinations. IP forwarding is required only in rare scenarios (e.g., using the VM as a network virtual appliance) and those should be reviewed with the network security team.
High Yes No
NSG should be used for subnets in a virtual network to permit traffic only on required inbound/outbound ports. NSGs should not have a rule to allow any-to-any traffic
Restricting inbound and outbound traffic via NSGs limits the network exposure of the subnets within a virtual network and limits the attack surface.
Medium Yes No
All users/identities must be granted minimum required permissions using Role Based Access Control (RBAC)
Granting minimum access by leveraging RBAC feature ensures that users are granted just enough permissions to perform their tasks. This minimizes exposure of the resources in case of user/service account compromise.
Medium Yes No
Presence of any virtual network gateways (GatewayType = VPN/ExpressRoute) in the virtual network must be justified
Virtual network gateways enable network traffic between a virtual network and other networks. All such connectivity must be carefully scrutinized to ensure that corporate data is not subject to exposure on untrusted networks.
High Yes No
Use of any virtual network peerings should be justified
Resources in the peered virtual networks can communicate with each other directly. If the two peered networks are on different sides of a security boundary (e.g., corpnet v. private vNet), this can lead to exposure of corporate data. Hence any vNet peerings should be closely scrutinized and approved by the network security team
High Yes No