メインコンテンツまでスキップ

Azure Virtual Network (VNet)

1. Giới thiệu

VNet là gì?

Virtual Network (VNet) là mạng riêng trên Cloud. Nó cung cấp một môi trường được cô lập (isolated) và an toàn cho các tài nguyên Azure của bạn (như máy ảo, Azure SQL Database, v.v.) để giao tiếp với nhau, với Internet và với các mạng On-premises (mạng vật lý của công ty) nếu cần.

  • Các máy ảo (VM) và dịch vụ trong VNet có thể giao tiếp với nhau an toàn.
  • VNet bị cô lập hoàn toàn với các VNet khác (trừ khi bạn kết nối chúng).
  • Mỗi VNet phải nằm trong một Vùng (Region) cụ thể.

2. Các thành phần cốt lõi

Address Space (Không gian địa chỉ)

Dải IP là không gian địa chỉ mà VNet của bạn sẽ sử dụng.

Lưu ý về các Dải IP Riêng Tư (Private IP Ranges) theo chuẩn IANA (10.x.x.x, 172.16.x.x - 172.31.x.x, 192.168.x.x) vì đây là những dải bạn nên dùng trong VNet.

  • Ví dụ: 10.0.0.0/16 (Cung cấp 65,536 địa chỉ IP).

Subnets (Mạng con)

Subnet là việc chia nhỏ Dải IP của VNet thành các phân đoạn nhỏ hơn. Mọi tài nguyên Azure đều được đặt vào một Subnet cụ thể bên trong VNet. Có thể chia Subnet theo lớp ứng dụng (Application Tier) hoặc dịch vụ (Service):

  • Frontend Subnet (10.0.1.0/24): Cho Web Server.
  • Backend Subnet (10.0.2.0/24): Cho Database.
  • Service Subnet: Một số dịch vụ Azure yêu cầu một Subnet chỉ dành riêng cho chúng, không được chứa các tài nguyên khác. Ví dụ: Gateway Subnet, Azure Firewall Subnet,...

Quy tắc IP bị giữ lại: Giải thích rằng Azure giữ lại 5 địa chỉ IP đầu tiên trong mỗi Subnet (cho các mục đích nội bộ như Router, DNS, v.v.).

Public IP Address

Public IP là địa chỉ IP công khai cho phép tài nguyên Azure giao tiếp với Internet.

Đặc điểm:

  • Static: IP không đổi, phù hợp cho production (web server, VPN Gateway).
  • Dynamic: IP có thể thay đổi khi VM stop/start, rẻ hơn Static.
  • SKU: Basic (legacy) và Standard (production, zone-redundant).

Khi nào cần Public IP:

  • Web server cần truy cập từ Internet.
  • VPN Gateway, Application Gateway, Load Balancer.
  • VM cần download packages từ Internet (hoặc dùng NAT Gateway).

Ví dụ:

Private IP Address

Private IP là địa chỉ IP nội bộ trong VNet, không truy cập được từ Internet.

Phân loại:

  • Dynamic: Azure tự động gán IP từ dải Subnet (mặc định).
  • Static: Gán IP cố định, dùng cho Database, Domain Controller, DNS Server.

Best Practice:

  • Dùng Static IP cho các dịch vụ quan trọng (DB, DNS).
  • Dùng Dynamic IP cho VM worker, application server.

Network Interface Card (NIC)

NIC là cầu nối logic cho phép một tài nguyên Azure (như Máy ảo - Virtual Machine) kết nối với một Subnet.

  • Điểm quan trọng:

    • Mỗi máy ảo có ít nhất một NIC.
    • NIC là nơi Địa chỉ IP Riêng tư (Private IP) được gán (từ dải IP của Subnet).
    • NIC là nơi các quy tắc bảo mật NSG (Network Security Group) được áp dụng.

Service Endpoints

Service Endpoint cho phép tài nguyên trong VNet truy cập trực tiếp vào các dịch vụ PaaS của Azure (như Azure Storage, Azure SQL Database, Azure Key Vault) qua mạng backbone riêng của Azure, thay vì đi qua Internet công cộng.

