Mã hóa dữ liệu doanh nghiệp: hướng dẫn cho chat khách hàng

Mỗi đơn hàng chốt qua WhatsApp, mỗi tin nhắn Instagram và mỗi cuộc hỗ trợ trên Telegram đều để lại dữ liệu khách hàng: số điện thoại, địa chỉ giao hàng, lịch sử chat và những access token đang nối các kênh của bạn lại với nhau. Mã hóa dữ liệu doanh nghiệp biến khối dữ liệu đó thành bản mã không ai đọc nổi nếu không giữ khóa, cả khi nó chạy qua mạng lẫn khi nó nằm yên trong cơ sở dữ liệu và bản sao lưu.

Những điều cần nhớ

Mã hóa dữ liệu doanh nghiệp có hai lớp: mã hóa khi truyền tải (TLS) bảo vệ dữ liệu đang di chuyển, còn mã hóa khi lưu trữ (thường là AES) bảo vệ dữ liệu đã được lưu trữ.
Access token của kênh, API key và webhook secret đều là thông tin xác thực. Một token bị lộ đủ để kẻ tấn công hành động nhân danh doanh nghiệp bạn, nên hãy mã hóa chúng ở mức từng trường dữ liệu.
Mã hóa ổ đĩa bảo vệ một ổ cứng bị lấy mất, chứ không bảo vệ một máy chủ đang chạy. Mã hóa ở mức trường, với khóa để bên ngoài cơ sở dữ liệu, vẫn bảo vệ các trường đó trong một bản dump bị rò rỉ.
AES-256-GCM là mã hóa có xác thực: vừa giấu dữ liệu vừa phát hiện can thiệp, và nó dựa trên việc không bao giờ dùng lại một nonce với cùng một khóa.
Mã hóa không chặn được người đã có quyền giải mã. Một nền tảng trả lời tự động bằng AI buộc phải đọc tin nhắn mới trả lời được, nên kiểm soát truy cập và thời hạn lưu trữ quan trọng ngang thuật toán mã hóa.

Mã hóa dữ liệu doanh nghiệp cần bao gồm những gì ở một công ty bán qua chat

Một công ty bán hàng qua chat, chẳng hạn bằng hộp thư AI cho WhatsApp, có danh mục dữ liệu của riêng mình:

Thông tin xác thực và bí mật. Access token của Facebook Page và WhatsApp Business, bot token Telegram, key của nhà cung cấp AI, key của cổng thanh toán và webhook secret.
Dữ liệu cá nhân (PII) của khách hàng. Số điện thoại, email, địa chỉ giao hàng và mã khách hàng. Trong bán hàng qua chat, số điện thoại thường chính là danh tính của khách.
Lịch sử chat và tệp đính kèm. Nội dung hội thoại, tin nhắn thoại, ảnh và hóa đơn khách gửi sang.
Mật khẩu nhân viên. Những giá trị này cần được băm (hash), không phải mã hóa (nói kỹ hơn ở dưới).
Thiết bị của nhân viên. Laptop và điện thoại dùng để mở hộp thư hoặc đang giữ file xuất. Hãy bật FileVault hoặc BitLocker, đặt mã khóa máy và bật xóa từ xa.
Các bản sao. Bản sao lưu, file CSV xuất ra, log và cơ sở dữ liệu staging, vốn thường được giám sát lỏng lẻo hơn hệ thống production.

Một nguyên tắc đơn giản cho việc bảo mật dữ liệu khách hàng: bảo vệ ở mức từng trường mọi thứ cấp quyền truy cập hoặc nhận diện một con người, và cho mọi bản sao mức bảo vệ ngang với bản gốc.

Mã hóa khi lưu trữ và mã hóa khi truyền tải khác nhau thế nào

Mã hóa khi truyền tải bảo vệ dữ liệu trong lúc nó đi giữa trình duyệt, máy chủ của bạn và các API bên thứ ba. Mã hóa khi lưu trữ bảo vệ dữ liệu nằm trên ổ đĩa, trong cơ sở dữ liệu và trong bản sao lưu.

