दीर्घकालिक Android सुरक्षा के लिए निर्माता मार्गदर्शिका

यह मार्गदर्शिका सुरक्षा पैच लागू करने के लिए Google द्वारा अनुशंसित सर्वोत्तम प्रथाओं का वर्णन करती है जिनका मूल्यांकन Android संगतता परीक्षण सूट (CTS) द्वारा किया जाता है। यह एंड्रॉइड-संगत ओईएम उपकरण (निर्माताओं) के निर्माताओं के लिए है जो तीन साल से अधिक समय तक समर्थित होंगे जैसे वाहन, टीवी, सेट-टॉप बॉक्स और घरेलू उपकरण। यह मार्गदर्शिका अंतिम उपयोगकर्ताओं (उदाहरण के लिए, वाहन मालिकों) के लिए नहीं है।

स्वीकृतियाँ और अस्वीकरण

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

प्रतिक्रिया

इस मार्गदर्शिका का उद्देश्य व्यापक होना नहीं है; अतिरिक्त संशोधन की योजना बनाई गई है। Manufacturers-guide-android@googlegroups.com पर फीडबैक सबमिट करें।

शब्दकोष

एंड्रॉइड ओएस के बारे में

एंड्रॉइड एक खुला स्रोत, लिनक्स-आधारित पूर्ण सॉफ़्टवेयर स्टैक है जिसे विभिन्न प्रकार के उपकरणों और फॉर्म कारकों के लिए डिज़ाइन किया गया है। 2008 में अपनी पहली रिलीज के बाद से, एंड्रॉइड सबसे लोकप्रिय ऑपरेटिंग सिस्टम (ओएस) बन गया है, जो दुनिया भर में 1.4+ बिलियन डिवाइसों को पावर देता है (2016)। मार्च 2017 तक उनमें से लगभग 67% डिवाइस एंड्रॉइड 5.0 (लॉलीपॉप) या नए का उपयोग करते हैं (हाल के आंकड़े एंड्रॉइड डैशबोर्ड पर उपलब्ध हैं)। जबकि अधिकांश उपकरण मोबाइल फोन और टैबलेट हैं, एंड्रॉइड स्मार्टवॉच, टीवी और ऑटोमोटिव इन-व्हीकल इंफोटेनमेंट (आईवीआई) उपकरणों में बढ़ रहा है।

Google Play Store पर उपलब्ध Android ऐप्स की संख्या 2.2+ मिलियन (2016) तक पहुंच गई है। एंड्रॉइड ऐप डेवलपमेंट एंड्रॉइड संगतता प्रोग्राम द्वारा समर्थित है, जो संगतता परिभाषा दस्तावेज़ (सीडीडी) के माध्यम से आवश्यकताओं के एक सेट को परिभाषित करता है और संगतता परीक्षण सूट (सीटीएस) के माध्यम से परीक्षण उपकरण प्रदान करता है। एंड्रॉइड संगतता प्रोग्राम यह सुनिश्चित करता है कि कोई भी एंड्रॉइड ऐप किसी भी एंड्रॉइड-संगत डिवाइस पर चल सकता है जो ऐप के लिए आवश्यक सुविधाओं का समर्थन करता है।

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

• एक Android डिवाइस सुरक्षित करें
• सुरक्षा अद्यतन और संसाधन
• संगतता परीक्षण सुइट
• कोडनाम, टैग और बिल्ड नंबर

कनेक्टेड वाहनों के बारे में (विहित दीर्घकालिक उत्पाद)