Lợi ích:

  • Bảo mật cao hơn: Lưu lượng không ra Internet công cộng, giảm nguy cơ bị tấn công.
  • Hiệu suất tốt hơn: Sử dụng mạng backbone Azure, độ trễ thấp hơn.
  • Đơn giản: Chỉ cần bật Service Endpoint trên Subnet, không cần cấu hình phức tạp.

Cách hoạt động:

  1. Bật Service Endpoint trên Subnet (ví dụ: Microsoft.Storage, Microsoft.Sql).
  2. Cấu hình firewall của dịch vụ PaaS để chỉ chấp nhận kết nối từ VNet/Subnet cụ thể.
  3. Tài nguyên trong Subnet đó có thể truy cập dịch vụ PaaS qua IP công khai của dịch vụ, nhưng lưu lượng đi qua mạng riêng Azure.

Hạn chế:

  • Dịch vụ PaaS vẫn giữ nguyên địa chỉ IP công khai.
  • Không thể dùng địa chỉ IP riêng tư để truy cập.
  • Mọi tài nguyên trong Subnet đều có thể truy cập dịch vụ (không kiểm soát được từng tài nguyên cụ thể).

Ví dụ sử dụng:

Private Endpoints

Private Endpoint gắn một địa chỉ IP riêng tư (từ VNet của bạn) cho dịch vụ PaaS. Điều này cho phép bạn truy cập dịch vụ PaaS như thể nó nằm ngay trong VNet của bạn.

Lợi ích:

  • Bảo mật tối đa: Dịch vụ PaaS có IP riêng tư, có thể tắt hoàn toàn truy cập từ Internet công cộng.
  • Kiểm soát chi tiết: Có thể áp dụng NSG, UDR (User Defined Routes) để kiểm soát từng kết nối cụ thể.
  • Tích hợp với DNS: Tự động tạo Private DNS Zone, cho phép sử dụng tên miền thay vì IP.
  • Hỗ trợ kết nối On-premise: Có thể truy cập dịch vụ PaaS từ mạng On-premise qua VPN/ExpressRoute.

Cách hoạt động:

  1. Tạo Private Endpoint trong một Subnet cụ thể.
  2. Azure gán một IP riêng tư từ dải IP của Subnet cho dịch vụ PaaS.
  3. Tài nguyên trong VNet (hoặc mạng kết nối với VNet) truy cập dịch vụ qua IP riêng này.

So sánh với Service Endpoint:

Tiêu chíService EndpointPrivate Endpoint
IP của dịch vụ PaaSCông khaiRiêng tư (trong VNet)
Truy cập từ InternetCó thể (nếu cấu hình)Không (trừ khi cho phép)
Kiểm soát chi tiếtCấp SubnetCấp tài nguyên
Hỗ trợ On-premiseKhôngCó (qua VPN/ExpressRoute)
Chi phíMiễn phíCó phí (theo giờ + dữ liệu)

Ví dụ minh họa:

Khi nào dùng Service Endpoint vs Private Endpoint?

  • Service Endpoint: Phù hợp khi bạn cần kết nối đơn giản, nhanh chóng, chi phí thấp, và không yêu cầu truy cập từ On-premise.
  • Private Endpoint: Phù hợp khi bạn cần bảo mật cao nhất, muốn tắt hoàn toàn truy cập Internet, hoặc cần truy cập từ mạng On-premise.

3. Bảo mật mạng (Security)

Network Security Group (NSG)

NSG là Tường lửa (Firewall) ở cấp độ Layer 4 (Network Layer) cơ bản và quan trọng nhất trong Azure VNet.

Cách hoạt động của NSG

NSG chứa một danh sách các Security Rules (quy tắc bảo mật) được đánh giá theo thứ tự Priority (từ thấp đến cao, 100-4096). Khi một packet đến, Azure sẽ:

  1. Kiểm tra từng rule theo thứ tự priority
  2. Khi tìm thấy rule phù hợp, thực hiện action (Allow/Deny) và dừng lại
  3. Nếu không có rule nào match, áp dụng Default Rules

Các thành phần của một Security Rule:

