Trong nhịp độ đào tạo 6 ngày mỗi tuần của chương trình, nếu Ngày 1 (W01-L01) thiết lập nền tảng lý thuyết mạng, Ngày 2–3 (W01-L02, W01-L03) thực hành dựng lab và bắt gói tin có hướng dẫn, Ngày 4 (W01-L04) nâng độ khó với bài toán đối chiếu kết quả quét cổng bên ngoài và các trường hợp dương tính giả, thì *Ngày 5 (W01-L05) chuyển trọng tâm sang năng lực Kiểm toán Hệ điều hành và Rà soát Chất lượng Kỹ thuật (Review & QA Governance — 1.0 giờ lý thuyết, 1.0 giờ thực hành lab, 1.5 giờ quản trị & rà soát nhóm). Ở bài W01-L04, thông qua lệnh ss -tulnp và Get-NetTCPConnection, chúng ta đã biết tiến trình nào đang giữ socket lắng nghe trên cổng :443, :8080, :5432 hay :445. Tuy nhiên, một câu hỏi kiến trúc sâu hơn lập tức xuất hiện: Nếu kẻ tấn công gửi một yêu cầu độc hại đi qua cổng :443 của Nginx hoặc cổng :8080 của Gunicorn, tiến trình đó đang chạy dưới danh nghĩa tài khoản người dùng nào, được phép đọc/ghi những tệp tin nào trên đĩa cứng, và hệ thống nhật ký sẽ ghi lại dấu vết gì?* Để trả lời câu hỏi này và đủ năng lực thẩm định báo cáo của các thành viên trong nhóm, Technical Lead phải nắm vững cơ chế phân quyền tiến trình, tài khoản dịch vụ và nhật ký sự kiện của cả Linux lẫn Windows [8] [23] .

Khi một bệnh nhân (Client) đến quầy tiếp nhận (Nginx Reverse Proxy), nhân viên lễ tân chỉ có thẻ ra vào sảnh chính (www-data) và chuyển hồ sơ bệnh án qua cửa sổ nội bộ cho bác sĩ khám bệnh (Gunicorn App chạy dưới tài khoản appsvc). Bác sĩ khám bệnh lại gửi phiếu yêu cầu xét nghiệm cho kho lưu trữ hồ sơ y tế (PostgreSQL Database chạy dưới tài khoản postgres). Mỗi người chỉ giữ đúng chiếc chìa khóa mở ngăn tủ thuộc phận sự của mình (Nguyên tắc Đặc quyền Tối thiểu — Least Privilege), và mọi lần quẹt thẻ mở cửa đều được ghi nhận tự động vào hộp đen an ninh kèm giờ quốc tế UTC (Windows Event Logs / Linux journald).

Trên hệ điều hành Linux (F01-linux-srv — 192.168.56.20), mọi tiến trình dịch vụ và tệp tin đều chịu sự chi phối của *Kiểm soát Truy cập Tự định (POSIX Discretionary Access Control — DAC) kết hợp với các cơ chế thu hẹp khả năng của nhân hệ điều hành (Linux Capabilities & systemd Sandboxing) [8] [9] . Mỗi tiến trình đang chạy mang hai nhóm định danh cốt lõi: Định danh Thực (Real UID/GID — $u_{\text{real}}, g_{\text{real}}$) cho biết ai là người khởi chạy tiến trình, và Định danh Hiệu lực (Effective UID/GID — $u_{\text{eff}}, g_{\text{eff}}$)* là con số duy nhất mà nhân Linux dùng để quyết định cấp hay từ chối quyền truy cập tài nguyên.

Mỗi đối tượng tệp hoặc thư mục $f$ lưu trữ một vector siêu dữ liệu bảo mật gồm chủ sở hữu $u_f$, nhóm sở hữu $g_f$, và 12 bit chế độ phân quyền được chia thành 4 nhóm bát phân (octal digits): 3 bit đặc biệt $\left(b_{\text{suid}}, b_{\text{sgid}}, b_{\text{sticky}}\right)$ có giá trị trọng số $(4, 2, 1)$ ở hàng nghìn, cùng 3 bộ bit quyền hạn Đọc ($r=4$), Ghi ($w=2$), Thực thi ($x=1$) dành cho Chủ sở hữu ($M_{\text{user}}$), Nhóm ($M_{\text{group}}$) và Người khác ($M_{\text{other}}$) [10] . Khi một tiến trình có định danh hiệu lực $\left(u_{\text{eff}}, G_{\text{eff}}\right)$ yêu cầu tập thao tác $R \subseteq \{r, w, x\}$ trên tệp $f$, hàm quyết định cấp quyền của nhân hệ điều hành $\mathcal{A}_{\text{POSIX}}(u_{\text{eff}}, G_{\text{eff}}, f, R)$ được xác định theo thứ tự ưu tiên loại trừ nghiêm ngặt (không cộng dồn):

