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