Thành phầnMô tảVí dụ
NameTên ruleAllow-HTTPS-Inbound
PriorityThứ tự xử lý (100-4096, càng thấp càng ưu tiên)100
SourceNguồn trafficIP address, CIDR, Service Tag, ASG
Source PortPort nguồn* (any), 443, 80-90
DestinationĐích đếnIP address, CIDR, Service Tag, ASG
Destination PortPort đích443, 3306, 22, 3389
ProtocolGiao thứcTCP, UDP, ICMP, Any
ActionHành độngAllow, Deny
DirectionChiều trafficInbound, Outbound

Nơi áp dụng NSG

Subnet Level (Khuyến nghị):

  • Bảo vệ tất cả tài nguyên trong Subnet
  • Dễ quản lý, áp dụng policy nhất quán
  • Một Subnet chỉ có thể có một NSG

NIC Level (Network Interface Card):

  • Bảo vệ VM cụ thể
  • Cho phép kiểm soát chi tiết hơn
  • Một NIC chỉ có thể có một NSG

Flow xử lý khi có cả NSG Subnet và NSG NIC:

Default Rules (Quy tắc mặc định)

Mỗi NSG có các Default Rules (không thể xóa, nhưng có thể override bằng custom rules có priority thấp hơn):

Inbound Default Rules:

PriorityNameSourceDestinationPortAction
65000AllowVnetInBoundVirtualNetworkVirtualNetworkAnyAllow
65001AllowAzureLoadBalancerInBoundAzureLoadBalancerAnyAnyAllow
65500DenyAllInBoundAnyAnyAnyDeny

Outbound Default Rules:

PriorityNameSourceDestinationPortAction
65000AllowVnetOutBoundVirtualNetworkVirtualNetworkAnyAllow
65001AllowInternetOutBoundAnyInternetAnyAllow
65500DenyAllOutBoundAnyAnyAnyDeny

NSG Best Practices

  1. Least Privilege Principle: Chỉ mở port cần thiết
  2. Explicit Deny: Tạo rule Deny ở priority cao để chặn traffic nguy hiểm
  3. Document Rules: Đặt tên rule rõ ràng, dễ hiểu
  4. Use Service Tags: Thay vì hardcode IP, dùng Service Tags
  5. Enable NSG Flow Logs: Để audit và troubleshoot

Application Security Group (ASG)

ASG là cách logic grouping các VMs thành các nhóm application, giúp đơn giản hóa việc quản lý NSG mà không cần quan tâm đến IP addresses.

Vấn đề ASG giải quyết

Vấn đề trước khi có ASG:

# NSG Rule cũ: Phải liệt kê từng IP
Source: 10.0.1.4, 10.0.1.5, 10.0.1.6 (3 Web VMs)
Destination: 10.0.2.7, 10.0.2.8 (2 DB VMs)
Port: 3306
Action: Allow

# Khi thêm Web VM mới có IP 10.0.1.9
→ Phải update NSG rule thủ công (dễ sai sót)

Với ASG:

# NSG Rule mới: Dùng tên nhóm
Source: WebServers_ASG
Destination: DatabaseServers_ASG
Port: 3306
Action: Allow

# Khi thêm Web VM mới
→ Chỉ cần gắn NIC của VM vào WebServers_ASG
→ NSG rule tự động áp dụng!

Cách hoạt động của ASG

Lợi ích của ASG

  1. Dễ quản lý: Không cần nhớ IP addresses
  2. Scale dễ dàng: Thêm VM mới chỉ cần gắn vào ASG
  3. Giảm số lượng rules: Một rule cho nhiều VMs
  4. Self-documenting: Tên ASG mô tả rõ mục đích
  5. Giảm sai sót: Không phải update rule khi IP thay đổi

Azure Bastion

Azure Bastion là dịch vụ managed jump box giúp bạn truy cập SSH/RDP vào VMs một cách an toàn không cần Public IP cho VMs.

Vấn đề Bastion giải quyết

Với Azure Bastion:

✅ VM chỉ cần Private IP

✅ Port 22/3389 không cần mở ra Internet

✅ Truy cập qua Azure Portal (HTTPS:443)

✅ Tích hợp Azure AD, MFA

