Device posture và continuous verification mọi request

TL;DR

Device posture là tín hiệu về trạng thái bảo mật của thiết bị tại mỗi request, không chỉ lúc đăng nhập. Phát hiện xâm nhập, trôi dạt tuân thủ, thiết bị bị đánh cắp sau khi người dùng đã xác thực, nguyên tắc cốt lõi của Zero Trust “never trust, always verify”.

4 lớp tín hiệu posture:

• Kiểm tra có sẵn của WARP: phiên bản OS, mã hóa ổ đĩa, firewall bật, ứng dụng đang chạy.
• Tích hợp EDR: Crowdstrike Falcon, SentinelOne, Microsoft Defender; thiết bị có đang được bảo vệ thời gian thực không?
• Tích hợp MDM: Intune/Jamf; thiết bị có tuân thủ chính sách không?
• Service-to-service tùy chỉnh: webhook posture provider tự định nghĩa.

Bài này đi qua:

• Tại sao xác thực lúc đăng nhập không đủ.
• Kiểm tra của WARP client: danh sách tín hiệu posture có sẵn.
• Thiết lập tích hợp EDR + rủi ro cảnh báo.
• Đánh giá liên tục: Access xác thực lại mỗi N phút.
• Playbook phản ứng: thiết bị fail posture, huỷ session, cảnh báo SOC, khắc phục.
• Chính sách posture phân lớp: phân tầng truy cập theo mức posture.

Luận điểm chính:

Xác thực là “bạn là ai” một lần. Device posture là “trạng thái máy bạn” liên tục. Người dùng có thể đăng nhập sạch lúc 9h sáng, rồi click malware lúc 10h, nếu không có posture check liên tục, kẻ tấn công có token hợp lệ trong tay và Access không biết. Đánh giá liên tục theo posture là cách duy nhất đóng vòng lặp đó.

Bài này là Part 16 của Cloudflare One Handbook, đóng block Observability & Ops, mở block Advanced Security (Part 17+).

---

Dành cho ai

• Kỹ sư bảo mật xây chính sách Zero Trust với tín hiệu theo thiết bị.
• Admin EDR (Crowdstrike, SentinelOne, Defender) muốn đưa telemetry vào quyết định truy cập.
• Nhóm tuân thủ cần chứng minh “verify” không chỉ lúc đăng nhập.

Bạn nên đã đọc:

• Part 4, Cloudflare Access (ngữ cảnh đánh giá policy).
• Part 9, WARP (nguồn tín hiệu posture).
• Part 14, Logs (luồng kết quả posture).

Sau bài này bạn sẽ:

• Biết danh sách posture check có sẵn của WARP.
• Cấu hình tích hợp EDR (Crowdstrike ZTA, SentinelOne, Defender).
• Viết Access policy dùng điều kiện posture.
• Thiết kế phản ứng khi thiết bị fail posture giữa session.
• Phân tầng truy cập theo mức posture (công ty quản lý > BYOD có quản lý > BYOD không quản lý).

---

Bài này không nói về gì

• So sánh nhà cung cấp endpoint protection sâu: chỉ góc tích hợp.
• Mobile Device Management chi tiết (thiết kế policy Intune/Jamf): bài riêng.
• Playbook phản ứng SOC đầy đủ: chỉ nhắc qua.
• Chi tiết framework tuân thủ (CIS, NIST 800-171): chỉ ánh xạ.
• UEBA (User Entity Behavior Analytics): khác dataset, chỉ nhắc qua.

---

Khái niệm

