Chặn App OAuth Bên Thứ Ba trong Google Workspace - Bảo Vệ Dữ Liệu Trước Shadow SaaS

TL;DR

Trong Admin console, vào Security → Access and data control → API controls → App access control, chọn "Don't allow users to access any third-party apps" cho unconfigured apps, sau đó whitelist từng app theo OAuth Client ID. Tính năng này miễn phí, áp dụng cho mọi Workspace edition - và nó block được cả sign-in scope, nghĩa là user không thể dùng Google account đăng nhập vào app lạ. Đây là lớp bảo vệ hiệu quả nhất chống consent phishing và shadow SaaS mà bạn chưa bật.

Cửa hậu không cần password

Hãy tưởng tượng kịch bản này: team marketing cấp quyền cho một tool automation quyền đọc/gửi Gmail và toàn bộ Drive để chạy campaign. Campaign kết thúc, tool bị "disconnect". Nhưng OAuth token vẫn sống. Ba năm sau, vendor của tool đó bị breach. Kẻ tấn công kế thừa mọi quyền ban đầu - không cần password, không cần vượt MFA.

Đây không phải kịch bản giả định. Theo báo cáo Verizon DBIR 2025 (phân tích hơn 22.000 incidents), third-party involvement trong breach tăng gấp đôi so với năm trước - từ 15% lên 30%. Nghiên cứu độc lập cho thấy privileged dormant service account tồn tại ở hơn 70% môi trường enterprise.

Có hai loại mối đe dọa OAuth chính cần hiểu:

• Consent phishing: Attacker tạo OAuth app trông hợp lệ, gửi link cho user, user đăng nhập trên trang Google thật, bấm "Allow" - và attacker nhận token với đầy đủ quyền. MFA không can thiệp được vì authentication đã hoàn tất hợp lệ.
• Shadow SaaS & dormant token: User tự ý cài tool mà IT không biết. Token tích lũy theo thời gian, không ai review. Khi nhân viên nghỉ việc hoặc vendor bị hack, token vẫn hoạt động.

Điểm chung: cả hai đều bypass hoàn toàn password policy và MFA.

App Access Control hoạt động như thế nào

Google Workspace cung cấp năm mức kiểm soát cho từng app:

Ngoài kiểm soát từng app, admin có thể set policy toàn domain:

• Block all third-party API access: Chặn mọi OAuth scope, kể cả sign-in - user không đăng nhập vào bất kỳ app bên thứ ba nào bằng Google account được
• Restrict Google services: Set Gmail hoặc Drive sang "Restricted" - chỉ app Trusted hoặc Specific Google data mới vào được; token của app chưa trust bị revoke ngay
• Block high-risk scopes: Gmail, Drive, Docs, Chat có danh sách scope nguy hiểm cao (gmail.send, gmail.modify, drive toàn quyền...) có thể chặn riêng

Tính năng này ra mắt ngày 8/4/2021. Đến tháng 12/2024, Google GA thêm khả năng giới hạn app theo từng scope cụ thể - ngăn app yêu cầu thêm scope mà không có admin consent dù app đã được approve trước đó.

Con số đáng lo ngại

Để hiểu tại sao đây là urgent, hãy nhìn vào quy mô thực tế:

Tháng 3/2025, nhóm tấn công pivot từ Salesforce sang Google Workspace dùng device-code phishing. Riêng vụ Salesloft-Drift OAuth token breach gây ra blast radius lớn hơn 10 lần so với direct attack - ảnh hưởng hơn 700 tổ chức downstream.

Điểm mấu chốt: reset password không giải quyết được gì khi token đã bị lấy. Token tồn tại độc lập với credential.

Bật tính năng trong 5 bước

1. Mở Google Admin console, đăng nhập tài khoản có quyền Service Settings
2. Vào Security → Access and data control → API controls
3. Nhấn card App access control → Settings
4. Ở mục Unconfigured third-party apps, chọn "Don't allow users to access any third-party apps"
5. Vào Manage App Access, thêm từng app cần thiết bằng OAuth Client ID, set trạng thái Trusted hoặc Specific Google data

Tip quan trọng: Bật thêm "Allow users to request access to unconfigured third-party apps" - user sẽ được redirect vào queue yêu cầu thay vì bị block im lặng. IT review từng request, approve hoặc dismiss. Nên set custom error message hướng dẫn user làm theo quy trình nội bộ.

Nếu muốn restrict riêng Gmail hoặc Drive, vào Manage Google Services, chọn service cần kiểm soát, chuyển sang Restricted. Lưu ý: thao tác này revoke token của mọi app chưa được trust ngay lập tức.

Triển khai không làm vỡ workflow

Block ngay mà không chuẩn bị whitelist sẽ gây chaos. Thứ tự đúng:

1. Inventory trước: Vào Accessed Apps, download CSV. Xem app nào user đang dùng, scope gì, bao nhiêu người. App không hoạt động 60-90 ngày - revoke ngay.
2. Build whitelist: Lấy OAuth Client ID từ vendor, add từng app vào Configured apps với trạng thái phù hợp. Ưu tiên dùng Specific Google data thay vì Trusted để giới hạn scope.
3. Pilot 1 OU nhỏ: Test với một phòng ban trước khi roll out toàn domain.
4. Roll out dần: Set chính sách unconfigured app, theo dõi queue Apps pending review hàng tuần.
5. Offboarding: Khi nhân viên nghỉ, revoke toàn bộ OAuth token - không chỉ disable account Google.

Cạm bẫy cần tránh:

• iOS app dùng Apple App Store bundle ID hiện thị "Unknown" trong cột Ownership - đây là hành vi bình thường
• Nếu app vừa có trong mobile allowlist vừa bị block qua API controls, API block thắng
• "Trust internal apps" checkbox tạo blind spot: attacker chiếm account có quyền register app có thể tạo malicious app nội bộ bypass mọi third-party restriction (CoPhish technique)
• Visibility latency: app mới xuất hiện trong list sau 24-48 giờ; revoke token cũng mất 48 giờ để reflect

Vì sao không nên chờ thêm

App Access Control là tính năng miễn phí, sẵn có cho mọi Google Workspace edition kể cả Cloud Identity Free. Không cần mua thêm gì. Rủi ro khi không bật: token tích lũy không ai biết, một vendor bị hack là đủ để attacker vào thẳng Gmail và Drive của toàn bộ nhân viên đã từng authorize.

Xu hướng tới không lạc quan hơn - 5 automated attack kit (SquarePhish, Graphish, Tycoon...) chiếm 50% toàn bộ device-code phishing traffic mùa thu 2025. Consent phishing đang đi theo vết footstep của ransomware: từ công cụ của hacker chuyên nghiệp thành dịch vụ thuê theo subscription. APT29 cũng đã adopt kỹ thuật này.

Bước 1 là inventory. Bước 2 là block unconfigured. Bước 3 là monitor liên tục - mỗi quý review một lần, alert khi có consent grant mới với high-risk scope.

Nguồn: Google Workspace Admin Help, Workspace Updates Blog, GAT Labs, Obsidian Security.