Bảo vệ bí mật kinh doanh trong ứng dụng nhắn tin cần một tập hợp biện pháp kiểm soát: quyền truy cập của nhân viên, bảo mật thiết bị, quản lý nhóm, lưu giữ tệp và mã hóa. Khả năng bảo vệ hậu lượng tử có thể quan trọng đối với thông tin cần giữ bí mật lâu dài, nhưng không thay thế các biện pháp này và tự nó không bảo đảm “an toàn cho tổ chức”.
Trước hết, xác định điều gì cần được giữ bí mật
Lập danh mục dữ liệu và các tuyến luân chuyển của chúng: lộ trình sản phẩm, hợp đồng, thông tin khách hàng, khóa truy cập và tệp nghiên cứu không nhất thiết có cùng mức rủi ro. Với mỗi loại, hãy hỏi ai cần xem, việc tiết lộ sẽ gây hậu quả gì và dữ liệu cần được giữ bí mật trong bao lâu.
Hướng dẫn chuyển đổi hậu lượng tử của NIST nhấn mạnh việc xác định tài sản và các thành phần phụ thuộc về mật mã. Nếu thiếu danh mục này, bạn có thể nâng cấp ứng dụng nhắn tin nhưng bản sao của cùng tệp đó trong email, bộ nhớ dùng chung hoặc bản sao lưu cũ vẫn được bảo vệ theo cách khác.
Đừng nhầm mối đe dọa tương lai với rủi ro hôm nay
Trong kịch bản “thu thập hôm nay, giải mã về sau”, kẻ tấn công giữ lại dữ liệu đã mã hóa để chờ khả năng giải mã có thể xuất hiện trong tương lai. Dữ liệu cần giữ bí mật nhiều năm đòi hỏi kế hoạch chuyển đổi sớm hơn. Kịch bản này không có nghĩa là mọi cuộc trò chuyện hiện nay đều có thể bị phá mã.
NIST, trong FIPS 203, đã chuẩn hóa cơ chế ML-KEM. Tiêu chuẩn này xác định một thành phần thiết lập khóa; không thể từ đó suy ra rằng mọi cuộc tấn công trong tương lai đều bất khả thi hoặc toàn bộ sản phẩm đã được phê duyệt.
Trong khi đó, tài khoản của nhân viên đã nghỉ việc, máy tính xách tay nhiễm mã độc và việc chia sẻ nhầm tệp có thể gây lộ thông tin ngay hôm nay. Kế hoạch bảo mật phải bao quát cả hai mốc thời gian.
Danh sách kiểm tra đánh giá ứng dụng nhắn tin doanh nghiệp
| Lĩnh vực | Câu hỏi thực tế | Bằng chứng phù hợp |
|---|---|---|
| Thành viên | Sau khi nhân viên nghỉ việc, quyền truy cập từ các thiết bị của họ sẽ ra sao? | Kiểm thử việc xóa thành viên và các phiên đang hoạt động |
| Nội dung | Văn bản, tệp đính kèm, cuộc gọi và bản ghi được bảo vệ như thế nào? | Tài liệu riêng cho từng phạm vi |
| Khôi phục | Ai nắm giữ cụm từ khôi phục hoặc bản sao lưu? | Quy trình khôi phục đã được thử với dữ liệu không nhạy cảm |
| Thiết bị | Có gì khác nhau giữa điện thoại cá nhân và điện thoại được quản lý? | Chính sách truy cập và cấu hình thực tế |
| Siêu dữ liệu | Những thông tin vận hành nào được ghi nhận và lưu giữ? | Chính sách rõ ràng, có thể kiểm chứng |
| Nâng cấp | Ứng dụng khách cũ hoặc không tương thích sẽ hoạt động thế nào? | Các phiên bản được hỗ trợ và kiểm thử tương thích |
| Sự cố | Ai chịu trách nhiệm xử lý và báo cáo lỗ hổng qua kênh nào? | Quy trình ứng phó và người chịu trách nhiệm cụ thể |
Bảng này đưa ra tiêu chí lựa chọn, không phải kết quả thử nghiệm hay bảng xếp hạng dịch vụ. Các yêu cầu pháp lý và hợp đồng của tổ chức cần được xem xét phù hợp với lĩnh vực hoạt động; tên một thuật toán không chứng minh sự tuân thủ pháp luật.
Livara có vai trò gì trong đánh giá này?
Tài liệu bảo mật của Livara mô tả kiến trúc LVR1 cho cuộc trò chuyện trực tiếp và LGS1 cho nhóm riêng tư. Cũng trên trang đó, thông tin định tuyến và thành viên được phân biệt với nội dung đã mã hóa, đồng thời nêu một ranh giới khác cho chế độ ghi ở phía máy chủ. Đây là mô tả sản phẩm, không phải báo cáo kiểm toán độc lập về bảo mật tổ chức.
Khi đánh giá, hãy gắn từng tuyên bố về tính năng với phiên bản thực tế và bằng chứng tương ứng. Proof Lab hữu ích cho các kiểm tra có phạm vi giới hạn, chẳng hạn đối chiếu tệp với giá trị băm tham chiếu, nhưng không thay thế kiểm thử kiểm soát truy cập, rà soát mã nguồn và đánh giá thiết bị.
Đánh giá riêng tính sẵn sàng khi mạng bị gián đoạn
Mã hóa không thể tạo ra một đường truyền mạng không tồn tại. Việc dịch vụ có hoạt động khi internet quốc tế bị ngắt hay không phụ thuộc vào khả năng truy cập thực tế đến máy chủ, DNS, tuyến mạng và các thành phần phụ thuộc của đăng nhập và thông báo. Không thể từ một thuật toán hậu lượng tử suy ra “hoạt động đầy đủ trong mọi sự cố mất kết nối”.
Để kiểm thử tính liên tục, hãy chạy các tình huống mất internet, chuyển mạng và khôi phục kết nối bằng dữ liệu thử nghiệm. Ghi nhận thời gian khôi phục, tin nhắn chưa được giao và hành vi của người dùng ngoại tuyến. Nếu xác định một tuyến thay thế, hãy xem xét cả tính bảo mật của tuyến đó.
Một lựa chọn tốt cho tổ chức là lựa chọn mà khả năng bảo vệ, giới hạn và hành vi khi xảy ra lỗi đều có thể được giải thích và kiểm thử.