• Posture: trạng thái bảo mật của thiết bị tại thời điểm đánh giá: phiên bản OS, đĩa đã mã hóa, firewall bật, agent EDR đang chạy, trạng thái tuân thủ.
• Posture provider: nguồn phát tín hiệu. Sẵn có (WARP), SaaS (nhà cung cấp EDR), tùy chỉnh (webhook).
• Posture check: rule ghép với tín hiệu provider. Ví dụ “Crowdstrike ZTA score ≥ 50”.
• Đánh giá liên tục: Access kiểm tra lại posture mỗi N phút hoặc mỗi request, không chỉ ở lúc đăng nhập.
• Access policy: rule kiểm soát cho thiết bị truy cập ứng dụng, có thể bao gồm điều kiện posture.
• EDR: Endpoint Detection and Response: Crowdstrike, SentinelOne, Defender for Endpoint, Carbon Black, Cortex XDR.
• ZTA (Zero Trust Assessment): tên gọi của Crowdstrike cho điểm posture.
• Session token: JWT do Access phát hành sau khi đăng nhập + policy pass; có hiệu lực 15 phút-24 giờ.

---

Tại sao xác thực lúc đăng nhập không đủ

Kịch bản

• 9:00: Alice đăng nhập Salesforce qua Access. Posture check pass (firewall on, OS đã cập nhật, đĩa mã hóa). Token có hiệu lực 8 giờ.
• 9:30: Alice làm việc ổn. Không cảnh báo.
• 10:30: Alice click email phishing. Dropper chạy. Credential stealer gọi C2.
• 10:45: Malware thử dump Chrome credentials, SSO token bị đánh cắp.
• 11:00: Kẻ tấn công dùng token, truy cập Salesforce từ IP khác.
• Access cổ điển: session vẫn hợp lệ (trong cửa sổ 8h). Token xác thực OK. Request pass.
• Posture liên tục: Crowdstrike phát cảnh báo, ZTA score tụt, Access đánh giá lại, policy fail, session bị huỷ.

Xác thực lúc đăng nhập là snapshot, không phải liên tục

ZTNA truyền thống kiểm soát tại lúc đăng nhập. Token được phát hành sau khi xác thực + kiểm tra. Token dùng lại cho tất cả request trong TTL. Token không mang tín hiệu thời gian thực, chỉ nói “lúc 9h sáng mọi thứ OK”.

Nguyên tắc Zero Trust “never trust, always verify” chỉ đúng khi xác thực diễn ra mỗi request (hoặc ít nhất mỗi N phút).

Các loại tín hiệu posture

Tín hiệu tĩnh (kiểm tra một lần hoặc ít thay đổi):

• Phiên bản OS
• Đĩa đã mã hóa (BitLocker, FileVault)
• Serial number / machine ID
• Domain-joined
• Có certificate

Tín hiệu động (có thể thay đổi mỗi phút):

• Agent EDR đang chạy + khỏe mạnh
• Điểm threat EDR (Crowdstrike ZTA)
• Firewall đang hoạt động
• Ứng dụng cần thiết đang chạy (ví dụ agent DLP)
• Sức khỏe mạng (WiFi an toàn, không phải AP công cộng)

Đánh giá liên tục tập trung vào tín hiệu động.

---

Posture check có sẵn của WARP

Danh sách kiểm tra có sẵn

Cloudflare WARP client thu được khoảng 15 loại tín hiệu:

Check	Platform	Example
OS version	Win, Mac, Linux, iOS, Android	macos_version >= 14.0
Domain joined	Windows	joined to corporate AD
Disk encryption	Win (BitLocker), Mac (FileVault), Linux	on/off
Firewall	all	on/off
Anti-virus	Win	Defender present
Application present	all	Chrome installed
Application running	all	DLP agent active
File present	all	/etc/corp-config.ini exists
File hash	all	SHA256 match expected
Registry key	Win	key value match
Serial number	all	in approved list
Certificate	all	cert issued by corp CA present
MDM compliant	Intune, Jamf	compliant flag
Client version	WARP	min version
Tamper proof	WARP	WARP binary not modified

Ví dụ cấu hình

posture_check:
  name: "corp-required-baseline"
  platforms: ["windows", "macos"]
  checks:
    - type: os_version
      operator: ">="
      value: "windows 10 build 19045"  # or macos 14.0
    - type: disk_encryption
      value: "on"
    - type: firewall
      value: "on"
    - type: application_present
      application: "com.crowdstrike.falcon.agent"
    - type: serial_number
      list: "$corp-serial-approved"  # UUID list from MDM export