1920 के दशक में एएम रेडियो की शुरुआत के साथ वाहनों को जोड़ा जाने लगा। वहां से, बाहरी भौतिक और वायरलेस कनेक्शन की संख्या बढ़ने लगी क्योंकि नियामकों और वाहन निर्माताओं ने निदान और सेवा को आसान बनाने (उदाहरण के लिए, ओबीडी-द्वितीय पोर्ट), सुरक्षा में सुधार (उदाहरण के लिए, टीपीएमएस), और ईंधन अर्थव्यवस्था लक्ष्यों को पूरा करने के लिए इलेक्ट्रॉनिक्स की ओर रुख किया। . कनेक्टिविटी की निम्नलिखित लहर ने ड्राइवर सुविधा सुविधाएँ जैसे रिमोट कीलेस एंट्री, टेलीमैटिक्स सिस्टम और ब्लूटूथ, वाई-फाई और स्मार्टफोन प्रोजेक्शन जैसी उन्नत इंफोटेनमेंट सुविधाएँ पेश कीं। आज, एकीकृत सेंसर और कनेक्टिविटी (उदाहरण के लिए, जीपीएस) सुरक्षा और अर्ध-स्वायत्त ड्राइविंग सिस्टम का समर्थन करते हैं।

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

निर्माताओं को क्षेत्र में किसी उत्पाद की निरंतर सुरक्षा और संरक्षा स्थिति सुनिश्चित करने के लिए एक सक्रिय दृष्टिकोण अपनाना चाहिए। संक्षेप में, निर्माताओं को उत्पाद में ज्ञात सुरक्षा कमजोरियों के बारे में पता होना चाहिए और उन्हें संबोधित करने के लिए जोखिम-आधारित दृष्टिकोण अपनाना चाहिए।

दीर्घकालिक सुरक्षा सुनिश्चित करें

एक कनेक्टेड वाहन में अक्सर एक या अधिक इलेक्ट्रॉनिक नियंत्रण इकाइयाँ (ECU) होती हैं जिनमें कई सॉफ़्टवेयर घटक जैसे OS, लाइब्रेरी, उपयोगिताएँ आदि शामिल होते हैं। निर्माताओं को ऐसे घटकों को ट्रैक करना चाहिए और सक्रिय विश्लेषण के साथ ज्ञात प्रकाशित कमजोरियों की पहचान करनी चाहिए, जिनमें शामिल हैं:

• सामान्य कमज़ोरियाँ और एक्सपोज़र (सीवीई) डेटाबेस के आधार पर उत्पाद का नियमित मूल्यांकन करना।
• उत्पाद-संबंधी सुरक्षा खामियों के लिए खुफिया जानकारी जुटाना।
• सुरक्षा परीक्षण.
• Android सुरक्षा बुलेटिनों का सक्रिय रूप से विश्लेषण करना।

उदाहरण ओएस और सुरक्षा पैच अपडेट (एंड्रॉइड चलाने वाले आईवीआई):

चित्र 1. वाहन के जीवनकाल में प्रमुख ओएस और सुरक्षा अद्यतन रोलआउट का नमूना।

सुरक्षा सर्वोत्तम प्रथाएँ

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

सुरक्षा दिशानिर्देश

सुरक्षा के लिए अनुशंसित प्रथाओं में शामिल हैं:

• बाहरी पुस्तकालयों और मुक्त स्रोत घटकों के नवीनतम संस्करणों का उपयोग करें।
• OS के रिलीज़ संस्करणों में दखल देने वाली डिबग कार्यक्षमता शामिल न करें।
• अप्रयुक्त कार्यक्षमता को हटाएं (अनावश्यक हमले की सतह को कम करने के लिए)।
• न्यूनतम विशेषाधिकार सिद्धांत और अन्य एंड्रॉइड ऐप विकास सर्वोत्तम प्रथाओं का उपयोग करें।

सॉफ्टवेयर विकास दिशानिर्देश

सिस्टम के जीवनचक्र के लिए सुरक्षित सॉफ़्टवेयर विकास के लिए अनुशंसित प्रथाओं में शामिल हैं:

• संपत्तियों, खतरों और संभावित शमन को रैंक करने और पहचानने के लिए खतरा मॉडलिंग करें।
• सुरक्षित और सुदृढ़ डिज़ाइन सुनिश्चित करने के लिए आर्किटेक्चर/डिज़ाइन समीक्षा करें।
• जितनी जल्दी हो सके एंटी-पैटर्न और बग की पहचान करने के लिए नियमित कोड समीक्षा करें।
• उच्च-कोड कवरेज इकाई परीक्षणों को डिज़ाइन, कार्यान्वित और चलाएं, जिनमें शामिल हैं:
  • कार्यात्मक परीक्षण (नकारात्मक परीक्षण मामलों सहित)
  • नियमित प्रतिगमन परीक्षण (यह सुनिश्चित करने के लिए कि निश्चित बग दोबारा सामने न आएं)
  • फ़ज़ परीक्षण (यूनिट परीक्षण सूट के भाग के रूप में)
• संभावित समस्याओं की पहचान करने के लिए स्थिर स्रोत कोड विश्लेषण उपकरण (स्कैन-बिल्ड, लिंट, आदि) का उपयोग करें।
• सिस्टम विकास के दौरान संभावित समस्याओं की पहचान करने और उन्हें कम करने के लिए डायनामिक सोर्स कोड विश्लेषण टूल, जैसे एड्रेससैनिटाइज़र, अनडिफ़ाइंडबिहेवियरसैनिटाइज़र, और FORTIFY_SOURCE (मूल घटकों के लिए) का उपयोग करें।
• सॉफ़्टवेयर स्रोत कोड और रिलीज़ कॉन्फ़िगरेशन/संस्करण के लिए एक प्रबंधन रणनीति रखें।
• सॉफ़्टवेयर पैच के निर्माण और परिनियोजन के लिए एक पैच प्रबंधन रणनीति रखें।

सुरक्षा बैकपोर्ट नीति

Google वर्तमान में एपीआई स्तर की सार्वजनिक रिलीज़ से तीन (3) वर्षों के लिए खोजी गई और रिपोर्ट की गई सुरक्षा कमजोरियों के सुरक्षा बैकपोर्ट के लिए सक्रिय समर्थन प्रदान करता है। सक्रिय समर्थन में निम्नलिखित शामिल हैं:

1. भेद्यता रिपोर्ट प्राप्त करें और उसकी जांच करें।
2. सुरक्षा अद्यतन बनाएं, परीक्षण करें और जारी करें।
3. सुरक्षा अद्यतन और सुरक्षा बुलेटिन विवरण की आवर्ती रिलीज़ प्रदान करें।
4. स्थापित दिशानिर्देशों के अनुसार गंभीरता का मूल्यांकन करें।

एपीआई स्तर की सार्वजनिक रिलीज़ तिथि से तीन साल बाद, Google निम्नलिखित दिशानिर्देशों की अनुशंसा करता है:

• एपीआई रिलीज से तीन साल से अधिक पुराने ओएस सुरक्षा अपडेट के लिए बैकपोर्ट समर्थन के लिए तीसरे पक्ष (जैसे एसओसी विक्रेता या कर्नेल प्रदाता) का उपयोग करें।
• सार्वजनिक रूप से उपलब्ध कराए गए एएसबी का उपयोग करके कोड समीक्षा करने के लिए तीसरे पक्ष का उपयोग करें। जबकि एएसबी वर्तमान में समर्थित संस्करण के लिए कमजोरियों की पहचान करते हैं, एक निर्माता पिछले संस्करणों के साथ नए जारी किए गए अपडेट की तुलना करने के लिए प्रदान की गई जानकारी का उपयोग कर सकता है। इस डेटा का उपयोग प्रभाव विश्लेषण करने और एपीआई रिलीज से तीन साल से अधिक पुराने ओएस संस्करणों के लिए संभावित रूप से समान पैच उत्पन्न करने के लिए किया जा सकता है।
• उपयुक्त होने पर, एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) पर सुरक्षा अपडेट अपलोड करें।
• निर्माता को विक्रेता-विशिष्ट कोड (उदाहरण के लिए, मालिकाना डिवाइस-विशिष्ट कोड) के लिए सुरक्षा अद्यतनों के प्रबंधन का समन्वय करना चाहिए।
• निर्माता को एनडीए एंड्रॉइड सुरक्षा बुलेटिन पार्टनर पूर्वावलोकन अधिसूचना समूह में शामिल होना चाहिए (डेवलपर एनडीए जैसे कानूनी समझौतों पर हस्ताक्षर करने की आवश्यकता है)। बुलेटिन में शामिल होना चाहिए:
  • घोषणाएं
  • सीवीई और गंभीरता सहित पैच स्तर के अनुसार मुद्दों का सारांश
  • जहां उपयुक्त हो वहां भेद्यता विवरण

