Chương 13: Phân quyền & Bảo mật Chuyên sâu - Tách biệt để An toàn

"Phân quyền (Permissions) giúp mọi người làm đúng việc. Bảo mật (Security) giúp dữ liệu không rơi vào tay kẻ xấu."

Rất nhiều người nhầm lẫn hai khái niệm này. Họ nghĩ ẩn cái nút đi là bảo mật (sai, đó chỉ là UX). Họ nghĩ app Public dùng UserSettings để lọc dữ liệu là an toàn (sai, đó là rủi ro cực lớn). Chương này sẽ mổ xẻ tường tận hai khía cạnh sống còn này.

13.1 Phần 1: Phân quyền (Permissions) - Ai được làm gì?

Đây là lớp kiểm soát hành vi và trải nghiệm người dùng. Mục đích là để giao diện gọn gàng và ngăn người dùng "bấm nhầm", chứ không phải để chống hacker.

13.1.1 Phân quyền trên View & Slice (Cấp Giao diện)

Mục tiêu: Sếp thấy View báo cáo doanh thu, Nhân viên chỉ thấy View nhập đơn.
Cách làm: Dùng Show_If trong View setting.
Công thức: LOOKUP(USEREMAIL(), "Users", "Email", "Role") = "Admin"
Lưu ý: Dữ liệu vẫn tải về máy nhân viên, chỉ là họ không thấy View đó thôi. Một người biết chút IT vẫn có thể móc dữ liệu ra được. → Đây không phải bảo mật.

13.1.2 Phân quyền trên Action (Cấp Hành động)

Mục tiêu: Chỉ có Trưởng kho mới thấy nút "Duyệt xuất kho". Nhân viên chỉ thấy nút "Tạo phiếu".
Cách làm: Dùng Only if this condition is true trong cấu hình Action.
Công thức: [TrangThai] = "ChoDuyet" AND USEREMAIL() = [NguoiQuanLy]
Tác dụng: Ngăn chặn thao tác sai quy trình (nhân viên lỡ tay bấm duyệt).

13.1.3 Phân quyền trên Data Table (Cấp Dữ liệu - Update Mode)

Mục tiêu: Bảng "Lịch sử Hệ thống" chỉ được xem, cấm sửa xóa. Bảng "Đơn hàng" được sửa nhưng cấm xóa.
Cách làm: Vào Data -> Tables -> Are updates allowed?
Cấu hình:
- Updates_Only: Chỉ cho sửa.
- Adds_and_Updates: Cho thêm và sửa, cấm xóa.
- Read_Only: Chỉ đọc.
- Nâng cao: Dùng công thức để Admin được Full quyền, User bị bóp quyền.
```
IFS(
  USERROLE() = "Admin", "ALL_CHANGES",
  TRUE, "ADDS_AND_UPDATES"
)
```

13.2 Phần 2: Bảo mật (Security) - Ai được thấy gì?

Đây là lớp sống còn. Nếu thủng lớp này, dữ liệu của bạn có thể bị lộ ra ngoài Internet. Security Filters là chốt chặn cuối cùng và quan trọng nhất (Server-side Security).

13.2.1 Core App Secure (Ứng dụng Bảo mật Nội bộ)

Đây là mô hình chuẩn cho doanh nghiệp: Mỗi người 1 email, bắt buộc đăng nhập.

Cơ chế: Dùng Security Filters. Dữ liệu được lọc ngay tại Server Google. Thiết bị của Nhân viên A tuyệt đối không bao giờ nhận được dữ liệu của Nhân viên B.
Công thức: [SaleRep] = USEREMAIL()
An toàn: 100%. Dù có là hacker cũng không thấy được dữ liệu không thuộc về mình.

13.2.2 Public App (Ứng dụng Công cộng) & Cái bẫy UserSettings

Đây là mô hình dành cho App không cần đăng nhập (Guest), nhưng nhiều người lạm dụng nó để tiết kiệm License và gây ra thảm họa.

