arrow_backQuay lại ghi chép lĩnh vực
CLOUD Đã đăng 7 Aug 2026

Conditional Access và PIM thực sự dừng lại những cuộc tấn công như thế nào?

Phân tích thực tế về các chính sách Conditional Access và Privileged Identity Management, và cách chúng đóng lại các khoảng trống mà các chính sách mật khẩu để lại.

Các chính sách mật khẩu dừng lại các cuộc tấn công đoán. Chúng không làm gì với một token phiên bị đánh cắp, một lời nhắc MFA bị lừa, hoặc một tài khoản quản trị dùng thường xuyên đã tồn tại với quyền Global Administrator trong hai năm. Conditional Access và Privileged Identity Management (PIM) là hai điều khiển Azure AD / Entra ID thực sự giải quyết những khoảng trống đó, và chúng hoạt động tốt nhất khi kết hợp.

Conditional Access đang làm gì dưới ngàn

Conditional Access là một công cụ if-this-then-that được đánh giá tại thời điểm đăng nhập. Phía "if" (signals) bao gồm thành viên nhóm/người dùng, trạng thái tuân thủ thiết bị, vị trí mạng, rủi ro đăng nhập (từ Identity Protection), ứng dụng được truy cập, và loại ứng dụng khách (trình duyệt so với giao thức cũ). Phía "then" (controls) bao gồm: yêu cầu MFA, yêu cầu thiết bị tuân thủ, yêu cầu ứng dụng khách được phê duyệt, chặn toàn bộ quyền truy cập, hoặc yêu cầu chấp nhận điều khoản sử dụng.

Một chính sách quan trọng ở hầu hết các tenant: chặn xác thực cũ. Các giao thức như POP, IMAP, và SMTP cũ hơn không hỗ trợ các thử thách MFA hiện đại, vì vậy chúng là điều đầu tiên mà các công cụ credential-stuffing thử. Kiểm tra các nhật ký đăng nhập được lọc theo "Client App = Other clients" trước khi bạn chặn — bạn thường sẽ tìm thấy một trình quét cũ hoặc một máy in đa chức năng cũ vẫn xác thực bằng xác thực cơ bản.

Cái thứ hai đáng có từ ngày đầu: yêu cầu MFA cho tất cả người dùng, phạm vi với một nhóm loại trừ chỉ dành cho các tài khoản break-glass. Đừng phạm vi MFA chỉ cho "quản trị viên". Các tài khoản người dùng tiêu chuẩn bị xâm phạm là cách những kẻ tấn công có được chân đứng đầu tiên trước khi thậm chí bắt đầu leo thang đặc quyền.

Rủi ro đăng nhập so với rủi ro người dùng — các signal khác nhau, các phản ứng khác nhau

Identity Protection (một phần của Entra ID P2) tạo ra hai điểm số rủi ro riêng biệt và dễ dàng nhầm lẫn chúng:

  • Rủi ro đăng nhập — nỗ lực xác thực cụ thể này trông bất thường (du lịch bất khả thi, IP ẩn danh, các thuộc tính đăng nhập không quen thuộc).
  • Rủi ro người dùng — tài khoản này đã được đánh dấu vì một lý do liên quan đến bản thân danh tính (thông tin đăng nhập bị rò rỉ được tìm thấy trong ngữ liệu kho breach, hoạt động xâm phạm được xác nhận).

Một chính sách Conditional Access phản ứng với rủi ro đăng nhập thường nên thử thách bằng MFA — nếu người dùng thực có thể hoàn thành thử thách, hãy để họ qua. Một chính sách phản ứng với rủi ro người dùng nên buộc phải đặt lại mật khẩu, vì MFA một mình không giúp được nếu thông tin đăng nhập đã bị đốt cháy.

Tại sao quyền truy cập quản trị dùng thường xuyên lại là vấn đề lớn hơn

Thậm chí với Conditional Access chắc chắn, một tài khoản giữ Global Administrator vĩnh viễn là mục tiêu ngồi rõ ràng trong thư mục. Bất kỳ ai xâm phạm nó đều kế thừa toàn bộ quyền kiểm soát tenant mà không cần bước bổ sung nào. PIM loại bỏ phần "vĩnh viễn".

Với PIM, các vai trò quản trị được gán là eligible thay vì active. Người dùng phải rõ ràng kích hoạt vai trò, điều này kích hoạt một yêu cầu biện minh bắt buộc, quy trình phê duyệt tùy chọn, xác nhận lại MFA, và một cửa sổ có giới hạn thời gian — thường là 1 đến 8 giờ — sau đó vai trò tự động bị hủy kích hoạt. Không ai, kể cả chủ sở hữu tài khoản, có Global Admin dùng thường xuyên trừ khi họ đang sử dụng nó.

Một cấu hình PIM tối thiểu thực sự có thể sử dụng được

  • Mọi vai trò trên Helpdesk Administrator: eligible, không vĩnh viễn.
  • Global Administrator và Privileged Role Administrator: yêu cầu phê duyệt từ quản trị viên thứ hai, không chỉ tự kích hoạt.
  • Kích hoạt MFA bắt buộc, không có ngoại lệ.
  • Thời lượng kích hoạt tối đa 4 giờ buộc mọi người phải kích hoạt lại cho các phiên làm việc riêng biệt thực sự, điều này cũng tạo ra các vết kiểm toán sạch hơn.
  • Đánh giá quyền truy cập mỗi 90 ngày trên tất cả các bài tập eligible — tài khoản được thêm cho một dự án và không bao giờ được xóa nếu không.

Nơi các đội làm sai điều này

Lỗi phổ biến nhất không phải là thiết kế chính sách, mà là danh sách loại trừ. Một chính sách Conditional Access với một nhóm "loại trừ những người dùng này vì ứng dụng không hỗ trợ MFA" ngày càng tăng cuối cùng sẽ loại trừ nửa tenant. Theo dõi các loại trừ như một mục nhật ký công việc với chủ sở hữu và ngày loại bỏ, không phải một bucket vĩnh viễn.

Lỗi thứ hai là các tài khoản break-glass không thực sự được kiểm tra. Hai tài khoản khẩn cấp, loại trừ khỏi Conditional Access và PIM, với mật khẩu ngẫu nhiên dài được lưu trữ ngoại tuyến và cảnh báo về bất kỳ đăng nhập nào — và ai đó nên cố gắng đăng nhập vào chúng hàng quý để xác nhận chúng vẫn hoạt động.

Conditional Access và PIM không phải là một hộp kiểm cho kiểm tra tuân thủ. Chúng là sự khác biệt giữa một thông tin đăng nhập bị lừa là một phiền toái và nó là một sự xâm phạm toàn bộ tenant. Nếu bạn đang lập bản đồ các điều khiển danh tính như một phần của bản dựng Blue Team, các phân đoạn Cloud và Blue Team của Korra Studio bao gồm phía phát hiện — các sự kiện rủi ro Identity Protection thực sự trông như thế nào trong Sentinel và cách cảnh báo về các mẫu kích hoạt PIM bất khả thi.

Viết với hỗ trợ của AI, được xem xét và đăng bởi Michal Pilch (CISSP), Korra Studio.

Sẵn sàng đi xa hơn?

Đây là một ghi chép từ cơ sở kiến thức Korra Studio — nền tảng kết hợp mỗi chủ đề với phiên hỗ trợ 1-kèm-1.

Bắt đầu miễn phíarrow_forward