Email mã hoá cho doanh nghiệp: TLS, S/MIME, PGP và E2EE

Email mã hoá cho doanh nghiệp gồm ba lớp: mã hoá khi truyền (TLS giữa các máy chủ thư và ứng dụng), mã hoá khi lưu (trên ổ đĩa và bản sao lưu của nhà cung cấp), và mã hoá đầu cuối (S/MIME, PGP hoặc hệ thống riêng của nhà cung cấp — chỉ người gửi và người nhận đọc được). Phần lớn doanh nghiệp cần TLS bắt buộc và bảo mật tài khoản tốt; mã hoá đầu cuối hợp với một số trường hợp nhạy cảm cụ thể.

"Email công ty mình có mã hoá không?" không phải câu hỏi có/không. Bài này giải thích từng lớp chống được gì, không chống được gì, và nên chọn thế nào cho vừa đủ.

Ba lớp mã hoá email

Lớp	Bảo vệ cái gì	Ai vẫn đọc được thư	Công nghệ thường gặp
Khi truyền	Thư trên đường đi giữa các máy chủ, giữa thiết bị của bạn và máy chủ	Nhà cung cấp của bạn và của người nhận	TLS, STARTTLS, MTA-STS, DANE
Khi lưu	Dữ liệu trên ổ đĩa, bản sao lưu, phòng khi bị lấy cắp thiết bị lưu trữ	Hệ thống của nhà cung cấp khi đang chạy	Mã hoá ổ đĩa/kho lưu trữ, sao lưu mã hoá
Đầu cuối (E2EE)	Nội dung thư từ người gửi tới người nhận, kể cả với chính các nhà cung cấp	Chỉ người giữ khoá bí mật	S/MIME, OpenPGP, E2EE riêng của nhà cung cấp

Mỗi lớp đối phó một mối đe doạ khác nhau: kẻ nghe lén trên đường mạng, ổ đĩa hay tệp sao lưu bị đánh cắp, hoặc bất kỳ ai ở giữa — kể cả nhà cung cấp email.

Mã hoá khi truyền: lớp ai cũng cần

Email đi theo từng chặng: từ laptop của bạn tới máy chủ của nhà cung cấp (qua IMAP, SMTP), từ máy chủ đó tới máy chủ người nhận (qua SMTP), rồi tới điện thoại người nhận. TLS bảo vệ được từng chặng.

Điểm yếu từ trước tới nay nằm ở chặng giữa hai máy chủ. Các máy chủ dùng STARTTLS để nâng một kết nối thường lên kết nối mã hoá nếu hai bên cùng hỗ trợ. Mặc định cơ chế này là "được thì mã hoá": nếu kẻ tấn công xoá lời mời STARTTLS, nhiều máy chủ lặng lẽ gửi thư dạng không mã hoá.

Hai tiêu chuẩn vá lỗ hổng này:

MTA-STS (RFC 8461) cho phép tên miền công bố chính sách "chỉ giao thư cho máy chủ của tôi qua TLS hợp lệ". Máy chủ gửi có hỗ trợ sẽ không chịu hạ cấp. TLS-RPT gửi báo cáo cho bạn khi có lần giao thư không qua được kiểm tra TLS.
DANE (RFC 7672) dùng bản ghi TLSA có ký DNSSEC để báo cho bên gửi biết chính xác chứng chỉ nào là thật, nên chứng chỉ giả bị từ chối.

Bài MTA-STS là gì giải thích các bản ghi và cách triển khai an toàn.

Mã hoá khi lưu và sao lưu

Mã hoá khi lưu bảo vệ dữ liệu nằm yên trên ổ đĩa, có ích khi phần cứng bị lấy cắp hay tệp sao lưu bị rò rỉ. Nó không ngăn hệ thống đang chạy của nhà cung cấp đọc thư — hệ thống cần đọc để lọc thư rác, quét virus, lập chỉ mục tìm kiếm và hiển thị hộp thư cho bạn.

Hãy hỏi nhà cung cấp hai câu đơn giản: bản sao lưu có được mã hoá không, và khoá giải mã nằm ở đâu? Sao lưu mã hoá đặt ở nơi khác (off-site), khoá tách riêng khỏi tệp sao lưu, là mức nền hợp lý.

Mã hoá đầu cuối: S/MIME, PGP và hệ thống riêng

