Play Integrity API के बारे में खास जानकारी

Play Integrity API की मदद से यह पता किया जा सकता है कि उपयोगकर्ता की कार्रवाइयां और सर्वर के अनुरोध, आप ही के ऐप्लिकेशन से हो रहे हैं या नहीं. साथ ही, यह पता किया जा सकता है कि ऐप्लिकेशन Google Play से इंस्टॉल किया गया है या नहीं और उसे सही और सर्टिफ़ाइड Android डिवाइस पर चलाया जा रहा है या नहीं. जोखिम भरे इंटरैक्शन का पता लगाकर, आपका बैकएंड सर्वर सही कार्रवाइयां कर सकता है. जैसे, छेड़छाड़ किए गए ऐप्लिकेशन वर्शन, गैर-भरोसेमंद डिवाइसों या एम्युलेट किए गए एनवायरमेंट से होने वाले इंटरैक्शन. इससे, ऐप्लिकेशन के गलत इस्तेमाल और बिना अनुमति वाले ऐक्सेस को रोका जा सकता है. साथ ही, धोखाधड़ी और डेटा चोरी को रोका जा सकता है. इसके अलावा, उपयोगकर्ताओं को सायबर हमलों से बचाया जा सकता है.

एपीआई ऐसे नतीजे दिखाता है जिनसे आपको संभावित खतरों का पता लगाने में मदद मिलती है. जैसे:

• बिना अनुमति के ऐक्सेस: accountDetails के फ़ैसले से आपको यह पता चलता है कि उपयोगकर्ता ने Google Play पर आपके ऐप्लिकेशन या गेम को इंस्टॉल किया है या उसके लिए पैसे चुकाए हैं.
• कोड में छेड़छाड़: appIntegrity नतीजे से आपको यह तय करने में मदद मिलती है कि आपका इंटरैक्शन, आपकी उस असल बाइनरी से हो रहा है या नहीं जिसकी पहचान Google Play ने की है.
• जोखिम भरे डिवाइस और एमुलेट किए गए एनवायरमेंट: deviceIntegrity नतीजे से आपको यह पता चलता है कि आपका ऐप्लिकेशन, सर्टिफ़ाइड किए गए किसी भरोसेमंद Android डिवाइस पर चल रहा है या नहीं. इससे यह भी पता चलता है कि आपका ऐप्लिकेशन किसी ऐसे पीसी पर चल रहा है या नहीं जिस पर Google Play Games काम करता है.

Google Play डेवलपर, ज़्यादा नतीजे पाने के लिए भी ऑप्ट-इन कर सकते हैं. इससे उन्हें संभावित खतरों की ज़्यादा रेंज का पता लगाने में मदद मिलेगी. जैसे:

• पैच नहीं किए गए डिवाइस: deviceIntegrity के फ़ैसले में MEETS_STRONG_INTEGRITY जवाब से यह पता चलता है कि किसी डिवाइस पर हाल ही में किए गए सुरक्षा अपडेट लागू किए गए हैं या नहीं. यह जानकारी, Android 13 और इसके बाद के वर्शन पर काम करने वाले डिवाइसों के लिए होती है.
• दूसरे ऐप्लिकेशन से जोखिम भरा ऐक्सेस: appAccessRiskVerdict की मदद से, यह पता लगाया जा सकता है कि क्या ऐसे ऐप्लिकेशन चल रहे हैं जिनका इस्तेमाल स्क्रीन कैप्चर करने, ओवरले दिखाने या डिवाइस को कंट्रोल करने के लिए किया जा सकता है. उदाहरण के लिए, ऐक्सेसिबिलिटी की अनुमति का गलत इस्तेमाल करके.
• पहले से मौजूद मैलवेयर: playProtectVerdict की मदद से, यह पता लगाया जा सकता है कि डिवाइस में Google Play Protect की सुविधा चालू है या नहीं. साथ ही, यह भी पता लगाया जा सकता है कि डिवाइस पर जोखिम भरे या खतरनाक ऐप्लिकेशन इंस्टॉल किए गए हैं या नहीं.
• ज़्यादा गतिविधि: recentDeviceActivity लेवल से यह पता चलता है कि किसी डिवाइस ने हाल ही में असामान्य रूप से ज़्यादा अनुरोध किए हैं या नहीं. इससे ऑटोमेटेड ट्रैफ़िक का पता चल सकता है और यह किसी हमले का संकेत हो सकता है.
• बार-बार होने वाले गलत इस्तेमाल और दोबारा इस्तेमाल किए गए डिवाइस: deviceRecall (बीटा) की मदद से, यह पता लगाया जा सकता है कि आपका इंटरैक्शन ऐसे डिवाइस से हो रहा है जिसे आपने पहले फ़्लैग किया था. भले ही, आपका ऐप्लिकेशन फिर से इंस्टॉल किया गया हो या डिवाइस को रीसेट किया गया हो.

