Bảo mật mạng & Zero TrustNetwork Security & Zero Trust

Thuộc bộ kiến thức DevSecOps Roadmap.

Tổng quan

Bảo mật mạng (network security) là lớp phòng thủ theo chiều sâu (defense-in-depth) kiểm soát cách traffic được phép di chuyển — giữa internet và hệ thống của bạn, giữa các zone bên trong môi trường, và giữa từng workload riêng lẻ. Trong bối cảnh DevSecOps, bảo mật mạng không chỉ là mối quan tâm ở perimeter do một team networking riêng sở hữu; nó được biểu diễn dưới dạng code (security group, network policy, firewall rule) nằm trong cùng repository và pipeline với application code, và ngày càng được xây dựng xoay quanh Zero Trust thay vì một mạng nội bộ được tin tưởng đứng sau một perimeter được gia cố kỹ.

Note này tập trung vào các khái niệm và quyết định mà một DevSecOps engineer cần: firewall, IDS/IPS và ACL làm gì và cách suy luận về rule của chúng; cách thiết kế network zone và segmentation sao cho một breach ở một chỗ không biến thành breach ở mọi chỗ; cách suy nghĩ và giảm thiểu tấn công DDoS; và cách Zero Trust Architecture định hình lại bảo mật mạng xoay quanh identity và việc xác minh liên tục thay vì vị trí mạng. Để tìm hiểu sâu hơn về cơ chế cấp thiết bị của firewall, ACL và IDS/IPS (luồng packet, chi tiết bên trong stateful inspection, cú pháp ACL kiểu Cisco, VLAN hopping, ARP poisoning, v.v.), xem Network Engineer — Network Security, viết từ góc nhìn network engineering. Note này xây dựng trên nền tảng đó và áp dụng vào cách các tổ chức cloud-native, vận hành theo pipeline hiện đại thiết kế và vận hành mạng một cách an toàn.

Đây là tài liệu giáo dục bảo mật mang tính phòng thủ (defensive): mục tiêu là hiểu các cơ chế kiểm soát này đủ sâu để thiết kế, cấu hình và audit chúng đúng cách — không phải để vượt qua (bypass) chúng.

Kiến thức nền tảng

Firewall — tóm tắt nhanh

Firewall thực thi một chính sách quy định traffic nào được phép đi qua một ranh giới (boundary). Có ba thế hệ mà một DevSecOps engineer cần nhận biết:

Loại	Kiểm tra	Tính stateful	Ứng dụng phổ biến hiện nay
Packet-filtering	Chỉ header IP/port/protocol, theo từng packet	Stateless — mỗi packet được đánh giá độc lập	Hiếm khi đứng riêng; là nền tảng của ACL đơn giản và NACL trên cloud
Stateful inspection	Header + trạng thái kết nối (theo dõi phiên TCP/UDP)	Stateful — chỉ cần cho phép chiều khởi tạo, traffic trả về được tự động cho phép	Security group trên cloud, phần lớn firewall on-prem, host firewall (iptables/nftables, Windows Firewall)
Next-Generation Firewall (NGFW)	Header, state, và payload — nhận diện ứng dụng/người dùng, nội dung đã giải mã TLS, IPS tích hợp, threat intelligence	Stateful + deep packet inspection	Perimeter/edge, firewall segmentation nội bộ, tương đương trên cloud-native (AWS Network Firewall, Azure Firewall Premium)

Trong môi trường cloud, tương đương hàng ngày của một stateful firewall là security group (stateful, áp dụng ở cấp instance/ENI) kết hợp với network ACL (stateless, áp dụng ở ranh giới subnet) — xem note Cloud để biết chi tiết theo từng provider. Điểm mấu chốt về vận hành cho DevSecOps: firewall rule nên được định nghĩa dưới dạng code (Terraform, CloudFormation, Kubernetes NetworkPolicy) và trải qua cùng quy trình review/CI như application code, chứ không phải chỉnh sửa thủ công trên console hay thiết bị.

IDS vs IPS

Cả Intrusion Detection System và Intrusion Prevention System đều phân tích traffic để tìm pattern độc hại; khác biệt nằm ở việc điều gì xảy ra sau khi phát hiện điều đáng ngờ.

