Power Apps के साथ सुरक्षित रूप से Microsoft SQL Server का उपयोग करें
कनेक्ट के लिए अलग-अलग तरीके हैं और Power Apps के साथ SQL सर्वर को प्रमाणित करें. यह लेख उन अवधारणाओं को रेखांकित करता है जो आपके ऐप के लिए आवश्यकताओं से मेल खाती सुरक्षा दृष्टिकोण के साथ SQL सर्वर से कनेक्ट करने के तरीके के बारे में विकल्प बनाने में सहायक हो सकती हैं.
महत्वपूर्ण
सुरक्षित निहित कनेक्शन सुविधा जनवरी 2024 में जारी की गई थी। · माइक्रोसॉफ्ट वर्तमान में इंप्लिसिट कनेक्शन का उपयोग करने वाले सभी एप्स को सुरक्षित इंप्लिसिट कनेक्शन में परिवर्तित करने और अंतिम उपयोगकर्ताओं के साथ साझा किए गए कनेक्शन को रद्द करने के लिए दृढ़ता से प्रोत्साहित करता है।
स्पष्ट, अंतर्निहित और सुरक्षित अंतर्निहित कनेक्शन के बीच अंतर
जब भी आप SQL सर्वर से कनेक्ट होने वाले Power Apps का उपयोग करके ऐप बनाते हैं तो SQL सर्वर का कनेक्शन बनाया जाता है. जब ऐसे ऐप्स प्रकाशित किए जाते हैं और दूसरों के साथ साझा किए जाते हैं, तो ऐप और कनेक्शन दोनों उन उपयोगकर्ताओं के लिए तैनात किए जाते हैं. दूसरे शब्दों में, ऐप और कनेक्शन—दोनों उपयोगकर्ताओं को ऐप्स के साथ साझा किए गए दिखाई देते हैं.
ऐसे कनेक्शनों के लिए उपयोग की जाने वाली प्रमाणीकरण विधि स्पष्ट या अंतर्निहित हो सकती है. हम यह भी कह सकते हैं कि इस तरह के कनेक्शन को स्पष्ट रूप से या परोक्ष रूप से साझा किया जाता है.
- एक स्पष्ट रूप से साझा कनेक्शन का मतलब है कि आवेदन के अंतिम उपयोगकर्ता को अपनी स्पष्ट क्रेडेंशियल्स के साथ SQL सर्वर को प्रमाणित करना होगा. आमतौर पर यह प्रमाणीकरण विंडोज प्रमाणीकरण हैंडशेक के भाग के रूप में पर्दे के पीछे होता है। Microsoft Entra जब प्रमाणीकरण होता है तो उपयोगकर्ता ध्यान भी नहीं देता है.
- एक परोक्ष रूप से साझा कनेक्शन का मतलब है कि उपयोगकर्ता स्पष्ट रूप से उस खाते के क्रेडेंशियल्स का उपयोग करता है जिसे ऐप निर्माता ऐप बनाते समय डेटा स्रोत से कनेक्ट और प्रमाणित करने के लिए उपयोग करता था. अंतिम उपयोगकर्ता का क्रेडेंशियल्स प्रमाणित करने के लिए उपयोग की जाने वाली नहीं हैं. हर बार जब अंतिम उपयोगकर्ता ऐप चलाता है, तो वे उस क्रेडेंशियल्स का उपयोग कर रहे हैं जो लेखक ने ऐप के साथ बनाया था.
- सुरक्षित निहित रूप से साझा कनेक्शन एक परिदृश्य को संदर्भित करता है जहां ऐप का अंतिम उपयोगकर्ता निहित रूप से उस खाते के क्रेडेंशियल्स का उपयोग करता है जिसका उपयोग ऐप निर्माता ने ऐप बनाते समय डेटा स्रोत से कनेक्ट और प्रमाणित करने के लिए किया था। इसका अर्थ यह है कि प्रमाणीकरण के लिए अंतिम उपयोगकर्ता के स्वयं के क्रेडेंशियल का उपयोग नहीं किया जाता है। इसके बजाय, जब उपयोगकर्ता ऐप चलाता है, तो वह उन क्रेडेंशियल्स का उपयोग कर रहा होता है जिनके साथ ऐप के लेखक ने इसे बनाया था। यह ध्यान रखना महत्वपूर्ण है कि अंतिम उपयोगकर्ता को कनेक्शन तक सीधी पहुंच प्रदान नहीं की जाती है, और ऐप केवल सीमित क्रियाओं और तालिकाओं तक ही पहुंच की अनुमति देता है।
Power Apps के लिए SQL सर्वर के साथ निम्नलिखित चार कनेक्शन प्रमाणीकरण प्रकारों का उपयोग किया जा सकता है:
| प्रमाणीकरण प्रकार | Power Apps कनेक्शन विधि |
|---|---|
| Microsoft Entra एकीकृत | एक्सप्लिसिट |
| SQL Server प्रमाणीकरण | निहित / सुरक्षित निहित |
| Windows प्रमाणीकरण | निहित / सुरक्षित निहित |
| Windows प्रमाणीकरण (गैर-साझा) | एक्सप्लिसिट |
अंतर्निहित कनेक्शन साझा करने के जोखिम
सभी नए अनुप्रयोग स्वचालित रूप से नए सुरक्षित अंतर्निहित कनेक्शन का उपयोग करते हैं। हालाँकि, पुराने 'अंतर्निहित कनेक्शन' का उपयोग करने वाले ऐप्स के साथ, ऐप और उसके कनेक्शन दोनों को अंतिम उपयोगकर्ताओं के लिए तैनात किया जाता है, इसका मतलब है कि अंतिम उपयोगकर्ता उन कनेक्शनों के आधार पर नए एप्लिकेशन लिख सकते हैं। ·
जब कोई लेखक सुरक्षित अंतर्निहित कनेक्शन का उपयोग करता है, तो इसका मतलब है कि कोई भी कनेक्शन साझा नहीं किया जाता है और कोई भी अंतिम उपयोगकर्ता कनेक्शन ऑब्जेक्ट प्राप्त नहीं करता है। इससे अंतिम-उपयोगकर्ता लेखक द्वारा नया ऐप बनाने के लिए कनेक्शन का पुनः उपयोग करने का जोखिम समाप्त हो जाता है। इसके बजाय, ऐप एक प्रॉक्सी कनेक्शन के साथ काम करता है जो ऐप के बारे में जानता है और केवल उस विशिष्ट ऐप के साथ संचार करता है। प्रॉक्सी कनेक्शन सीमित क्रियाएं (बनाएं, पढ़ें, अपडेट करें, हटाएं) और ऐप में विशिष्ट तालिकाओं तक पहुंच की अनुमति देता है जिन्हें ऐप प्रकाशित होने पर परिभाषित किया जाता है। इसलिए, अंतिम उपयोगकर्ता को केवल अधिकृत कार्य और पहुंच ही प्रदान की जाती है।
पुरानी शैली का सरल अंतर्निहित कनेक्शन वास्तव में अंतिम उपयोगकर्ता को एक कनेक्शन ऑब्जेक्ट वितरित करता है। उदाहरण के लिए, यदि आप ऐसा ऐप बनाते हैं जो उस डेटा को फ़िल्टर कर देता है जिसे आप नहीं चाहते कि उपयोगकर्ता देखें. लेकिन, फ़िल्टर किया गया डेटा डेटाबेस में मौजूद है। लेकिन आप यह सुनिश्चित करने के लिए आपके द्वारा कॉन्फ़िगर किए गए फ़िल्टर पर भरोसा कर रहे हैं कि अंतिम उपयोगकर्ता कुछ डेटा नहीं देखेंगे.
पुनः, पुरानी शैली के सरल अंतर्निहित कनेक्शनों के साथ, आपके द्वारा ऐप को तैनात करने के बाद, अंतिम उपयोगकर्ता आपके ऐप के साथ तैनात कनेक्शन का उपयोग उनके द्वारा बनाए गए किसी भी नए ऐप में कर सकते हैं। नए ऐप्स में उपयोगकर्ता आपके एप्लीकेशन में फ़िल्टर किए गए डेटा को देख सकते हैं. नए सुरक्षित अंतर्निहित कनेक्शन का उपयोग करना महत्वपूर्ण है।
महत्वपूर्ण
एक बार जब कोई पुराना अंतर्निहित साझा कनेक्शन अंतिम उपयोगकर्ताओं के लिए तैनात कर दिया जाता है, तो आपके द्वारा साझा किए गए ऐप में लगाए गए प्रतिबंध (जैसे कि फ़िल्टर या केवल पढ़ने के लिए पहुँच) अब अंतिम उपयोगकर्ताओं द्वारा बनाए गए नए ऐप के लिए मान्य नहीं होते हैं। अंत उपयोगकर्ताओं के पास जो भी अधिकार होंगे, प्रमाणीकरण परोक्ष रूप से साझा कनेक्शन के हिस्से के रूप में अनुमति देता है. इसलिए, जब आप किसी ऐप को सुरक्षित निहित कनेक्शन का उपयोग करने के लिए परिवर्तित करते हैं, तो आपको अपने ऐप के साथ साझा किए गए कनेक्शन को भी रद्द करना होगा। · व्यवस्थापक COE टूलकिट के साथ अंतर्निहित रूप से साझा कनेक्शन वाले ऐप्स की रिपोर्ट प्राप्त कर सकते हैं।
ग्राहक और सर्वर सुरक्षा
आप सुरक्षित होने के लिए फ़िल्टरिंग या अन्य क्लाइंट-साइड ऑपरेशंस के माध्यम से डेटा की सुरक्षा पर भरोसा नहीं कर सकते हैं. डेटा के सुरक्षित फ़िल्टरिंग की आवश्यकता वाले अनुप्रयोगों को यह सुनिश्चित करना चाहिए कि उपयोगकर्ता पहचान और फ़िल्टरिंग दोनों सर्वर पर होते हैं.
जब उपयोगकर्ता की पहचान और सुरक्षा की बात आती है तो ऐप्स के भीतर डिज़ाइन किए गए फ़िल्टर पर निर्भर रहने के बजाय आईडी जैसी सेवाओं का उपयोग करें। Microsoft Entra यह कॉन्फ़िगरेशन सर्वर-साइड फ़िल्टर अपेक्षा के अनुसार काम सुनिश्चित करता है.
निम्नलिखित चित्र बताते हैं कि ऐप्स के भीतर सुरक्षा पैटर्न क्लाइंट-साइड और सर्वर-साइड सुरक्षा मॉडल के बीच कैसे भिन्न होते हैं.
एक ग्राहक सुरक्षा ऐप पैटर्न में, [1] उपयोगकर्ता केवल ग्राहक पक्ष पर आवेदन करने के लिए प्रमाणित करता है. फिर [2] एप्लिकेशन सेवा की जानकारी का अनुरोध करता है, और [3] सेवा केवल डेटा अनुरोध के आधार पर जानकारी देता है.
एक सर्वर-साइड सुरक्षा पैटर्न में, [1] उपयोगकर्ता पहले सेवा को प्रमाणित करता है ताकि उपयोगकर्ता को सेवा के लिए जाना जाता है. फिर, [2] जब आवेदन से कॉल किया जाता है, तो सेवा [3] डेटा को उचित रूप से फ़िल्टर करने के लिए वर्तमान उपयोगकर्ता की ज्ञात पहचान का उपयोग करती है और [4] डेटा लौटाती है.
ऊपर वर्णित अंतर्निहित विभागीय साझा परिदृश्य इन दो पैटर्न का संयोजन है. उपयोगकर्ता को क्रेडेंशियल का उपयोग करके सेवा में लॉग इन करना होगा। Power Apps Microsoft Entra यह व्यवहार सर्वर सुरक्षा ऐप पैटर्न है. उपयोगकर्ता को सेवा पर मौजूद पहचान का उपयोग करके जाना जाता है। Microsoft Entra इसलिए, ऐप उन उपयोगकर्ताओं के सेट तक सीमित है जिस पर Power Apps ने औपचारिक रूप से आवेदन साझा किया है.
हालांकि, SQL सर्वर के लिए अंतर्निहित साझा कनेक्शन ग्राहक सुरक्षा ऐप पैटर्न है. SQL सर्वर केवल जानता है कि एक विशिष्ट उपयोगकर्ता नाम और पासवर्ड का उपयोग किया जाता है. उदाहरण के लिए, किसी भी क्लाइंट-साइड फ़िल्टरिंग को एक ही उपयोगकर्ता नाम और पासवर्ड का उपयोग करके एक नए अनुप्रयोग के साथ दरकिनार किया जा सकता है.
सर्वर की ओर से डेटा को सुरक्षित रूप से फ़िल्टर करने के लिए, SQL सर्वर में अंतर्निहित सुरक्षा सुविधाओं जैसे पंक्ति स्तर सुरक्षा पंक्तियों के लिए, और इनकार विशिष्ट उपयोगकर्ताओं के लिए अनुमतियां (जैसे कॉलम). यह दृष्टिकोण सर्वर पर डेटा को फ़िल्टर करने के लिए उपयोगकर्ता पहचान का उपयोग करता है। Microsoft Entra
कुछ मौजूदा कॉर्पोरेट सेवाओं ने एक दृष्टिकोण का उपयोग किया है जहां उपयोगकर्ता पहचान को व्यवसाय डेटा परत में उसी तरह से कैप्चर किया जाता है जैसा कि Microsoft Dataverse करता है. इस मामले में, व्यवसाय परत SQL सर्वर की पंक्ति स्तर सुरक्षा का उपयोग कर सकती है या नहीं कर सकती है और सुविधाओं को सीधे अस्वीकार कर सकती है. यदि ऐसा नहीं होता है, तो अक्सर यह मामला होता है कि संग्रहीत प्रक्रियाओं या व्यू का उपयोग करके सुरक्षा सक्षम की जाती है.
व्यवसाय लेयर (सर्वर साइड पर) एक ज्ञात उपयोगकर्ता Microsoft Entra पहचान का उपयोग SQL सर्वर प्रिंसिपल के रूप में संग्रहीत प्रक्रिया को लागू करने और डेटा को फ़िल्टर करने के लिए करता है। हालांकि, Power Apps वर्तमान में संग्रहित प्रक्रियाओं से कनेक्ट नहीं होता है. एक व्यवसाय लेयर एक दृश्य को भी आमंत्रित कर सकता है जो Microsoft Entra पहचान को SQL सर्वर प्रिंसिपल के रूप में उपयोग करता है। इस मामले में, व्यू से कनेक्ट करने के लिए Power Apps का उपयोग करें ताकि डेटा सर्वर-साइड पर फ़िल्टर किया जा सके. उपयोगकर्ताओं के लिए केवल विचारों को उजागर करने के लिए अपडेट के लिए Power Automate प्रवाह की आवश्यकता हो सकती है.