Loading...

Bài 8. Change management (2) — tác động kỹ thuật và tài liệu hóa: allow/deny list, downtime, hệ thống legacy, version control

Khóa học CompTIA Security+ SY0-801 · Phần 1: Khái niệm bảo mật cốt lõi · Bài 8 · 🎯 Objective 1.2 · ⏱️ Đọc khoảng 13 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

  • Phân biệt allow list và deny list, và hiểu nguyên tắc "mặc định từ chối".
  • Nhận biết tác động kỹ thuật của một thay đổi: downtime, khởi động lại dịch vụ hoặc ứng dụng, hệ thống legacy, các phụ thuộc.
  • Giải thích vì sao phải cập nhật tài liệu (sơ đồ, chính sách, quy trình) sau mỗi thay đổi.
  • Hiểu vai trò của quản lý phiên bản (version control) trong việc truy vết và quay lui.

📎 Vị trí trong đề thi: bài này nối tiếp Bài 7 trong Objective 1.2. Bài 7 nói về quy trình, bài này nói về hệ quả kỹ thuật mà người thực hiện phải lường trước.

💡 Liên hệ thực tế: Chủ nhật 22:00, thay đổi theo đúng quy trình

Sau sự cố ở Bài 7, công ty chị Lan áp dụng quy trình thay đổi. Lần này Nam chuẩn bị nâng cấp máy chủ ứng dụng kế toán, kèm thêm một nhà cung cấp hóa đơn điện tử mới. Đây là tình huống minh họa, không phải vụ việc có thật.

Trong bước phân tích tác động, Nam lập bản đồ những thứ sẽ bị chạm tới:

  • Khởi động lại dịch vụ. Máy chủ ứng dụng phải khởi động lại, nên kết nối tới cơ sở dữ liệu kế toán sẽ bị cắt khoảng 5 phút. Đó là downtime đã lường trước, và là lý do chọn Chủ nhật 22:00.
  • Hệ thống legacy. Phần mềm kế toán đời cũ chỉ chạy với Java 8. Bản mới của máy chủ ứng dụng sẽ làm nó hỏng, nên Nam phải giữ nguyên Java 8 cho riêng phần mềm này.
  • Allow list. Nhà cung cấp hóa đơn điện tử mới cần gọi vào cổng 8443. Nam thêm đúng một địa chỉ IP của nhà cung cấp vào danh sách cho phép, không mở cho mọi nơi.

Nam lưu cấu hình firewall vào kho quản lý phiên bản. Lúc 22:05, anh Dũng (người được nhờ hỗ trợ) lỡ sửa quy tắc thành "cho phép từ mọi IP". Nam nhìn bản so sánh (diff), thấy ngay chỗ sai, và đưa cấu hình về phiên bản trước chỉ trong vài giây. Hôm sau, Nam cập nhật sơ đồ mạng và quy trình, vì sơ đồ cũ vẫn ghi địa chỉ IP của nhà cung cấp trước.

🗺️ Hình 8a. Mỗi thẻ là một hệ quả kỹ thuật phải xét trước khi làm. Các thẻ lần lượt được nhấn mạnh.

📘 Kiến thức cốt lõi

✅ Allow list và deny list

Allow listDeny list
Tên khác Whitelist, danh sách cho phép Blocklist, blacklist, danh sách chặn
Nguyên tắc Chỉ những thứ có trong danh sách mới được qua, mọi thứ còn lại bị từ chối Những thứ có trong danh sách bị chặn, mọi thứ còn lại được qua
Mức chặt Chặt hơn, theo hướng "mặc định từ chối" Lỏng hơn, vì chỉ chặn những gì đã biết là xấu
Ví dụ Chỉ IP của nhà cung cấp hóa đơn được gọi vào cổng 8443 Chặn danh sách IP độc hại đã biết
Nhược điểm Phải bảo trì liên tục khi có đối tác mới, dễ chặn nhầm Không chặn được mối đe dọa chưa được liệt kê

🎯 Mẹo làm bài: đề nói "chỉ cho phép những thứ đã được duyệt, chặn tất cả còn lại" là allow list. Đề nói "chặn những địa chỉ hoặc ứng dụng đã biết là nguy hiểm" là deny list. Đề nhắc tới "mặc định từ chối" (default deny, implicit deny) gợi ý hướng allow list.

Mỗi lần sửa danh sách cũng là một thay đổi. Chỉ cần thêm nhầm một dòng "any" là cả nguyên tắc bị phá. Vì vậy thay đổi trên danh sách cũng phải qua quy trình ở Bài 7.

🔌 Tác động kỹ thuật khi thay đổi