Khía cạnh	IDS (Intrusion Detection System)	IPS (Intrusion Prevention System)
Vị trí đặt	Out-of-band, theo dõi một bản sao của traffic (qua SPAN/mirror port hoặc tap)	Inline, nằm trực tiếp trên đường đi của traffic
Hành động khi phát hiện	Chỉ cảnh báo — ghi log, phát alarm, thông báo cho SOC/SIEM	Có thể chủ động chặn, drop packet, reset kết nối, hoặc cách ly nguồn
Ảnh hưởng của false positive	Alert gây nhiễu, không gián đoạn dịch vụ	Có thể drop traffic hợp lệ — rủi ro về availability nếu tinh chỉnh không tốt
Overhead hiệu năng	Thấp hơn (phân tích trên bản sao)	Cao hơn (phải kiểm tra và quyết định real-time, tăng độ trễ)
Chế độ thất bại (failure mode)	Vốn đã “fail open” (traffic đã đi qua rồi)	Phải cấu hình rõ ràng fail-open hay fail-closed

Phương pháp phát hiện (áp dụng cho cả IDS và IPS):

• Signature-based — so khớp traffic với cơ sở dữ liệu các pattern tấn công đã biết (giống signature của antivirus). Nhanh, tỷ lệ false-positive thấp với threat đã biết, nhưng không nhận ra được tấn công mới/zero-day và dễ bị né tránh bằng những biến thể nhỏ. Ví dụ: rule Snort/Suricata so khớp byte pattern của một exploit cụ thể.
• Anomaly-based — xây dựng baseline về traffic/hành vi “bình thường” (khối lượng traffic, cách dùng protocol, pattern kết nối) và gắn cờ những sai lệch. Có thể bắt được tấn công mới và zero-day, nhưng tỷ lệ false-positive cao hơn và cần thời gian tune/học.
• Hybrid — hầu hết sản phẩm hiện đại (ví dụ: Suricata, module IPS/NGFW thương mại) kết hợp cả hai, cộng thêm reputation feed và phát hiện dựa trên hành vi/ML để có tín hiệu phong phú hơn.

NIDS vs HIDS: một Network IDS/IPS (Suricata, Snort, Zeek) theo dõi traffic trên đường truyền tại một điểm nghẽn (span port, inline tap); một Host IDS/IPS (OSSEC, Wazuh, Falco cho container) theo dõi hoạt động trên một host hoặc container đơn lẻ — file integrity, process execution, syscall. Trong pipeline DevSecOps, các công cụ kiểu HIDS chạy dưới dạng sidecar hoặc DaemonSet (ví dụ: Falco trong Kubernetes) thường liên quan hơn so với network tap cổ điển, vì traffic east-west bên trong một cluster hoặc overlay network là vô hình đối với một NIDS ở perimeter.

ACL (Access Control List)

ACL là một danh sách có thứ tự các rule permit/deny được so khớp với đặc điểm của traffic. Hai dạng cốt lõi:

Loại	So khớp trên	Độ chi tiết	Vị trí đặt điển hình
Standard ACL	Chỉ địa chỉ IP nguồn	Thô	Gần đích (vì không thể lọc theo service/đích)
Extended ACL	IP nguồn, IP đích, protocol, port nguồn/đích	Chi tiết	Gần nguồn (lọc traffic càng sớm càng tốt)

Ba quy tắc cần khắc cốt ghi tâm:

1. Thứ tự quan trọng — rule được đánh giá từ trên xuống dưới, và rule khớp đầu tiên sẽ thắng; một “deny” rộng đặt trên một “permit” cụ thể sẽ âm thầm chặn permit đó và không bao giờ được xử lý tới.
2. Implicit deny (deny ngầm định) — gần như mọi hiện thực ACL đều kết thúc bằng một “deny all” vô hình sau rule tường minh cuối cùng. Nếu không có gì khớp, traffic bị drop. Đây chính là biểu hiện thực tế của default-deny / least privilege ở tầng mạng.
3. Hướng (direction) — ACL được áp dụng theo từng interface, theo từng hướng (inbound vs outbound); cùng một danh sách rule có thể mang ý nghĩa rất khác nhau tùy vào việc nó được gắn theo hướng nào.

Ví dụ extended ACL (cú pháp Cisco IOS) cho phép HTTPS tới web tier từ bất kỳ đâu, SSH chỉ từ subnet quản trị, và deny mọi thứ còn lại:

ip access-list extended WEB-TIER-IN
 permit tcp any host 10.0.1.10 eq 443
 permit tcp 10.0.100.0 0.0.0.255 host 10.0.1.10 eq 22
 deny   ip any any log
!
interface GigabitEthernet0/1
 ip access-group WEB-TIER-IN in

Ý định tương đương được biểu diễn dưới dạng Kubernetes NetworkPolicy (namespace default-deny, sau đó allow tường minh) — phiên bản cloud-native, thân thiện với pipeline của ACL ở trên:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: web-tier
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-https-from-anywhere
  namespace: web-tier
spec:
  podSelector:
    matchLabels: { app: web }
  policyTypes: ["Ingress"]
  ingress:
    - from: []
      ports:
        - protocol: TCP
          port: 443

Chú ý ba nguyên tắc trên vẫn áp dụng: một default-deny tường minh, các allow rule được thu hẹp phạm vi, và cách đánh giá mang tính cộng dồn (rule NetworkPolicy của Kubernetes được OR với nhau — không có kiểu “khớp đầu tiên thắng” như ACL của Cisco, đây là khác biệt quan trọng cần lưu ý khi chuyển đổi giữa hai mô hình).

Để tìm hiểu sâu hơn về cú pháp ACL, wildcard mask và cơ chế cấu hình theo từng thiết bị, xem Network Engineer — Network Security § ACLs.

Khái niệm chính

Network segmentation và secure zoning

Segmentation chia mạng thành các zone tách biệt để việc một zone bị compromise không tự động cho phép truy cập vào mọi zone khác — nó giới hạn blast radius (phạm vi ảnh hưởng) của kẻ tấn công và làm chậm hoặc chặn đứng lateral movement (di chuyển ngang).

Zone/kỹ thuật	Mục đích	Ví dụ
DMZ (demilitarized zone)	Chứa các hệ thống cần truy cập được từ internet, tách biệt khỏi mạng nội bộ đáng tin cậy	Web server public, reverse proxy, mail gateway
Internal zone (zone nội bộ)	Nhóm các hệ thống nội bộ theo mức độ tin cậy hoặc chức năng để traffic xuyên zone phải đi qua một policy enforcement point	VLAN người dùng, VLAN server/app, VLAN database, VLAN quản trị
Microsegmentation	Thực thi chính sách chi tiết, thường theo từng workload — xuống tới từng pod, container, hoặc VM — bất kể topology vật lý/mạng	Kubernetes NetworkPolicy, security group theo từng service trên cloud, service mesh mTLS + authorization policy (Istio, Linkerd)

Tại sao segmentation quan trọng đến vậy trong thực tế: hầu hết các breach nghiêm trọng không phải là “kẻ tấn công vào được một server và thế là xong” — mà là một chuỗi: chỗ đứng chân ban đầu (ví dụ: một web app dễ tổn thương trong DMZ) → di chuyển ngang (tới database hoặc hệ thống admin nội bộ) → leo thang đặc quyền (privilege escalation) → exfiltration (đánh cắp dữ liệu). Segmentation phá vỡ chuỗi này ở bước thứ hai. Nếu không có nó, một container bị compromise thường có thể tới được mọi service khác trong một mạng phẳng; với microsegmentation đúng cách, chính container đó chỉ có thể tới các service cụ thể mà NetworkPolicy/security group của nó cho phép tường minh — mọi thứ còn lại là implicit deny.

Nguyên tắc thiết kế segmentation:

• Segment theo mức độ tin cậy và blast-radius, không chỉ theo phòng ban — production vs. staging, hệ thống trong phạm vi PCI vs. mọi thứ khác, hệ thống chứa PII vs. hệ thống không chứa.
• Thực thi default-deny giữa các zone; chỉ allow tường minh những luồng mà kiến trúc đã ghi chép thực sự cần (điều này khớp trực tiếp với ví dụ ACL/NetworkPolicy ở trên).
• Đặt một policy enforcement point (firewall, ranh giới security group, sidecar service mesh) tại mọi ranh giới zone — segmentation không có enforcement chỉ là một sơ đồ trên giấy.
• Trong môi trường Kubernetes/cloud-native, mặc định dùng NetworkPolicy default-deny ở cấp namespace cộng với allow rule tường minh cho từng service, phản chiếu mô hình DMZ/zone nội bộ ở cấp workload.