✅ Audit logs đầy đủ

Cách hoạt động

Bastion Best Practices

  1. Dùng Standard SKU: Có thêm features như IP-based connection, Kerberos
  2. Enable diagnostic logs: Audit ai truy cập VM nào
  3. Combine với JIT Access: Thêm layer security
  4. Subnet sizing: /27 là nhỏ nhất, nên dùng /26 để mở rộng

Chú ý: Chi phí của Bastion Azure


Azure DDoS Protection

Azure DDoS Protection bảo vệ ứng dụng khỏi tấn công DDoS (Distributed Denial of Service).

Các loại DDoS Protection

1. DDoS Basic (Miễn phí)

  • Tự động bật cho tất cả Azure resources
  • Bảo vệ cơ bản ở network layer (Layer 3/4)
  • Không có tuning hay reporting

2. DDoS Standard (Tính phí)

  • Advanced DDoS mitigation
  • Tuning theo từng application
  • Real-time attack metrics
  • Post-attack analysis reports
  • Cost protection (Azure credit cho scale-out trong attack)

Khi nào cần DDoS Standard?

✅ Public-facing web applications

✅ Gaming servers

✅ API endpoints với high traffic

✅ Compliance requirements (PCI-DSS, ISO)

Chi phí: ~$2,944/tháng cho 100 Public IPs đầu tiên


4. Kết nối (Connectivity)

VNet Peering (Nối mạng)

VNet Peering cho phép kết nối hai VNet với nhau để các tài nguyên trong hai VNet có thể giao tiếp trực tiếp như thể chúng nằm trong cùng một mạng.

Đặc điểm:

  • Kết nối trực tiếp: Lưu lượng đi qua mạng backbone Azure, không qua Internet.
  • Băng thông cao: Không giới hạn băng thông giữa các VNet được peering.
  • Độ trễ thấp: Gần như bằng giao tiếp nội bộ trong cùng một VNet.
  • Không transitive: Nếu VNet A peering với VNet B, và VNet B peering với VNet C, thì VNet A KHÔNG tự động kết nối được với VNet C.

Các loại Peering:

  • Local Peering (Regional VNet Peering):

    • Kết nối 2 VNet trong cùng một Region (ví dụ: cả hai ở Southeast Asia).
    • Chi phí rất thấp (chỉ tính phí ingress/egress data transfer).
    • Sử dụng: Khi bạn muốn tách biệt môi trường (Dev, Test, Prod) nhưng vẫn cần kết nối.
  • Global Peering (Global VNet Peering):

    • Kết nối 2 VNet ở khác Region (ví dụ: Singapore nối với US East).
    • Chi phí cao hơn Local Peering.
    • Sử dụng: Kiến trúc multi-region, disaster recovery, hoặc phân tán ứng dụng theo địa lý.

Ví dụ kiến trúc:

Lưu ý quan trọng:

  • Các dải IP của các VNet peering KHÔNG được trùng nhau.
  • Cần cấu hình peering ở cả hai phía (bidirectional).
  • Có thể kiểm soát lưu lượng bằng NSG và UDR.

VPN Gateway

VPN Gateway cho phép kết nối an toàn từ mạng On-premise (văn phòng, nhà riêng) lên Azure VNet qua kết nối Internet được mã hóa (IPsec/IKE tunnel).

Các loại kết nối VPN:

1. Site-to-Site VPN (S2S)

Kết nối toàn bộ mạng On-premise với Azure VNet.

Đặc điểm:

  • Kết nối cố định giữa router/firewall văn phòng với Azure.
  • Tất cả người dùng trong văn phòng đều có thể truy cập tài nguyên Azure.
  • Cần thiết bị VPN On-premise (router hỗ trợ IPsec).
  • Băng thông: 100 Mbps - 10 Gbps tùy SKU của Gateway.

Khi nào dùng:

  • Kết nối văn phòng công ty với Azure.
  • Hybrid Cloud: Một phần hạ tầng ở On-premise, một phần trên Azure.
  • Migration: Di chuyển dần dần workload lên Cloud.

Sơ đồ kiến trúc:

2. Point-to-Site VPN (P2S)

