Bảo mật không phải checklist trước ngày phát hành

1. Xác định nguy cơ trước khi chọn công cụ

Mô hình nguy cơ không cần biểu mẫu phức tạp. Một giờ trước bảng trắng với ba câu hỏi thường là đủ: dữ liệu nào rò rỉ sẽ gây thiệt hại lớn nhất, ai có thể chạm tới nó, và bằng cách nào chúng ta biết điều đó đã xảy ra. Câu trả lời quyết định lớp bảo vệ nào đáng đầu tư.

Thiếu bước này, nhóm dễ mua bảo vệ cho sai lớp. Một tường lửa ứng dụng web không giúp gì khi rủi ro thật là công cụ xuất dữ liệu nội bộ mà mọi tài khoản nhân viên đều gọi được, hoặc một bản backup cơ sở dữ liệu được sao sang ổ đĩa cá nhân.

• Liệt kê tài sản quan trọng: dữ liệu khách hàng, thông tin thanh toán, thông tin đăng nhập, logic nghiệp vụ, khả năng phục vụ.
• Liệt kê ai chạm được tới từng tài sản: người dùng cuối, nhân viên, đối tác, tác vụ nền, dịch vụ bên thứ ba.
• Liệt kê các đường vào: trang công khai, API cần xác thực, công cụ quản trị, tích hợp, pipeline triển khai, quy trình hỗ trợ.
• Với mỗi tài sản, gọi tên hậu quả xấu nhất có thể xảy ra thật và biện pháp giúp ngăn hoặc phát hiện nó.

Một mô hình nguy cơ hữu ích thì ngắn và được xem lại. Nó phải thay đổi khi sản phẩm thêm một vai trò, một tích hợp hoặc một loại dữ liệu mới.

2. Danh tính và phân quyền là vành đai thật sự

Khi hệ thống đã có công cụ cho nhân viên, tài khoản đối tác và tác vụ nền, biên giới mạng không còn là biên giới. Kiểm soát truy cập trở thành lớp quan trọng nhất, và nó phải được kiểm tra ở phía server cho từng request, chứ không dựa vào việc ẩn một mục menu.

Lỗi phân quyền là nhóm phát hiện nghiêm trọng phổ biến nhất, chính vì nó trông giống phần mềm đang chạy tốt. Trang vẫn hiển thị, request vẫn thành công, chỉ có dữ liệu trả về là của người khác. Loại lỗi này vô hình với công cụ quét tự động nhưng lộ ngay khi một tài khoản thứ hai thử truy cập bản ghi của tài khoản thứ nhất.

• Kiểm tra quyền ở server cho mọi lượt đọc và ghi, bao gồm xuất dữ liệu, tải tệp và webhook.
• Giới hạn truy vấn theo đơn vị của người gọi ngay trong câu lệnh, thay vì lọc kết quả sau khi đã lấy toàn bộ.
• Chia vai trò theo quyết định mà người dùng phải đưa ra, không theo chức danh; giữ số vai trò đủ ít để giải thích được.
• Bắt buộc xác thực hai yếu tố cho các hành động quản trị và liên quan đến tiền.
• Rà soát danh sách tài khoản định kỳ, và bảo đảm quy trình rời tổ chức thu hồi quyền ngay trong ngày.

3. Quyết định giữ dữ liệu nào và khoá bí mật nằm ở đâu

Cách bảo vệ dữ liệu rẻ nhất là không lưu nó. Trước khi thêm một trường, hãy hỏi ai cần, cần trong bao lâu và điều gì xảy ra nếu dữ liệu đó sai. Số giấy tờ đầy đủ, vị trí chính xác hay chi tiết thẻ thường được thu thập vì biểu mẫu mẫu có sẵn, không phải vì một bước vận hành nào cần đến.

Khoá bí mật cần kỷ luật tương tự. API key nằm trong repository, một mật khẩu dùng chung trong nhóm chat hay connection string của môi trường production trong tệp cấu hình trên máy lập trình viên đều là cùng một lỗi: một thông tin xác thực không có chủ sở hữu, không được luân chuyển và không ai biết đã dùng ở đâu.

• Phân loại dữ liệu thành công khai, nội bộ, mật và chịu quản lý pháp lý; để phân loại đó quyết định biện pháp bảo vệ.
• Đặt thời hạn lưu trữ cho từng loại, và biến việc xoá thành một tác vụ được cài đặt thật, không phải một dự định.
• Mã hoá toàn bộ đường truyền, và mã hoá các trường nhạy cảm khi lưu với khoá không nằm cạnh dữ liệu.
• Đặt khoá bí mật trong hệ quản lý riêng, nạp vào lúc chạy, luân chuyển theo định kỳ và thu hồi được trong vài phút.
• Băm mật khẩu bằng thuật toán chuyên dụng; không bao giờ ghi log thông tin đăng nhập, token hay bản ghi cá nhân đầy đủ.

Bản sao lưu chịu cùng quy tắc với production. Một cơ sở dữ liệu được bảo vệ tốt và một bản dump hằng đêm không mã hoá trên ổ chia sẻ mang lại cho kẻ tấn công cùng một kết quả.

4. Đưa các bước kiểm tra vào pipeline phát hành

Những vòng review phụ thuộc vào việc có người còn nhớ sẽ không sống nổi qua một tuần phát hành gấp. Thứ trụ được là các bước chạy tự động trên mọi thay đổi: quét thư viện phụ thuộc, phát hiện khoá bí mật, phân tích tĩnh trên các đoạn liên quan đến xác thực và dữ liệu, và một bản build thất bại khi xuất hiện phát hiện nghiêm trọng.

Thư viện phụ thuộc cần chú ý riêng, vì phần lớn mã trong một ứng dụng hôm nay là mã đi kèm. Hãy khoá phiên bản, cập nhật theo nhịp thay vì chạy gấp khi có tin xấu, và biết thư viện nào nằm trên đường xử lý request để xử lý một cảnh báo trong vài giờ thay vì vài ngày.

• Chặn merge khi phát hiện khoá bí mật hoặc cảnh báo nghiêm trọng ở thư viện phụ thuộc.
• Bắt buộc người review khác tác giả cho thay đổi liên quan đến xác thực, phân quyền và thanh toán.
• Tách biệt môi trường; không để thông tin xác thực production tiếp cận được từ máy lập trình viên.
• Ghi lại ai triển khai gì, vào lúc nào, và giữ khả năng rollback nhanh.
• Chạy lại đúng các bước kiểm tra đó trên nhánh phát hành, không chỉ trên nhánh tính năng.

5. Chuẩn bị cho ngày có sự cố

Phòng ngừa rồi cũng có lúc thất bại, nên câu hỏi thứ hai là nhóm phát hiện nhanh đến đâu và trả lời được điều gì đã xảy ra chắc chắn đến mức nào. Điều đó cần một dấu vết kiểm toán được thiết kế có chủ đích: ai thao tác, trên bản ghi nào, từ đâu, lúc nào và thay đổi những gì.

Nó cũng cần một kế hoạch mà nhóm đang căng thẳng vẫn làm theo được. Ai tuyên bố sự cố, ai có quyền thu hồi thông tin xác thực hoặc tắt một tính năng, ai nói với khách hàng, và bằng chứng nào phải được giữ lại trước khi bắt đầu sửa. Quyết định trước thì đó là vài phút. Quyết định giữa sự cố thì đó là vài giờ.

• Ghi log sự kiện đăng nhập, các lần bị từ chối quyền, hành động quản trị và mọi lượt xuất dữ liệu.
• Cảnh báo theo dấu hiệu lạm dụng: dò mật khẩu hàng loạt, khối lượng xuất dữ liệu bất thường, thay đổi quyền.
• Giữ log đủ lâu để điều tra, và bảo vệ log khỏi chính những tài khoản mà nó theo dõi.
• Viết kế hoạch ứng phó một trang gồm tên người, cách liên lạc và năm việc cần làm đầu tiên.
• Diễn tập một lần với tình huống thực tế, rồi sửa đúng những gì buổi diễn tập chỉ ra.

Thước đo của một chương trình bảo mật không phải là không còn phát hiện nào. Đó là khoảng thời gian từ phát hiện đến bản sửa, và tần suất cùng một loại lỗi quay lại.