Khía cạnh	Mã hóa khi truyền tải	Mã hóa khi lưu trữ
Chống lại	Nghe lén, can thiệp, máy chủ giả mạo	Ổ đĩa bị lấy cắp, bản dump rò rỉ, bản sao lưu bị lộ
Chuẩn thường dùng	TLS 1.2 hoặc TLS 1.3	AES-256, thường là AES-256-GCM
Áp dụng ở đâu	Trình duyệt tới ứng dụng, webhook, lệnh gọi API	Ổ đĩa, cơ sở dữ liệu, từng trường riêng lẻ, bản sao lưu
Không bao gồm	Dữ liệu sau khi đã tới nơi và được giải mã	Dữ liệu đang được một ứng dụng chạy sử dụng

NIST SP 800-52 Rev. 2 yêu cầu máy chủ TLS của chính phủ Mỹ phải hỗ trợ TLS 1.2 và hỗ trợ TLS 1.3 chậm nhất từ tháng 1/2024. Đó là mức nền hợp lý cho mọi doanh nghiệp: chấp nhận TLS 1.2 và 1.3, tắt mọi phiên bản cũ hơn.

TLS chỉ bảo vệ chặng đường đi. WhatsApp Cloud API gửi webhook qua HTTPS, và tài liệu của Meta giải thích rằng Cloud API giải mã tin nhắn đến rồi chuyển tiếp cho doanh nghiệp, giữ tin nhắn tối đa 30 ngày. Sau đó, chuyện lưu trữ và kiểm soát truy cập mới là thứ quyết định.

Mã hóa ổ đĩa, cơ sở dữ liệu và từng trường dữ liệu

Mã hóa khi lưu trữ có nhiều lớp:

Mã hóa ổ đĩa hoặc volume bảo vệ một ổ cứng bị lấy cắp hoặc bị thanh lý. Trong lúc máy chủ chạy, hệ điều hành tự giải mã dữ liệu, nên kẻ tấn công đã vào được bên trong máy chủ vẫn thấy dữ liệu thô.
Mã hóa file cơ sở dữ liệu vướng đúng giới hạn đó: ai truy vấn được cơ sở dữ liệu thì nhận về dữ liệu thô.
Mã hóa ở mức trường mã hóa từng cột cụ thể, chẳng hạn một token hay một số điện thoại, ngay trong ứng dụng trước khi chúng xuống cơ sở dữ liệu. Khóa nằm ở nơi khác, nên một bản dump rò rỉ hay một bản sao lưu bị chép đi chỉ hiện ra bản mã ở những trường đó.

Cái giá phải trả là khả năng tìm kiếm: bạn không chạy được bộ lọc SQL thông thường trên một cột đã mã hóa. Cách làm thực tế là dành mã hóa mức trường cho các bí mật và những thông tin liên hệ rủi ro cao. Đội nào buộc phải tra cứu khách theo số điện thoại hay email có thể lưu thêm một hash có khóa (chỉ mục mù, blind index) cạnh bản mã và tìm trên đó.

AES-256-GCM: độ dài khóa và chế độ hoạt động

AES được định nghĩa trong FIPS 197 với khóa 128, 192 và 256 bit. AES-256 dùng loại khóa dài nhất trong ba loại.

Chế độ hoạt động quan trọng không kém độ dài khóa. GCM (NIST SP 800-38D) là mã hóa có xác thực: nó giữ dữ liệu bí mật và phát hiện được việc ai đó sửa bản mã. Đừng bao giờ dùng lại một nonce với cùng một khóa: dùng lại nonce phá vỡ các bảo đảm của GCM, nên hãy để một thư viện được bảo trì tốt sinh nonce, và tuyệt đối không tự viết mã hóa của riêng mình.

Cách lưu API key và access token an toàn

Chọn theo tiêu chí bạn có cần lấy lại giá trị gốc hay không:

Mã hóa những bí mật bạn phải gửi lại cho bên khác: access token của WhatsApp và Instagram, bot token Telegram, key của nhà cung cấp AI và key thanh toán. Dùng AES-GCM ở mức trường với khóa giữ bên ngoài cơ sở dữ liệu.
Băm (hash) những bí mật bạn chỉ cần đối chiếu: mật khẩu, API key của đối tác và mã dùng một lần. Một hash không giải ngược về giá trị gốc được, nhưng giá trị ngắn hoặc dễ đoán vẫn bị dò ra, nên hãy dùng hàm băm chậm như Argon2id hoặc bcrypt cho mật khẩu và HMAC có khóa cho mã xác thực.
Giữ chúng ngoài log, ngoài thông báo lỗi, ngoài analytics và ngoài URL.
Giới hạn phạm vi và xoay vòng. Chỉ xin đúng những quyền một token cần, và thay token khi có người từng nắm quyền rời đi.

