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

इस अनुभाग में मुख्य एंड्रॉइड ऑपरेटिंग सिस्टम और उपकरणों की सुरक्षा सुनिश्चित करने के लिए सिफारिशें शामिल हैं।

बॉयोमीट्रिक प्रमाणीकरण

उपयोगकर्ता प्रमाणीकरण के लिए बायोमेट्रिक डेटा सावधानीपूर्वक प्राप्त करें, संग्रहीत करें और संसाधित करें। तुम्हे करना चाहिए:

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

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

अधिक बायोमेट्रिक दिशानिर्देशों के लिए, बायोमेट्रिक एचएएल कार्यान्वयन दिशानिर्देश देखें।

SELinux

SELinux एंड्रॉइड के अधिकांश सुरक्षा मॉडल की परिभाषा और प्रवर्तन प्रदान करता है। SELinux का सही ढंग से उपयोग करना Android उपकरणों की सुरक्षा के लिए महत्वपूर्ण है और सुरक्षा कमजोरियों के प्रभाव को कम करने में मदद कर सकता है। इस कारण से सभी Android उपकरणों को एक मजबूत SELinux नीति लागू करनी चाहिए।

• न्यूनतम विशेषाधिकार नीति लागू करें.
• CAP_DAC_OVERRIDE , CAP_SYS_ADMIN और CAP_NET_ADMIN अनुमतियाँ देने से बचें।
• सिस्टम डेटा को एसडी कार्ड में लॉग न करें।
• ड्राइवर एक्सेस के लिए दिए गए प्रकारों का उपयोग करें, जैसे gpu_device , audio_device , आदि।
• प्रक्रियाओं, फ़ाइलों और SELinux प्रकारों के लिए सार्थक नामों का उपयोग करें।
  • सुनिश्चित करें कि डिफ़ॉल्ट लेबल का उपयोग नहीं किया जाता है और उन तक पहुंच प्रदान नहीं की जाती है।
• डिवाइस-विशिष्ट नीति को किसी डिवाइस पर चलने वाली समग्र नीति का 5-10% हिस्सा होना चाहिए। 20%+ रेंज में अनुकूलन में लगभग निश्चित रूप से अति-विशेषाधिकार प्राप्त डोमेन और मृत नीति शामिल होती है। अनावश्यक रूप से बड़ी नीति मेमोरी को बर्बाद करती है, बड़ी बूट छवि की आवश्यकता के कारण डिस्क स्थान को बर्बाद करती है, और रनटाइम नीति लुकअप समय को नकारात्मक रूप से प्रभावित करती है।

SELinux नीति की गतिशील लोडिंग

Android उपकरणों पर SELinux नीति को गतिशील रूप से लोड न करें। ऐसा करने से समस्याएँ उत्पन्न हो सकती हैं, जैसे:

• महत्वपूर्ण सुरक्षा पैच की स्वीकृति को रोकना।
• नीतियों को पुनः लोड करके किसी डिवाइस को रूट करने की क्षमता को उजागर करना।
• पॉलिसी अपडेटर के विरुद्ध मैन-इन-द-मिडिल हमलों के लिए एक वेक्टर को उजागर करना।
• नीति अद्यतनों में त्रुटियों के कारण डिवाइस खराब हो गए।

backdoors

एंड्रॉइड ऐप्स में सिस्टम या डेटा तक पहुंचने के लिए कोई पिछला दरवाजा या रास्ता नहीं होना चाहिए जो सामान्य सुरक्षा तंत्र को बायपास करता हो। इसमें डायग्नोस्टिक्स, डिबगिंग, विकास, या वारंटी मरम्मत विशेष पहुंच शामिल है जो डेवलपर को ज्ञात रहस्यों द्वारा प्राप्त होती है। पिछले दरवाज़ों को रोकने के लिए:

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

विकास उपकरण

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

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

प्रकटीकरण और सहमति को लागू करते समय संदर्भित करने के लिए यहां कुछ अतिरिक्त सुझाव दिए गए हैं:

इन-ऐप प्रकटीकरण

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

सहमति के लिए अनुरोध

• सहमति सकारात्मक होनी चाहिए. नेविगेशन को प्रकटीकरण से दूर न समझें, जिसमें दूर टैप करना या बैक या होम बटन दबाना भी सहमति के रूप में शामिल है।
• सहमति संवाद को स्पष्ट और सुस्पष्ट तरीके से प्रस्तुत करें।
• सकारात्मक उपयोगकर्ता कार्रवाई की आवश्यकता है, जैसे किसी आदेश को स्वीकार करने के लिए टैप करना या स्वीकार करने के लिए बोलना।
• सकारात्मक सहमति प्राप्त करने से पहले व्यक्तिगत या संवेदनशील डेटा एकत्र न करें।
• स्वत: खारिज करने या समाप्त होने वाले संदेशों का उपयोग न करें।

AOSP में एंबेडेड कार्यक्षमता

AOSP में अतिरिक्त कार्यक्षमता एम्बेड करने से अक्सर अप्रत्याशित व्यवहार और परिणाम हो सकते हैं; सावधानी के साथ आगे बढ़ना।

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

सुरक्षा अद्यतन

