🦈 👴🏽 🧟 كيف قمنا بفحص جوجل للأمن 🧘🏼 🛀🏼 🔼

لضمان أمان بيانات المستخدم ، تتحقق Google بعناية من جميع التطبيقات التي تستخدم نطاقات API المقيدة ولديها إمكانية الوصول إلى بيانات مستخدم Google. منذ وقت ليس ببعيد ، مررنا في Snov.io عملية التحقق وحصلنا على موافقة Google ، والتي نريد مشاركتها.

قواعد جديدة للتطبيقات

في 9 أكتوبر 2018 ، أعلنت Google عن قواعد جديدة للتطبيقات التي تستخدم نطاقات API المقيدة من Google. شملت مرحلتين للتحقق:

تحقق من أن تطبيقك يتوافق مع سياسة بيانات مستخدم Google API
تحقق من الحد الأدنى من متطلبات الأمان

يتحقق التحقق من تطبيق النطاق المقيد من الامتثال لسياسة بيانات المستخدم في Google API ومجموعة إضافية من السياسات الموضحة في المتطلبات الإضافية لنطاقات واجهة برمجة التطبيقات المحددة. أولاً ، ستتم مراجعة تطبيقك للتأكد من امتثاله لخدمات Google API: سياسة بيانات المستخدم. بعد ذلك ، سيكون لديك ما تبقى من عام 2019 لإثبات الامتثال لمتطلبات المناولة الآمنة.

يكلف التحقق من الامتثال لمتطلبات الأمان الدنيا الكثير من المال - من 15000 دولار إلى 75000 دولار.

سيتم إجراء التقييمات بواسطة مُقيِّم من جهة خارجية مُعيّن من قِبل Google ، وقد تتكلف ما بين 15000 دولار أمريكي و 75000 دولار أمريكي (أو أكثر) اعتمادًا على مدى تعقيد التطبيق ، وسيتحمل المطور الدفع. قد تكون هذه الرسوم مطلوبة سواء اجتاز تطبيقك التقييم أم لا .

في وقت مبكر من 9 يناير 2019 ، شددت Google قواعد التطبيقات التي تخطط لاستخدام Google API. بالنسبة إلى التطبيقات التي استخدمت واجهة برمجة تطبيقات Google في وقت سابق ، كان هناك متطلب لإرسال طلب للتحقق قبل 15 فبراير . خلاف ذلك ، سيتم إغلاق الوصول إلى التطبيق للمستخدمين الجدد بدءًا من 22 فبراير ، ولا يمكن للمستخدمين الحاليين استخدام التطبيق من 31 مارس .

إن عواقب مثل هذا التطور ستكون غير سارة. ويرجع ذلك إلى حقيقة أن عددًا كبيرًا من مستخدمينا (وهناك أكثر من 100 ألف) يستخدمون Gmail. لذلك ، سوف نفقد هؤلاء العملاء ببساطة.

بالنسبة للمشاريع التي تتطلب إجراءً ، يجب عليك إرسال تطبيقات للتحقق قبل 15 فبراير 2019. إذا لم تفعل ذلك ، فسيتم تعطيل الوصول للمستخدمين الجدد في 22 فبراير 2019 ، وسيتم إبطال المنح الحالية لحسابات المستهلكين في 31 مارس ، 2019.

كيف حدث كل شيء قبل التحديثات؟

تستخدم منصة Snov.io الخاصة بنا واجهة برمجة تطبيقات Google منذ عام 2017. استخدم تطبيقنا العديد من النطاقات المقيدة: لقراءة البريد الوارد والعمل مع المسودات.

اختبرت Google سابقًا التطبيقات التي تستخدم Google API. لتطبيق نطاق API الجديد ، كان من الضروري إضافته إلى وحدة التحكم والإشارة إلى ما سيتم استخدامه. أثناء فحص موظفي Google للتطبيق ، شاهد المستخدمون الإشعار "لم يتم التحقق من هذا التطبيق" على شاشاتهم:

عادةً ما يستغرق منا هذا الفحص من يومين إلى 3 أيام عمل (على الرغم من الإشارة في رسالة من Google إلى أن العملية يمكن أن تستمر حتى 7 أيام) وتمريرها دائمًا دون مشاكل. لقد انتظرنا حتى قامت Google بفحص تطبيقنا ، وبعد ذلك فقط قمنا بسكب الميزة على المنتج حتى لا يرى المستخدمون الإشعار "لم يتم التحقق من هذا التطبيق".

مرور المرحلة الأولى

بادئ ذي بدء ، قررنا التركيز على المرحلة الأولى من التحقق ، وهي امتثال تطبيقنا لسياسة بيانات مستخدم Google API.

في 16 يناير ، ظهر زر إرسال للتحقق في وحدة تحكم Google وأرسلنا طلبًا. قبل المغادرة ، تأكدنا من التزامنا بجميع النقاط في سياسة بيانات مستخدم Google API. أضفنا تغييرات على سياسة الخصوصية ، على وجه الخصوص ، أضفنا قسم بيانات مستخدم Google ، الذي وصف بالتفصيل البيانات التي تم تلقيها من Google API التي نخزنها ، وكيف نستخدمها ومتى نحذفها. تلقينا في

12 فبراير ردًا على الطلب المقدم. طُلب منا تسجيل مقاطع الفيديو وإظهار كيفية استخدام نطاقات API المقيدة المطلوبة.

ونتيجة لذلك ، كان علينا التخلي عن مشروعينا على Google Cloud ودمجهما في واحد. لقد تخلينا عن المشروع الأول لخادم الاختبار ، الذي عمل في وضع الاختبار ، واستخدمنا نفس المشروع للاختبار كما هو الحال في المنتج. حذفنا أيضًا المشروع الثاني للتفويض في النظام من خلال Google وبدلاً من ذلك استخدمنا المشروع الذي يتطلب التحقق لتسجيل الدخول.

رد ممثلو Google على رسائلنا في مكان ما بعد أسبوعين. بالنسبة للأسئلة ، بدلاً من الإجابات المباشرة ، تلقينا اقتباسات. يبدو لنا أن لديهم نصًا خاصًا يتحققون من خلاله التطبيقات.

على سبيل المثال ، تم تذكيرنا بأننا نستخدم تطبيقًا برقم تعريف واحد للدخول إلى النظام ، وعند ربط حساب بريد إلكتروني ، تطبيق برقم تعريف مختلف. قمنا بذلك عن قصد ، لأن هاتين وظيفتان مختلفتان تمامًا. لا يتطلب تطبيق تسجيل الدخول أي عمليات تحقق ولا نريد الفشل في اجتياز التحقق من التطبيق بنطاقات API المقيدة لتعطيل تطبيق التحقق.

في 20 أبريل ، نجحنا أخيرًا في المرحلة الأولى من التحقق من الامتثال لسياسة بيانات Google!

مرور المرحلة الثانية

الخطوة 1. اختيار شركة لتمرير المراجعة

في المرحلة الثانية من اختبار تطبيقنا ، أرسلت Google جهات اتصال لشركتين للاختيار من بينها - Bishop Fox و Leviathan Security . كان من الممكن تمرير الشيك معهم فقط. تم تحديد الموعد النهائي حتى 31 ديسمبر .

في 20 مايو ، أرسلنا رسائل إلى خبيرين مستقلين لتمرير المراجعة. أرسل الأسقف فوكس و Leviathan Security استبيانات مع أسئلة حول طلبنا. كان من الضروري الإجابة عن نوع بيانات Google التي نستخدمها ، وعدد أسطر التعليمات البرمجية المكتوبة لكل لغة برمجة ، بالإضافة إلى الأسئلة حول بنيتنا التحتية ، وعملية نشر البرنامج وموفر الاستضافة. ملأنا كل شيء وبدأنا في انتظار عرض السعر.

أثناء التحضير والتواصل الأولي مع ممثلي الشركة ، علمنا أن الاستضافة التي تقع عليها خوادمنا لا تتوافق مع SOC2 . وللتحقق الناجح ، كان علينا الانتقال إلى استضافة SOC2 المناسبة . لقد كنا نفكر منذ فترة طويلة في الانتقال إلى أمازون ، لذلك بدأنا عملية الانتقال بالتوازي.

علمنا أيضًا أننا بحاجة إلى برنامج Bug Bounty الذي يقدمه العديد من مواقع الويب ومطوري البرامج. مع ذلك ، يمكن للأشخاص الحصول على الاعتراف والمكافأة للعثور على الأخطاء ، وخاصة تلك المتعلقة بالاستغلال ونقاط الضعف.