Mã hóa khi lưu trữ không bảo vệ được một token trong lúc nó nằm ở dạng đã giải mã trong bộ nhớ giữa một lệnh gọi API. Gia cố bảo mật máy chủ và áp dụng đặc quyền tối thiểu là cách giảm rủi ro đó.

Quản lý khóa mã hóa: những điều cơ bản

Mã hóa chỉ mạnh bằng chỗ bạn cất khóa. Kiểu hỏng kinh điển là để khóa ngay cạnh dữ liệu, trong cùng cơ sở dữ liệu hoặc trong một file cấu hình đã commit.

Tách khóa khỏi dữ liệu. Giữ khóa trong một trình quản lý bí mật, một KMS hoặc trong cấu hình máy chủ mà cơ sở dữ liệu không với tới.
Dùng mã hóa lồng (envelope encryption) khi quy mô lớn. Một khóa chủ mã hóa các khóa dữ liệu, nên xoay vòng khóa chủ không đồng nghĩa với việc mã hóa lại toàn bộ.
Dẫn xuất khóa riêng cho từng mục đích bằng một hàm dẫn xuất khóa như HKDF.
Lên kế hoạch xoay vòng và khôi phục. Mất khóa là mất dữ liệu, kể cả dữ liệu trong bản sao lưu.

Kiểm soát truy cập và đặc quyền tối thiểu: mã hóa là chưa đủ

Mã hóa chặn những ai không có khóa, chứ không chặn người hay hệ thống đã được phép giải mã. Một nền tảng trả lời tự động bằng AI phải đọc được tin nhắn của khách mới viết được câu trả lời, nên máy chủ của nó xử lý tin nhắn ở dạng đọc được.

Logic đó đúng cả ở phía trên. Tài liệu bảo mật của WhatsApp không xem các cuộc chat với doanh nghiệp dùng Cloud API là mã hóa đầu cuối, vì tin nhắn không được chuyển thẳng tới một điểm cuối do doanh nghiệp kiểm soát. Hãy đọc WhatsApp Business Cloud API và Business App trước khi chọn mô hình.

Vậy nên lớp tiếp theo là chuyện ai chạm được vào dữ liệu:

Kiểm soát truy cập theo đặc quyền tối thiểu: cho mỗi đồng nghiệp vai trò nhỏ nhất mà vẫn làm được việc. Một nhân viên trực chat không cần quyền xem thanh toán.
Đăng nhập chặt chẽ: thêm một bước xác minh thứ hai và thu hồi phiên khi đăng xuất.
Cô lập theo doanh nghiệp: mỗi request phải chứng minh được người gọi thuộc về doanh nghiệp đó.
Nhật ký kiểm toán và thời hạn lưu: ghi lại các thao tác đặc quyền, và chỉ giữ lịch sử chat đúng khoảng thời gian bạn cần.

Sao lưu, xuất dữ liệu và thời hạn lưu trữ

Bản sao lưu là bản sao đầy đủ của dữ liệu khách hàng, thường được giữ lâu hơn và được giám sát ít kỹ hơn hệ thống production. Hãy mã hóa file sao lưu, giới hạn ai được tải về, diễn tập khôi phục kèm cả khôi phục khóa, và xóa những file CSV cũ từng được gửi qua email hay qua chat.

Mã hóa còn có sức nặng pháp lý. Điều 32 GDPR nêu mã hóa như một biện pháp bảo mật, và Điều 34(3)(a) cho phép bên kiểm soát dữ liệu không phải thông báo cho cá nhân bị ảnh hưởng khi mã hóa đã khiến dữ liệu trở nên không thể hiểu được với người không có thẩm quyền. Nghĩa vụ theo Điều 33 là thông báo cho cơ quan giám sát trong vòng 72 giờ kể từ khi biết về sự cố, và đó là nghĩa vụ riêng. PDPL của Ả Rập Xê Út và KVKK của Thổ Nhĩ Kỳ cũng đặt hạn 72 giờ với cơ quan quản lý.

Đây là thông tin chung, không phải tư vấn pháp lý. Việc GDPR hay một luật khác có áp dụng hay không, và một miễn trừ có phù hợp với một sự cố cụ thể hay không, còn tùy hoàn cảnh của bạn, nên hãy hỏi luật sư có chuyên môn.

