क्या मुझे उन स्तंभों को स्पष्ट रूप से अद्यतन करना चाहिए जिन्हें अद्यतन नहीं किया जाना चाहिए?

25

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

उदाहरण के लिए:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

मान सेट होने के बाद इन दो कॉलमों को कभी नहीं बदलना चाहिए। इसलिए मैं स्पष्ट रूप DENYसे UPDATEउन पर अनुमति देना चाहूंगा ।

हाल ही में, एक टीम मीटिंग के दौरान एक डेवलपर ने यह मुद्दा उठाया कि यह सुनिश्चित करने के लिए कि फ़ील्ड्स को कभी भी अपडेट नहीं किया जाने वाला तर्क आवेदन परत के भीतर समाहित होना चाहिए न कि इस घटना में डेटाबेस लेयर कि "उन्हें किसी कारण से मान अपडेट करने की आवश्यकता है"। मेरे लिए जो विशिष्ट देव मानसिकता की तरह लगता है (मुझे पता है, मैं एक हुआ करता था!)

मैं अपनी कंपनी में सबसे वरिष्ठ वास्तुकार हूं और मैंने हमेशा ऐप को काम करने के लिए आवश्यक विशेषाधिकारों के सिद्धांत पर काम किया है। सभी अनुमतियों का नियमित रूप से ऑडिट किया जाता है।

इस परिदृश्य में सबसे अच्छा अभ्यास क्या है?

— Mr.Brownstone
स्रोत

टिप्पणियाँ संग्रहीत ।

— पॉल व्हाइट GoFundMonica कहते

28

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

यदि उन्हें पूरी तरह से अद्यतन करने की आवश्यकता है, तो वह स्पष्ट रूप से अप्रभावित व्यक्ति द्वारा किया जा सकता है DENY, या व्यक्ति को अस्थायी रूप से एक भूमिका में ले जाया जा सकता है जो अप्रभावित है, या DENYअस्थायी रूप से हटाया जा सकता है। ये ऐसी चीजें हैं जो आपके लिए आसान हैं, डीबीए के रूप में, चारों ओर ऑडिटिंग स्थापित करने के लिए। ऐप में? इतना नहीं।

— आरोन बर्ट्रेंड
स्रोत

16

मैं इसके तकनीकी पहलू पर @Aaron से पूरी तरह सहमत हूं।

सबसे अच्छी प्रथाओं के संबंध में मैं कहूंगा:

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

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

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

मैंने उस अंतिम भाग में डाला क्योंकि गलतफहमी, गलत सूचना और ज्ञान की कमी का एक उच्च स्तर है (यहां तक कि इस पृष्ठ पर भी कुछ सही है)। उदाहरण के लिए, यह धारणा है कि सभी नियम व्यावसायिक नियम हैं। हमें यह समझाने की ज़रूरत है कि डेटा नियमों और व्यावसायिक नियमों के बीच एक अंतर है (@Aaron ने इसे "वर्कफ़्लो बाधा के रूप में संदर्भित किया जाता है" प्रश्न पर एक टिप्पणी में डेटा बाधा) ", और यह कि जबकि अधिकांश डेटा स्वाभाविक रूप से अनुप्रयोग के हैं, कुछ डेटा वास्तव में डेटा मॉडल के अंतर्गत आता है। क्या डीबीए को डेवलपर्स को निर्देशित करना चाहिए कि एप्लिकेशन डेटा कैसे बाधित होगा ? बिलकूल नही। यह कैसे आवेदन डेटा तक की पेशकश करने के लिए हमारा काम है कर सकते हैंविवश होना। यदि एप्लिकेशन डेटा से संबंधित व्यावसायिक नियम का उल्लंघन नुकसान पहुंचा सकता है, और ऐप 100% केवल डेटा में हेरफेर करने का तरीका नहीं है, तो शायद एक चेक बाधा वास्तव में मदद कर सकती है (और वे बदलने या हटाने के लिए मुश्किल नहीं हैं )।

लेकिन, दूसरी दिशा से आने वाले, डेवलपर्स को यह निर्धारित नहीं करना चाहिए कि डेटा मॉडल डेटा (यानी मेटा-डेटा) कैसे संभाला जाता है। इसमें ऑडिट फ़ील्ड (जैसे created_on/ created_byकॉलम) और PK / FK कॉलम शामिल हैं (इन मानों को केवल आंतरिक रूप से जाना जाता है और ग्राहकों को नहीं दिया जाता है)। यह डेटा वह नहीं है जो ऐप ग्राहकों के बारे में संग्रहीत करता है (भले ही ऐप मूल्यों को देख सकता है और यहां तक कि उनका उपयोग भी कर सकता है, जैसे कि आईडी के साथ), यह वही है जो डेटा मॉडल ऐप के डेटा के बारे में संग्रहीत करता है।

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