Tần suất đánh giá

• WARP client kiểm tra mỗi 30 giây (cấu hình được 30s - 30m).
• Kết quả đẩy về bộ đánh giá Access của CF.
• Access kiểm tra lại posture mỗi lần refresh session (mặc định 1h, cấu hình được).

Để xác thực liên tục, giảm TTL token xuống 15-30 phút, posture được kiểm tra lại mỗi lần refresh.

---

Tích hợp EDR

EDR được hỗ trợ

• Crowdstrike Falcon ZTA: tích hợp sẵn, điểm posture 0-100.
• SentinelOne: trạng thái sức khỏe thiết bị qua API.
• Microsoft Defender for Endpoint: tuân thủ qua Graph API.
• Tanium: tuân thủ của agent.
• Carbon Black: tùy chỉnh qua API.

Tích hợp Crowdstrike ZTA

1. Dashboard Crowdstrike → API Clients → tạo client với phạm vi ZTA:read.
2. Cloudflare Zero Trust → Settings → Device posture → Add integration → Crowdstrike → nhập credentials API.
3. CF kéo ZTA score mỗi 5 phút cho từng thiết bị đã enroll.
4. Dùng trong policy:

posture_check:
  name: "Crowdstrike healthy"
  type: crowdstrike
  zta_score_minimum: 70
  overall_status: "pass"

Cách hiểu điểm ZTA:

• 70-100: Xanh: khỏe mạnh, rủi ro tối thiểu.
• 40-69: Vàng: có vấn đề.
• 0-39: Đỏ: phát hiện threat đang hoạt động.

Tích hợp Microsoft Defender

Yêu cầu ngữ cảnh Azure AD + Intune. Tín hiệu tuân thủ Intune được phơi qua Graph API.

posture_check:
  name: "Intune compliant"
  type: intune
  compliance_status: "compliant"

Tích hợp SentinelOne

posture_check:
  name: "SentinelOne active"
  type: sentinel_one
  threat_status: "resolved"
  agent_last_active_within: "5m"

Cân nhắc luồng dữ liệu

• Độ trễ: EDR cloud về CF thường thăm dò trễ 5 phút.
• Sẵn sàng: nhà cung cấp EDR outage, CF không kéo được posture, policy quyết định thế nào?
  • Fail closed: từ chối truy cập (nghiêm ngặt, Zero Trust thuần).
  • Fail open: cho phép với cảnh báo (nhẹ tay).
• Khuyến nghị: fail closed cho ứng dụng quan trọng, fail open cho truy cập chung + giám sát.

Quota API

• Nhà cung cấp EDR giới hạn API.
• 10K thiết bị, khoảng 2K calls/giờ cho dữ liệu ZTA.
• Kiểm tra quota trong hợp đồng; nâng cấp nếu mở rộng lớn.

---

Posture service-to-service tùy chỉnh

Trường hợp sử dụng

EDR không được hỗ trợ native, tự xây tùy chỉnh.

Mẫu webhook

Custom posture provider (your service)
  ↓ push
POST https://posture.cloudflareaccess.com/webhook
  { "device_id": "d_xyz", "status": "pass", "score": 85, "timestamp": ... }
  ↓
Cloudflare validates
  ↓
Access policy evaluate with custom signal

Thiết lập

1. Cloudflare Zero Trust → Device posture → Add integration → Service to service.
2. Lấy webhook URL + API key.
3. Dịch vụ của bạn POST trạng thái thiết bị định kỳ.

Khi nào dùng tuỳ chỉnh

• Nhà cung cấp không được hỗ trợ (Trellix, F-Secure, Sophos).
• Cần tín hiệu kết hợp (EDR + vulnerability scanner + vệ sinh mạng).
• Công cụ bảo mật tự xây.

---

Đánh giá liên tục: Access policy

Mẫu policy

