Azure Networking: Request for Granular Control of “Allow Azure Services and Resources”
I would like to get the Azure community’s thoughts on a networking/security improvement that I believe could help organizations implement a stronger least-privilege model. Several Azure resources provide an option similar to: “Allow Azure services and resources to access this resource.” This is useful when an Azure service needs to access another Azure resource, but the current option can be quite broad. Example: Power BI → Azure SQL For example, suppose Power BI Service needs to access an Azure SQL Server. The actual requirement might be: Power BI → Specific Azure SQL Server = Allow However, the available option may require enabling: “Allow Azure services and resources to access this server” This effectively creates a much broader trusted-service exception than the actual requirement. Ideally, I would like to see something like: Azure SQL Server │ ├── Power BI Service → Allow ├── Azure Data Factory → Deny ├── Azure Functions → Deny ├── Azure App Service → Deny └── Other Azure Services → Deny Proposed improvement Could Microsoft provide an additional option such as: “Allow selected Azure services and resources” where customers can explicitly select which Azure service/resource is allowed to bypass the network restriction? Depending on the Azure service, the selection could potentially be based on: Specific Azure service Specific Azure resource Resource ID Subscription Resource group Tenant Managed identity / Entra identity Specific service instance For example: Trusted Azure Services / Resources Power BI → Production Analytics → Allow All other Azure services → Deny Why I think this would be useful This would give customers a middle ground between: Disabling public access and implementing Private Endpoint/private connectivity, or Allowing all Azure services/resources through the broad trusted-service exception. A granular trusted-service model would allow: Only the Azure service/resource that actually requires access is trusted. This would better support least privilege, Zero Trust, security, and compliance requirements. Broader Azure applicability My suggestion is not specifically for Azure SQL. The Power BI → Azure SQL scenario is just an example. I think this could be a common Azure networking capability for all Azure resources that currently support a trusted Azure services / “Allow Azure services and resources” type of bypass. I would be interested to hear from the Azure community and Microsoft: Is there already a way to achieve this level of granularity? Are there architectural/security reasons why this cannot currently be implemented? Is Microsoft considering a more granular trusted-service model? Would a feature like “Allow selected Azure services/resources” be technically feasible? I would appreciate any feedback or guidance from the Azure networking/service teams.🔥The Power of Azure’s Security Arsenal 🔥
◆ Using a Public IP without securing your Azure applications and resources exposes you to security threats. Today, we’ll explore the most powerful security solutions from Azure’s arsenal. ◆ Azure provides a multi-layered approach (more than one layer of protection) to secure your resources when using a Public IP. Organizations can now transform this open gateway into a fortified checkpoint. Here’s how these tools work together to mitigate risks: 🚀 Azure DDoS Protection 🚀 ■ Protects your resources and services from being overwhelmed by malicious traffic. This excellent service is available for Network & IP Protection SKUs. ■ Uses Machine Learning to distinguish between normal traffic patterns and malicious flooding attempts (such as SYN floods or UDP amplification attacks) before they impact your applications and services ensuring availability. 🚀 Azure Web Application Firewall (WAF) 🚀 ■ Adds application-layer protection, intercepting HTTP/HTTPS traffic for inspection. ■ Blocks suspicious attacks like SQL injection or XSS by applying OWASP core rule sets, which define how attacks occur and how to defend against them, with continuous updates. ■ Enhances security for customer-facing services, ensuring trust and protection for your website and users. 🚀 Network Security Groups (NSGs) 🚀 ■ Acts as a virtual firewall at the subnet or network interface level, filtering traffic based on predefined rules. ■ Can allow only trusted HTTPS (port 443) connections while blocking unsolicited RDP or SSH attempts. ■ Implements the critical security principle of reducing attack surface, ensuring only authorized traffic reaches your target resources. 🚀 Azure Private Link 🚀 ■ In some scenarios, avoiding Public IPs altogether is the best security approach. This powerful service allows secure access to Azure SQL Database or Storage via Private Endpoints inside your virtual network. ■ Helps organizations minimize external exposure while maintaining secure, private connections to necessary services. 🚀 Azure Bastion 🚀 ■ Provides secure access to Azure VMs without Public IPs, using RDP/SSH over encrypted TLS 1.2 traffic. ■ Uses a browser-based HTML5 web client to establish RDP/SSH sessions over TLS on port 443, fully compatible with any firewall. ■ Connects to VMs via Private IPs while enforcing NSG rules to allow access only through Azure Bastion. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! 🚀
Advanced Container Apps Networking: VNet Integration and Centralized Firewall Traffic Logging
Azure community, I recently documented a networking scenario relevant to Azure Container Apps environments where you need to control and inspect application traffic using a third-party network virtual appliance. The article walks through a practical deployment pattern: • Integrate your Azure Container Apps environment with a Virtual Network. • Configure user-defined routes (UDRs) so that traffic from your container workloads is directed toward a firewall appliance before reaching external networks or backend services. • Verify actual traffic paths using firewall logs to confirm that routing policies are effective. This pattern is helpful for organizations that must enforce advanced filtering, logging, or compliance checks on container egress/ingress traffic, going beyond what native Azure networking controls provide. It also complements Azure Firewall and NSG controls by introducing a dedicated next-generation firewall within your VNet. If you’re working with network control, security perimeters, or hybrid network architectures involving containerized workloads on Azure, you might find it useful. Read the full article on my blog
Network Monitoring
Hi, I recently applied Network Security Groups on Virtual Networks (NSG). Now my question is, is it possible to monitor / record the network traffic? For example, I've configured many rules on the NSG, now a application on a Server won't work and my first guess is the NSG is blocking the communication. How do I see now which port the application is using so I can set a new rule to the NSG? I know when you already know the port you can check it in Network Watcher "IP flow verify and NSG diagnostics" as a whatif state. Traffic Analytics isn't the right answer too or am I seeing it wrong? Vnet Flow Logs should be the right thing. I configured it, applied traffic analytics and a account storage. Applied it for testing on a nic but I don't see anything practical for my use? The only thing Iwish is to see live or logged the traffic if the NSG blocked anything and troubleshoot.Storage Accounts - Networking
Hi All, Seems like a basic issue, however, I cannot seem to resolve the issue. In a nutshell, a number of storage accounts (and other resources) were created with the Public Network Access set as below: I would like to change them all to them all to Enabled from selected virtual networks and IP addresses or even Disabled. However, when I change to Enabled from selected virtual networks and IP addresses, connectivity from, for example, Power Bi to the Storage Account fails. I have added the VPN IP's my local IP etc. But all continue to fail connection or authentication. Once it is changed back to Enabled for All networks everything works, i.e. Power Bi can access the Azure Blob Storage and refresh successfully. I have also enabled 'Allow Azure services on the trusted services list to access this storage account'. But PBI fails to have access to the data. data Source Credentials error, whether using Key, Service Principal etc, it fails. As soon as I switch it back to Enable From All Networks, it authenticates straight away. One more idea I had was to add ALL of the Resource Instances, as this would white list more Azure services, although PBI should be covered by enabling 'Allow Azure services on the trusted services list to access this storage account'. I thought I might give it a try. Also, I created an NSG and used the ServiceTags file to create an inbound rule to allow Power BI from UK South. Also, I have created a Private Endpoint. This should all have worked but still can’t set it to restricted networks. I must be missing something fundamental or there is something fundamentally off with this tenant. When any of the two restrictive options are selected, do they also block various Microsoft services? Any help would be gratefully appreciated.
Scaling Smart with Azure: Architecture That Works
Hi Tech Community! I’m Zainab, currently based in Abu Dhabi and serving as Vice President of Finance & HR at Hoddz Trends LLC a global tech solutions company headquartered in Arkansas, USA. While I lead on strategy, people, and financials, I also roll up my sleeves when it comes to tech innovation. In this discussion, I want to explore the real-world challenges of scaling systems with Microsoft Azure. From choosing the right architecture to optimizing performance and cost, I’ll be sharing insights drawn from experience and I’d love to hear yours too. Whether you're building from scratch, migrating legacy systems, or refining deployments, let’s talk about what actually works.Azure NSG Challenge : When NIC and Subnet Rules Collide
Imagine this real-world scenario: 🔹 A VM needs to connect outbound via RDP (TCP 3389) to an external server for management. 🔹 The NIC-level NSG allows outbound RDP, ensuring the VM can initiate connections. 🔹 However, the Subnet-level NSG has an inbound deny rule specifically for RDP. 💭 Question for IT Pros: 👉 Would the outbound RDP session succeed or be blocked due to the subnet-level NSG? 👉 How do you design NSG rules to prevent misconfigurations while maintaining security? ####################################################### Great challenge! Let's break it down: 🚦 Would the outbound RDP session succeed or be blocked? The outbound RDP session would succeed because the subnet-level NSG applies to inbound traffic coming into the subnet, not traffic leaving the VM. Since outbound RDP is explicitly allowed at the NIC level, the VM can initiate connections without issue. However, if the external server tries to respond back, the inbound deny rule at the subnet level would block the return traffic. This effectively disrupts the session, making it seem like the connection failed. 🔒 How to design NSG rules effectively? To prevent misconfigurations while maintaining security: 1- Understand NSG processing – Rules are evaluated independently at the NIC and Subnet levels, but both must allow the required traffic. 2- Use least privilege principles – Only allow necessary traffic and explicitly deny everything else. 3- Be careful with inbound rules at the subnet level – Blocking inbound traffic here can unintentionally interfere with legitimate outbound sessions. 4- Log traffic flows with NSG Flow Logs – Use diagnostic settings to capture insights for troubleshooting. 5- Consider Application Security Groups (ASGs) – These simplify NSG management by grouping resources dynamically.Azure VM Networking Components Real Case Scenario
📌 Public IP 📌 🔹 Public IPs allow internet-based services to reach Azure resources, such as web applications hosted on VMs or Azure App Services. 🔹 Azure resources can use Public IPs to communicate with external services, ensuring connectivity for APIs, databases, and other cloud-based applications. 🔹 Public IPs can be assigned as static (fixed address) or dynamic (changes over time). Static IPs are ideal for services requiring a consistent address, while dynamic IPs are useful for temporary workloads. 📌 Azure Load Balancer (External / Internal) 📌 🔹 Distributes Internet Traffic – Balances incoming requests from the internet across multiple backend resources. 🔹 Balances Private Network Traffic – Distributes requests within an Azure Virtual Network (VNet). 🔹 Supports Multi-Tier Architectures – Ideal for backend services like databases and application layers. 🔹 Enhances Availability – Ensures high availability by routing traffic to healthy instances. 🔹 Provides Outbound Connectivity – Enables Azure VMs to communicate with external services using NAT. 📌 VNET Subnets Segmentation 📌 🔹 Web Subnet – Contains two VMs, each with a Network Interface Card (NIC) and is protected by a Network Security Group (NSG) to filter traffic based on rules. 🔹 App Subnet – Similar to the Web Subnet, hosting two VMs with NICs and NSGs, but uses an internal load balancer to balance traffic within the subnet. 🔹 Data Subnet – Also includes two VMs with NICs and NSGs, leveraging an internal load balancer for optimized traffic management. 🔹 Gateway Subnet – Hosts the VPN Gateway, ensuring connectivity between on-premises networks and Azure. 📌 Azure Network Security Groups (NSGs)📌 🔹 Traffic Filtering – NSGs allow or deny inbound and outbound traffic based on defined security rules. 🔹 Granular Control – Rules can be applied at the subnet or network interface level for precise traffic management. 🔹 Default Security Rules – Azure provides built-in rules to ensure basic security, which can be overridden with custom rules. 🔹 Priority-Based Processing – Rules are evaluated in order of priority (100-4096), with lower numbers processed first. 🔹 Supports Service Tags – Simplifies rule management by using predefined tags like Internet, VirtualNetwork, and AzureLoadBalancer. 📌 Azure VPN Gateway 📌 🔹 Secure Connectivity – Establishes encrypted connections between Azure Virtual Networks (VNets) and on-premises networks. 🔹 Site-to-Site VPN – Enables secure communication between an on-premises network and Azure using IPsec/IKE VPN tunnels. 🔹 Point-to-Site VPN – Allows individual devices to securely connect to Azure from remote locations using OpenVPN, IKEv2, or SSTP. 🔹 VNet-to-VNet Connectivity – Facilitates secure communication between multiple Azure VNets. 🔹 ExpressRoute Failover – Provides a backup connection for ExpressRoute in case of failure. 🔹 High Availability – Supports active-active configurations for redundancy and reliability. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! 🚀🔥 Hybrid Networking 101: Linking On-Prem to Azure 🔥
Many organizations seek to extend their networks to include subnets and virtual machines (VMs) hosted on Azure. The goal is to enable seamless connectivity between on-premises computers in a data center and Azure-based virtual machines. 🔹 Common Use Cases for Hybrid Networking: # Application Connectivity: You have an Azure-hosted application that needs access to your on-premises database servers. # Branch Office Integration: Your business operates retail stores worldwide and requires a single centralized service to connect all locations. # Remote Access: You need secure remote access to your Azure VMs and applications. # Data Synchronization: You want to connect on-premises servers with Azure servers for real-time synchronization and data transfer. # To address these scenarios, Azure provides four key networking solutions: ✅ Point-to-Site VPN (P2S) ✅ Site-to-Site VPN (S2S) ✅ ExpressRoute ✅ Azure Virtual WAN One essential component that supports all these solutions is Azure VPN Gateway. Let's explore its capabilities! 🔍 🚀 Azure VPN Gateway 🚀 # Secure Connectivity Between Azure & On-Premises by encrypting data while transferring it between Azure VNets and on-premises servers over the internet. # Multiple connections can be established using a single VPN Gateway, sharing available bandwidth across all VPN tunnels. # The gateway consists of Azure-managed VMs, automatically deployed and configured in a GatewaySubnet with a CIDR size of /27. # There are two types of gateways: 🔹 VPN Gateway (for encrypted connections) 🔹 ExpressRoute Gateway (for dedicated high-speed connectivity) 💡 Gateway SKUs define performance characteristics, including: # Supported tunnel types (S2S, P2S, VNet-to-VNet) # Maximum aggregate throughput # BGP (Border Gateway Protocol) support # Scalability options (resize within the same generation and family via Azure Portal or PowerShell) 🚀 VPN Gateway Types: # Route-Based VPN: Supports S2S & P2S connections—widely used in hybrid networking. # Policy-Based VPN: Limited to Basic SKUs and allows only S2S connections (not ideal for Remote Access). 🔹 Local Network Gateway: Represents your on-premises router or firewall, enabling Azure to recognize your internal network's public IP and subnets for connectivity via IPSec IKEv1/2. 🔹 Azure Availability Zones can be leveraged for high availability and service continuity. 📌 Point-to-Site VPN (P2S) 📌 🔹 Secure access for individual users connecting remotely to Azure VNets. 🔹 Supported protocols: OpenVPN® (SSL/TLS-based; compatible with Windows, Mac, Linux, Android, iOS) SSTP (TLS-based; Windows-only) IKEv2 (IPsec VPN solution; Mac-supported) 🔹 Authentication Methods: (1) Certificate Authentication (requires client certificates issued from a trusted root certificate). (2) Azure AD Authentication (available for OpenVPN clients). (3) Active Directory Domain Server Authentication (via RADIUS server integration). 📌 Site-to-Site VPN (S2S) 📌 🔹 Enables on-premises data centers to connect with Azure VNets via IPSec IKEv1/2. 🔹 Supports VNet-to-VNet connections over Microsoft's backbone network. 🔹 Compatible with hardware devices from vendors such as Cisco, Fortinet, Barracuda, Check Point. 🔹 Supports software VPN devices, including Microsoft RRAS and Linux Openswan. 🔹 Enables dynamic routing via BGP to propagate network changes automatically. 📌 ExpressRoute 📌 🔹 Dedicated high-speed connectivity to Microsoft Cloud (Azure, Microsoft 365). 🔹 Up to 100 Gbps speeds with low latency, ideal for business-critical applications. 🔹 Layer 3 connectivity, using BGP for seamless route exchange between on-premises and Azure networks. 📌 Azure Virtual WAN 📌 🔹 A scalable networking service integrating VPN, ExpressRoute, and SD-WAN solutions. 🔹 Provides branch connectivity using site-to-site VPN or private ExpressRoute connections. 🔹 Supports remote user VPN (P2S) for secure external access. 🔹 Follows hub-and-spoke architecture, ensuring full mesh connectivity across Azure regions. If you found this valuable, consider sharing so more professionals can benefit. Let's keep the conversation growing! 🚀
Error code 11408: The operation has timed out. Id. de actividad
Hello, I am starting with Azure Synapse, and when I want to ingest data with a copy, when I configure the connection to the data source (In this case, it is HTTP with a URL), I get this error, and I don't know why. I have configured the storage account with the IPs that have permissions, and I have also configured the IPs that have access in my Synapse resource. Additionally, I have enabled the managed virtual network with Data exfiltration protection enabled. I believe this should be related to that, but I don't know what extra configuration I need to do to allow this type of connections and others. I haven't found information regarding this error code, I would greatly appreciate any help.