Chiến lược giảm thiểu DDoS

Tấn công Distributed Denial of Service (DDoS) nhắm vào việc làm cạn kiệt availability của mục tiêu — băng thông, trạng thái kết nối, hoặc năng lực ứng dụng — bằng traffic từ nhiều nguồn phân tán. Việc giảm thiểu hiệu quả phụ thuộc vào việc nhận diện tầng nào đang bị tấn công.

Loại tấn công	Tầng OSI	Cạn kiệt cái gì	Ví dụ	Giảm thiểu chính
Volumetric	L3/L4	Băng thông mạng	UDP/ICMP flood, khuếch đại DNS/NTP	Anycast + scrubbing center, dịch vụ DDoS protection của ISP/cloud thượng nguồn, blackhole nguồn cực đoan
Protocol	L3/L4	Bảng trạng thái kết nối của server/thiết bị mạng	SYN flood, ping of death, tấn công phân mảnh packet	SYN cookie, giới hạn số kết nối trên stateful firewall, rate limiting ở edge
Application-layer	L7	Năng lực compute/database của ứng dụng/backend	HTTP flood, slow POST (Slowloris), lạm dụng API vào endpoint tốn kém	Rule WAF, rate limiting theo client/IP/API key, CAPTCHA/trang challenge, caching (CDN), validate request

Các kỹ thuật giảm thiểu cốt lõi, dùng kết hợp:

• Rate limiting — giới hạn số request theo nguồn (IP, API key, người dùng) trong một khoảng thời gian; áp dụng ở edge (CDN/WAF), load balancer, API gateway, và tầng ứng dụng.
• Traffic scrubbing — chuyển hướng traffic đáng ngờ qua một scrubbing center hoặc dịch vụ DDoS protection trên cloud (AWS Shield, Cloudflare Magic Transit/Spectrum, Azure DDoS Protection) để lọc traffic độc hại và chỉ chuyển tiếp traffic sạch về origin.
• Anycast routing — quảng bá cùng một địa chỉ IP từ nhiều điểm hiện diện (point of presence) phân tán về mặt địa lý để traffic tấn công volumetric được hấp thụ và pha loãng trên nhiều địa điểm thay vì dồn vào một origin duy nhất.
• CDN/edge caching — phục vụ nội dung tĩnh và có thể cache từ edge node để một luồng request ồ ạt không bao giờ chạm tới hạ tầng origin.
• Overprovisioning và autoscaling — hấp thụ những đợt burst ngắn, dù riêng nó không ngăn được một tấn công đủ lớn và có thể biến thành kịch bản “scale tới phá sản” tốn kém nếu không kết hợp với rate limiting.
• Lọc theo geo/reputation IP — chặn hoặc thách thức traffic từ những dải/khu vực không có mối quan hệ kinh doanh hợp pháp nào với dịch vụ, như một bộ lọc thô ban đầu.
• BCP38 / anti-spoofing tại edge mạng — việc ISP và nhà vận hành mạng lọc packet có địa chỉ nguồn giả mạo làm giảm hiệu quả của tấn công khuếch đại và phản xạ trên toàn ngành (bối cảnh liên quan dù phần lớn được thực thi ở thượng nguồn, không phải bởi chủ sở hữu ứng dụng).

Một kế hoạch ứng phó DDoS (một phần của incident response) nên xác định: ai công bố sự cố, tầng giảm thiểu nào kích hoạt tự động (rule CDN/WAF) so với cần quyết định của con người (liên hệ nhà cung cấp scrubbing thượng nguồn), và cách truyền đạt tình trạng trong suốt sự cố.

Zero Trust Architecture (NIST SP 800-207)

Zero Trust đảo ngược mô hình bảo mật mạng truyền thống. Bảo mật perimeter kiểu “castle-and-moat” (lâu đài-hào nước) truyền thống giả định rằng bất cứ thứ gì bên trong ranh giới mạng đều tương đối đáng tin cậy — một khi thiết bị hoặc người dùng đã ở trong mạng nội bộ, họ thường có thể tiếp cận một loạt tài nguyên khác với rất ít ma sát bổ sung. Zero Trust giả định điều ngược lại: không người dùng, thiết bị, hay vị trí mạng nào được tin tưởng mặc định, bất kể request xuất phát từ đâu — mọi request đều phải được xác thực (authenticate), phân quyền (authorize), và mã hóa, liên tục, dựa trên identity và ngữ cảnh (context) thay vì vị trí mạng. Điều này được thể hiện trong khẩu hiệu “never trust, always verify”.