इस एपीआई का इस्तेमाल, Android के अलग-अलग साइज़, डाइमेंशन या कॉन्फ़िगरेशन वाले डिवाइसों पर किया जा सकता है. जैसे, फ़ोन, टैबलेट, फ़ोल्ड किए जा सकने वाले डिवाइस, Android Auto, Android TV, Android XR, ChromeOS, Wear OS, और Google Play Games for PC.

सुरक्षा से जुड़ी बातें

Play Integrity API आपके ऐप्लिकेशन के लिए सबसे ज़्यादा मददगार तब साबित होता है, जब इन सुझाए गए तरीकों का पालन किया जाता है:

गलत इस्तेमाल रोकने के लिए रणनीति बनाना

अगर Play Integrity API को सिर्फ़ गलत इस्तेमाल रोकने के एक तरीके के बजाय, गलत इस्तेमाल रोकने की रणनीति के तौर पर अन्य सिग्नल के साथ इस्तेमाल किया जाता है, तो यह एपीआई सबसे असरदार साबित होता है. अपने ऐप्लिकेशन के लिए, इस एपीआई का इस्तेमाल सुरक्षा से जुड़े अन्य सबसे सही तरीकों के साथ करें. डिफ़ॉल्ट रूप से, आपका ऐप्लिकेशन सभी इंस्टॉल के लिए हर दिन ज़्यादा से ज़्यादा 10,000 अनुरोध कर सकता है. हर दिन के लिए तय की गई सीमा को बढ़ाने का अनुरोध किया जा सकता है.

कार्रवाई करने से पहले, टेलीमेट्री डेटा इकट्ठा करें और अपनी ऑडियंस को समझें

Play Integrity API के नतीजों के आधार पर, अपने ऐप्लिकेशन के व्यवहार में बदलाव करने से पहले, एपीआई को लागू करके मौजूदा ऑडियंस की मौजूदा स्थिति को समझा जा सकता है. हालांकि, इस दौरान एपीआई को लागू नहीं किया जाएगा. जब आपको यह पता चल जाए कि इंस्टॉल किए गए ऐप्लिकेशन के मौजूदा बेस से कौनसे फ़ैसले मिल रहे हैं, तब आप लागू की जाने वाली किसी भी नीति के असर का अनुमान लगा सकते हैं. साथ ही, उसके हिसाब से, ऐप्लिकेशन के गलत इस्तेमाल को रोकने के लिए बनाई गई रणनीति में बदलाव कर सकते हैं.

तय करें कि आपको इंटिग्रिटी के नतीजों का अनुरोध कैसे करना है

Play Integrity API, पूरी सुरक्षा की जांच के नतीजे पाने और उनका अनुरोध करने के लिए दो विकल्प देता है. स्टैंडर्ड अनुरोध, क्लासिक अनुरोध या दोनों तरह के अनुरोधों का कॉम्बिनेशन करने पर, पूरी सुरक्षा की जांच के नतीजे का जवाब एक ही फ़ॉर्मैट में मिलेगा.

एपीआई के स्टैंडर्ड अनुरोध, किसी भी ऐप्लिकेशन या गेम के लिए सही होते हैं. इन्हें मांग पर भेजा जा सकता है, ताकि यह पता लगाया जा सके कि उपयोगकर्ता की कोई कार्रवाई या सर्वर का अनुरोध सही है या नहीं. स्टैंडर्ड अनुरोधों के लिए इंतज़ार का समय सबसे कम होता है. औसतन, यह कुछ सौ मिलीसेकंड होता है. साथ ही, इस्तेमाल किए जा सकने वाले नतीजे मिलने की संभावना ज़्यादा होती है. स्टैंडर्ड अनुरोधों में, डिवाइस पर मौजूद स्मार्ट कैश मेमोरी का इस्तेमाल किया जाता है. साथ ही, कुछ तरह के हमलों से सुरक्षा की ज़िम्मेदारी Google Play को सौंपी जाती है.