Những câu hỏi nên đặt cho bất kỳ nhà cung cấp chat hay CRM nào

Trước khi nối các kênh vào, hãy dùng bộ câu hỏi bảo mật dành cho nhà cung cấp chatbot này như một bảng hỏi bằng văn bản:

Các endpoint của bên bạn chấp nhận những phiên bản TLS nào?
Dữ liệu nào được mã hóa khi lưu trữ, và ở lớp nào? Có bao gồm nội dung tin nhắn không?
Token của kênh và API key có được mã hóa ở mức trường không, và khóa được giữ ở đâu?
Bản sao lưu có được mã hóa không, và ai truy cập được?
Nhân viên của bên bạn có đọc được hội thoại của chúng tôi không, và việc truy cập đó có được ghi log không?
Chúng tôi đặt được những vai trò và quyền nào cho đội của mình?
Dữ liệu của chúng tôi được cô lập khỏi khách hàng khác bằng cách nào?
Hội thoại của chúng tôi có bị dùng để huấn luyện mô hình AI không, bởi bên bạn hoặc bởi các nhà cung cấp AI của bên bạn?
Bên bạn dùng những nhà xử lý phụ nào, và dữ liệu được lưu ở đâu?
Bên bạn có ký DPA không, và sau khi chúng tôi rời đi thì dữ liệu bị xóa nhanh thế nào?

Hãy cảnh giác với những câu trả lời kiểu "mã hóa cấp độ quân sự" hay "toàn bộ dữ liệu được mã hóa hoàn toàn". Một nhà cung cấp đáng tin sẽ nói rõ thuật toán, lớp áp dụng và cả những chỗ còn hở.

Raabt hiện mã hóa và bảo vệ những gì

Mỗi mục dưới đây phản ánh đúng mã nguồn của Raabt tính đến tháng 9/2026.

Mã hóa ở mức trường: các trường nhạy cảm được mã hóa ở tầng ứng dụng bằng AES-256-GCM. Bản ghi mới dùng khóa dẫn xuất qua HKDF-SHA256, còn giá trị cũ được mã hóa lại bằng khóa đó ở lần lưu tiếp theo. Ứng dụng từ chối khởi động nếu không có khóa dài tối thiểu 32 ký tự.
Những gì được mã hóa: thông tin xác thực và token (access token của các kênh Facebook, Instagram, WhatsApp và Telegram, API key của nhà cung cấp AI và cổng thanh toán, webhook secret) cùng một số thông tin liên hệ được chọn (số điện thoại, email và địa chỉ giao hàng của khách).
Băm: mật khẩu dùng Argon2id (19 MiB bộ nhớ, 2 vòng lặp), và các hash bcrypt cũ được nâng cấp khi đăng nhập. Phần bí mật của API key đối tác chỉ được lưu dưới dạng hash SHA-256.
Đăng nhập: đăng nhập bằng email và mật khẩu đòi thêm một mã dùng một lần gửi tới email của người dùng trước khi phiên được cấp (đăng nhập bằng Google không dùng mã này). Mã chỉ được lưu dưới dạng hash HMAC-SHA256, có hạn dùng và chỉ dùng được một lần.
Quyền của đội: bốn vai trò (owner, admin, agent, viewer) với quyền theo từng mục. Quyền thanh toán không ủy nhiệm được cho người không phải owner.
Cô lập: các endpoint của doanh nghiệp xác nhận người gọi là thành viên đang hoạt động của doanh nghiệp đó, nếu không thì trả về "not found".
Webhook và tệp đính kèm: webhook của Meta bị từ chối nếu thiếu chữ ký X-Hub-Signature-256 hợp lệ, webhook Telegram bắt buộc có secret token, và tệp đính kèm chỉ được phục vụ qua URL có chữ ký và có hạn.
Hạ tầng: ứng dụng không phơi trực tiếp ra Internet; lưu lượng công khai đi vào qua một Cloudflare Tunnel. Log lỗi cơ sở dữ liệu không bao giờ kèm tham số truy vấn, nên số điện thoại và email không lọt vào những log đó.
Nhật ký kiểm toán của quản trị nền tảng: thao tác của quản trị viên nền tảng được ghi vào một nhật ký kiểm toán chỉ ghi thêm (ai, làm gì, khi nào, IP, kèm ảnh chụp trước/sau và đã che các bí mật). Đây không phải nhật ký tin nhắn của khách hàng.

