हमने google security checkup कैसे किया

उपयोगकर्ता डेटा की सुरक्षा सुनिश्चित करने के लिए, Google उन सभी अनुप्रयोगों की सावधानीपूर्वक जाँच करता है जो प्रतिबंधित API स्कोप का उपयोग करते हैं और Google उपयोगकर्ता डेटा तक पहुँच रखते हैं। बहुत पहले नहीं, हम Snov.io पर सत्यापन प्रक्रिया से गुजरे और Google अनुमोदन प्राप्त किया, जिसके साथ हम साझा करना चाहते हैं।

अनुप्रयोगों के लिए नए नियम


9 अक्टूबर, 2018 को, Google ने उन अनुप्रयोगों के लिए नए नियमों की घोषणा की जो Google प्रतिबंधित API स्कोप का उपयोग करते हैं। वे सत्यापन के 2 चरणों में शामिल थे:

  • सत्यापित करें कि आपका एप्लिकेशन Google API उपयोगकर्ता डेटा नीति का अनुपालन करता है
  • न्यूनतम सुरक्षा आवश्यकताओं की पुष्टि करें

प्रतिबंधित स्कोप ऐप सत्यापन Google API उपयोगकर्ता डेटा नीति और विशिष्ट API स्कोप के लिए अतिरिक्त आवश्यकताओं में उल्लिखित नीतियों का एक अतिरिक्त सेट का अनुपालन सत्यापित करता है। सबसे पहले, Google एपीआई सेवाओं: उपयोगकर्ता डेटा नीति के अनुपालन के लिए आपके आवेदन की समीक्षा की जाएगी। इसके बाद, आपके पास सुरक्षित हैंडलिंग आवश्यकताओं के अनुपालन को प्रदर्शित करने के लिए 2019 का शेष भाग होगा।

न्यूनतम सुरक्षा आवश्यकताओं के अनुपालन के सत्यापन में बहुत अधिक पैसा खर्च होता है - $ 15,000 से $ 75,000 तक।
मूल्यांकन Google द्वारा नामित तीसरे पक्ष के मूल्यांकनकर्ता द्वारा किया जाएगा, आवेदन की जटिलता के आधार पर $ 15,000 और $ 75,000 (या अधिक) के बीच खर्च हो सकता है और डेवलपर द्वारा देय होगा। यह शुल्क आवश्यक हो सकता है कि आपका ऐप मूल्यांकन पास करता है या नहीं

9 जनवरी, 2019 की शुरुआत में , Google ने उन एप्लिकेशन के नियमों को कड़ा कर दिया जो Google API का उपयोग करने की योजना बना रहे हैं। Google API का उपयोग करने वाले अनुप्रयोगों के लिए, 15 फरवरी से पहले सत्यापन के लिए एक आवेदन प्रस्तुत करना था । अन्यथा, आवेदन की पहुंच 22 फरवरी से शुरू होने वाले नए उपयोगकर्ताओं के लिए बंद हो जाएगी , और मौजूदा उपयोगकर्ता 31 मार्च से आवेदन का उपयोग नहीं कर सकते हैं

इस तरह के विकास के परिणाम अप्रिय होंगे। यह इस तथ्य के कारण है कि हमारे उपयोगकर्ताओं की एक महत्वपूर्ण संख्या (और 100 हजार से अधिक हैं) जीमेल का उपयोग करते हैं। इसलिए, हम बस इन ग्राहकों को खो देंगे।

जिन परियोजनाओं के लिए कार्रवाई की आवश्यकता है, आपको 15 फरवरी, 2019 से पहले सत्यापन के लिए ऐप सबमिट करना होगा। यदि आप नहीं करते हैं, तो 22 फरवरी, 2019 को नए उपयोगकर्ताओं की पहुंच अक्षम हो जाएगी, और 31 मार्च को उपभोक्ता खातों के लिए मौजूदा अनुदान रद्द कर दिया जाएगा, 2019।

अपडेट से पहले सब कुछ कैसे हुआ?


