Bảo mật phần mềm: Cần hỏi gì trước khi phát triển?

Trong cổng hồ sơ, cần nhìn cả những bản dữ liệu nằm ngoài màn hình chính: tệp tải xuống, email, báo cáo xuất ra và dữ liệu đưa sang môi trường thử. Đối tác nên mô tả một hồ sơ đi qua những nơi nào và ai được tiếp cận ở từng bước. Việc ẩn thông tin trên màn hình chưa chứng minh các đường còn lại cũng đã được kiểm soát.

Cũng cần xác nhận khi nào tài liệu không còn được sử dụng, ai có quyền quyết định lưu hoặc xóa và những bản đã xuất được quản lý thế nào. Thời hạn cụ thể phải theo nhu cầu và yêu cầu đã được doanh nghiệp xác nhận. Không nên để đội phát triển tự suy ra chính sách này từ một chức năng “xóa hồ sơ”.

Từ đó mới chốt ai cần quyền gì. Nhân viên xử lý có thể cần xem tệp của hồ sơ được giao nhưng chưa cần xuất toàn bộ danh sách; quản lý có thể cần xem tiến độ tổng hợp nhưng chưa cần tải mọi tài liệu.

Đây là những ví dụ để xác nhận nghiệp vụ, không phải chính sách áp dụng cho mọi doanh nghiệp. Chọn quyền theo công việc giúp giảm cả việc cấp quá rộng lẫn việc người dùng bị chặn đến mức phải gửi tệp qua đường khác.

Sau khi xác định ai cần xem hoặc xử lý hồ sơ, doanh nghiệp cần thống nhất quyền cho từng thao tác, chẳng hạn xem tệp, sửa thông tin hay xuất danh sách. Bài Phân quyền người dùng sao cho đúng việc? hướng dẫn cách chuyển nhu cầu công việc thành quyền sử dụng cụ thể để trao đổi với đội phát triển.

Nếu dùng dịch vụ ngoài, phần trách nhiệm còn lại là gì?

Việc thuê dịch vụ ngoài cũng không làm mất câu hỏi về trách nhiệm. Cần biết phần bảo vệ nào do dịch vụ cung cấp, phần cấu hình và quyền nào do đội triển khai quản lý, phần nào cần doanh nghiệp phê duyệt. Nếu chưa có câu trả lời, ghi người kiểm tra và bằng chứng cần nhận thay vì suy rằng nền tảng lớn thì mọi phần của ứng dụng đều đã được bảo vệ.

Các cách kiểm tra trả lời những câu hỏi khác nhau. Rà mã giúp tìm vấn đề trong cách viết chương trình; kiểm tra thư viện xem các thành phần đang dùng có vấn đề đã biết cần xử lý hay không; kiểm tra cấu hình xem môi trường được thiết lập ra sao; thử tình huống truy cập trái phép xem các giới hạn có thực sự được thực thi. Một báo cáo quét có ít phát hiện không thay thế được phần kiểm tra chưa thực hiện.

Ví dụ, đội dự án có thể tạo các hồ sơ thử được phép sử dụng cho hai người dùng khác nhau. Người thứ nhất xử lý được hồ sơ của mình nhưng phải bị từ chối khi yêu cầu hồ sơ của người thứ hai qua màn hình hoặc đường tải tệp.

Khi quyền bị thu hồi, cần xác nhận các đường truy cập liên quan đã tuân theo thay đổi. Phạm vi thử phải được cho phép và diễn ra trên môi trường phù hợp, không tự thử trên dữ liệu của khách thật.

Ngoài thử quyền truy cập, cần làm rõ cách giữ thông tin dùng để kết nối dịch vụ, chẳng hạn mật khẩu hoặc khóa truy cập. Những thông tin này không nên bị lẫn trong tài liệu hoặc kho mã được chia sẻ rộng. Người quản lý, cách thay đổi và cách thu hồi khi không còn dùng phải được xác định trong phạm vi phù hợp.

Có thể dùng khung tham khảo như OWASP ASVS để trao đổi yêu cầu và cách xác minh cho ứng dụng web, nhưng cần chọn phần phù hợp thay vì mặc định áp dụng mọi mục. Kết quả kiểm tra nên nêu rõ môi trường, phạm vi, phát hiện và giới hạn. Nếu dùng kiểm thử chuyên sâu từ bên ngoài, cần thống nhất riêng phạm vi, trách nhiệm và điều kiện thực hiện.

Khi nhận kết quả, doanh nghiệp cần đọc được hệ thống hoặc phiên bản nào đã được kiểm tra, hạng mục nào nằm ngoài phạm vi, phát hiện nào còn mở và ai chấp nhận phần rủi ro còn lại. Nếu có sửa, bằng chứng kiểm tra lại phải liên hệ với phát hiện đó. Dấu “đã sửa” trong một danh sách chưa đủ nếu thay đổi chưa được xác minh hoặc bản sắp phát hành không phải bản đã kiểm tra.

Khi có phát hiện, cần phân loại ảnh hưởng, xác định người sửa, người kiểm tra lại và điều kiện để được phát hành. Những vấn đề chưa xử lý phải có quyết định rõ về cách giảm thiểu hoặc lý do chấp nhận rủi ro. Không nên đóng một phát hiện chỉ vì đã ghi vào danh sách hoặc chưa có ai gặp lỗi trên màn hình.

Không phải mọi phát hiện đều có cùng hậu quả. Một lỗi làm người không có quyền tải hồ sơ khách cần được xem xét khác lỗi ít ảnh hưởng trong chức năng nội bộ.

Người kỹ thuật phải giải thích điều kiện có thể xảy ra, phạm vi dữ liệu và hướng xử lý bằng ngôn ngữ dễ hiểu; người có thẩm quyền quyết định rủi ro kinh doanh cần có căn cứ đó. Không nên để một nhãn mức độ nghiêm trọng hoặc một số điểm tự quyết định thay toàn bộ bối cảnh.

Trước khi ký phạm vi duy trì, cần xác nhận đầu mối nhận báo cáo, phần sửa nào thuộc hỗ trợ, trường hợp nào cần báo giá thêm và ai có quyền triển khai bản cập nhật.

Những điều chưa có con số hoặc thời hạn cần được đưa vào trao đổi, không tự hiểu rằng đối tác luôn trực và xử lý ngay mọi vấn đề. Với doanh nghiệp, giá trị của phần này là tránh khoảng trống trách nhiệm sau ngày nghiệm thu.

Trước khi vận hành, nên thử đường báo cáo một vấn đề: người phát hiện gửi tới đâu, ai đánh giá mức ảnh hưởng, ai có thể hạn chế truy cập và ai thông tin cho người liên quan. Không cần đưa dữ liệu thật nhạy cảm vào buổi diễn tập. Mục tiêu là xác nhận các đầu mối hoạt động và quyền quyết định rõ ràng, thay vì đợi đến sự cố mới tìm ai đang giữ trách nhiệm.

Sau khi đưa vào dùng, cần có người theo dõi thông báo lỗ hổng của các thành phần đang sử dụng và quyết định khi nào phải cập nhật. Phần việc này liên quan đến cả đơn vị vận hành lẫn phạm vi hỗ trợ của đối tác. Tài liệu phải được cập nhật nếu người phụ trách, tài khoản quản lý hoặc cách tiếp nhận sự cố thay đổi.

Theo dõi lỗ hổng và cập nhật hệ thống là công việc cần tiếp tục sau khi bàn giao. Khi thỏa thuận với đối tác, doanh nghiệp nên làm rõ việc nào nằm trong hợp đồng hỗ trợ và việc nào do đội nội bộ đảm nhận. Bài Bảo trì phần mềm gồm những gì? giúp bạn xác định phạm vi này trước khi thống nhất trách nhiệm giữa các bên.

Sau cuộc trao đổi, hai bên nên có một phạm vi chung cho dữ liệu và người dùng cần bảo vệ, những nơi dữ liệu đi qua và các giới hạn phải thực thi. Nội dung chưa quyết định cần có người xác nhận và mốc xử lý. Nhờ đó, yêu cầu bảo mật trở thành phần công việc có thể theo dõi trong dự án.

Kế hoạch kiểm tra cần nêu hạng mục, thời điểm, người thực hiện và bằng chứng phải nhận. Nếu thuê bên kiểm tra độc lập, phải làm rõ phạm vi được phép và bên tiếp nhận phát hiện. Khi còn vấn đề chưa sửa, cần ghi cách giảm thiểu, người chấp nhận và điều kiện xem lại; không chỉ chuyển chúng sang một danh sách rồi coi là xong.

Trước bàn giao, cần xác nhận người sẽ quản lý tài khoản, nhận cảnh báo, lưu bằng chứng kiểm tra và tiếp nhận các vấn đề còn mở. Nếu đội nhận chưa biết thực hiện những việc này, trách nhiệm sau dự án vẫn còn bỏ ngỏ dù phần mềm đã được nghiệm thu.

Để đội nhận có thể thực hiện những trách nhiệm này, việc bàn giao phải bao gồm hướng dẫn, quyền truy cập và các hồ sơ kiểm tra cần thiết. Doanh nghiệp nên xác nhận đội mới sử dụng được những gì đã nhận, thay vì chỉ kiểm đếm tài liệu. Bài Bàn giao phần mềm cần những gì? trình bày cách kiểm tra việc tiếp quản trước khi kết thúc dự án.

Bạn có thể trao đổi với Fenix từ luồng dữ liệu và cách sử dụng dự kiến của phần mềm. Đây là thông tin giúp xác định những yêu cầu cần đưa vào phạm vi phát triển và những phần cần chuyên môn hoặc kiểm tra bổ sung.

Trao đổi nhu cầu với Fenix