application: "salesforce"
policies:
  - name: "Allow if posture OK"
    action: allow
    include:
      - email_domain: "company.com"
    require:
      - posture:
          name: "corp-required-baseline"
      - posture:
          name: "Crowdstrike healthy"
    session_duration: "30m"  # short TTL = frequent re-check

Block require = TẤT CẢ phải khớp. include = bất kỳ khớp.

TTL session ngắn

• Mặc định session Access: 24h.
• Có posture: 15-30 phút cho ứng dụng nhạy cảm.
• Mỗi lần refresh: đánh giá lại toàn bộ policy gồm cả posture.

Buộc xác thực lại khi posture thay đổi

Cloudflare hỗ trợ Purge tokens on posture failure (đánh giá lại theo chu kỳ Access — xem ghi chú bên dưới).

Luồng:

1. Thiết bị fail tín hiệu posture.
2. Bộ đánh giá posture CF đánh dấu thiết bị không tuân thủ.
3. Token Access bị thu hồi ngay (không chờ hết hạn).
4. Request tiếp theo của người dùng, xác thực lại + kiểm tra posture lại.
5. Nếu thiết bị vẫn không đạt, từ chối.

Middleware mẫu: ghép Access với Workers

Để kiểm soát tối đa, ghép Access + Cloudflare Workers:

// Worker in front of critical app
export default {
  async fetch(request, env) {
    const jwt = request.headers.get("cf-access-jwt-assertion");
    const identity = await verifyJWT(jwt, env.AUD);

    // Real-time posture check via API
    const posture = await fetch(
      `https://api.cloudflare.com/client/v4/accounts/${env.ACCOUNT}/devices/${identity.device_id}/posture`,
      { headers: { Authorization: `Bearer ${env.API_TOKEN}` } }
    ).then(r => r.json());

    if (posture.result.crowdstrike_score < 70) {
      return new Response("Posture insufficient", { status: 403 });
    }

    return fetch(`https://origin.corp.internal${new URL(request.url).pathname}`, request);
  }
};

Xác thực mỗi request. Đắt (gọi API mỗi lần), dành cho ứng dụng rủi ro cao nhất.

---

Playbook phản ứng: posture fail

Hành động tức thì (tự động)

1. Thu hồi session, token Access bị vô hiệu.
2. Chặn session mới, người dùng kẹt ở màn đăng nhập với lỗi posture.
3. Ghi log sự kiện, access_requests + device_posture_results đẩy về SIEM.

Thông báo

4. Người dùng: email + WARP popup: “Thiết bị của bạn fail kiểm tra bảo mật. Liên hệ IT để được khôi phục truy cập. Lỗi: [lý do cụ thể]”.
5. SOC/IT: cảnh báo PagerDuty, đặc biệt cho EDR red score (active threat).
6. Manager: nếu kéo dài.

Điều tra (thủ công hoặc bán tự động)

7. SOC: xem chi tiết EDR, xác định loại threat.
8. IT: xác nhận người dùng không bị xâm nhập (tín hiệu gian lận, di chuyển bất khả thi).
9. Cách ly: EDR cách ly thiết bị khỏi mạng nếu có malware chủ động.

Khắc phục

10. Người dùng khắc phục theo hướng dẫn: chạy AV scan, cập nhật OS, mã hóa lại đĩa.
11. IT xác nhận khắc phục: tín hiệu posture được đánh giá lại.
12. Khôi phục truy cập tự động khi posture cải thiện.

Cách ly qua MDM

Với xâm nhập đã xác nhận: MDM xoá thiết bị + cấp lại, không chỉ chặn posture.

Tài liệu

• Mọi lần posture fail đều được log.
• SOC mở ticket triage cho mỗi sự cố red-score.
• Rà soát hàng tháng: tỉ lệ false positive, thời gian khắc phục.

---

Posture phân tầng: truy cập theo tier

Không phải người dùng nào cũng cần full posture. Phân tầng theo rủi ro:

Tier 1: Thiết bị công ty quản lý đầy đủ

Posture: WARP + EDR + MDM compliant + đĩa mã hóa + firewall + serial trong danh sách.