हमारा Snov.io प्लेटफ़ॉर्म 2017 से Google API का उपयोग कर रहा है। हमारे आवेदन ने कई प्रतिबंधित स्कोप का उपयोग किया: आने वाले मेल को पढ़ने और ड्राफ्ट के साथ काम करने के लिए। 

Google ने पहले Google API का उपयोग करने वाले एप्लिकेशन का परीक्षण किया है। नए API स्कोप को लागू करने के लिए, इसे कंसोल में जोड़ना और इंगित करना आवश्यक था कि इसका उपयोग किस लिए किया जाएगा। जब Google कर्मचारियों ने एप्लिकेशन की जाँच की, तो उपयोगकर्ताओं ने उनकी स्क्रीन पर "यह ऐप सत्यापित नहीं है" अधिसूचना देखी: 



आमतौर पर इस चेक में हमें 2-3 कार्यदिवस लगते थे (हालाँकि, Google के एक पत्र में यह संकेत दिया गया था कि यह प्रक्रिया 7 दिनों तक चल सकती है) और हमेशा बिना किसी समस्या के बीत जाती है। हमने तब तक इंतजार किया जब तक कि Google ने हमारे आवेदन की जाँच नहीं की और केवल तब ही ठिकानों पर यह फीचर डाला ताकि उपयोगकर्ता "यह ऐप सत्यापित न हो" अधिसूचना नहीं देख पाएंगे। 

पहले चरण का अंश


शुरू करने के लिए, हमने सत्यापन के पहले चरण पर ध्यान देने का निर्णय लिया, अर्थात्, Google API उपयोगकर्ता डेटा नीति के साथ हमारे आवेदन का अनुपालन। 

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

12 फरवरी, हमें प्रस्तुत आवेदन का जवाब मिला। हमें वीडियो रिकॉर्ड करने और यह दिखाने के लिए कहा गया कि हम अनुरोधित प्रतिबंधित एपीआई स्कोप का उपयोग कैसे करते हैं। 

परिणामस्वरूप, हमें Google क्लाउड पर अपनी दो परियोजनाओं को छोड़ना पड़ा और उन्हें एक में मिलाना पड़ा। हमने परीक्षण सर्वर के लिए पहली परियोजना को छोड़ दिया, जो परीक्षण मोड में काम करता था, और परीक्षण के लिए उसी परियोजना का उपयोग करता था जैसे कि ठेस पर। हमने Google के माध्यम से सिस्टम में प्राधिकरण के लिए दूसरी परियोजना को भी हटा दिया और इसके बजाय उस परियोजना का उपयोग किया जिसमें लॉग इन करने के लिए सत्यापन की आवश्यकता थी। 

Google के प्रतिनिधियों ने 2 सप्ताह के बाद हमारे पत्रों का जवाब दिया। प्रश्नों के लिए, सीधे उत्तर के बजाय, हमें उद्धरण प्राप्त हुए। हमें यह प्रतीत हुआ कि उनके पास एक विशेष स्क्रिप्ट है जिसके द्वारा वे अनुप्रयोगों की जांच करते हैं। 

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



20 अप्रैल को, हमने अंत में Google डेटा नीति अनुपालन जांच का पहला चरण पारित किया!

दूसरे चरण का मार्ग 


चरण 1. ऑडिट पास करने के लिए कंपनी चुनना


हमारे आवेदन के परीक्षण के दूसरे चरण तक, Google ने चुनने के लिए दो कंपनियों के संपर्क भेजे - बिशप फॉक्स और लेविथान सिक्योरिटी । केवल उनके साथ चेक पास करना संभव था। 31 दिसंबर तक की समय सीमा दी गई थी

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



कंपनी के प्रतिनिधियों के साथ तैयारी और प्रारंभिक संचार के दौरान, हमने सीखा कि हमारे सर्वर जिस होस्टिंग पर स्थित हैं, वह SOC2 का अनुपालन नहीं करता है । और सफल सत्यापन के लिए हमें उपयुक्त SOC2 होस्टिंग की ओर बढ़ना पड़ा । हम लंबे समय से अमेज़न पर जाने के बारे में सोच रहे हैं , इसलिए हमने समानांतर में आगे बढ़ने की प्रक्रिया शुरू की। 

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

