न्यूनतम विशेषाधिकार का सिद्धांत

Not to be confused with Rule of least power.

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

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

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

एक और सीमा नियंत्रण की ग्रैन्युलैरिटी है जो ऑपरेटिंग वातावरण में एक व्यक्तिगत प्रक्रिया के लिए विशेषाधिकारों से अधिक है। व्यवहार में, स्मृति, प्रसंस्करण समय, I/O डिवाइस पते या मोड तक किसी प्रक्रिया की पहुंच को नियंत्रित करना शायद ही कभी संभव होता है, केवल विशेषाधिकारों के सटीक सेट को सुविधाजनक बनाने के लिए आवश्यक सटीकता के साथ एक प्रक्रिया की आवश्यकता होगी।

मूल सूत्रीकरण जेरोम एच। साल्टज़र से है:

Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.

— Jerome Saltzer, Communications of the ACM

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

विशेषाधिकारों के गतिशील समनुदेशन पर पहले 1972 में रोजर नीधम द्वारा चर्चा की गई थी। ऐतिहासिक रूप से, कम से कम विशेषाधिकार का सबसे पुराना उदाहरण शायद login.c का स्रोत कोड है, जो सुपर-उपयोगकर्ता अनुमतियों के साथ निष्पादन शुरू करता है और तत्काल वे अब जरूरी नहीं हैं- उन्हें गैर-शून्य तर्क के साथ setuid() के माध्यम से प्रदर्शित किया गया है। संस्करण 6 यूनिक्स में स्रोत कोड।

कार्यान्वयन

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

Intel x86 के लिए प्रिविलेज रिंग्स द्वारा प्रदर्शित कम से कम विशेषाधिकार का सिद्धांत

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

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

समान सिद्धांत

ट्रस्टेड कंप्यूटिंग बेस (टीसीबी) न्यूनीकरण की ट्रस्टेड कंप्यूटर सिस्टम इवैल्यूएशन क्राइटेरिया (टीसीएसईसी) अवधारणा कहीं अधिक कठोर आवश्यकता है जो केवल कार्यात्मक रूप से सबसे मजबूत आश्वासन वर्गों, अर्थात, बी3 और ए1 (जो स्पष्ट रूप से भिन्न लेकिन कार्यात्मक रूप से समान हैं) पर लागू होती है। .

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

यह भी देखें

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

ग्रन्थसूची

• Ben Mankin, The Formalisation of Protection Systems, Ph.D. thesis, University of Bath, 2004
• P. J. Denning (December 1976). "Fault tolerant operating systems". ACM Computing Surveys. 8 (4): 359–389. doi:10.1145/356678.356680. S2CID 207736773.
• Jerry H. Saltzer, Mike D. Schroeder (September 1975). "The protection of information in computer systems". Proceedings of the IEEE. 63 (9): 1278–1308. CiteSeerX 10.1.1.126.9257. doi:10.1109/PROC.1975.9939. S2CID 269166.
• Deitel, Harvey M. (1990). An introduction to operating systems (revisited first ed.). Addison-Wesley. p. 673. ISBN 978-0-201-14502-1. page 31.
• Sean Martin (April 2012). "Are security basics getting lost under the cover of cloud and mobile?". SC Magazine.
• SANS Institute (May 2013). "20 Critical Security Controls" (PDF). SANS Institute. Archived from the original (PDF) on 2013-11-01.

बाहरी संबंध

• Managing least privileges from the cloud by Monique Sendze
• The Saltzer and Schroeder paper cited in the references.
• NSA (the one that implemented SELinux) talks about the principle of least privilege
• A discussion of the implementation of the principle of least privilege in Solaris
• Tom's IT Pro: Most Organizations Unaware of Employees With Admin Rights
• "Proof that LUA makes you safer" by Dana Epp
• Applying the Principle of Least Privilege to User Accounts on Windows XP, by Microsoft
• "Commercial enterprises are putting our critical infrastructure at risk" CSO
• How to successfully implement the principle of least privilege