क्लासिक एपीआई अनुरोध, पूरी सुरक्षा की जांच के नतीजे पाने का मूल तरीका है. यह तरीका भी अब भी उपलब्ध है. क्लासिक अनुरोधों में ज़्यादा समय लगता है. औसतन, कुछ सेकंड का समय लगता है. साथ ही, आपको कुछ खास तरह के हमलों के जोखिम को कम करने की ज़िम्मेदारी लेनी होती है. क्लासिक अनुरोधों में, स्टैंडर्ड अनुरोधों की तुलना में उपयोगकर्ता के ज़्यादा डेटा और बैटरी का इस्तेमाल होता है. ऐसा इसलिए, क्योंकि ये अनुरोध नए सिरे से आकलन शुरू करते हैं. इसलिए, इन्हें कभी-कभी ही किया जाना चाहिए. ऐसा एक बार में ही यह जांचने के लिए किया जाना चाहिए कि कोई बेहद संवेदनशील या अहम कार्रवाई असली है या नहीं. अगर आपको क्लासिक अनुरोध करना है और उसे बाद में इस्तेमाल करने के लिए कैश मेमोरी में सेव करना है, तो आपको स्टैंडर्ड अनुरोध करना चाहिए. इससे हमलों का खतरा कम हो जाएगा.

यहां दी गई टेबल में, दोनों तरह के अनुरोधों के बीच के कुछ मुख्य अंतरों को हाइलाइट किया गया है:

	स्टैंडर्ड एपीआई अनुरोध	क्लासिक एपीआई अनुरोध
Android SDK टूल का कम से कम यह वर्शन होना ज़रूरी है*	Android 6.0 (एपीआई लेवल 23) या इसके बाद का वर्शन	Android 6.0 (एपीआई लेवल 23) या इसके बाद का वर्शन
एपीआई को चालू करने के लिए, कुछ समय तक इसका इस्तेमाल करना ज़रूरी है	✔️ (कुछ सेकंड)	❌
अनुरोध पूरा होने में लगने वाला सामान्य समय	कुछ सौ मिलीसेकंड	कुछ सेकंड
अनुरोध की संभावित फ़्रीक्वेंसी	बार-बार (किसी कार्रवाई या अनुरोध के लिए, मांग पर जांच करना)	कभी-कभी (सबसे ज़्यादा वैल्यू वाले ऐक्शन या सबसे संवेदनशील अनुरोधों के लिए एक बार जांच)
जवाबी और मिलते-जुलते हमलों से बचाव	Google Play की ओर से अपने-आप जोखिम कम करने की सुविधा	सर्वर साइड लॉजिक के साथ nonce फ़ील्ड का इस्तेमाल करना

* Play Integrity API लाइब्रेरी v1.4.0 और इसके बाद के वर्शन के लिए, दोनों तरह के अनुरोधों के लिए Android SDK का कम से कम ज़रूरी वर्शन एक जैसा होता है. यह लाइब्रेरी के minSdkVersion से तय होता है. v1.3.0 और इससे पहले के वर्शन के लिए, स्टैंडर्ड एपीआई अनुरोधों के लिए Android 5.0 (एपीआई लेवल 21) और क्लासिक एपीआई अनुरोधों के लिए Android 4.4 (एपीआई लेवल 19) का Android SDK ज़रूरी है.

क्लासिक अनुरोधों से जुड़ी बातों में, आपको दोनों के बीच के अंतर के बारे में ज़्यादा जानकारी वाली टेबल मिल सकती है.

सही समय पर, पूरी सुरक्षा की जांच के नतीजे का अनुरोध करना

आपको ऐप्लिकेशन के ऐक्सेस से जुड़े जोखिम के बारे में फ़ैसले का अनुरोध, उस कार्रवाई या सर्वर के अनुरोध के समय के आस-पास करना चाहिए जिसे आपको ऐक्सेस होने से बचाना है. इससे, धोखाधड़ी करने वाले लोगों को आपके ऐप्लिकेशन की ओर से की गई इंटिग्रिटी जांच को बायपास करने से रोका जा सकेगा.

