Chuyển đến nội dung chính (Skip to content)
Mục lục bài viết
Security Essentials

Security Essentials 025.2: Bảo mật Thông tin và Giao tiếp an toàn

Security Essentials 025.2: Bảo mật Thông tin và Giao tiếp an toàn

Học giao tiếp an toàn qua phishing, tệp đính kèm, phân loại thông tin và quyền cloud; thực hành xác minh người nhận, giảm dữ liệu và xử lý chia sẻ nhầm.

Một đối tác nhắn “gửi lại danh sách nhân viên vào địa chỉ mới, cần ngay trước cuộc họp”. Tên hiển thị và ảnh đại diện đều quen thuộc. Nếu người hỗ trợ chỉ kiểm tra kết nối có mã hóa rồi gửi, dữ liệu vẫn có thể đến nhầm người. Giao tiếp an toàn cần đúng người, đúng dữ liệu, đúng quyền và đúng kênh.

Kết quả học tập và phạm vi

Sau bài này, bạn phân biệt phishing, social engineering, spam và scareware; xử lý tệp đính kèm bất ngờ; chọn cách chia sẻ theo phân loại thông tin; giải thích giới hạn của mã hóa và thu hồi quyền. Kiến thức tiên quyết gồm danh tính, MFA, TLS và mã hóa đầu cuối ở các bài trước.

Bài tham chiếu mục tiêu 025.2 của giáo trình Security Essentials 020-100, PDF phiên bản 2026-04-15, trang in 282–296. Đầu trang một bài trong PDF ghi nhầm 025.1; phạm vi ở đây theo mục tiêu 025.2 trong bảng đối chiếu. Nội dung, hình và tình huống được viết độc lập; nguồn kiểm tra ngày 23/10/2026. Thực hành là hồ sơ giả trên giấy, không gửi email, chia sẻ tệp cloud, thay bộ lọc hoặc kiểm thử ứng dụng nhắn tin thật.

Rò rỉ không chỉ xảy ra khi bị nghe lén

Thông tin có thể lộ vì sai người nhận, quyền chia sẻ quá rộng, dữ liệu thừa trong tệp hoặc thiết bị bị chiếm. Mã hóa truyền tải xử lý một phần đường đi, không sửa quyền của người đang nhận bản rõ. Báo cáo có bảng ẩn, ghi chú hoặc lịch sử sửa cũng có thể mang thêm dữ liệu ngoài phần nhìn thấy.

Hậu quả phụ thuộc nội dung, khả năng sử dụng lại và người nhận: lộ lịch công tác khác lộ bí mật truy cập, nhưng kết hợp nhiều dữ kiện nhỏ có thể hỗ trợ mạo danh. Không cần có mật khẩu mới phát sinh rủi ro. Một ảnh màn hình chứa tên khách hàng, mã hồ sơ và cuộc trao đổi nội bộ cũng cần được xem xét trước khi đưa lên ticket công khai.

Nếu phát hiện đã gửi sai, dừng chia sẻ tiếp, ghi thời gian, đối tượng và phạm vi rồi báo theo quy trình. Thu hồi liên kết có thể ngăn truy cập mới trong dịch vụ, nhưng không bảo đảm xóa các bản đã tải hoặc ảnh đã chụp. Đừng tự khẳng định dữ liệu đã được thu hồi hoàn toàn chỉ vì nút “Remove access” báo thành công.

Nhận diện yêu cầu cần xác minh

Phishing dùng thông điệp hoặc trang giả để lừa cung cấp thông tin hay thực hiện hành động. Social engineering rộng hơn, có thể qua điện thoại, chat hoặc gặp trực tiếp. Microsoft giải thích dấu hiệu phishing và việc báo cho bộ phận bảo mật khi gặp yêu cầu đáng ngờ.

Đừng dùng lỗi chính tả làm tiêu chí quyết định. Thư viết trôi chảy, đúng dự án và mang tên người quen vẫn có thể đến từ tài khoản bị chiếm hoặc nội dung được tạo tự động. Tín hiệu cần chú ý là thay đổi bất thường: đổi tài khoản nhận tiền, đổi nơi gửi dữ liệu, yêu cầu giữ bí mật hoặc bỏ qua bước phê duyệt.

Xác minh bằng kênh lấy độc lập, chẳng hạn số liên hệ trong danh bạ đã được quản lý. Trả lời chính chuỗi thư đáng ngờ hoặc gọi số mới trong thông điệp có thể vẫn gặp người giả. Không cần đối chất hay cố gài bẫy người gửi; mục tiêu là kiểm tra thẩm quyền và nhu cầu thực.

