We manage big environments inside Azure with multiple customers, we are redesigning it and in it we wanted to manage traffic within multiple common subnets like app, web and db subnets.
So essentially no two different application inside any common subnet like db cannot communicate with each other.
By default, resources in the different subnets from the same VNet could communicate with each other. So you need to use an Azure network security group to filter network traffic to and from Azure resources in an Azure virtual network or subnet.
Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. To learn more, see Application security groups.
For PaaS like Azure app service or Azure SQL database, you could use VNet Integration to access VNet resources in a private network or use virtual network service endpoints and rules for servers in Azure SQL Database.
For more information, you may know:
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/secure-vnet-dmz
https://learn.microsoft.com/en-us/azure/networking/networking-overview
Related
Right now we have multiple resources like storage accounts and key vaults where the team is using the firewall setting within the networking tab on the individual services. This means when their ip changes after a disconnect/connect to the company VPN they have to go in to each service and add their new IP address.
Not being well versed in Azure networking possibilities, what are some of the options we have to allow a group of incoming IP addresses to be able to access all these services without having to individually touch each service to add their new ip address?
All services are also on the same virtual network.
Thank You
I used to work on Azure Cloud services as a DevOps in the past.
There should be multiple ways to control incoming network traffic to your landing zone or azure resources. But you should consider your requirements meet the solution.
Here are few you could take a look at which I used:
Virtual network service endpoints
Azure Firewall
Network Security Groups
ExpressRoute
I was told recently that the Hub VNET is only used in case there is on-premise networking to/from considerations.
I am quite surprised as were many, at the table.
I was under the impression if I have, say, a AZURE Cloud only env. that I could still have a Hub Spoke approach. Or is this not so? What would be the preferred non-Hub Spoke approach if there is peering or inter-VNET access required?
I am aware of VNET Peering and other methods to access resources in other VNETs, API's and Private Link.
The hub-spoke approach works great in some scenarios in cloud-only environments - although in most of docs or architectural patterns Microsoft shows it together with on-prem connectivity.
I used it frequently when we shared some resources like ACR, Log Analytics or simply to host a jump host (with Bastion) to access resources in other networks.
One of the most common scenarios is also the Azure Monitor Private Link Scope, where the hub-spoke topology is recommended:
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-design#hub-and-spoke-networks
In an Azure Cloud only environment, you can still have a Hub-Spoke approach and this is the recommended one.
While you can cross-peer different spokes to form a Mesh for spokes to exchange data (in a non-Hub scenario), this will become complicated as the number of spokes increases. You will have to configure 1:n Peering in every VNet.
With Hub-Spoke model, you have to route spoke-spoke traffic via Hub Vnet, but the advantage here is that the Hub Vnet becomes the single point entry for the environment and you can deploy resources here that would be shared and used by all other VNets (such as custom DNS server, Firewall)
If I am setting up an Azure SQL Database in a vnet which Azure App Service and Azure Function will access. Is using both Subnet Delegation and Service Endpoints the right way to go? I didn't fully understand the documentation.
Regarding subnet delegation, I read this Microsoft article and this stackoverflow post, which stated:
When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner.
That sounds like a good thing but makes me wonder how it worked efficiently w/o subnet delegation.
As for Service Endpoints, I read this Microsoft article, which states:
Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Service Endpoints enables private IP addresses in the VNet to reach the endpoint of an Azure service without needing a public IP address on the VNet.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
They both sound like they have the same benefits and I'm struggling to understand the difference. I suppose the larger question is should I enable both for the simple architecture outlined above.
In the Microsoft service endpoints documentation they also mention:
Microsoft recommends use of Azure Private Link for secure and private access to services hosted on Azure platform. For more information, see Azure Private Link.
For some reason that seems like an Azure to on-premise thing.
• You cannot use a ‘Subnet Delegation’ along with a ‘Private endpoint’ since that subnet is delegated for the said service, in your case, the Azure SQL Database. Through a subnet delegation, you can define the NSG association for it, as well as associate multiple delegated subnets to a common NSG. You can also define the IP Address space for the delegated subnet, the route table association with it, the custom DNS entry configuration in Azure DNS as well as define the minimum number of IP Addresses available for that delegated subnet. Similarly, with regards to service endpoint, these stated functions are not available.
• In service endpoint, you do not have control over the routing mechanism as well as the IP address related allotment, reservation, or configuration. Also, managing DNS entries for the resources managed through them and controlling them through a firewall or NAT gateway isn’t required unlike a subnet delegation because all these things are managed by Microsoft Azure’s backbone network on your behalf.
Thus, both have their own features and specifications for enabling you to configure according to your own requirements.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
Yes, you will have to create a firewall rule to allow the access from on-premises system to Azure SQL Server/Database and configure the service endpoint accordingly to allow the VPN client IP Addresses for accessing the same over public internet.
Also, through Azure private link, you won’t be able to connect from on-premises to Azure as it uses a private IP address and a private DNS zone entry related to it to connect to Azure resources in the same virtual network.
To know more regarding the configuration of Azure service access from on-premises network, kindly refer to the below given link: -
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview#secure-azure-service-access-from-on-premises
Also, refer to the below snapshots regarding the configuration and selection of service endpoint for a particular subnet: -
I am setting up a VPC on AWS. It has a public subnet and two private subnets. The public subnet is for web servers. The private subnets are for high availability databases. I am securing the resources using Security Groups, not Network ACL's.
The default security group which was created when I created the VPC allows all outbound traffic, and only allows inbound traffic from other subnets in the VPC. I'm not sure exactly what kind of servers I'll be deploying in the future - more web servers, more RDS instance, something else? In light of this, I think my default security group should allow no traffic inbound or outbound. Does that make sense?
In this way, if I forget to explicitly choose the security group when I launch an instance, the server is isolated from all other resources.
Given your design, a recommended security configuration is:
Put your load balancer in the public subnet: It is public-facing
Put your web servers in a private subnet: This keeps them secure by removing direct access from the Internet
This way, if you launch a future instance in the private subnet, it is more secure than launching in a public subnet. Security groups are then an extra layer of security.
Given that you are aiming for High Availability, also spread your web servers across multiple Availability Zones. An easy way to do this is to use Auto Scaling, which distributes instances evenly across Availability Zones and has the benefit of scaling in/out to meet demand while minimizing costs.
For an example architecture, see the Web Application Hosting reference architecture in the AWS Architecture Center.
what is the AWS security groups equivalent in azure
if there is any in azure is this only for the PaaS services or also for IaaS ?
According to Amazon EC2 Documentation, a security group is just a single point for firewall settings applied to a given instance:
A security group acts as a firewall that controls the traffic allowed
to reach one or more instances. When you launch an instance, you
assign it one or more security groups. You add rules to each security
group that control traffic for the instance.
In Windows Azure you have to set these rules on a per-instance or per-service basis, there is no way to define some rules and apply them automatically to all instances.
But you can use PowerShell cmdlets for automating this task for your services.
Firewall rules apply mostly for PaaS: for your web/worker role services and for SQL Azure. In case of IaaS there are two sides: your VM with custom software firewall (depending upon your OS etc.) and the endpoints you create and manage in Azure Portal that relay in- and outbound traffic to your VM.
Azure Network security groups and other related improvements were announced today:
http://weblogs.asp.net/scottgu/azure-new-marketplace-network-improvements-new-batch-service-automation-service-more
Network Security group in Azure is the option you are looking for. But there is no option to create it directly. But can be created while creating Virtual Machines and can be associated with multiple Virtual Machines. For more detail,
http://tehcbase.com/aws-security-group-equivalent-in-microsoft-azure/