Network Security (Part 2 of 3)

By Ashwin Venugopal -



 


To read part 1 please click here
To read part 3 please click here


Application Security Groups or ASGs

ASGs enables you to configure network security as a natural extension of an application's structure and then you can easily group VMs and define network security policies based on those groups while also allowing you to reuse your security policy at scale without any manual maintenance of explicit IP addresses. NSG1 is associated to both subnets and contains following rules:
  • Allow-HTTP-Inbound-Internet
  • Deny-Database-All
  • Allow-Database-BusinessLogic 

The rules that specify an ASG as the source or destination are only applied to the network interfaces that are members of the ASG, but if they are not a member of an ASG, the rule is not applied to the network interface even though the network security group (NSG) is associated to the subnet. 

ASGs have the following constraints

  • There are limits to the number of ASGs you can have in a subscription, in addition to the other limits related to ASGs.
  • You can specify one ASG as the source and destination in a security rule but cannot specify multiple ASGs in the source or destination.
  • All network interfaces assigned to an ASG must exist in the same virtual network as the first network interface is assigned to the ASG.
  • If you specify an ASG as the source and destination in a security rule, the network interfaces in both ASGs must exist in the same virtual network.  

Hence ASGs along with the NSGs, have brought multiple benefits on the network security area:

  • A single management experience
  • Increased limits on multiple dimensions
  • A great level of simplification
  • A seamless integration with your architecture 

Service Endpoints

A virtual network service endpoints provides the identity of your virtual network to the Azure service. once they are enabled in your virtual network, you can secure Azure service resources to your virtual network by adding a virtual network rule to the resources.
A common usage case for service endpoints is a virtual machine accessing storage. The storage account restricts access to the virtual machines private IP address.

Why use a service endpoint?
  • Improved security for your Azure service resources- Once service endpoints are enabled in your virtual network, you can secure Azure service resources to your virtual network by adding a virtual network rule to the resources. This offers improved security by fully removing public Internet access to resources, and allowing traffic only from your virtual network.

  • Endpoints always take service traffic directly from your virtual network to the service on the Microsoft Azure backbone network- Keeping traffic on the Azure backbone network allows you to continue auditing and monitoring outbound Internet traffic from your virtual networks, through forced-tunneling, without impacting service traffic.

  • Simple to set up with less management overhead- No NAT or gateway devices are required to set up the service endpoints, but they are configured through a simple click on a subnet. There is no additional overhead to maintain the endpoints.   

With the help of service endpoints, the source IP addresses of the virtual machines in the subnet for service traffic can switch from using public IPv4 addresses to using private IPv4 addresses. 

Service Endpoint Services

Service endpoint would provide benefits in the following scenarios:
  • Peered, connected, or multiple virtual networks- To secure Azure services to multiple subnets within a virtual network or across multiple virtual networks, you can enable service endpoints on each of the subnets independently, and secure Azure service resources to all of the subnets.

  • Filtering outbound traffic from a virtual network to Azure services- This scenario might be helpful if you want to use network virtual appliance filtering to restrict Azure service access from your virtual network only to the specific Azure resources.

  • Securing Azure resources to services deployed directly into virtual networks- You can secure Azure service resources to managed service subnets by setting up a service endpoint on the managed service subnet.

  • Disk traffic from an Azure virtual machine- Virtual Machine Disk traffic for managed and unmanaged disks isn't affected by service endpoints routing changes for Azure Storage. You can limit REST access to page blobs to select networks through service endpoints and Azure Storage network rules.

Private Links

Azure Private Link works on an approval call flow model wherein the Private Link service consumer can request a connection to the service provider for consuming the service. There are two connection approval methods that a Private Link service consumer can choose from:

  • Automatic- If the service consumer has RBAC permissions on the service provider resource, then the consumer can choose the automatic approval method. In this case, when the request reaches the service provider resource, no action is required from the service provider and the connection is automatically approved.

  • Manual- If the service consumer doesn't have the RBAC permissions on the service provider resource, then the consumer can choose the manual approval method. In this case, the connection request appears on the service resources  as Pending and the service provider has to manually approve the request before the connections can be established.  

The service provider has options like- approved, reject, and remove- to choose from for all the Private Endpoint connections and Portal is the preferred method for managing Endpoint connections on Azure PaaS resources.



To read part 1 please click here
To read part 3 please click here



Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more