Kết nối từ một máy tính cá nhân đến Azure VNet.

Đặc điểm:

  • Mỗi người dùng cài VPN client trên laptop/máy tính của mình.
  • Kết nối từ bất kỳ đâu (nhà, quán cà phê, khi đi công tác).
  • Không cần thiết bị VPN chuyên dụng.
  • Hỗ trợ nhiều protocol: IKEv2, OpenVPN, SSTP.

Khi nào dùng:

  • Developer làm việc từ xa cần truy cập tài nguyên Azure.
  • Nhân viên IT cần troubleshoot hệ thống.
  • Số lượng người dùng ít (vài chục người).

Ví dụ:

3. VNet-to-VNet VPN

Kết nối hai VNet với nhau qua VPN Gateway (thay vì dùng VNet Peering).

Khi nào dùng:

  • Khi hai VNet thuộc hai subscription khác nhau.
  • Khi cần mã hóa lưu lượng giữa các VNet (Peering không mã hóa).
  • Kết nối cross-tenant (hai tổ chức khác nhau).

VPN Gateway SKUs:

SKUBăng thôngTunnels S2STunnels P2SUse Case
Basic100 Mbps10128Dev/Test, không production
VpnGw1650 Mbps30250Small production workloads
VpnGw21 Gbps30500Medium workloads
VpnGw31.25 Gbps301000Large workloads
VpnGw4-55-10 Gbps100+5000+Enterprise scale

ExpressRoute

ExpressRoute là kết nối riêng tư chuyên dụng (private dedicated connection) từ mạng On-premise lên Azure, không đi qua Internet công cộng.

Đặc điểm:

  • Tốc độ cao: 50 Mbps đến 100 Gbps.
  • Độ trễ thấp và ổn định: Không bị ảnh hưởng bởi Internet công cộng.
  • Bảo mật cao: Lưu lượng không đi qua Internet.
  • Độ tin cậy cao: SLA 99.95% uptime.
  • Truy cập nhiều dịch vụ: Không chỉ VNet mà còn có thể truy cập Microsoft 365, Dynamics 365.

Cách hoạt động:

Các loại ExpressRoute:

  1. ExpressRoute Direct: Kết nối trực tiếp 100 Gbps vào Microsoft network (cho enterprise lớn).
  2. ExpressRoute Partner: Thuê kết nối qua nhà cung cấp (Viettel, VNPT, FPT, Verizon, AT&T, v.v.).
  3. ExpressRoute Local: Chỉ truy cập Azure trong một region cụ thể (rẻ hơn).

So sánh VPN Gateway vs ExpressRoute:

Tiêu chíVPN Gateway (S2S)ExpressRoute
Kết nối quaInternet (encrypted)Private connection
Băng thôngTối đa 10 GbpsTối đa 100 Gbps
Độ trễKhông ổn định (phụ thuộc Internet)Thấp và ổn định
Bảo mậtIPsec encryptionPrivate, không cần encryption
Chi phíThấp (vài trăm USD/tháng)Cao (vài ngàn - chục ngàn USD/tháng)
Thời gian setupNhanh (vài giờ)Lâu (vài tuần - vài tháng)
SLA99.9%99.95%
Use caseSMB, Dev/Test, Budget limitedEnterprise, Mission-critical, High bandwidth

Khi nào dùng ExpressRoute:

  • Công ty lớn, yêu cầu băng thông cao (>1 Gbps).
  • Ứng dụng mission-critical, không được phép downtime.
  • Yêu cầu độ trễ thấp và ổn định (trading, real-time analytics).
  • Compliance yêu cầu dữ liệu không được đi qua Internet công cộng.
  • Di chuyển lượng dữ liệu lớn lên Azure (migration hàng TB).

5. Routing (Định tuyến)

Azure Routing - Cơ bản

Azure tự động định tuyến traffic giữa các Subnets, VNets và Internet. Tuy nhiên, bạn có thể tùy chỉnh routing bằng Route Tables (Bảng định tuyến).

System Routes (Routes mặc định)

Azure tự động tạo System Routes cho mỗi Subnet để định tuyến traffic:

Các System Routes cơ bản:

Đích đến (Destination)Next HopGiải thích
VNet address spaceVNetTraffic trong cùng VNet
Peered VNetVNet peeringTraffic đến VNet đã peering
InternetInternetTraffic ra ngoài Internet
On-premise (via VPN)VPN GatewayTraffic đến mạng On-premise
On-premise (via ER)ExpressRouteTraffic qua ExpressRoute

Sơ đồ VD System Routes:

Destination (Đích đến)Address PrefixNext Hop TypeNext HopMô tả
VM2 trong VNet10.0.2.0/24VNetLocal VNet routingTraffic đến Subnet B trong cùng VNet
Internet0.0.0.0/0InternetAzure default gatewayTraffic ra ngoài Internet
On-Premise192.168.0.0/16VirtualNetworkGatewayVPN GatewayTraffic đến mạng On-premise qua VPN
Peered VNet10.1.0.0/16VNetPeeringPeering connectionTraffic đến VNet đã peering (nếu có)

User-Defined Routes (UDR)

User-defined routes (custom routes) cho phép bạn override Azure's default system routing để kiểm soát traffic flow.

Khi nào cần UDR?

Force tunneling: Bắt buộc tất cả Internet traffic đi qua on-premises (hoặc firewall) trước khi ra Internet

Network Virtual Appliance (NVA): Định tuyến traffic qua firewall, IDS/IPS, hoặc load balancer

Subnet isolation: Kiểm soát traffic giữa các subnets

Multi-tier architecture: Buộc traffic từ web tier phải đi qua app tier trước khi đến database

Next Hop Types

Khi tạo custom route, bạn chỉ định next hop type:

Next Hop TypeMô tảUse Case
Virtual applianceIP address của NVA (firewall, router)Route traffic qua firewall/NVA
Virtual network gatewayVPN hoặc ExpressRoute gatewayRoute traffic đến on-premises
Virtual networkVNet local routingOverride default VNet routing
InternetAzure Internet gatewayForce traffic ra Internet
NoneDrop trafficChặn traffic đến destination cụ thể

Ví dụ UDR thực tế

Kịch bản 1: Force all Internet traffic qua Azure Firewall

Requirement: Tất cả traffic từ Web Subnet ra Internet phải đi qua Azure Firewall

Route Table configuration:

Route NameAddress PrefixNext Hop TypeNext Hop IPPriority
Internet-via-Firewall0.0.0.0/0Virtual appliance10.0.0.4100

Sơ đồ:

Kịch bản 2: Subnet isolation với NVA

Requirement: Traffic từ Web Subnet đến DB Subnet phải đi qua Firewall

Route Table cho Web Subnet:

Route NameAddress PrefixNext Hop TypeNext Hop IP
To-DB-via-FW10.0.3.0/24Virtual appliance10.0.0.4

Route Table cho DB Subnet:

Route NameAddress PrefixNext Hop TypeNext Hop IP
From-Web-via-FW10.0.1.0/24Virtual appliance10.0.0.4

Sơ đồ:

Route Tables (Bảng định tuyến tùy chỉnh)

Route Table là bảng định tuyến do bạn tạo ra để kiểm soát cách traffic được định tuyến từ Subnet của bạn.

Khi nào cần Route Table:

✅ Buộc tất cả traffic Internet đi qua Firewall để kiểm tra

✅ Định tuyến traffic giữa Subnets qua một thiết bị bảo mật (Firewall/NVA)

✅ Chặn hoàn toàn traffic ra Internet từ một Subnet

✅ Định tuyến traffic theo một đường đi cụ thể thay vì mặc định

Các thành phần của một Route:

Thành phầnMô tảVí dụ
NameTên routeRoute-To-Firewall
Address PrefixDải IP đích0.0.0.0/0 (Internet), 10.0.2.0/24 (Subnet)
Next Hop TypeLoại điểm đến kế tiếpVirtual Appliance, VNet Gateway, Internet, None
Next Hop IPIP của điểm đến10.0.0.4 (Firewall IP)