Các nguyên tắc cốt lõi từ NIST SP 800-207:

1. Mọi nguồn dữ liệu và dịch vụ tính toán đều được coi là resource — mọi resource đều cần access control, không có ngoại lệ vì “nằm trong nội bộ”.
2. Mọi giao tiếp đều được bảo mật bất kể vị trí mạng — việc ở trên LAN của công ty không mang lại tin cậy ngầm định; traffic được mã hóa và xác thực như nhau bất kể xuất phát từ nội bộ hay bên ngoài.
3. Quyền truy cập vào từng resource riêng lẻ được cấp theo từng phiên (per-session) — trust được đánh giá và cấp cho một phiên/request đơn lẻ, không phải một cách dai dẳng cho thiết bị hay người dùng sau khi đã xác thực một lần.
4. Quyền truy cập được xác định bởi policy động — được đánh giá dựa trên identity, tình trạng/độ khỏe của thiết bị (device posture), thuộc tính hành vi, và ngữ cảnh môi trường (thời gian, vị trí, threat intelligence), không chỉ dựa trên một vai trò (role) tĩnh.
5. Tổ chức giám sát và đo lường tính toàn vẹn cùng tư thế bảo mật của mọi tài sản (asset) sở hữu và liên quan — tình trạng sức khỏe/patch của thiết bị được đưa vào quyết định truy cập.
6. Mọi xác thực và phân quyền resource đều động và được thực thi nghiêm ngặt trước khi cho phép truy cập — đánh giá lại liên tục, không phải “xác thực một lần, tin tưởng mãi mãi”.
7. Tổ chức thu thập càng nhiều thông tin càng tốt về trạng thái hiện tại của asset, hạ tầng mạng, và giao tiếp, và dùng nó để cải thiện tư thế bảo mật — logging và telemetry phản hồi ngược lại vào policy.

Các thành phần kiến trúc (mô hình NIST 800-207):

• Policy Engine (PE) — thành phần ra quyết định; đánh giá một request dựa trên policy và tín hiệu bên ngoài (threat intelligence, dữ liệu identity provider, device posture) và đưa ra quyết định allow/deny.
• Policy Administrator (PA) — thực thi quyết định của PE bằng cách thiết lập hoặc chấm dứt đường giao tiếp (ví dụ: phát hành credential/token có thời hạn ngắn, cấu hình PEP).
• Policy Enforcement Point (PEP) — thành phần thực sự chặn/kiểm soát kết nối dựa trên chỉ thị của PA (một gateway, proxy, sidecar, hoặc agent đứng trước resource). Đây là phần thực tế, hàng ngày mà một DevSecOps engineer cấu hình — về bản chất, mỗi service có perimeter nhỏ của riêng nó.

PE + PA kết hợp lại thường được gọi chung là Policy Decision Point (PDP), đối lập với PEP nằm gần resource hơn.

Cơ chế then chốt hiện thực hóa Zero Trust trong thực tế:

• Identity-centric access (truy cập lấy identity làm trung tâm) — quyết định truy cập được neo vào identity đã được xác thực mạnh (identity người dùng và/hoặc workload/service qua chứng chỉ mTLS hoặc SPIFFE/SPIRE), không phải IP nguồn hay network segment. Đây là lý do Zero Trust và IAM không thể tách rời — xem Identity and Access Management để biết về xác thực, phân quyền, và thiết kế truy cập least-privilege.
• Microsegmentation — thực thi policy theo từng workload (xem ở trên) sao cho ngay cả sau khi xác thực, một workload chỉ có thể tới các dependency cụ thể mà nó cần, không hơn.
• Kiểm tra tình trạng thiết bị/endpoint — xác minh thiết bị gửi request được quản lý, đã patch, và tuân thủ chính sách trước khi cấp quyền truy cập, không chỉ xác minh credential của người dùng.
• ZTNA (Zero Trust Network Access) — thay thế truy cập từ xa dựa trên VPN truyền thống kiểu “kết nối vào mạng, rồi tin tưởng mọi thứ” bằng truy cập môi giới (brokered), đã xác minh identity, theo từng ứng dụng (ví dụ: Google BeyondCorp, Cloudflare Access, Zscaler Private Access). Người dùng không bao giờ được đặt “vào trong mạng”; mỗi kết nối tới ứng dụng được phân quyền riêng lẻ.
• Credential ngắn hạn và xác minh liên tục — session token, credential của service, và chứng chỉ có thời hạn ngắn và được cấp lại/xác minh lại thường xuyên thay vì được tin tưởng vô thời hạn sau một lần đăng nhập.

