Interfejs Play Integrity API pomaga sprawdzać, czy działania użytkowników i żądania serwera pochodzą z autentycznej aplikacji zainstalowanej z Google Play i uruchomionej na oryginalnym, certyfikowanym urządzeniu z Androidem. Wykrywając ryzykowne interakcje, np. ze zmodyfikowanych wersji aplikacji, niezaufanych urządzeń lub środowisk emulowanych, serwer backendu może zareagować, podejmując odpowiednie działania zapobiegające nadużyciom i nieautoryzowanemu dostępowi, zwalczające oszustwa i nieuczciwe praktyki oraz chroniące użytkowników przed atakami.
Interfejs API zwraca oceny, które pomagają wykrywać potencjalne zagrożenia, w tym:
- Nieautoryzowany dostęp: wynik
accountDetailspomaga określić, czy użytkownik zainstalował Twoją aplikację lub grę w Google Play lub za nią zapłacił. - Modyfikacja kodu: ocena
appIntegritypomaga określić, czy używasz niezmodyfikowanego pliku binarnego rozpoznawanego przez Google Play. - Urządzenia stanowiące ryzyko i środowiska emulowane: ocena
deviceIntegritypomaga określić, czy aplikacja działa na oryginalnym certyfikowanym urządzeniu z Androidem lub oryginalnym wystąpieniu Gier Google Play na PC.
Deweloperzy w Google Play mogą też wyrazić zgodę na otrzymywanie dodatkowych ocen, aby wykrywać szerszy zakres potencjalnych zagrożeń, w tym:
- Urządzenia bez poprawek: odpowiedź
MEETS_STRONG_INTEGRITYw oceniedeviceIntegritypomaga określić, czy na urządzeniu zastosowano najnowsze aktualizacje zabezpieczeń (w przypadku urządzeń z Androidem 13 lub nowszym). - Ryzykowny dostęp innych aplikacji:
appAccessRiskVerdictpomaga określić, czy uruchomione są aplikacje, które mogą przechwytywać ekran, wyświetlać nakładki lub sterować urządzeniem (np. przez niewłaściwe wykorzystanie uprawnień ułatwień dostępu). - Znane złośliwe oprogramowanie: ocena
playProtectVerdictpomaga określić, czy usługa Google Play Protect jest włączona i czy wykryła zainstalowane na urządzeniu stwarzające ryzyko lub niebezpieczne aplikacje. - Nadaktywność: poziom
recentDeviceActivitypomaga określić, czy urządzenie wysłało ostatnio anomalnie dużą liczbę żądań, co może wskazywać na zautomatyzowany ruch i być oznaką ataku. - Powtarzające się nadużycia i ponownie używane urządzenia: funkcja
deviceRecall(wersja beta) pomaga określić, czy korzystasz z urządzenia, które zostało wcześniej przez Ciebie oznaczone, nawet jeśli aplikacja została ponownie zainstalowana lub urządzenie zostało zresetowane.
Interfejsu API można używać na urządzeniach z Androidem, w tym na telefonach, tabletach, urządzeniach składanych, Androidzie Auto, Androidzie TV, Androidzie XR, ChromeOS, Wear OS i w Grach Google Play na PC.
Bezpieczeństwo
Interfejs Play Integrity API będzie działać najlepiej, gdy zastosujesz te zalecane metody:
Opracuj strategię zapobiegania nadużyciom
Interfejs Play Integrity API działa najlepiej, gdy jest używany w połączeniu z innymi sygnałami w ramach ogólnej strategii przeciwdziałania nadużyciom, a nie jako jedyny mechanizm tego rodzaju. Używaj tego interfejsu API w połączeniu z innymi odpowiednimi sprawdzonymi metodami dotyczącymi bezpieczeństwa w aplikacji. Domyślnie aplikacja może wysyłać maksymalnie 10 tys. żądań dziennie we wszystkich instalacjach. Możesz poprosić o zwiększenie dziennego limitu.
Zbieranie danych telemetrycznych i poznawanie odbiorców przed podjęciem działań
Zanim zmienisz sposób działania aplikacji na podstawie ocen interfejsu Play Integrity API, możesz poznać obecną sytuację wśród dotychczasowych odbiorców, wdrażając interfejs API bez wymuszania. Gdy dowiesz się, jakie werdykty zwraca obecna liczba instalacji, możesz oszacować wpływ planowanych działań i odpowiednio dostosować strategię zapobiegania nadużyciom.
Wybierz sposób żądania oceny integralności
Play Integrity API oferuje 2 opcje wysyłania żądań dotyczących ocen integralności i ich otrzymywania. Niezależnie od tego, czy wysyłasz żądania standardowe, klasyczne czy kombinację obu typów, odpowiedź z oceną integralności będzie zwracana w tym samym formacie.
Standardowe żądania do interfejsu API są odpowiednie dla każdej aplikacji lub gry i można je wysyłać na żądanie, aby sprawdzić, czy działanie użytkownika lub żądanie serwera jest autentyczne. Żądania standardowe mają najkrótszy czas oczekiwania (średnio kilkaset milisekund) i wysoką niezawodność uzyskiwania przydatnej oceny. Żądania standardowe korzystają z inteligentnego buforowania na urządzeniu, a ochronę przed niektórymi rodzajami ataków przekazują Google Play.
Klasyczne żądania do interfejsu API, czyli pierwotny sposób żądania oceny integralności, również są nadal dostępne. Żądania klasyczne mają większe opóźnienie (średnio kilka sekund), a Ty odpowiadasz za ograniczanie ryzyka związanego z niektórymi rodzajami ataków. Klasyczne żądania zużywają więcej danych i baterii użytkownika niż żądania standardowe, ponieważ inicjują nową ocenę. Dlatego powinny być wysyłane rzadko, jako jednorazowe sprawdzenie, czy działanie o wysokiej czułości lub wartości jest autentyczne. Jeśli rozważasz wysłanie żądania klasycznego i zapisanie go w pamięci podręcznej do późniejszego użycia, wyślij żądanie standardowe, aby zmniejszyć ryzyko ataków.
W tej tabeli przedstawiono najważniejsze różnice między tymi 2 rodzajami żądań:
| Standardowe żądanie do interfejsu API | Żądanie do interfejsu API Classic | |
|---|---|---|
| Minimalna wymagana wersja pakietu Android SDK* | Android 6.0 (poziom interfejsu API 23) lub nowszy, | Android 6.0 (poziom interfejsu API 23) lub nowszy, |
| Wymagane rozgrzanie interfejsu API | ✔️ (kilka sekund) | ❌ |
| Typowy czas oczekiwania na żądanie | kilkaset milisekund, | kilka sekund, |
| Potencjalna częstotliwość żądań | Często (sprawdzanie na żądanie pod kątem działań lub próśb) | Rzadko (jednorazowa weryfikacja w przypadku działań o najwyższej wartości lub najbardziej poufnych żądań) |
| ochrona przed atakami typu replay i podobnymi; | Automatyczne zastosowanie złagodzeń przez Google Play | Używanie pola nonce z logiką po stronie serwera |
* W przypadku biblioteki Play Integrity API w wersji 1.4.0 i nowszych minimalna obsługiwana wersja pakietu Android SDK jest taka sama dla obu typów żądań i jest określana przez minSdkVersion biblioteki. W przypadku wersji 1.3.0 i starszych minimalna wersja pakietu Android SDK wymagana do obsługi żądań do standardowego interfejsu API to Android 5.0 (poziom interfejsu API 21), a do obsługi żądań do klasycznego interfejsu API – Android 4.4 (poziom interfejsu API 19).
Tabelę z większą liczbą różnic znajdziesz w sekcji Uwagi dotyczące klasycznych żądań.
Prośba o ocenę integralności w odpowiednim momencie
Aby uniemożliwić oszustom obejście kontroli integralności przeprowadzanej przez aplikację, poproś o ocenę ryzyka dotyczącego dostępu do aplikacji jak najbliżej momentu wykonania działania lub wysłania żądania do serwera, przed którym chcesz się zabezpieczyć.
Utrudnianie replikacji żądań do interfejsu API
Standardowe żądania do interfejsu API zawierają pole requestHash, które służy do ochrony przed manipulacją i podobnymi atakami. W tym polu należy podać podsumowanie wszystkich odpowiednich wartości z żądania aplikacji. Postępuj zgodnie ze wskazówkami dotyczącymi korzystania z wiązania treści, aby chronić standardowe żądania aplikacji.
Żądania do interfejsu Classic API mają pole o nazwie nonce (skrót od „number once”), które służy do ochrony przed niektórymi rodzajami ataków, takimi jak ataki typu replay i tampering. Postępuj zgodnie ze wskazówkami dotyczącymi generowania liczb jednorazowych, aby chronić klasyczne żądania aplikacji.
Unikaj zapisywania ocen integralności w pamięci podręcznej
Zapisywanie ocen integralności w pamięci podręcznej zwiększa ryzyko ataku polegającego na przekazywaniu, podczas którego nieuczciwy podmiot ponownie wykorzystuje ocenę z dobrego urządzenia do nadużyć w innym środowisku. Zamiast zapisywać odpowiedzi w pamięci podręcznej, możesz wysłać standardowe żądanie do interfejsu API, aby uzyskać ocenę na żądanie.
Zastosuj wielopoziomową strategię egzekwowania zasad
Ocena integralności określona przez interfejs Play Integrity API może wiązać się z różnymi reakcjami, co pozwala opracować strategię przeciwdziałania nadużyciom z wieloma poziomami egzekwowania zasad. Możesz to zrobić, konfigurując serwer backendu aplikacji tak, aby działał inaczej w zależności od każdej możliwej odpowiedzi lub grupy odpowiedzi.
Zanim ocenisz wiarygodność urządzenia, musisz sprawdzić inne podstawowe sygnały w odpowiedzi interfejsu API:
- Szczegóły żądania: upewnij się, że
requestDetailsodpowiada oczekiwanym wartościom, w szczególności sprawdźrequestHashlubnonce, aby zapobiec atakom typu replay. - Integralność aplikacji: sprawdź, czy parametr
appRecognitionVerdictma wartośćPLAY_RECOGNIZED, co potwierdza, że certyfikat podpisywania aplikacji jest rozpoznawany przez Google Play i nie został zmodyfikowany. - Szczegóły konta: sprawdź, czy
appLicensingVerdicttoLICENSED, co potwierdza, że użytkownik zainstalował lub zaktualizował aplikację z Google Play.
Aplikacja powinna być w stanie obsłużyć sytuację, gdy te podstawowe testy zakończą się niepowodzeniem, np. za pomocą okna dialogowego działań naprawczych w aplikacji w Google Play. Aplikacja powinna też obsługiwać kody błędów, które mogą wystąpić podczas żądania.
Gdy podstawowe testy zakończą się pomyślnie, możesz podzielić strategię egzekwowania na poziomy na podstawie wiarygodności urządzenia, wyrażając zgodę na otrzymywanie dodatkowych etykiet urządzeń w odpowiedzi interfejsu API z Konsoli Play. Każde urządzenie zwróci wszystkie etykiety, których kryteria spełnia. Aby uzyskać wersję pakietu Android SDK, użyj pola deviceAttributes zawartego w odpowiedzi interfejsu API.
Poziomy zaufania do urządzeń obejmują urządzenia od bardziej do mniej zaufanych:
MEETS_STRONG_INTEGRITY(Android 13 lub nowszy): najwyższy poziom zaufania urządzenia, który wymaga potwierdzonych sprzętowo sygnałów zabezpieczeń i najnowszej poprawki zabezpieczeń.MEETS_DEVICE_INTEGRITY(Android 13 lub nowszy) iMEETS_STRONG_INTEGRITY(Android starszy niż 13): kolejny poziom zaufania. Obie metody opierają się na sygnałach bezpieczeństwa opartych na sprzęcie.MEETS_DEVICE_INTEGRITY(Android 12 i starsze): następny poziom, który używa atestu sprzętowego, gdy jest dostępny, i atestu programowego jako rozwiązania zastępczego.MEETS_BASIC_INTEGRITY: najniższy poziom zaufania, tuż przed brakiem etykiet urządzeń.
Na przykład po wyrażeniu zgody na otrzymywanie wszystkich etykiet urządzeń możesz uznać urządzenie, które zwraca MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY i MEETS_BASIC_INTEGRITY, za bardziej zaufane niż urządzenie, które zwraca tylko MEETS_BASIC_INTEGRITY. W każdym scenariuszu możesz odpowiedzieć inaczej niż serwer.
Następnie możesz dodać inne sygnały do strategii egzekwowania zasad, np. traktować urządzenia, które zwracają wyższe poziomy w recentDeviceActivity, jako mniej zaufane.
Wysyłanie różnych odpowiedzi z serwera do aplikacji
Zakres wyników decyzji jest trudniejszy do odtworzenia niż wysyłanie z serwera do aplikacji odpowiedzi binarnej „zezwól” lub „odmów” dla każdej odpowiedzi. Możesz na przykład użyć serii powiązanych odpowiedzi, takich jak Zezwól, Zezwól z ograniczeniami, Zezwól z ograniczeniami po wypełnieniu testu CAPTCHA i Odmów.
Wykrywanie powtarzających się nadużyć za pomocą zapamiętania urządzenia przy jednoczesnym zachowaniu prywatności użytkownika
Zapamiętanie urządzenia umożliwia aplikacjom przechowywanie i odczytywanie niektórych danych niestandardowych powiązanych z konkretnym urządzeniem w taki sposób, aby zachować prywatność użytkownika. Dane są przechowywane na serwerach Google, dzięki czemu aplikacja może niezawodnie przywoływać dane dotyczące poszczególnych urządzeń nawet po ponownej instalacji aplikacji lub zresetowaniu urządzenia. Dzięki temu możesz niezawodnie zidentyfikować urządzenie, na którym wcześniej dochodziło do nadużyć, i podjąć działania, aby zapobiec ponownemu wykorzystaniu go do nadużyć. Możesz zdefiniować własne znaczenie 3 wartości, które składają się na dane zapamiętania urządzenia:
- Można ich używać jako maksymalnie 3 osobnych flag lub wartości logicznych. Wartości mogą na przykład wskazywać, czy na urządzeniu utworzono konto, czy wykorzystano bezpłatny okres próbny lub czy urządzenie było używane do poważnych nadużyć.
- Możesz też połączyć wszystkie stany wartości w maksymalnie 8 etykiet własnych, np. 1 etykietę dla stanu domyślnego, gdy wszystkie 3 wartości są niezmienione, i 7 etykiet o niestandardowych znaczeniach. Dzięki temu możesz podzielić wszystkie urządzenia na maksymalnie 8 grup na podstawie zdefiniowanych przez siebie zachowań lub działań. W tym scenariuszu najnowsza z 3 aktualizacji
writeDateswskazuje, kiedy ostatnio zaktualizowano etykietę.
Podczas pracy z danymi zapamiętywania urządzenia pamiętaj też o wymaganiach wstępnych i innych kwestiach.
Wykrywanie nadużyć na dużą skalę na podstawie ostatniej aktywności na urządzeniu
Użyj funkcji ostatniej aktywności na urządzeniu w interfejsie Play Integrity API, aby znaleźć urządzenia, które wysyłają żądania dużej liczby tokenów integralności. Osoby, które nadużywają usługi, generują zwykle prawidłowe wyniki atestacji z prawdziwych urządzeń i udostępniają je botom, aby zautomatyzować ataki na urządzenia z dostępem do roota i emulatory. Możesz użyć poziomu ostatniej aktywności na urządzeniu, aby sprawdzić, ile atestów wygenerowała Twoja aplikacja na tym urządzeniu w ciągu ostatniej godziny.
Wyświetlanie komunikatów o błędach, które można rozwiązać
Jeśli to możliwe, wyświetlaj użytkownikom przydatne komunikaty o błędach z informacjami, jak mogą rozwiązać problem, np. spróbować ponownie, włączyć połączenie z internetem lub sprawdzić, czy aplikacja Sklep Play jest aktualna.
Przygotuj plan na wypadek nieoczekiwanych problemów lub przerw w działaniu usługi
W panelu stanu Google Play znajdziesz informacje o stanie usługi Play Integrity API oraz o przerwach i zakłóceniach w jej działaniu. Zaplanuj z wyprzedzeniem, w jaki sposób serwer backendu ma działać w mało prawdopodobnym przypadku przerwy w działaniu usługi Play Integrity API na dużą skalę. Pamiętaj, że serwer backendu powinien być też gotowy do działania w przypadku, gdy klucze atestacji kluczy platformy Androida dla konkretnych urządzeń zostaną unieważnione.
Rozważ kompleksowe rozwiązania do ochrony firm przed oszustwami
Klienci korporacyjni, którzy szukają kompletnego rozwiązania do zarządzania oszustwami i botami, mogą kupić reCAPTCHA Enterprise na urządzenia mobilne. To rozwiązanie obejmuje pakiety SDK na Androida, które dostarczają deweloperom oceny ryzyka oszustwa. reCAPTCHA Enterprise automatycznie uwzględnia sygnały z Play Integrity API i łączy je z sygnałami z sieci i aplikacji reCAPTCHA, zapewniając klientom bezproblemowe, niewidoczne i gotowe do użycia rozwiązanie do zarządzania oszustwami. Może też zapewniać ochronę aplikacji na Androida, w których interfejs Play Integrity API jest niedostępny.
Weryfikuj podejrzany ruch podczas uzyskiwania dostępu do funkcji o wysokiej wartości lub funkcji poufnych.
Zidentyfikuj w aplikacji lub grze działania o wysokiej wartości lub działania poufne, które chcesz chronić za pomocą interfejsu Play Integrity API, zamiast od razu odmawiać dostępu. Jeśli to możliwe, sprawdzaj podejrzany ruch, zanim zezwolisz na wykonanie działań o wysokiej wartości. Na przykład gdy ryzyko dotyczące dostępu do aplikacji wskazuje, że uruchomiona jest aplikacja, która może przechwytywać ekran, poproś użytkownika o wyłączenie lub odinstalowanie aplikacji, które mogą przechwytywać ekran, zanim zezwolisz mu na przejście do funkcji, którą chcesz chronić.
Warunki korzystania z usługi i bezpieczeństwo danych
Używanie interfejsu Play Integrity API oznacza akceptację Warunków korzystania z interfejsu Play Integrity API. Przed uzyskaniem dostępu do interfejsu API przeczytaj i zrozum wszystkie obowiązujące warunki i zasady.
W Google Play znajduje się sekcja Bezpieczeństwo danych, w której deweloperzy mogą informować użytkowników o sposobach zbierania, udostępniania i zabezpieczania danych przez aplikacje. Aby dowiedzieć się, jak wypełnić formularz, zapoznaj się z informacjami o tym, jak interfejs Play Integrity API przetwarza dane.