Security và Data Governance

Level: L7 — MCP, API & Connectors (Bài 11/11 theo thứ tự sản xuất — · Đối tượng: Người đã học đầy đủ bài 65-74 — Notes App (dự án tích

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Phân biệt 5 tầng rủi ro bảo mật khi tích hợp AI với hệ thống bên ngoài, và biết bài nào trong Level 7 đã dạy tầng nào.
Tổng hợp lại rủi ro riêng của cả 4 tích hợp thật (Google/Notion/CRM/ Database) thành 1 checklist rà soát duy nhất.
Phân biệt rõ “bảo mật tích hợp kỹ thuật” (bài này) với “guardrail tầng agent” (Level 8) và “quản trị AI cấp tổ chức” (Level 9).
Áp dụng nguyên tắc “AI đề xuất, con người xác nhận” cho quyết định cuối cùng: hệ thống đã đủ an toàn để dùng thật chưa.

2. Khái niệm cốt lõi

5 tầng rủi ro bảo mật đã học xuyên suốt Level 7 (tổng hợp, không có tầng nào là nội dung mới):

Tầng giao thức (protocol-level) — 4 nguyên tắc MCP đã học bài 68 (user consent, data privacy, tool safety, sampling control) — áp dụng cho cách 1 AI application kết nối với 1 MCP server.
Tầng connector (đã duyệt qua directory) — checklist 4 bước đã học ở Ch02 (đọc điều khoản nhà phát triển, đọc OAuth scope, bắt đầu chỉ đọc, biết cách gỡ) — áp dụng khi bật 1 connector đã qua kiểm duyệt.
Tầng tích hợp cụ thể (integration-specific) — rủi ro riêng từng loại hệ thống, mỗi bài 70-73 đã tự nêu:
- Bài 70 (Google): xin scope “trọn gói Workspace” thay vì đúng 1 dịch vụ làm thiệt hại lan qua nhiều dịch vụ nếu credential lộ.
- Bài 71 (Notion): Personal Access Token kế thừa toàn bộ quyền người tạo — rộng hơn tưởng nếu người đó có quyền truy cập nhiều nội dung.
- Bài 72 (CRM): dữ liệu khách hàng thật — mức nhạy cảm cao nhất, hậu quả sai sót là thật (liên hệ nhầm người, lộ dữ liệu kinh doanh).
- Bài 73 (Database): rủi ro quyền ghi cao nhất — có thể bỏ qua mọi lớp kiểm tra nghiệp vụ nếu không cấu hình RLS đúng.
Tầng xác thực (authentication-level) — quản lý vòng đời credential đã học bài 74 (API key tĩnh dễ lộ hơn OAuth token có thể thu hồi; nguyên tắc least privilege khi chọn scope).
Tầng quản trị dữ liệu (data governance, nội dung mới duy nhất của bài này) — sau khi đã kết nối đúng cách (tầng 1-4), câu hỏi còn lại: dữ liệu đi đâu sau khi đã kết nối, và ai chịu trách nhiệm cuối cùng?

3. Tại sao nội dung này quan trọng

Đây là bài khép lại lời hứa Project của Level 7 (“Build an AI system that can interact with real-world systems safely”) — Notes App giờ đã “nói chuyện” được với 4 hệ thống bên ngoài; câu hỏi cuối cùng không phải “có kết nối được không” (đã làm xong ở bài 70-73) mà là “đã đủ an toàn để dùng thật chưa.”

4. Cơ chế hoạt động

Câu hỏi quản trị dữ liệu (tầng 5, nội dung mới): sau khi dữ liệu đã rời khỏi hệ thống gốc (ví dụ: nội dung Google Doc được đọc vào Notes App, rồi có thể được gửi tiếp sang Notion hoặc CRM), cần trả lời:

Dữ liệu này có thực sự cần rời khỏi hệ thống gốc không? (nguyên tắc data minimization — chỉ lấy đúng phần cần, không lấy “cho đủ.”)
Dữ liệu có bị lưu lại ở nơi trung gian không cần thiết không? (ví dụ: nếu chỉ cần chuyển tiếp Google Docs → CRM, có cần lưu bản sao trong database log của Notes App không, hay chỉ cần log rằng “đã chuyển,” không log nội dung?)
Ai là người chịu trách nhiệm nếu dữ liệu đi sai chỗ? — với dự án cá nhân, câu trả lời là chính bạn; với dự án phục vụ tổ chức/nhiều người dùng, cần xác định rõ vai trò này trước khi triển khai thật (điểm bàn giao sang tư duy quản trị cấp tổ chức — Level 9).

5. Mental model

Nối lại toàn bộ ẩn dụ mạng lưới nhà cung cấp xuyên suốt Level 7: Notes App giờ là 1 “cửa hàng” đã kết nối với nhiều “nhà cung cấp” khác nhau (Google, Notion, CRM, Database), qua đúng thủ tục giấy tờ (OAuth) và đúng cổng bảo vệ (MCP/connector). Bài này là buổi kiểm toán cuối kỳ — không kiểm tra lại từng giấy tờ đã có (đã làm ở 65-74), mà hỏi: hàng hóa (dữ liệu) đang thực sự chảy đi đâu, có đúng nơi cần tới, có bị rò rỉ dọc đường không, và ai ký tên chịu trách nhiệm cuối cùng cho toàn bộ chuỗi cung ứng này?

6. Hướng dẫn từng bước

Checklist rà soát bảo mật tổng hợp cho Notes App (tổng hợp toàn bộ 5 tầng, áp dụng trước khi coi hệ thống “đủ an toàn để dùng thật”):

Tầng 1 — Giao thức (nếu dùng MCP, bài 68):
[ ] Đã xác nhận user consent & tool safety cho mọi MCP server đang dùng?

Tầng 2 — Connector (nếu dùng connector có sẵn, Ch02):
[ ] Đã đọc điều khoản nhà phát triển, bắt đầu ở chế độ chỉ đọc?

Tầng 3 — Tích hợp cụ thể (70-73):
[ ] Google: chỉ xin scope đúng dịch vụ cần, không xin "trọn gói"?
[ ] Notion: đã cân nhắc PAT vs Public Connection đúng quy mô?
[ ] CRM: đã có bước xác nhận con người trước khi ghi dữ liệu khách hàng?
[ ] Database: đã cấu hình RLS trước khi lộ bảng ra API?

Tầng 4 — Xác thực (74):
[ ] Mọi credential (API key, client secret, access token) đã lưu qua
    biến môi trường, không hardcode?
[ ] Mọi scope/quyền đã xin đúng mức tối thiểu cần thiết?

Tầng 5 — Quản trị dữ liệu (bài này):
[ ] Dữ liệu chuyển giữa các hệ thống có thực sự cần thiết, không dư
    thừa?
[ ] Đã xác định rõ ai chịu trách nhiệm nếu có sự cố?

7. Ví dụ thực tế

Áp dụng cho toàn bộ Notes App: trước khi coi dự án tích lũy “sẵn sàng dùng thật,” chạy đủ checklist mục 6 cho cả 4 tích hợp cùng lúc — không chỉ kiểm tra riêng lẻ từng cái (đã làm ở bài 70-73), mà nhìn toàn cảnh: nếu cả 4 credential (Google, Notion, HubSpot, Supabase) đều bị lộ cùng lúc (ví dụ: file biến môi trường bị lộ), thiệt hại tổng cộng là gì? Đây là câu hỏi chỉ nhìn thấy được khi tổng hợp, không phải khi xét từng tích hợp riêng lẻ.

8. Prompt/template/workflow

Checklist ở mục 6 chính là công cụ chính của bài này — dùng làm bước rà soát cuối cùng trước khi triển khai thật bất kỳ hệ thống nào kết nối nhiều dịch vụ bên ngoài, không chỉ riêng Notes App.

9. Visual hoặc diagram cần thiết

Hình 7.11 — 5 tầng rủi ro bảo mật Level 7: từ Giao thức tới Quản trị dữ liệu.

10. Bài tập thực hành

Chạy checklist mục 6 cho toàn bộ Notes App (cả 4 tích hợp đã xây ở bài 70-73).
Với bất kỳ mục nào chưa đạt, quay lại đúng bài tương ứng để sửa.
Viết ra: nếu bạn phải chọn 1 tích hợp để “tắt trước” khi có sự cố bảo mật nghi ngờ, bạn sẽ tắt cái nào trước — dựa trên mức rủi ro đã học (gợi ý: đối chiếu lại mục 2, tầng 3).
Xác nhận: dự án tích lũy đã đủ an toàn để bạn tự tin coi là “hoàn thành” theo đúng lời hứa Project Level 7 chưa?

11. Checklist

Phân biệt được 5 tầng rủi ro bảo mật, biết bài nào dạy tầng nào.
Chạy được checklist rà soát tổng hợp cho 1 hệ thống đa tích hợp.
Phân biệt rõ bài này với guardrail tầng agent (Level 8) và quản trị AI cấp tổ chức (Level 9).
Áp dụng được nguyên tắc "AI đề xuất, con người xác nhận" cho quyết định "đủ an toàn để dùng thật."

12. Lỗi thường gặp

(Tổng hợp từ các lỗi đã nêu riêng lẻ ở bài 70-74, không phải quan sát độc lập mới.)

Kiểm tra riêng lẻ từng tích hợp mà không nhìn tổng thể — bỏ lỡ rủi ro cộng dồn khi nhiều credential bị lộ cùng lúc.
Nhầm “đã qua checklist kỹ thuật” với “đã sẵn sàng cho dữ liệu thật của tổ chức” — với dự án cá nhân, checklist mục 6 là đủ; với dự án phục vụ tổ chức, cần thêm tư duy quản trị cấp tổ chức (Level 9).
Coi bảo mật là việc làm 1 lần rồi xong — cần rà soát định kỳ, đặc biệt khi thêm tích hợp mới hoặc scope thay đổi.

13. Giới hạn & khi nào KHÔNG nên áp dụng

Bài này tổng hợp đúng những gì đã học ở Level 7 — không thay thế kiểm toán bảo mật chuyên nghiệp cho hệ thống xử lý dữ liệu thật sự nhạy cảm (tài chính, y tế, pháp lý) ở quy mô tổ chức.
Không dạy cách thiết kế guardrail runtime cho agent (khi nào agent tự dừng lại, khi nào cần hỏi con người giữa chừng) — đó là Level 8 (Ch04).
Không dạy khung quản trị rủi ro AI cấp tổ chức đầy đủ (Govern/Map/ Measure/Manage) — đó là Level 9 (#100, NIST AI RMF).

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 bao trùm cả Level 7: dù đã qua đủ 4 tầng kỹ thuật (giao thức, connector, tích hợp cụ thể, xác thực), quyết định cuối cùng “hệ thống đã đủ an toàn để dùng thật” không bao giờ là quyết định của AI — đúng nguyên tắc “AI đề xuất, con người xác nhận” đã thiết lập từ Level 5 (bài 52) và tái khẳng định xuyên suốt Level 6 (bài 64). AI có thể chạy checklist mục 6 và báo cáo kết quả, nhưng phán đoán “đủ an toàn” đòi hỏi bối cảnh và trách nhiệm chỉ con người có.

15. Best practices

Chạy checklist tổng hợp (mục 6) định kỳ, không chỉ 1 lần khi mới xây xong — đặc biệt sau khi thêm tích hợp mới.
Đánh giá rủi ro cộng dồn (nếu nhiều credential lộ cùng lúc), không chỉ đánh giá riêng lẻ từng tích hợp.
Với dữ liệu thật của tổ chức/khách hàng (không phải dữ liệu cá nhân), xác định rõ người chịu trách nhiệm trước khi triển khai — không để ngỏ.
Khi mở rộng hệ thống ra khỏi phạm vi cá nhân (Level 9, tổ chức), quay lại áp dụng khung quản trị rủi ro cấp tổ chức đầy đủ hơn checklist ở bài này.

16. Nội dung nâng cao — Hoàn thành Level 7, chuẩn bị cho Level 8 (không bắt buộc)

Sau bài này, Notes App có 1 hệ thống có thể gọi nhiều tool/API bên ngoài an toàn (Google/Notion/CRM/Database) — nhưng chưa có khả năng tự lập kế hoạch nhiều bước, tự quyết định thứ tự hành động, hay biết khi nào cần dừng lại hỏi con người giữa chừng 1 tác vụ phức tạp. Đó chính xác là nội dung Level 8 sẽ dạy tiếp (orchestration pattern, guardrail 6 loại, multi-agent, human-in-the-loop) — Level 7 dừng đúng ở “có các công cụ an toàn để dùng,” Level 8 dạy “biết tự điều phối dùng công cụ nào trước, khi nào cần dừng lại” — ranh giới bàn giao rõ ràng, đúng khuôn mẫu đã áp dụng ở lần bàn giao L5→L6 (bài 51).

17. Nguồn tham khảo

Không có nguồn Tier 1 mới — bài capstone tổng hợp lại toàn bộ bài 65-74 của Level 7, đúng vai trò đã xác định trong kế hoạch (Bước 2: “#75 cần tổng hợp, không cần Source Discovery độc lập”).

Dẫn chiếu (không trích dẫn mới): bài 68 (4 nguyên tắc an toàn MCP); Ch02 (checklist connector); bài 70-73 (rủi ro riêng từng tích hợp); bài 74 (least privilege, quản lý credential); L5 bài 52 (nguyên tắc “AI trình bày, con người quyết định”); L6 bài 64 (áp dụng lại nguyên tắc đó); Level 8 Ch04 (guardrail tầng agent — không dạy lại); Level 9 #100 (NIST AI RMF, quản trị cấp tổ chức — không dạy lại).

18. Ngày kiểm chứng

Không có claim mới cần kiểm chứng thời gian — bài tổng hợp lại nội dung đã kiểm chứng ở các bài trước (ngày kiểm chứng gốc: 2026-07-13, xem từng bài 65-74 để biết chi tiết nguồn của từng phần được tổng hợp lại).