Trong một buổi họp, giám đốc kỹ thuật đưa ra một vấn đề như sau:
Vừa qua, trong quá trình thực hiện penetration test hàng năm cho hệ thống khảo giá của chúng ta, một số lỗi nghiêm trọng được tìm thấy trong cơ chế xác thực danh tính và gán quyền cho tài khoản. Những lỗi bảo mật này đã được cảnh báo đến công ty cung cấp phần mềm. Tuy nhiên, sau khi nghiên cứu, họ cho biết họ không thể giúp được gì vì cách khai triển đi ra ngoài giới hạn và đề nghị của họ. Nếu muốn họ giúp, cơ chế này phải được thay đổi theo thiết kế họ đưa ra và chi phí của việc làm này sẽ không nhỏ. Trở ngại lớn nhất ở đây là vấn đề thời gian vì tháng sau công ty phải ra mắt một sản phẩm mới trên hệ thống khảo giá. Quy trình thay đổi và kiểm nghiệm cơ chế xác thực danh tính và gán quyền này cần ít nhất là hai tháng để thực hiện và không có cách gì rút ngắn lại được bởi vì nó đòi hỏi phải điều chỉnh lại mã nguồn và thiết kế lại cơ sở hạ tầng liên quan đến cơ chế này.
Sau khi xong cuộc họp, tay "Problem Manager" liền triệu tập một cuộc họp thứ nhì để hình thành một cái gọi là "collaboration team". Nhóm này bao gồm đại diện của tất cả các tầng kỹ thuật (như network, security, middleware, DBA, midrange, developers, testers...). Nhóm này được tạo ra nhằm mục đích hình thành một "white boarding session" (nhóm tập họp lại trong một phòng họp có bảng trắng) để đưa ra tất cả các giải pháp có thể nghĩ ra được.
Sau khi mười mấy "giải pháp" được đưa ra, từ ngớ ngẩn nhất (vì không đủ thời gian và tiền bạc để thực hiện) cho đến khả thi nhất được hình thành, tất cả thành viên của nhóm đi xuyên qua giai đoạn thẩm định (assessment) và cho điểm mỗi giải pháp (với thang điểm từ 1 đến 10 chẳng hạn với 1 là ít khả thi và 10 là khả thi nhất). Bốn giải pháp có điểm cao nhất được chọn ra để đi đến chỗ "cãi lộn" nhằm chọn ra hai giải pháp khả thi nhất cho ngắn hạn và dài hạn (nên nhớ, nhóm này toàn là những tay nắm vững các tầng kỹ thuật chớ không lơ tơ mơ).
Sau khi hình thành khung của giải pháp, nhóm bắt tay vô thực thi ngay. Bởi vì các thành viên của nhóm có quyền thay đổi và điều chỉnh ở khu vực kỹ thuật của mình nên cần thực thi ở bất cứ tầng nào cũng xảy ra nhanh chóng (chớ không còn chờ đợi được thực thi như hoàn cảnh bình thường nữa). Mỗi lần thực thi như vậy được xem là đi xuyên qua 1 "iteration" (1 vòng). Công ty anh áp dụng "agile principle" nên tất cả quy trình thảo luận và thực thi xảy ra rất nhanh. Thậm chí, kéo nhau vô phòng họp, mỗi đứa mang theo laptop của mình và thực hiện ngay tại chỗ các thay đổi (tất nhiên chỉ thực hiện trên hệ thống thử nghiệm chớ không phải trên hệ thống production đang hoạt động).
Problem Manager có trách nhiệm thu thập các ghi chú kỹ thuật của từng cá nhân trong nhóm để hình thành "action plan" cho production system sau này và mỗi cá nhân phải có trách nhiệm tự "take notes" và viết tài liệu chuyên biệt cho phạm vi của mình. Xuyên qua mỗi iteration, những thiếu sót hoặc những chi tiết chưa hoàn chỉnh phải được điều chỉnh cho hoàn chỉnh.
Kết quả, giải pháp được áp dụng vào hệ thống production trước thời hạn 1 tuần. Giải pháp ngắn hạn, rẻ tiền nhất và nhanh nhất đã được chọn là thay thế hai con IBM HTTP server chạy trên AIX bằng hai con RHEL 5.x chạy trên 2 virtual machine (vmware) và Apache 2.2.x được cài với mod_security để áp dụng cản lọc nhờ khả năng "transformation" của nó. Giải pháp dài hạn là coding lại application để tiếp nhận và kiểm soát giá trị của cookies / sessions một cách chặt chẽ trước khi "xi nhan" cơ chế authentication / authorisation cho phép xuất truy cập tiếp tục. Chi tiết kỹ thuật thì khá phức tạp bởi vì một application có thể có nhiều "context" và mỗi context trỏ đến một hệ thống khác nhau có chức năng và thông tin khác nhau. Để các hệ thống A, B, C, D.... đều bảo đảm user session X là có giá trị thì chúng phải thông tin và kiểm chứng với nhau dựa trên các điều kiện bảo mật cụ thể.
Điều cần nói ở đây là cách tổ chức và xử lý vấn đề của từng tổ chức doanh nghiệp có thể khác nhau. Nếu sự cố được đưa ra vẫn không khắc phục và kỳ hạn phải tung ra một sản phẩm mới không thể thay đổi được (vì nó quyết định thắng thua bạc triệu) thì bằng mọi cách phải khắc phục. Nếu không khắc phục mà một khách hàng nào bị "dính chấu" thì coi như sản phẩm và chiến dịch ấy hỏng bét. Uy tín của cty cũng trôi xuống sông, xuống biển. Việc hình thành một nhóm "response" để làm việc dedicated và liên tục trong 3 tuần là việc không đơn giản vì chi phí không nhỏ. Tuy nhiên, nếu xét thấy chi phí này chiếm một tỉ lệ không lớn so với doanh thu (theo dự tính) thì không có lý do gì mà không tiến hành hết.
No comments:
Post a Comment