Scareware tạo cảnh báo hù dọa để thúc tải phần mềm, gọi hỗ trợ hoặc trả tiền. Một pop-up nói máy nhiễm chưa phải kết quả quét đáng tin. Dừng tương tác với thông điệp, ghi lại hiện tượng và mở công cụ hỗ trợ được tổ chức cung cấp. Không cấp điều khiển từ xa cho người liên hệ bất ngờ.

Spam filter và tệp đính kèm có giới hạn

Spam là thư không mong muốn; thư độc hại và thư rác có phần giao nhau nhưng không đồng nghĩa. Bộ lọc xét tín hiệu người gửi, nội dung, liên kết và các lớp bảo vệ theo sản phẩm. Nó có thể bỏ sót hoặc chặn nhầm. Thư vào Inbox chưa chứng minh an toàn; thư vào Junk chưa chứng minh người gửi cố tình gây hại.

Không thêm cả tên miền vào danh sách cho phép chỉ để giải quyết một thư bị chặn. Help Desk cần giữ mẫu theo quy trình, xác minh người gửi và chuyển quản trị email xem chính sách. Việc nới luật rộng có thể ảnh hưởng những thư sau, vượt xa yêu cầu hiện tại.

Safe Attachments của Microsoft là ví dụ có cơ chế kiểm tra tệp trong môi trường ảo và hành động theo policy, không phải tính năng mặc định của mọi hộp thư. Tệp được bảo vệ bằng mật khẩu có thể khó kiểm tra nếu công cụ không có mật khẩu. Không tự giải nén hoặc bỏ bảo vệ để vượt kiểm tra trên máy làm việc.

Với tệp bất ngờ, xác nhận công việc và loại nội dung trước khi mở. Đuôi .pdf hoặc .docx không bảo đảm vô hại; đuôi kép cũng có thể gây nhầm. Không bật macro, chạy script hoặc cài extension theo lời tài liệu lạ. Nếu đã mở rồi, báo chính xác thao tác đã làm; không sửa log hoặc xóa dấu vết để “dọn trước”.

Kiểm tra đúng người, quyền, dữ liệu và kênh trước khi chia sẻ.
Hình 1. Kiểm tra đúng người, quyền, dữ liệu và kênh trước khi chia sẻ. Mở hình để xem chi tiết.

Phân loại dữ liệu và NDA

Phân loại giúp nối mức nhạy cảm với cách lưu, quyền nhận và kênh truyền. Tên nhãn do tổ chức quy định; “nội bộ” không mặc định có nghĩa lộ ra không gây hại, và nhãn của doanh nghiệp không tự tương đương hệ thống phân loại bí mật nhà nước.

Nhãn minh họa Câu hỏi trước khi chia sẻ Ví dụ hành động
Đã công khai Bản này đã được duyệt công bố chưa? Dùng đúng phiên bản công khai
Dùng nội bộ Người nhận có thuộc phạm vi được phép? Hạn chế quyền theo nhóm phù hợp
Hạn chế Ai sở hữu và ai phê duyệt việc cung cấp? Xác minh nhu cầu, giảm dữ liệu và ghi căn cứ

Đây là ví dụ học tập, không tạo chính sách mới cho cơ quan bạn. Khi chưa rõ, hỏi chủ sở hữu thông tin hoặc người phụ trách theo quy trình. Việc bỏ nhãn không làm dữ liệu hết nhạy cảm; ngược lại, gắn nhãn nhưng để liên kết công khai cũng chưa tạo kiểm soát truy cập.

NDA ghi nhận các nghĩa vụ bảo mật theo thỏa thuận. WIPO mô tả bảo vệ bí mật thương mại, trong đó thỏa thuận bảo mật là một phần biện pháp giữ bí mật. Bài không kết luận hiệu lực pháp lý của một hợp đồng cụ thể. NDA không tự xác thực email người nhận, mã hóa tệp hoặc cấp quyền nhận mọi hồ sơ.

Chia sẻ cloud: liên kết và quyền là hai việc

Google Drive phân biệt quyền chia sẻ: Restricted giới hạn người có quyền, còn Anyone with the link cho phép người có liên kết truy cập theo cấu hình. Không coi liên kết khó đoán là kiểm soát danh tính. Tùy tài khoản và chính sách, lựa chọn cùng vai trò Viewer, Commenter hoặc Editor có thể khác.

Trước khi gửi, chọn đúng tài khoản người nhận, phạm vi, vai trò và phiên bản tệp. Người chỉ cần đọc không mặc định cần sửa. Với thư mục, xem cả quyền kế thừa và nội dung mới có thể được thêm sau; giới hạn một liên kết tệp chưa xác nhận toàn bộ thư mục đã hạn chế.