Defense-in-depth áp dụng vào thiết kế mạng

Zero Trust không thay thế firewall, IDS/IPS, hay segmentation — nó là nguyên lý tổ chức gắn kết chúng lại với nhau, với identity là lớp kết nối. Một mạng được thiết kế tốt áp dụng tất cả những điều này cùng nhau, theo từng lớp:

1. Lớp 1
   Edge / CDN / WAFPerimeter: NGFW/WAF, DDoS scrubbing, anycast
2. Lớp 2
   DMZdịch vụ public-facing, reverse proxy
3. Lớp 3
   Mạng lõi nội bộSegmentation: zone nội bộ, VLAN/subnet, NACL; đi qua policy enforcement point — extended ACL / stateful FW
4. Lớp 4
   Users và ServicesMicrosegmentation: NetworkPolicy theo workload / security group / service-mesh mTLS
5. Lớp 5
   PEPpolicy enforcement point theo từng service — sidecar/gateway. Lớp identity Zero Trust: mọi request được xác thực và phân quyền bất kể xuất phát từ zone nào
6. Lớp 6
   ResourceDetection: IDS/IPS (NIDS tại điểm nghẽn, HIDS theo từng host/container), logging tập trung tới SIEM

Mỗi lớp giả định rằng những lớp “bên ngoài” nó có thể thất bại: firewall perimeter có thể bị cấu hình sai, một host trong DMZ có thể bị compromise, kẻ tấn công có thể có được credential trông có vẻ hợp lệ — việc xác minh liên tục, dựa trên identity ở mọi hop của Zero Trust chính là thứ giới hạn mức độ lan rộng của một thất bại đơn lẻ đó, và IDS/IPS cùng logging tập trung là thứ biến “chúng ta đã bị breach” thành “chúng ta phát hiện trong vài phút, không phải vài tháng”. Điều này mở rộng trực tiếp mô hình defense-in-depth từ note Giới thiệu DevSecOps sang cụ thể tầng mạng.

Bảo mật perimeter truyền thống vs. Zero Trust

Khía cạnh	Perimeter truyền thống (“castle-and-moat”)	Zero Trust
Cơ sở của trust	Vị trí mạng (bên trong = tin cậy, bên ngoài = không tin cậy)	Identity và ngữ cảnh (người dùng, thiết bị, workload) — vị trí không phải là tín hiệu tin cậy
Perimeter	Một ranh giới được gia cố duy nhất (firewall ở edge)	Không có perimeter duy nhất; mọi resource tự thực thi ranh giới của riêng nó (PEP)
Traffic nội bộ	Phần lớn được tin cậy sau khi qua perimeter (mạng nội bộ phẳng)	Được xác thực và phân quyền ở mọi request, mã hóa khi truyền
Độ chi tiết truy cập	Rộng — truy cập cấp VLAN/subnet một khi đã kết nối	Chi tiết — theo từng resource, từng phiên, least-privilege
Mô hình truy cập từ xa	VPN — đặt người dùng từ xa “vào trong mạng”	ZTNA — môi giới truy cập tới từng ứng dụng riêng lẻ, người dùng không bao giờ gia nhập mạng
Rủi ro lateral movement	Cao — compromise một host thường làm lộ nhiều host khác	Thấp — microsegmentation và xác thực theo từng request giới hạn resource có thể tiếp cận
Cơ sở của policy	Rule tĩnh (IP/subnet/port)	Policy động (identity, device posture, hành vi, tín hiệu rủi ro)
Chế độ thất bại	Điểm lỗi đơn (single point of failure) — phá được perimeter, tiếp cận được mọi thứ bên trong	Defense-in-depth theo thiết kế — compromise một credential/phiên không cấp quyền truy cập rộng
Nơi thực thi	Thiết bị mạng ở edge	Phân tán — mọi ranh giới service/workload

