इस गाइड में, Android Compatibility Test Suite (CTS) से जांच किए गए सुरक्षा पैच को लागू करने के लिए, Google के सुझाए गए सबसे सही तरीकों के बारे में बताया गया है. यह Android के साथ काम करने वाले ओईएम के ऐसे प्रॉडक्ट (मैन्युफ़ैक्चरर) के लिए है जिन्हें तीन साल से ज़्यादा समय तक अपडेट मिलते रहेंगे. जैसे, वाहन, टीवी, सेट-टॉप बॉक्स, और घरेलू उपकरण. यह गाइड, असली उपयोगकर्ताओं (जैसे कि वाहन मालिकों) के लिए नहीं है.
स्वीकारोक्ति और डिसक्लेमर
इस गाइड में दी गई जानकारी, कानूनी या अनुबंध के तौर पर Google या अन्य मैन्युफ़ैक्चरर के लिए बाध्यकारी नहीं है. साथ ही, इसे ज़रूरी शर्तों के तौर पर नहीं बनाया गया है. इसके बजाय, यह गाइड एक निर्देशिका है, जिसमें सुझाए गए तरीकों के बारे में बताया गया है.
सुझाव/राय दें या शिकायत करें
इस गाइड में पूरी जानकारी नहीं दी गई है. इसमें और भी बदलाव किए जाने हैं. सुझाव/राय दें या शिकायत करें इसके लिए, manufacturers-guide-android@googlegroups.com पर ईमेल भेजें.
शब्दावली
| शब्द | परिभाषा |
|---|---|
| ACC | Android Compatibility Commitment. पहले इसे Android Anti-Fragmentation Agreement (AFA) के नाम से जाना जाता था. |
| AOSP | Android ओपन सोर्स प्रोजेक्ट |
| एएसबी | Android सुरक्षा बुलेटिन |
| बसपा | बोर्ड सपोर्ट पैकेज |
| सीडीडी | कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट |
| CTS | Compatibility Test Suite |
| FOTA | फ़र्मवेयर ओवर द एयर |
| जीपीएस | ग्लोबल पोज़िशनिंग सिस्टम |
| MISRA | मोटर इंडस्ट्री सॉफ़्टवेयर रिलायबिलिटी असोसिएशन |
| NIST | नैशनल इंस्टिट्यूट ऑफ़ स्टैंडर्ड्स ऐंड टेक्नोलॉजी |
| ओबीडी | ऑन-बोर्ड डाइग्नोस्टिक्स (OBD-II, OBD-I से बेहतर है. यह सुविधा और स्टैंडर्ड, दोनों के मामले में बेहतर है) |
| OEM | ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर |
| ओएस | ऑपरेटिंग सिस्टम |
| SEI | सॉफ़्टवेयर इंजीनियरिंग इंस्टिट्यूट |
| SoC | चिप पर सिस्टम (SoC) |
| एसओपी | प्रोडक्शन शुरू होने की तारीख |
| एसपीएल | सुरक्षा पैच का लेवल |
| टीपीएमएस | टायर के दबाव की निगरानी करने वाला सिस्टम |
Android OS के बारे में जानकारी
Android, ओपन सोर्स और Linux पर आधारित एक फ़ुल सॉफ़्टवेयर स्टैक है. इसे अलग-अलग डिवाइसों और साइज़, डाइमेंशन या कॉन्फ़िगरेशन के हिसाब से डिज़ाइन किया गया है. Android को पहली बार 2008 में रिलीज़ किया गया था. तब से, यह सबसे लोकप्रिय ऑपरेटिंग सिस्टम (ओएस) बन गया है. साल 2016 में, दुनिया भर में 140 करोड़ से ज़्यादा डिवाइसों में Android का इस्तेमाल किया जा रहा था. मार्च 2017 तक, इनमें से करीब 67% डिवाइसों में Android 5.0 (Lollipop) या इसके बाद का वर्शन इस्तेमाल किया जा रहा था. ज़्यादा हाल के आंकड़े Android डैशबोर्ड पर उपलब्ध हैं. ज़्यादातर डिवाइस मोबाइल फ़ोन और टैबलेट हैं. हालांकि, Android का इस्तेमाल स्मार्टवॉच, टीवी, और गाड़ियों में लगे इन-व्हीकल इन्फ़ोटेनमेंट (आईवीआई) डिवाइसों में भी बढ़ रहा है.
Google Play Store पर उपलब्ध Android ऐप्लिकेशन की संख्या 2016 में 22 लाख से ज़्यादा हो गई थी. Android ऐप्लिकेशन डेवलपमेंट को Android Compatibility Program का सपोर्ट मिलता है. यह प्रोग्राम, Compatibility Definition Document (CDD) के ज़रिए ज़रूरी शर्तों का एक सेट तय करता है. साथ ही, Compatibility Test Suite (CTS) के ज़रिए टेस्टिंग टूल उपलब्ध कराता है. Android Compatibility Program यह पक्का करता है कि Android के साथ काम करने वाले किसी भी डिवाइस पर, Android का कोई भी ऐप्लिकेशन चल सके. हालांकि, इसके लिए ज़रूरी है कि डिवाइस में ऐप्लिकेशन के लिए ज़रूरी सुविधाएं मौजूद हों.
Google, ओएस के नए वर्शन, ओएस के सुरक्षा अपडेट, और मिली हुई कमज़ोरियों के बारे में नियमित तौर पर जानकारी जारी करता है. डिवाइस बनाने वाली कंपनियों को Android के सुरक्षा बुलेटिन देखने चाहिए. इससे उन्हें यह पता चलेगा कि Android OS पर काम करने वाले प्रॉडक्ट के लिए, ये अपडेट लागू किए जा सकते हैं या नहीं. Android की सुरक्षा, कंपैटिबिलिटी, और बिल्ड सिस्टम की समीक्षा के लिए, यहां जाएं:
- Android डिवाइस को सुरक्षित करना
- सुरक्षा से जुड़े अपडेट और संसाधन
- Compatibility Test Suite
- कोडनेम, टैग, और बिल्ड नंबर
कनेक्ट किए गए वाहनों (कैननिकल लॉन्ग-लिव्ड प्रॉडक्ट) के बारे में जानकारी
साल 1920 में एएम रेडियो की शुरुआत के साथ ही, वाहनों को कनेक्ट करने की सुविधा शुरू हुई. इसके बाद, बाहरी फ़िज़िकल और वायरलेस कनेक्शन की संख्या बढ़ने लगी. ऐसा इसलिए हुआ, क्योंकि रेगुलेटर और कार बनाने वाली कंपनियों ने, गड़बड़ियों का पता लगाने और सर्विसिंग को आसान बनाने के लिए इलेक्ट्रॉनिक्स का इस्तेमाल करना शुरू कर दिया. उदाहरण के लिए, ओबीडी-II पोर्ट. साथ ही, सुरक्षा को बेहतर बनाने के लिए, जैसे कि टीपीएमएस और ईंधन की बचत के लक्ष्यों को पूरा करने के लिए भी इलेक्ट्रॉनिक्स का इस्तेमाल किया जाने लगा. कनेक्टिविटी की अगली लहर में, ड्राइवर की सुविधा के लिए कई सुविधाएं पेश की गईं. जैसे, रिमोट से बिना चाबी के दरवाज़ा खोलने की सुविधा, टेलीमैटिक्स सिस्टम, और ब्लूटूथ, वाई-फ़ाई, और स्मार्टफ़ोन प्रोजेक्शन जैसी बेहतर इन्फ़ोटेनमेंट सुविधाएं. आजकल, इंटिग्रेटेड सेंसर और कनेक्टिविटी (जैसे, जीपीएस) की मदद से, सुरक्षा और सेमी-ऑटोनॉमस ड्राइविंग सिस्टम को सपोर्ट किया जाता है.
जैसे-जैसे वाहन के कनेक्शन बढ़ते हैं वैसे-वैसे वाहन पर संभावित साइबर हमले का दायरा भी बढ़ता जाता है. कनेक्टिविटी की वजह से, साइबर सुरक्षा से जुड़ी समस्याएं भी बढ़ जाती हैं. ये समस्याएं, उपभोक्ता इलेक्ट्रॉनिक्स से जुड़ी समस्याओं जैसी ही होती हैं. हालांकि, रीबूट होने, हर दिन पैच अपडेट होने, और बिना किसी वजह के काम न करने जैसी समस्याएं, उपभोक्ता इलेक्ट्रॉनिक्स में आम हैं. लेकिन, वाहनों जैसे सुरक्षा से जुड़े सिस्टम वाले प्रॉडक्ट में ये समस्याएं नहीं होनी चाहिए.
मैन्युफ़ैक्चरर को यह पक्का करने के लिए कि प्रॉडक्ट की सुरक्षा और सुरक्षा की स्थिति बनी रहे, पहले से ही ज़रूरी कदम उठाने चाहिए. संक्षेप में कहें, तो मैन्युफ़ैक्चरर को प्रॉडक्ट में मौजूद, सुरक्षा से जुड़ी उन कमियों के बारे में पता होना चाहिए जिनके बारे में पहले से जानकारी है. साथ ही, उन्हें इन कमियों को ठीक करने के लिए, जोखिम के आधार पर तरीका अपनाना चाहिए.
लंबे समय तक सुरक्षा बनाए रखना
कनेक्ट किए गए वाहन में अक्सर एक या उससे ज़्यादा इलेक्ट्रॉनिक कंट्रोल यूनिट (ईसीयू) होते हैं. इनमें कई सॉफ़्टवेयर कॉम्पोनेंट शामिल होते हैं, जैसे कि ओएस, लाइब्रेरी, यूटिलिटी वगैरह. मैन्युफ़ैक्चरर को ऐसे कॉम्पोनेंट ट्रैक करने चाहिए. साथ ही, पहले से मालूम जोखिम की पहचान करने के लिए, सक्रियता से विश्लेषण करना चाहिए. इसमें ये शामिल हैं:
- सामान्य जोखिम की आशंका और एक्सपोज़र (सीवीई) के डेटाबेस के हिसाब से, प्रॉडक्ट का नियमित तौर पर आकलन करना.
- प्रॉडक्ट से जुड़ी सुरक्षा की कमियों के बारे में जानकारी इकट्ठा करना.
- सुरक्षा की जांच करना.
- Android सुरक्षा बुलेटिन का लगातार विश्लेषण करना.
ओएस और सुरक्षा पैच अपडेट के उदाहरण (Android पर चलने वाले IVI):
पहली इमेज. वाहन के जीवनकाल में, ओएस और सुरक्षा से जुड़े अपडेट को रोल आउट करने का सैंपल.
| # | चरण | गतिविधियां |
|---|---|---|
|
① |
डेवलपमेंट ब्रांच | मैन्युफ़ैक्चरर, Android का कोई वर्शन (Android X) चुनता है. इस उदाहरण में, "Android X" को उस सिस्टम के आधार के तौर पर इस्तेमाल किया जाता है जिसे शुरुआती उत्पादन शुरू होने (एसओपी) से दो साल पहले, वाहन में शिप किया जाएगा. |
| ② | शुरुआती लॉन्च | Android X को प्रॉडक्ट में शिप किया जाने वाला पहला ओएस वर्शन बनने से कुछ महीने पहले, सुरक्षा अपडेट Android सुरक्षा बुलेटिन (एएसबी) और मैन्युफ़ैक्चरर के हिसाब से अन्य ज़रूरी स्रोतों से लिए जाते हैं. y2 = Android के वर्शन X के लिए दूसरा सुरक्षा बुलेटिन. इसे मैन्युफ़ैक्चरर ने Android X पर लागू किया (बैकपोर्ट किया). यह अपडेट, प्रॉडक्ट में शामिल होता है. साथ ही, Android X.y2 के साथ प्रोडक्शन क्लॉक, साल ज़ीरो से शुरू होती है.
इस उदाहरण में, डिवाइस बनाने वाली कंपनी ने Android X+1 के सालाना रिलीज़ होने वाले नए वर्शन को शिप न करने का फ़ैसला किया है. सबसे नई रिलीज़ को शिप करने की वजहों में, नई सुविधाएं जोड़ना, सुरक्षा से जुड़ी नई कमियों को ठीक करना, और/या Google या तीसरे पक्ष की ऐसी सेवाओं को शिप करना शामिल है जिनके लिए Android का नया वर्शन ज़रूरी है. हाल ही में रिलीज़ किए गए सॉफ़्टवेयर के साथ शिपिंग न करने की वजहें ये हैं: बदलावों को इंटिग्रेट करने, उनकी जांच करने, और उनकी पुष्टि करने के लिए, वाहन को डेवलप करने और लॉन्च करने की प्रोसेस में लगने वाला समय. इसमें सभी कानूनी और सर्टिफ़िकेशन से जुड़ी ज़रूरी शर्तों का पालन करना भी शामिल है. |
| ③ | पूरा ओएस अपडेट | एसओपी के बाद, मैन्युफ़ैक्चरर Android X+2 OS का अपडेट रिलीज़ करता है. यह Android के दो वर्शन के बाद का अपडेट होता है. Android X0, शुरुआती प्रॉडक्ट के लिए इस्तेमाल किया गया वर्शन है. एएसबी के सुरक्षा अपडेट, एपीआई लेवल (शिपिंग की तारीख के हिसाब से) के लिए उपलब्ध हैं. इसलिए, अपडेट एसओपी के करीब 1.25 साल बाद X+2.y0 के तौर पर जारी किया जाता है. ऐसा हो सकता है कि ओएस का यह अपडेट, फ़ील्ड में मौजूद प्रॉडक्ट के साथ काम न करे. अगर ऐसा है, तो
डिप्लॉय किए गए वाहनों को अपडेट करने के लिए, एक प्लान बनाया जा सकता है.
जब तक कारोबार से जुड़े अन्य कानूनी समझौते लागू नहीं होते, तब तक ओएस को पूरी तरह से अपडेट करने का फ़ैसला, पूरी तरह से मैन्युफ़ैक्चरर के विवेक पर निर्भर करता है. |
| ④ | सुरक्षा से जुड़ा अपडेट | गाड़ी के प्रोडक्शन के दो साल बाद, मैन्युफ़ैक्चरर Android X+2 OS को पैच करता है. यह फ़ैसला, मैन्युफ़ैक्चरर के जोखिम के आकलन के आधार पर लिया जाता है. मैन्युफ़ैक्चरर, अपडेट के आधार के तौर पर, रिलीज़ X+2 के लिए तीसरे ASB सुरक्षा अपडेट को चुनता है. सुरक्षा अपडेट पाने वाले प्रॉडक्ट, अब (X+2.y3) ओएस + Android सुरक्षा पैच लेवल पर हैं.
मैन्युफ़ैक्चरर, किसी भी एएसबी से अलग-अलग सुरक्षा पैच चुन सकते हैं. हालांकि, उन्हें बुलेटिन में बताई गई सभी ज़रूरी समस्याओं को ठीक करना होगा, ताकि वे बुलेटिन से जुड़े Android सुरक्षा पैच लेवल (एसपीएल) का इस्तेमाल कर सकें. उदाहरण के लिए, 2017-02-05. सपोर्ट किए गए प्रॉडक्ट के लिए, बैकपोर्ट और सुरक्षा से जुड़ी रिलीज़ करने की ज़िम्मेदारी मैन्युफ़ैक्चरर की होती है. |
| ⑤ | पूरा ओएस अपडेट | तीसरे चरण (पूरे ओएस को अपडेट करना) को दोहराया जाता है. दूसरी बार पूरे ओएस को अपडेट करने पर, प्रॉडक्ट को Android X+4 पर अपग्रेड किया जाता है. यह अपग्रेड, वाहन के प्रोडक्शन के तीन साल बाद किया जाता है. मैन्युफ़ैक्चरर अब Android के नए वर्शन के लिए, हार्डवेयर से जुड़ी नई ज़रूरी शर्तों को प्रॉडक्ट में मौजूद हार्डवेयर के साथ-साथ उपयोगकर्ता के फ़ायदों के हिसाब से तय कर रहा है. इससे उपयोगकर्ता को Android ओएस के अपडेट किए गए वर्शन का फ़ायदा मिलता है. डिवाइस बनाने वाली कंपनी, सुरक्षा अपडेट के बिना एक अपडेट रिलीज़ करती है. इसलिए, प्रॉडक्ट अब (X+4.y0) ओएस + Android सिक्योरिटी पैच लेवल पर है.
इस उदाहरण में, हार्डवेयर की सीमाओं की वजह से, X+4 Android का आखिरी मुख्य वर्शन है, जो इस प्रॉडक्ट के लिए उपलब्ध कराया जाएगा. हालांकि, वाहन के छह साल से ज़्यादा चलने की उम्मीद होने के बावजूद, सुरक्षा से जुड़ी सहायता की ज़रूरत होती है. |
| ⑥ | सुरक्षा से जुड़ा अपडेट | चौथे चरण (सुरक्षा से जुड़ा अपडेट) को दोहराया गया है. डिवाइस बनाने वाली कंपनी को Android के नए वर्शन (X+6) से ASB सुरक्षा अपडेट लेने होते हैं. इसके बाद, उसे उन अपडेट में से कुछ या सभी को Android X+4 पर पोर्ट करना होता है. अपडेट को मर्ज, इंटिग्रेट, और लागू करने की ज़िम्मेदारी, मैन्युफ़ैक्चरर की होती है. इसके अलावा, वह किसी तीसरे पक्ष के साथ कानूनी समझौता भी कर सकता है. इसके अलावा, मैन्युफ़ैक्चरर को यह भी पता होना चाहिए कि Android के उन वर्शन में सुरक्षा से जुड़ी समस्याओं को ASB में शामिल नहीं किया जाता है जिनके लिए अब सहायता उपलब्ध नहीं है. |
| ⑦ | सुरक्षा से जुड़ा अपडेट | वाहन के प्रोडक्शन के आठ साल बाद, चरण 5 (पूरा ओएस अपडेट) में आखिरी ओएस अपडेट के बाद से चार Android रिलीज़ हो चुकी हैं. साथ ही, Android X को रिलीज़ हुए दस साल हो चुके हैं. ऐसे में, एपीआई लेवल की सार्वजनिक रिलीज़ के तीन साल से ज़्यादा पुराने वर्शन के लिए, सुरक्षा पैच को मैनेज करने और उन्हें बैकपोर्ट करने की ज़िम्मेदारी पूरी तरह से मैन्युफ़ैक्चरर की होती है. |
सुरक्षा के सबसे सही तरीके
सुरक्षा से जुड़े जोखिमों को कम करने के लिए, Google सुरक्षा और सॉफ़्टवेयर इंजीनियरिंग के लिए, आम तौर पर स्वीकार किए जाने वाले सबसे सही तरीकों का इस्तेमाल करता है. इनके बारे में सुरक्षा लागू करना लेख में बताया गया है.
सुरक्षा से जुड़े दिशा-निर्देश
सुरक्षा के लिए सुझाए गए तरीकों में ये शामिल हैं:
- बाहरी लाइब्रेरी और ओपन सोर्स कॉम्पोनेंट के नए वर्शन का इस्तेमाल करें.
- ओएस के रिलीज़ वर्शन में, डीबग करने से जुड़ा ऐसा फ़ंक्शन शामिल न करें जो उपयोगकर्ता की निजता में दख़ल देता हो.
- इस्तेमाल नहीं की गई सुविधा को हटाएं, ताकि हमले की गुंजाइश कम हो सके.
- कम से कम अधिकारों के सिद्धांत और Android ऐप्लिकेशन डेवलपमेंट के अन्य सबसे सही तरीकों का इस्तेमाल करें.
सॉफ़्टवेयर डेवलपमेंट से जुड़े दिशा-निर्देश
सिस्टम के लाइफ़साइकल के लिए, सुरक्षित सॉफ़्टवेयर डेवलपमेंट के लिए सुझाए गए तरीकों में ये शामिल हैं:
- खतरों का आकलन करने के लिए, थ्रेट मॉडलिंग की जाती है. इससे ऐसेट, खतरों, और संभावित जोखिमों की पहचान करने और उन्हें रैंक करने में मदद मिलती है.
- आर्किटेक्चर/डिज़ाइन की समीक्षा करें, ताकि यह पक्का किया जा सके कि डिज़ाइन सुरक्षित और सही है.
- कोड की नियमित तौर पर समीक्षा करें, ताकि एंटी-पैटर्न और गड़बड़ियों का जल्द से जल्द पता लगाया जा सके.
- ज़्यादा कोड कवरेज वाली यूनिट टेस्ट डिज़ाइन, लागू, और चलाएं. इनमें ये शामिल हैं:
- फ़ंक्शन की जांच करना (इसमें नेगेटिव टेस्ट केस भी शामिल हैं)
- रिग्रेशन टेस्टिंग को नियमित तौर पर करना (यह पक्का करने के लिए कि ठीक की गई गड़बड़ियां फिर से न दिखें)
- फ़ज़ टेस्टिंग (यूनिट टेस्ट सुइट के तौर पर)
- संभावित समस्याओं का पता लगाने के लिए, स्टैटिक सोर्स कोड का विश्लेषण करने वाले टूल (स्कैन-बिल्ड, लिंट वगैरह) का इस्तेमाल करें.
- सिस्टम डेवलपमेंट के दौरान संभावित समस्याओं की पहचान करने और उन्हें कम करने के लिए, डाइनैमिक सोर्स कोड विश्लेषण टूल का इस्तेमाल करें. जैसे, AddressSanitizer, UndefinedBehaviorSanitizer, और FORTIFY_SOURCE (नेटिव कॉम्पोनेंट के लिए).
- सॉफ़्टवेयर के सोर्स कोड और रिलीज़ कॉन्फ़िगरेशन/वर्शन को मैनेज करने के लिए, एक रणनीति बनाएं.
- सॉफ़्टवेयर पैच जनरेट करने और उन्हें डिप्लॉय करने के लिए, पैच मैनेजमेंट की रणनीति लागू की गई हो.
सुरक्षा से जुड़ी बैकपोर्टिंग की नीति
Google, सुरक्षा से जुड़ी उन कमियों के लिए सुरक्षा से जुड़े बैकपोर्ट की सुविधा देता है जिनके बारे में पता चला है और जिनकी शिकायत की गई है. यह सुविधा, एपीआई लेवल के सार्वजनिक तौर पर रिलीज़ होने के बाद तीन (3) साल तक मिलती है. ऐक्टिव सहायता में ये शामिल हैं:
- जोखिम की संभावना वाली रिपोर्ट पाना और उनकी जांच करना.
- सुरक्षा से जुड़े अपडेट बनाना, उनकी जांच करना, और उन्हें रिलीज़ करना.
- सुरक्षा से जुड़े अपडेट और सुरक्षा बुलेटिन की जानकारी बार-बार उपलब्ध कराएं.
- तय की गई गाइडलाइन के मुताबिक, गंभीरता का आकलन करें.
एपीआई लेवल के सार्वजनिक तौर पर उपलब्ध होने की तारीख के तीन साल बाद, Google इन दिशा-निर्देशों का पालन करने का सुझाव देता है:
- एपीआई रिलीज़ होने के तीन साल से ज़्यादा पुराने ओएस के सुरक्षा अपडेट के लिए, बैकपोर्ट सपोर्ट के लिए किसी तीसरे पक्ष (जैसे कि SoC वेंडर या कर्नल प्रोवाइडर) का इस्तेमाल करें.
- सार्वजनिक तौर पर उपलब्ध कराए गए एएसबी का इस्तेमाल करके, कोड की समीक्षा करने के लिए किसी तीसरे पक्ष की सेवा का इस्तेमाल करें. एएसबी, फ़िलहाल सपोर्ट किए जा रहे वर्शन की कमज़ोरियों का पता लगाते हैं. हालांकि, डिवाइस बनाने वाली कंपनी दी गई जानकारी का इस्तेमाल करके, नए अपडेट की तुलना पिछले वर्शन से कर सकती है. इस डेटा का इस्तेमाल, असर का विश्लेषण करने के लिए किया जा सकता है. साथ ही, इससे एपीआई रिलीज़ होने के तीन साल से पुराने ओएस वर्शन के लिए, मिलते-जुलते पैच जनरेट किए जा सकते हैं.
- ज़रूरत पड़ने पर, Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में सुरक्षा से जुड़े अपडेट अपलोड करें.
- डिवाइस बनाने वाली कंपनी को, वेंडर के हिसाब से कोड के लिए सुरक्षा अपडेट मैनेज करने होंगे. उदाहरण के लिए, मालिकाना हक वाला डिवाइस के हिसाब से कोड.
- निर्माता को एनडीए Android Security Bulletin Partner Preview notification ग्रुप में शामिल होना चाहिए. इसके लिए, कानूनी समझौते (जैसे कि डेवलपर एनडीए) पर हस्ताक्षर करना ज़रूरी है. बुलेटिन में यह जानकारी शामिल होनी चाहिए:
- सूचनाएं
- पैच लेवल के हिसाब से समस्याओं की खास जानकारी. इसमें CVE और गंभीरता की जानकारी भी शामिल है
- जहां ज़रूरी हो वहां सुरक्षा जोखिम की जानकारी
अन्य रेफ़रंस
सुरक्षित कोडिंग और सॉफ़्टवेयर डेवलपमेंट के तरीकों के बारे में जानने के लिए, यहां दिया गया लेख पढ़ें:
- Motor Industry Software Reliability Association (MISRA).
- सॉफ़्टवेयर इंजीनियरिंग इंस्टिट्यूट (एसईआई) के टूल और तरीके.
- नैशनल इंस्टिट्यूट ऑफ़ स्टैंडर्ड्स ऐंड टेक्नोलॉजी (एनआईएसटी).
प्रॉडक्ट के लिए सुझाए गए तरीके
Google, यहां दिए गए सुझावों को अपनाने के लिए कहता है.
लॉन्च करने से जुड़े सामान्य दिशा-निर्देश
आम तौर पर, यह सुझाव दिया जाता है कि कनेक्ट किए गए किसी भी प्रॉडक्ट को ओएस के नए वर्शन के साथ लॉन्च किया जाए. साथ ही, प्रॉडक्ट लॉन्च करने से पहले, मैन्युफ़ैक्चरर को ओएस के सबसे नए वर्शन का इस्तेमाल करना चाहिए. टेस्टिंग और पुष्टि करने से पहले, वर्शन को लॉक करना ज़रूरी है, ताकि वह ठीक से काम करे. हालांकि, डिवाइस बनाने वाली कंपनी को ओएस के पुराने वर्शन से मिलने वाली स्थिरता और ओएस के नए वर्शन से मिलने वाली स्थिरता के बीच संतुलन बनाए रखना चाहिए. ओएस के नए वर्शन में, सुरक्षा से जुड़ी कमियां कम होती हैं और सुरक्षा के बेहतर तरीके होते हैं.
सुझाए गए दिशा-निर्देशों में ये शामिल हैं:
- वाहन को डेवलप करने में ज़्यादा समय लगता है. इसलिए, हो सकता है कि वाहन बनाने वाली कंपनियों को OS के n-2 या इससे पुराने वर्शन के साथ लॉन्च करना पड़े.
- Android के हर रिलीज़ किए गए वर्शन के लिए, Android के साथ काम करने की सुविधा को बनाए रखें. इसके लिए, ओवर-द-एयर (OTA) कैंपेन का इस्तेमाल करें.
- प्रॉडक्ट में Android फ़र्मवेयर-ओवर-द-एयर (FOTA) की सुविधा लागू करें, ताकि ग्राहकों को आसानी से और तेज़ी से अपडेट मिल सकें. FOTA को सुरक्षा से जुड़े सबसे सही तरीकों का इस्तेमाल करके किया जाना चाहिए. जैसे, कोड साइनिंग और प्रॉडक्ट और आईटी बैकऑफ़िस के बीच टीएलएस कनेक्शन.
- Android की सुरक्षा से जुड़ी उन कमियों को Android की सुरक्षा टीम को सबमिट करें जिनका पता आपने खुद लगाया है.
ध्यान दें: Google ने Android सुरक्षा बुलेटिन में, डिवाइस टाइप या इंडस्ट्री के हिसाब से सूचनाएं देने के बारे में सोचा है. हालांकि, Google को किसी डिवाइस (वाहन, टीवी, पहनने योग्य डिवाइस, फ़ोन वगैरह) के कर्नल, ड्राइवर या चिपसेट के बारे में जानकारी नहीं होती. इसलिए, Google के पास किसी डिवाइस टाइप से जुड़ी सुरक्षा की किसी भी समस्या को लेबल करने का कोई तय तरीका नहीं है.
प्रॉडक्ट साइकल के दिशा-निर्देश
डिवाइस बनाने वाली कंपनी को, प्रॉडक्ट के जीवनकाल को बेहतर बनाने के दौरान, इस्तेमाल किए जा रहे वर्शन के लिए, ओएस के नए वर्शन या सुरक्षा अपडेट का इस्तेमाल करने की पूरी कोशिश करनी चाहिए. प्रॉडक्ट को समय-समय पर अपडेट किया जा सकता है. इसके अलावा, क्वालिटी और/या अन्य समस्याओं को ठीक करने के लिए भी अपडेट किया जा सकता है. सुझाए गए तरीकों में ये शामिल हैं:
- ड्राइवर, कर्नल, और प्रोटोकॉल से जुड़े अपडेट के लिए प्लान बनाएं.
- तैनात किए गए वाहनों के बारे में अपडेट देने के लिए, इंडस्ट्री के हिसाब से सही तरीके का इस्तेमाल करें.
कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट (सीडीडी)
कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट (सीडीडी) में, किसी डिवाइस के Android के साथ काम करने की ज़रूरी शर्तों के बारे में बताया गया है. सीडीडी सार्वजनिक तौर पर उपलब्ध है और इसे कोई भी ऐक्सेस कर सकता है. Android 1.6 से लेकर नए वर्शन तक के सीडीडी वर्शन डाउनलोड किए जा सकते हैं. इसके लिए, source.android.com पर जाएं.
किसी प्रॉडक्ट के लिए इन ज़रूरी शर्तों को पूरा करने के लिए, यह तरीका अपनाएं:
- पार्टनर, Google के साथ Android Compatibility Commitment (ACC) पर हस्ताक्षर करता है. इसके बाद, एक टेक्निकल सलूशन कंसल्टेंट (टीएससी) को गाइड के तौर पर असाइन किया जाता है.
- पार्टनर, प्रॉडक्ट के Android OS वर्शन के लिए सीडीडी की समीक्षा पूरी करता है.
- पार्टनर, Android के साथ काम करने की ज़रूरी शर्तों को पूरा करने के लिए, सीटीएस टेस्ट चलाता है और उसके नतीजे सबमिट करता है. इसके बारे में यहां बताया गया है.
Compatibility Test Suite (CTS)
Compatibility Test Suite (CTS) टेस्टिंग टूल से यह पुष्टि की जाती है कि कोई प्रॉडक्ट, Android के साथ काम करता है या नहीं. साथ ही, यह भी पुष्टि की जाती है कि उसमें सुरक्षा से जुड़े नए पैच शामिल हैं या नहीं. सीटीएस सार्वजनिक, ओपन सोर्स, और सभी के लिए उपलब्ध है. Android 1.6 से लेकर नए वर्शन तक के सीटीएस वर्शन, source.android.com से डाउनलोड किए जा सकते हैं.
Android सॉफ़्टवेयर के हर ऐसे बिल्ड को सार्वजनिक तौर पर रिलीज़ किया जाना चाहिए जो सीटीएस के नतीजों के ज़रिए, Android के साथ काम करने की पुष्टि करता हो. जैसे, फ़ैक्ट्री में इंस्टॉल किए जाने वाले और फ़ील्ड में अपडेट किए जाने वाले इमेज. उदाहरण के लिए, अगर डिवाइस में Android 7.1 है, तो रिलीज़-इंटेंट बिल्ड इमेज बनाते और उसकी जांच करते समय, CDD 7.1 और CTS 7.1 के सबसे नए वर्शन का इस्तेमाल किया जाना चाहिए. मैन्युफ़ैक्चरर को यह सुझाव दिया जाता है कि वे समस्याओं की पहचान करने और उन्हें ठीक करने के लिए, सीटीएस का इस्तेमाल जल्दी और बार-बार करें.
CTS वर्कफ़्लो
CTS वर्कफ़्लो में, टेस्टिंग एनवायरमेंट सेट अप करना, टेस्ट चलाना, नतीजों की व्याख्या करना, और CTS सोर्स कोड को समझना शामिल है. यहां दिए गए दिशा-निर्देश, CTS का इस्तेमाल करने वाले लोगों (जैसे, डेवलपर, मैन्युफ़ैक्चरर) की मदद करने के लिए बनाए गए हैं. इनसे वे CTS का असरदार तरीके से इस्तेमाल कर पाएंगे.
- बार-बार टेस्ट चलाएं. सीटीएस को एक ऑटोमेटेड टूल के तौर पर डिज़ाइन किया गया है. यह आपके बिल्ड सिस्टम में इंटिग्रेट हो जाता है. बार-बार सीटीएस चलाने से, सॉफ़्टवेयर में खराबी या रिग्रेशन होने पर, आपको जल्दी और आसानी से गड़बड़ियों का पता लगाने में मदद मिल सकती है.
- CTS के सोर्स कोड को डाउनलोड और उसकी जांच करें. पूरा CTS सोर्स कोड, ओपन सोर्स सॉफ़्टवेयर है. इसे कोई भी व्यक्ति डाउनलोड और इस्तेमाल कर सकता है. डाउनलोड किए गए सोर्स कोड को पूरी तरह से बनाया और चलाया जा सकता है. अगर डिवाइस पर कोई टेस्ट पूरा नहीं होता है, तो सोर्स कोड के संबंधित सेक्शन की जांच करके, यह पता लगाया जा सकता है कि ऐसा क्यों हुआ.
- CTS का नया वर्शन पाएं. Android की नई रिलीज़ में, गड़बड़ियों को ठीक करने, सुधार करने, और नए टेस्ट के साथ सीटीएस को अपडेट किया जा सकता है. सीटीएस डाउनलोड को समय-समय पर देखें और अपने सीटीएस प्रोग्राम को ज़रूरत के मुताबिक अपडेट करें. प्रॉडक्ट लॉन्च करने के लिए, मैन्युफ़ैक्चरर और Google को सीटीएस के एक वर्शन पर सहमत होना होगा. ऐसा इसलिए, क्योंकि सीटीएस को अपडेट किया जाता रहता है, लेकिन प्रॉडक्ट को किसी समय पर फ़्रीज़ करना ज़रूरी होता है.
सीटीएस पास करना
Android के साथ काम करने वाले किसी प्रॉडक्ट के लिए, Google यह पक्का करता है कि डिवाइस के सीटीएस और सीटीएस वेरिफ़ायर की रिपोर्ट में टेस्ट के नतीजे स्वीकार किए जा सकते हैं. सिद्धांत के तौर पर, सभी टेस्ट पास होने चाहिए. हालांकि, अगर कोई टेस्ट इस वजह से पास नहीं होता है कि डिवाइस, Android के साथ काम करने की ज़रूरी शर्तों का पालन नहीं करता है, तो Google उसकी समीक्षा करेगा. इस प्रोसेस के दौरान:
- डिवाइस बनाने वाली कंपनी, Google को सीटीएस पैच, पैच की पुष्टि, और तर्क को सही साबित करने के लिए ज़रूरी जानकारी देती है.
- Google, सबमिट किए गए मटीरियल की जांच करता है. अगर इसे स्वीकार कर लिया जाता है, तो Google, सीटीएस के ज़रूरी टेस्ट अपडेट करता है. इससे डिवाइस, सीटीएस के अगले वर्शन में पास हो जाता है.
अगर सुरक्षा पैच लागू करने के बाद, अचानक कोई सीटीएस टेस्ट फ़ेल हो जाता है, तो डिवाइस बनाने वाली कंपनी को पैच में बदलाव करना होगा, ताकि वह कंपैटिबिलिटी को न तोड़े. इसके अलावा, यह भी दिखाया जा सकता है कि टेस्ट गलत है और टेस्ट को ठीक करने का तरीका बताया जा सकता है (जैसा कि ऊपर बताया गया है).
टेस्ट फ़िक्स की समीक्षाओं के लिए, सीटीएस खुला रहता है. उदाहरण के लिए, Android 4.4 में अब भी फ़िक्स स्वीकार किए जाते हैं. इसके बारे में जानने के लिए, https://android-review.googlesource.com/c/platform/cts/+/273371 पर जाएं.
अक्सर पूछे जाने वाले सवाल
सवाल: Android के किसी खास वर्शन पर सुरक्षा से जुड़े अपडेट लागू करने की ज़िम्मेदारी किसकी होती है?
जवाब: डिवाइस बनाने वाली कंपनी सीधे तौर पर डिवाइस उपलब्ध कराती है. इसलिए, वह इसके लिए ज़िम्मेदार है. यह इकाई, Google नहीं है. यह AOSP में सुरक्षा से जुड़े अपडेट पब्लिश करती है. हालांकि, यह किसी खास डिवाइस (जैसे कि वाहन) के लिए अपडेट पब्लिश नहीं करती.
सवाल: Google, Android में सुरक्षा से जुड़ी समस्याओं को कैसे हैंडल करता है?
जवाब: Google लगातार समस्याओं की जांच करता है और उन्हें ठीक करने के तरीके ढूंढता है. Google, सुरक्षा से जुड़े अपडेट की नियमित प्रोसेस के तहत, इन तरीकों को सभी ज़रूरी एपीआई लेवल के लिए उपलब्ध कराता है. Google, अगस्त 2015 से source.android.com पर बुलेटिन और अपडेट के लिंक पब्लिश करता आ रहा है. Google, ओएस के मुख्य वर्शन के साथ सुरक्षा से जुड़े अपडेट भी पब्लिश करता है. सुरक्षा से जुड़ी बैकपोर्टिंग की नीति भी देखें.
सवाल: अगर किसी मैन्युफ़ैक्चरर ने ASB से सभी एओएसपी पैच इंटिग्रेट किए हैं, लेकिन उसी बुलेटिन में बताए गए बीएसपी वेंडर से पैच इंटिग्रेट नहीं किए हैं, तो क्या वह अब भी सुरक्षा का लेवल बढ़ा सकता है (उदाहरण के लिए, प्लैटफ़ॉर्म/बिल्ड पर उससे जुड़ा पैच लागू करना)?
जवाब: Android के सुरक्षा पैच का लेवल (एसपीएल) तय करने के लिए, डिवाइस बनाने वाली कंपनी को Android के सुरक्षा बुलेटिन (पिछले बुलेटिन भी शामिल हैं) में पब्लिश की गई सभी ज़रूरी समस्याओं को ठीक करना होगा. साथ ही, उन्हें किसी खास Android एसपीएल से मैप करना होगा. उदाहरण के लिए, अगर कोई डिवाइस बनाने वाली कंपनी मार्च 2017 के सुरक्षा बुलेटिन (1 मार्च, 2017 का एसपीएल) का इस्तेमाल करती है, तो इसका मतलब है कि उसने मार्च 2017 के बुलेटिन में बताए गए एसपीएल से जुड़ी सभी ज़रूरी समस्याओं को ठीक कर दिया है. साथ ही, उसने डिवाइस के हिसाब से बनाए गए उन सभी अपडेट को भी लागू कर दिया है जो Android के पिछले सभी सुरक्षा बुलेटिन में बताए गए थे. इनमें 5 फ़रवरी, 2017 के एसपीएल से जुड़े डिवाइस के हिसाब से बनाए गए अपडेट भी शामिल हैं.
सवाल: अगर डिवाइस बनाने वाली कंपनी, बीएसपी वेंडर के दिए गए सुरक्षा अपडेट से सहमत नहीं है, तो क्या होगा? इसके अलावा, अगर एएसबी की ओर से ज़रूरी सुरक्षा अपडेट, वेंडर उपलब्ध नहीं कराते हैं, तो क्या होगा?
जवाब: एएसबी में सुरक्षा से जुड़ी कमियों के बारे में बताया जाता है. इन कमियों को सीवीई की सूची में शामिल किया जाता है. साथ ही, इसमें अक्सर सुरक्षा से जुड़े टेस्ट भी शामिल होते हैं. इसका मकसद यह पक्का करना है कि डिवाइस पर बताई गई कमियों को ठीक कर दिया गया है और डिवाइस, सुरक्षा से जुड़े टेस्ट पास कर सकता है. इसलिए, समस्या Google या तीसरे पक्ष के वेंडर से मिले सुरक्षा अपडेट को लागू करने से जुड़ी नहीं है. बल्कि, यह इस बात से जुड़ी है कि मैन्युफ़ैक्चरर यह पुष्टि करे कि डिवाइस, ASB में मौजूद सीवीई की सूची के हिसाब से सुरक्षित है. डिवाइस बनाने वाली कंपनी के पास, सुरक्षा से जुड़े अपडेट का इस्तेमाल करने का विकल्प होता है. इसके अलावा, अगर कंपनी को लगता है कि उसके डिवाइस के लिए कोई और अपडेट ज़्यादा सही है, तो वह उसका इस्तेमाल कर सकती है.
उदाहरण के लिए, मान लें कि Google, AOSP में सुरक्षा से जुड़े जोखिम को ठीक करने के लिए कोड में बदलाव करता है. इससे कॉम्पोनेंट पूरी तरह से काम करता रहता है और सीडीडी के मुताबिक होता है. अगर डिवाइस बनाने वाली कंपनी को लगता है कि डिवाइस पर कॉम्पोनेंट की ज़रूरत नहीं है या सीडीडी (या इससे जुड़ी सर्टिफ़िकेशन टेस्टिंग) के लिए यह ज़रूरी नहीं है, तो कंपनी कॉम्पोनेंट को हटा सकती है. इससे आने वाले समय में डिवाइस को ठीक करने की ज़रूरत कम होगी और हमले की आशंका भी कम हो जाएगी. डिवाइस बनाने वाली कंपनी ने सुरक्षा से जुड़े उपलब्ध कराए गए अपडेट का इस्तेमाल नहीं किया. हालांकि, उसने यह पक्का किया कि डिवाइस, सुरक्षा बुलेटिन में बताए गए CVE के लिए असुरक्षित न हो. हालांकि, सुरक्षा से जुड़े सुझाए गए अपडेट से अलग होने पर, डिवाइस बनाने वाली कंपनी को ये जोखिम उठाने पड़ सकते हैं: समस्या को गलत तरीके से ठीक करना, सुरक्षा से जुड़ी नई जोखिम की आशंकाएं पैदा करना या किसी अन्य तरीके से फ़ाइनल बिल्ड की सुविधाओं को कम करना.
हम सभी एसओसी पार्टनर के साथ मिलकर काम करते हैं, ताकि यह पक्का किया जा सके कि एएसबी में मौजूद सभी समस्याओं को ठीक किया जा सके. हमारा सुझाव है कि डिवाइस के पूरे जीवनकाल के लिए, मैन्युफ़ैक्चरर अपने एसओसी वेंडर के साथ सर्विसिंग का समझौता करें. ऐसा हो सकता है कि एसओसी, चिपसेट के लिए तय समय से पहले सेवाएं देना बंद कर दे. इसलिए, डिवाइस के चिपसेट को चुनने से पहले समझौते करना, डिवाइस लॉन्च करने की प्रोसेस का एक अहम हिस्सा है.
आखिर में, अगर किसी एएसबी में बताई गई समस्या को ठीक करने के लिए, सीधे तौर पर कोई समाधान नहीं मिल पा रहा है या उसे अलग से नहीं बनाया जा सकता, तो डिवाइस बनाने वाली कंपनी, Android के पिछले एसपीएल को बनाए रख सकती है. साथ ही, बिल्ड में उपलब्ध नए समाधानों को जोड़ सकती है. हालांकि, इस तरीके से बिल्ड सर्टिफ़िकेशन से जुड़ी समस्याएं हो सकती हैं. ऐसा इसलिए, क्योंकि Android यह पक्का करता है कि सर्टिफ़ाइड डिवाइसों पर नया सिक्योरिटी पैच लेवल उपलब्ध हो. Google का सुझाव है कि इस तरह की समस्या से बचने के लिए, पहले से ही अपने एसओसी के साथ काम करें.
सवाल: अगर डिवाइस बनाने वाली कंपनी को लगता है कि एएसबी आइटम, उसके प्रॉडक्ट पर लागू नहीं होता है, तो क्या Google की अन्य ज़रूरी शर्तों को पूरा करने या सीटीएस पास करने के लिए, आइटम को अब भी लागू या पैच करना होगा?
जवाब: Android सुरक्षा पैच लेवल (एसपीएल) का एलान करने के लिए, पैच को लागू करना ज़रूरी नहीं है. हालांकि, हम यह ज़रूरी मानते हैं कि डिवाइस बनाने वाली कंपनी यह पुष्टि करे कि उसका बिल्ड, समस्या के लिए जोखिम भरा नहीं है.
उदाहरण के लिए, ऐसा हो सकता है कि जिस कॉम्पोनेंट को पैच किया जा रहा है वह मैन्युफ़ैक्चरर के सिस्टम में मौजूद न हो या किसी समस्या को ठीक करने के लिए, मैन्युफ़ैक्चरर के सिस्टम से किसी कॉम्पोनेंट को हटा दिया गया हो. ऐसे में, सिस्टम ज़रूरी शर्तों का पालन कर सकता है. इसके लिए, मैन्युफ़ैक्चरर को पैच लेने की ज़रूरत नहीं होगी.
यह इस मामले से अलग है कि कोई मैन्युफ़ैक्चरर सिर्फ़ ज़रूरी पैच ठीक करना चाहता है. वहीं, वह अन्य लागू होने वाले पैच को ठीक नहीं करना चाहता, जिनकी वजह से सुरक्षा जांच में गड़बड़ी हो सकती है. इस मामले में, यह मान लिया जाता है कि एसपीएल की शर्तों को पूरा नहीं किया गया है.