Khi công việc kết thúc, rà quyền đã cấp và thu hồi theo quy trình. Ghi riêng hai kết quả: quyền trong dịch vụ đã thay đổi thế nào, và bản sao ngoài dịch vụ còn chưa xác nhận ra sao. Không thử bằng tài khoản cá nhân hoặc gửi cho đồng nghiệp không có nhu cầu chỉ để kiểm tra nút chia sẻ.

Nhắn tin mã hóa: kiểm tra người và phạm vi

Mã hóa đầu cuối bảo vệ nội dung trong phạm vi các đầu cuối được thiết kế, không biến tên hiển thị thành danh tính đã xác minh. Signal giải thích safety number dùng để kiểm tra bảo mật trao đổi với liên hệ, và nói rõ nó không tự xác minh danh tính ngoài đời.

Thay đổi số bảo mật có thể liên quan đổi điện thoại hoặc cài lại, cũng có thể cần kiểm tra thêm. Xác minh theo kênh phù hợp trước nội dung nhạy cảm; không mặc định mọi thay đổi là bị tấn công hoặc mặc định đều vô hại. Không gửi bí mật vào cuộc chat chỉ vì ứng dụng có biểu tượng mã hóa.

Gmail confidential mode là một tính năng khác. Google mô tả thời hạn và thu hồi quyền xem, đồng thời lưu ý người nhận vẫn có thể chụp ảnh hoặc màn hình. Không đồng nhất nó với OpenPGP hay coi nó là bằng chứng E2EE. Tin nhắn tự hủy cũng không xóa trí nhớ, bản xuất hoặc ảnh của người đã nhận.

Thu hồi quyền truy cập trong dịch vụ không tự xóa các bản sao người nhận đã có.
Hình 2. Thu hồi quyền truy cập trong dịch vụ không tự xóa các bản sao người nhận đã có. Mở hình để xem chi tiết.

Lab giấy: quyết định trước khi gửi

Chuẩn bị bảng gồm mã tình huống, dữ kiện, hành động được phép, dữ liệu tối thiểu và bằng chứng cần xác minh. Không dùng hồ sơ hoặc thông tin liên hệ thật. Đọc lần lượt bốn trường hợp:

  1. C40-A: người tự xưng đối tác có NDA yêu cầu gửi toàn bộ danh sách nhân viên qua địa chỉ mới. Dừng gửi; xác minh người, mục đích, quyền và phạm vi qua kênh độc lập. NDA chưa trả lời các câu hỏi đó.
  2. C40-B: tệp “hóa đơn” bất ngờ đi kèm hướng dẫn bỏ chặn macro. Không mở hoặc bật theo hướng dẫn; ghi nguồn và chuyển bộ phận xử lý đúng quy trình. Không cần chạy thử để chứng minh nghi ngờ.
  3. C40-C: tài liệu hạn chế đang đặt Anyone with the link. Xác nhận chủ sở hữu và thay quyền theo thẩm quyền; chưa kết luận không ai ngoài dự kiến từng đọc.
  4. C40-D: người nhận nói số bảo mật đổi sau khi thay điện thoại. Kiểm tra qua kênh phù hợp trước chia sẻ, ghi đây là dữ kiện cần xác minh chứ chưa phải chứng cứ bị chiếm tài khoản.

Kết quả mong đợi là bốn quyết định kèm lý do, không phải bốn nhãn “an toàn” hoặc “nguy hiểm”. Rà lại xem bạn đã tách người nhận, quyền nhận, kênh truyền và lượng dữ liệu chưa. Bài tập đã được đối chiếu về lập luận; không có thư, link hoặc tệp thật được gửi, không có policy production được sửa.

Khi đã chia sẻ nhầm

Báo sớm bằng sự kiện quan sát được: thời gian và múi giờ, tài liệu, đối tượng, kênh, quyền tại thời điểm đó và thao tác đã thực hiện. Hạn chế đưa thêm nội dung nhạy cảm vào bản báo cáo. Đội phụ trách quyết định thu hồi, lưu bằng chứng, liên hệ người nhận và nghĩa vụ thông báo thích hợp.

Help Desk xác nhận phục hồi theo phạm vi: quyền trong dịch vụ đã đúng, đường gửi được kiểm tra và yêu cầu được người có trách nhiệm chấp nhận. Nếu chưa biết bản sao nào đã tồn tại bên ngoài, ghi rõ điều chưa biết. Kết nối được mã hóa và thao tác thu hồi thành công đều có giá trị, nhưng cần được diễn giải đúng giới hạn.

Bài liên quan trong bộ LPI

Tìm hiểu thêm