Next Hop Types:

  • Virtual Appliance: Firewall/NVA (phải cung cấp IP)
  • VNet Gateway: VPN Gateway hoặc ExpressRoute Gateway
  • Internet: Ra Internet trực tiếp
  • VNet: Trong cùng VNet (tự động)
  • None: Chặn traffic (drop packet)

Ví dụ thực tế: Route Table cơ bản

Kịch bản: Bạn muốn tất cả traffic Internet từ Subnet Web đi qua Azure Firewall để kiểm tra.

Route Table:

Route NameDestinationNext Hop TypeNext Hop IPMục đích
Default-To-Internet0.0.0.0/0Virtual Appliance10.0.0.4Traffic Internet qua Firewall
To-DB-Subnet10.0.2.0/24Virtual Appliance10.0.0.4Traffic đến DB qua Firewall

Sơ đồ:

Route Priorities (Thứ tự ưu tiên)

Khi có nhiều routes, Azure sẽ chọn route theo thứ tự:

  1. User-defined routes (Route Table của bạn) - Ưu tiên cao nhất
  2. BGP routes (từ VPN/ExpressRoute)
  3. System routes (Routes mặc định của Azure)

Ví dụ:

User Route:     0.0.0.0/0 → Firewall (10.0.0.4)     ← Được chọn
System Route: 0.0.0.0/0 → Internet ← Bị override

Azure Firewall

Azure Firewall là managed firewall as a service, bảo vệ VNet ở mức cao hơn NSG.

Tính năng:

  • Application Rules: Kiểm soát theo FQDN (ví dụ: chỉ cho phép truy cập *.microsoft.com).
  • Network Rules: Kiểm soát theo IP, Port, Protocol (giống NSG nhưng mạnh hơn).
  • Threat Intelligence: Tự động block traffic đến/từ các IP độc hại.
  • NAT Rules: DNAT để forward traffic từ Public IP vào VM.
  • Central Logging: Tất cả log gửi về Log Analytics.

So sánh NSG vs Azure Firewall:

Tính năngNSGAzure Firewall
LayerLayer 4 (IP, Port)Layer 4 & Layer 7 (FQDN, URL)
GiáMiễn phí~$1.25/hour + data
Quản lýPer Subnet/NICCentralized
Threat IntelKhông
LoggingNSG Flow LogsLog Analytics, SIEM
Use caseBasic filteringEnterprise security

NAT Gateway

NAT Gateway cho phép các VM trong private subnet (không có Public IP) truy cập Internet để download packages, cập nhật hệ thống.

Lợi ích:

  • Tất cả VM trong Subnet dùng chung một hoặc nhiều Public IP.
  • Không cần gán Public IP cho từng VM (bảo mật hơn).
  • Hỗ trợ 64,000+ concurrent connections per IP.
  • Static outbound IP (dễ whitelist ở phía đối tác).

Khi nào dùng:

  • VM cần tải packages từ Internet (apt, yum, npm).
  • Backend services cần call API bên ngoài.
  • Không muốn expose VM ra Internet nhưng vẫn cần outbound.

7. Monitoring & Troubleshooting

Network Watcher

Network Watcher là bộ công cụ để giám sát, chẩn đoán và troubleshoot mạng Azure.

Các công cụ chính:

1. IP Flow Verify

Kiểm tra xem một packet cụ thể có bị NSG chặn hay không.

Use case: VM không kết nối được, kiểm tra NSG rule nào đang block.

2. Connection Troubleshoot

Kiểm tra kết nối từ VM đến một endpoint (IP, FQDN, Port).

Use case: VM không kết nối được đến Database, kiểm tra routing và NSG.

3. NSG Flow Logs

Ghi lại tất cả traffic đi qua NSG (source, destination, port, action).

Use case:

  • Security audit: Ai đang truy cập vào hệ thống?
  • Troubleshooting: Tại sao kết nối bị chặn?
  • Compliance: Lưu lại log để audit.

4. Packet Capture

Bắt gói tin network giống Wireshark.

Use case: Phân tích chi tiết traffic để troubleshoot vấn đề phức tạp.

5. Connection Monitor

Giám sát liên tục kết nối giữa các resources, cảnh báo khi có vấn đề.

Use case: Giám sát kết nối giữa On-premise và Azure, giữa các region.

