Bảo mật cơ bản cho web app doanh nghiệp: phân quyền, sao lưu

Nếu ngày mai ai đó lấy được toàn bộ danh sách khách hàng và công nợ của bạn, bạn sẽ biết mình đã làm gì sai ở đâu? Phần lớn chủ doanh nghiệp không trả lời được, và đó không phải lỗi của họ. Bảo mật hay bị gói vào một chữ "kỹ thuật" rồi giao hết cho người viết phần mềm. Nhưng có một nhóm quyết định chỉ người đặt hàng mới đưa ra được: ai được xem gì, dữ liệu để ở đâu, hỏng thì khôi phục từ đâu. Những câu dưới đây là thứ bạn nên hỏi đơn vị thực hiện, viết bằng lời thường.

Ai trong công ty được thấy và được sửa cái gì?

Đa số sự cố trong phần mềm nội bộ không đến từ kẻ lạ ở xa. Nó đến từ một nhân viên mở nhầm một danh sách, hay một người sửa được thứ họ không nên sửa. Vì vậy hãy bắt đầu bằng một bảng đơn giản: mỗi vai trò, từ bán hàng, kế toán đến quản lý, thấy được và làm được gì.

Một ví dụ cho dễ hình dung. Nhân viên chỉ thấy khách mình phụ trách. Kế toán thấy công nợ nhưng không sửa được giá. Quản lý duyệt các trường hợp ngoại lệ. Cứ cấp quyền ít nhất đủ để làm việc, rồi mở thêm khi có lý do, thay vì mở hết rồi thu lại. Bảng này sau đó trở thành căn cứ khi nghiệm thu. Đội kỹ thuật có thể tham khảo tài liệu OWASP về kiểm soát truy cập để thiết kế phần này.

Nhân viên nghỉ việc thì tài khoản của họ đi đâu?

Câu hỏi này nghe nhỏ nhưng đứng sau khá nhiều vụ lộ dữ liệu. Một tài khoản cũ không ai nhớ tắt là cánh cửa mở sẵn. Hãy chỉ định một người có trách nhiệm khóa hoặc đổi quyền ngay khi ai đó nghỉ hay chuyển vị trí.

Còn chuyện đăng nhập nói chung: mật khẩu cần có chính sách hợp lý, hệ thống nên làm chậm hoặc khóa khi nhập sai nhiều lần, và việc đặt lại mật khẩu không được tiết lộ thêm thông tin nào. Với tài khoản quản trị, xác thực hai bước đáng được cân nhắc.

Dữ liệu của bạn nằm trên máy của ai?

Đây là câu hỏi mà nhiều người chỉ hỏi sau khi hợp đồng đã kết thúc. Hãy hỏi sớm hơn: dữ liệu lưu trên hạ tầng của ai, và những ai vào được máy chủ cũng như cơ sở dữ liệu. Tài khoản quản trị hạ tầng nên đứng tên doanh nghiệp, ho���c ít nhất doanh nghiệp phải có quyền kiểm soát và thu hồi. Nếu chỉ bên làm phần mềm vào được máy chủ, bạn đang phụ thuộc vào họ hơn mình tưởng.

Nếu hệ thống lưu dữ liệu cá nhân, hãy xem quy định hiện hành như Nghị định 13/2023/NĐ-CP, và thống nhất rõ mục đích thu thập, thời gian lưu, cách xử lý yêu cầu xóa hay chỉnh sửa. Văn bản có thể được cập nhật, vì vậy nên nhờ người am hiểu pháp lý xác nhận trước khi thiết kế.

Nếu hệ thống hỏng sáng mai thì mất bao nhiêu?

Bản sao lưu chỉ có giá trị khi khôi phục được từ nó, và cách duy nhất để biết là thử. Hãy hỏi bao lâu sao lưu một lần, giữ mấy bản, cất ở đâu, và đã thử khôi phục thật lần nào chưa. Bản sao lưu nằm cùng máy với dữ liệu gốc sẽ biến mất cùng nó.

Rồi hãy tự trả lời hai con số: mất tối đa bao nhiêu dữ liệu thì chấp nhận được, và ngừng hoạt động bao lâu thì còn chịu được. Hai con số này quyết định tần suất sao lưu và kiểu hạ tầng, và chúng phải xuất phát từ việc kinh doanh của bạn chứ không phải từ cấu hình mặc định.

Có một điểm hay bị bỏ sót là môi trường thử nghiệm. Dữ liệu khách hàng thật không nên được chép sang đó khi chưa che thông tin nhạy cảm, vì nơi này thường được canh giữ lỏng hơn nơi chạy chính thức.

Làm sao biết ai đã làm gì?

Nhật ký thao tác ghi lại ai xem, sửa, xóa hay xuất dữ liệu và vào lúc nào. Khi có nghi vấn, nó cho bạn câu trả lời thay vì suy đoán. Với những thao tác nhạy cảm như đổi giá, duyệt chi, xuất toàn bộ danh sách khách, chỉ việc biết có nhật ký cũng đã đủ để người ta cẩn thận hơn.

Nhật ký không được sửa lén, và cũng không nên chứa mật khẩu hay số thẻ. Hãy hỏi nhật ký nào được ghi, giữ bao lâu và ai xem được.

Một việc nhỏ nhưng hữu ích: yêu cầu đơn vị thực hiện cho xem thử một bản ghi nhật ký thật trước khi nghiệm thu. Nhìn một dòng nhật ký cụ thể, với tên người, hành động và giờ giấc, bạn sẽ hiểu ngay nó có dùng được cho việc điều tra hay không, thay vì chỉ nghe nói rằng hệ thống có ghi nhật ký. Điều tương tự áp dụng cho bản sao lưu: đề nghị họ khôi phục thử trước mặt bạn một lần.

Đơn vị làm phần mềm kiểm tra lỗ hổng bằng cách nào?

OWASP Top 10 là danh sách rủi ro phổ biến của ứng dụng web mà nhiều đội kỹ thuật dùng làm mốc tham chiếu. Bạn không cần đọc hết từng mục. Chỉ cần hỏi họ dựa vào tiêu chuẩn nào, kiểm thử bảo mật ra sao trước khi bàn giao, và nếu phát hiện lỗi thì xử lý thế nào.

Vài câu kiểm tra nhanh: dữ liệu có được mã hóa khi truyền không, thư viện bên thứ ba có được cập nhật đều không, thông tin cấu hình nhạy cảm có nằm ngoài mã nguồn không. Nếu câu trả lời lòng vòng, đó là lúc hỏi thêm.

Ai lo chuyện bảo mật sau ngày bàn giao?

Lỗ hổng mới được phát hiện liên tục ở thư viện và hệ điều hành, nên bảo mật không kết thúc ở ngày nghiệm thu. Cần thống nhất ai chịu trách nhiệm cập nhật, bao lâu kiểm tra một lần, và khi có sự cố thì ai được báo, bước đầu tiên là gì. Một kế hoạch ứng phó viết sẵn trên một trang giấy thường tốt hơn nhiều so với xử lý tùy hứng lúc đang hoảng.

Nếu bạn đang cần một hệ thống quản trị có phân quyền và nhật ký rõ ràng, F2C Labs sẵn sàng cùng bạn đặt những câu hỏi trên ngay ở buổi khảo sát. Phần dịch vụ phát triển web app và hệ thống quản trị có mô tả cách làm việc, còn trang liên hệ nhận mô tả ngắn về hệ thống bạn cần.