Microsoft Azure is Going Secure by Default. Are You Ready?

By Jason Bordujenko, Global Head of Solutions Architects

Developers aren't lazy – but sometimes cloud service defaults can be. Here’s what to look out for, and how Azure is changing the game.

Let’s face it: Developers can sometimes be labeled as “laissez faire” when it comes to security. But is that really fair?

In reality, it’s not about being lax or lazy; it’s about the default configurations of many cloud services setting the security bar too low on initial deployment. When racing against the clock, it’s tempting to rely on these defaults, which can inadvertently open doors for malicious actors.

But as network attack surfaces grow wider from global expansions, edge integrations, and AI/ML, using these defaults puts more and more at stake.

In this blog, we’ll tell you what to look out for when it comes to cloud service defaults, how major players like Microsoft Azure are stepping up their security, and how you can keep up.

The problem with default security configurations

In the realm of cybersecurity, default configurations often prioritize ease of getting started over security, inadvertently creating vulnerabilities that can persist if left unmodified. Here are some notable examples of such “bar set too low” security defaults:

1. Unnecessarily opened ports: Sure, you can hit the web interface for the service, but what about the database ports? Do they really need to be world readable/writable?

2. Excessively lax permissions: Default settings might grant broader access than necessary, violating the principle of least privilege.

3. Revision fatigue: Failing to apply the latest security patches leaves these systems susceptible to exploits.

4. Disabled security features: Certain security features might be turned off by default to enhance performance or user experience. Worse yet, the dreaded line: “that might need a different license”.

And last, but not least:

5. Default credentials, default permissions, or default configuration settings: What’s the first userID/password combination you think of? Is it admin/admin? Services also may often run with elevated privileges or have overly permissive configurations, increasing the risk of an environment being exploited.

Azure’s secure-by-default networking: Don’t get caught out

Recognizing these challenges, Microsoft Azure is making some major changes to move towards what they are terming a secure-by-default deployment model, particularly in its networking components.

With a currently advertised commencement date of September 30, 2025, this shift will bring a major change to Azure networking with Microsoft removing default outbound internet access for newly deployed virtual machines.

That’s big news for those deploying on cloud. And it doesn’t stop there, with the additional announcement that legacy multifactor authentication (MFA) and self-service password reset (SSPR) policies will also be deprecated on September 30. This means cloud engineers must migrate any legacy policies to a new converged authentication methods policy for Microsoft Entra ID. Thankfully, the deprecation for the IP addressing is slightly less onerous than the above.

Here’s the exact wording on the scope of the change:

“On September 30, 2025, Basic SKU public IPs will be retired. If you are currently using Basic SKU public IPs, make sure to upgrade to Standard SKU public IPs prior to the retirement date."

It’s not that scary, but there could certainly be implications for the scenario of “rolling over” any existing addressing under the Basic SKU, as well as the non-availability of the Basic SKU in favour of the Standard SKU going forward past that date.

In the following section of this blog, we’ll dive into the key logical drivers behind these substantial changes and what they might mean for you.

What makes a secure-by-default model?

Beyond the buzzwords, a secure-by-default model ensures that services and resources are provisioned with security configurations already in place, reducing the risk of misconfigurations.

Key aspects include:

• Default security posture: Services are secure upon provisioning, minimizing the chance of misconfigurations.
• Minimized attack surface: By disabling unnecessary features and enforcing strong authentication, network segmentation, and data protection, the potential entry points for attackers are reduced.
• Ground up compliance: Default security settings often align with regulatory standards like ISO 27001 and PCI-DSS, simplifying compliance efforts.

The building blocks for secure by default on Azure

1. Network Security Groups (NSGs): By default, NSGs are configured in a “deny all” manner with regards to inbound traffic, allowing only outbound communications unless address(es) are specifically added to an allow group. This minimizes exposure to potential threats in the out-of-box experience (OOBE).
   
2. Azure Firewall: This managed, cloud-based network service built to protect Azure Virtual Network (or VNet) resources allows for centralized creation, enforcement, and logging of application and network connectivity policies across subscriptions and virtual networks. Azure Firewall operates at OSI layers 3, 4 and 7 – that is the network, transport and application layers.
   
3. DDoS protection: Azure provides built-in Distributed Denial of Service (DDoS) protection to safeguard applications from overwhelming traffic flows, ensuring availability and resilience. There are three main types of attacks that the DDoS mitigation strategies defend against: Volumetric Attacks (e.g. UDP floods, amplification attacks), Protocol Attacks (e.g. SYN floors and reflection attacks) and Resource (or Application) Layer Attacks, which commonly compromise the upper layer protocols such as HTTP or SQL.

Diving deeper into default outbound access

In Azure, virtual machines (VMs) created in a virtual network without explicit outbound connectivity are assigned a default outbound public IP address. This IP address enables outbound internet connectivity, but can be subject to change and is not recommended for production workloads.

If you have existing VMs using default outbound access, they will continue to work after the scheduled change date and you will retain your Basic SKU IP addresses. However, it is strongly recommended to transition to an explicit method to avoid potential disruptions.

Let’s say you’re using a cloud-based security appliance that reaches out to the internet for threat intelligence feeds and other system updates. Unless you’re aware of the change and make an explicit connectivity configuration change, it’s likely your detection pipeline will stall and potentially leave your organization open to zero-day threats.

In order to ensure a smooth transition, Microsoft recommends using explicit outbound connectivity methods such as:

• Azure NAT Gateway
• Azure Load Balancer outbound rules
• Enhanced Azure Firewall support
• Directly attached Azure public IP addresses
• Zone-redundant and zonal front ends for both inbound and outbound traffic.

Here’s a table that details the major changes, and availability of features between Basic and Standard SKU:

The specific configuration of these Microsoft items is beyond the scope of this blog, but our Solutions team is more than happy to assist in advising the best path forward for your requirement.

The role of Megaport in enhancing network security

At Megaport, we understand the critical importance of secure network connectivity. Our Network as a Service (NaaS) platform offers private, scalable, and on-demand connectivity, enabling businesses to establish secure connections to Azure and other cloud providers in just a few clicks.

By leveraging Megaport services, organizations can further enhance their network security posture, ensuring that data traverses through secure, dedicated connections rather than the public internet.

Megaport NAT Gateway

If your business is running high-volume data migration/ingest pipelines, managing enterprise-scale cloud infrastructure, or otherwise dealing with large volumes (petabytes-per-month scale) of Network Address Translation (NAT) traffic, using Megaport NAT Gateway may well be worthy of your consideration. Consider the following potential benefits:

• Scalable cost savings: The larger your NAT requirements, the greater the potential savings to be made. For example, a business currently using a cloud managed NAT gateway processing 1 petabyte of data a month can potentially save over $78,000, or 76% of its NAT bill, each month – translating to nearly $1 million in annual savings.
• Reduce ingress and egress charges: Utilize Megaport’s cost-effective network backbone instead of paying hyperscaler rates.
• High availability and scalability: Our solution is built to handle enterprise-scale workloads while maintaining network resilience, with 930+ global locations and available bandwidth of up to 100G.
• Flexibility to grow with you: With our vendor-neutral, scalable network underlay, you’re never locked into a single provider’s pricing and your network can simply grow right alongside your business needs.

For the most accurate savings estimate for your business, reach out through our NAT Gateway product page to get a personalized cost analysis. We can guide you through pricing and integration, and once you’ve decided on the perfect resilient design, we can deploy it within minutes.