सितंबर में, हमारे पास बिशप फॉक्स और लेविथान सिक्योरिटी से दो तैयार अनुबंध थे। हमें यह तय करना था कि किसके साथ अनुबंध समाप्त किया जाए। हमें नहीं पता था कि विशेषज्ञ के लिए कौन से मापदंड चुनने हैं, लेकिन लेविथान सुरक्षा के साथ समझौता हमारे लिए अधिक पारदर्शी था, इस तथ्य के बावजूद कि इसकी लागत थोड़ी अधिक थी।

चरण 2. अनुबंध पर हस्ताक्षर करना और सत्यापन की तैयारी करना


8 अक्टूबर को, हमने लेविथान सुरक्षा के साथ एक समझौते पर हस्ताक्षर किए। अनुबंध पर हस्ताक्षर करते समय, हमने अभी तक अमेज़ॅन में जाने की प्रक्रिया पूरी नहीं की है। इसलिए, कॉलम "होस्टिंग" में हमारे अनुबंध में एक अंतर था और हमें इसे बाद में दर्ज करना था।

हमने यह भी सीखा कि सत्यापन में क्या शामिल होगा:

  • बाहरी नेटवर्क पेनेट्रेशन टेस्ट 
  • आवेदन पैठ परीक्षण 
  • परिनियोजन समीक्षा 
  • नीति और प्रक्रिया की समीक्षा 

और निम्नलिखित कदम:

  • तैयारी 
  • मूल्यांकन
  • सत्यापन प्रमाणीकरण
  • अंतिम रिपोर्ट

जाँच लगभग एक महीने तक चलती है। इसकी कीमत में मिली कमजोरियों को खत्म करने का समय शामिल है। फिर एक दूसरा चेक किया जाता है। सत्यापन के परिणामस्वरूप, हमें एक लेटर ऑफ असेसमेंट (एलओए) प्राप्त होना चाहिए, जिसे तब Google प्रतिनिधियों को भेजा जाना चाहिए। लेकिन विशेषज्ञ आकलन के 100% परिणाम के रूप में LOA की प्राप्ति की गारंटी नहीं देता है। 

