Trộm cắp Token là nguyên nhân hàng đầu gây ra các vụ vi phạm SaaS. Khám phá lý do OAuth và API tokens thường bị bỏ qua và cách các đội ngũ bảo mật có thể tăng cường “vệ sinh” Token để ngăn chặn các cuộc tấn công.
Hầu hết các công ty vào năm 2025 đều dựa vào một loạt các ứng dụng software-as-a-service (SaaS) để vận hành hoạt động của họ. Tuy nhiên, bảo mật của các ứng dụng này phụ thuộc vào những mảnh dữ liệu nhỏ gọi là tokens. Các tokens, như OAuth access tokens, API keys, và session tokens, hoạt động giống như chìa khóa để truy cập vào các ứng dụng này. Nếu một tội phạm mạng chiếm được một token, chúng có thể truy cập các hệ thống liên quan mà không gặp nhiều khó khăn.
Các vụ vi phạm bảo mật gần đây đã chỉ ra rằng chỉ một token bị đánh cắp có thể vượt qua multi-factor authentication (MFA) và các biện pháp bảo mật khác. Thay vì khai thác trực tiếp các lỗ hổng, kẻ tấn công đang tận dụng hành vi trộm cắp Token. Đây là một mối lo ngại về bảo mật gắn liền với vấn đề rộng lớn hơn về SaaS sprawl và khó khăn trong việc giám sát vô số tích hợp của bên thứ ba.
Các vụ vi phạm gần đây liên quan đến Token bị đánh cắp
Một loạt các sự kiện thực tế cho chúng ta thấy cách các token bị đánh cắp có thể gây ra các vụ vi phạm bảo mật trong môi trường SaaS:
1. Slack (Tháng 1 năm 2023). Kẻ tấn công đã đánh cắp một số Slack employee tokens và sử dụng chúng để truy cập trái phép vào các kho lưu trữ mã nguồn riêng tư trên GitHub của Slack. (Không có dữ liệu khách hàng nào bị lộ, nhưng đây là một cảnh báo rõ ràng rằng các token bị đánh cắp có thể phá vỡ các rào cản bảo mật nội bộ.)
2. CircleCI (Tháng 1 năm 2023). Phần mềm độc hại đánh cắp thông tin trên máy tính xách tay của một kỹ sư đã cho phép các tác nhân đe dọa chiếm quyền kiểm soát session tokens cho các hệ thống của CircleCI. Những tokens đó đã cấp cho kẻ tấn công quyền truy cập tương tự như người dùng, ngay cả khi có MFA, cho phép chúng đánh cắp customer secrets từ nền tảng CI.
3. Cloudflare/Okta (Tháng 11 năm 2023). Sau vụ vi phạm nhà cung cấp danh tính, Cloudflare đã xoay vòng khoảng 5.000 credentials. Tuy nhiên, một API token chưa được xoay vòng và một số service account credentials đã đủ để tội phạm mạng thỏa hiệp môi trường Atlassian của Cloudflare. Sự cố này cho thấy một token bị lãng quên có thể làm suy yếu một phản ứng sự cố kỹ lưỡng như thế nào.
4. Salesloft/Drift (Tháng 8 năm 2025). Chatbot Drift (thuộc sở hữu của Salesloft) đã phải chịu một vụ vi phạm chuỗi cung ứng cho phép kẻ tấn công thu thập OAuth tokens cho các tích hợp như Salesforce và Google Workspace. Sử dụng các token bị đánh cắp đó, chúng đã truy cập dữ liệu SaaS của hàng trăm tổ chức khách hàng. Việc lạm dụng OAuth token này đã cho phép kẻ tấn công di chuyển ngang vào email, tập tin và hồ sơ hỗ trợ trên các nền tảng.
SaaS Sprawl thúc đẩy các điểm mù về Token
Tại sao các vụ vi phạm dựa trên Token này vẫn tiếp tục xảy ra?
Vấn đề lớn hơn bất kỳ ứng dụng đơn lẻ nào, đó là một vấn đề về hệ sinh thái được thúc đẩy bởi việc sử dụng SaaS tràn lan và các mối quan hệ ủy thác Token ẩn giữa các ứng dụng.
Ngày nay, mọi phòng ban đều tận dụng các công cụ SaaS và tích hợp chúng trên các hệ thống. Nhân viên sử dụng nhiều dịch vụ đám mây của bên thứ ba và các doanh nghiệp quản lý khoảng 490 ứng dụng đám mây, nhiều trong số đó không được cấp phép hoặc không được bảo mật đúng cách.
Việc sử dụng SaaS cao (thường được gọi là SaaS sprawl) này đồng nghĩa với sự bùng nổ của OAuth tokens, API keys và các kết nối ứng dụng. Mỗi tích hợp giới thiệu một định danh phi con người (về cơ bản là một credential) mà thường không hiển thị đối với IT hoặc không được theo dõi bởi các giải pháp quản lý danh tính truyền thống.
Kết quả chung của điều này là một bề mặt tấn công không được quản lý. Một vài yếu tố thường góp phần tạo nên điểm mù này:
- Thiếu khả năng hiển thị. Nhiều tổ chức thực sự không biết về tất cả các ứng dụng SaaS và tích hợp mà nhân viên của họ đã bật, hoặc ai đã ủy quyền chúng. Shadow IT (nhân viên thêm ứng dụng mà không được chấp thuận) phát triển mạnh, và các đội bảo mật có thể chỉ phát hiện ra một kết nối OAuth sau khi nó đã tạo ra vấn đề.
- Không có sự chấp thuận hoặc giám sát. Nếu không có quy trình kiểm duyệt, người dùng có thể tự do kết nối các ứng dụng như plugin marketing hoặc công cụ năng suất với các tài khoản SaaS của công ty. Các ứng dụng của bên thứ ba này thường yêu cầu các quyền rộng rãi và được cấp, ngay cả khi chúng chỉ cần thiết tạm thời. Các ứng dụng chưa được kiểm duyệt và có đặc quyền quá mức có thể nằm kết nối vô thời hạn nếu không ai xem xét chúng.
- Không giám sát thường xuyên. Rất ít công ty thực thi cài đặt bảo mật trên các tích hợp OAuth hoặc theo dõi các kết nối này theo thời gian thực. Tokens hiếm khi có thời gian tồn tại ngắn hoặc phạm vi nghiêm ngặt theo mặc định, và các tổ chức thường không giới hạn việc sử dụng chúng theo IP hoặc thiết bị. Nhật ký từ các tích hợp SaaS cũng có thể không được đưa vào hệ thống giám sát bảo mật.
Tại sao bảo mật truyền thống bỏ qua vấn đề Token
Chính vì vậy, các công cụ bảo mật truyền thống hoàn toàn chưa bắt kịp vấn đề này.
Single sign-on (SSO) và multi-factor authentication bảo vệ thông tin đăng nhập của người dùng, nhưng OAuth tokens lại bỏ qua các kiểm soát này. Chúng cấp quyền tin cậy liên tục giữa các ứng dụng mà không cần xác minh thêm.
Một token hoạt động thay mặt cho người dùng hoặc dịch vụ mà không cần mật khẩu, vì vậy một kẻ tấn công thu được một token hợp lệ có thể truy cập dữ liệu của ứng dụng được kết nối như thể chúng đã được xác thực. Không có cửa sổ bật lên để kiểm tra lại MFA khi một OAuth token được sử dụng. Kết quả là, nếu không có sự giám sát đặc biệt, OAuth và API tokens đã trở thành gót chân Achilles trong bảo mật SaaS. Các giải pháp truyền thống khác, như cloud access security brokers, tập trung vào lưu lượng truy cập từ người dùng đến ứng dụng và không giám sát các kết nối giữa các ứng dụng này.
Khoảng trống này đã dẫn đến sự ra đời của các nền tảng bảo mật SaaS động nhằm mục đích khám phá và bảo mật các tích hợp SaaS trong bối cảnh SaaS sprawl. Các nền tảng này cố gắng lập bản đồ tất cả các ứng dụng của bên thứ ba, tokens và đặc quyền đang được sử dụng, mang lại khả năng hiển thị và kiểm soát. Cho dù thông qua khám phá tự động (quét các ứng dụng được kết nối) hay thực thi các chính sách về việc sử dụng OAuth, mục tiêu là để đóng lại khoảng trống bảo mật SaaS do các token không được kiểm soát tạo ra.
Cuối cùng, mọi tổ chức, dù có hay không có công cụ mới, đều có thể áp dụng các thực hành "vệ sinh" Token tốt hơn. Bạn không thể bảo vệ những gì bạn không thể thấy. Bước đầu tiên là biết các token và tích hợp SaaS của bạn ở đâu. Bước tiếp theo là kiểm soát và giám sát chúng để chúng không trở thành cửa hậu.
Danh sách kiểm tra "Vệ sinh" Token
Danh sách kiểm tra sau đây có thể được sử dụng để giảm thiểu rủi ro từ việc Token bị thỏa hiệp:
| Thực hành | Hành động | Đ/K |
|---|---|---|
| Duy trì kiểm kê ứng dụng OAuth | Khám phá và theo dõi tất cả các ứng dụng của bên thứ ba được kết nối với tài khoản SaaS của bạn. Giữ một danh sách kiểm kê cập nhật các OAuth tokens, API keys và các tích hợp. Điều này cung cấp khả năng hiển thị về dấu vết Token của bạn. | |
| Thực thi phê duyệt ứng dụng | Thiết lập một quy trình kiểm duyệt cho các tích hợp SaaS mới. Yêu cầu xem xét bảo mật hoặc phê duyệt của quản trị viên trước khi nhân viên cấp quyền truy cập OAuth cho tài khoản của họ. Điều này hạn chế các ứng dụng chưa được kiểm duyệt và đảm bảo mỗi token được cấp là cần thiết và đi kèm với các rủi ro đã biết. | |
| Tokens có ít đặc quyền nhất | Hạn chế phạm vi và quyền hạn của tokens ở mức tối thiểu cần thiết. Tránh cấp quyền truy cập quá rộng ("cho phép tất cả") khi ủy quyền cho một ứng dụng. Ví dụ, nếu một ứng dụng chỉ cần quyền đọc, đừng cấp cho nó quyền quản trị đọc-ghi. Đặc quyền tối thiểu giúp giảm thiểu tác động nếu một token bị đánh cắp. | |
| Xoay vòng Tokens thường xuyên | Xem các tokens có thời gian tồn tại dài như các credential hết hạn. Cấu hình tokens để hết hạn sau một khoảng thời gian ngắn, nếu có thể, hoặc định kỳ thu hồi và cấp lại chúng. Xoay vòng thường xuyên (hoặc thời gian tồn tại ngắn) có nghĩa là một token bị đánh cắp sẽ nhanh chóng trở nên vô dụng, thu hẹp cửa sổ cơ hội của kẻ tấn công. | |
| Loại bỏ hoặc cảnh báo về Tokens không sử dụng | Xác định các tokens và kết nối ứng dụng đã không được sử dụng trong nhiều tuần hoặc nhiều tháng. Các tokens không sử dụng là mối đe dọa tiềm ẩn – hãy thu hồi chúng nếu chúng không cần thiết. Triển khai cảnh báo hoặc báo cáo cho các tokens không hoạt động để chúng có thể được dọn dẹp chủ động, ngăn chặn các credential bị lãng quên tồn tại vô thời hạn. | |
| Giám sát hoạt động của Token | Bật nhật ký và giám sát việc sử dụng Token trên các nền tảng SaaS của bạn. Theo dõi hoạt động Token bất thường, chẳng hạn như một tích hợp thường không được sử dụng đột nhiên thực hiện các yêu cầu dữ liệu lớn hoặc truy cập từ các vị trí lạ. Thiết lập cảnh báo cho các bất thường trong việc sử dụng Token (ví dụ: một sự gia tăng đột biến trong các cuộc gọi API, hoặc việc sử dụng một token từ một IP không quen thuộc). | |
| Tích hợp Tokens vào quy trình Offboarding | Khi nhân viên nghỉ việc hoặc khi một ứng dụng của bên thứ ba bị ngừng sử dụng, hãy đảm bảo các tokens và khóa truy cập của họ được thu hồi kịp thời. Biến việc thu hồi Token thành một bước tiêu chuẩn trong quy trình offboarding người dùng và quản lý vòng đời ứng dụng. Điều này ngăn chặn các credential cũ tồn tại sau khi chúng không còn cần thiết. |