Zero Trust không có nghĩa là “không có bảo mật mạng” hay “không có firewall” — segmentation, ACL, IDS/IPS, và phòng thủ perimeter đều vẫn hiện diện; Zero Trust bổ sung một bước kiểm tra identity-và-ngữ-cảnh bắt buộc ở mọi hop thay vì dựa vào vị trí mạng như một tín hiệu tin cậy ngầm định. Trong thực tế, hầu hết tổ chức chuyển sang Zero Trust theo từng bước, phủ thêm identity-aware proxy và microsegmentation lên một mạng đã được segment sẵn thay vì thay thế toàn bộ trong một đêm.

Best Practices

• Default-deny ở mọi nơi — ở cấp firewall/ACL, cấp namespace Kubernetes, và cấp policy Zero Trust. Chỉ allow tường minh, cho những luồng đã được ghi chép và thực sự cần thiết.
• Coi network policy là code — firewall rule, security group, và manifest NetworkPolicy phải nằm trong version control, trải qua review pull request, và được áp dụng qua CI/CD, không chỉnh sửa thủ công trên console hay thiết bị.
• Segment theo blast radius, không phải theo sự tiện lợi — tách production khỏi non-production, và cách ly các hệ thống xử lý dữ liệu nhạy cảm/theo quy định, dù điều đó có nghĩa là phải quản lý nhiều zone hơn.
• Giả định perimeter sẽ bị breach — đầu tư nhiều vào internal segmentation, microsegmentation, và xác minh identity ngang bằng với firewall ở edge; một breach ở một lớp không được phép lan rộng theo tầng.
• Ưu tiên ZTNA hơn VPN truy cập phẳng cho truy cập từ xa/bên thứ ba — môi giới truy cập theo từng ứng dụng thay vì đặt bất kỳ bên nào từ xa “vào trong mạng”.
• Khớp vị trí đặt và chế độ của IDS/IPS với khẩu vị rủi ro (risk tolerance) — chỉ dùng IPS (inline, chặn) ở những nơi false positive đã được hiểu rõ và tinh chỉnh; bắt đầu detection mới ở chế độ IDS (chỉ cảnh báo) và nâng lên chế độ chặn khi đã đủ tin cậy.
• Quan sát traffic east-west, không chỉ north-south — triển khai detection ở cấp host/container (Falco, Wazuh, telemetry của service mesh) vì một NIDS ở perimeter không thể thấy traffic giữa các service nội bộ.
• Thiết kế và diễn tập ứng phó DDoS trước khi tấn công xảy ra, không phải trong lúc tấn công — biết rõ giảm thiểu nào là tự động (rule CDN/WAF, rate limit) và giảm thiểu nào cần quyết định của con người, và thử nghiệm chuyển đổi sang nhà cung cấp scrubbing.
• Kết hợp network control với identity mạnh — network segmentation mà không có xác thực/phân quyền mạnh là Zero Trust chưa hoàn chỉnh; xem Identity and Access Management để biết phần identity của phương trình này.
• Liên tục kiểm thử các control của bạn — xác thực ACL, ranh giới segmentation, và việc thực thi policy Zero Trust bằng các công cụ và kỹ thuật trong Security Testing Tools, không chỉ ở thời điểm thiết kế ban đầu.

Tài liệu tham khảo

• NIST SP 800-207 — Zero Trust Architecture
• NIST SP 800-53 — Security and Privacy Controls for Information Systems and Organizations
• Cloudflare Learning Center — What is Zero Trust?
• Cloudflare Learning Center — What is a DDoS Attack?
• Cloudflare Learning Center — Firewall vs. IDS vs. IPS
• OWASP — Network Segmentation Cheat Sheet
• Kubernetes — Network Policies documentation
• Network Engineer — Network Security (đào sâu cấp thiết bị)

ip access-list extended WEB-TIER-IN
 permit tcp any host 10.0.1.10 eq 443
 permit tcp 10.0.100.0 0.0.0.255 host 10.0.1.10 eq 22
 deny   ip any any log
!
interface GigabitEthernet0/1
 ip access-group WEB-TIER-IN in

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: web-tier
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-https-from-anywhere
  namespace: web-tier
spec:
  podSelector:
    matchLabels: { app: web }
  policyTypes: ["Ingress"]
  ingress:
    - from: []
      ports:
        - protocol: TCP
          port: 443