-> Tích hợp với NSG Flow Logs, Azure Firewall Logs để:

  • Phân tích traffic patterns.
  • Tạo dashboard giám sát real-time.
  • Cảnh báo khi phát hiện anomaly.

8. Best Practices

8.1. Quy hoạch IP (IP Planning)

Vấn đề phổ biến: Dùng dải IP trùng với mạng On-premise hoặc giữa các VNet → Không thể kết nối sau này.

Best Practices:

  1. Sử dụng dải IP lớn: Đừng dùng /24 cho VNet, hãy dùng /16 để dễ mở rộng sau này.

    • Tốt: 10.0.0.0/16 (65,536 IPs)
    • Tránh: 10.0.1.0/24 (256 IPs, khó mở rộng)
  2. Tránh dải IP phổ biến: Nhiều công ty dùng 192.168.0.0/16, dễ trùng khi peering/VPN.

    • Nên dùng: 10.x.x.x với x là số độc đáo cho từng VNet.
  3. Lập bảng quy hoạch IP trước:

    On-Premise:      192.168.0.0/16
    Hub VNet: 10.0.0.0/16
    Production VNet: 10.1.0.0/16
    Development VNet: 10.2.0.0/16
    DR Site VNet: 10.3.0.0/16
  4. Giữ lại dải IP dự phòng cho các dịch vụ Azure (Gateway Subnet, Firewall Subnet):

    • 10.0.0.0/27: Gateway Subnet
    • 10.0.0.64/26: Azure Firewall Subnet
    • 10.0.0.128/25: Dự phòng cho dịch vụ khác

8.2. Subnet Segmentation (Phân chia Subnet)

Nguyên tắc: Luôn chia Subnet theo chức năng và security boundary.

Best Practices:

  1. Tách biệt theo tier:

    • Frontend Subnet (10.0.1.0/24): Web servers, Load Balancer
    • Application Subnet (10.0.2.0/24): API servers, App logic
    • Database Subnet (10.0.3.0/24): Databases, data stores
    • Management Subnet (10.0.4.0/24): Jump boxes, monitoring tools
  2. Tạo Subnet chuyên dụng cho dịch vụ Azure:

    • GatewaySubnet: VPN/ExpressRoute Gateway (bắt buộc tên này)
    • AzureFirewallSubnet: Azure Firewall (bắt buộc tên này)
    • Private Endpoint Subnet: Tập trung Private Endpoints
  3. Áp dụng NSG khác nhau cho mỗi Subnet theo Zero Trust principle.

8.3. Security Best Practices

NSG (Network Security Group)

  1. Principle of Least Privilege: Chỉ mở port thực sự cần thiết.

    • ❌ Tránh: Allow *:* (tất cả port)
    • ✅ Tốt: Allow chỉ port 443 (HTTPS) và 22/3389 (SSH/RDP) từ IP cụ thể
  2. Deny by Default: Rule cuối cùng nên là Deny All, chỉ allow các rule cần thiết ở trên.

  3. Source Control: Không allow từ 0.0.0.0/0 (Internet) trừ khi thực sự cần.

    • Dùng Service Tags: AzureLoadBalancer, VirtualNetwork
    • Dùng ASG để quản lý dễ dàng hơn
  4. Enable NSG Flow Logs để audit và troubleshoot.

Private Endpoints vs Public Access

Tắt Public Access cho các dịch vụ PaaS trong production:

- Azure Storage: Disable public blob access
- Azure SQL: Deny public network access
- Azure Key Vault: Use Private Endpoint.

8.4. Cost Optimization

  1. Chọn đúng Connectivity:

    • VNet Peering rẻ hơn VPN Gateway (nếu cùng subscription)
    • Service Endpoint miễn phí, Private Endpoint tốn phí (~$7/month/endpoint)
  2. Right-size Gateway SKUs:

    • Đừng dùng VpnGw5 cho Dev/Test (quá đắt)
    • Basic VPN Gateway chỉ cho lab, không production
  3. Reserved Capacity: Commit 1-3 năm cho ExpressRoute để giảm 30-50% chi phí.


Tài liệu tham khảo: