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 đòi hỏi 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 nặng nhất, ai có thể chạm tới nó, và bằng cách nào chúng ta biết sự việc đã xảy ra. Ba câu trả lời đó quyết định nên đầu tư vào lớp bảo vệ nào.

Bỏ qua bước này, doanh nghiệp rất dễ đầu tư bảo vệ nhầm lớp. Một tường lửa ứng dụng web không giúp được gì khi rủi ro thật nằm ở công cụ xuất dữ liệu nội bộ mà bất kỳ tài khoản nhân viên nào cũng gọi được, hay ở bản backup cơ sở dữ liệu đã có người sao chép sang ổ 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ụ 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 và 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 và quy trình hỗ trợ.
• Với mỗi tài sản, xác định tình huống xấu nhất có thể xảy ra và biện pháp giúp ngăn chặn hoặc phát hiện nó.

Một mô hình nguy cơ dùng được phải ngắn gọn và được xem lại thường xuyên. Mỗi khi bổ sung một vai trò, một tích hợp hay một loại dữ liệu mới, mô hình đó cũng phải thay đổi theo.

2. Danh tính và phân quyền mới là hàng rào 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 nữa. Kiểm soát truy cập trở thành lớp quan trọng nhất, và nó phải được kiểm ở phía server cho từng request thay vì chỉ ẩn bớt một mục menu.

Lỗi phân quyền là loại lỗi nghiêm trọng phổ biến nhất, chính vì nó trông giống hệt như 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. Công cụ quét tự động gần như không phát hiện được loại lỗi này, nhưng nó lộ ra ngay khi bạn dùng một tài khoản thứ hai để thử mở bản ghi của tài khoản thứ nhất.

• Kiểm quyền ở server cho mọi lượt đọc và ghi, bao gồm cả 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ấy hết rồi mới lọc.
• Chia vai trò theo những quyết định người dùng phải đưa ra chứ không theo chức danh, và giữ số vai trò đủ ít để giải thích được bằng một câu.
• Bắt buộc xác thực hai yếu tố cho các hành động quản trị và những thao tác liên quan tới 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à lưu khoá bí mật ở đâu

Cách bảo vệ dữ liệu tiết kiệm nhất là không lưu nó. Trước khi thêm một trường, hãy tự 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 chỉ vì biểu mẫu mẫu có sẵn ô đó, chứ không phải vì bước vận hành nào thật sự cần.

Khoá bí mật cũng cần kỷ luật tương tự. API key nằm trong repository, một mật khẩu dùng chung gửi qua nhóm chat, connection string của production trong file cấu hình trên máy lập trình viên: cả ba đều là cùng một lỗi, đó là một thông tin xác thực không có chủ, không được luân chuyển và không ai biết nó đã đi qua nhữ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ý, rồi để phân loại đó quyết định mức bảo vệ.
• Đặt thời hạn lưu cho từng loại và biến việc xoá thành một tác vụ chạy thật thay vì một dự định.
• Mã hoá toàn bộ đường truyền, 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.
• Lưu khoá bí mật trong hệ quản lý riêng, nạp vào lúc chạy, luân chuyển đị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 và tuyệt đối không ghi log thông tin đăng nhập, token hay bản ghi cá nhân đầy đủ.

Bản sao lưu phải tuân theo đúng những quy tắc của production. Một cơ sở dữ liệu được bảo vệ kỹ đi cùng một bản dump hằng đêm không mã hoá nằm trên ổ chia sẻ thì với kẻ tấn công vẫn cho ra 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 dựa vào trí nhớ của con người sẽ không trụ nổi qua một tuần phát hành gấp. Thứ tồn tại được là các bước máy tự chạy trên mọi thay đổi: quét thư viện phụ thuộc, phát hiện khoá bí mật lẫn trong mã, phân tích tĩnh những đoạn liên quan tới xác thực và dữ liệu, cùng một bản build tự động dừng khi có phát hiện nghiêm trọng.

Thư viện phụ thuộc xứng đáng được quan tâm riêng, bởi phần lớn mã trong một ứng dụng ngày nay là mã đi kèm. Hãy khoá phiên bản, cập nhật theo nhịp đều đặn thay vì chạy gấp khi có tin xấu, và nắm rõ thư viện nào nằm trên đường xử lý request, để một cảnh báo được xử lý 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 những thay đổi liên quan tới xác thực, phân quyền và thanh toán.
• Tách biệt môi trường và không để thông tin xác thực production truy cập được từ máy lập trình viên.
• Ghi lại ai triển khai gì, vào thời điểm nào, đồng thời luôn giữ được đường rollback nhanh.
• Chạy lại đúng những 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 sự cố xảy ra

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

Bên cạnh đó là một kế hoạch mà một đội ngũ đ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 trao đổi với khách hàng, và bằng chứng nào phải giữ lại trước khi bắt tay vào sửa. Quyết định trước chỉ mất vài phút, còn quyết định giữa lúc sự cố sẽ mất vài giờ.

• Ghi log các lầ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, lượng xuất dữ liệu bất thường và thay đổi quyền.
• Giữ log đủ lâu để phục vụ điều tra, đồng thời bảo vệ log khỏi chính những tài khoản mà nó đang theo dõi.
• Viết một kế hoạch ứng phó gọn trong một trang: tên người, cách liên lạc và năm việc phải làm đầu tiên.
• Diễn tập một lần với tình huống thật, sau đó khắc phục đúng những điểm 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, mà là khoảng thời gian từ lúc phát hiện đến lúc có bản sửa, cùng tần suất cùng một loại lỗi quay trở lại.