Mã hoá đầu cuối nghĩa là thư được mã hoá ngay trên thiết bị người gửi và chỉ được giải mã trên thiết bị người nhận. Các máy chủ ở giữa chỉ lưu và chuyển một khối dữ liệu mà chúng không đọc được.

S/MIME dùng chứng chỉ X.509, thường do tổ chức cấp chứng chỉ (CA) phát hành. Outlook, Apple Mail và nhiều ứng dụng thư doanh nghiệp hỗ trợ sẵn, nên S/MIME hợp với tổ chức hoặc đối tác đã quen quản lý chứng chỉ. Điểm trừ: phải xin cấp, gia hạn chứng chỉ, và hai bên phải trao đổi chứng chỉ trước khi gửi thư mã hoá đầu tiên.

OpenPGP (PGP) dùng cặp khoá do người dùng tự tạo. Thunderbird hỗ trợ sẵn, một số nhà cung cấp chú trọng quyền riêng tư cũng xây dựa trên PGP. Linh hoạt và không phụ thuộc CA, nhưng việc xác minh và quản lý khoá phần lớn do người dùng tự lo — khó làm tốt trên quy mô cả công ty.

E2EE riêng của nhà cung cấp. Các dịch vụ chú trọng quyền riêng tư như Proton Mail tự động mã hoá đầu cuối giữa người dùng của họ, và dùng thư có mật khẩu hoặc OpenPGP cho người nhận bên ngoài. Đây là thế mạnh thật sự nếu mục tiêu chính của bạn là giữ bí mật cả với nhà cung cấp. Một số bộ công cụ doanh nghiệp lớn cũng có mã hoá thư hoặc mã hoá phía máy khách ở gói cao hay dạng mua thêm; hãy xem kỹ chúng mã hoá phần nào và ai giữ khoá.

Cái giá của mã hoá đầu cuối

E2EE mạnh nhưng không miễn phí. Trước khi bắt buộc cả công ty, hãy cân nhắc những gì phải đánh đổi:

Lớp bảo vệ trên máy chủ yếu đi. Máy chủ không đọc được thư thì không quét được mã độc, liên kết lừa đảo hay thư rác. Kẻ tấn công hoàn toàn có thể giấu mã độc trong thư mã hoá.
Tìm kiếm, trợ lý AI, xem trước chạy trên máy chủ không nhìn thấy nội dung đã mã hoá.
Lưu trữ tuân thủ và eDiscovery khó hơn. Một kho lưu trữ toàn bản mã chỉ có ích nếu nhiều năm sau vẫn có người giải mã được.
Mất khoá là mất dữ liệu. Người dùng làm mất khoá bí mật mà không có bản ký gửi khoá thì thư mã hoá của họ coi như mất.
Siêu dữ liệu vẫn lộ. Người gửi, người nhận, thời gian và — ở nhiều cấu hình PGP — cả tiêu đề thư không được mã hoá.
Người nhận phải tham gia. Mọi đối tác bên ngoài phải có phần mềm tương thích hoặc làm theo quy trình cổng web/mật khẩu.

Còn một điểm lớn hơn: phần lớn sự cố email trên thực tế đến từ mật khẩu bị đánh cắp và lừa đảo, không phải từ việc ai đó nghe lén đường truyền. Nếu kẻ tấn công đăng nhập được dưới tên chị Lan kế toán, E2EE không giúp gì — họ đọc được mọi thứ chị Lan đọc được. Bảo mật tài khoản và chống lừa đảo thường mang lại nhiều lợi ích hơn trên mỗi giờ công. Xem bảo mật email doanh nghiệp và chống lừa đảo email doanh nghiệp.

Zomail có gì và không có gì

Nói rõ Zomail đứng ở đâu:

Zomail có

TLS cho kết nối từ ứng dụng của bạn (IMAP, SMTP, CalDAV/CardDAV, webmail).
TLS giữa các máy chủ thư, với MTA-STS ở chế độ enforce (bắt buộc) và bản ghi TLS-RPT được hướng dẫn cài trên trang DNS.
Kiểm tra DANE khi gửi đi: nếu tên miền người nhận công bố bản ghi DANE, Zomail đối chiếu chứng chỉ với bản ghi đó.
Sao lưu mã hoá đặt ở nơi khác, cùng lọc thư rác, virus và lừa đảo nhiều lớp cho mọi thư.
Bảo vệ tài khoản: xác thực 2 bước (bắt buộc với quản trị viên), mật khẩu ứng dụng, đăng xuất từ xa, đăng nhập một lần (SSO) với Google Workspace hoặc Microsoft Entra ID.