अतिरिक्त संदर्भ

सुरक्षित कोडिंग और सॉफ़्टवेयर विकास प्रथाओं पर निर्देशों के लिए, निम्नलिखित देखें:

• मोटर उद्योग सॉफ्टवेयर विश्वसनीयता एसोसिएशन (MISRA) ।
• सॉफ्टवेयर इंजीनियरिंग संस्थान (एसईआई) उपकरण और तरीके ।
• राष्ट्रीय मानक एवं प्रौद्योगिकी संस्थान (एनआईएसटी)।

अनुशंसित उत्पाद प्रथाएँ

Google निम्नलिखित अनुशंसित प्रथाओं के उपयोग को प्रोत्साहित करता है।

सामान्य लॉन्च दिशानिर्देश

आम तौर पर यह अनुशंसा की जाती है कि किसी भी जुड़े उत्पाद को नवीनतम ओएस संस्करण के साथ लॉन्च किया जाए, और निर्माता को उत्पाद लॉन्च करने से पहले नवीनतम ओएस संस्करण का उपयोग करने का प्रयास करना चाहिए। जबकि परीक्षण और सत्यापन से पहले स्थिरता लाने के लिए संस्करण को लॉक करना आवश्यक है, निर्माता को पुराने ओएस संस्करणों से प्राप्त उत्पाद स्थिरता को नए ओएस संस्करणों के साथ संतुलित करना होगा जिनमें कम ज्ञात सुरक्षा कमजोरियां और बढ़ी हुई सुरक्षा सुरक्षा है।

अनुशंसित दिशानिर्देशों में शामिल हैं:

• वाहन विकास प्रक्रिया में निहित लंबे विकास समय के कारण, निर्माताओं को OS संस्करण n-2 या पुराने के साथ लॉन्च करने की आवश्यकता हो सकती है।
• ओवर-द-एयर (OTA) अभियान के साथ प्रत्येक रिलीज़ किए गए Android OS संस्करण के लिए Android संगतता के अनुरूपता बनाए रखें।
• उत्पाद एंड्रॉइड फ़र्मवेयर-ओवर-द-एयर (FOTA) लागू करें - तेज़, ग्राहक-अनुकूल अपडेट के लिए सक्षम। FOTA को सुरक्षा सर्वोत्तम प्रथाओं जैसे कोड हस्ताक्षर और उत्पाद और आईटी बैकऑफ़िस के बीच टीएलएस कनेक्शन का उपयोग करके किया जाना चाहिए।
• स्वतंत्र रूप से पहचानी गई Android सुरक्षा कमजोरियों को Android सुरक्षा टीम को सबमिट करें ।

नोट: Google ने Android सुरक्षा बुलेटिन में डिवाइस प्रकार या उद्योग-विशिष्ट सूचनाओं पर विचार किया है। हालाँकि, क्योंकि Google किसी दिए गए डिवाइस (वाहन, टीवी, पहनने योग्य, फोन, आदि) के लिए कर्नेल, ड्राइवर या चिपसेट को नहीं जानता है, इसलिए Google के पास किसी दिए गए सुरक्षा मुद्दे को डिवाइस प्रकार के साथ लेबल करने का कोई नियतात्मक तरीका नहीं है। .

