सिस्टम की सुरक्षा के सबसे सही तरीके

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

इस सेक्शन में, मुख्य Android ऑपरेटिंग सिस्टम और डिवाइसों की सुरक्षा को पक्का करने के लिए सुझाव दिए गए हैं.

बायोमेट्रिक ऑथेंटिकेशन

उपयोगकर्ता की पहचान की पुष्टि करने के लिए, बायोमेट्रिक डेटा को ध्यान से इकट्ठा, सेव, और प्रोसेस करें. आपको यह करना चाहिए:

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

बायोमेट्रिक्स की सुविधा वाले डिवाइसों पर, BiometricPrompt API काम करना चाहिए. इससे ऐप्लिकेशन डेवलपर को एक जैसा और एक जैसा इंटरफ़ेस मिलता है, ताकि वे अपने ऐप्लिकेशन में बायोमेट्रिक्स पर आधारित पुष्टि की सुविधा का फ़ायदा ले सकें. सिर्फ़ बेहतर बायोमेट्रिक्स को BiometricPrompt के साथ इंटिग्रेट किया जा सकता है. साथ ही, इंटिग्रेशन के लिए Android के साथ काम करने की शर्तों के बारे में बताने वाले दस्तावेज़ (सीडीडी) के दिशा-निर्देशों का पालन करना ज़रूरी है.

बायोमेट्रिक से जुड़े ज़्यादा दिशा-निर्देश पाने के लिए, बायोमेट्रिक एचएएल लागू करने के लिए दिशा-निर्देश देखें.

SELinux

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

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

SELinux नीति को डाइनैमिक तरीके से लोड करना

Android डिवाइसों पर, SELinux नीति को डाइनैमिक तौर पर लोड न करें. ऐसा करने से, ये समस्याएं हो सकती हैं:

• सुरक्षा से जुड़े अहम पैच को स्वीकार न करना.
• नीतियां फिर से लोड करके, डिवाइस को रूट करने की सुविधा देना.
• नीति अपडेट करने वाले टूल के ख़िलाफ़ मैन इन द मिडल अटैक के लिए वेक्टर को एक्सपोज़ करना.
• नीति के अपडेट में गड़बड़ियों की वजह से, डिवाइसों को ठीक नहीं किया जा सका.

बैकडोर

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

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

डेवलपमेंट टूल

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

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

जानकारी ज़ाहिर करने और सहमति लेने की सुविधा लागू करते समय, यहां दिए गए कुछ और सुझाव देखें:

ऐप्लिकेशन में जानकारी ज़ाहिर करना

• ऐप्लिकेशन के सामान्य इस्तेमाल की जानकारी सीधे ऐप्लिकेशन में दिखाएं. उपयोगकर्ता को इसके लिए, मेन्यू या सेटिंग में जाने की ज़रूरत नहीं पड़नी चाहिए.
• यह बताएं कि किस तरह का डेटा इकट्ठा किया जा रहा है और उसका इस्तेमाल कैसे किया जाता है.
• आम तौर पर, इस जानकारी को निजता नीति या सेवा की शर्तों में एम्बेड न करें. इसे ऐसी दूसरी जानकारी में शामिल न करें जो निजी या संवेदनशील डेटा इकट्ठा करने से जुड़ी नहीं है.

सहमति का अनुरोध

• सहमति ज़रूर होनी चाहिए. जहां जानकारी दी गई है वहां से कहीं और जाने को, ऐप्लिकेशन इस्तेमाल करने वाले व्यक्ति की सहमति नहीं समझा जाना चाहिए. इसमें टैप करके बाहर जाना या वापस जाने के लिए बैक या होम बटन दबाना शामिल है.
• सहमति वाला डायलॉग साफ़ और सीधे तौर पर पेश करें.
• स्वीकार करने के लिए, उपयोगकर्ता से कोई कार्रवाई करने के लिए कहें. जैसे, स्वीकार करने के लिए टैप करना या कोई निर्देश बोलना.
• सहमति मिलने से पहले, निजी या संवेदनशील डेटा इकट्ठा न करें.
• अपने-आप खारिज या खत्म होने वाले मैसेज का इस्तेमाल न करें.

AOSP में एम्बेड की गई सुविधा

AOSP में अतिरिक्त सुविधाएं जोड़ने पर, अक्सर अनचाहा व्यवहार और नतीजे मिल सकते हैं. इसलिए, सावधानी से आगे बढ़ें.

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

सुरक्षा से जुड़े अपडेट

Android डिवाइसों को लॉन्च होने के बाद, कम से कम दो साल तक सुरक्षा से जुड़ी सहायता मिलती रहनी चाहिए. इसमें समय-समय पर मिलने वाले ऐसे अपडेट शामिल हैं जिनसे, सुरक्षा से जुड़ी उन समस्याओं को ठीक किया जाता है जिनके बारे में पहले से पता होता है.

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

डाइनैमिक कर्नेल अपडेट