अपने एपीआई अनुरोधों को दोहराना मुश्किल बनाएं

एपीआई के स्टैंडर्ड अनुरोधों में requestHash नाम का एक फ़ील्ड होता है. इसका इस्तेमाल, डेटा में छेड़छाड़ और इस तरह के अन्य हमलों से बचाने के लिए किया जाता है. इस फ़ील्ड में, आपको अपने ऐप्लिकेशन के अनुरोध से मिली सभी काम की वैल्यू का डाइजेस्ट शामिल करना चाहिए. अपने ऐप्लिकेशन के स्टैंडर्ड अनुरोधों को सुरक्षित रखने के लिए, कॉन्टेंट बाइंडिंग का इस्तेमाल करने का तरीका देखें.

क्लासिक एपीआई अनुरोधों में nonce (इसे एक बार इस्तेमाल किया जा सकता है) नाम का फ़ील्ड होता है. इसका इस्तेमाल, कुछ तरह के हमलों से सुरक्षा के लिए किया जाता है. जैसे, रीप्ले और छेड़छाड़ वाले हमले. अपने ऐप्लिकेशन के क्लासिक अनुरोधों को सुरक्षित रखने के लिए, नॉनस जनरेट करने के तरीके के बारे में दिए गए दिशा-निर्देशों का पालन करें.

इंटिग्रिटी के नतीजों को कैश मेमोरी में सेव न करें

डिवाइस पर पूरी सुरक्षा की जांच के नतीजों को कैश मेमोरी में सेव करने से, प्रॉक्सी करने का जोखिम बढ़ जाता है. यह एक ऐसा हमला है जिसमें कोई गलत व्यक्ति, किसी भरोसेमंद डिवाइस के नतीजे का गलत इस्तेमाल करता है. ऐसा वह किसी दूसरे एनवायरमेंट में करता है. जवाबों को कैश मेमोरी में सेव करने के बजाय, मांग पर फ़ैसले पाने के लिए स्टैंडर्ड एपीआई अनुरोध किया जा सकता है.

नीति उल्लंघन ठीक करने के लिए, अलग-अलग चरणों वाली रणनीति बनाना

Play Integrity API की सुरक्षा जांच से कई अलग-अलग नतीजे मिलते हैं. इससे हर एक नतीजे के हिसाब से, गलत इस्तेमाल को रोकने की अलग-अलग रणनीतियां बनाई जा सकती हैं और उन्हें लागू करने के कई तरीके सेट किए जा सकते हैं. इसके लिए, अपने ऐप्लिकेशन के बैकएंड सर्वर को इस तरह कॉन्फ़िगर करें कि वह हर संभावित जवाब या जवाबों के ग्रुप के हिसाब से अलग-अलग कार्रवाई कर सके.

डिवाइस के भरोसेमंद होने का आकलन करने से पहले, एपीआई से मिले जवाब में मौजूद अन्य मुख्य सिग्नल की जांच करना ज़रूरी है:

• अनुरोध की जानकारी: पक्का करें कि requestDetails आपकी उम्मीद के मुताबिक वैल्यू से मेल खाती हो. खास तौर पर, requestHash या nonce की पुष्टि करें, ताकि रीप्ले अटैक को रोका जा सके.
• ऐप्लिकेशन के लिए पूरी सुरक्षा देने की सुविधा: यह जांच करें कि appRecognitionVerdict, PLAY_RECOGNIZED है या नहीं. इससे यह पुष्टि होती है कि ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट को Play ने मंज़ूरी दी है और उसमें कोई बदलाव नहीं किया गया है.
• खाते की जानकारी: देखें कि appLicensingVerdict LICENSED है या नहीं. इससे पुष्टि होती है कि उपयोगकर्ता ने Google Play से ऐप्लिकेशन इंस्टॉल या अपडेट किया है.

अगर ये बुनियादी जांचें पूरी नहीं होती हैं, तो आपका ऐप्लिकेशन इस स्थिति को मैनेज कर पाए. उदाहरण के लिए, ऐप्लिकेशन में मौजूद Play की गड़बड़ी ठीक करने वाला डायलॉग का इस्तेमाल करना. इसके अलावा, आपके ऐप्लिकेशन में गड़बड़ी के कोड को हैंडल करने की सुविधा भी होनी चाहिए. ये कोड, अनुरोध के दौरान दिख सकते हैं.