उत्पाद चक्र दिशानिर्देश

निर्माता को उत्पाद चक्र संवर्द्धन के दौरान उपयोग में आने वाले संस्करण के लिए नवीनतम ओएस संस्करण या सुरक्षा अद्यतन का उपयोग करने का हर संभव प्रयास करना चाहिए। अद्यतन आवर्ती आवधिक उत्पाद अद्यतनों के दौरान, या गुणवत्ता और/या अन्य समस्याओं के समाधान के लिए हॉटफ़िक्स के लिए किए जा सकते हैं। अनुशंसित प्रथाओं में शामिल हैं:

• ड्राइवर, कर्नेल और प्रोटोकॉल अपडेट को संबोधित करने के लिए एक योजना बनाएं।
• तैनात वाहनों को अद्यतन प्रदान करने के लिए एक उद्योग उपयुक्त पद्धति का उपयोग करें।

संगतता परिभाषा दस्तावेज़ (सीडीडी)

संगतता परिभाषा दस्तावेज़ (सीडीडी) किसी डिवाइस को एंड्रॉइड-संगत मानने के लिए आवश्यकताओं का वर्णन करता है। सीडीडी सार्वजनिक है और सभी के लिए उपलब्ध है; आप एंड्रॉइड 1.6 से नवीनतम संस्करण तक सीडीडी संस्करण source.android.com से डाउनलोड कर सकते हैं।

किसी उत्पाद के लिए इन आवश्यकताओं को पूरा करने में निम्नलिखित बुनियादी चरण शामिल हैं:

1. पार्टनर Google के साथ Android संगतता प्रतिबद्धता (ACC) पर हस्ताक्षर करता है। फिर एक तकनीकी समाधान सलाहकार (टीएससी) को मार्गदर्शक के रूप में नियुक्त किया जाता है।
2. पार्टनर ने उत्पाद के एंड्रॉइड ओएस संस्करण के लिए सीडीडी समीक्षा पूरी कर ली है।
3. पार्टनर सीटीएस परिणाम चलाता है और सबमिट करता है (नीचे वर्णित है) जब तक परिणाम एंड्रॉइड संगतता के लिए स्वीकार्य नहीं हो जाते।

संगतता परीक्षण सूट (सीटीएस)

संगतता परीक्षण सूट (सीटीएस) परीक्षण उपकरण सत्यापित करता है कि उत्पाद कार्यान्वयन एंड्रॉइड-संगत है और इसमें नवीनतम सुरक्षा पैच शामिल हैं। सीटीएस सार्वजनिक, खुला स्रोत और सभी के लिए उपलब्ध है; आप एंड्रॉइड 1.6 से नवीनतम संस्करण तक सीटीएस संस्करण source.android.com से डाउनलोड कर सकते हैं।

जनता के लिए जारी किए गए एंड्रॉइड सॉफ़्टवेयर के प्रत्येक निर्माण (फ़ैक्टरी-इंस्टॉल और फ़ील्ड-अपडेट छवियां) को सीटीएस परिणामों के माध्यम से एंड्रॉइड संगतता साबित करनी होगी। उदाहरण के लिए, यदि डिवाइस एंड्रॉइड 7.1 चलाता है, तो रिलीज-इंटेंट बिल्ड छवि बनाते और परीक्षण करते समय सीडीडी 7.1 और सीटीएस 7.1 के नवीनतम संबंधित संस्करण को संदर्भित किया जाना चाहिए। निर्माताओं को मुद्दों की पहचान करने और उनका समाधान करने के लिए जल्दी और बार-बार सीटीएस का उपयोग करने के लिए दृढ़ता से प्रोत्साहित किया जाता है।

सीटीएस वर्कफ़्लो

