Vì sao cần mã hóa tệp số liệu thô trước khi gửi qua email

Bạn nên mã hóa tệp số liệu thô trước khi gửi qua email vì một email không chỉ đi từ máy bạn tới máy người nhận: nó nằm lại trong hộp thư đã gửi, trên máy chủ thư của cả hai bên, trên điện thoại, máy tính bảng được đồng bộ, và có thể bị chuyển tiếp mà bạn không biết. Một tệp nén mã hóa AES với mật khẩu gửi qua kênh khác giúp dữ liệu vẫn an toàn ngay cả khi email rơi vào tay người không mong muốn.

Email đi qua những đâu

Ngày nay kết nối giữa người dùng và máy chủ thư, và giữa các máy chủ thư lớn với nhau, phần lớn đã được mã hóa khi truyền (TLS). Tuy vậy, điều đó chỉ bảo vệ email trên đường đi. Khi đến nơi, email được lưu dưới dạng mà nhà cung cấp dịch vụ và bất kỳ ai đăng nhập được hộp thư đều đọc được. Rủi ro thực tế vì vậy nằm ở các điểm cuối:

• Hộp thư của người nhận bị chiếm do mật khẩu yếu hoặc lừa đảo.
• Gõ nhầm địa chỉ, tự động điền chọn sai người có tên giống nhau.
• Người nhận chuyển tiếp cả chuỗi email cho người khác.
• Điện thoại có hộp thư được đồng bộ bị mất.
• Tài khoản email cũ của người đã rời nhóm vẫn còn lưu dữ liệu.

Gửi nhầm địa chỉ là sự cố phổ biến nhất và không công nghệ truyền tải nào cứu được. Nếu tệp đính kèm đã mã hóa, người nhận nhầm chỉ có một tệp không mở được.

Dữ liệu nào cần mã hóa

Các cách mã hóa đơn giản, không cần chuyên môn

Nén thành tệp 7z hoặc zip với AES 256

Phần mềm miễn phí 7-Zip trên Windows (và các công cụ tương đương trên macOS) cho phép nén một hoặc nhiều tệp, đặt mật khẩu và chọn phương thức mã hóa AES-256. Với định dạng 7z, nên đánh dấu tùy chọn mã hóa tên tệp để người không có mật khẩu không thấy cả danh sách tệp bên trong. Lưu ý: kiểu mã hóa zip cũ (ZipCrypto) yếu, hãy chọn AES.

Đặt mật khẩu mở trực tiếp cho tệp Office

Excel, Word bản hiện đại cho phép mã hóa tệp bằng mật khẩu trong phần Thông tin, Bảo vệ tài liệu. Cách này tiện khi chỉ gửi một tệp Excel. Đừng nhầm với tính năng "bảo vệ trang tính" chỉ ngăn sửa ô, không mã hóa nội dung.

Không đính kèm, dùng chia sẻ có phân quyền

Thay vì gửi tệp, tải lên thư mục đám mây của trường, chia sẻ cho đúng địa chỉ email người nhận với quyền truy cập hạn chế, và gửi email chỉ chứa đường dẫn. Ưu điểm lớn: bạn có thể thu hồi quyền bất cứ lúc nào và xem ai đã mở. Kết hợp được với mã hóa tệp nếu dữ liệu đặc biệt nhạy cảm.

Mã hóa đầu cuối email

S/MIME hoặc OpenPGP mã hóa cả nội dung email, nhưng cần cả hai bên cài đặt chứng thư, khóa. Một số tổ chức đã có sẵn hạ tầng này; nếu trường bạn có, hãy dùng. Nếu không, các cách trên thực tế hơn.

Gửi mật khẩu sao cho đúng

Lỗi phổ biến nhất là gửi tệp mã hóa trong một email và mật khẩu trong email tiếp theo cho cùng người. Ai đọc được hộp thư sẽ có cả hai. Nguyên tắc là mật khẩu đi đường khác:

• Nhắn tin hoặc gọi điện cho người nhận.
• Dùng ứng dụng nhắn tin mã hóa đầu cuối; cách chọn và hiểu đúng loại ứng dụng này có trong bài nhắn tin mã hóa đầu cuối hoạt động ra sao.
• Thống nhất trước một mật khẩu khi gặp trực tiếp, đổi theo từng dự án.

Mật khẩu nên dài, gồm nhiều từ ngẫu nhiên. Tệp mã hóa có thể bị thử đoán mật khẩu ngoại tuyến không giới hạn số lần, nên mật khẩu ngắn như ngày sinh sẽ bị bẻ nhanh.

Quy trình mẫu cho nhóm nghiên cứu

1. Thống nhất kênh lưu trữ chính (thư mục đám mây của trường) và chỉ dùng email khi cần gửi ra ngoài.
2. Dữ liệu có định danh chỉ gửi dưới dạng tệp 7z AES-256 có mã hóa tên tệp.
3. Mật khẩu gửi qua ứng dụng nhắn tin, không ghi trong email.
4. Tên tệp không mô tả nội dung nhạy cảm.
5. Khi người nhận đã tải và giải nén, xóa email chứa tệp ở cả hai bên nếu không cần lưu.
6. Ghi lại ai đã nhận dữ liệu gì và khi nào.

Quy trình này phù hợp với các yêu cầu bảo vệ dữ liệu khi làm khảo sát có thông tin người tham gia và đặc biệt quan trọng với nghiên cứu y khoa nhạy cảm.

Những ngộ nhận cần bỏ

• "Email trường thì an toàn": email trường cũng là mục tiêu lừa đảo thường xuyên, như phân tích trong bài về phishing nhắm vào tài khoản edu.
• "Đổi đuôi tệp là giấu được": đổi .xlsx thành .txt không bảo vệ gì cả.
• "Chỉ gửi cho thầy thôi": hộp thư của thầy cô cũng có thể bị chiếm, và thầy cô có thể chuyển tiếp cho hội đồng mà không nghĩ tới tính nhạy cảm.
• "Mã hóa phức tạp lắm": nén 7z có mật khẩu mất chưa tới một phút.

Nếu đã lỡ gửi dữ liệu không mã hóa cho nhầm người

Liên hệ người nhận ngay, đề nghị xóa email và tệp, xác nhận lại bằng văn bản. Dùng tính năng thu hồi thư nếu hệ thống hỗ trợ (chỉ có tác dụng trong một số trường hợp). Báo người hướng dẫn, và nếu dữ liệu có thông tin cá nhân của người tham gia, báo cho đơn vị phụ trách để đánh giá có cần thông báo theo quy định hay không. Ghi nhận sự việc và áp dụng mã hóa cho lần sau.