बुनियादी जांचों के पास होने के बाद, डिवाइस के भरोसेमंद होने के आधार पर, उल्लंघन रोकने की रणनीति को अलग-अलग लेवल पर लागू किया जा सकता है. इसके लिए, Play Console से एपीआई के जवाब में डिवाइस के अतिरिक्त लेबल पाने के लिए ऑप्ट-इन करें. हर डिवाइस उन सभी लेबल को दिखाएगा जिनके लिए वह ज़रूरी शर्तें पूरी करता है. Android SDK टूल का वर्शन पाने के लिए, आपको एपीआई रिस्पॉन्स में शामिल deviceAttributes फ़ील्ड का इस्तेमाल करना चाहिए. डिवाइस ट्रस्ट टियर की रेंज, ज़्यादा भरोसेमंद से लेकर कम भरोसेमंद डिवाइसों तक होती है:

• MEETS_STRONG_INTEGRITY (Android 13 और इसके बाद के वर्शन वाले डिवाइस): यह डिवाइस के भरोसे का सबसे ऊंचा टियर है. इसके लिए, हार्डवेयर में सेव किए गए सुरक्षित सिग्नल और हाल ही का सुरक्षा पैच ज़रूरी है.
• MEETS_DEVICE_INTEGRITY (Android 13 और इसके बाद के वर्शन) और MEETS_STRONG_INTEGRITY (Android 13 से पहले के वर्शन): यह भरोसे का अगला टियर है. दोनों ही, हार्डवेयर की मदद से सुरक्षा सिग्नल पर भरोसा करते हैं.
• MEETS_DEVICE_INTEGRITY (Android 13 से पहले के वर्शन): यह अगला टियर है. इसमें, हार्डवेयर की मदद से पुष्टि करने की सुविधा उपलब्ध होने पर उसका इस्तेमाल किया जाता है. साथ ही, सॉफ़्टवेयर की मदद से पुष्टि करने की सुविधा को फ़ॉलबैक के तौर पर इस्तेमाल किया जाता है.
• MEETS_BASIC_INTEGRITY: यह सबसे कम भरोसे वाला टियर है. इसके बाद, डिवाइस के लिए कोई लेबल नहीं मिलता.

उदाहरण के लिए, सभी डिवाइस लेबल पाने के लिए ऑप्ट-इन करने के बाद, आपके पास यह चुनने का विकल्प होता है कि आपको किस डिवाइस पर भरोसा करना है. ऐसे में, MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY, और MEETS_BASIC_INTEGRITY लेबल वाले डिवाइस पर, सिर्फ़ MEETS_BASIC_INTEGRITY लेबल वाले डिवाइस के मुकाबले ज़्यादा भरोसा किया जा सकता है. हर स्थिति में, सर्वर से अलग-अलग जवाब दिए जा सकते हैं.

इसके बाद, टियर के हिसाब से उल्लंघन ठीक करने की रणनीति में अन्य सिग्नल जोड़े जा सकते हैं. जैसे, recentDeviceActivity में ज़्यादा लेवल वाले डिवाइसों को कम भरोसेमंद माना जा सकता है.

अपने सर्वर से, ऐप्लिकेशन को कई तरह के जवाब भेजना

हर जवाब के लिए, सर्वर से ऐप्लिकेशन को अनुमति दें/अस्वीकार करें वाला बाइनरी जवाब भेजने की तुलना में, फ़ैसले के अलग-अलग नतीजों को दोहराना ज़्यादा मुश्किल होता है. उदाहरण के लिए, इससे जुड़ी प्रतिक्रियाओं की एक सीरीज़ का इस्तेमाल किया जा सकता है. जैसे, अनुमति दें, कुछ शर्तों के साथ अनुमति दें, कैप्चा पूरा करने के बाद कुछ शर्तों के साथ अनुमति दें, और अनुमति न दें.

डिवाइस रीकॉल का इस्तेमाल करके, बार-बार होने वाले गलत इस्तेमाल का पता लगाना. साथ ही, उपयोगकर्ता की निजता को बनाए रखना

