API Tính toàn vẹn của Play giúp bạn kiểm tra để đảm bảo các lượt tương tác và yêu cầu gửi tới máy chủ đến từ tệp nhị phân của ứng dụng chính thống đang chạy trên một thiết bị Android thực. Bằng cách phát hiện các lượt tương tác tiềm ẩn rủi ro và gian lận, chẳng hạn như từ các phiên bản ứng dụng bị can thiệp và môi trường không đáng tin cậy, máy chủ phụ trợ của ứng dụng có thể phản hồi bằng những hành động thích hợp để ngăn chặn các cuộc tấn công và giảm thiểu hành vi sử dụng sai mục đích.
Khi ứng dụng hoặc trò chơi của bạn chạy trên thiết bị Android có Cửa hàng Google Play và sử dụng Dịch vụ Google Play, API Tính toàn vẹn của Play sẽ cung cấp nội dung phản hồi giúp bạn xác định xem mình có đang tương tác với những yếu tố sau đây hay không:
- Tệp nhị phân của ứng dụng chính thống: Xác định xem bạn có đang tương tác với tệp nhị phân chưa được sửa đổi mà Google Play biết hay không.
- Bản cài đặt chính thống từ Play: Xác định xem tài khoản người dùng hiện tại có được cấp phép hay không, tức là liệu người dùng đã cài đặt hoặc thanh toán cho ứng dụng/trò chơi trên Google Play chưa.
- Thiết bị Android thực: Xác định xem ứng dụng của bạn có đang chạy trên thiết bị Android thực sử dụng Dịch vụ Google Play (hoặc một phiên bản thực của Google Play Games dành cho máy tính) hay không.
Bạn cũng có thể chọn nhận thông tin về môi trường trong phản hồi của API Tính toàn vẹn của Play, bao gồm:
- Rủi ro truy cập ứng dụng: Xác định xem các ứng dụng đang chạy có khả năng dùng để chụp màn hình, hiển thị lớp phủ hoặc điều khiển thiết bị.
- Rủi ro từ phần mềm độc hại đã biết: Xác định xem bạn đã bật Google Play Protect hay chưa cũng như liệu Google có tìm thấy các ứng dụng gây rủi ro hoặc nguy hiểm được cài đặt trên thiết bị này hay không.
Tổng quan
Khi người dùng thực hiện một thao tác trong ứng dụng, bạn có thể gọi API Tính toàn vẹn của Play để kiểm tra nhằm đảm bảo việc đó xảy ra trong tệp nhị phân của ứng dụng chính thống (do Google Play cài đặt), chạy trên thiết bị Android chính hãng. Bạn cũng có thể chọn tham gia vào thông tin trong phản hồi, bao gồm cả số lượng yêu cầu mà một thiết bị đã đưa ra và các tín hiệu về môi trường, bao gồm cả rủi ro truy cập ứng dụng và kết quả kiểm tra Play Protect. Nếu có vấn đề gì với kết quả, thì máy chủ phụ trợ của ứng dụng có thể quyết định việc nên làm để ngăn chặn các sự cố chẳng hạn như hành vi sai trái và lừa đảo, sử dụng sai mục đích và gian lận, truy cập trái phép và tấn công.
Lưu ý về bảo mật
API Tính toàn vẹn của Play hữu ích nhất khi bạn làm theo các phương pháp đề xuất sau đây:
Có chiến lược chống hành vi sử dụng sai mục đích
API Tính toàn vẹn của Play hoạt động tốt nhất khi được dùng cùng với các tín hiệu khác để tạo thành một chiến lược chống hành vi sử dụng sai mục đích, chứ không phải như cơ chế phòng vệ duy nhất. Hãy sử dụng API này cùng với các phương pháp bảo mật hay nhất khác phù hợp với ứng dụng của bạn. Theo mặc định, ứng dụng của bạn có thể thực hiện tổng cộng 10.000 yêu cầu mỗi ngày trên tất cả lượt cài đặt. Bạn có thể yêu cầu tăng mức tối đa hằng ngày.
Thu thập dữ liệu đo từ xa và tìm hiểu đối tượng của bạn trước khi hành động
Trước khi thay đổi cách hoạt động của ứng dụng dựa trên kết quả của API Tính toàn vẹn của Play, bạn có thể tìm hiểu tình hình hiện tại của độc giả hiện tại bằng cách triển khai API mà không có biện pháp thực thi. Sau khi bạn biết kết quả nào về số lượt cài đặt hiện tại của mình là trở lại, bạn có thể ước tính tác động của bất kỳ biện pháp thực thi nào mà bạn đang lên kế hoạch và và điều chỉnh chiến lược chống hành vi sử dụng sai mục đích cho phù hợp.
Lựa chọn cách bạn yêu cầu kết quả về tính toàn vẹn
API Tính toàn vẹn của Play cung cấp 2 lựa chọn để yêu cầu và nhận kết quả về tính toàn vẹn. Cho dù bạn đưa ra yêu cầu thông thường, yêu cầu kiểu cũ hay kết hợp cả 2 loại yêu cầu, thì phản hồi kết quả về tính toàn vẹn sẽ được trả về ở cùng một định dạng.
Các yêu cầu API thông thường phù hợp với mọi ứng dụng/trò chơi và có thể được thực hiện theo yêu cầu để kiểm tra xem bất kỳ hành động nào của người dùng hoặc bất kỳ yêu cầu nào gửi tới máy chủ có phải là hành động/yêu cầu thật hay không. Các yêu cầu thông thường có độ trễ thấp nhất (trung bình vài trăm mili giây) và độ tin cậy cao trong quá trình thu thập kết quả hữu dụng. Các yêu cầu thông thường tận dụng khả năng lưu vào bộ nhớ đệm thông minh trên thiết bị khi uỷ quyền cho Google Play ngăn chặn một số loại tấn công nhất định.
Các yêu cầu API kiểu cũ (phương thức nguyên gốc để yêu cầu kết quả về tính toàn vẹn) vẫn có thể được sử dụng. Các yêu cầu kiểu cũ có độ trễ cao hơn (trung bình vài giây) và bạn chịu trách nhiệm giảm thiểu nguy cơ xảy ra một số loại tấn công nhất định. Các yêu cầu kiểu cũ sử dụng nhiều dữ liệu và pin của người dùng hơn so với các yêu cầu thông thường vì chúng khởi chạy một quy trình đánh giá hoàn toàn mới. Vì vậy, bạn chỉ nên thực hiện loại yêu cầu này một lần để kiểm tra xem một hành động có giá trị hay mang tính nhạy cảm cao có phải là thật hay không. Nếu đang cân nhắc tạo một yêu cầu kiểu cũ và lưu vào bộ nhớ đệm để sử dụng sau này, thì thay vào đó, bạn nên thực hiện một yêu cầu thông thường để giảm nguy cơ bị tấn công.
Bảng sau đây nêu bật một số điểm khác biệt chính giữa 2 loại yêu cầu này:
Yêu cầu API thông thường | Yêu cầu API kiểu cũ | |
---|---|---|
Cần có phiên bản SDK Android tối thiểu | Android 5.0 (API cấp 21) trở lên | Android 4.4 (API cấp 19) trở lên |
Cần phải khởi động API | ✔️ (vài giây) | ❌ |
Độ trễ thông thường của yêu cầu | Vài trăm mili giây | Vài giây |
Tần suất yêu cầu tiềm năng | Thường xuyên (kiểm tra theo yêu cầu đối với bất kỳ hành động hoặc yêu cầu nào) | Không thường xuyên (kiểm tra một lần đối với các hành động có giá trị cao nhất hoặc các yêu cầu mang tính nhạy cảm nhất) |
Giảm thiểu cuộc tấn công phát lại và các cuộc tấn công tương tự | Tự động giảm thiểu nhờ Google Play | Sử dụng trường nonce với logic phía máy chủ |
Bạn có thể thấy một bảng có nhiều khác biệt khác trong phần những điểm cần cân nhắc về yêu cầu kiểu cũ.
Yêu cầu kết quả về tính toàn vẹn vào một thời điểm thích hợp
Bạn nên yêu cầu cung cấp kết quả đánh giá rủi ro truy cập ứng dụng càng sớm càng tốt hành động hoặc yêu cầu gửi tới máy chủ mà bạn muốn bảo vệ khỏi bị truy cập, để ngăn chặn những kẻ lừa đảo vượt qua quy trình kiểm tra tính toàn vẹn do .
Khiến các yêu cầu API của bạn khó sao chép
Các yêu cầu API thông thường có một trường tên là requestHash
dùng để ngăn chặn hành vi can thiệp và các cuộc tấn công tương tự. Trong trường này, bạn nên thêm một chuỗi đại diện cho tất cả các giá trị có liên quan trong yêu cầu của ứng dụng. Làm theo hướng dẫn về cách sử dụng tính năng liên kết nội dung để bảo vệ các yêu cầu thông thường của ứng dụng.
Các yêu cầu API kiểu cũ có một trường tên là nonce
(viết tắt của number once (số chỉ dùng một lần)), dùng để ngăn chặn một số loại tấn công nhất định, chẳng hạn như các cuộc tấn công phát lại và can thiệp. Hãy làm theo hướng dẫn về cách tạo số chỉ dùng một lần để bảo vệ các yêu cầu kiểu cũ của ứng dụng.
Tránh lưu kết quả về tính toàn vẹn vào bộ nhớ đệm
Việc lưu vào bộ nhớ đệm các kết quả về tính toàn vẹn sẽ làm tăng nguy cơ bị tấn công proxy. Đây là kiểu tấn công trong đó đối tượng xấu sử dụng lại kết quả từ một thiết bị tốt cho mục đích sai trái trong một môi trường khác. Thay vì lưu các phản hồi vào bộ nhớ đệm, bạn có thể thực hiện yêu cầu API thông thường để nhận kết quả theo yêu cầu.
Có chiến lược thực thi theo cấp độ
Kết quả về tính toàn vẹn mà API Tính toàn vẹn của Play cung cấp có thể có phản hồi đa dạng, giúp bạn xây dựng được một chiến lược chống hành vi sử dụng sai mục đích với nhiều cấp độ thực thi. Bạn có thể thực hiện việc này bằng cách định cấu hình để máy chủ phụ trợ của ứng dụng hoạt động theo các cách khác nhau tuỳ vào từng phản hồi hoặc nhóm phản hồi.
Bạn cũng có thể phân cấp chiến lược thực thi dựa trên độ tin cậy của thiết bị bằng cách chọn nhận nhãn thiết bị bổ sung trong phản hồi của API từ Play Console. Mỗi thiết bị sẽ trả về tất cả các nhãn mà thiết bị đáp ứng tiêu chí. Ví dụ: sau khi chọn nhận tất cả các nhãn thiết bị, bạn có thể chọn tin tưởng thiết bị trả về MEETS_STRONG_INTEGRITY
, MEETS_DEVICE_INTEGRITY
và MEETS_BASIC_INTEGRITY
hơn so với thiết bị chỉ trả về MEETS_BASIC_INTEGRITY
. Bạn có thể để máy chủ phản hồi khác đi trong từng trường hợp.
Gửi một loạt các phản hồi từ máy chủ đến ứng dụng
Việc đưa ra một loạt kết quả cho quyết định sẽ khó sao chép hơn so với việc gửi một phản hồi nhị phân Cho phép/Từ chối từ máy chủ trở lại ứng dụng cho mỗi phản hồi. Ví dụ: bạn có thể sử dụng một loạt các phản hồi có liên quan như Cho phép, Cho phép kèm giới hạn, Cho phép kèm giới hạn sau khi hoàn thành hình ảnh xác thực (CAPTCHA) và Từ chối.
Phát hiện hành vi sai trái trên diện rộng bằng hoạt động gần đây trên thiết bị
Sử dụng tính năng hoạt động gần đây trên thiết bị trong API Tính toàn vẹn của Play để tìm thiết bị yêu cầu số lượng lớn mã thông báo về tính toàn vẹn. Hoạt động ở khối lượng lớn những người lạm dụng thường tạo kết quả chứng thực hợp lệ từ thiết bị thực và cung cấp chúng cho bot để tự động tấn công trên trình mô phỏng và thiết bị bị can thiệp hệ thống. Bạn có thể sử dụng cấp độ hoạt động gần đây trên thiết bị để kiểm tra số lượng chứng thực đã được ứng dụng của bạn tạo trên thiết bị đó trong giờ vừa qua.
Hiện thông báo lỗi có thể xử lý
Khi có thể, hãy cung cấp các thông báo lỗi hữu ích cho người dùng và cho họ biết những việc có thể làm để khắc phục vấn đề, chẳng hạn như thử lại, bật kết nối Internet hoặc kiểm tra để đảm bảo rằng ứng dụng Cửa hàng Play đã được cập nhật.
Lên kế hoạch cho các vấn đề hoặc tình trạng ngừng dịch vụ bất ngờ
Trang tổng quan về trạng thái của Play hiển thị thông tin về trạng thái dịch vụ của API Tính toàn vẹn của Play, cùng với thông tin về mọi sự cố gián đoạn và ngừng hoạt động. Bạn nên lên kế hoạch trước về cách bạn muốn máy chủ phụ trợ của mình hoạt động trong trường hợp hiếm gặp xảy ra với quy mô lớn API Tính toàn vẹn của Play ngừng hoạt động.
Cân nhắc các giải pháp chống gian lận toàn diện cho doanh nghiệp
Khách hàng doanh nghiệp đang tìm kiếm giải pháp toàn diện để quản lý bot và gian lận có thể mua reCAPTCHA Enterprise cho thiết bị di động. Trong dịch vụ này có SDK dành cho Android cung cấp điểm số về rủi ro gian lận cho nhà phát triển. reCAPTCHA Enterprise sẽ tự động nhận các tín hiệu của API Tính toàn vẹn của Play, đồng thời kết hợp các tín hiệu này với mạng reCAPTCHA và các tín hiệu của ứng dụng để cung cấp cho khách hàng một giải pháp quản lý gian lận độc đáo, thầm lặng nhưng vô cùng hiệu quả. Ngoài ra, giải pháp này còn có thể bảo vệ các ứng dụng Android khi không có API Tính toàn vẹn của Play.
Thử thách lưu lượng truy cập rủi ro khi sử dụng các tính năng nhạy cảm hoặc có giá trị cao
Xác định các hành động có giá trị cao/nhạy cảm trong ứng dụng hoặc trò chơi để bảo vệ bằng API Tính toàn vẹn của Play, thay vì từ chối quyền truy cập ngay lập tức. Khi có thể, hãy thử thách lưu lượng truy cập rủi ro trước khi cho phép các hành động có giá trị cao tiếp tục. Ví dụ: khi tính năng đánh giá rủi ro truy cập ứng dụng cho biết rằng một ứng dụng đang chạy có thể ghi lại màn hình, hãy yêu cầu người dùng tắt hoặc gỡ cài đặt các ứng dụng có thể ghi lại màn hình trước khi cho phép họ tiếp tục sử dụng chức năng mà bạn muốn bảo vệ.
Điều khoản dịch vụ và an toàn dữ liệu
Bằng cách truy cập hoặc sử dụng API Tính toàn vẹn của Play, bạn đồng ý với Điều khoản dịch vụ của API Tính toàn vẹn của Play. Vui lòng đọc và nắm được tất cả các điều khoản và chính sách hiện hành trước khi truy cập vào API này.
Google Play có một mục an toàn dữ liệu dành cho nhà phát triển để công bố thông tin về ứng dụng của họ thu thập, chia sẻ dữ liệu và các phương pháp bảo mật để luôn cập nhật thông tin cho người dùng. Để giúp bạn hoàn thành biểu mẫu dữ liệu, hãy xem thông tin về cách API Tính toàn vẹn của Play xử lý dữ liệu.