सिस्टम के अहम कॉम्पोनेंट में डाइनैमिक तौर पर बदलाव न करें. कुछ रिसर्च से पता चलता है कि डाइनैमिक कर्नेल अपडेट, आपातकालीन खतरों से बचाने में मदद करते हैं. हालांकि, फ़िलहाल इसके फ़ायदों के मुकाबले, इसकी लागत ज़्यादा है. इसके बजाय, ओटीए अपडेट का एक बेहतर तरीका बनाएं, ताकि कमज़ोरियों से जुड़ी सुरक्षा को तुरंत डिस्ट्रिब्यूट किया जा सके.

कुंजी मैनेजमेंट

साइनिंग पासकोड की सुरक्षा को पक्का करने के लिए, पासकोड मैनेज करने की अच्छी नीतियों और तरीकों का पालन करें.

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

सिस्टम इमेज पर हस्ताक्षर करना

डिवाइस इंटिग्रिटी का पता लगाने के लिए, सिस्टम इमेज का हस्ताक्षर ज़रूरी है.

• सार्वजनिक तौर पर उपलब्ध कुंजी का इस्तेमाल करके, डिवाइसों पर हस्ताक्षर न करें.
• संवेदनशील कुंजियों को मैनेज करने के लिए, इंडस्ट्री के स्टैंडर्ड के मुताबिक डिवाइस-साइनिंग कुंजियों को मैनेज करें. इनमें हार्डवेयर सुरक्षा मॉड्यूल (एचएसएम) भी शामिल है, जो सीमित और ऑडिट किया जा सकने वाला ऐक्सेस देता है.

अनलॉक किए जा सकने वाले बूटलोडर

कई Android डिवाइसों को अनलॉक किया जा सकता है. इससे डिवाइस के मालिक को सिस्टम के partition में बदलाव करने या पसंद के मुताबिक ऑपरेटिंग सिस्टम इंस्टॉल करने की सुविधा मिलती है. आम तौर पर, डिवाइस पर किसी तीसरे पक्ष की सिस्टम इमेज को इंस्टॉल करने और सिस्टम-लेवल पर डेवलपमेंट करने के लिए, इस सुविधा का इस्तेमाल किया जाता है. उदाहरण के लिए, Google Nexus या Pixel पर सिस्टम इमेज को अनलॉक करने के लिए, उपयोगकर्ता fastboot oem unlock चला सकता है. इससे यह मैसेज दिखता है:

सबसे सही तरीके के तौर पर, अनलॉक किए जा सकने वाले Android डिवाइसों को अनलॉक करने से पहले, उनमें से उपयोगकर्ता का सारा डेटा सुरक्षित तरीके से मिटा दिया जाना चाहिए. अनलॉक करने पर, सभी डेटा को ठीक से मिटाने से, पास में मौजूद हमलावर को Android डिवाइस के उपयोगकर्ता के गोपनीय डेटा का ऐक्सेस मिल सकता है. उपयोगकर्ता के डेटा को ज़ाहिर होने से बचाने के लिए, अनलॉक करने की सुविधा वाले डिवाइस को इसे सही तरीके से लागू करना होगा.

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

इन ज़रूरी शर्तों से यह पक्का होता है कि डिवाइस को अनलॉक करने के बाद, उसका सारा डेटा मिट जाए. इन सुरक्षा उपायों को लागू न करने पर, इसे मध्यम लेवल की सुरक्षा से जुड़ी समस्या माना जाता है.

अनलॉक किए गए डिवाइस को फिर से लॉक करने के लिए, fastboot oem lock निर्देश का इस्तेमाल किया जा सकता है. बूटलोडर को लॉक करने से, डिवाइस के मैन्युफ़ैक्चरर के ओरिजनल ऑपरेटिंग सिस्टम की तरह ही, नए कस्टम ऑपरेटिंग सिस्टम में भी उपयोगकर्ता के डेटा की सुरक्षा की जाती है. उदाहरण के लिए, डिवाइस को फिर से अनलॉक करने पर, उपयोगकर्ता का डेटा मिट जाता है.

डिवाइस की पेनटेस्टिंग

डिवाइसों को शिप करने से पहले, किसी पेशेवर पेनटेस्टर की समीक्षा करानी चाहिए. पेनटेस्टिंग से यह पता चलना चाहिए कि डिवाइस ने यहां दिए गए सुरक्षा दिशा-निर्देशों के साथ-साथ, OEM के सुरक्षा दिशा-निर्देशों का पालन किया है या नहीं.

सुरक्षा जांच

AOSP के सुरक्षा जांच के लिए उपलब्ध टूल का इस्तेमाल करें. खास तौर पर

• डेवलपमेंट के दौरान, मेमोरी की सुरक्षा से जुड़े टूल का इस्तेमाल करें: जहां काम करता है वहां MTE का इस्तेमाल करें (ARMv9 और उसके बाद के वर्शन). इसके अलावा, जहां काम नहीं करता वहां HWASan का इस्तेमाल करें. इन टूल को चालू करके, ज़्यादा से ज़्यादा टेस्ट चलाएं.
• मेमोरी की सुरक्षा से जुड़ी समस्याओं का पता लगाने के लिए, प्रोडक्शन में GWP-ASan और KFENCE का इस्तेमाल करें.