एंड्रॉइड डिवाइस को लॉन्च से कम से कम दो साल तक निरंतर सुरक्षा सहायता मिलनी चाहिए। इसमें नियमित अपडेट प्राप्त करना शामिल है जो ज्ञात सुरक्षा कमजोरियों का समाधान करता है।

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

गतिशील कर्नेल अद्यतन

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

महतवपूर्ण प्रबंधन

हस्ताक्षरित कुंजियों की सुरक्षा सुनिश्चित करने के लिए अच्छी कुंजी प्रबंधन नीतियों और प्रथाओं को बनाए रखें।

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

सिस्टम छवि हस्ताक्षर

डिवाइस की अखंडता निर्धारित करने के लिए सिस्टम छवि का हस्ताक्षर महत्वपूर्ण है।

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

अनलॉक करने योग्य बूटलोडर

कई एंड्रॉइड डिवाइस अनलॉकिंग का समर्थन करते हैं, जिससे डिवाइस मालिक सिस्टम विभाजन को संशोधित करने या कस्टम ऑपरेटिंग सिस्टम स्थापित करने में सक्षम होता है। सामान्य उपयोग के मामलों में तृतीय-पक्ष सिस्टम छवि स्थापित करना और डिवाइस पर सिस्टम-स्तरीय विकास करना शामिल है। उदाहरण के लिए, Google Nexus या Pixel पर सिस्टम छवि को अनलॉक करने के लिए, उपयोगकर्ता fastboot oem unlock चला सकता है, जो यह संदेश प्रदर्शित करता है:

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

• उपयोगकर्ता द्वारा अनलॉकिंग कमांड की पुष्टि करने के बाद, डिवाइस को तत्काल डेटा वाइप शुरू करना होगा। सुरक्षित विलोपन पूरा होने तक unlocked फ़्लैग को सेट नहीं किया जाना चाहिए।
• यदि सुरक्षित विलोपन पूरा नहीं किया जा सकता है, तो डिवाइस को लॉक स्थिति में रहना चाहिए।
• यदि अंतर्निहित ब्लॉक डिवाइस द्वारा समर्थित है, ioctl(BLKSECDISCARD) या समकक्ष का उपयोग किया जाना चाहिए। एम्बेडेड मल्टीमीडियाकार्ड (ईएमएमसी) उपकरणों के लिए, इसका मतलब सिक्योर इरेज़ या सिक्योर ट्रिम कमांड का उपयोग करना है। ईएमएमसी 4.5 और बाद के संस्करण के लिए, इसका अर्थ है सामान्य इरेज़ या ट्रिम का उपयोग करना और उसके बाद सैनिटाइज़ ऑपरेशन करना।
• यदि BLKSECDISCARD अंतर्निहित ब्लॉक डिवाइस द्वारा समर्थित नहीं है, तो इसके बजाय ioctl(BLKDISCARD) उपयोग किया जाना चाहिए। ईएमएमसी उपकरणों पर, यह एक सामान्य ट्रिम ऑपरेशन है।
• यदि BLKDISCARD समर्थित नहीं है, तो सभी शून्यों के साथ ब्लॉक डिवाइस को ओवरराइट करना स्वीकार्य है।
• उपयोगकर्ता के पास यह विकल्प होना चाहिए कि विभाजन को फ्लैश करने से पहले उपयोगकर्ता डेटा को मिटा दिया जाए। उदाहरण के लिए, नेक्सस डिवाइस उपयोगकर्ता डेटा को मिटाने के लिए fastboot oem lock कमांड का उपयोग करते हैं।
• एक उपकरण ईफ़्यूज़ या समान तंत्र के माध्यम से रिकॉर्ड कर सकता है, चाहे कोई उपकरण अनलॉक किया गया हो और/या पुनः लॉक किया गया हो। हालाँकि, हम दृढ़ता से अनुशंसा करते हैं कि बूटलोडर को बाद के फ़ैक्टरी रीसेट के साथ फिर से लॉक करने से पूर्ण डिवाइस कार्यक्षमता बहाल होनी चाहिए।

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

एक डिवाइस जिसे अनलॉक किया गया है उसे बाद में fastboot oem lock कमांड का उपयोग करके पुनः लॉक किया जा सकता है। बूटलोडर को लॉक करने से नए कस्टम ओएस के साथ उपयोगकर्ता डेटा की वही सुरक्षा मिलती है जो मूल डिवाइस निर्माता ओएस के साथ उपलब्ध थी (उदाहरण के लिए यदि डिवाइस को दोबारा अनलॉक किया जाता है तो उपयोगकर्ता डेटा मिटा दिया जाएगा)।

डिवाइस का परीक्षण

शिपमेंट से पहले उपकरणों की एक सक्षम पेंटेस्टर द्वारा समीक्षा की जानी चाहिए। पेन्टेस्टिंग को यह स्थापित करना चाहिए कि डिवाइस ने यहां दिए गए सुरक्षा मार्गदर्शन के साथ-साथ आंतरिक ओईएम सुरक्षा मार्गदर्शन का पालन किया है।

सुरक्षा परीक्षण

AOSP द्वारा उपलब्ध कराए गए सुरक्षा परीक्षण टूल का उपयोग करें। विशेष रूप से

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