सीटीएस वर्कफ़्लो में परीक्षण वातावरण स्थापित करना, परीक्षण चलाना, परिणामों की व्याख्या करना और सीटीएस स्रोत कोड को समझना शामिल है। निम्नलिखित दिशानिर्देशों का उद्देश्य सीटीएस उपयोगकर्ताओं (उदाहरण के लिए, डेवलपर्स, निर्माताओं) को सीटीएस का प्रभावी और कुशलता से उपयोग करने में मदद करना है।

• बार-बार परीक्षण चलाएँ . सीटीएस को एक स्वचालित उपकरण के रूप में डिज़ाइन किया गया है जो आपके बिल्ड सिस्टम में एकीकृत होता है। सीटीएस को बार-बार चलाने से आपको सॉफ़्टवेयर में गिरावट या प्रतिगमन होने पर दोषों को जल्दी और जल्दी ढूंढने में मदद मिल सकती है।
• सीटीएस स्रोत कोड डाउनलोड करें और जांचें । पूर्ण सीटीएस स्रोत कोड खुला स्रोत सॉफ़्टवेयर है जिसे कोई भी डाउनलोड और उपयोग कर सकता है (डाउनलोड किया गया स्रोत कोड पूरी तरह से निर्माण योग्य और चलाने योग्य है)। जब डिवाइस पर कोई परीक्षण विफल हो जाता है, तो स्रोत कोड के संबंधित अनुभाग की जांच करने से आपको इसका कारण पहचानने में मदद मिल सकती है।
• नवीनतम सीटीएस प्राप्त करें । नए एंड्रॉइड रिलीज़ बग फिक्स, सुधार और नए परीक्षणों के साथ सीटीएस को अपडेट कर सकते हैं। सीटीएस डाउनलोड बार-बार जांचें और आवश्यकतानुसार अपने सीटीएस कार्यक्रम को अपडेट करें। निर्माता और Google उत्पाद लॉन्च के लिए सीटीएस संस्करण को पारित करने पर सहमत होंगे क्योंकि सीटीएस के ताज़ा होने के दौरान उत्पाद को किसी बिंदु पर फ़्रीज़ किया जाना चाहिए।

सीटीएस पास करें

एंड्रॉइड संगत उत्पाद के लिए, Google सुनिश्चित करता है कि डिवाइस की सीटीएस और सीटीएस सत्यापनकर्ता रिपोर्ट परीक्षण परिणाम स्वीकार्य हैं। सिद्धांत रूप में, सभी परीक्षण उत्तीर्ण होने चाहिए। हालाँकि, एक परीक्षण जो डिवाइस के एंड्रॉइड संगतता आवश्यकताओं के अनुपालन में नहीं होने के अलावा अन्य कारणों से विफल हो जाता है, Google द्वारा समीक्षा के अधीन है। इस प्रक्रिया के दौरान:

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

यदि सुरक्षा पैच लगाने के बाद सीटीएस परीक्षण अचानक विफल हो रहा है, तो निर्माता को पैच को संशोधित करना होगा ताकि संगतता भंग न हो या यह दिखाए कि परीक्षण गलत है और परीक्षण के लिए एक समाधान प्रदान करें (जैसा कि ऊपर वर्णित है)।