इसलिए:

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

वर्षों बाद उन्होंने उस तर्क के लिए माफी मांगी; ;-)

— सोलोमन रुट्ज़की
स्रोत

7

यह शायद एक XY- समस्या है। डेवलपर शायद विशेष रूप से निरंतर क्षेत्र की तरह अद्यतन अवरुद्ध करने से चिंतित नहीं है created_on। यह विशेष उदाहरण एक अत्यंत मामूली बाधा है।

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

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

तो इन आशंकाओं को आत्मसात करने के लिए आपको कुछ चीजें करनी चाहिए:

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

— jpmc26
स्रोत

0

आपके पास परस्पर विरोधी कथन हैं

ऐसे कॉलम जिन्हें कभी भी अपडेट नहीं किया जाना चाहिए
उन्हें किसी कारण से मूल्यों को अपडेट करने की आवश्यकता है

क्या यह वास्तव में आप पर निर्भर करता है कि पहले को निर्देशित करें?

आप बिना प्रमाण के काम करने के लिए ऐप प्राप्त करने के लिए कम से कम विशेषाधिकार फेंक देते हैं, ऐप को कभी भी मूल्य अपडेट करने की आवश्यकता नहीं होगी।

डेटा अखंडता के लिए कौन जिम्मेदार है?

SQL बाधाओं के साथ आप डेटा अखंडता की गारंटी दे सकते हैं? नहीं, आप नहीं कर सकते क्योंकि अक्सर व्यापार नियम हैं जो एक डेटाबेस से आगे बढ़ सकते हैं।

वेंडर को कभी नहीं बदलना चाहिए लेकिन अगर दो विक्रेताओं का विलय होता है। नेवर से नेवर।

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

उपयुक्त सवाल यह है कि ऐप को कभी भी डेटा अपडेट करना चाहिए।

— paparazzo
स्रोत

3

के बारे में " यदि ऐप टीम डेटा को दूषित करती है और उन्होंने कहा कि उन्हें उस प्राधिकरण की आवश्यकता है तो यह उन पर है। " उम, क्या आपने कभी एक पेजर किया है और 2:00 पूर्वाह्न - 4:00 बजे जाग गया है क्योंकि कुछ गलत हुआ है? आप 2:00 बजे ऐप टीम को कॉल नहीं कर सकते और उन्हें अपनी समस्या को ठीक करने के लिए कह सकते हैं । यह डीबीए की समस्या है, क्योंकि ऐप टीम ए) को पता नहीं है कि क्या ठीक करना है, बी) इसे ठीक करना नहीं जानता है, और सी) के पास इसे ठीक करने के लिए डीबी की अनुमति नहीं है। और अंत में सामने आए सवाल के लिए, डेवलपर ने कभी नहीं कहा कि ऐप को डेटा को अपडेट करना चाहिए ; यह "शायद किसी दिन मैं चाह सकता था"।

@SolomonRutzky आपके साथ इस पर बहस करने वाला नहीं है। यदि इसे प्रलेखित किया जाता है तो जिम्मेदारी प्राधिकरण के पास जाती है। आपके साथ शब्द का खेल खेलने के लिए नहीं जा रहा है।

— paparazzo

2

मैं आपके साथ प्रिंसिपल पर सहमत हूं कि "जिम्मेदारी प्राधिकरण के साथ जाती है"। लेकिन यह एक महान कई लोगों के लिए वास्तविकता नहीं है। मैंने उन आदर्शों के लिए उन स्थानों पर तर्क दिया है जहां मैंने काम किया है। मैं शायद ही कभी ऐसा होता देखता हूं। इसके अलावा, यह एक तर्क नहीं है, यह एक चर्चा है।

— सोलोमन रटज़की

@SolomonRutzky जब तक यह एक ऐसा मुद्दा है जो डेटाबेस के हर अनुप्रयोग को किसी के अनुप्रयोग (या देव ऑप्स) से प्रभावित करता है टीम के पास समस्या को ठीक करने के लिए ज्ञान और अनुमति होनी चाहिए। ऐसा कोई कारण नहीं है कि डीबीए टीम उन मुद्दों के लिए जिम्मेदार होनी चाहिए जो आवेदन स्तर पर है और डेटाबेस स्तर पर नहीं है।

— जो डब्ल्यू

1

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

— सोलोमन रटज़की