Secure your subnet via private subnet and explicit outbound methods

by Contributed | Nov 16, 2023 | Technology

This article is contributed. See the original author and article here.

While there are multiple methods for obtaining explicit outbound connectivity to the internet from your virtual machines on Azure, there is also one method for implicit outbound connectivity – default outbound access.  When virtual machines (VMs) are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address.  These IP addresses may seem convenient, but they have a number of issues and therefore are only used as a “last resort”:

• These implicit IPs are subject to change which can result in issues later on if any dependency is taken on them.


• Their dynamic nature also makes them challenging to use for logs or filtering with network security groups (NSGs).


• Because these IPs are not associated with your subscription, they are very difficult to troubleshoot.


• This type of open egress does not adhere to Microsoft’s “secure-by-default” model which ensures customers have a strong security policy without having to take additional steps.

Because of these factors, we recently announced the retirement of this type of implicit connectivity, which will be removed for all VMs in subnets created after September 2025. 

Private subnet

At Ignite, a new feature—private subnet—was released in preview.  This feature will let you prevent this type of insecure implicit connectivity for all subnets with the “default outbound access” parameter set to false.  Any virtual machines created on this subnet will be prevented from connecting to the Internet without an explicit outbound method specified.  To enable this feature, simply ensure the option is selected when a new subnet is created as shown below.

View of Azure portal with Private subnet selection

Note that currently:

• A subnet must be created as private; this parameter cannot be changed following creation.


• Certain services will not function on a virtual machine in a private subnet without an explicit method of egress (examples are Windows Activation and Windows Updates).


• Both CLI and ARM templates can also be used; PowerShell is in development.

Azure’s recommended explicit outbound connectivity methods

The good news is that there are much better, more scalable, and secure methods for having your VMs access the Internet.  The three recommended options—in order of preference—are a NAT gateway, using outbound rules with a public load balancer, or placing a public IP directly on the VM network interface card (NIC).

Diagram of multiple explicit outbound methods

Azure NAT Gateway

NAT Gateway is the best option for connecting outbound to the internet as it is specifically designed to provide highly secure and scalable outbound connectivity. NAT Gateway enables all instances within private subnets of Azure virtual networks to remain fully private and source network address translate (SNAT) to a static public IP address. No connections sourced directly from the internet are permitted through a NAT gateway. NAT Gateway also provides on-demand SNAT port allocation to all virtual machines in its associated subnets. Since ports are not in fixed amounts to each VM, this means you don’t need to worry about knowing the exact traffic patterns of each VM. To learn more, take a look at our documentation on SNATing with NAT Gateway or our blog that explores a specific outbound connectivity failure scenario where NAT Gateway came to the rescue.

Azure Load Balancer with outbound rules

Another method for explicit outbound connectivity is using public Azure load balancers with outbound rules. To provide outbound connectivity with Azure Load Balancer, you assign a dedicated public IP address or addresses as the frontend IP of the outbound rule. Private instances in the backend pool of the Load balancer then use the frontend IP of the outbound rule to connect outbound in a secure manner, similar to NAT Gateway. However, unlike NAT Gateway, SNAT ports are not allocated dynamically with outbound rules. Rather, using a load balancer requires manual allocation of SNAT ports in fixed amounts to each instance of your backend pool prior to deployment. This manual SNAT port allocation gives you full declarative control over outbound connectivity since you decide the exact amount of ports each VM is allowed. However, this manual allocation creates more overhead management in ensuring that you have assigned the correct amount of SNAT ports needed by your backend instances for connecting outbound. While you can scale your Load balancer by adding more frontend IPs to your outbound rule, this scaling requires you to then re-allocate assigned SNAT ports per backend instance to ensure that you are utilizing the full inventory of SNAT ports available.

Public IP address assignment to virtual machine NICs

Another option for providing explicit outbound connectivity from an Azure virtual network is the assignment of a public IP address directly to the NIC of a virtual machine. Customers that want to have control over which public IP address their VMs use for connecting to specific destination endpoints may benefit from assigning public IPs directly to the VM NIC. However, customers with more complex and dynamic workloads that need a many to one SNATing relationship that scales with their traffic volume should look to NAT Gateway or Load Balancer.

To learn more about each of these explicit outbound connectivity methods, see our public documentation on using source network address translation for outbound connections.

What outbound method am I currently using?

As mentioned earlier, default outbound access is enabled only when no other explicit outbound connectivity method exists.  Note that there is an order of priority among the explicit methods, shown in the flowchart below.  In other words, if your VM has multiple forms of outbound connectivity defined, then the higher order one will be used (e.g. NAT Gateway takes precedence above a public IP address attached to the VM NIC).

To check the form of outbound your deployments are using, you can refer to the flowchart below which lists them in the order of precedence.

Flowchart showing priority order for diffrent outbound methods

To read more about default outbound access and private subnets, please refer to Default outbound access in Azure – Azure Virtual Network | Microsoft Learn.