सीटीएस परीक्षण सुधारों की समीक्षा के लिए खुला रहता है। उदाहरण के लिए, Android 4.4 सुधारों को स्वीकार करना जारी रखता है ( https://android-review.googlesource.com/#/c/273371/ देखें)।

अक्सर पूछे जाने वाले प्रश्न (एफएक्यू)

प्रश्न: एंड्रॉइड के विशिष्ट कार्यान्वयन में सुरक्षा अद्यतन लागू करने के लिए कौन जिम्मेदार है?

उत्तर: सीधे तौर पर उपकरण उपलब्ध कराने वाला निर्माता जिम्मेदार है। यह इकाई Google नहीं है, जो AOSP में सुरक्षा अपडेट प्रकाशित करती है, न कि किसी विशिष्ट डिवाइस (जैसे वाहन) के लिए।

प्रश्न: Google एंड्रॉइड में सुरक्षा समस्याओं को कैसे संभालता है?

उ: Google लगातार समस्याओं की जांच करता है और संभावित समाधान विकसित करता है, जिसे Google नियमित सुरक्षा अद्यतन प्रक्रिया के हिस्से के रूप में सभी समर्थित एपीआई स्तरों पर उपलब्ध कराता है। अगस्त 2015 से, Google ने source.android.com पर अपडेट के लिए बुलेटिन और लिंक प्रकाशित करने का नियमित क्रम बनाए रखा है; Google प्रमुख OS रिलीज़ के भाग के रूप में सुरक्षा अद्यतन भी प्रकाशित करता है। सुरक्षा बैकपोर्ट नीति भी देखें।

प्रश्न: यदि कोई निर्माता एएसबी से सभी एओएसपी पैच को एकीकृत करता है लेकिन उसी बुलेटिन में उल्लिखित बीएसपी विक्रेता से पैच को एकीकृत नहीं करता है, तो क्या यह अभी भी सुरक्षा स्तर बढ़ा सकता है (उदाहरण के लिए, प्लेटफॉर्म/बिल्ड पर संबंधित पैच लागू करें) ?

उ: एंड्रॉइड सुरक्षा पैच स्तर (एसपीएल) घोषित करने के लिए, निर्माता को एंड्रॉइड सुरक्षा बुलेटिन ( पूर्व बुलेटिन सहित ) में प्रकाशित और एक विशेष एंड्रॉइड एसपीएल पर मैप किए गए सभी आवश्यक मुद्दों को संबोधित करना होगा। उदाहरण के लिए, मार्च 2017 सुरक्षा बुलेटिन (2017-03-01 एसपीएल) का उपयोग करने वाले एक निर्माता ने उस एसपीएल के लिए मार्च 2017 बुलेटिन में दर्ज सभी आवश्यक मुद्दों और सभी पूर्व एंड्रॉइड सुरक्षा बुलेटिन के लिए डिवाइस-विशिष्ट अपडेट सहित सभी पूर्व अपडेट को संबोधित किया है। 2017-02-05 एसपीएल से जुड़े डिवाइस-विशिष्ट अपडेट।

प्रश्न: क्या होता है जब निर्माता बीएसपी विक्रेता द्वारा प्रदान किए गए सुरक्षा अद्यतनों से सहमत नहीं होता है या जब एएसबी द्वारा अनिवार्य सुरक्षा अद्यतन विक्रेताओं द्वारा प्रदान नहीं किए जाते हैं?

ए: एएसबी सुरक्षा कमजोरियों का वर्णन करता है (सीवीई की सूची द्वारा गिना जाता है) और अक्सर मिलान सुरक्षा परीक्षण प्रदान करता है। लक्ष्य यह सुनिश्चित करना है कि सूचीबद्ध कमजोरियाँ अब किसी डिवाइस पर पुन: उत्पन्न नहीं की जा सकें और डिवाइस संबंधित सुरक्षा परीक्षण पास कर सके। इस प्रकार, मुद्दा Google या किसी तृतीय-पक्ष विक्रेता द्वारा प्रदान किए गए सुरक्षा अद्यतन को लेने के बारे में नहीं है, बल्कि निर्माता द्वारा यह प्रमाणित करने के बारे में है कि डिवाइस ASB में CVEs की सूची के प्रति असुरक्षित नहीं है। निर्माता दिए गए सुरक्षा अद्यतनों का उपयोग करने के लिए स्वतंत्र है या, यदि उनके पास कोई परिवर्तन है जो उनके डिवाइस के लिए अधिक उपयुक्त है, तो इसके बजाय उस परिवर्तन का उपयोग करें।

उदाहरण के लिए, ऐसे मामले पर विचार करें जिसमें Google एक कोड परिवर्तन का उपयोग करके AOSP सुरक्षा भेद्यता को संबोधित करता है जो घटक को पूरी तरह कार्यात्मक और सीडीडी के अनुरूप रहने की अनुमति देता है। यदि निर्माता यह निर्धारित करता है कि डिवाइस पर घटक की आवश्यकता नहीं है या सीडीडी (या संबंधित प्रमाणन परीक्षण) द्वारा अनिवार्य नहीं है, तो निर्माता भविष्य की सर्विसिंग आवश्यकताओं को कम करने और हमले की सतह को कम करने के लिए घटक को हटा सकता है। हालाँकि निर्माता ने दिए गए सुरक्षा अद्यतन का उपयोग नहीं किया, लेकिन यह सुनिश्चित किया कि डिवाइस सुरक्षा बुलेटिन में दर्ज सीवीई के प्रति असुरक्षित नहीं है। हालाँकि, अनुशंसित सुरक्षा अद्यतन से विचलित होकर, निर्माता समस्या को गलत तरीके से संबोधित करने, नई सुरक्षा कमजोरियाँ पेश करने, या अन्यथा अंतिम निर्माण की कार्यक्षमता को कम करने का जोखिम उठा रहा है।

जबकि हम यह सुनिश्चित करने के लिए सभी SoC भागीदारों के साथ काम करते हैं कि ASB में सभी समस्याओं का समाधान मौजूद है, हम अनुशंसा करते हैं कि निर्माता किसी डिवाइस के जीवनचक्र के लिए अपने SoC विक्रेताओं के साथ एक सर्विसिंग समझौता सुरक्षित करें। SoCs वांछित समय से पहले चिपसेट की सर्विसिंग बंद कर सकते हैं, इसलिए डिवाइस चिपसेट चयन से पहले समझौते स्थापित करना डिवाइस लॉन्च प्रक्रिया का एक महत्वपूर्ण हिस्सा है।

अंत में, ऐसे मामलों में जहां एएसबी में दर्ज किसी समस्या के लिए सीधे तौर पर अधिग्रहण करना या स्वतंत्र रूप से फिक्स बनाना असंभव है, निर्माता पूर्व एंड्रॉइड एसपीएल को बनाए रख सकता है और फिर भी बिल्ड में नए उपलब्ध फिक्स जोड़ सकता है। हालाँकि, यह अभ्यास अंततः बिल्ड प्रमाणन के साथ समस्याओं को जन्म देगा (क्योंकि एंड्रॉइड सुनिश्चित करता है कि नवीनतम सुरक्षा पैच स्तर प्रमाणित उपकरणों पर उपलब्ध है)। Google इस प्रथा से बचने के लिए आपके SoC के साथ पहले से काम करने की अनुशंसा करता है।

प्रश्न: यदि निर्माता यह निर्धारित करता है कि एएसबी आइटम उनके उत्पाद के लिए लागू नहीं है, तो क्या अन्य Google आवश्यकताओं को पूरा करने या सीटीएस पास करने के लिए आइटम को अभी भी लागू करने या पैच करने की आवश्यकता है?

उत्तर: एंड्रॉइड सुरक्षा पैच स्तर (एसपीएल) घोषित करने के लिए हमें पैच लेने की आवश्यकता नहीं है; हमें यह आवश्यक है कि निर्माता प्रमाणित करे कि उनका निर्माण समस्या के प्रति संवेदनशील नहीं है।

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

यह मौलिक रूप से उस निर्माता से भिन्न है जो उदाहरण के लिए, केवल महत्वपूर्ण पैच को ठीक करना चाहता है, जबकि अन्य लागू पैच नहीं लेता है जिससे सुरक्षा परीक्षण विफल हो सकता है। इस मामले में माना जाता है कि एसपीएल पूरा नहीं हुआ है।