تساعدك واجهة برمجة التطبيقات Play Integrity API في التحقّق من أنّ التفاعلات وطلبات الخادم تتم. يتم تشغيله من خلال البرنامج الثنائي الحقيقي لتطبيقك على جهاز Android حقيقي. من اكتشاف عمليات التفاعل الاحتيالية والخطيرة التي يُحتمل أن تكون خطيرة، مثل التلاعب إصدارات التطبيق والبيئات غير الموثوقة، يمكن لخادم الخلفية في تطبيقك من خلال اتخاذ الإجراءات المناسبة لمنع الهجمات والحدّ من إساءة الاستخدام.
عند استخدام تطبيقك أو لعبتك على جهاز Android من خلال "متجر Google Play" بفضل "خدمات Google Play"، توفّر واجهة برمجة التطبيقات Play Integrity API تساعدك في تحديد ما إذا كنت تتفاعل مع ما يلي:
- برنامج الثنائي الحقيقي للتطبيق: يمكنك تحديد ما إذا كنت تتفاعل مع برنامج ثنائي غير معدَّل يتعرّف عليه Google Play.
- التثبيت الحقيقي من Play: يمكنك تحديد ما إذا كان حساب المستخدم الحالي الترخيص، ما يعني أنّ المستخدِم ثبَّت تطبيقك أو لعبتك أو دفع رسومهما على Google Play.
- جهاز Android حقيقي: يمكنك تحديد ما إذا كان تطبيقك يعمل على جهاز Android حقيقي متوافق مع خدمات Google Play (أو مثال على "ألعاب Google Play على الكمبيوتر").
يمكنك أيضًا اختيار تلقّي معلومات عن البيئة. في ردّك على واجهة برمجة التطبيقات Play Integrity API، بما في ذلك:
- مخاطر الوصول إلى التطبيقات: يتم تحديد ما إذا كانت التطبيقات قيد التشغيل أم لا تُستخدم لالتقاط الشاشة أو عرض العناصر المركّبة أو التحكم في الجهاز.
- خطر البرامج الضارة المعروفة: يمكنك تحديد ما إذا تم تفعيل خدمة "Google Play للحماية" أو لا. عليه وما إذا كان قد وجد تطبيقات خطيرة أو خطيرة تم تثبيتها على الجهاز.
نظرة عامة
عندما ينفِّذ المستخدِم إجراءً في تطبيقك، يمكنك طلب واجهة برمجة التطبيقات Play Integrity API. للتحقق من حدوث ذلك في البرنامج الثنائي الحقيقي لتطبيقك، والذي تم تثبيته عن طريق Google Play، يعمل على جهاز Android حقيقي. يمكنك أيضًا الاشتراك في المعلومات الواردة في الردّ، بما في ذلك حجم الطلبات التي أجراها الجهاز مؤخرًا وإشارات حول البيئة، بما في ذلك مخاطر الوصول إلى التطبيق القرار وبيان "Play للحماية". إذا كانت هناك أي مشكلة في القرارات، يمكن لخادم الخلفية في تطبيقك أن يقرّر ما يجب فعله لحماية تطبيقك من المشاكل مثل إساءة الاستخدام والاحتيال، وإساءة الاستخدام والغش، والوصول غير المصرّح به، والهجمات.
اعتبارات الأمان
توفّر واجهة برمجة التطبيقات Play Integrity API أكبر قيمة لتطبيقك عند اتّباع هذه الممارسات المقترَحة:
وضع استراتيجية لمكافحة إساءة الاستخدام
تعمل واجهة برمجة التطبيقات Play Integrity API على أفضل نحو عند استخدامها مع إشارات أخرى كجزء من استراتيجية مكافحة إساءة الاستخدام بشكل عام، وليس كآلية وحيدة لمكافحة إساءة الاستخدام. استخدام واجهة برمجة التطبيقات هذه مع حلول لأفضل ممارسات الأمان الممارسات لتطبيقك. يطبق تطبيقك بشكل تلقائي يمكن أن يصل إجمالي عدد الطلبات إلى 10000 طلب في اليوم على مستوى جميع عمليات التثبيت. يمكنك تطلب زيادة نقاطك الحد الأقصى.
جمع بيانات القياس عن بُعد وفهم جمهورك قبل اتّخاذ أي إجراء
قبل تغيير سلوك تطبيقك استنادًا إلى بيانات واجهة برمجة التطبيقات Play Integrity API، يمكنك إجراء ما يلي: الوضع الحالي مع جمهورك الحالي من خلال تنفيذ واجهة برمجة التطبيقات بدون فرض إجراءات. بعد معرفة البيانات التي تحدّد عدد الأجهزة النشطة التي تم تثبيت التطبيق عليها يعود هذا الإجراء، فيمكنك تقدير تأثير أي إجراء تنفيذ تخطط له عدِّل استراتيجية مكافحة إساءة الاستخدام وفقًا لذلك.
تحديد كيفية طلب بيانات السلامة
توفّر واجهة برمجة التطبيقات Play Integrity API خيارَين لطلب التحقّق من السلامة والحصول على المعلومات اللازمة. البيانات. تقديم طلبات عادية أو طلبات كلاسيكية أو مزيج منهما في كلا النوعين من الطلبات، فسيتم عرض استجابة بيان السلامة في نفس التنسيق.
الطلبات العادية من واجهة برمجة التطبيقات هي مناسبة لأي تطبيق أو لعبة ويمكن إجراؤها على التحقق من أن أي إجراء للمستخدم أو طلب خادم حقيقي. عادي تتسم الطلبات بأقل وقت استجابة (بضعة مئات من المللي ثانية في المتوسط) والموثوقية العالية للحصول على بيان قابل للاستخدام. تستفيد الطلبات القياسية من التخزين المؤقت الذكي على الجهاز فقط مع تفويض الحماية من أنواع معينة من هجوم على Google Play.
والطلبات الكلاسيكية للبيانات من واجهة برمجة التطبيقات، وهي الطريقة الأصلية لطلب بيانات السلامة، ستظل متاحة. يكون وقت استجابة الطلبات الكلاسيكية أطول (بضع ثوانٍ على المتوسط) وتكون مسئولاً عن التخفيف من مخاطر أنواع معينة من الهجمات. تستخدم الطلبات الكلاسيكية قدرًا أكبر من بيانات المستخدم والبطارية أكثر من مقدار استخدام عادي الطلبات لأنها تبدأ تقييمًا جديدًا ولذلك يجب تقديمها نادرًا كمرة واحدة للتحقق مما إذا كان الإجراء حساسًا أو ذا قيمة حقيقية. إذا كنت تفكر في تقديم طلب كلاسيكي وتخزينه مؤقتًا لاستخدامها لاحقًا، فيجب عليك تقديم طلب قياسي بدلاً من ذلك لتقليل خطر الهجمات.
يوضح الجدول التالي بعض الاختلافات الرئيسية بين نوعي الطلبات:
| طلب البيانات من واجهة برمجة التطبيقات العادية | طلب البيانات من واجهة برمجة التطبيقات الكلاسيكية | |
|---|---|---|
| مطلوب إصدار حزمة تطوير البرامج (SDK) لنظام التشغيل Android بالحدّ الأدنى | Android 5.0 (مستوى واجهة برمجة التطبيقات 21) أو إصدار أحدث | الإصدار 4.4 من نظام التشغيل Android (المستوى 19 من واجهة برمجة التطبيقات) أو الإصدارات الأحدث |
| يجب تحضير واجهة برمجة التطبيقات | ✔️ (بضع ثوانٍ) | ❌ |
| وقت الاستجابة المعتاد للطلبات | بضع مئات من المللي ثانية | بضع ثوانٍ |
| معدّل تكرار الطلب المحتمَل | متكرر (فحص عند الطلب لأي إجراء أو طلب) | غير متكرّر (عملية فحص لمرة واحدة للإجراءات ذات القيمة الأعلى أو الطلبات الأكثر حساسية) |
| الحد من عمليات إعادة التشغيل والهجمات المماثلة | إجراءات التخفيف التلقائية من خلال Google Play | استخدام الحقل nonce مع منطق جهة الخادم |
يمكنك الاطّلاع على جدول يحتوي على المزيد من الاختلافات في اعتبارات الطلب الكلاسيكي.
طلب بيان السلامة في الوقت المناسب
يجب طلب بيان خطورة الوصول إلى التطبيق في أقرب وقت ممكن من الوقت. الإجراء أو طلب الخادم الذي تريد الدفاع عنه ضد الوصول إليه، لمنع المخادعين من العمل على إكمال عملية التحقّق من السلامة التي يجريها التطبيق.
صعوبة تكرار طلبات البيانات من واجهة برمجة التطبيقات
تتضمّن الطلبات العادية للبيانات من واجهة برمجة التطبيقات حقلاً يُسمى requestHash يُستخدم لحماية
ضد التلاعب والهجمات المماثلة. في هذا الحقل، يجب عليك تضمين
ملخص بجميع القيم ذات الصلة من طلب تطبيقك. اتّبِع الإرشادات الواردة على
كيفية استخدام ربط المحتوى
لحماية الطلبات العادية لتطبيقك.
تتضمّن الطلبات الكلاسيكية للبيانات من واجهة برمجة التطبيقات حقلاً يُسمى nonce (اختصارًا للرقم مرة واحدة)،
تستخدم للحماية ضد أنواع معينة من الهجمات، مثل إعادة التشغيل
هجمات التلاعب. اتبع الإرشادات حول كيفية إنشاء
Nons (رقم التعريف) لحماية الإصدار الكلاسيكي من تطبيقك
الطلبات.
تجنُّب بيانات سلامة التخزين المؤقت
بيانات السلامة في التخزين المؤقت تزيد من خطر إنشاء خادم وكيل وهو هجوم عندما يُعيد جهة مسيئة استخدام قرار من جهاز جيد لأغراض مسيئة في بيئة أخرى. بدلاً من التخزين المؤقت للردود، يمكنك إنشاء واجهة برمجة تطبيقات عادية لطلب الحصول على قرار عند الطلب.
وضع استراتيجية تنفيذ ذات مستويات متعددة
يتضمّن بيان السلامة لواجهة برمجة التطبيقات Play Integrity API مجموعة من الردود المحتمَلة. إنشاء استراتيجية لمكافحة إساءة الاستخدام تتضمّن مستويات التنفيذ. ويمكنك إجراء ذلك من خلال ضبط خادم الخلفية في تطبيقك لكي يعمل. بشكل مختلف اعتمادًا على كل إجابة محتملة أو مجموعة ردود.
من الممكن أيضًا تقسيم استراتيجية التنفيذ استنادًا إلى الجهاز
وموثوقية من خلال تفعيل خيار تلقّي أجهزة إضافية
التصنيفات في واجهة برمجة التطبيقات
استجابة من Play Console. سيعرض كل جهاز جميع التصنيفات التي
المعايير التي تلبيها. على سبيل المثال، بعد الموافقة على استلام جميع الأجهزة
التصنيفات، فيمكنك اختيار الوثوق بجهاز يعود
MEETS_STRONG_INTEGRITY وMEETS_DEVICE_INTEGRITY وMEETS_BASIC_INTEGRITY
أكبر من سعر الجهاز الذي لا يعرض سوى MEETS_BASIC_INTEGRITY. يمكنك الردّ
بشكل مختلف عن الخادم في كل سيناريو.
إرسال مجموعة من الردود من الخادم إلى تطبيقك
يكون تكرار الحصول على مجموعة من نتائج القرار أصعب من إرسال برنامج ثنائي السماح/رفض الاستجابة من الخادم إلى التطبيق لكل استجابة. بالنسبة يمكنك استخدام سلسلة من الردود ذات الصلة مثل "Allow" و"Allow" (السماح) مع الحدود، والسماح بحدود بعد إكمال اختبار CAPTCHA، والرفض.
رصد إساءة الاستخدام على نطاق واسع باستخدام آخر نشاط على الجهاز
يمكنك استخدام ميزة النشاط الأخير على الجهاز في واجهة برمجة التطبيقات Play Integrity API للعثور على الأجهزة التي تطلب أعدادًا كبيرة من رموز السلامة المميّزة. نشاط مرتفع عادةً ما ينتج عن الأشخاص المسيئين نتائج مصادقة صالحة من أجهزة حقيقية تزويدها ببرامج الروبوت لبرمجة الهجمات على الأجهزة الجذر وأجهزة المحاكاة. يمكنك استخدام مستوى النشاط الأخير على الجهاز لمعرفة تم إنشاء إقرارات من خلال تطبيقك على ذلك الجهاز في الساعة الماضية.
عرض رسائل خطأ قابلة للتنفيذ
عند الإمكان، قدِّم رسائل خطأ مفيدة للمستخدمين وأخبِرهم بما يحدث. التي يمكنهم فعلها لإصلاحها؛ مثل إعادة المحاولة، أو تمكين الاتصال بالإنترنت، أو التأكد من أنّ تطبيق "متجر Play" محدَّث.
وضع خطة لمعالجة المشاكل أو الانقطاعات غير المتوقعة
تعرض لوحة البيانات الخاصة بحالة Play معلومات حول حالة الخدمة لواجهة برمجة التطبيقات Play Integrity API معلومات حول أي اضطرابات وانقطاع. يجب أن تخطط مسبقًا لكيفية إذا كنت تريد أن يعمل خادم الخلفية في حالة حدوث نزاع واسع النطاق انقطاع الخدمة في واجهة برمجة التطبيقات Play Integrity API
تجربة حلول شاملة للاحتيال على مستوى المؤسسات
عملاء من المؤسسات يبحثون عن حلّ كامل لإدارة عمليات الاحتيال وبرامج التتبُّع يمكنك شراء reCAPTCHA Enterprise للأجهزة الجوّالة يتضمن حِزم تطوير البرامج (SDK) الخاصة نظام التشغيل Android التي توفّر للمطورين نتائج حول مخاطر الاحتيال. reCAPTCHA Enterprise تلقائيًا يتضمَّن إشارات واجهة برمجة التطبيقات Play Integrity API ودمجها مع شبكة reCAPTCHA. إشارات وتطبيقات للعملاء، ما يؤدي إلى حدوث احتيال سلس وغير مرئي حل إدارة المشروعات بطريقة مبتكرة. ويمكنها أيضًا توفير الحماية لأجهزة Android التطبيقات التي لا تتوفّر فيها واجهة برمجة التطبيقات Play Integrity API
تحدّي الزيارات الخطيرة عند استخدام ميزات حساسة أو عالية القيمة
حدِّد الإجراءات الحسّاسة أو المهمة في تطبيقك أو لعبتك لحمايتها باستخدام Play Integrity API بدلاً من رفض طلب الوصول بشكل مباشر. عند الإمكان، تحدي حركة المرور المحفوفة بالمخاطر قبل السماح بمتابعة الإجراءات عالية القيمة. على سبيل المثال، عندما يشير خطر الوصول إلى التطبيق إلى أن هناك تطبيقًا قيد التشغيل يمكن أن يحصل على أن تطلب من المستخدم إيقاف أو إلغاء تثبيت التطبيقات التي يمكنها تصوير الشاشة قبل السماح لهم بالمتابعة إلى الوظائف التي تريد حمايتها.
بنود الخدمة وأمان البيانات
إذا وصلت إلى واجهة برمجة التطبيقات Play Integrity API أو استخدمتها يعني هذا أنّك توافق على Play Integrity. بنود خدمة واجهة برمجة التطبيقات: يُرجى القراءة والفهم. كل البنود والسياسات السارية قبل الدخول إلى واجهة برمجة التطبيقات.
يتضمّن Google Play قسم "أمان البيانات" ليتمكّن المطوّرون من الإفصاح عن تطبيقاتهم ممارسات جمع البيانات ومشاركتها والحفاظ على أمانها لإبقاء المستخدمين على اطّلاع إلى على إكمال نموذج البيانات، فراجع هذه المعلومات حول كيفية تنفيذ تعالج واجهة برمجة التطبيقات Integrity API البيانات.