To learn more about how to deploy a NAT Gateway, please use Quickstart: Create a NAT Gateway – Azure portal | Microsoft Learn.

Are You Alive: Enhancing Azure AI Vision Face API with Liveness Detection

by Contributed | Nov 15, 2023 | Technology

This article is contributed. See the original author and article here.

By Quentin Miller 

We are excited to announce the public preview of Liveness Detection, an addition to the existing Azure AI Face API service. Facial recognition technology has been a longstanding method for verifying a user’s identity in device and online account login for its convenience and efficiency. However, the system encounters escalating challenges as malicious actors persist in their attempts to manipulate and deceive the system through various spoofing techniques. This issue is expected to intensify with the emergence of generative AIs such as DALL-E and ChatGPT. Many online services e.g., LinkedIn and Microsoft Entra, now support “Verified Identities” that attest to there being a real human behind the identity. 

Face Liveness Detection 

Liveness detection aims to verify that the system engages with a physically present, living individual during the verification process. This is achieved by differentiating between a real (live) and fake (spoof) representation which may include photographs, videos, masks, or other means to mimic a real person. 

Face Liveness Detection has been an integrated part of Windows Hello Face for nearly a decade. “Every day, people around the world get access to their device in a convenient, personal and secure way using Windows Hello face recognition”, said Katharine Holdsworth, Principal Group Program Manager, Windows Security. The new Face API liveness detection is a combination of mobile SDK and Azure AI service. It is conformant to ISO/IEC 30107-3 PAD (Presentation Attack Detection) standards as validated by iBeta level 1 and level 2 conformance testing. It successfully defends against a plethora of spoof types ranging from paper printouts, 2D/3D masks, and spoof presentations on phones and laptops. Liveness detection is an active area of research, with continuous improvements being made to counteract increasingly sophisticated spoofing attacks over time, and continuous improvement will be rolled out to the client and the service components as the overall solution gets hardened against new types of attacks over time. 

A simple illustration of the user experience from the SDK sample is shown below, where the screen background goes from white to black before the final liveness detection result is shown on the last page. 

The following video demonstrates how the product works under different spoof conditions.  

While blocking spoof attacks is the primary focus of the liveness solution, paramount importance is also given to allowing real users to successfully pass the liveness check with low friction. Additionally, the liveness solution complies with the comprehensive responsible AI and data privacy standards to ensure fair usage across demographics around the world through extensive fairness testing. 

For more information, please visit: Empowering responsible AI practices | Microsoft AI. 

Implementation 

The overall liveness solution integration involves 2 different components: a mobile application and an app server/orchestrator. 

Prepare mobile application to perform liveness detection 

The newly released Azure AI Vision Face SDK for mobile (iOS and Android) allows for ease-of-integration of the liveness solution on front-end applications. To get started you would need to apply for the Face API Limited Access Features to get access to the SDK. For more information, see the Face Limited Access page. 

Once you have access to the SDK, follow the instructions and samples included in the github-azure-ai-vision-sdk to integrate the UI and the code needed into your native mobile application. The SDK supports both Java/Kotlin for Android and Swift for iOS mobile applications. 

Upon integration into your application, the SDK will handle starting the camera, guide the end-user to adjust their position, compose the liveness payload and then call the Face API to process the liveness payload. 

Orchestrating the liveness solution 

The high-level steps involved in the orchestration are illustrated below:  

For more details, refer to the tutorial. 

Face Liveness Detection with Face Verification 

Integrating face verification with liveness detection enables biometric verification of a specific person of interest while ensuring an additional layer of assurance that the individual is physically present. 

For more details, refer to the tutorial.  

Deepening Well-Architected guidance for workloads hosted on Azure

by Contributed | Nov 14, 2023 | Technology

This article is contributed. See the original author and article here.

I am excited to announce a comprehensive refresh of the Well-Architected Framework for designing and running optimized workloads on Azure. Customers will not only get great, consistent guidance for making architectural trade-offs for their workloads, but they’ll also have much more precise instructions on how to implement this guidance within the context of their organization.

Background

Cloud services have become an essential part of the success of most companies today. The scale and flexibility of the cloud offer organizations the ability to optimize and innovate in ways not previously possible. As organizations continue to expand cloud services as part of their IT strategies, it is important to establish standards that create a culture of excellence that enables teams to fully realize the benefits of the modern technologies available in the cloud.

At Microsoft, we put huge importance on helping customers be successful and publish guidance that teaches every step of the journey and how to establish those standards. For Azure, that collection of adoption and architecture guidance is referred to as Azure Patterns and Practices.

The Patterns and Practices guidance has three main elements:

• organization-wide adoption guidance in the Cloud Adoption Framework (CAF)


• workload-focussed design and continuous improvement guidance in the Well-architected Framework (WAF)


• architecture patterns and reference architectures in the Azure Architecture Center (AAC)