Truy cập: tất cả ứng dụng gồm crown jewel (prod, finance, HR detail).

Tier 2: BYOD với posture một phần

Posture: WARP + đĩa mã hóa + firewall (không EDR/MDM).

Truy cập: ứng dụng năng suất (email, wiki, calendar). KHÔNG prod, KHÔNG hệ thống finance.

Tier 3: Khách / fail posture

Posture: chỉ WARP đã enroll, không check sâu hơn.

Truy cập: chỉ thông tin công khai. Trang login kèm hướng dẫn khắc phục.

Ví dụ policy

- application: "prod-admin"
  policies:
    - action: allow
      require:
        - posture: ["corp-baseline", "crowdstrike-green", "mdm-compliant"]

- application: "company-wiki"
  policies:
    - action: allow
      require:
        - posture: ["warp-enrolled", "firewall-on"]

- application: "public-info"
  policies:
    - action: allow
      include:
        - email_domain: "company.com"

Tăng dần: người dùng không đủ posture cho ứng dụng cao vẫn truy cập ứng dụng thấp, IT từ từ cải thiện thiết bị.

---

Cân nhắc bảo mật

Giả mạo posture

Người dùng có quyền admin nội bộ có thể:

• Giả trạng thái posture WARP.
• Tắt EDR âm thầm.
• Chỉnh registry key.

Giảm nhẹ:

• Kiểm tra chống giả mạo của WARP: xác nhận tính toàn vẹn binary.
• EDR tự bảo vệ: agent không thể đóng.
• Kết hợp nhiều tín hiệu: khó giả mạo cùng lúc.
• Giám sát: thiết bị bỗng dưng xanh hoàn toàn sau thời gian dài đỏ là đáng nghi.

Agent EDR là mục tiêu tấn công

EDR có đặc quyền cao. Bypass EDR là kiểm soát thiết bị. Playbook APT đã biết:

• Tắt dịch vụ EDR.
• Gỡ agent (nếu có quyền admin).
• Rootkit mức kernel.

Giảm nhẹ:

• EDR chống giả mạo + tự phục hồi.
• Cảnh báo khi agent mất kết nối > 10 phút.
• Kết hợp EDR với giám sát hành vi (“bỗng dưng khỏe” là không thể).

Quyền riêng tư dữ liệu posture

Posture check thu thập OS, trạng thái đĩa, danh sách ứng dụng, có thể nhạy cảm quyền riêng tư đặc biệt với BYOD.

Hướng dẫn:

• Ghi rõ trong thông báo quyền riêng tư thứ gì được thu thập.
• BYOD: thu tối thiểu (phiên bản OS, mã hóa đĩa, firewall). Bỏ qua kiểm kê ứng dụng.
• EDR: chỉ cho thiết bị công ty. EDR trên BYOD vượt lằn ranh quyền riêng tư.
• Lưu giữ: kết quả posture tối đa 30-90 ngày.

Fail-open vs fail-closed

EDR cloud outage khiến CF không kéo được posture. Quyết định:

• Fail closed: từ chối mọi thứ dựa trên tín hiệu EDR. An toàn nhưng ảnh hưởng vận hành.
• Fail open: cho phép kèm cảnh báo. Ít an toàn nhưng duy trì hoạt động.
• Kết hợp: ứng dụng quan trọng fail closed, ứng dụng chung fail open với log tăng cường.

Chọn theo mức nhạy cảm của từng ứng dụng, không áp dụng chung.

Ánh xạ compliance

• NIST CSF: PR.AC-1 (identities managed), PR.DS-1 (data at rest protected), PR.IP-12 (vulnerability management).
• ISO 27001: A.8.1 (asset inventory), A.8.9 (secure config), A.8.16 (monitoring).
• CIS 18: Control 4 (secure config enterprise assets), Control 10 (malware defenses).
• PCI DSS 4.0: 5.x (malware protection), 2.x (secure config).

---

Truy nguyên

”Người dùng fail posture nhưng khẳng định thiết bị OK”