23 अक्टूबर को, लेविथान सुरक्षा ने एक स्व-मूल्यांकन प्रश्नावली (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 नवंबर को, एक बाहरी संरेखण बैठक हुई, जिसमें हमने सभी संगठनात्मक मुद्दों पर चर्चा की, संचार ( स्लैक ) के लिए एक दूत की पहचान की और हमारे आवेदन के बारे में संक्षेप में बात की। हमें चेतावनी दी गई थी कि स्रोत कोड तक पहुंच प्रदान करना आवश्यक होगा - यह हमारे लिए कोई समस्या नहीं थी। 

रैली में, हमें पता चला कि हमें KMS का उपयोग करके Oauth टोकन को एन्क्रिप्ट करने की आवश्यकता है , जो हमने पहले नहीं किया था। हमने अपने चेक के अनुमानित समय पर भी चर्चा की। हमें आश्वासन दिया गया था कि अगर उसे वर्ष के अंत में नियुक्त किया गया था और हमारे पास इसके माध्यम से जाने का समय नहीं था, तो लेविथान सुरक्षा हमारे लिए समय सीमा बढ़ाने के लिए Google के साथ बातचीत करेगी।

14 नवंबरहमें अपने निरीक्षण की योजनाबद्ध शुरुआत के बारे में जानकारी मिली: दिसंबर के अंत या जनवरी की शुरुआत में। और लेविथान सिक्योरिटी ने Google को चेतावनी दी कि हम एलओए को समय सीमा के बाद प्रदान कर सकते हैं। 

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. आंतरिक सुरक्षा टीमों, सीडीएन और होस्टिंग प्रदाताओं को सूचित करें कि सत्यापन 2 जनवरी से 27 जनवरी तक होगा।

8. OneDrive पर एक साझा फ़ोल्डर बनाएँ।

9. Google चेकआउट अक्सर पूछे जाने वाले प्रश्न देखें । 

30 दिसंबरएक किक-ऑफ मीटिंग हुई, जिस पर पहली रैली में लगभग सब कुछ वैसा ही था। हमने खुद को पेश किया, उत्पाद को प्रौद्योगिकियों के एक सेट के साथ वर्णित किया, और पुष्टि की कि हमारी प्रणाली स्थिर है और उत्पाद मूल्यांकन के दौरान कोई बड़ी रिलीज जारी नहीं की जाएगी। यह सवालों और टिप्पणियों के साथ समाप्त हुआ। 

2 जनवरी को, एक सुरक्षा जांच शुरू हुई। ध्यान दें कि यह बहुत कठिनाई के बिना हुआ। कभी-कभी समय क्षेत्रों में अंतर के कारण यह असुविधाजनक था - स्लैक में सभी कॉल और संचार हमारे पास पहले से ही हमारे लिए ऑफ-घंटों के दौरान थे। 

हमने कई कमजोरियां पाई हैं - उच्च और महत्वपूर्ण स्तर (उच्च और महत्वपूर्ण)। ऐसी कमजोरियों को ठीक करने की जरूरत है। मध्य स्तर और नीचे की कमजोरियों को उनके विवेक पर तय किया जा सकता है। सुधार 30 दिनों का दिया गया था। लेकिन हमने उन्हें अगले दिन शाब्दिक रूप से तय किया। 

भेद्यता मुख्य रूप से उपयोगकर्ता डेटा एन्क्रिप्ट करने और अपर्याप्त लॉगिंग के पुराने तरीकों से संबंधित थी। हमारे नीति दस्तावेजों के खिलाफ कोई शिकायत नहीं थी। लेविथान सुरक्षा नीति विभाग ने कुछ स्पष्ट सवाल पूछे और कहा कि वे ठोस दिखे।

संचार की कोई कमी नहीं थी। हम रैलियों की स्थिति में या स्लैक में सभी अस्पष्ट मुद्दों को स्पष्ट कर सकते हैं। भेद्यता रिपोर्ट को अच्छी तरह से प्रलेखित किया गया था और इसमें फिक्सिंग के लिए सिफारिशें भी शामिल थीं। हमारे मूल्यांकन के अंतिम दिन, सभी महत्वपूर्ण, उच्च, साथ ही कुछ मध्यम और कम कमजोरियों को ठीक किया गया और जाँच की गई। 

31 जनवरी, हमने LOA प्राप्त किया और इसे Google प्रतिनिधियों को भेजा।  

11 फरवरी को Google से सत्यापन की पुष्टि हुई।



हमारे लिए सबसे कठिन बात अज्ञात थी। क्या उम्मीद? कैसे होगा सब कुछ? हम पायनियर की तरह महसूस करते थे। कहीं भी इस बारे में कोई जानकारी नहीं थी कि अन्य कंपनियों ने इस परीक्षा को कैसे पास किया, जिसने हमें सुरक्षा जांच के बारे में अन्य लोगों के साथ जानकारी साझा करने के लिए प्रेरित किया।

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

ऐसी कंपनियां हैं, जैसे कि Context.io, जिन्होंने ऑडिट पास नहीं करने और बंद करने का फैसला किया है। ऐसे लोग हैं जो एपीआई तक पहुंच के बिना काम करना जारी रखते हैं, लेकिन एक ही समय में उपयोगकर्ताओं की आंखों में अपनी प्रतिष्ठा खो देते हैं। प्रत्येक व्यवसाय को परीक्षण करने की आवश्यकता है, ज़ाहिर है, स्वतंत्र रूप से पेशेवरों और विपक्षों को तौलना होगा। सबसे मुश्किल काम बहुत युवा कंपनियों के लिए होगा जिनके पास अभी तक लाभ नहीं है। लेकिन अगर व्यवसाय में परीक्षण पास करने के लिए संसाधन हैं, तो यह निश्चित रूप से करने योग्य है।

हमें उम्मीद है कि हमारा अनुभव आपको इसमें मदद करेगा!

All Articles