डिवाइस रीकॉल की सुविधा से, ऐप्लिकेशन को किसी डिवाइस से जुड़े कस्टम डेटा को सेव करके उसे वापस लाने की सुविधा मिलती है. इसमें उपयोगकर्ता की निजता सुरक्षित रहती है. इस डेटा को Google के सर्वर पर सेव रखा जाता है. इससे ऐप्लिकेशन के फिर से इंस्टॉल होने या डिवाइस रीसेट हो जाने के बाद भी डिवाइसों का डेटा आसानी से वापस लाया जा सकता है. इससे आपको उस डिवाइस की पहचान करने का एक भरोसेमंद तरीका मिलता है जिसका इस्तेमाल आपने पहले गलत तरीके से किया था. इससे आपको उस डिवाइस के ख़िलाफ़ कार्रवाई करने और उसे फिर से गलत तरीके से इस्तेमाल होने से रोकने में मदद मिलती है. डिवाइस रीकॉल डेटा बनाने वाली तीन वैल्यू का मतलब तय किया जा सकता है:

• इनका इस्तेमाल ज़्यादा से ज़्यादा तीन अलग-अलग फ़्लैग या बूलियन के तौर पर किया जा सकता है. उदाहरण के लिए, वैल्यू से यह पता चल सकता है कि किसी डिवाइस ने खाता बनाया है या नहीं, उसने बिना किसी शुल्क के आज़माने की सुविधा को रिडीम किया है या नहीं या उसे गंभीर दुर्व्यवहार के लिए जाना जाता है या नहीं.
• इसके अलावा, वैल्यू की सभी स्थितियों को ज़्यादा से ज़्यादा आठ कस्टम लेबल में भी जोड़ा जा सकता है. उदाहरण के लिए, एक लेबल डिफ़ॉल्ट स्थिति के लिए, जब तीनों वैल्यू में कोई बदलाव नहीं किया गया हो. साथ ही, सात लेबल कस्टम मतलब के साथ. इसकी मदद से, सभी डिवाइसों को आठ ग्रुप में बांटा जा सकता है. यह बंटवारा, आपके तय किए गए व्यवहार या कार्रवाइयों के आधार पर किया जाता है. इस उदाहरण में, सबसे हाल ही में अपडेट किया गया writeDates यह दिखाता है कि आपने लेबल को पिछली बार कब अपडेट किया था.

डिवाइस रीकॉल डेटा के साथ काम करते समय, ज़रूरी शर्तें और अन्य बातों का भी ध्यान रखें.

डिवाइस पर हाल ही में की गई गतिविधि का इस्तेमाल करके, बड़े पैमाने पर हो रहे गलत इस्तेमाल का पता लगाना

Play Integrity API में, डिवाइस से हाल ही में की गई गतिविधि सुविधा का इस्तेमाल करके, ऐसे डिवाइसों का पता लगाएं जो बड़ी संख्या में इंटिग्रिटी टोकन का अनुरोध कर रहे हैं. ज़्यादा गतिविधि करने वाले जालसाज़, आम तौर पर असली डिवाइसों से पुष्टि के मान्य नतीजे जनरेट करते हैं. साथ ही, रूट किए गए डिवाइसों और एम्युलेटर पर अपने-आप हमले करने के लिए, बॉट को ये नतीजे उपलब्ध कराते हैं. हाल ही की डिवाइस गतिविधि के लेवल का इस्तेमाल करके, यह देखा जा सकता है कि आपके ऐप्लिकेशन ने पिछले एक घंटे में उस डिवाइस पर कितने अटेस्टेशन जनरेट किए.

कार्रवाई करने लायक गड़बड़ी के मैसेज दिखाना

जब भी मुमकिन हो, तब उपयोगकर्ताओं को काम के गड़बड़ी के मैसेज भेजें और उन्हें बताएं कि इन्हें ठीक करने के लिए वे क्या कर सकते हैं. जैसे, फिर से कोशिश करना, इंटरनेट कनेक्शन चालू करना या यह देखना कि Play Store ऐप्लिकेशन अप-टू-डेट है.

अचानक आने वाली समस्याओं या आउटेज के लिए प्लान बनाएं