Tác độngÝ nghĩaCách xử lý
Downtime Thời gian dịch vụ không dùng được Chọn maintenance window, báo trước cho stakeholders
Service restart Khởi động lại một dịch vụ, có thể cắt kết nối đang chạy Chọn giờ thấp điểm, thông báo trước, kiểm tra các kết nối đang mở
Application restart Khởi động lại ứng dụng, có thể mất phiên làm việc chưa lưu Yêu cầu người dùng lưu việc trước, xử lý phiên còn dở
Dependencies (phụ thuộc) Hệ thống A cần hệ thống B để chạy Lập sơ đồ phụ thuộc, hỏi "thay đổi này chạm tới ai?"
Legacy application Ứng dụng cũ, không còn hỗ trợ, khó vá hoặc nâng cấp Cô lập bằng kiểm soát bù đắp, giữ nguyên môi trường cần thiết
Restricted activities Việc bị cấm hoặc phải xin phép riêng trong lúc thay đổi Ghi rõ trong phạm vi thay đổi để mọi người cùng tuân theo

Hệ thống legacy đáng chú ý vì nó là chỗ bảo mật và vận hành xung đột nhau. Nâng cấp thì có thể làm hỏng quy trình kinh doanh. Không nâng cấp thì giữ nguyên lỗ hổng. Cách xử lý thường thấy là dùng kiểm soát bù đắp (compensating control, Bài 4) như tách vào VLAN riêng, chỉ cho vài máy truy cập, đồng thời lập kế hoạch thay thế dài hạn.

📚 Tài liệu hóa và cập nhật

Thay đổi chưa được coi là xong khi hệ thống chạy lại. Nó chỉ xong khi tài liệu được cập nhật:

  • Sơ đồ (mạng, hệ thống, luồng dữ liệu): phản ánh đúng thực tế mới.
  • Chính sách và quy trình (policies, SOP): sửa nếu thay đổi làm đổi cách làm việc.
  • Hồ sơ thay đổi: ai đề xuất, ai duyệt, đã làm gì, kết quả, bài học.

Tài liệu lỗi thời nguy hiểm không kém việc không có tài liệu. Khi sự cố xảy ra, người xử lý sẽ tin vào sơ đồ cũ và đi sai hướng.

🌿 Version control: quản lý phiên bản

Quản lý phiên bản (version control) lưu lịch sử của cấu hình, mã nguồn hoặc tài liệu, ghi lại mỗi thay đổi kèm người làm và thời điểm. Công cụ phổ biến là Git.

🌿 Hình 8b. Phiên bản v1.2 có lỗi nên con trỏ HEAD quay về v1.1. Bảng diff cho thấy chính xác dòng nào bị đổi.

Lợi ích đối với bảo mật:

  • Quay lui nhanh. Quay về phiên bản tốt gần nhất chỉ trong vài giây, thực thi backout plan.
  • Truy vết. Biết ai đổi gì, lúc nào, nên điều tra và quy trách nhiệm được.
  • So sánh (diff). Thấy chính xác dòng nào đổi, nên phát hiện thay đổi trái phép hoặc nhầm lẫn.
  • Cộng tác an toàn. Nhiều người cùng sửa mà không ghi đè lên nhau.

🧠 Áp vào câu chuyện của Nam

Việc Nam làmKhái niệm
Chọn Chủ nhật 22:00, báo trước Downtime, maintenance window
Giữ Java 8 cho phần mềm kế toán Legacy application, dependency
Chỉ thêm đúng một IP cho nhà cung cấp hóa đơn Allow list
Phát hiện quy tắc "any" nhờ bản so sánh Version control, diff
Quay lui cấu hình về v1.1 Backout plan, version control
Cập nhật sơ đồ mạng và quy trình Documentation

📖 Thuật ngữ cần nhớ

Thuật ngữNghĩa
Allow list Danh sách cho phép, chỉ những thứ trong danh sách mới được qua.
Deny list Danh sách chặn, những thứ trong danh sách bị chặn.
Default deny Mặc định từ chối mọi thứ chưa được cho phép rõ ràng.
Downtime Thời gian dịch vụ không sẵn sàng.
Service restart Khởi động lại dịch vụ.
Dependency Mối phụ thuộc giữa các hệ thống hoặc thành phần.
Legacy application Ứng dụng cũ, khó nâng cấp hoặc vá.
Restricted activities Hoạt động bị hạn chế trong lúc thay đổi.
Version control Quản lý phiên bản, lưu lịch sử thay đổi.
Diff Bản so sánh hai phiên bản, chỉ ra điểm khác nhau.
Rollback Quay lui về phiên bản hoặc trạng thái trước.