Điều mà mã hóa không làm được ở đây: một hộp thư AI phải đọc nội dung tin nhắn mới viết được câu trả lời, nên nội dung hội thoại được xử lý ở dạng đọc được trên máy chủ. Chính vì vậy mà các điểm về kiểm soát truy cập, thời hạn lưu trữ và sao lưu ở trên quan trọng ngang thuật toán mã hóa bạn chọn.

Yêu cầu xóa dữ liệu từ Meta trả về một mã xác nhận kèm liên kết tra trạng thái trên trang xóa dữ liệu của chúng tôi. Xóa tài khoản đòi mật khẩu cộng một mã dùng một lần gửi qua email, và tài khoản sẽ bị vô hiệu hóa cùng với việc email bị ẩn danh.

Checklist mã hóa dữ liệu doanh nghiệp: thứ tự triển khai cho đội nhỏ

Mã hóa dữ liệu cho doanh nghiệp nhỏ hiệu quả nhất khi làm theo một thứ tự cố định, bắt đầu từ thứ gây thiệt hại nặng nhất nếu rò rỉ:

Phục vụ mọi thứ qua HTTPS, chỉ với TLS 1.2 hoặc 1.3.
Bật mã hóa toàn ổ đĩa và khóa màn hình trên mọi thiết bị có mở chat khách hàng.
Chuyển token và API key sang mã hóa mức trường với khóa để riêng.
Băm mật khẩu bằng Argon2id hoặc bcrypt và thêm một bước đăng nhập thứ hai.
Mã hóa số điện thoại, email và địa chỉ của khách hàng.
Mã hóa bản sao lưu, đặt vai trò theo đặc quyền tối thiểu và đặt thời hạn lưu lịch sử chat.
Gửi bộ câu hỏi cho nhà cung cấp tới mọi công cụ chat, CRM và AI mà bạn đang dùng.

Câu hỏi thường gặp

Doanh nghiệp cần mã hóa những dữ liệu nào?

Bắt đầu từ mọi thứ cấp quyền truy cập hoặc nhận diện một con người: token của kênh, API key, webhook secret, và số điện thoại, email, địa chỉ của khách hàng. Sau đó tới lịch sử chat, thiết bị nhân viên và mọi bản sao lưu hay file xuất.

Mã hóa khi lưu trữ và mã hóa khi truyền tải khác nhau thế nào?

Mã hóa khi truyền tải, thường là TLS, bảo vệ dữ liệu đang đi giữa thiết bị, máy chủ và API. Mã hóa khi lưu trữ, thường là AES, bảo vệ dữ liệu đã được lưu.

Mã hóa AES-256 có đủ để bảo vệ dữ liệu khách hàng không?

AES-256 rất mạnh, nhưng thuật toán hiếm khi là điểm yếu. Những chỗ hay hỏng là lưu khóa sơ sài, dùng lại nonce, cho nhân viên quyền quá rộng và bản sao lưu không được bảo vệ.

Lưu API key và access token thế nào cho an toàn?

Mã hóa những token bạn phải dùng lại bằng AES-GCM ở mức trường và giữ khóa bên ngoài cơ sở dữ liệu. Băm những bí mật bạn chỉ cần đối chiếu, như mật khẩu và API key của đối tác.

Dùng HTTPS thì dữ liệu trên máy chủ đã được bảo vệ chưa?

Chưa. HTTPS chỉ bảo vệ dữ liệu khi truyền tải. Trên máy chủ, mức an toàn phụ thuộc vào mã hóa khi lưu trữ, kiểm soát truy cập và cách xử lý bản sao lưu.

Nên hỏi nhà cung cấp chatbot hay CRM những gì về bảo mật?

Hỏi họ chấp nhận phiên bản TLS nào, những gì được mã hóa khi lưu trữ và ở lớp nào, khóa được giữ ở đâu, việc nhân viên truy cập hội thoại có được ghi log không, nhà xử lý phụ của họ là ai và dữ liệu lưu ở đâu, hội thoại có dùng để huấn luyện mô hình AI không, và họ có ký DPA kèm thời hạn xóa dữ liệu hay không.

Sẵn sàng đưa các cuộc chat của bạn lên một hộp thư AI có mã hóa access token của kênh và những thông tin liên hệ khách hàng được chọn? Bắt đầu miễn phí.