Play के स्टेटस डैशबोर्ड में, Play Integrity API की सेवा के स्टेटस के बारे में जानकारी दिखती है. साथ ही, इसमें सेवा में आने वाली किसी भी रुकावट और सेवाओं के कुछ समय तक उपलब्ध न होने के बारे में जानकारी भी दिखती है. आपको पहले से ही यह तय कर लेना चाहिए कि Play Integrity API के बड़े पैमाने पर काम न करने की स्थिति में, आपका बैकएंड सर्वर किस तरह से काम करेगा. ध्यान दें कि आपका बैकएंड सर्वर भी काम करने के लिए तैयार होना चाहिए. ऐसा तब होता है, जब डिवाइसों के लिए Android प्लैटफ़ॉर्म की खास कुंजी की पुष्टि करने वाली कुंजियों को रद्द कर दिया जाता है.

एंटरप्राइज़ के लिए, धोखाधड़ी रोकने से जुड़े सभी समाधानों का इस्तेमाल करें

जिन एंटरप्राइज़ ग्राहकों को धोखाधड़ी और बॉट मैनेजमेंट का पूरा समाधान चाहिए वे मोबाइल के लिए reCAPTCHA Enterprise खरीद सकते हैं. इसमें Android के लिए SDK शामिल हैं. ये डेवलपर को धोखाधड़ी के जोखिम के स्कोर देते हैं. reCAPTCHA Enterprise में Play Integrity API के सिग्नल अपने-आप शामिल हो जाते हैं. साथ ही, यह उन्हें ग्राहकों के लिए reCAPTCHA नेटवर्क और ऐप्लिकेशन के सिग्नल के साथ जोड़ देता है. इससे, धोखाधड़ी को मैनेज करने का एक ऐसा समाधान मिलता है जो बिना किसी रुकावट के काम करता है और दिखता नहीं है. यह Android ऐप्लिकेशन को भी सुरक्षा दे सकता है. हालांकि, इसके लिए ज़रूरी है कि Play Integrity API उपलब्ध न हो.

ज़्यादा अहम या संवेदनशील सुविधाओं को ऐक्सेस करते समय, जोखिम भरे ट्रैफ़िक को चुनौती दें

अपने ऐप्लिकेशन या गेम में, ऐसी कार्रवाइयों की पहचान करें जो बहुत अहम या संवेदनशील हों. इसके बाद, उन्हें Play Integrity API की मदद से सुरक्षित रखें. इसके बजाय, सीधे तौर पर ऐक्सेस न दें. जब भी मुमकिन हो, ज़्यादा वैल्यू वाले ऐक्शन को आगे बढ़ने की अनुमति देने से पहले, जोखिम भरे ट्रैफ़िक को चुनौती दें. उदाहरण के लिए, जब ऐप्लिकेशन को ऐक्सेस करने से जुड़े जोखिम की सूचना देने वाली सुविधा से पता चलता है कि कोई ऐसा ऐप्लिकेशन चल रहा है जो स्क्रीन कैप्चर कर सकता है, तो उपयोगकर्ता से स्क्रीन कैप्चर करने वाले ऐप्लिकेशन को बंद करने या अनइंस्टॉल करने के लिए कहें. इसके बाद, उसे उस सुविधा को ऐक्सेस करने की अनुमति दें जिसे आपको सुरक्षित रखना है.

सेवा की शर्तें और डेटा की सुरक्षा

Play Integrity API को ऐक्सेस या इस्तेमाल करने का मतलब है कि आपको Play Integrity API की सेवा की शर्तें मंज़ूर हैं. एपीआई को ऐक्सेस करने से पहले, कृपया इस पर लागू होने वाली सभी शर्तों और नीतियों को पढ़कर समझ लें.

Google Play में, डेटा की सुरक्षा वाला सेक्शन होता है. इसमें डेवलपर, अपने ऐप्लिकेशन के डेटा इकट्ठा करने, शेयर करने, और सुरक्षा से जुड़े तरीकों के बारे में जानकारी देते हैं, ताकि उपयोगकर्ताओं को इसके बारे में पता चल सके. डेटा फ़ॉर्म भरने में आपकी मदद करने के लिए, Play Integrity API, डेटा को कैसे मैनेज करता है, इस बारे में यह जानकारी देखें.