📌 Tóm tắt nhanh

  • Allow list chỉ cho phép thứ đã duyệt, chặt hơn deny list chỉ chặn thứ đã biết là xấu.
  • Trước khi đổi, phải lường các tác động: downtime, khởi động lại, hệ thống legacy, phụ thuộc.
  • Sau khi đổi, phải cập nhật sơ đồ, chính sách và quy trình.
  • Version control giúp truy vết, so sánh và quay lui nhanh.

💬 Hỏi & Đáp nhanh

❓ Allow list có luôn tốt hơn deny list không? Allow list an toàn hơn về mặt chặn, nhưng tốn công bảo trì và dễ chặn nhầm công việc hợp lệ. Deny list dễ vận hành nhưng không chặn được cái chưa biết. Nhiều tổ chức dùng allow list cho hệ thống nhạy cảm và deny list cho phần còn lại.

❓ Vì sao không cứ nâng cấp hệ thống legacy cho xong? Vì nâng cấp có thể làm hỏng quy trình kinh doanh đang chạy, và đôi khi không có phiên bản thay thế. Việc nâng cấp cần được lập kế hoạch dài hạn, còn ngắn hạn phải dùng kiểm soát bù đắp để giảm rủi ro.

❓ Version control chỉ dành cho lập trình viên à? Không. Cấu hình firewall, tập lệnh tự động hóa, chính sách và cả tài liệu đều có thể quản lý phiên bản. Lợi ích về truy vết và quay lui áp dụng cho mọi thứ thay đổi theo thời gian.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Firewall được cấu hình chỉ cho phép các địa chỉ IP đã được phê duyệt truy cập máy chủ, mọi địa chỉ khác bị từ chối. Đây là cơ chế nào?

  • A. Deny list
  • B. Allow list
  • C. Backout plan
  • D. Version control

Câu 2. Một thay đổi yêu cầu khởi động lại dịch vụ cơ sở dữ liệu, làm cắt kết nối của người dùng trong vài phút. Điều gì cần được lập kế hoạch và thông báo trước?

  • A. Downtime
  • B. Legacy application
  • C. Allow list
  • D. Diff

Câu 3. Một ứng dụng cũ không thể cài bản vá vì sẽ chạy sai. Biện pháp nào phù hợp trong lúc chờ thay thế?

  • A. Bỏ qua, vì ứng dụng cũ không cần bảo vệ
  • B. Cài bản vá bất chấp
  • C. Cô lập ứng dụng bằng kiểm soát bù đắp
  • D. Xóa tài liệu liên quan

Câu 4. Nhóm IT muốn biết ai đã đổi cấu hình firewall, đổi lúc nào và đổi dòng nào, đồng thời có thể quay về phiên bản trước nhanh chóng. Công cụ hoặc khái niệm nào đáp ứng tốt nhất?

  • A. Maintenance window
  • B. Allow list
  • C. Version control
  • D. Stakeholders

Câu 5. Sau khi thay đổi địa chỉ IP của một máy chủ, nhóm IT không cập nhật sơ đồ mạng. Rủi ro lớn nhất là gì?

  • A. Máy chủ sẽ chạy chậm hơn
  • B. Người xử lý sự cố sau này sẽ dựa vào sơ đồ sai và đi lạc hướng
  • C. Firewall sẽ tự xóa quy tắc
  • D. Không có rủi ro nào

👉 Đáp án

Câu 1: B — Chỉ những địa chỉ đã được duyệt mới được qua, mọi thứ còn lại bị từ chối. Đó là allow list.

Câu 2: A — Dịch vụ không dùng được trong lúc khởi động lại là downtime, cần lên kế hoạch và thông báo trước.

Câu 3: C — Khi không vá được thì cô lập ứng dụng bằng kiểm soát bù đắp như tách VLAN, đồng thời lập kế hoạch thay thế.

Câu 4: C — Version control lưu lịch sử thay đổi với người làm, thời điểm, nội dung, và cho phép quay lui.

Câu 5: B — Tài liệu lỗi thời khiến người xử lý sự cố tin vào thông tin sai. Phải cập nhật tài liệu sau mỗi thay đổi.


📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng

⬅️ Bài trước🏠 Mục lục khóa họcBài kế tiếp ➡️
Bài 7: Change management (1) — phê duyệt, phân tích tác động, kế hoạch rollback Mục lục khóa học CompTIA Security+ Bài 9: Mật mã nền tảng: mã hóa đối xứng, bất đối xứng, trao đổi khóa