Kịch bản sai lầm:
- Tạo App Public (không cần login) để đỡ tốn tiền 10$/user.
- Tạo bảng UserSettings để người dùng nhập "Mã khách hàng" và "Mật khẩu".
- Dùng Slice để lọc: [MaKH] = USERSETTINGS("MaKH").
Rủi ro chết người:
- Vì là App Public, TOÀN BỘ DỮ LIỆU của bảng đó được tải về trình duyệt của người dùng (chỉ là giao diện ẩn đi thôi).
- Người dùng chỉ cần nhấn F12 (Inspect) trên trình duyệt là thấy được toàn bộ danh sách khách hàng khác.
- Kết luận: Tuyệt đối không dùng mô hình này cho dữ liệu nhạy cảm (Lương, Hợp đồng, Thông tin cá nhân). App Public chỉ dùng cho: Form khảo sát trắng, Danh mục sản phẩm công khai, Tra cứu tin tức.

13.3 Phần 3: Chiến lược License & UserSettings

Làm sao để vừa tiết kiệm tiền (Tối ưu License) vừa an toàn?

13.3.1 Khi nào nên dùng mỗi người 1 Email (User License)?

Đây là cách tốt nhất và an toàn nhất.

Khi cần Audit Trail: Biết chính xác ai đã sửa dòng này vào lúc mấy giờ (Editor column).
Khi dữ liệu riêng tư: Mỗi người chỉ được thấy phần lương/hoa hồng của mình.
Tuân thủ: Google tính tiền theo Email. Nếu công ty có 20 sales, hãy mua 20 licenses. Đừng tiếc tiền cho bảo mật.

13.3.2 Khi nào dùng tài khoản chung (Generic Email)?

Tình huống: Có bộ phận Kho gồm 3 người làm theo ca (Sáng, Chiều, Tối). Họ dùng chung 1 máy tính bảng tại kho. Công việc giống hệt nhau, không cần giấu nhau cái gì.
Giải pháp: Tạo 1 email kho@company.com. Cả 3 người dùng chung email này để login.
Sử dụng UserSettings: Trong App, tạo UserSettings có cột CaLamViec (Sáng/Chiều/Tối) hoặc TenNhanVien. Mỗi khi đổi ca, họ vào Setting chọn lại tên mình.
Lợi ích: Tiết kiệm License (chỉ tốn 1 user), vẫn biết được ai làm (ghi UserSettings("TenNhanVien") vào cột lịch sử).

13.3.3 Rủi ro License: Monthly Unique Users (Cái bẫy 30 ngày)

Nhiều người nghĩ: "Gói Free cho 10 user. Vậy tôi cứ add 10 người, mai kick 1 người ra add người mới vào, vẫn là 10 người cùng lúc mà?" -> SAI.

Cách tính của Google: Monthly Unique Users (Người dùng duy nhất trong tháng).
Nếu hôm nay bạn share cho A, mai remove A share cho B. Google đếm là 2 users.
Nếu trong 30 ngày bạn làm thao tác này 15 lần -> Google đếm 15 users -> Vượt quá gói Free/Starter -> App bị khóa.
Lời khuyên: Danh sách user nên ổn định. Đừng add/remove liên tục để lách luật.

13.4 Vận dụng (Your Project)

Hãy rà soát lại App CRM của bạn:

Dữ liệu khách hàng có đang lộ không?
- Vào Security Filter của bảng Customers. Đảm bảo đã có công thức: [SaleRep] = USEREMAIL() OR USERROLE()="Admin".
App có đang Public không?
- Vào Manage -> Security. Đảm bảo "Require Sign-In" đang bật.
Chiến lược License:
- Sales Team: Mỗi người 1 email (để bảo mật khách riêng).
- Delivery Team: Có thể dùng chung email shipper@company.com nếu không cần giấu đơn hàng của nhau (nhưng cần cân nhắc carefully).

13.5 Tổng kết: An toàn là trên hết

Phân quyền là để tiện dụng (UX), dùng Show_If, Only If.
Bảo mật là để an toàn (Security), dùng Security Filter và Require Sign-In.
UserSettings trên App Public là con dao hai lưỡi - chỉ lọc hiển thị chứ không bảo mật dữ liệu.
License: "Tiền nào của nấy". Dùng gói Core Secure cho dữ liệu nội bộ. Dùng App Public cho dữ liệu đại chúng.

Chuyển sang chương tiếp theo, chúng ta sẽ áp dụng toàn bộ kiến thức bảo mật này vào dự án thực tế để xây dựng ma trận phân quyền cho CRM.

13.6 Tài liệu tham khảo (Google Docs)

Security Filters: Security filters: The Essentials
User Settings: User settings: The Essentials
Domain whitelist: Require domain authentication