في سبتمبر ، كان لدينا عقدين جاهزين من المطران فوكس وليفياثان سيكيوريتي. كان علينا أن نقرر مع من نبرم العقد. لم نكن نعرف المعايير التي يجب أن نختار خبيرًا لها ، لكن الاتفاقية مع شركة Leviathan Security بدت أكثر شفافية بالنسبة لنا ، على الرغم من أنها تكلف أكثر قليلاً.

الخطوة 2. توقيع العقد والتحضير للتحقق

في 8 أكتوبر ، وقعنا اتفاقية مع Leviathan Security. في وقت توقيع العقد ، لم ننتهي بعد من عملية الانتقال إلى أمازون. لذلك ، في عقدنا في عمود "الاستضافة" كانت هناك فجوة واضطررنا إلى إدخالها لاحقًا.

تعلمنا أيضًا ما الذي سيشمل التحقق:

اختبار اختراق الشبكة الخارجية
اختبار اختراق التطبيق
مراجعة النشر
مراجعة السياسات والإجراءات

والخطوات التالية:

تجهيز
تقدير
التحقق من صحة التحقق
التقرير الأخير

يستمر الفحص حوالي شهر. يشمل سعره الوقت للقضاء على نقاط الضعف الموجودة. ثم يتم إجراء فحص ثان. نتيجة لعملية التحقق ، كان يجب أن نتلقى خطاب تقييم (LOA) ، والذي يجب إرساله بعد ذلك إلى ممثلي Google. لكن الخبير لا يضمن استلام خطاب الاعتماد كنتيجة 100٪ للتقييم.

في 23 أكتوبر ، أرسلت شركة Leviathan Security استبيانًا للتقييم الذاتي (SAQ). بالتعاون معها ، قدمنا أيضًا سياساتنا اللازمة لاجتياز المراجعة:

خطة الاستجابة للحوادث: تحدد الأدوار والمسؤوليات والإجراءات عند وقوع الحادث
سياسة إدارة المخاطر: تحدد وتقليل وتمنع الحوادث أو النتائج غير المرغوب فيها
سياسة الكشف عن نقاط الضعف: توفر وسيلة للأطراف الخارجية للإبلاغ عن نقاط الضعف
Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
Privacy Policy: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant

في 8 نوفمبر ، عقد اجتماع محاذاة خارجي ، ناقشنا فيه جميع القضايا التنظيمية ، وحدد رسولًا للاتصال ( سلاك ) وتحدثنا لفترة وجيزة عن طلبنا. تم تحذيرنا من أنه سيكون من الضروري توفير الوصول إلى شفرة المصدر - لم تكن هذه مشكلة بالنسبة لنا.

في المسيرة ، علمنا أننا بحاجة إلى تشفير رموز Oauth المميزة باستخدام KMS ، وهو ما لم نفعله من قبل. ناقشنا أيضًا الوقت التقريبي للشيك. لقد تم التأكيد لنا على أنه إذا تم تعيينها في نهاية العام ولم يكن لدينا الوقت اللازم لذلك ، فسوف تتفاوض شركة Leviathan Security مع Google لتمديد الموعد النهائي بالنسبة لنا.

14 نوفمبرتلقينا معلومات حول البدء المخطط لتفتيشنا: أواخر ديسمبر أو أوائل يناير. وحذر Leviathan Security Google من أنه يمكننا تقديم LOA في وقت لاحق عن الموعد النهائي.

في 16 نوفمبر ، تلقينا تأكيدًا من Google بأنه تم تأجيل الموعد النهائي حتى 31 مارس.

الخطوة 3. التحقق

في 13 ديسمبر ، تلقينا رسالة تم إعلامنا فيها ببدء المراجعة - في 2 يناير ، وطلبنا استيفاء المتطلبات التالية:

1. تأكد من إمكانية المراجعة.

2. تقديم المعلومات اللازمة مرة أخرى.

يجب تحميل المستندات إلى المجلد المشترك على OneDrive قبل أسبوع من الفحص - حتى 26 ديسمبر . لم نقدم أي مستندات إضافية باستثناء المستندات المطلوبة:

خطة الاستجابة للحوادث
سياسة إدارة المخاطر
Vulnerability Disclosure Policy
Information Security Policy
Privacy Policy
Supporting Privacy Documentation
Terms and Conditions
Self Assessment Questionnaire (SAQ)
API
URL-
IP

3. توفير الوصول إلى التعليمات البرمجية المصدر.

4. دعوة أشخاص معينين إلى سلاك رسول.

5. اذكر رقم الهاتف وتفاصيل التصعيد للمشروع.

