# Sử dụng nhật ký khi điều tra sự cố

### Mục tiêu <a href="#mc-tiu" id="mc-tiu"></a>

Hướng dẫn Admin cách dùng nhật ký đăng nhập và nhật ký hoạt động để điều tra sự cố (mất dữ liệu, lỗi cấu hình, nghi ngờ bảo mật).

Định hình quy trình kiểm tra định kỳ (audit) nhằm phát hiện sớm sai sót, thao tác sai quy trình, hoặc rủi ro bảo mật.

***

### Dành cho ai <a href="#dnh-cho-ai" id="dnh-cho-ai"></a>

Org Admin / Chủ site – chịu trách nhiệm cuối cùng về an toàn dữ liệu và cấu hình hệ thống.

Admin hệ thống / IT / Security – trực tiếp dùng nhật ký để điều tra, audit, và đề xuất cải tiến chính sách bảo mật.

***

### Khi nào dùng <a href="#khi-no-dng" id="khi-no-dng"></a>

Khi xảy ra sự cố:

* User bị vô hiệu hóa mà không rõ lý do.
* Thay đổi quyền truy cập gây lỗi nghiệp vụ.
* Dữ liệu bị xóa/chỉnh sửa bất thường.
* Nghi ngờ tài khoản bị lộ hoặc truy cập trái phép.

Định kỳ (hàng tuần/tháng/quý) để kiểm tra sức khỏe bảo mật và vận hành hệ thống qua nhật ký.

***

### Hướng dẫn <a href="#hng-dn" id="hng-dn"></a>

#### 1. Điều tra sự cố với nhật ký đăng nhập <a href="#id-1-iu-tra-s-c-vi-nht-k-ng-nhp" id="id-1-iu-tra-s-c-vi-nht-k-ng-nhp"></a>

Bước này trả lời câu hỏi: Ai đã đăng nhập, khi nào, có bất thường không?

* Vào Thông báo và nhật ký quản trị → Nhật ký → Nhật ký đăng nhập.
* Lọc theo:
  * Tài khoản nghi ngờ (user cụ thể).
  * Khoảng thời gian sự cố (ví dụ: 2–3 giờ trước khi phát hiện lỗi).

Kiểm tra:

* Thời điểm đăng nhập gần nhất (last login).
* Có nhiều lần đăng nhập thất bại liên tiếp không (gợi ý brute-force hoặc quên mật khẩu).
* Đăng nhập có trùng khung giờ người dùng khẳng định không thao tác không.

Kết luận có thể:

* Nếu có đăng nhập từ thời điểm người dùng nói “không dùng”: khả năng tài khoản bị lộ hoặc bị dùng sai.
* Nếu không có đăng nhập nhưng lại có thay đổi dữ liệu: cần kiểm tra nhầm user, hoặc các tác nhân khác (job, script, quyền ẩn).

#### 2. Điều tra sự cố với nhật ký hoạt động quản trị <a href="#id-2-iu-tra-s-c-vi-nht-k-hot-ng-qun-tr" id="id-2-iu-tra-s-c-vi-nht-k-hot-ng-qun-tr"></a>

Bước này trả lời câu hỏi: User đó đã làm gì trên hệ thống?

* Vào Thông báo và nhật ký quản trị → Nhật ký → Nhật ký tổng hợp / Nhật ký hoạt động người dùng.
* Lọc theo:
  * Người dùng: tài khoản nghi ngờ hoặc các Admin liên quan.
  * Thời gian: cùng khoảng với bước 1 (trước và sau khi phát hiện sự cố).
  * Loại hành động (nếu có filter): thay đổi user, nhóm quyền, cấu hình bảo mật, thao tác dữ liệu.

Đối chiếu sự cố với log:

* Nếu user A bị vô hiệu hóa: log sẽ cho biết user B (Admin nào) đã disable A, lúc nào.
* Nếu quyền truy cập thay đổi: log thể hiện thay đổi nhóm quyền/quyền doctype liên quan.
* Nếu dữ liệu bị xóa: log cho thấy ai xóa, xóa gì, khi nào, từ đó kiểm tra thêm Thùng rác/backup.

Khi nghi ngờ bảo mật, kết hợp:

* Nhật ký đăng nhập: có đăng nhập lạ?
* Nhật ký hoạt động: tài khoản đó đã làm gì sau khi đăng nhập?

#### 3. Kiểm tra định kỳ (audit) bằng nhật ký <a href="#id-3-kim-tra-nh-k-audit-bng-nht-k" id="id-3-kim-tra-nh-k-audit-bng-nht-k"></a>

Mục tiêu: phát hiện sai sót trước khi thành sự cố lớn.

Gợi ý tần suất và nội dung kiểm tra:

* **Hàng tuần – Admin hệ thống:**
  * Xem nhanh nhật ký hoạt động:
    * Có thay đổi nào về nhóm quyền, phân quyền doctype bất thường không.
    * Có thao tác tạo/xóa user, vô hiệu hóa tài khoản ngoài kế hoạch không.
* **Hàng tháng – Org Admin/IT/Security:**
  * Rà nhật ký:
    * Thay đổi chính sách bảo mật (2FA, IP whitelist, session, mật khẩu).
    * Thay đổi cấu hình chung hệ thống (backup retention, quota…).
  * Đối chiếu với quy trình nội bộ (ticket, yêu cầu thay đổi) để xem có thao tác nào không có yêu cầu chính thức.
* **Sau mỗi lần triển khai thay đổi lớn (bật 2FA, đổi policy, nâng app):**
  * Dùng nhật ký để kiểm tra:
    * Chính sách đã được chỉnh đúng như thiết kế.
    * Không có thay đổi “ngoài dự tính” quanh thời điểm triển khai.

***

### Lưu ý <a href="#lu" id="lu"></a>

Nhật ký nên được coi là nguồn sự thật khi điều tra: mọi quyết định xử lý (khóa user, khôi phục dữ liệu) nên dựa vào log + xác minh người dùng, không chỉ dựa vào lời kể.

Không nên cho phép xóa log nhật ký quản trị qua UI; nếu cần retention, nên làm ở mức hạ tầng và có chính sách riêng, để đảm bảo tính toàn vẹn audit.

Khi phát hiện thao tác trái quy trình (ví dụ Admin tự ý đổi quyền), nên ghi nhận sự cố, cập nhật quy trình nội bộ, và cân nhắc siết phân quyền hoặc thêm bước phê duyệt cho các thay đổi nhạy cảm.

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mhiring.vn/mbase/mbw-admin/thong-bao-va-nhat-ky-quan-tri/su-dung-nhat-ky-khi-dieu-tra-su-co.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.