Phương trình Eq. (1) làm sáng tỏ ba cơ chế kỹ thuật mà mọi Technical Lead phải kiểm tra khi đọc baseline Linux: 1. Quy tắc khớp bậc thang không cộng dồn: Nhân Linux kiểm tra lần lượt từ User $\rightarrow$ Group $\rightarrow$ Other. Nếu một tiến trình khớp với chủ sở hữu tệp ($u_{\text{eff}} = u_f$), nhân chỉ xét duy nhất tập quyền $M_{\text{user}}$ và dừng lại ngay (kể cả khi $M_{\text{user}} = \emptyset$ và $M_{\text{other}} = \{r,w,x\}$, chủ sở hữu vẫn bị từ chối truy cập). 2. Tác động chuyển đổi định danh của bit SUID (04000) và SGID (02000): Khi tiến trình gọi hàm hệ thống execve() trên một tệp thực thi có bật bit SUID ($b_{\text{suid}} = 1$), nhân Linux lập tức gán định danh hiệu lực của tiến trình mới bằng chủ sở hữu của tệp đó ($u_{\text{eff}} \leftarrow u_f$). Nếu $u_f = 0$ (root) và tệp thực thi cho phép người dùng thường sửa đổi hoặc gọi shell con, đây là con đường leo thang đặc quyền trực tiếp [13] . 3. Đóng hộp dịch vụ bằng systemd và Linux Capabilities: Để ngăn chặn rủi ro một dịch vụ mạng bị xâm nhập có thể lạm dụng tệp SUID hoặc đọc dữ liệu của dịch vụ khác, các đơn vị dịch vụ hiện đại (/etc/systemd/system/*.service) áp dụng các chỉ thị khóa cứng ở tầng nhân [9] [11] [12] : - User= và Group=: Buộc tiến trình chạy dưới tài khoản phi đặc quyền riêng biệt (ví dụ www-data cho Nginx, appsvc cho Gunicorn, postgres cho PostgreSQL). - NoNewPrivileges=yes: Khóa chặt cờ PR_SET_NO_NEW_PRIVS trong nhân Linux, vô hiệu hóa hoàn toàn khả năng nâng quyền qua bất kỳ tệp SUID/SGID hay File Capabilities nào. - ProtectSystem=strict và ProtectHome=yes: Gắn kết (mount) toàn bộ cây thư mục hệ thống /usr, /boot, /etc ở chế độ chỉ đọc (read-only) và ẩn hoàn toàn /home, /root đối với không gian tên (mount namespace) của dịch vụ. - CapabilityBoundingSet=: Thu hồi các năng lực hạt nhân nguy hiểm (như CAP_SYS_ADMIN, CAP_NET_RAW, CAP_DAC_OVERRIDE), chỉ giữ lại đúng năng lực tối thiểu (ví dụ CAP_NET_BIND_SERVICE cho phép Nginx gắn vào cổng < 1024 mà không cần chạy dưới quyền root).

Trong khi Linux quản lý dịch vụ qua systemd và định danh số học UID/GID, hệ điều hành Windows Server (F01-win-trial — 192.168.56.30) quản lý các tiến trình nền thông qua *Trình điều khiển Dịch vụ (Service Control Manager — SCM, services.exe)* và mô hình bảo mật dựa trên đối tượng của nhân Windows NT [4] . Mọi cấu hình dịch vụ được lưu trữ bền vững trong nhánh Registry HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>, bao gồm đường dẫn tệp thực thi (ImagePath), chế độ khởi động (Start: 2 = Auto, 3 = Demand/Manual, 4 = Disabled), và tài khoản khởi chạy (ObjectName).

Khi SCM khởi chạy một dịch vụ, hệ thống xác thực cục bộ (LSASS) tạo ra một *Thẻ bài Truy cập (Access Token) gắn vào tiến trình dịch vụ. Access Token này chứa Mã định danh Bảo mật (Security Identifier — SID) của tài khoản dịch vụ, danh sách SID của các nhóm mà tài khoản đó trực thuộc, và danh sách Đặc quyền Hệ thống (Privileges*, ví dụ SeDebugPrivilege, SeImpersonatePrivilege, SeBackupPrivilege). Bốn loại tài khoản dịch vụ tiêu chuẩn trên Windows có ranh giới đặc quyền hoàn toàn khác nhau [4] [14] : - LocalSystem (NT AUTHORITY\System, SID S-1-5-18): Mức đặc quyền cao nhất trên máy chủ cục bộ (tương đương và thậm chí rộng hơn root vì có quyền truy cập nhân hệ điều hành và đồng thời sử dụng định danh tài khoản máy tính DOMAIN\ComputerName$ khi giao tiếp qua mạng SMB/RPC). - NetworkService (NT AUTHORITY\NetworkService, SID S-1-5-20): Tài khoản có đặc quyền cục bộ tối thiểu (tương đương người dùng thường Users), nhưng vẫn được phép sử dụng thông tin xác thực của máy tính khi kết nối ra mạng. - LocalService (NT AUTHORITY\LocalService, SID S-1-5-19):* Tài khoản có đặc quyền cục bộ tối thiểu và khi kết nối ra mạng chỉ sử dụng phiên ẩn danh (Anonymous session), giúp cô lập hoàn toàn khả năng lây lan ngang (lateral movement*). - *Tài khoản Dịch vụ Ảo (Virtual Service Account, NT SERVICE\<ServiceName>) và Group Managed Service Account (gMSA):* Mỗi dịch vụ có một SID riêng biệt (S-1-5-80-...), cho phép cấp quyền NTFS DACL chính xác cho từng dịch vụ đơn lẻ mà không cần quản lý mật khẩu thủ công.

Để lượng hóa rủi ro cấu hình sai của một tập hợp các dịch vụ $\mathcal{S}$ trên máy chủ (cả Windows và Linux), nếu gọi $\omega(s) \in [0, 1]$ là trọng số đặc quyền của tài khoản chạy dịch vụ $s$ (ví dụ $\omega = 1.0$ cho LocalSystem/root, $\omega = 0.5$ cho tài khoản dịch vụ chia sẻ, $\omega = 0.1$ cho tài khoản dịch vụ cô lập có bật NoNewPrivileges / Virtual Account), $\varepsilon_{\text{net}}(s) \in \{0, 1\}$ là chỉ báo dịch vụ có mở socket ra mạng ngoài hay không, và $\mu_{\text{acl}}(s) \in \{0, 1\}$ là chỉ báo tệp thực thi, tệp cấu hình hoặc khóa Registry của dịch vụ có cho phép tài khoản phi đặc quyền sửa đổi (Weak File/Service DACL hoặc Unquoted Service Path) hay không, thì *Chỉ số Phơi nhiễm Đặc quyền Dịch vụ (Service Privilege Exposure Index — $\mathcal{I}_{\text{priv}}$)* của dịch vụ $s$ được xác định bởi:

Trong phương trình Eq. (2) (với các hệ số khuếch đại rủi ro $\alpha = 1, \beta = 2$), một dịch vụ chỉ trở thành điểm yếu nghiêm trọng khi có sự giao thoa giữa đặc quyền cao ($\omega(s)$ lớn) và lỗi phân quyền kiểm soát truy cập ($\mu_{\text{acl}}(s) = 1$) hoặc phơi bày trực tiếp ra mạng ($\varepsilon_{\text{net}}(s) = 1$). Điều này giải thích tại sao một dịch vụ hệ thống chạy dưới quyền LocalSystem ($\omega = 1.0$) nhưng không mở cổng mạng ($\varepsilon_{\text{net}} = 0$) và có DACL khóa chặt chỉ cho TrustedInstaller/SYSTEM ghi ($\mu_{\text{acl}} = 0$) là hoàn toàn bình thường trong baseline của hệ điều hành, không phải là lỗ hổng bảo mật.

Một đường cơ sở hệ điều hành không thể tách rời khỏi *Đường cơ sở Nhật ký Kiểm toán (Audit & Telemetry Baseline*). Theo hướng dẫn quản lý nhật ký an toàn thông tin của NIST SP 800-92 [2] và các nghiên cứu về phát hiện xâm nhập qua Windows Event Logs của Fujimoto và cộng sự [15] , Visoottiviseth và cộng sự [17] [18] cùng Devabhaktuni và cộng sự [16] , mọi tương tác xác thực, khởi tạo tiến trình hoặc thay đổi dịch vụ đều để lại dấu vết có cấu trúc trên cả hai hệ điều hành: - Trên Windows (F01-win-trial — .30): Dịch vụ Windows Event Log (EventLog) ghi nhận sự kiện dưới định dạng nhị phân XML (.evtx) tại %SystemRoot%\System32\Winevt\Logs\, chia thành 3 kênh cốt lõi (Security, System, Application) và các kênh chuyên biệt (Applications and Services Logs, như Microsoft-Windows-PowerShell/Operational Event ID 4104 [21] [20] ): - Security Event ID 4624 (An account was successfully logged on): Ghi rõ Logon Type (ví dụ Type 3 = Network Logon qua SMB/RPC từ .10; Type 5 = Service Startup bởi SCM; Type 10 = RemoteInteractive qua RDP), tên tài khoản, SID và địa chỉ IP nguồn. - Security Event ID 4625 (An account failed to log on): Ghi nhận mọi nỗ lực đăng nhập thất bại kèm mã nguyên nhân (Status / SubStatus), là chỉ báo trực tiếp để phát hiện hành vi dò mật khẩu trái phép. - Security Event ID 4672 (Special privileges assigned to new logon): Xuất hiện ngay cạnh 4624 khi phiên đăng nhập được cấp các đặc quyền nhạy cảm tương đương quản trị viên (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeImpersonatePrivilege) [15] [19] . - Security Event ID 4688 (A new process has been created):* Ghi nhận tiến trình mới khởi chạy kèm dòng lệnh đầy đủ (Command Line Auditing*) và SID của tiến trình cha. - System Event ID 7045 (A service was installed in the system) & 7036 (Service state changed): Bằng chứng kiểm toán quan trọng nhất để phát hiện việc cài đặt dịch vụ mới hoặc dừng dịch vụ bảo vệ trong quá trình kiểm thử. - Trên Linux (F01-linux-srv — .20): Hệ thống systemd-journald thu thập toàn bộ luồng đầu ra chuẩn (stdout/stderr) và thông điệp syslog của từng đơn vị dịch vụ kèm siêu dữ liệu xác thực từ nhân (_PID, _UID, _SYSTEMD_UNIT), đồng thời chuyển tiếp các sự kiện xác thực (PAM, sshd, sudo) vào /var/log/auth.log và nhật ký truy cập ứng dụng vào /var/log/nginx/access.log cùng /var/log/postgresql/ [9] .

Kết hợp dữ liệu mạng từ W01-L01..L04 với dữ liệu hệ điều hành của bài học này, chúng ta xây dựng được *Mô hình Luồng Ứng dụng Xuyên Tầng (Cross-Layer Application & Identity Data Flow) cho kiến trúc Client → Proxy → App → DB. Thay vì chỉ nhìn thấy các địa chỉ IP và số cổng, Technical Lead theo dõi sự chuyển đổi của cả 3 chiều thông tin* tại mỗi bước nhảy: (1) Giao thức & Cổng Socket, (2) Định danh Tiến trình & Quyền Hệ điều hành (UID/GID hoặc SID), và (3) Dấu vết Nhật ký phát sinh trên từng tầng [3] [24] . Toàn bộ luồng chuyển tiếp này được mô hình hóa chi tiết trong sơ đồ Figure 1 :

Trong ví dụ có lời giải này, chúng ta thực hiện kiểm toán song song trên hai máy chủ mục tiêu của Safe Lab F01 là F01-linux-srv (192.168.56.20) và F01-win-trial (192.168.56.30), sau đó gửi một yêu cầu kiểm thử có gắn mã định danh truy vết X-Correlation-ID: F01-TRACE-001 từ F01-tester (192.168.56.10) để quan sát cách yêu cầu đi qua toàn bộ chuỗi Client → Proxy → App → DB và để lại dấu vết trên từng hệ điều hành.

Bảng tổng hợp kết quả kiểm toán đường cơ sở dịch vụ, định danh tiến trình, quyền tệp tin và mã sự kiện nhật ký trên cả hai máy chủ được trình bày tại Table 1 :

Phân tích bảng Table 1 cho phép chúng ta rút ra ba kết luận quan trọng đưa vào báo cáo OS-baseline-and-flow.md: 1. Sự tách biệt đặc quyền theo chiều dọc trên .20 hoạt động đúng thiết kế: Ngay cả khi tầng Nginx (www-data, UID=33) bị khai thác lỗi đọc tệp, tiến trình www-data vẫn bị chặn hoàn toàn khi cố truy cập thư mục mã nguồn ứng dụng /opt/corp-app (0750 root:app-svc — theo phương trình Eq. (1) , vì $33 \neq 0$, $33 \neq u_f$ và $33 \notin G_{\text{app-svc}}$, nhân áp dụng $M_{\text{other}} = \emptyset$) cũng như thư mục dữ liệu PostgreSQL /var/lib/postgresql/16/main (0700 postgres:postgres). 2. Phát hiện điểm cần cải tiến cấu hình (Hardening Opportunity) trên .20: Tệp cấu hình môi trường /etc/corp-app/env.conf đang chứa chuỗi kết nối cơ sở dữ liệu ở dạng văn bản rõ (quyền 0640 root:app-svc). Mặc dù đã giới hạn chỉ nhóm app-svc đọc được, khuyến nghị chuẩn doanh nghiệp là chuyển sang nạp thông tin xác thực qua cơ chế LoadCredentialEncrypted= của systemd hoặc sử dụng xác thực socket cục bộ (peer authentication) để loại bỏ mật khẩu tĩnh trên đĩa. 3. Loại trừ cảnh báo giả trên .30: Công cụ quét cấu hình có thể liệt kê dịch vụ LanmanServer chạy dưới quyền LocalSystem ($\omega = 1.0$), nhưng kiểm tra icacls xác nhận tệp thực thi và khóa Registry hoàn toàn không cho phép người dùng thường chỉnh sửa ($\mu_{\text{acl}} = 0$), đồng thời Event ID 4624 và 4672 xác nhận tài khoản kiểm thử win_lab_reader không hề được cấp đặc quyền quản trị (Special Privileges) khi đăng nhập qua mạng.

Bài tập thực hành: Bạn cần hoàn thiện hai đoạn mã kiểm toán nhanh (một trên Bash cho Linux .20 và một trên PowerShell cho Windows .30) để: (1) Tìm kiếm toàn bộ các tệp thực thi có bật cờ SUID hoặc SGID trên hệ thống tệp cục bộ mà không đi lạc sang các hệ thống tệp ảo; (2) Kiểm tra các chỉ thị đóng hộp bảo mật của dịch vụ app-gunicorn.service; và (3) Trích xuất 10 sự kiện đăng nhập thành công (Event ID 4624) gần nhất từ kênh Security trên Windows. Hãy điền các tham số còn khuyết ___ vào khung mã dưới đây:

Để giúp Technical Lead chuyển đổi tư duy kiểm toán mượt mà giữa hai hệ điều hành trong môi trường doanh nghiệp hỗn hợp (Hybrid Linux/Windows Enterprise), bảng Table 2 ánh xạ trực tiếp từng khái niệm định danh, phân quyền, quản lý dịch vụ và nhật ký kiểm toán giữa Linux và Windows:

Song song với bảng ánh xạ tương đương tại Table 2 , khi đánh giá các dịch vụ trên máy chủ Windows (F01-win-trial), Technical Lead cần đối chiếu mức độ cô lập của 4 nhóm tài khoản dịch vụ theo ma trận so sánh dưới đây:

Trong bài thực hành Safe Lab F01 của Ngày 5 (W01-L05 — tổng thời lượng 3.5 giờ gồm 1.0 giờ lý thuyết, 1.0 giờ thực hành lab và 1.5 giờ quản trị & rà soát nhóm), học viên trực tiếp thu thập đường cơ sở dịch vụ, định danh người dùng, quyền hạn tệp tin và nhật ký sự kiện trên hai máy chủ mục tiêu F01-linux-srv (192.168.56.20) và F01-win-trial (192.168.56.30). Sau đó, học viên vận dụng phương trình phân quyền Eq. (1) , chỉ số phơi nhiễm đặc quyền Eq. (2) và sơ đồ luồng ứng dụng Figure 1 để biên soạn và rà soát chéo báo cáo chuẩn OS-baseline-and-flow.md kèm mã băm SHA256SUMS [1] [2] .

Phần đánh giá năng lực của bài W01-L05 kiểm tra khả năng vận dụng kiến thức hệ điều hành Linux/Windows ở cấp độ *Rà soát Kỹ thuật (Review Depth), đồng thời thực hiện truy hồi ngắt quãng (Spaced Retrieval*) kết nối xuyên suốt 5 bài học đầu tiên của Tuần 1 (W01-L01 đến W01-L05). Hồ sơ OS-baseline-and-flow.md được đánh giá theo Thang đo Hành vi tại bảng Table 3 .