Martin Hellman góp phần định hình trao đổi khóa để những người lạ có thể chia sẻ bí mật qua mạng thù địch. Xem cách nó làm nền tảng cho TLS, VPN và niềm tin hiện đại.
Khi bạn gửi một tin nhắn qua internet, thường nó đi qua các mạng bạn không sở hữu và không thể kiểm tra. Đó là vấn đề cốt lõi: bạn muốn một cuộc trò chuyện riêng tư, nhưng “phòng” bạn đang nói chuyện là nơi công cộng.
Mạng thù địch không nhất thiết do một kẻ ác điều hành. Nó đơn giản có nghĩa là đường truyền giữa bạn và người kia bao gồm các bên trung gian có thể quan sát, sửa đổi, hoặc chuyển hướng những gì bạn gửi.
Hãy nghĩ tới:
Trên một mạng mở, “niềm tin” không phải mặc định. Nếu bạn gửi bí mật ở dạng văn bản thuần, bạn thực tế đang trao bản sao cho mọi điểm dừng trên đường đi.
Trong nhiều thập kỷ, truyền thông an toàn gặp một nút thắt: để dùng mã hóa, hai bên phải cùng chia sẻ một khóa bí mật. Nhưng làm sao bạn chia sẻ khóa đó nếu mạng đang bị giám sát?
Đây là lúc Martin Hellman (cùng với Whitfield Diffie và Ralph Merkle) thay đổi hướng phát triển của mật mã. Trao đổi khóa cho phép hai bên thiết lập bí mật chung qua một kênh không an toàn—mà không cần gặp nhau trước đó.
Bạn dựa vào tư duy này mỗi khi dùng HTTPS, nhiều ứng dụng nhắn tin an toàn và VPN.
Bài viết này tập trung vào khái niệm—không đi sâu toán học—để bạn hiểu điều gì đang xảy ra khi trình duyệt báo “Secure” và tại sao niềm tin đó là được tạo ra chứ không phải mặc định.
Trước khi người ta nói về “khóa công khai,” hầu hết mã hóa thực tế là mật mã đối xứng: cả hai bên dùng cùng một khóa bí mật để khóa và mở thông điệp. Nếu bạn từng dùng mật khẩu để mở một file được mã hóa, bạn đã dùng ý tưởng tương tự.
Trong thời gian dài, mật mã tập trung vào hai việc: làm cho hệ mã khó bẻ hơn và quản lý khóa cẩn thận.
Mật mã đối xứng hấp dẫn vì hiệu quả. Nó có thể bảo vệ khối lượng dữ liệu lớn nhanh chóng, nên vẫn là nền tảng của hầu hết kết nối an toàn ngày nay.
Nhưng mật mã đối xứng có một yêu cầu nghiêm ngặt: cả hai bên phải đã chia sẻ khóa. Điều đó có nghĩa phần khó nhất thường không phải là mã hóa—mà là khâu chuẩn bị.
Hãy tưởng tượng Alice muốn gửi Bob một tin nhắn mã hóa qua mạng có thể bị giám sát. Nếu Alice đơn giản gửi khóa đối xứng cho Bob, kẻ nghe lén cũng có thể sao chép. Nếu họ chưa có khóa chung, họ cần một kênh an toàn khác để chuyển khóa.
Điều này tạo ra vòng tuần hoàn:
Giống như cố gắng thống nhất một mật khẩu qua điện thoại mà bạn nghi ngờ đang bị ghi âm. Nói mật khẩu sẽ vô hiệu mục đích. Gửi bằng thư có thể hiệu quả—nhưng chỉ khi bạn tin bưu điện và không ai mở phong bì.
Ở quy mô nhỏ, tổ chức giải quyết bằng đưa thư, sách mã chia sẻ trước, thiết bị phần cứng hoặc mạng nội bộ kiểm soát chặt. Ở quy mô internet—nơi máy tính của người lạ phải kết nối an toàn trong vài giây—cách tiếp cận này tan rã.
Không có cách thiết lập bí mật qua mạng mở, giao tiếp an toàn bị giới hạn trong môi trường nơi khóa được phân phối trước. Điều đó có nghĩa:
Nút thắt khóa chia sẻ này là bức tường mà ý tưởng trao đổi khóa—gắn với công trình định hướng thời Martin Hellman—được thiết kế để vượt qua.
Martin Hellman là nhà khoa học máy tính có tên gắn với một bước ngoặt trong mật mã: giúp người lạ thiết lập bí mật trên mạng mở. Nghe có vẻ bình thường bây giờ, nhưng nó trả lời một vấn đề thực tế mà các hệ thống mạng sơ khai không thể giải quyết gọn.
Trước thời Hellman, giao tiếp an toàn chủ yếu giả định một bí mật được sắp xếp trước: hai bên phải gặp (hoặc dùng đưa thư tin cậy) để trao đổi khóa trước. Mô hình đó phù hợp nhóm nhỏ, nhưng khó mở rộng khi bạn muốn hàng triệu thiết bị và người dùng giao tiếp an toàn qua mạng thù địch.
Đóng góp cốt lõi của Hellman—nổi tiếng nhất qua trao đổi Diffie–Hellman với Whitfield Diffie—đã chuyển câu hỏi từ “Làm sao vận chuyển bí mật?” sang “Làm sao tạo một bí mật chung mới ngay cả khi có người nghe?”
Bước đột phá không chỉ là ý tưởng trừu tượng. Nó trở thành thành phần thực tế mà các hệ thống thật có thể triển khai, cho phép phiên bảo mật được tạo theo yêu cầu. Điều này nối liền mật mã học học thuật và kỹ thuật mạng: bạn có thể thiết kế giao thức giả sử mạng bị giám sát, nhưng vẫn bảo vệ tính bảo mật.
Về khái niệm, “mật mã khóa công khai” có nghĩa bạn có thể công bố một phần thông tin (bên “công khai”) trong khi giữ một bí mật liên quan riêng tư. Người khác dùng thông tin công khai để tương tác an toàn với bạn—mà không học được bí mật riêng. Trong trao đổi khóa, thông tin công khai đó cho phép hai bên đồng ý một khóa phiên chung, thay vì gửi một khóa.
Cũng cần nhắc rằng đây không phải nỗ lực một mình hay phép màu bất ngờ: những người cùng thời như Ralph Merkle khám phá hướng đi tương tự, và cộng đồng nghiên cứu đã tinh chỉnh và kiểm tra các ý tưởng này. Kết quả là nền tảng cho cách thiết lập niềm tin trực tuyến ở quy mô lớn.
Mục tiêu của trao đổi khóa dễ nói nhưng khó đạt: Alice và Bob muốn có cùng một khóa bí mật ngay cả khi kẻ nghe lén có thể xem mọi thứ họ gửi. Họ được phép nói công khai; họ chỉ không muốn ai khác biết bí mật cuối cùng.
Hãy tưởng tượng Alice và Bob trên một mạng Wi‑Fi mở. Eve nghe lén mọi tin nhắn. Alice và Bob không thể bắt đầu bằng cách chia sẻ mật khẩu—vì điều đó sẽ cần một kênh an toàn mà họ không có.
Thay vào đó, họ dùng một mánh “pha trộn” khéo léo:
Cuối cùng, Alice và Bob đạt đến một màu cuối cùng giống nhau, đó trở thành khóa bí mật chung.
Eve thấy quy tắc công khai và các kết quả pha đi qua lại. Eve có thể sao chép, lưu trữ và phát lại các thông điệp đó.
Những gì Eve không thể làm (với tham số đủ mạnh) là đảo ngược pha trộn để phục hồi nguyên liệu riêng. Đó là ý tưởng cốt lõi: chiều xuôi thì dễ, chiều ngược thì về mặt tính toán khó—một bài toán một chiều thực dụng.
Khóa chung cuối cùng thường không được dùng trực tiếp để mã hóa toàn bộ cuộc trò chuyện bằng các phương pháp trao đổi khóa. Thay vào đó, nó được đưa vào bước dẫn xuất khóa rồi dùng cho mã hóa đối xứng nhanh (loại hiệu quả cho khối lượng dữ liệu lớn). Trao đổi khóa là cây cầu giúp cả hai bên đến cùng một bí mật—mà không bao giờ gửi bí mật đó qua mạng.
Trao đổi khóa giải quyết một vấn đề rất cụ thể: làm thế nào hai bên đồng ý một bí mật trong khi có người nghe. Nhưng nhiều cuộc tấn công thực sự không chỉ là “ai đó nghe” mà là “ai đó ngồi giữa”.
Trong kịch bản man-in-the-middle, kẻ tấn công chuyển tiếp tin nhắn giữa bạn và server trong khi lặng lẽ sửa đổi chúng. Nếu bạn cố gắng trao đổi khóa mà không kiểm tra danh tính, kẻ tấn công có thể chạy hai trao đổi khóa: một với bạn và một với server thực sự. Kết quả là bạn có một khóa bí mật tốt… nhưng lại chia sẻ với kẻ tấn công.
Đó là lý do trao đổi khóa một mình không chứng minh bạn đang nói chuyện với ai. Nó cung cấp tính bảo mật chống lại người nghe thụ động, nhưng không đảm bảo danh tính.
Trong ngữ cảnh này, “niềm tin” không phải tin ai đó trung thực. Nó là một đảm bảo hẹp, thực dụng: bạn đã tiếp cận đúng đối tượng chứ không phải impostor.
Xác thực là cách giao thức gắn trao đổi khóa với một danh tính thực. Các cách thông dụng bao gồm:
Hệ thống an toàn hiện đại ghép trao đổi khóa (tạo khóa phiên mới) với xác thực (chứng minh bên kia là ai). Sự kết hợp này—dùng trong TLS cho HTTPS và nhiều VPN—ngăn kẻ tấn công lặng lẽ chen vào giữa bạn và dịch vụ bạn dự định kết nối.
Khi bạn truy cập một trang qua HTTPS, trình duyệt thường đang nói chuyện với một server mà nó chưa từng gặp, qua một mạng có thể bị giám sát. Lý do điều này vẫn an toàn là kết nối nhanh chóng thiết lập các khóa mã hóa mới—mà không gửi chúng rõ ràng.
Ở mức cao, HTTPS hoạt động như sau:
Trao đổi khóa là điểm ngoặt: nó giúp cả hai bên có cùng khóa bí mật mà không phải “vận chuyển” khóa qua mạng.
Trong TLS handshake, trao đổi khóa diễn ra sớm—trước khi bất kỳ dữ liệu nhạy cảm nào như mật khẩu hay số thẻ tín dụng được gửi. Chỉ sau khi handshake hoàn tất, trình duyệt mới gửi yêu cầu HTTP “bên trong” đường hầm đã mã hóa.
Trao đổi khóa cho bạn bí mật, nhưng không tự động xác thực. Đó là vai trò của chứng chỉ. Một website trình bày chứng chỉ nói rằng “khóa công khai này thuộc về example.com”, được ký bởi một Certificate Authority mà trình duyệt tin. Trình duyệt kiểm tra tên miền, ngày hiệu lực và chuỗi chữ ký; nếu có điều gì không ổn, nó sẽ cảnh báo bạn.
Hãy nhìn cho thấy https:// và chỉ báo bảo mật của trình duyệt, và coi trọng cảnh báo chứng chỉ.
Một hiểu lầm: HTTPS không làm bạn ẩn danh. Nó mã hóa nội dung gửi và nhận, nhưng địa chỉ IP của bạn, việc bạn kết nối và thường là domain bạn truy cập vẫn có thể hiển thị với mạng và các bên trung gian.
Bí mật tiến (forward secrecy) có nghĩa: nếu ai đó đánh cắp một khóa trong tương lai, họ vẫn không thể quay lại và giải mã lưu lượng bạn đã ghi lại trước đó.
Điều này quan trọng vì kẻ tấn công thường ghi lại các kết nối được mã hóa hôm nay và cố gắng bẻ khoá sau. Nếu hệ thống của bạn tái sử dụng cùng một khóa dài hạn để bảo vệ nhiều phiên, một lần rò rỉ có thể trở thành cỗ máy thời gian—bỗng nhiên hàng tháng hoặc hàng năm dữ liệu trước đây có thể lộ.
Khóa tái sử dụng tạo một điểm lỗi duy nhất. Khóa tồn tại càng lâu, càng có nhiều cơ hội bị sao chép, ghi lại, cấu hình sai hoặc bị chiết xuất từ server bị xâm phạm. Dù thuật toán mạnh, thực tế vận hành là các bí mật sống lâu dễ bị lộ cuối cùng.
Trao đổi khóa tạm thời (thường ECDHE trong TLS hiện đại) tạo một bí mật phiên mới mỗi lần bạn kết nối. Trình duyệt và server thực hiện trao đổi nhanh, dẫn xuất khóa phiên dùng một lần, rồi loại bỏ các giá trị riêng tư tạm thời.
Vì vậy, ngay cả khi khóa chứng chỉ của server bị đánh cắp sau này, kẻ tấn công không có vật liệu cần thiết để tái tạo khóa phiên của các phiên trước.
Bí mật tiến giúp chống lại:
Nó không giúp chống:
Ưu tiên cấu hình hiện đại hỗ trợ bí mật tiến:
VPN là một “ống” riêng tư dựng qua mạng bạn không kiểm soát—như Wi‑Fi công cộng, router khách sạn hoặc kết nối ISP. Mục tiêu không phải làm cho internet “an toàn”; mà là làm cho lưu lượng giữa thiết bị của bạn và server VPN được mã hóa và khó bị chỉnh sửa khi đi qua các đoạn không đáng tin.
Khi bạn kết nối VPN, thiết bị và server VPN đồng ý các khóa mã hóa tươi cho phiên này. Bước đồng ý đó chính là trao đổi khóa. Giao thức VPN hiện đại thường dùng trao đổi theo kiểu Diffie–Hellman (hoặc biến thể đường cong elliptic) để tạo bí mật chung qua mạng mở mà không gửi bí mật đó.
Khi cả hai bên có bí mật chung, họ dẫn xuất các khóa đối xứng và bắt đầu mã hóa dữ liệu hai chiều. Kể từ đó, đường hầm VPN chỉ còn là mã hóa đối xứng nhanh và kiểm tra tính toàn vẹn.
Trao đổi khóa cung cấp bí mật nhưng không tự động cho bạn biết bạn đang nói chuyện với ai. VPN cũng phải xác thực điểm cuối—thường bằng chứng chỉ, khóa chia sẻ trước hoặc thông tin đăng nhập người dùng—để bạn không lỡ tạo một đường hầm mã hóa tới kẻ tấn công.
Hầu hết vi phạm VPN là do con người và cấu hình, chứ không phải “mã hóa bị phá”:
VPN hữu ích khi bạn cần bảo vệ lưu lượng trên mạng không đáng tin, truy cập tài nguyên riêng tư hoặc giảm phơi nhiễm trên Wi‑Fi chia sẻ. Nó không bảo vệ bạn khỏi website độc hại, thiết bị bị nhiễm, hay bảo mật tài khoản yếu—và nó chuyển phần tin cậy sang nhà cung cấp VPN hoặc gateway tổ chức.
Kết nối an toàn hiện đại theo mẫu: làm một “bắt tay” ngắn để đồng ý bí mật mới, rồi chuyển sang mã hóa rất nhanh cho phần còn lại của phiên.
Sự kết hợp này gọi là mật mã lai. Nó thực tế vì toán học dùng cho trao đổi khóa (như phương pháp Diffie–Hellman) tương đối tốn kém, trong khi mã hóa đối xứng (như AES hoặc ChaCha20) được thiết kế để chạy nhanh trên hầu hết thiết bị.
Trong bắt tay, trình duyệt và server đàm phán tham số, xác thực server và dẫn xuất khóa phiên. Giai đoạn này nhỏ về byte nhưng nặng về tính toán so với phần còn lại.
Khi khóa được thiết lập, kết nối chuyển sang “chế độ khối lượng”: trang, hình ảnh, phản hồi API và tải lên được bảo vệ bằng mã hóa đối xứng và kiểm tra tính toàn vẹn có thể xử lý lượng lớn dữ liệu hiệu quả.
Trên thiết bị di động, hạn chế CPU và pin khiến hiệu quả bắt tay rõ rệt—nhất là trên mạng không ổn định.
Với các site có lưu lượng cao, bắt tay cũng là vấn đề mở rộng: hàng nghìn kết nối mới mỗi giây có thể gây tốn kém cho server nếu bắt tay quá chậm.
Để giảm bắt tay lặp lại, TLS hỗ trợ session resumption: nếu bạn kết nối lại sớm, trình duyệt và server có thể tái sử dụng trạng thái trước đó (một cách an toàn) để thiết lập mã hóa với ít lượt trao đổi và ít tính toán hơn. Điều này làm cho trang mượt hơn mà không làm suy yếu ý tưởng khóa phiên mới.
Cài đặt bảo mật chặt chẽ hơn có thể tốn thêm thời gian (tham số mạnh hơn, xác thực nghiêm ngặt), trong khi lựa chọn hiệu năng quá mức có thể tăng rủi ro nếu dùng sai. Điểm then chốt: bắt tay ngắn nhưng là nơi an ninh được thiết lập đúng hay bị mất đi.
“Zero trust” là ý tưởng đơn giản: đừng bao giờ giả định mạng an toàn. Hãy coi mỗi kết nối như thể ai đó có thể đang xem, sửa hoặc giả mạo dịch vụ trên đường đi.
Tư duy trao đổi khóa của Hellman phù hợp hoàn hảo. Diffie–Hellman không cần một mạng “thân thiện”; nó giả định mạng thù địch và vẫn làm cho bảo mật có thể. Zero Trust lấy giả định tương tự và áp dụng nó cho mọi thứ xung quanh bảo mật: danh tính, truy cập và kiểm chứng liên tục.
Hệ thống hiện đại gồm nhiều dịch vụ trò chuyện với nhau—API, cơ sở dữ liệu, queue và công cụ nội bộ. Trao đổi khóa cho phép hai đầu điểm thiết lập khóa mã hóa mới ngay lập tức, ngay cả khi lưu lượng đi qua các mạng bạn không hoàn toàn kiểm soát.
Đó là lý do service mesh an toàn, TLS nội bộ và đường hầm VPN tự động khả thi: chúng dựa vào thương lượng khóa tự động thay vì phân phối thủ công các bí mật dài hạn khắp nơi.
Mã hóa một mình chỉ che nội dung; nó không đảm bảo bạn đang nói với ai. Zero Trust nhấn mạnh xác thực lẫn nhau:
Trên thực tế, việc này dùng chứng chỉ, token ký, nhận dạng thiết bị hoặc nhận dạng workload—rồi trao đổi khóa dùng những danh tính đã xác minh đó để bảo vệ phiên.
Zero Trust tránh “cài đặt rồi quên”. Thay vào đó, ưu tiên chứng chỉ ngắn hạn và xoay khóa thường xuyên để nếu có rò rỉ, tổn thất bị giới hạn. Trao đổi khóa làm điều này khả thi: khóa phiên mới có thể tạo liên tục mà không cần con người truyền tay mật khẩu mới.
Đóng góp trường tồn của Hellman không chỉ là một giao thức—mà là thói quen thiết kế bảo mật như thể mạng luôn thù địch, và thiết lập niềm tin mỗi lần chứ không giả định nó.
Trao đổi khóa (bao gồm Diffie–Hellman và các biến thể hiện đại) là nền tảng cho giao tiếp riêng tư trên mạng thù địch—nhưng không phải lá chắn phép thuật. Nhiều nhầm lẫn xuất phát từ giả định “được mã hóa” nghĩa là “an toàn mọi mặt.” Nó không phải vậy.
Trao đổi khóa bảo vệ dữ liệu trong quá trình truyền khỏi nghe lén thụ động và chặn. Nó không bảo vệ nếu điểm cuối bị xâm phạm.
Nếu phần mềm độc hại có trên laptop của bạn, nó có thể đọc tin nhắn trước khi mã hóa hoặc sau khi giải mã. Tương tự, nếu kẻ tấn công kiểm soát server, họ không cần phá Diffie–Hellman—họ chỉ truy cập dữ liệu tại nguồn.
Mã hóa thường che nội dung chứ không che tất cả ngữ cảnh. Trong nhiều triển khai thực tế, một số metadata vẫn có thể rò rỉ hoặc hiển thị:
Ngay cả với tính năng TLS hiện đại giảm rò rỉ (như encrypted SNI trong một số môi trường), metadata thường chỉ được bảo vệ một phần. Đó là lý do các công cụ riêng tư xếp lớp hơn là chỉ dùng một tính năng.
HTTPS có nghĩa kết nối của bạn tới một server được mã hóa và (thường) được xác thực qua chứng chỉ. Nhưng nó không đảm bảo server đó là server bạn dự định tin tưởng.
Phishing vẫn hiệu quả vì kẻ tấn công có thể:
Mã hóa ngăn nghe lén, không ngăn lừa đảo. Lớp con người và niềm tin thương hiệu vẫn là bề mặt tấn công lớn.
Vấn đề vận hành có thể làm suy yếu an ninh một cách âm thầm:
Mật mã hiện đại mạnh, nhưng hệ thống thực tế thất bại ở khâu vận hành—bảo trì, cấu hình và triển khai.
Tư duy trao đổi khóa của Hellman giúp giải quyết vấn đề chia sẻ bí mật, nhưng hệ thống an toàn vẫn cần nhiều biện pháp phối hợp:
Mạng “thù địch” là bất kỳ đoạn đường truyền giữa hai đầu mà các bên trung gian có thể quan sát, thay đổi, chặn hoặc chuyển hướng lưu lượng. Nó không nhất thiết phải do kẻ xấu điều hành—Wi‑Fi công cộng, ISP, proxy hoặc router bị xâm hại đã đủ.
Bài học thực tế: hãy coi đường truyền là không đáng tin và dựa vào mã hóa + tính toàn vẹn + xác thực, chứ không phải môi trường mạng.
Mã đối xứng nhanh và hiệu quả, nhưng yêu cầu cả hai bên phải đã chia sẻ cùng một khóa bí mật. Nếu bạn gửi khóa đó qua cùng mạng bị giám sát, kẻ nghe lén có thể sao chép nó.
Vấn đề vòng tròn này—cần một kênh an toàn để tạo ra một kênh an toàn—là vấn đề phân phối khóa mà trao đổi khóa được thiết kế để phá vỡ.
Trao đổi khóa cho phép hai bên suy ra cùng một bí mật chung mà không gửi chính bí mật đó qua mạng. Trong các trao đổi kiểu Diffie–Hellman, mỗi bên kết hợp:
Kẻ nghe lén có thể thấy các thông điệp nhưng (với thông số đủ mạnh) không thể tính được khóa chung cuối cùng một cách thực tế.
Đóng khung lại việc thiết lập an toàn từ “vận chuyển một khóa bí mật trước” sang “tạo một bí mật chung mới theo yêu cầu trên kênh không an toàn.”
Sự thay đổi này khiến các thiết bị của người lạ (như trình duyệt và website) có thể nhanh chóng thiết lập các phiên mã hóa, nền tảng cho các giao thức hiện đại như TLS.
Không. Trao đổi khóa chủ yếu bảo vệ chống lại người nghe thụ động. Nếu không có xác thực, bạn vẫn có thể bị lừa trao đổi khóa với kẻ giả mạo.
Để ngăn tấn công trung gian, các giao thức phải liên kết trao đổi khóa với danh tính bằng cách sử dụng:
Trong HTTPS, TLS handshake thường sẽ:
Chỉ sau khi handshake hoàn tất thì dữ liệu HTTP nhạy cảm mới nên được gửi bên trong kênh đã mã hóa.
Chứng chỉ là cách trình duyệt kiểm tra rằng bạn đang kết nối với trang mà bạn dự định, chứ không chỉ là một trang nào đó. Máy chủ trình bày một chứng chỉ nói rằng khóa công khai này thuộc về một domain, được ký bởi một CA mà trình duyệt tin cậy.
Nếu tên, khoảng thời gian hợp lệ hoặc chuỗi chữ ký của chứng chỉ không thỏa, cảnh báo trình duyệt có nghĩa là bước xác thực đã thất bại—mã hóa một mình thì không đủ.
Bí mật tiến (forward secrecy) có nghĩa là ngay cả khi khóa dài hạn (ví dụ khóa riêng của chứng chỉ server) bị đánh cắp sau này, kẻ tấn công vẫn không thể giải mã các phiên đã bị ghi lại trước đó.
Thường thực hiện bằng trao đổi khóa tạm thời (ví dụ ECDHE), nơi mỗi phiên tạo vật liệu khóa mới và dùng một lần.
VPN dùng trao đổi khóa để thiết lập các khóa phiên mới giữa thiết bị của bạn và server VPN, rồi mã hóa lưu lượng qua “ống” đó bằng mã đối xứng.
Nó giúp bảo vệ lưu lượng trên mạng cục bộ không đáng tin, nhưng cũng chuyển phần tin cậy sang nhà cung cấp VPN hoặc gateway của tổ chức và không giải quyết thiết bị bị nhiễm hay phishing.
Bắt đầu bằng các kiểm tra ngăn các sai sót phổ biến:
