Hiểu mục tiêu bảo mật CIA, vai trò và tác nhân; dùng lab hash giả lập để phân biệt thay đổi dữ liệu với bằng chứng tác giả, nguồn gốc và ý định.
Một cổng hỗ trợ bị ngừng truy cập, một danh sách liên hệ được chia sẻ sai người và một yêu cầu bị sửa nội dung đều có thể tạo sự cố. Tuy nhiên, điều cần bảo vệ trong từng trường hợp khác nhau. Nếu chỉ hỏi “đã cài phần mềm bảo mật chưa”, chúng ta dễ bỏ qua mục tiêu và người chịu trách nhiệm của hệ thống.
Bài thuộc Security Essentials 021.1, giáo trình 020-100 tiếng Việt bản 15/04/2026, trang in 2–15, trang PDF 10–23. Đối chiếu mục tiêu LPI đang công bố và nguồn chính thức tới 23/10/2026. Bạn sẽ phân biệt mục tiêu bảo vệ, vai trò vận hành, tác nhân và bằng chứng quy kết. Cần biết khái niệm tài khoản, tệp và dịch vụ mạng; chưa cần công cụ kiểm thử xâm nhập.
Lab dùng tệp giả lập trên Ubuntu 26.04.1 LTS ARM64, bằng tài khoản không root trong container cô lập mạng, không volume host. Phép thử chỉ quan sát thay đổi byte và khả năng khôi phục fixture. Bài tập về vai trò và tác nhân là tình huống trên giấy, không phải kết quả điều tra một sự cố thật.
Tài sản có thể là dữ liệu, thiết bị, tài khoản, dịch vụ hoặc một năng lực mà công việc phụ thuộc. Danh sách liên hệ của nhóm là dữ liệu; cổng nhận ticket là dịch vụ; tài khoản quản trị là một đường kiểm soát dịch vụ. Ghi tên tài sản chưa cho biết điều gì sẽ gây tổn hại nếu nó bị dùng sai.
Ví dụ tự biên soạn: nhóm hỗ trợ cần người được phân công đọc ticket, nội dung yêu cầu không bị đổi ngoài quy trình và cổng hoạt động trong thời gian cần thiết. Ba yêu cầu cùng áp dụng cho một dịch vụ, nhưng được kiểm chứng theo cách khác nhau. Không có một nút bật duy nhất chứng minh cả ba đã đạt.
Theo FIPS 199 của NIST, việc phân loại an toàn thông tin xem xét confidentiality, integrity, availability cùng ảnh hưởng tiềm tàng khi các mục tiêu đó bị tổn hại. Bài dùng các khái niệm làm nền tảng; không áp hệ thống phân loại liên bang Hoa Kỳ thành yêu cầu bắt buộc cho mọi doanh nghiệp.
| Mục tiêu | Câu hỏi nhập môn | Ví dụ ở cổng hỗ trợ giả lập |
|---|---|---|
| Confidentiality, tính bí mật | Ai được phép biết nội dung? | Ticket riêng bị đọc ngoài phạm vi được cấp |
| Integrity, tính toàn vẹn | Thay đổi có đúng thẩm quyền và kỳ vọng? | Nội dung yêu cầu bị sửa ngoài quy trình |
| Availability, tính sẵn sàng | Người được phép có dùng được khi cần? | Nhóm không truy cập được cổng để xử lý việc |
Tính bí mật không đồng nghĩa giấu mọi thông tin khỏi mọi người. Người được giao xử lý vẫn cần truy cập theo mục đích. Còn dữ liệu công khai vẫn cần toàn vẹn và sẵn sàng: hướng dẫn hỗ trợ bị sửa sai có thể gây hại dù ai cũng được phép đọc.
Toàn vẹn cũng không đòi hỏi tệp đứng yên mãi. Một thay đổi được phê duyệt, ghi nhận và kiểm tra có thể hoàn toàn phù hợp. Cần xác định trạng thái tham chiếu, người có quyền thay đổi và cách phát hiện thay đổi ngoài kỳ vọng.
Sẵn sàng không chỉ là máy có điện. Với người dùng, đó còn là truy cập đúng dịch vụ trong thời gian cần, với dữ liệu dùng được. Một bản sao khôi phục đọc được giúp đánh giá một phần khả năng phục hồi; chưa đủ chứng minh toàn bộ ứng dụng hoặc quy trình làm việc đã hoạt động trở lại.
Tính không thể chối bỏ thường được gọi là non-repudiation. Thuật ngữ NIST mô tả những cơ chế hỗ trợ xác minh nguồn gốc, tính toàn vẹn hoặc xác định một hành động có được thực hiện hay không, tùy ngữ cảnh nguồn định nghĩa. Nó không nên được diễn đạt thành “có log là người dùng không thể phủ nhận”.
Chữ ký số có thể hỗ trợ xác minh dữ liệu gắn với khóa ký. Để kết luận sâu hơn còn cần bối cảnh danh tính gắn với khóa, quyền kiểm soát khóa, cách xác minh và quy trình xử lý bằng chứng. Khóa bị dùng trái phép hoặc quy trình bàn giao không rõ có thể làm suy luận phức tạp hơn. Bài này chưa tạo chữ ký số và không kết luận giá trị pháp lý của một bằng chứng cụ thể.
Hash thông thường giúp so sánh dữ liệu với một giá trị tham chiếu; nó không tự cho biết ai tạo dữ liệu. Nếu cùng một người thay được cả tệp lẫn bản hash được dùng làm mốc, việc check khớp chưa chứng minh tệp là bản được phê duyệt. Lab sau minh họa đúng giới hạn đó.
Một tổ chức có thể chia công việc theo nhiều cách. Chủ sở hữu nghiệp vụ xác định nhu cầu và ảnh hưởng; người quản trị triển khai cấu hình; người dùng thực hiện tác vụ; Help Desk tiếp nhận và khoanh vùng; nhóm an ninh đánh giá, phối hợp phản hồi theo trách nhiệm được giao. Một người có thể kiêm nhiều vai trò, nhưng không nên để trách nhiệm biến mất giữa các nhóm.
CISO là một chức danh thường liên quan định hướng và quản lý chương trình an toàn thông tin. Không suy ra mọi tổ chức đều có chức danh này hoặc người giữ chức danh phải tự sửa mọi máy. Người học cần biết ai có thẩm quyền quyết định trong môi trường mình thay vì dựa hoàn toàn vào tên chức vụ.
NIST Cybersecurity Framework 2.0 là nguồn mở rộng về quản lý rủi ro ở cấp tổ chức. Trong ví dụ của bài, nó gợi câu hỏi thực hành: ai chịu trách nhiệm với tài sản, ai được chấp nhận rủi ro và ai xác nhận phục hồi? Bài không nhận là đã triển khai hoặc đánh giá tuân thủ CSF.
Một ticket chuyển cấp tốt nêu tài sản, triệu chứng, thời điểm, người bị ảnh hưởng và những bước đã làm. Nó cũng ghi ai được liên hệ khi thao tác có thể gián đoạn dịch vụ. Tự đổi policy rộng để giải quyết một lỗi cá nhân có thể tác động người khác và vượt quyền của người xử lý.
Tác nhân có thể là người bên ngoài, người trong tổ chức, bên cung cấp hoặc một quy trình/tài khoản bị sử dụng sai. Các sự kiện gây tổn hại cũng có thể bắt nguồn từ lỗi vô ý, hỏng thiết bị hay cấu hình sai, không nhất thiết là một cuộc tấn công. Đầu tiên hãy mô tả hành vi quan sát được.
Các thuật ngữ hacker, cracker, script kiddie, mũ trắng và mũ đen xuất hiện trong mục tiêu và tài liệu. Cách dùng có thể khác giữa cộng đồng; năng lực sử dụng công cụ không tự xác định quyền hạn hoặc ý định. Với hoạt động kiểm thử hợp lệ, điểm cần xác nhận là sự ủy quyền và phạm vi cụ thể, không chỉ nhãn “mũ trắng”.
Động cơ có thể gồm thu lợi, lấy thông tin, gián đoạn dịch vụ, ép trả tiền hoặc đạt mục đích khác. Đó là những khả năng để lập giả thuyết, không phải kết luận có thể đọc thẳng từ một thông báo lỗi. Ransomware, chẳng hạn, có thể tác động nhiều mục tiêu bảo vệ cùng lúc; không nên chỉ nghĩ đến việc có đọc được tệp hay không.
Một địa chỉ IP hoặc tên tài khoản trong log là đầu mối gắn với hoạt động kỹ thuật. Nó chưa tự chứng minh một con người cụ thể chủ ý thực hiện hoạt động đó. Có thể cần xem phiên, thiết bị, mức tin cậy của log, cách đồng bộ thời gian và khả năng tài khoản bị sử dụng trái phép. Không tự công bố danh tính người bị nghi từ một dấu hiệu đơn lẻ.
Chạy trong Bash của lab riêng, với dữ liệu hoàn toàn giả:
umask 077
work=$(mktemp -d)
cd "$work"
printf '%s\n' 'id,amount' 'DEMO01,120' > request.csv
cp request.csv reference.csv
sha256sum request.csv > original.sha256
sha256sum --check original.sha256
Lần đầu phải check thành công. Bản reference.csv và original.sha256 là mốc chúng ta tự giữ trong phép thử. Đổi nội dung có chủ đích:
printf '%s\n' 'id,amount' 'DEMO01,900' > request.csv
sha256sum --check original.sha256
Mong đợi kiểm tra thất bại. Nó chỉ ra tệp không khớp mốc đã giữ, không cho biết ai sửa hoặc thay đổi có được phê duyệt không. Nếu shell bật set -e, chạy thử thất bại trong nhánh điều kiện để tránh thoát trước khi đọc kết quả.
Tiếp tục tạo một manifest mới từ tệp đã đổi:
sha256sum request.csv > untrusted.sha256
sha256sum --check untrusted.sha256
cp reference.csv request.csv
cmp reference.csv request.csv
sha256sum --check original.sha256
Manifest mới check thành công dù nội dung trước đó khác bản đầu. Sau khi copy lại mốc, cmp và manifest gốc cũng khớp. Trong lab chúng ta biết người thao tác vì tự tạo kịch bản; từ kết quả hash riêng lẻ không thể suy ra danh tính ấy trong một sự cố ngoài đời.
Bộ kiểm thử đã xác nhận các nhánh trên bằng tài khoản không root, với sha256sum uutils coreutils 0.10.0. Nó chưa kiểm thử bí mật dữ liệu, chữ ký số, chống chối bỏ hoặc uptime dịch vụ. Các tệp tham chiếu cùng thư mục là dụng cụ minh họa, không phải thiết kế kho bằng chứng chống sửa đổi.
Giả định người dùng báo không vào được cổng, đồng thời một bản báo cáo khác bản hôm qua. Hãy viết ba phần riêng: điều quan sát được, các giải thích có thể và dữ kiện cần thu. Chưa có cơ sở thì đừng gắn nhãn “bị hacker sửa” hoặc kết luận lỗi do người dùng.
Phân công giả lập: Help Desk ghi triệu chứng và thời điểm; người phụ trách ứng dụng kiểm tra dịch vụ; chủ dữ liệu xác nhận thay đổi dự kiến; nhóm an ninh đánh giá nếu có dấu hiệu cần phản hồi sự cố. NIST SP 800-61 Rev. 3, ban hành tháng 4/2025, đặt phản hồi sự cố trong hoạt động quản lý rủi ro. Chuỗi dùng góc nhìn phối hợp đó, không lấy bài tập giấy làm bằng chứng một tổ chức đã có năng lực phản hồi.
Bạn đạt bài khi gọi đúng mục tiêu bị ảnh hưởng, phân công trách nhiệm có căn cứ và giải thích được giới hạn lab hash. Nội dung, fixture và hình được biên soạn độc lập theo khung PDF; đối chiếu thêm mục tiêu 021.1 do LPI công bố. Bài tiếp theo dùng bối cảnh này để đánh giá mức ưu tiên rủi ro.
Học bảo vệ quyền riêng tư qua cookie, fingerprinting, hồ sơ và quyền dữ liệu; thực hành quan sát cookie trong lab riêng, phân biệt xóa cục bộ và log server.
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.
Hiểu danh tính và xác thực với mật khẩu, MFA, passkeys và SSO; đối chiếu NIST 800-63B-4, thực hành salt và băm, lập đường khôi phục tài khoản phù hợp.
Phân biệt mã hóa mạng và ẩn danh với VPN, proxy, Tor và E2EE; đọc ranh giới bảo vệ, hiểu bút danh blockchain qua bốn tình huống thực hành giả định.