Trong thế giới kỹ thuật số ngày nay, việc bảo vệ danh tính trong một tổ chức là vô cùng quan trọng. Các tội phạm mạng không ngừng tìm cách xâm nhập, không chỉ cố gắng phá vỡ hệ thống tường lửa kiên cố của tổ chức mà còn cố gắng nhắm vào chính danh tính của người dùng. Microsoft Entra ID Protection là một công cụ mạnh mẽ bên cạnh Entra ID, Defender for Identity giúp phát hiện và ngăn chặn các cuộc tấn công này bằng cách xác định các hoạt động đáng ngờ.
Tầm quan trọng của tích hợp danh tính vào Defender XDR
Trong chiến lược Zero Trust, danh tính người dùng được xem như vòng phòng thủ bảo mật mới. Việc bảo vệ danh tính giờ đây không chỉ dừng ở xác thực mạnh như sử dụng mật khẩu phức tạp, xác thực đa yếu tố (MFA) mà còn cần được giám sát liên tục và phản ứng kịp thời trước các dấu hiệu xâm nhập.
Do đó, việc tích hợp Microsoft Entra ID Protection với hệ sinh thái Defender XDR (Extended Detection and Response) cho phép kết hợp sức mạnh của việc bảo vệ danh tính với các công cụ phát hiện, phản ứng nâng cao. Cách tiếp cận này mang đến nhiều lợi ích:
- Phát hiện sớm và phản ứng nhanh hơn đối với tấn công danh tính: Thay vì để các cảnh báo danh tính nằm riêng lẻ, chúng sẽ được quản lý tập trung trong các cảnh báo và sự cố bảo mật. Chẳng hạn, các cảnh báo có mức đăng nhập rủi ro cao từ Entra ID Protection sẽ xuất hiện như một phần của sự cố trong Microsoft Defender XDR. Nhờ đó, nếu tài khoản người dùng bị xâm phạm, hệ thống XDR có thể tự động thực hiện hành động khẩn cấp như cô lập thiết bị liên quan hoặc vô hiệu hóa tài khoản người dùng ngay lập tức.
- Tăng cường tự động hóa và hành động chủ động: Microsoft XDR cung cấp tính năng Automatic Attack Disruption (tự động phá vỡ tấn công). Đây là một năng lực AI tự động phản ứng khi phát hiện chuỗi tấn công. Nhờ tích hợp với Entra ID, cơ chế này có thể thực thi các hành động liên quan đến danh tính mà không cần chờ con người. Ví dụ, tự động khóa tài khoản nghi bị chiếm quyền hoặc buộc đặt lại mật khẩu khi phát hiện dấu hiệu rõ ràng về xâm nhập. Đặc biệt, Defender XDR thông qua Defender for Identity có thể vô hiệu hóa đồng thời tài khoản trên Active Directory và Entra ID nếu người dùng hybrid bị tấn công.
- Giảm thiểu lỗ hổng do công cụ rời rạc: Ở nhiều doanh nghiệp, hệ thống an ninh mạng truyền thống thường tách biệt: nhóm quản lý tài khoản (AD/Entra ID) làm việc trên cổng Entra ID, còn nhóm SOC giám sát trên SIEM hoặc các bảng điều khiển khác. Sự rời rạc này dễ khiến cảnh báo bị bỏ sót hoặc chậm phản ứng. Bằng cách tích hợp Entra ID Protection với XDR (bao gồm cả Microsoft Sentinel), doanh nghiệp có tầm nhìn hợp nhất khi mọi tín hiệu rủi ro về danh tính đều được liên kết với các tín hiệu khác như báo động từ thiết bị, email, ứng dụng đám mây,…. Như vậy, đội an ninh có ngữ cảnh đầy đủ để đánh giá mức độ nghiêm trọng và phản ứng nhanh, trong khi đội quản trị danh tính cũng thấy rõ bức tranh tổng thể.
- Đơn giản hóa tuân thủ và phân tích bảo mật: Việc tích hợp cũng hỗ trợ mục tiêu tuân thủ quy định và điều tra sau sự cố. Toàn bộ dữ liệu rủi ro danh tính (như log các đăng nhập rủi ro, log thay đổi trạng thái người dùng rủi ro) có thể được gửi sang Microsoft Sentinel, nền tảng SIEM/SOAR của Microsoft, để lưu trữ và phân tích lâu dài. Tại Sentinel, tổ chức có thể viết quy tắc nâng cao (kết hợp nhiều nguồn log) để dò tìm hành vi bất thường phức tạp, hoặc tự động kích hoạt kịch bản phản hồi (SOAR playbook) khi nhận cảnh báo từ Entra ID Protection (ví dụ: tạo ticket trong ITSM, nhắn tin cảnh báo,…) Ngoài ra, tích hợp Entra ID với Microsoft Purview (bộ giải pháp quản trị dữ liệu và tuân thủ) đang dần hình thành khi thông tin về người dùng rủi ro cao có thể được Purview Insider Risk Management sử dụng để tăng độ ưu tiên theo dõi nhân sự đó. Ví dụ một nhân viên bị đánh giá rủi ro cao do đăng nhập lạ sẽ bị Purview giám sát chặt hơn nếu họ tải xuống dữ liệu nhạy cảm. Ngược lại, nếu Purview phát hiện một người dùng có hành vi nội bộ đáng ngờ, thông tin đó cũng có thể góp phần đánh giá rủi ro danh tính. Sự chia sẻ chéo dữ liệu giữa các thành phần Entra, Defender, Purview tạo nên bức tranh toàn diện về rủi ro, từ danh tính đến thiết bị và dữ liệu.
Nhìn chung, tích hợp Entra ID Protection với XDR giúp doanh nghiệp chủ động hơn trước các đe dọa danh tính. Đặc biệt tại Việt Nam và châu Á, nơi nhiều doanh nghiệp vừa bước vào chuyển đổi số và còn hạn chế về nhân sự an ninh, một nền tảng hợp nhất, tự động hóa cao sẽ bù đắp thiếu hụt nguồn lực, đồng thời đối phó kịp thời với cuộc tấn công đang ngày một gia tăng.
Giấy phép và Vai trò để triển khai và quản lý Entra ID Protection
Giấy phép:
Để triển khai Microsoft Entra ID Protection, tổ chức cần tối thiểu giấy phép Microsoft Entra ID P2. Microsoft Entra ID Protection cũng thu nhận những tín hiệu từ Microsoft Defender cho một số phát hiện rủi ro, vì vậy tổ chức cũng cần có giấy phép phù hợp cho sản phẩm Microsoft Defender sở hữu tín hiệu này. Ví dụ:
- Microsoft Defender for Cloud Apps
- Activity from anonymous IP address
- Impossible travel
- Mass access to sensitive files
- New country
- Microsoft Defender for Office 365
- Suspicious inbox rules
- Microsoft Defender for Endpoint
- Possible attempt to access Primary Refresh Token
Microsoft 365 E5 có đầy đủ tất cả các tín hiệu trên.
Role (Vai trò)
ID Protection cần người dùng được gán một hoặc nhiều vai trò sau đây:
- Global Reader: chỉ có thể truy cập và đọc các thông tin trong ID Protection
- User Administrator: Có thể khôi phục mật khẩu người dùng
- Conditional Access Administrator: Xây dựng các chính sách trong đó có các điều kiện tính đến rủi ro người dùng hoặc rủi ro đăng nhập
- Security Reader: Xem tất cả báo cáo ID Protection và trang tổng thể (Overview)
- Security Operator: Xem tất cả báo cáo ID Protection và trang tổng thể (Overview), có thể thực hiện một số thao tác trên người dùng rủi ro như Dismiss user risk, confirm safe sign-in, confirm compromise.
- Security Administrator: Đầy đủ quyền trên ID Protection
Cách quản trị rủi ro của Entra ID Protection
Mô hình kim tự tháp trong quản trị rủi ro
Mọi rủi ro trong Entra ID đều được xây dựng dựa trên nhau theo một mô hình kim tự tháp trực quan, gồm 3 tầng:
- Tầng đáy – Tầng phát hiện rủi ro (Risk Detections)
- Đây là những tín hiệu riêng lẻ, những mảnh ghép nhỏ nhất như là đăng nhập từ 1 địa chỉ IP có liên quan đến mã độc, đăng nhập từ một trình duyệt Tor ẩn danh, thông tin đăng nhập bị rò rỉ,… Đây là dữ liệu thô mà hệ thống thu thập được. Một tín hiệu đơn lẻ như vậy có thể chỉ ở mức rủi ro thấp.
- Tầng giữa – Rủi ro đăng nhập (Sign-in risk)
- Tầng này được hình thành khi các phát hiện rủi ro thời gian thực được quan sát trong một phiên đăng nhập cụ thể. Khi nhiều rủi ro được phát hiện trong cùng một phiên đăng nhập, chúng sẽ được tổng hợp lại và tạo nên một sự kiện đăng nhập rủi ro cao. Ví dụ một người dùng đăng nhập trên một địa điểm chưa từng thấy trên một thiết bị lạ, và từ một IP có dấu hiệu đáng ngờ. Khi gộp 3 tín hiệu này lại thì độ tin cậy tăng lên đáng kể.
- Đỉnh kim tự tháp-Rủi ro người dùng (User Risk)
- Thể hiện trạng thái rủi ro tổng thể của người dùng theo thời gian. Nó là sự tổng hợp của tất cả các rủi ro đăng nhập cộng với các thông tin độc lập khác như thông tin đăng nhập của họ tìm thấy bị rò rỉ trên dark web.
Cấu trúc kim tự tháp này cung cấp kết luận chính xác thay vì chỉ đưa ra kết luận vội vàng chỉ từ một tín hiệu riêng lẻ.
Phân biệt phát hiện rủi ro thời gian thực (Real time) và Phát hiện rủi ro ngoại tuyến (Offline)
Microsoft phân tích hàng nghìn tỉ tín hiệu mỗi ngày từ các dịch vụ của họ như thông tin đăng nhập trên Entra ID, các mối nguy hiểm từ Microsoft Defender, các tín hiệu máy ảo trên Azure, hành vi người dùng trên Microsoft 365,….Bằng cách dựa trên những tín hiệu này, Microsoft xây dựng một đường cơ sở (baseline) những gì gọi là bình thường và những gì đi chệch đi khỏi quỹ đạo đường cơ sở này có thể được xem là rủi ro.
Để hiểu rõ hơn về nền tảng của kim tự tháp, chúng ta cần phân biệt hai loại phát hiện rủi ro chính, dựa trên thời điểm chúng được tính toán.
Realtime: phát hiện ngay lập tức trong vòng vài giây, ngay khi người dùng đang đăng nhập. Ví dụ như đăng nhập từ một IP ẩn danh, hệ thống biết ngay IP này đáng ngờ và có thể hành động ngay như yêu cầu MFA trước khi cho truy cập.
Offline: cần nhiều thời gian và phân tích sâu hơn, nên thường diễn ra sau khi phiên đăng nhập đã hoàn tất. Ví dụ như atypical travel (di chuyển không điển hình), hệ thống không thể kết luận điều này chỉ từ một lần đăng nhập được. Ví dụ người dùng đăng nhập ở VN, sau đó 60 phút có đăng nhập ở Mỹ à đưa ra kết luận không thể có di chuyển như vậy về mặt vật lý. Dù phát hiện có độ trễ nhưng không hề vô ích khi sẽ ngay lập tức nâng mức độ rủi ro tổng thể của người dùng lên mức cao hơn. Và do đó ở lần đăng nhập tiếp theo của chính người dùng/kẻ tấn công ở bất cứ đâu sẽ đối mặt với chính sách đăng nhập nghiêm ngặt hơn.
Dưới đây là bảng so sánh Phát hiện thời gian thực (real-time) và Phát hiện ngoại tuyến (Offline)
| Phát Hiện Thời Gian Thực (Real time) | Phát Hiện Ngoại Tuyến (Offline) |
| Thời điểm tính toán:
Được tính toán trong khi một phiên đăng nhập đang diễn ra. Hệ thống đánh giá rủi ro ngay lập tức. |
Thời điểm tính toán:
Được xử lý sau khi một phiên đăng nhập đã hoàn tất. Quá trình này đòi hỏi phân tích một lượng lớn tín hiệu và cần nhiều thời gian hơn. |
| Tác động tức thì:
Có thể chặn hoặc yêu cầu khắc phục (như MFA) một phiên đăng nhập trước khi nó thành công. |
Tác động tức thì:
Không ảnh hưởng đến lần đăng nhập vừa xảy ra, mà nó sẽ làm tăng rủi ro tổng thể của người dùng cho lần đăng nhập tiếp theo. |
| Ví dụ: Địa chỉ IP ẩn danh; thuộc tính đăng nhập không quen thuộc | Ví dụ: Thông tin đăng nhập bị rò rỉ; Di chuyển bất khả thi (Impossible Travel) |
Microsoft cũng có mô hình học máy (machine learning) luôn sàng lọc dữ liệu tìm ra các mẫu tấn công mới mà chưa ai tìm thấy và mặt khác có các phát hiện do các chuyên gia an ninh Microsoft viết ra dưới dạng các quy tắc an ninh. Khi điều tra ra một cuộc tấn công thực tế và phát hiện ra một kỹ thuật tấn công mới của kẻ tấn công, họ sẽ tạo ra một quy tắc phát hiện kiểu tấn công đó và triển khai nó cho tất cả các khách hàng trên toàn cầu. Sự kết hợp này mang đến khả năng thích ứng của máy học và kinh nghiệm thực chiến của con người.
Triển khai các chính sách Conditional Access dựa trên rủi ro
Sau khi phát hiện các rủi ro, chúng ta sử dụng phòng thủ chủ động với Conditional Access. Dù bản thân Entra ID Protection cũng có sẵn một số chính sách nhưng Microsoft khuyến nghị các tổ chức nên sử dụng Conditional Access. Conditional Access cho phép chúng ta tạo ra các chính sách Nếu-Thì kết hợp nhiều các yếu tố với nhau, không chỉ dựa trên mỗi yếu tố rủi ro.
Truy cập Entra Admin Center https://entra.microsoft.com/, chọn ID Protection > Risk-based Conditional Access > New Policy from template.
Chuyển sang thẻ All sẽ thấy danh sách tất cả các chính sách Conditional Access. Một số template phù hợp để triển khai gồm:
- Require multifactor authentication for risky sign-ins
- Require password change for high-risk users
Mặc định các chính sách này áp dụng cho tất cả người dùng và tất cả ứng dụng trong tổ chức. Trong trường hợp muốn tùy chỉnh cho từng nhóm khác nhau có thể cấu hình các chính sách Conditional Access khác nhau cho từng nhóm người dùng, từng nhóm ứng dụng. Xem lại bài viết để biết cách cấu hình chính sách Conditional Access.
Triển khai Microsoft Entra ID Conditional Access – Master Learning Hub
Quản lý Entra ID Protection
Giao diện của Entra ID Protection sẽ gồm 4 chức năng chính là:
- Dashboard: trang quản lý tổng thể và xem được đầy đủ các thông tin về các cuộc tấn công đã ngăn chặn được (number of attacks blocked); thời gian trung bình để xử lý/khắc phục các người dùng có rủi ro cao (Mean time to remediate high risk users), số lượng người dùng đã bảo vệ được (Number of users protected); số lượng người dùng rủi ro cao (Number of high risk users); các đề xuất (Recommendations); các hoạt động rủi ro theo vị trí địa lý (risky activity by location)
Trang dashboard tổng thể của Identity Protection
Trang hiển thị các hoạt động rủi ro theo vị trí địa lý. Trong ảnh, những khu vực màu đỏ là các rủi ro ở mức trung bình trong vòng 1 tháng gần đây.
- Risk-based Conditional Access: triển khai danh sách các chính sách Conditional Access dựa trên rủi ro
- Risky Users: danh sách các người dùng rủi ro
Danh sách người dùng rủi ro và mức độ rủi ro của họ.
- Risky workloads identities: danh sách các tài khoản dịch vụ (service principal) gặp rủi ro
Đối với mỗi phát hiện tài khoản người dùng rủi ro trên hệ thống, sẽ có 3 lựa chọn chính là:
- Confirm user(s) compromised: xác nhận tài khoản bị xâm phạm
- Dismiss user(s) risk: Xác nhận an toàn để báo cho hệ thống biết đây là một báo động giả (false positive)
- Confirm user(s) safe: Xác nhận người dùng an toàn, bỏ qua rủi ro chẳng hạn như khi đội an ninh nội bộ đang kiểm tra xâm nhập.
Những xác nhận này sẽ giúp hệ thống học hỏi và thông minh hơn; giảm thiểu được báo động giả.
Cấu hình thông tin nhận email về Identity Protection
Chức năng Identity Protection cho phép cấu hình quản trị viên có thể nhận các thông tin về các rủi ro danh tính của người dùng. Mặc định các quyền Global Administrator, Security Administrator, Security Reader sẽ có thể nhận được email này, và có thể cấu hình thêm email của quản trị viên khác. Chọn mức độ rủi ro muốn nhận cảnh báo ở phần Alert on user risk level at or above. Đề xuất nên chọn Medium để nhận thông báo khi có rủi ro từ trung bình trở lên.
Mỗi tuần một báo cáo tổng hợp sẽ được gửi đến quản trị viên. Truy cập Identity protection chọn Settings > Weekly digest. Mặc định tất cả người dùng Global Admin, Security Admin, Security Reader sẽ nhận thông báo này. Có thể chuyển trạng thái từ Enabled sang Disabled để không nhận email cho từng người cụ thể; hoặc kích hoạt tùy chọn Send weekly digest emails sang No để không nhận email. Đề xuất luôn nhận email để hiểu rõ hơn trạng thái bảo mật danh tính của tổ chức.
Nhấn Save để lưu lại thông tin.