Each element focuses on different parts of the overall adoption of Azure and speaks to specific audiences, such as WAF and workload teams.

What is a workload?

The term workload in the context of the Well-Architected Framework refers to a collection of application resources, data, and supporting infrastructure that function together towards a defined business goal.

Well-architected is a state that is achieved and maintained through design and continuous improvement. You optimize through a design process that results in an architecture that delivers what the business needs while minimizing risk and expense.

For us, the workload standard of excellence is defined in the Well-architected Framework – a set of principles, considerations, and trade-offs that cover the core elements of workload architecture. As with all of the Well-architected Framework content, this guidance is based on proven experience from Microsoft’s customer-facing technical experts. The Well-architected Framework continues to receive updates from working with customers, partners, and our technical teams. 

Today we have published updates across each of the core pillars of WAF which represent a huge amount of experience and learning from across Microsoft.

The refreshed and expanded Well-Architected Framework brings together guidance to help workload teams design, build, and optimize great workloads in the cloud. It is intended to shape discussions and decisions within workload teams and help create standards that should be applied continuously to all workloads.

Details of the refreshed Well-Architected Framework

Over the past six months, Microsoft’s cloud solution architects refreshed the Well-Architected Framework by compiling the learnings and experience of over 10,000 engagements that had leveraged the WAF and its assessment.

All five pillars of the Well-Architected Framework now follow a common structure that consists exclusively of design principles, design review checklists, trade-offs, recommendation guides, and cloud design patterns.

Design principles. Presents goal-oriented principles that build a foundation for the workload. Each principle includes a set of recommended approaches and the benefits of taking those approaches. The principles for each pillar have changed in terms of content and coverage.

• Reliability design principles


• Security design principles


• Cost Optimization design principles


• Operational Excellence design principles


• Performance Efficiency design principles

Design review checklists. Lists roughly codified recommendations that drive action. Use the checklists during the design phase of your new workload and to evaluate brownfield workloads.

• Design review checklist for Reliability


• Design review checklist for Security


• Design review checklist for Cost Optimization


• Design review checklist for Operational Excellence


• Design review checklist for Performance Efficiency

Trade-offs. Describes tradeoffs with other pillars. Many design decisions force a tradeoff. It’s vital to understand how achieving the goals of one pillar might make achieving the goals of another pillar more challenging.

• Reliability tradeoffs


• Security tradeoffs


• Cost Optimization tradeoffs


• Operational Excellence tradeoffs


• Performance Efficiency tradeoffs

Recommendation guides. Every design review checklist recommendation is associated with one or more guides. They explain the key strategies to fulfill that recommendation. They also include how Azure can facilitate workload design to help achieve that recommendation. Some of these guides are new, and others are refreshed versions of guides that cover a similar concept.

The recommendation guides include trade-offs along with risks.

• This icon indicates a trade-off: 


• This icon indicates a risk: 
  

   

  
  

Cloud design patterns. Build your design on proven, common architecture patterns. The Azure Architecture Center maintains the Cloud Design Patterns catalog. Each pillar includes descriptions of the cloud design patterns that are relevant to the goals of the pillar and how they support the pillar.

The Well-Architected Review assessment has also been refreshed. Specifically, the “Core Well-Architected Review” option now aligns to the new content structure in the Well-Architected Framework. Every question in every pillar maps to the design review checklist for that pillar. All choices for the questions correlate to the recommendation guides for the related checklist item.

Using the guidance

The Well-architected Framework is intended to help workload teams throughout the process of designing and running workloads in the cloud.

Here are three key ways in which the guidance can help your team be successful:

1. Use the Well-architected Framework as the basis for your organization’s approach to designing and improving cloud workloads.


2. Establish the concept of achieving and maintaining a state of well-architected as a best practice for all workload teams


3. Regularly review each workload to find opportunities to optimize further – use learnings from operations and new technology capabilities to refine elements such as running costs, or attributes aligned to performance, reliability, or security

To learn more, see the new hub page for the Well-Architected Framework: aka.ms/waf

Dom Allen has also created a great, 6-minute video on the Azure Enablement Series. 

Service Delivery Manager Profile: Meiko Lopez

by Contributed | Nov 13, 2023 | Technology

This article is contributed. See the original author and article here.

v:* {behavior:url(#default#VML);}
o:* {behavior:url(#default#VML);}
w:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}

Meiko Lopez
Normal
Joe Cicero
2
277
2023-11-09T21:37:00Z
2023-11-09T21:37:00Z
3
719
4101
34
9
4811
16.00

0x010100A389A42144AF8541BAAFF21480674075

Clean
Clean

false

false
false
false

EN-US
JA
AR-SA

 

Service Delivery Manager Profile: Meiko Lopez

Defender Experts for XDR

 

“Be steadfast in the truth – providing comfort and assurance to the customers that you will help them to a resolution.”

-Meiko Lopez, Sr. Product Manager