# AZ-104 Project 2: Secure Azure Networking with Azure Bastion (No Public IPs)

## Overview

This project focuses on designing and validating a **secure Azure network architecture** that allows administrators to manage virtual machines **without exposing them directly to the public internet**.

Instead of relying on public IP addresses, open RDP ports, or jumpbox VMs, administrative access is enforced through **Azure Bastion**, a Microsoft-managed access service.

The objective of this project was to demonstrate how modern Azure environments reduce attack surface by shifting from **network-based access** to **identity-based access**, a core responsibility of an Azure Administrator and a key concept tested in the AZ-104 exam.

## Problem Statement

Traditionally, virtual machines were managed by:

* Assigning public IP addresses
    
* Opening ports like RDP (3389) or SSH (22) to the internet
    
* Relying on firewall rules and passwords for protection
    

This model significantly increases attack surface and exposes management ports to:

* Internet scanning
    
* Brute-force attacks
    
* Exploitation of protocol vulnerabilities
    

**Organizations need a way to:**

* Manage virtual machines securely
    
* Eliminate public exposure
    
* Enforce identity-based access
    
* Maintain operational simplicity
    

## Architecture Overview

This project implements a **private Azure network** where virtual machines are never directly reachable from the internet.

Administrative access is provided exclusively through **Azure Bastion**, which requires authentication through Microsoft Entra ID before any network connectivity is established.

### High-level design

* Virtual machines have **no public IP addresses**
    
* No inbound internet access is allowed
    
* Azure Bastion serves as the **only management entry point**
    
* Access is authenticated and audited via Entra ID
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767233622266/87d0ffef-ce82-4d2f-a3ba-9f655ff909fc.jpeg align="center")

## Network Design

### Virtual Network

A custom virtual network was created with the following address space:

* **VNet address space:** `10.0.0.0/16`
    

| Subnet | Purpose |
| --- | --- |
| `app-subnet` | Hosts application / workload virtual machines |
| `management-subnet` | Reserved for future management resources (unused in this project) |
| `AzureBastionSubnet` | Dedicated subnet required for Azure Bastion |

Azure Bastion requires a **dedicated subnet named** `AzureBastionSubnet` with a minimum /26 address range, which was created using Azure’s Bastion subnet purpose to enforce Microsoft’s requirements.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767233492824/5afda96d-42cc-4770-ab82-ead002f6005a.png align="center")

## Azure Bastion Deployment

Azure Bastion was deployed as a **managed PaaS service** within the virtual network.

Key characteristics:

* Deployed into `AzureBastionSubnet`
    
* Uses HTTPS (443) via the Azure Portal
    
* Requires Microsoft Entra ID authentication
    
* Does not expose RDP or SSH ports publicly
    
* No NSGs or custom routing required
    

Bastion acts as a **secure access broker**, not a jumpbox VM. Administrators connect *through* Bastion rather than logging *into* it.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767233667915/2d0154b2-358c-459e-876d-0a8339d40d6e.png align="center")

## Virtual Machine Deployment

A Windows Server virtual machine was deployed with the following security controls:

* **No public IP address**
    
* Placed in `app-subnet`
    
* Default NSG behavior only (no inbound internet rules)
    
* RDP enabled internally for administrative access
    

Because the VM has no public IP and no inbound internet access, it is completely isolated from direct external connectivity.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767233702304/432ad2be-5974-42e9-b6cd-7ac5179f56d1.png align="center")

## Access & Security Model

### Identity-based access

To connect to the VM:

1. The administrator authenticates to **Microsoft Entra ID**
    
2. Access is authorized through Azure RBAC
    
3. The connection is initiated via **Azure Bastion**
    
4. Bastion establishes a private RDP session to the VM
    

At no point is the VM exposed to the internet.

This design ensures that:

* Identity is verified **before** network access exists
    
* Unauthorized users cannot probe or reach management ports
    
* All access is authenticated and logged
    

## Validation & Testing

### Secure access validation

* The VM was successfully accessed using **Azure Bastion**
    
* The RDP session was established entirely within the browser
    
* No public IP was assigned to the VM
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1767233717037/1cdcf94a-bec7-441b-b648-1383cffb1cbd.png align="left")

### Exposure validation

* VM networking configuration confirms **Public IP: None**
    
* No inbound rules allowing internet traffic exist
    
* Direct RDP from an external machine is not possible
    

This confirms that administrative access is **fully private and identity controlled**.

## Key Takeaways

* Public IP addresses are not required for VM management
    
* Azure Bastion reduces attack surface
    
* Identity-based access is more secure than network-based exposure
    
* Secure architectures can be simple and cost-effective
    
* Azure-native services can replace legacy jumpbox patterns
    

## Final Thoughts

This project demonstrates how Azure administrators can design secure-by-default environments by eliminating public exposure and enforcing identity-based access. By leveraging Azure Bastion, administrative connectivity is tightly controlled, audited, and aligned with modern Zero Trust principles.

This architecture mirrors real-world Azure environments where security, simplicity, and operational efficiency are prioritized.