Security Căn Bản
Security Căn Bản
Secrets không bao giờ nằm trong code — tồn tại vĩnh viễn trong lịch sử Git. Nếu lỡ lộ: xoay vòng credential ngay, không chỉ xóa lịch sử. 4 rủi ro OWASP quan trọng nhất cho dự án cá nhân: Cryptographic Failures, Injection, Broken Access Control, Security Misconfiguration.
Nắm vững nguyên lý và khái niệm nền tảng trước khi đi vào công cụ thực tế.
Áp dụng quy trình từng bước, case study thực chiến và template mẫu có sẵn.
Kiểm tra checklist hoàn thành, né tránh các sai lầm kinh điển để vận hành bền vững.
Nắm vững các khái niệm nền tảng, cơ chế hoạt động và mô hình tư duy cốt lõi.
1. Mục tiêu học tập
Sau bài này, bạn có thể:
2. Khái niệm cốt lõi
Secrets là gì, và vì sao không bao giờ được đặt trực tiếp trong code: “secrets” là các credential nhạy cảm cấp quyền truy cập hệ thống/dịch vụ — cụ thể: API key, mật khẩu, token. Khi 1 secret được ghi thẳng vào code và commit lên Git (đã học bài 54), nó “trở thành mục tiêu cho truy cập trái phép” — và tồn tại vĩnh viễn trong lịch sử Git trên mọi nhánh, rất khó gỡ bỏ hoàn toàn dù sau đó có xóa ở phiên bản mới nhất. Đây là lý do secrets phải được lưu tách biệt khỏi code ngay từ đầu, không phải “sửa sau.”
Nếu lỡ để lộ 1 secret — bước quan trọng nhất không phải cố xóa lịch sử Git: nguồn chính thức nhấn mạnh biện pháp khắc phục chính là xoay vòng (rotate) credential ngay lập tức — tạo key/mật khẩu mới, vô hiệu hóa cái cũ. Cố gắng xóa khỏi lịch sử Git tốn thời gian và thường không cần thiết nếu credential đã bị vô hiệu hóa.
4 rủi ro bảo mật phổ biến nhất với 1 sản phẩm cá nhân quy mô nhỏ (chọn lọc từ OWASP Top 10:2025 — tiêu chuẩn ngành chính thức, 10 mục đầy đủ, ở đây chỉ dùng 4 mục liên quan trực tiếp tới quy mô dự án tích lũy):
- Cryptographic Failures (A04) — bao gồm để lộ secrets, đúng nội dung đã học ở trên.
- Injection (A05) — tấn công khai thác do không kiểm tra dữ liệu đầu vào (input validation): ví dụ người dùng nhập nội dung ghi chú chứa mã độc thay vì văn bản thường, hệ thống xử lý mù quáng mà không kiểm tra.
- Broken Access Control (A01) — lỗ hổng phân quyền: ví dụ người dùng A xem/xóa được ghi chú của người dùng B, do hệ thống không kiểm tra đúng ai đang thao tác với ghi chú nào.
- Security Misconfiguration (A02) — cấu hình bảo mật sai hoặc dùng mặc định không an toàn (ví dụ: để chế độ “hiển thị lỗi chi tiết” bật công khai khi sản phẩm đã deploy, vô tình lộ thông tin nội bộ).
3. Tại sao nội dung này quan trọng
Bài 56 đã trích số liệu thật: code AI-đồng-tác-giả không qua review có lỗ hổng bảo mật cao hơn 2,74 lần so với code được viết/review cẩn thận [S97, dẫn lại]. Bài này là bước bù đắp trực tiếp cho đúng rủi ro đó, ngay trước khi dự án tích lũy thêm tính năng gọi API bên ngoài (bài 64, cần lưu trữ đúng cách 1 API key thật) và deploy công khai (bài 63).
4. Cơ chế hoạt động
Phân định AI vs con người:
| Điều bạn cần hiểu | Điều AI có thể thực hiện | Điều bạn phải xác nhận | |
|---|---|---|---|
| Secrets | Secret không bao giờ nằm trong code, và tồn tại vĩnh viễn trong lịch sử Git nếu lỡ commit | Rà soát code tìm secret bị hardcode, đề xuất cách lưu tách biệt | Không có secret/dữ liệu nhạy cảm nào bị lộ — đây là xác nhận con người quan trọng nhất giai đoạn Secure |
| Input validation | Dữ liệu người dùng nhập vào không bao giờ nên được tin tuyệt đối | Đề xuất/thêm bước kiểm tra input | Các bước kiểm tra có phủ đúng những chỗ người dùng thực sự nhập dữ liệu |
| Access control | Ai được phép làm gì với dữ liệu của ai | Rà soát, chỉ ra chỗ thiếu kiểm tra quyền | Đã thử với góc nhìn “người dùng khác” xem có truy cập được dữ liệu không nên thấy |
| Cấu hình | Cấu hình mặc định thường ưu tiên tiện lợi hơn an toàn | Đề xuất cấu hình an toàn hơn cho môi trường thật | Cấu hình khi deploy (bài 63) khác cấu hình khi phát triển cục bộ |
5. Mental model
Nếu bài 61 là lắp cảm biến rò nước, bài này là lúc bạn kiểm tra khóa cửa và cất chìa khóa dự phòng đúng chỗ trước khi mời người lạ (dịch vụ AI bên ngoài, bài 64) vào nhà và trước khi mở cửa cho công chúng (deploy, bài 63). Secrets giống như chìa khóa nhà — không bao giờ dán công khai ngay trước cửa (code commit lên Git), mà cất ở nơi riêng biệt chỉ người có quyền mới lấy được.
Quy trình thực thi từng bước, case study cụ thể và bộ prompt/template áp dụng ngay.
6. Hướng dẫn từng bước
Áp dụng cho dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.
Trước khi thêm tính năng AI tóm tắt (bài 64) — tính năng này cần 1 API key thật để gọi dịch vụ AI bên ngoài — chuẩn bị đúng cách ngay từ bây giờ:
7. Ví dụ thực tế
Vì sao chuẩn bị lưu API key đúng cách trước khi có key thật quan trọng: nếu bạn thêm tính năng AI tóm tắt (bài 64) trước, rồi mới nghĩ tới bảo mật sau, rủi ro cao là API key đã bị viết thẳng vào code và có thể đã commit lên Git ít nhất 1 lần — đúng rủi ro “tồn tại vĩnh viễn trong lịch sử” đã học ở mục 2. Học và thiết lập cách lưu đúng trước khi có key thật (thứ tự đúng của bài này, trước bài 64) tránh được rủi ro đó hoàn toàn, thay vì phải xoay vòng key sau khi đã lỡ để lộ.
8. Prompt/template/workflow
Rà soát code của dự án cho 4 rủi ro sau:1. Có credential/API key nào bị viết trực tiếp trong code không?2. Dữ liệu người dùng nhập vào có được kiểm tra trước khi xử lý không?3. Người dùng có thể truy cập dữ liệu của người dùng khác không?4. Có thông tin nội bộ nào bị hiển thị công khai khi có lỗi không?Đề xuất cách khắc phục cho từng điểm phát hiện được.[ ] Không có secret nào bị viết trực tiếp trong code?[ ] Secrets được lưu tách biệt (không commit lên Git)?[ ] Dữ liệu đầu vào quan trọng đã được kiểm tra?[ ] Đã thử góc nhìn "người dùng khác" để kiểm tra phân quyền?9. Visual hoặc diagram cần thiết
10. Bài tập thực hành
- Yêu cầu Claude Code rà soát dự án của bạn theo khung ở mục 8.
- Nếu phát hiện bất kỳ secret nào bị hardcode (kể cả secret thử nghiệm), thực hành chuyển sang cách lưu tách biệt.
- Thử nhập dữ liệu bất thường (ghi chú rỗng, ghi chú rất dài, ký tự đặc biệt) vào chức năng thêm ghi chú, quan sát hệ thống xử lý thế nào.
- Chuẩn bị trước cách lưu API key cho tính năng AI tóm tắt (bài 64) — xác nhận với Claude Code đây là cách lưu tách biệt, không hardcode.
Checklist kiểm tra mức độ sẵn sàng, nhận diện các bẫy sai lầm và nguyên tắc vàng vận hành.
11. Checklist
12. Lỗi thường gặp
15. Best practices
16. Nội dung nâng cao (không bắt buộc)
OWASP Top 10 đầy đủ còn 6 mục khác (Software Supply Chain Failures, Insecure Design, Authentication Failures, Software/Data Integrity Failures, Security Logging Failures, Mishandling of Exceptional Conditions) — quan trọng ở quy mô tổ chức/nhiều người dùng hơn nhiều so với phạm vi 1 dự án cá nhân mới bắt đầu của Level 6. Người học muốn đi sâu hơn về bảo mật phần mềm nên tham khảo trực tiếp tài liệu OWASP đầy đủ sau khi hoàn thành Level 6.
⚠️ 13. Giới hạn & khi nào KHÔNG nên áp dụng
- Bài này không dạy bảo mật kết nối/dữ liệu khi AI truy cập công cụ ngoài (OAuth scope, MCP) — xem Level 7 (#74-75) khi có.
- Bài này chỉ dạy 4/10 rủi ro OWASP liên quan trực tiếp nhất tới dự án cá nhân quy mô nhỏ — với sản phẩm thật sự nghiêm túc/nhiều người dùng, cần rà soát đầy đủ hơn, lý tưởng nhất có chuyên gia bảo mật xem lại.
- Rà soát bằng AI ở bài này là bước sàng lọc cơ bản, không thay thế kiểm toán bảo mật chuyên nghiệp cho sản phẩm xử lý dữ liệu nhạy cảm thật (tài chính, y tế…).
🔐 14. An toàn & quản trị (Safety/Governance)
Đây là bài mà chính nội dung là an toàn/quản trị — không có mục riêng tách biệt cần bổ sung. Nguyên tắc quan trọng nhất xuyên suốt: secrets không bao giờ là quyết định của AI một mình — AI có thể rà soát và đề xuất, nhưng con người là người xác nhận cuối cùng không có secret nào bị lộ, đúng nguyên tắc bất biến đã đặt ra từ đầu Level 6 cho vai trò con người ở giai đoạn Secure.
📚 17. Nguồn tham khảo
OWASP Top 10:2025, OWASP (owasp.org/Top10/2025) — danh sách 10 rủi ro bảo mật ứng dụng web hàng đầu, tiêu chuẩn ngành chính thức · About Secret Scanning, GitHub Docs (docs.github.com) — định nghĩa secrets, rủi ro khi commit vào Git, biện pháp khắc phục chính (xoay vòng credential) · Dẫn chiếu (không trích dẫn mới): (số liệu rủi ro bảo mật khi AI đồng tác giả, đã trích đầy đủ ở bài 56); bài 54 (Git, lịch sử commit); bài 55 (mô hình 4 lớp).