1. Dashboard → Device posture → từng thiết bị, xem trạng thái mỗi kiểm tra.
2. Xác định kiểm tra đang fail, tín hiệu cụ thể.
3. Phổ biến: agent EDR đang cập nhật, WARP tạm mất kết nối, firewall bị ứng dụng tắt (Zoom, Teams trong dev).
4. Người dùng khắc phục theo hướng dẫn, posture kiểm tra lại 1-5 phút, truy cập khôi phục.

”Tích hợp EDR không kéo được dữ liệu”

• Xác nhận credentials API còn hợp lệ (admin EDR có thể đã xoay khóa).
• Kiểm tra quota API EDR chưa vượt.
• Cloudflare → trang trạng thái tích hợp: xem lần kéo thành công gần nhất.
• Phía EDR: xác nhận thiết bị đã enroll (agent đã đăng ký?).

”Đánh giá liên tục quá mạnh tay, người dùng bị đăng xuất thường xuyên”

• TTL session quá ngắn (5 phút) cho sử dụng thông thường.
• Tăng lên 30-60 phút, kèm purge-on-posture-fail thay thế.
• Cân bằng: ngắn hơn = an toàn hơn; dài hơn = ít ma sát hơn.

”Posture check chậm, trang đăng nhập bị trễ”

• Kiểm tra đồng bộ lúc đăng nhập: mỗi kiểm tra tuần tự, chậm.
• Cloudflare chạy song song; kiểm tra chậm có thể do đường mạng tới nhà cung cấp.
• Giảm số kiểm tra lúc đăng nhập, thực hiện đánh giá posture bất đồng bộ sau đăng nhập.

”Cảnh báo sai EDR điểm đỏ, thiết bị khỏe mạnh”

• Nhà cung cấp EDR có thể đánh dấu phần mềm công ty hợp pháp.
• Thêm ngoại lệ EDR (nói với admin EDR).
• Tạm ghi đè policy: cho phép thiết bị trong khi điều tra.
• Theo dõi tỉ lệ cảnh báo sai hàng tháng: > 5% = nhiễu.

---

Đánh đổi và quyết định thiết kế

Quyết định	Phương án A	Phương án B	Khuyến nghị
TTL session	24h (legacy)	15 phút (Zero Trust)	30-60 phút kèm kiểm tra lại posture + purge on fail.
Chế độ fail của EDR	Fail open	Fail closed	Theo tier ứng dụng: quan trọng đóng, chung mở + log.
Độ sâu posture BYOD	Đầy đủ (EDR)	Tối thiểu (firewall + disk)	Tối thiểu. EDR trên BYOD là cờ đỏ quyền riêng tư.
Posture provider	Một (chỉ EDR)	Kết hợp nhiều	Kết hợp, khó giả mạo hơn, chịu được nhà cung cấp outage.
Khắc phục	Ticket thủ công	Script tự động	Tự động cho vấn đề phổ biến (khởi động lại EDR), thủ công cho ca lạ.
Cách ly	MDM khoá	MDM xoá	Khoá + điều tra; xoá chỉ khi đã xác nhận xâm nhập + người dùng chấp nhận mất hoạt động.

---

Danh sách kiểm tra: posture liên tục trên production

Đường cơ sở:

• WARP đã enroll trên tất cả thiết bị được quản lý.
• Các kiểm tra có sẵn của WARP đã định nghĩa (OS, disk, firewall, serial).
• Danh sách serial nhập từ MDM + quy trình xoay.

EDR:

• Tích hợp EDR đã cấu hình (Crowdstrike, SentinelOne, Defender).
• Lịch xoay credential API.
• Chế độ fail định nghĩa theo tier ứng dụng.
• Giám sát quota API.

Access policy:

• Policy Tier 1 (công ty) yêu cầu posture đầy đủ.
• Policy Tier 2 (BYOD) với posture tối thiểu.
• Policy Tier 3 (khách) tối thiểu.
• TTL session 30-60 phút cho ứng dụng quan trọng.
• Bật Purge-on-posture-fail.

Phản ứng:

• Tự động thu hồi đã kiểm chứng.
• Mẫu thông báo người dùng.
• Runbook SOC cho posture đỏ.
• Tích hợp MDM cho cách ly.
• Hướng dẫn khắc phục đã công bố.

Giám sát:

• Logpush kết quả posture về SIEM.
• Dashboard: tỉ lệ pass, top lý do fail.
• Cảnh báo: agent EDR mất kết nối > 10 phút mỗi người dùng.
• Cảnh báo: posture fail tăng đột biến mỗi nhóm.
• Theo dõi tỉ lệ cảnh báo sai.

Tài liệu:

• Cập nhật thông báo quyền riêng tư.
• Chính sách BYOD rõ ràng.
• FAQ khắc phục cho người dùng.
• Runbook: triage “posture fail”.

---

Bài học thực tế

• Bắt đầu tối thiểu, siết chặt dần. Ra mắt với 3-5 kiểm tra, thêm theo dữ liệu. Gánh nặng ngay từ đầu sẽ gây ma sát + tải helpdesk.
• Tích hợp EDR là kiểm tra ROI cao nhất. Kiểm tra có sẵn tĩnh; EDR động, bắt threat thời gian thực. Đầu tư đáng.
• Rút ngắn TTL session khiến người dùng phản ứng mạnh. 24h xuống 30 phút = sóng ticket helpdesk tuần đầu. Truyền thông + chia giai đoạn rất quan trọng.
• Độ sâu posture BYOD là gai. Kiểm tra đầy đủ vượt lằn ranh quyền riêng tư. Kiểm tra tối thiểu thì tín hiệu yếu. Phân tầng truy cập là thỏa hiệp lành mạnh.
• Nhà cung cấp EDR sẽ có outage. Chế độ fail định trước, không phải trong sự cố. Kiểm thử fail open vs closed hàng quý.
• Log posture chứa dữ liệu cận PII. Lưu giữ + kiểm soát truy cập. Đừng chia sẻ log posture rộng.
• Rà soát chính sách posture hàng quý. Tính năng EDR mới, phiên bản OS mới, threat mới, cập nhật rule. Posture cũ chỉ là bảo mật trình diễn.
• Đo cảnh báo sai liên tục. Người dùng bị chặn oan nhiều hơn thật sẽ tìm đường vòng. 2-3% cảnh báo sai chấp nhận được; 10%+ là phải chỉnh rule.

---

Kết luận

Device posture là “verify” trong “never trust, always verify”. Xác thực cho biết “ai”; posture cho biết “trạng thái máy”. Kết hợp + liên tục = Zero Trust thực sự.

Công thức production:

• Kiểm tra có sẵn của WARP làm đường cơ sở (rẻ, rộng).
• Tích hợp EDR cho tín hiệu động (Crowdstrike/SentinelOne/Defender).
• Webhook tuỳ chỉnh khi nhà cung cấp không được hỗ trợ.
• TTL session ngắn + purge-on-fail cho đánh giá liên tục.
• Phân tầng truy cập theo mức posture: không áp dụng một khuôn cho tất cả.

Nếu phải nhớ một câu:

Xác thực là câu hỏi “ai?” hỏi một lần. Device posture là câu hỏi “bạn còn đáng tin không?” hỏi mỗi phút. Bỏ posture là Zero Trust chỉ có một chân.

Đến đây Part 16 đóng block Observability & Ops.

Series sẽ tiếp tục với block Advanced Security: Browser Isolation, CASB, DLP, Email Security (Area 1), mỗi bài đi sâu vào một khả năng.

---

Tài liệu tham khảo

• Device posture overview
• WARP native posture checks
• Crowdstrike Falcon ZTA
• SentinelOne integration
• Intune integration
• Service-to-service webhook

Trong series này:

• ← Part 15: DEX
• Tiếp theo → Part 17: Browser Isolation (RBI)
• Xem toàn bộ: Series Cloudflare One Handbook