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