In Part 1 of our Enterprise Hybrid Cloud Architecture series, we established resilient BGP transport highways (ExpressRoute & IPsec), optimized MTU fragmentation, and fortified the external perimeter using Azure Front Door, WAF, and DDoS protection. We effectively secured the outside.

However, modern cybersecurity operates under the assumption of breach. The traditional "castle-and-moat" philosophy—where everything inside the network is implicitly trusted—is obsolete. In Part 2, we dive into the core of the hybrid cloud: bridging On-Premises Active Directory with Entra ID, enforcing the Principle of Least Privilege (PoLP) via Azure PIM, and constructing robust Hub-Spoke micro-segmentation to halt lateral movement.

1. Identity Bridging: On-Premises AD to Entra ID

In a hybrid ecosystem, identity is the ultimate control plane. Managing disparate identities across On-Premises servers and Azure workloads leads to shadow IT and catastrophic credential leaks. The enterprise standard is to maintain a single source of truth: extending On-Premises Active Directory Domain Services (AD DS) to the cloud using Microsoft Entra Connect.

Depending on compliance requirements, organizations utilize either Password Hash Synchronization (PHS) or Pass-Through Authentication (PTA). PTA ensures that all authentication requests for cloud applications are validated directly against the On-Premises Domain Controllers, guaranteeing that localized security policies (like active login hour restrictions) apply universally.

2. Zero Trust and Conditional Access

Once identity is bridged, we implement Zero Trust. Verifying a username and password is no longer enough. Conditional Access Policies act as the intelligent gateway for every authentication attempt. Before granting a token, the policy evaluates multiple signals:

  • User Risk & Location: Is this an "Impossible Travel" scenario (e.g., login from London and Tokyo within 30 minutes)?
  • Device Posture: Is the requesting endpoint enrolled in Microsoft Intune, and does it have the latest EDR agents running?
  • Application Sensitivity: Is the user accessing a standard HR portal, or the highly sensitive Core Banking database?

If risk is detected, the policy dynamically enforces Multi-Factor Authentication (MFA) or blocks access entirely.

3. Principle of Least Privilege: Azure PIM & JIT

One of the largest attack vectors in Azure is standing privileged access—administrators who retain "Global Admin" or "Owner" rights 24/7. If their account is compromised, the entire subscription is compromised.

To mitigate this, organizations deploy Azure AD Privileged Identity Management (PIM). Users are granted "Eligible" assignments rather than active ones. When an engineer needs to modify a firewall rule, they must request Just-In-Time (JIT) elevation. This request requires MFA, a documented ticketing reason (e.g., ServiceNow ID), and expires automatically after a set duration (e.g., 2 hours).

Azure PIM and Identity Vault
SECURITY EVENT / AZURE PIM ACTIVATION LOG
[2025-12-05 10:15:22] PIM Role Activation Requested
User: e.guven@kurumsal.local
Requested Role: Network Contributor (Subscription: Hub-Prod)
Duration: 2 Hours Ticket Ref: INC-99412
MFA Verification: Passed (Hardware Token)
Status: Role ACTIVATED. Access will automatically revoke at 12:15:22.

4. Hub-Spoke Topology & User Defined Routes (UDR)

With identity secured, we must segment the network. Flat VNet architectures allow an attacker who breaches a web server to easily pivot to a database server. The enterprise standard is the Hub-and-Spoke Topology.

The Hub VNet acts as the central transit and security clearinghouse, hosting the Azure VPN/ExpressRoute Gateways and the central Azure Firewall. Application workloads are isolated in their own Spoke VNets (e.g., Spoke-Web, Spoke-DB). These spokes peer only with the Hub, never directly with each other.

To enforce inspection, we deploy User Defined Routes (UDRs). If a server in Spoke-Web needs to communicate with a server in Spoke-DB, the UDR overrides default Azure routing, forcing the packet via the Azure Firewall's private IP address in the Hub. The Firewall then evaluates the traffic against strict Layer 4/Layer 7 rules.

Hub and Spoke Topology with Azure Firewall
AZURE CLI / ROUTING TABLE INSPECTION (UDR)
$ az network route-table route list --resource-group RG-Network-Hub \
  --route-table-name Spoke-Web-UDR --output table

Name              AddressPrefix    NextHopType       NextHopIpAddress
----------------  ---------------  ----------------  ------------------
To-Spoke-DB       10.200.2.0/24    VirtualAppliance  10.100.1.4 (Firewall)
To-OnPremises     10.10.0.0/16     VirtualAppliance  10.100.1.4 (Firewall)
Default-Internet  0.0.0.0/0        VirtualAppliance  10.100.1.4 (Firewall)

5. Micro-segmentation: Moving beyond IP Addresses (NSG & ASG)

Relying solely on IP subnets for security is archaic in cloud environments where IP addresses change dynamically. We achieve true micro-segmentation by combining Network Security Groups (NSGs) with Application Security Groups (ASGs).

An ASG is a logical tag applied to a Virtual Machine's network interface (NIC). Instead of writing a firewall rule that says "Allow 10.200.1.5 to 10.200.2.10 on Port 1433", we assign the VMs to ASGs and write an NSG rule stating: "Allow ASG-Web-Tier to ASG-DB-Tier on Port 1433."

This means even if two database servers exist in the exact same subnet, they cannot communicate with each other via SSH or RDP unless explicitly allowed by the NSG/ASG rule. Lateral movement is completely suffocated at the NIC level.

CONFIGURATION / NSG RULE USING ASG
Rule Name: Allow-Web-to-SQL
Priority: 100
Source: Application Security Group -> ASG-Web-Servers
Destination: Application Security Group -> ASG-DB-Servers
Destination Port: 1433 (MSSQL)
Action: Allow

What's Next?

We have now secured the transport layer and built a resilient, Zero Trust core where identity is verified continuously, administrative access is temporary, and workloads are logically isolated down to the network interface.

But architecture is not just about prevention; it is about resilience and visibility. In the final installment, Part 3: Resilience & Operations - Disaster Recovery, Posture & SIEM, we will explore Azure Site Recovery (ASR) for business continuity, optimizing your Microsoft Defender Secure Score, and correlating On-Premises and Azure logs within Microsoft Sentinel to hunt for advanced threats.