6. قدم معلومات عن كيفية تحرير الفواتير.

7. قم بإبلاغ فرق الأمن الداخلي وشبكة CDN ومقدمي خدمات الاستضافة بأن التحقق سيتم في الفترة من 2 يناير إلى 27 يناير.

8. قم بإنشاء مجلد مشترك على OneDrive.

9. تحقق من Google Checkout الأسئلة الشائعة .

30 ديسمبرعقد اجتماع انطلاق ، حيث كان كل شيء تقريبًا كما كان في التجمع الأول. قدمنا أنفسنا ، ووصفنا المنتج بمجموعة من التقنيات ، وأكدنا أن نظامنا مستقر وأنه لن يتم إصدار أي إصدارات رئيسية أثناء تقييم المنتج. انتهى بأسئلة وتعليقات.

في 2 يناير ، بدأ فحص أمني. لاحظ أنه حدث دون صعوبة كبيرة. في بعض الأحيان كان الأمر غير مريح بسبب الاختلاف في المناطق الزمنية - جميع المكالمات والاتصالات في Slack التي أجريناها بالفعل خارج ساعات العمل بالنسبة لنا.

لقد وجدنا العديد من نقاط الضعف - المستوى العالي والحرج (مرتفع وحرج). ويلزم إصلاح نقاط الضعف هذه. يمكن تصحيح نقاط الضعف في المستوى المتوسط وما دون ذلك حسب تقدير المرء. تم منح التصحيح 30 يومًا. لكننا أصلحناها حرفياً في اليوم التالي.

كانت نقاط الضعف مرتبطة بشكل أساسي بالأساليب القديمة لتشفير بيانات المستخدم وعدم كفاية التسجيل. لم تكن هناك شكاوى ضد وثائق سياستنا. طرحت إدارة السياسة الأمنية في ليفياثان بعض الأسئلة التوضيحية وقالت إنها تبدو قوية.

لم يكن هناك نقص في الاتصال. يمكننا توضيح جميع القضايا الغامضة في حالة التجمعات أو في Slack. تم توثيق تقارير الضعف بشكل جيد وتضمنت أيضًا توصيات لإصلاحها. في اليوم الأخير من تقييمنا ، تم إصلاح جميع نقاط الضعف الحرجة والعالية وكذلك بعض الثغرات المتوسطة والمنخفضة والتحقق منها.

في 31 يناير ، تلقينا LOA وأرسلناه إلى ممثلي Google. تلقى

11 فبراير تأكيد التحقق من جوجل.

أصعب شيء بالنسبة لنا كان المجهول. ماذا تتوقع؟ كيف سيحدث كل شيء؟ شعرنا بأننا رواد. لم يكن هناك أي معلومات حول كيفية اجتياز الشركات الأخرى لهذا الاختبار ، مما دفعنا إلى مشاركة المعلومات حول فحص الأمان مع الآخرين.

نريد أن نقول لمن لم يأت بعد مثل هذا الشيك ، إنه ليس مخيفًا كما قد يبدو. نعم ، تستغرق العملية وقتًا طويلاً ، ولكن سيكون هناك هامش جيد من الوقت لإصلاح جميع الثغرات الأمنية. على الرغم من حقيقة أن الأمر استغرقنا عامًا لإجراء فحص أمان Google ، إلا أن هذه المرة لم تضيع. يمكننا الاستمرار في استخدام Google API ، وهو أمر حيوي بالنسبة لنا ، وكذلك إغلاق الثغرات الأمنية التي قد تظهر لاحقًا جانبية لنا أو لعملائنا.

هناك شركات ، مثل Context.io ، قررت عدم اجتياز المراجعة وأغلقت. هناك أولئك الذين يواصلون العمل دون الوصول إلى واجهة برمجة التطبيقات ، ولكن في نفس الوقت يفقدون سمعتهم في أعين المستخدمين. بالطبع ، يجب على كل شركة تحتاج إلى اختبارها أن تزن إيجابيات وسلبيات بشكل مستقل. سيكون الأمر الأصعب بالنسبة للشركات الصغيرة جدًا التي لا تحقق ربحًا بعد. ولكن إذا كان لدى الشركة الموارد اللازمة لاجتياز الاختبار ، فمن الجدير بالتأكيد القيام به.

نأمل أن تساعدك تجربتنا في ذلك!

كيف قمنا بفحص جوجل للأمن