Zomail không có

Mã hoá đầu cuối.
Tính năng S/MIME hay PGP trong webmail và ứng dụng Zomail: không quản lý khoá hay chứng chỉ, không đọc hay tạo thư mã hoá ở đó.

Nếu mã hoá đầu cuối giữa chính người dùng của bạn là yêu cầu bắt buộc, một nhà cung cấp chuyên về quyền riêng tư có lẽ hợp hơn — chúng tôi muốn nói thẳng điều đó.

Cách làm thực tế với thông tin nhạy cảm

Nhiều doanh nghiệp chỉ cần gửi một số tệp nhạy cảm (bảng lương, hợp đồng, bản chụp giấy tờ tuỳ thân) chứ không cần mã hoá mọi thứ. Vài cách thực tế:

Gửi liên kết thay vì đính kèm. Tải tệp lên Drive và gửi liên kết chia sẻ có hạn dùng. Tệp không nằm lại trong mọi hộp thư nó đi qua, và bạn thu hồi được quyền truy cập.
Mã hoá chính tệp đó. Nén có mật khẩu hoặc PDF có mật khẩu, còn mật khẩu gửi qua kênh khác như gọi điện hay tin nhắn.
Dùng S/MIME hoặc PGP với từng đối tác cụ thể, khi cả hai bên đều dùng ứng dụng máy tính hỗ trợ và thống nhất cách quản lý khoá.
Khoá chặt tài khoản. Bắt buộc xác thực 2 bước, rà soát quy tắc chuyển tiếp, đào tạo nhân viên nhận diện lừa đảo. Việc này bảo vệ mọi thứ, có mã hoá hay không.

Nếu mã hoá khi truyền bắt buộc, sao lưu mã hoá và lớp chống lừa đảo vững chắc là đủ cho nhu cầu của bạn, Zomail có sẵn những thứ đó, tính phí theo mỗi hộp thư mỗi tháng — giá hiện hành trên trang bảng giá. Cách bật các cài đặt có trong hướng dẫn chống spam và lừa đảo.

FAQ

Email doanh nghiệp có được mã hoá sẵn không?

Kết nối giữa ứng dụng của bạn và một nhà cung cấp uy tín gần như luôn được mã hoá bằng TLS. Giữa các máy chủ, thư dùng TLS khi hai bên cùng hỗ trợ; MTA-STS và DANE biến việc đó thành bắt buộc. Nội dung thư không được mã hoá đầu cuối, trừ khi bạn dùng S/MIME, PGP hoặc nhà cung cấp chuyên về E2EE.

TLS khác mã hoá đầu cuối thế nào?

TLS mã hoá từng chặng đường đi, nên nhà cung cấp đọc được thư ở mỗi điểm dừng. Mã hoá đầu cuối mã hoá chính bức thư, chỉ người gửi và người nhận đọc được, máy chủ thì không.

Zomail có hỗ trợ S/MIME hay PGP không?

Không. Zomail cung cấp TLS khi truyền với MTA-STS bắt buộc và kiểm tra DANE khi gửi, cùng sao lưu mã hoá, nhưng không có mã hoá đầu cuối, S/MIME hay PGP.

Doanh nghiệp nhỏ có cần email mã hoá đầu cuối không?

Với thư từ hằng ngày thì thường không. TLS bắt buộc, xác thực 2 bước và chống lừa đảo tốt đã xử lý những rủi ro phổ biến nhất. Mã hoá đầu cuối đáng dùng cho quy trình cụ thể hoặc dữ liệu chịu quy định chặt, khi bạn quản lý được khoá và chấp nhận các đánh đổi.

Gmail hay Outlook có mã hoá email không?

Cả hai dùng TLS khi truyền và mã hoá dữ liệu khi lưu. Tài khoản thông thường không mã hoá đầu cuối, dù mỗi bên đều có S/MIME hoặc tính năng mã hoá bổ sung ở một số gói doanh nghiệp.