Tweet
Sự cố nghiêm trọng nhất trong quý của một công ty không đến từ lỗi phần cứng hay bug phần mềm, mà đến từ một thay đổi cấu hình router lúc 5 giờ chiều thứ Sáu - không qua phê duyệt, không ai ghi lại đã đổi gì. Cuối tuần mạng sập, đội trực không có baseline để so sánh, không biết ai vừa đổi gì, mất gần nguyên buổi tối chỉ để xác định đâu là nguyên nhân chứ chưa nói đến khắc phục. Vấn đề không nằm ở kỹ thuật - nó nằm ở quy trình.
Ba khái niệm hay bị dùng lẫn lộn với nhau thực ra tách bạch rõ ràng. Kế hoạch (Plan) đóng vai trò như danh từ, vạch ra định hướng và mục tiêu tổng thể - Business Continuity Plan, Disaster Recovery Plan, Incident Response Plan đều thuộc nhóm này. Quy trình (Procedure) đóng vai trò như động từ, là các bước hành động cụ thể để hiện thực hóa kế hoạch đó. Chính sách (Policy) là nguyên tắc bắt buộc do tổ chức ban hành, đảm bảo mọi người làm đúng và làm giống nhau, đồng thời phản ánh yêu cầu tuân thủ pháp lý. Có kế hoạch mà không có quy trình thì chỉ là khẩu hiệu trên giấy; có quy trình mà không có chính sách ràng buộc thì mỗi người làm một kiểu.
Thay đổi cấu hình router kể trên lẽ ra phải đi qua Change Management - quy trình kiểm soát mọi thay đổi phần cứng, phần mềm, luôn đòi hỏi có sẵn kế hoạch hoàn tác (rollback/backout plan) phòng khi thay đổi thất bại, phải được hội đồng thay đổi CAB phê duyệt trước, và chỉ thực hiện trong khung giờ bảo trì đã định để giảm thiểu tác động lên người dùng. Khi sự cố vẫn xảy ra dù đã kiểm soát thay đổi, Incident Response Plan mới là thứ quyết định tốc độ xử lý: ai làm gì, tra log bảo mật ở đâu, dùng công cụ pháp chứng nào, dựa vào bản sao lưu nào để khôi phục - tất cả phải được định sẵn từ trước, vì giữa lúc sự cố đang cháy không phải lúc ngồi bàn ai chịu trách nhiệm việc gì. Business Continuity Plan và Disaster Recovery Plan hay bị nhầm là một, nhưng thực ra đứng ở hai tầng khác nhau: BCP mang tầm chiến lược kinh doanh, lo cho những chức năng thiết yếu của công ty vẫn chạy được xuyên suốt thảm họa dù phải xử lý thủ công hay chuyển sang văn phòng tạm; DRP là tập con kỹ thuật nằm bên trong BCP, chỉ tập trung đúng một việc là dựng lại hệ thống IT, khôi phục dữ liệu từ bản sao lưu và đưa máy chủ hoạt động trở lại.
Tài sản thiết bị trong công ty cũng cần được theo dõi xuyên suốt vòng đời, không chỉ tính đến lúc lắp đặt xong là hết trách nhiệm. Từ lúc mua sắm, triển khai, đưa vào sử dụng và hỗ trợ, bảo trì định kỳ, cho đến khi thu hồi hoặc tái sử dụng, rồi cuối cùng là tiêu hủy đúng cách - bỏ qua giai đoạn cuối này là lý do không ít vụ rò rỉ dữ liệu xảy ra chỉ vì một ổ cứng thanh lý mà không ai xóa sạch dữ liệu trước.
Muốn quy trình được làm đúng và làm giống nhau mỗi lần, cần có Standard Operating Procedure ghi rõ từng bước cụ thể, để công việc không phụ thuộc vào trí nhớ hay thói quen riêng của từng người. Song song đó là một nhóm chính sách bảo mật nền tảng: Acceptable Use Policy quy định ranh giới khi dùng tài nguyên công ty, BYOD cân bằng giữa tiện lợi cho nhân viên và an toàn dữ liệu khi thiết bị cá nhân chạm vào mạng nội bộ, cùng với password policy, remote access policy, onboarding/offboarding policy để đóng tài khoản đúng lúc nhân viên nghỉ việc, privileged user account policy siết chặt quyền quản trị, và data loss prevention để chặn dữ liệu nhạy cảm rò rỉ ra ngoài.
Tất cả những chính sách đó chỉ có tác dụng nếu hạ tầng cũng được tài liệu hóa đầy đủ - sơ đồ mạng vật lý và logic, sơ đồ đi dây, sơ đồ rack, tài liệu phòng MDF/IDF, cùng với baseline configuration để biết "bình thường" trông như thế nào. Không có baseline, đội trực trong ví dụ đầu bài sẽ mãi rơi vào tình cảnh dò tìm trong bóng tối mỗi khi có sự cố.
Khi làm việc với bên thứ ba, ba loại văn bản thường xuất hiện nhất: SLA ràng buộc mức dịch vụ tối thiểu và mức đền bù nếu đối tác vi phạm, NDA bảo vệ thông tin không bị lộ ra ngoài, và MOU ghi nhận sự thống nhất mục tiêu hợp tác dù chưa mang tính ràng buộc pháp lý chặt như hợp đồng chính thức.
Nhìn lại, phần lớn sự cố mạng nghiêm trọng không bắt đầu từ một dòng lệnh sai, mà từ một quy trình bị bỏ qua trước khi dòng lệnh đó được gõ. Công ty bạn có quy trình phê duyệt thay đổi rõ ràng, hay vẫn còn ai đó âm thầm sửa cấu hình lúc cuối tuần?
Ba khái niệm hay bị dùng lẫn lộn với nhau thực ra tách bạch rõ ràng. Kế hoạch (Plan) đóng vai trò như danh từ, vạch ra định hướng và mục tiêu tổng thể - Business Continuity Plan, Disaster Recovery Plan, Incident Response Plan đều thuộc nhóm này. Quy trình (Procedure) đóng vai trò như động từ, là các bước hành động cụ thể để hiện thực hóa kế hoạch đó. Chính sách (Policy) là nguyên tắc bắt buộc do tổ chức ban hành, đảm bảo mọi người làm đúng và làm giống nhau, đồng thời phản ánh yêu cầu tuân thủ pháp lý. Có kế hoạch mà không có quy trình thì chỉ là khẩu hiệu trên giấy; có quy trình mà không có chính sách ràng buộc thì mỗi người làm một kiểu.
Thay đổi cấu hình router kể trên lẽ ra phải đi qua Change Management - quy trình kiểm soát mọi thay đổi phần cứng, phần mềm, luôn đòi hỏi có sẵn kế hoạch hoàn tác (rollback/backout plan) phòng khi thay đổi thất bại, phải được hội đồng thay đổi CAB phê duyệt trước, và chỉ thực hiện trong khung giờ bảo trì đã định để giảm thiểu tác động lên người dùng. Khi sự cố vẫn xảy ra dù đã kiểm soát thay đổi, Incident Response Plan mới là thứ quyết định tốc độ xử lý: ai làm gì, tra log bảo mật ở đâu, dùng công cụ pháp chứng nào, dựa vào bản sao lưu nào để khôi phục - tất cả phải được định sẵn từ trước, vì giữa lúc sự cố đang cháy không phải lúc ngồi bàn ai chịu trách nhiệm việc gì. Business Continuity Plan và Disaster Recovery Plan hay bị nhầm là một, nhưng thực ra đứng ở hai tầng khác nhau: BCP mang tầm chiến lược kinh doanh, lo cho những chức năng thiết yếu của công ty vẫn chạy được xuyên suốt thảm họa dù phải xử lý thủ công hay chuyển sang văn phòng tạm; DRP là tập con kỹ thuật nằm bên trong BCP, chỉ tập trung đúng một việc là dựng lại hệ thống IT, khôi phục dữ liệu từ bản sao lưu và đưa máy chủ hoạt động trở lại.
Tài sản thiết bị trong công ty cũng cần được theo dõi xuyên suốt vòng đời, không chỉ tính đến lúc lắp đặt xong là hết trách nhiệm. Từ lúc mua sắm, triển khai, đưa vào sử dụng và hỗ trợ, bảo trì định kỳ, cho đến khi thu hồi hoặc tái sử dụng, rồi cuối cùng là tiêu hủy đúng cách - bỏ qua giai đoạn cuối này là lý do không ít vụ rò rỉ dữ liệu xảy ra chỉ vì một ổ cứng thanh lý mà không ai xóa sạch dữ liệu trước.
Muốn quy trình được làm đúng và làm giống nhau mỗi lần, cần có Standard Operating Procedure ghi rõ từng bước cụ thể, để công việc không phụ thuộc vào trí nhớ hay thói quen riêng của từng người. Song song đó là một nhóm chính sách bảo mật nền tảng: Acceptable Use Policy quy định ranh giới khi dùng tài nguyên công ty, BYOD cân bằng giữa tiện lợi cho nhân viên và an toàn dữ liệu khi thiết bị cá nhân chạm vào mạng nội bộ, cùng với password policy, remote access policy, onboarding/offboarding policy để đóng tài khoản đúng lúc nhân viên nghỉ việc, privileged user account policy siết chặt quyền quản trị, và data loss prevention để chặn dữ liệu nhạy cảm rò rỉ ra ngoài.
Tất cả những chính sách đó chỉ có tác dụng nếu hạ tầng cũng được tài liệu hóa đầy đủ - sơ đồ mạng vật lý và logic, sơ đồ đi dây, sơ đồ rack, tài liệu phòng MDF/IDF, cùng với baseline configuration để biết "bình thường" trông như thế nào. Không có baseline, đội trực trong ví dụ đầu bài sẽ mãi rơi vào tình cảnh dò tìm trong bóng tối mỗi khi có sự cố.
Khi làm việc với bên thứ ba, ba loại văn bản thường xuất hiện nhất: SLA ràng buộc mức dịch vụ tối thiểu và mức đền bù nếu đối tác vi phạm, NDA bảo vệ thông tin không bị lộ ra ngoài, và MOU ghi nhận sự thống nhất mục tiêu hợp tác dù chưa mang tính ràng buộc pháp lý chặt như hợp đồng chính thức.
Nhìn lại, phần lớn sự cố mạng nghiêm trọng không bắt đầu từ một dòng lệnh sai, mà từ một quy trình bị bỏ qua trước khi dòng lệnh đó được gõ. Công ty bạn có quy trình phê duyệt thay đổi rõ ràng, hay vẫn còn ai đó âm thầm sửa cấu hình lúc cuối tuần?