हमें विधि स्तर सुरक्षा की आवश्यकता क्यों है?

14

वास्तविक दुनिया में, हमें विधि स्तर की सुरक्षा को लागू करने की आवश्यकता क्यों है?

हमारे पास एक वेब एप्लिकेशन या एक डेस्कटॉप एप्लिकेशन है, जहां उपयोगकर्ता उपयोगकर्ता इंटरफ़ेस तक पहुंचता है (और इसलिए सीधे विधि तक नहीं पहुंच सकता है)।

तो कहाँ पहुँच तरीकों सीधे तस्वीर में यहाँ आता है?

संपादित करें: मैं यह सवाल पूछता हूं क्योंकि मैं वसंत सुरक्षा के साथ प्रयोग कर रहा हूं, और मैं उपयोगकर्ताओं तक पहुंचने के तरीकों के लिए अधिकृत करता हूं।

कुछ इस तरह :

 @ROLE_ADMIN
public void update() {
      //update
}

security

— विनोथ कुमार सी.एम.
स्रोत

1. सुरक्षा मुद्दों के बारे में सोचने के बिना कोड का पुन: उपयोग करने के लिए 2. एक वेब सेवा के साथ आसानी से एकीकृत करने के लिए 3. सुरक्षा के बारे में सुनिश्चित करने के लिए जब आप ऊपरी परतों के सुरक्षा तंत्र पर भरोसा नहीं करते हैं

— एरकन एरोल

23

ठीक से डिज़ाइन किए गए एप्लिकेशन में बैकएंड और फ्रंटेंड डिस्कनेक्ट हो गए हैं। बैकएंड सुरक्षा प्रणाली किसी भी विशिष्ट दृश्य को सही ढंग से सुरक्षा को संभाल नहीं सकती है, इसलिए इसे स्वयं ही संभालना होगा।

— jwenting
स्रोत

आपने इस प्रश्न का उत्तर नहीं दिया: विधि का स्तर क्यों?

— कोडिज्म

@ समाजवाद - उन्होंने इसका जवाब दिया। B / c आप कुछ भी नहीं मान सकते हैं। आप विधि स्तर b / c पर प्राधिकरण जांच करते हैं कि कोई भी व्यक्ति कैसे मिला, आपको यह सुनिश्चित करने की आवश्यकता है कि उनके पास उचित अधिकार हैं।

— जोसेफ वासना

@JosephLust: उत्तर और आपकी टिप्पणी किसी भी सुरक्षा प्रणाली पर किसी भी अलग स्तर पर लागू की जा सकती है। मूल प्रश्न विशेष रूप से पूछ रहा था कि पद्धति के स्तर पर क्यों।

— कोडिज्म

1

क्योंकि यह AOP या AspectJ का उपयोग करते हुए आसानी से उपलब्ध न्यूनतम स्तर और आसानी से लागू किया गया है। मेरा मानना है कि यह अन्य सभी सुरक्षा कार्यान्वयनों पर लागू होता है।

— जोसेफ वासना

5

मुझे लगता है कि आप एक नियंत्रक में कार्यों के लिए भूमिका आधारित पहुंच के बारे में बात कर रहे हैं। एक MVC आर्किटेक्चर में Ie प्रत्येक विधि एक Controllerवर्ग पर एक अलग कार्रवाई है। अधिकांश MVC फ्रेमवर्क मैंने उपयोग किए हैं जो मुझे विधि स्तर और वर्ग स्तर दोनों पर विशेषाधिकार निर्दिष्ट करने की अनुमति देते हैं। इसका मतलब है कि मैं कक्षा स्तर पर एक विशेषता / एनोटेशन लागू कर सकता हूं और उस नियंत्रक में प्रत्येक क्रिया के लिए संबंधित भूमिका की आवश्यकता होगी।

भूमिका आधारित पहुंच के लिए अधिक महीन दानेदार नियंत्रण के संबंध में इस पर विचार करें:

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

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

— बेरिन लोरिट्श
स्रोत

3

विधि स्तर की सुरक्षा दो मुख्य कारणों के लिए उपयोगी है:

सुरक्षा की एक और परत के रूप में (अन्य परतों के अलावा)
ऐसे मामलों में जहां विधि के स्तर में अनुमतियाँ रखना अधिक सुविधाजनक या तार्किक है, ऐसे मामले पर विचार करें जहां विभिन्न उपयोगकर्ता समान "प्रत्यक्ष" क्रियाएं कर सकें (इसलिए क्लाइंट सुरक्षा प्रासंगिक नहीं है)। लेकिन कुछ मामलों में उनकी कार्रवाई एक व्यवहार को ट्रिगर कर सकती है जिसे आप सीमित करना चाहते हैं - इस मामले में विधि स्तर की सुरक्षा एक प्रासंगिक समाधान हो सकती है।

— ओफिर योकतन
स्रोत

0

माइक वेसनर ने इस स्प्रिंगस्रोस प्रेजेंटेशन में याद दिलाया, इंट्रोडक्शन टू स्प्रिंग सिक्योरिटी 3 / 3.1 , टॉमकैट और कई अन्य सर्वलेट कंटेनरों में एक उदाहरण था, जो यूनिकोड में एनकोड किए जाने पर "../" को ठीक से पहचानने में विफल रहा। एक साधारण बराबरी का परीक्षण जावा में विफल हो जाएगा, लेकिन फाइलसिस्टम में ऊपरी निर्देशिका में अनुवाद होगा।

सुरक्षा कठिन है, सुरक्षा के कई स्तर, परिधि के प्रयासों को अवरुद्ध करने के अवसरों में सुधार करेंगे। चूंकि विधि स्तर की सुरक्षा को सीधे वर्ग के अंदर कोडित किया जाता है, एओपी वृद्धि के बाद, जब आप विधि को कॉल करते हैं, तो आप हमेशा सुरक्षा जांच को कॉल करेंगे।

— stivlo
स्रोत

-2

मुझे लगता है कि आप यहाँ सार्वजनिक, निजी और संरक्षित तरीकों के बारे में बात कर रहे हैं?

यदि ऐसा है, तो वे सुरक्षा के उद्देश्य के लिए मौजूद नहीं हैं। वे यह आसान ओ गारंटी बनाने के उद्देश्य से मौजूद हैं कि सॉफ्टवेयर ठीक से संचालित है। (क्या वे इसमें सफल होते हैं कि एक बहस मैं दूसरों के लिए छोड़ दूंगा। यह, हालांकि, जो वे हैं उसके लिए दृष्टि।)

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

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

— btilly
स्रोत

2

आपको यह नहीं मिला, वह सार्वजनिक, निजी और संरक्षित के बारे में बात नहीं कर रहा है, लेकिन यह जांचने के बारे में है कि क्या उपयोगकर्ता की AOP के साथ कोई भूमिका है या नहीं

— stivlo