नमस्ते।
 हम क्लाउड कंप्यूटिंग(Cloud Computing) पर हमारी चर्चा जारी रखेंगे।
 आज हम क्लाउड सुरक्षा (cloud security) के कुछ पहलुओं के बारे में बात करेंगे बल्कि हम एक परिदृश्य को देखेंगे जहां यह सुरक्षा भूमिका निभाती है और विभिन्न पहलुओं क्या हैं।
 यह मुख्य रूप से सास(SaaS) के साथ सास(SaaS )क्लाउड(cloud) का सहयोग करने के लिए क्लाउड के प्रकार के साथ है।
 तो, हम यह देख रहे हैं, कि आप वर्तमान में या निकट भविष्य में थे कि इस तरह के क्लाउड एक-दूसरे के बीच संवाद करेंगे; इसका मतलब है, दूसरे अर्थ में की यह क्लाउड में अपना उपभोक्ता या विभिन्न हितधारकों(stakeholders) के पास अपना आवेदन रखने वाले अन्य क्लाउड में अन्य अनुप्रयोगों(applications) के साथ संवाद कर रहे हैं।
 इसलिए,दूसरे अर्थ में यह क्लाउड के अनुप्रयोग स्तर पर एक सहयोगी सास (SaaS) क्लाउड है।
 इसलिए,आज की चर्चा में हम एक-दूसरे के बीच सहयोग करते हैं तो हम अलग-अलग सुरक्षा पहलुओं को देखेंगे, हम देखेंगे कि यहाँ बहुत ही मुश्किल मुद्दे प्रयोग में आते हैं।
 तो,इस दृष्टिकोण में से एक यह है, कि यह मेरे पीएचडी विद्वान निनॉय घोष(Nirnoy Ghosh) में से एक का काम है, क्योंकि वह अपना काम वर्णन करेगे, लेकिन हम और अधिक व्यापक पहलुओं को देखेंगे कि चीजें कैसे होनी चाहिए।
 तो, आप में से कई लोगों के लिए यह अच्छा होगा जो कुछ प्रकार के शोध या चीजों के इन पहलुओं में कुछ और अध्ययन कर रहे हैं।
 तो, यह सहयोगी सास क्लाउड (SaaS cloud) में सुरक्षा समस्या है।
 तो, अगर आप क्लाउड कंप्यूटिंग में सुरक्षा समस्याओं को देखते हैं, तो यह बस पूर्वावालोकन करने के लिए है।
 इसलिए, जो इस क्लाउड के लिए आम तौर पर या अद्वितीय हैं, वह सह किरायेदारी (co tenancy) है।
 आवेदन की संख्या निवास कर रहे हैं या अलग उपयोगकर्ता एक ही भौतिक आधारभूत संरचना में रह रहे हैं।
 तो, सह किरायेदारी (co tenancy) एक प्रमुख मुद्दा है।
 और आउटसोर्स डेटा और आवेदकों पर नियंत्रण की कमी जो इस प्रकार के क्लाउड प्लेटफार्म की एक और आम तौर पर विशिष्टता है।
 इसलिए, हमने एक बार क्लाउड में अपना डेटा और एप्लिकेशन लोड या आउटसोर्स करने के बाद बंद कर दिया है, तो हमारे पास उन चीजों पर अधिक नियंत्रण नहीं है।
 या हमारे नियंत्रण प्रदाता द्वारा सही निर्णय लिया जाता है।
 जो कुछ भी मैं नियंत्रित कर सकता हूं या नियंत्रण के लिए जो भी हैंडलर हैं, मुख्य रूप से सेवा प्रदाता द्वारा तय किया जाता है।
 इसलिए, अन्य अर्थों में यदि हम इस सुरक्षा बिंदु को देखते हैं, तो यह एक बाधा है, कि मेरा डेटा और आपको सुरक्षित करने की आवश्यकता है।
 यह क्या है और यह बाहरी अन्य अनुप्रयोगों के संपर्क में कितना है और अन्य प्रकार के उपयोगकर्ता और उन सभी चीजें हैं।
 अपर्याप्त नीतियों और प्रथाओं जैसी अन्य सामान्य चिंताएं हैं, जो कि एक और चिंतित और अपर्याप्त सुरक्षा नियंत्रण है, जिसकी हम बात कर रहे हैं।
 इसलिए, ग्राहक अपने ग्राहकों की सेवा के लिए क्लाउड सेवाओं का उपयोग करते हैं।
 इसलिए, उन क्लाउड सेवाओं पर एप्लिकेशन चलाने के लिए ट्रस्ट रिश्तों (trust relationships) को सही स्थापित करने की आवश्यकता है।
 इसलिए, यह आवश्यक है, कि मैं इस सेवा प्रदाता पर कितना भरोसा करता हूं।
 इसलिए, इसके लिए एक बड़ी आवश्यकता है और यह ग्राहक और प्रदाता दोनों हितधारकों के लिए फायदेमंद हो सकता है।
 इसलिए, यह केवल प्रदाता ही नहीं है, जो कि ग्राहक प्रदाता पर भरोसा कैसे करता है।
 यह सवाल है, कि मैं कितना हूं यदि मैं सेवा क्लाउड सेवा प्रदाता हूं, यदि मेरे लिए ग्राहक या सेवाओं के उपभोक्ता भी भरोसा करते हैं।
 इसलिए, दुर्भावनापूर्ण ग्राहक नहीं होना चाहिए जो ऐसी चीजों से कोई समस्या पैदा करेगा जो हमेशा नहीं होता है।
 ऐसा नहीं है, क्योंकि क्लाउड सेवा प्रदाता उनका व्यवसाय सेवाएं बेच रहा है।
 इसलिए, वे दुर्भावनापूर्ण नहीं हो सकते हैं या उनके पास किसी भी दुर्भावनापूर्ण इरादे के बजाय कोई दुर्भावनापूर्ण नहीं हो सकता है।
 हालांकि, आप इस प्रक्रिया में यह कर सकते हैं कि आपके पास कुछ दुर्भावनापूर्ण ग्राहक हो सकते हैं, जो आम तौर पर परिदृश्य हैं।
 जो सेवाओं का या प्लेटफॉर्म का उपयोग अन्य डेटा और चीजों के प्रकार पर हमला करने या छेड़छाड़ करने के लिए करते हैं।
 इसलिए, यदि मैं यह एक चीज है जो इसमें उपलब्ध है, तो हमने एक विभिन्न साहित्य भी देखा है।
 अगर आप आईएएसएस (IaaS) के मामले में सुरक्षा जिम्मेदारियों को देखते हैं।
 तो, हाइपरवाइजर की ज़िम्मेदारी खत्म हो जाती है।
 जिसके बाद ऑपरेटिंग सिस्टमया अतिथि ऑपरेटिंग सिस्टम हो रहा है औरयह किरायेदार के पास जाता है।
 इसलिए, पाएएस(PaaS) क्लाउड प्रदाता की ज़िम्मेदारी के मामले में प्रदाताओं की हाइपरवाइजर की ज़िम्मेदारी उस प्लेटफॉर्म पर निर्भर है, या वे समाधान स्टैक थे।
 सास (SaaS) के मामले में यह जिम्मेदारी इंटरफ़ेस एप्लिकेशन इंटरफ़ेस तक जाती है।
 तो, यह चीजें हैं जैसे कि मैं प्रसंस्करण के लिए एक एपीआई (api) कह रहा हूं।
 इसलिए, यह उस स्तर तक है, जो प्रदाताओं के प्रयोग में आ रहा है।
 क्योंकि उपभोक्ता के लिए, यह उस स्तर के स्तर पर निर्भर करता है, कि सेवाएं इस सुरक्षा को प्रदाता द्वारा संभाली जाती हैं।
 इसलिए, हम देख सकते हैं, कि विभिन्न प्रकार के क्लाउड में हमारे पास विभिन्न प्रकार की सुरक्षा है।
 इसलिए, सास(SaaS) के मामले में बहुत सी चीजें हैं, जो प्रदाताओं के अंत पर निर्भर करती हैं।
 जैसे की मैं कह रहा हूं कि, प्रसंस्करण सेवा या किसी भी प्रकार की टेक्स्ट संपादन सेवा क्या है।
 इसलिए, जैसा कि मैं उस एपीआई (api) का उपयोग कर रहा हूं।
 तो, यह वही एप्लीकेशन स्तर है, जिसमें मेरे पास अलग-अलग उदाहरण हो सकते हैं ,जो विभिन्न प्रकार की चीजों के लिए काम कर रहे हैं।
 तो, सास क्लाउड (SaaS cloud) बेस सहयोग है।
 तो, हमारा व्यापक रूप से संसाधनों को साझा करने के लिए एपीआई (api) का मतलब है, और सूचना सेवा उपभोक्ता या ग्राहक मानव उपयोगकर्ता अनुप्रयोग संगठन डोमेन।
 और कोई भी सेवा प्रदाता क्लाउड विक्रेता सास क्लाउड (SaaS cloud) केंद्रित सहयोग है।
 इसलिए, वे कुछ आवश्यक चीजें हैं, जैसे डाटा शेयरिंग मुद्दों की समस्याओं को विभिन्न प्रकार के मुद्दों को संभालने के लिए मनुष्यों को अंतःविषय दृष्टिकोण की तरह संभाला जाता है।
 इसलिए, आम तौर पर संबंधित कई उपयोगकर्ताओं में साझा किए गए डेटा की अखंडता को चीजों से समझौता किया जा सकता है।
 चूंकि एक डेटा साझा किया जा रहा है या मूल मंच कई उपयोगकर्ताओं में साझा किया जाता है।
 तो, एक समझौता हो सकता है और समझौता होने का मौका हो सकता है।
 और मैं एक आदर्श विक्रेता या सेवा प्रदाता कैसे चुनूं यदि बड़ी संख्या में प्रदाता है, तो मैं प्रदाता कैसे चुनूं।
 इसलिए, जैसा कि मैंने यह भेजा है, यह मेरे पीएचडी छात्र में से एक का काम है।
 इस क्षेत्र में काम करने वाले डॉ निर्ने घोष ( Dr. Nirnay Ghosh )हैं।
 और हम वर्णन के लिए अपने काम का कुछ हिस्सा लेंगे और हम इस विशेष समस्या में उठाए गए चुनौतियों का सामना करेंगे।
 तो, उन चीजों को देखने के लिए अच्छा होगा।
 तो, बहु डोमेन (multi domain )या क्लाउड सिस्टम में सहयोग का प्रकार कसकर युग्मित (tightly coupled )या संघीय है, इसे देखने का एक तरीका हो सकता है।
 जहां इस प्रकार के संघीय क्लाउड के बीच मजबूत कनेक्टिविटी है या वे ढीले ढंग से युग्मित (loosely coupled) सिस्टम हैं।
 इसलिए, कि वे संघीय बादल हैं, लेकिन वे कमजोर युग्मित प्रणाली हैं।
 तो, मेरे पास एक ही क्लाउड में अलग-अलग क्लाउड के उदाहरण हो सकते हैं, लेकिन वे कमजोर युग्मित (loosely coupled) हैं।
 तो, वे बहुत दृढ़ता से युग्मित (tightly coupled) नहीं हैं।
 इसलिए, क्लाउड पर्यावरण में कमजोर युग्मित (loosely coupled) सहयोग को सुरक्षित करने में कई बदलाव हैं, और मुख्य रूप से कसकर युग्मित प्रणालियों के लिए सुरक्षा तंत्र प्रस्तावित हैं।
 तो, जो कमजोर युग्मित (loosely coupled )है, वहां बहुत अधिक सुरक्षा तंत्र नहीं हैं।
 इसलिए, जब भी आप सुरक्षा तंत्र की तलाश करते हैं, जैसा कि हम पहले चर्चा कर चुकें हैं, यह घटना में भेजता है।
 तो, हाथ में हाथ की आवश्यकता है।
 इसलिए, बदले में क्लाउड में मौजूदा प्रमाणीकरण प्राधिकरण तंत्र में अधिक कसकर युग्मित(tightly coupled) चीज़ प्रतिबंध होने की बात आती है, एक और समस्या यह है कि वर्तमान में क्लाउड में आपके द्वारा किए जा रहे प्रत्येक तंत्र का प्रकार उन गुप्त घटनाओं को प्रतिबंधित करने के लिए एक प्रतिबंधक जगह हो सकता है ।
 इसलिए, कई चुनौतियां हैं और जो प्रेरित करती हैं, या यदि आप दूसरी तरफ देखते हैं, तो ये इस क्षेत्र में अनुसंधान या अध्ययन करने की प्रेरणा हैं।
 जैसे सास क्लाउड डिलीवरी मॉडल (SaaS cloud delivery model), तो नियंत्रण की अधिकतम कमी है।
 तो, सेवा प्रदाता अंत पर पूरा नियंत्रण है और इसलिए इनके पास उपभोक्ता के अंत में नियंत्रण न्यूनतम है।
 कोई भी सक्रिय डेटा स्ट्रीम ऑडिट ट्रेल्स आउटेज रिपोर्ट सीधे चीजों के लिए उपलब्ध नहीं होती है, जो उपभोक्ता द्वारा प्रदान की जाने वाली चीज़ों को देखने की आवश्यकता होती है।
 तो, क्लाउड सेवाओं के उपयोग में प्रमुख चिंता; क्लाउड में इतना व्यापक दायरा पता सुरक्षा समस्याएं हमें संबोधित करने की आवश्यकता है।
 इसलिए, क्लाउड मार्केटप्लेस की एक अवधारणा हाल ही में प्रगति के कारण तेजी से बढ़ रही है।
 इसलिए, हमारे पास आम तौर पर क्लाउड मार्केट जगह है, जहां उपभोक्ताओं की संख्या में एक आर्थिक मॉडल है।
 मैं क्लाउड इकोनॉमिक्स के बारे में बात नहीं कर रहा हूं, इस बारे में बात कर रहा हूं कि आप बेहतर सेवाओं के लिए क्यों जाते हैं, जिससे न केवल सेवाओं की गुणवत्ता की गुणवत्ता बेहतर होती है।
 एसएलए (SLAs ) बेहतर सुरक्षा है।
 इसलिए, एकाधिक सेवा प्रदाता की उपलब्धता यह चुनने की एक बड़ी चुनौती है, कि कौन सा सेवा प्रदाता हमें इस तरह दिखने की आवश्यकता है।
 इसलिए, सेवा में असंगत है और कोई मानक खंड की गारंटी नहीं देता है।
 तो, एक आदर्श सास क्लाउड (SaaS cloud) प्रदाता का चयन कर रहा है और यह एक मुद्दा है, और अगर मैं चयन के बाद कैसे अन्य सुरक्षा चुनौतियों का सामना कर सकता हूं।
 तो, ऑनलाइन सहयोग जैसे अन्य चीजें बहुत लोकप्रिय हो रही हैं।
 एक आदर्श प्रदाता खोजने में कई सुरक्षा समस्याएं हैं।
आज के संदर्भ की प्रासंगिकता एक कमजोर युग्मित सहयोग गतिशील डेटा जानकारी साझाकरण है, जैसे कि यदि आप किसी भी ई मार्केटप्लेस को देखते हैं, या किसी भी प्रकार के सेवा प्रदाता को देखते हैं, जैसे कि हम देखते हैं, कि आप किस प्रकार की चीजें खरीदते हैं और ऑनलाइन खरीद चयन इत्यादि पर भी, यहां तक ​​कि आपके यात्रा बुकिंग केंद्र।
 इसलिए, अलग-अलग पार्टियां हैं।
 जो जुड़ी हुई हैं और अधिकांशतः वे कमजोर हैं, ऐसे पक्ष हैं, जो उत्पादों के प्रदाता हैं।
 ऐसे पक्ष हैं, जो वित्तीय प्रकार के क्षेत्र जैसे क्रेडिट कार्ड डेबिट कार्ड की अन्य प्रकार की सेवाओं के प्रदाता हैं, पार्टियां हैं कूरियर सेवाओं और चीजों के प्रकार हैं।
 तो, वे एक कमजोर जोड़े रास्ते से जुड़े हुए हैं।
 तो, हमारा लक्ष्य एक आदर्श सास (SaaS) क्लाउड प्रदाता का चयन करना और इसमें कमजोर युग्मित सहयोग को सुरक्षित वातावरण करना है।
 तो, विभिन्न पहलुओं क्या हैं।
 तो, वे क्या चाहते हैं।
वे एक सामान्य दृष्टिकोण की तलाश में हैं, ऐसा नहीं है कि अन्य दृष्टिकोण नहीं हो सकते हैं, लेकिन इस विशेष समस्या में हम किस तरह से जा सकते हैं।
 इसलिए, यदि आप हमारे उद्देश्य में से एक को देखते हैं, कि हम एक ढांचे को विकसित कर सकते हैं ।
 जैसे, कि मैंने उल्लेख किया है, कि इस विशेष कार्य में हमने एक ढांचा विकसित किया है या एक सेल्ससीएसपी (SelCSP)को भरोसेमंद और सक्षम चुनने के लिए सहयोग सेवा प्रदाता तैयार किया है।
 इसलिए, सीएसपी(CSP’s) के सेट में अलग-अलग सीएसपी(CSP’s) हो सकते हैं और उस विशेष रूप से किसी केंद्रीय प्राधिकरण में पंजीकृत हो सकते हैं।
 और ग्राहक व्यवसाय आउटसोर्सिंग के लिए सास (SaaS) प्रदाता का चयन करने का अनुरोध कर रहा है, और यह सिफारिश करता है, कि सीएसपी(CSP’s) विशेष के, या सीएसपीआई(CSPi) इसके लिए अनुकूल आधार है, मुख्य रूप से सुरक्षा पहलुओं पर मुख्य रूप से दिखने की आवश्यकता है।
 तो, यह बात का लक्ष्य है।
 चयन के बाद वहां हो सकता है, की स्थानीय संसाधन तक पहुंचने के लिए अनुरोध का चयन किया जा सकता है।
 इसलिए, एक बार जब मैं एक बार विशेष सीएसपी(CSPs) चुनता हूं, तो हम अज्ञात उपयोगकर्ता के लिए क्लाउड के भीतर स्थानीय संसाधनों तक पहुंचने के लिए चुनिंदा अनुरोध को देखना चाहते हैं।
 क्योंकि, हम नहीं जानते कि उपयोगकर्ता कौन हैं।
 जैसे, कि दोनों जोखिम और सुरक्षा अनिश्चितता सूचना साझाकरण के कारण कम रखा जाता है।
 इसलिए, हमारा उद्देश्य यह है, कि जानकारी साझा करने के लिए पहुंच जोखिम और सुरक्षा अनिश्चित सी(c) को कम या न्यूनतम रखा जाना चाहिए।
 इसलिए, यदि मेरे पास अलग-अलग डोमेन में अलग-अलग ग्राहक हैं, जैसे डोमेन एक डोमेन 2 डोमेन 3 (domain one domain 2 domain 3)।
 और वे किसी और जगह में सहयोग कर रहे हैं, या हम कहें की यहां कुछ प्रकार की तंत्र की आवश्यकता है हमने एक अस्पष्ट अनुमान(fuzzy inference) प्रणाली पर काम किया, जो कि उसे रखता है।
 इसलिए, अनुरोध करने के लिए डोमेन सहयोग अनुरोध और सही अनुमतियां सेट अप करें।
 और कहें अनुरोध प्रतिष्ठा अनुरोध स्थानीय ऑब्जेक्ट सुरक्षा स्तर की प्रतिष्ठा है, और सहयोग के लिए अधिकृत अनुमति सेट अप करें।
 तो, ऐसा हो सकता है कि ऐसा हो सकता है कि मैं संचालन के सेट के लिए अनुरोध करता हूं, और फिर मैं मूल नीति इंजन पर आधारित हूं और अनुरोधकर्ता के आधार पर किसी भी प्रतिष्ठा और स्थानीय वस्तुओं की सुरक्षा स्तर पर आधारित हूं, मैं सहयोग के अधिकार के लिए एक सेट अप अनुमति प्रदान करता हूं।
 तो, यह है, कि अगर हम किसी तरह का एक समानता करने की कोशिश करते हैं।
 जैसे, कि मैं किसी विशेष कार्यालय या चीज़ों का उपयोग करना चाहता हूं।
 और फिर मेरी प्रतिष्ठा या प्रमाण पत्र के आधार पर मैंने शायद विभिन्न प्रकार की चीजों तक पहुंच प्रदान की, जैसे कि मुझे कहा जा सकता है, कि आप परिसर में प्रवेश कर सकते हैं, आप आगंतुक लाउंज में प्रवेश कर सकते हैं, लेकिन आप मेरी प्रतिष्ठा के आधार पर वास्तविक कार्यालय में प्रवेश नहीं कर सकते, एक और प्रकार का प्रमाण पत्र मुझे वास्तविक कार्यालय में अंतर करने की अनुमति दी जा सकती है।
 हालांकि, मैं कहने वाले कंप्यूटिंग सिस्टम प्रयोगशाला में प्रवेश नहीं कर सकता हूं या जहां वास्तविक प्रयोगशालाएं हैं।
 इसलिए, यह आपके अधिकार के स्तर और आपकी आवश्यकता के आधार पर और डोमेन पर अनुरोध करता है, कि आप चीजों पर जाते हैं।
 जैसे, कि मैं बैंक जाता हूं।
 और अगर मैं सिर्फ कुछ चेक या कुछ दस्तावेज जमा करने जा रहा हूं, तो मैं कहीं कहीं जाता हूं, अगर मैं प्रबंधक से मिलना चाहता हूं तो मैं किसी अन्य स्तर की पहुंच और चीजों के प्रकार पर जाता हूं और यह निर्भर करता है कि मेरी आवश्यकता प्रकार की चीजें क्या हैं।
 या दूसरे अर्थ में यदि यह मिस एक्सेस एक मिस या एक्सेस रोल (miss access one misses or access role )अनुरोध भूमिका से तय किया जाता है, और विभिन्न प्रकार की वस्तुओं के लिए अनुमत चीजें क्या हैं।
 जैसे, कि अगर मैं किसी विशेष भाग को एक्सेस करना चाहता हूं तो अगर वे करेंगे किसी ऑब्जेक्ट को एक्सेस एक्सेस पॉलिसी के आधार पर ले जाएं, मुझे फ़िल्टर करने की आवश्यकता है।
 तो, एक सहयोगी क्लाउड के मामले में, जब ग्राहक इसके आधार पर अनुरोध के प्रकार के साथ आता है, तो वस्तुओं पर अन्य प्रकार की पहुंच नीतियां प्रतिष्ठित होती हैं।
 इसे चीजों का एक सेट दिया गया है।
 यह संभावना नहीं है, कि जो भी विशेष ग्राहक ने सब कुछ अनुरोध किया है, उसे अनुमति दी गई है।
 लेकिन, इसके आधार पर इसकी उप-अनुमति की अनुमति दी जा सकती है।
 तो, अन्य उद्देश्य को उस आईडीआरएम (IDRM )समस्या को इंटर डोमेन रोल मैपिंग समस्या (inter domain role mapping problem,को देखने के लिए एक ह्युरिस्टिक(heuristic) तैयार किया जा सकता है।
 जैसे, न्यूनतम पहुंच विशेषाधिकार प्रदान किया जाता है।
 तो, यही वह चीज है, जो विभिन्न प्रकार की चीजों के लिए एक समस्या है।
 जैसे, कि अगर मैं संगठन से कुछ हासिल करना चाहता हूं, तो संगठन की भूमिका में संगठन की भूमिका को मानचित्र बनाने की आवश्यकता है।
 अन्य संगठनों में एक समान भूमिका है।
 जैसे, कि मैं संगठन से वित्तीय संगठन के रूप में उपयोग कर रहा हूं, 1, 2 संगठन में कुछ डेटा के रूप में कुछ और कहता है, और यहां मैं स्तर 1 के प्रबंधक के रूप में उपयोग कर रहा हूं।
 और वह डेटा जिसके लिए प्रबंधक के बराबर है, स्तर 2 वे हैं।
 तो, तो मेरी भूमिका को उस विशेष स्तर पर नक्शा बनाने की आवश्यकता है अन्यथा मैं इस चीज़ तक नहीं पहुंच सकता।
 तो, यह एक रोल मैप्पिन समस्या(roll mapping problem) है, जो पहले से ही है और इसे देखने की आवश्यकता है।
 इस प्रकार की चीजें सहयोगी क्लाउड में भी है।
 तो, यहां हम यह भी कहने का प्रयास करते हैं, कि डोमेन सहयोगी अनुरोध अनुमतियों का एक सेट अधिकृत है और आईडीआरएम (IDRM) समस्या को हल करने के लिए कुछ ह्युरिस्टिक (heuristic) पर आधारित हम देखेंगे कि यह एक कठिन समस्या है।
 और इसलिए, हमें कुछ लालची शोध (greedy research )आधारित एल्गोरिदम(algorithm) करना चाहिए और कम से कम अतिरिक्त अनुमतियों के साथ एक सेट अप रोल मैप करने की कोशिश करें।
 इसलिए, न्यूनतम अतिरिक्त अनुमति जो यह कहने का प्रयास करती है, कि मुझे उस स्तर की अनुमति देने की आवश्यकता है, जो कि न्यूनतम अनुमति की अनुमति है, जिससे मुझे चीजों को निष्पादित करने की आवश्यकता है।
 मान लीजिए कि मैं एक दस्तावेज़ पढ़ना चाहता हूं।
 इसलिए, मुझे केवल पढ़ने की अनुमति दी जा सकती है, जिसे मुझे पढ़ा और सही अनुमति दी जा सकती है।
 तो, न्यूनतम सेट शायद सही चीज़ को पढ़ रहा हो।
 इसलिए, ताकि कोई अतिरिक्त अनुमति न हो, इस बात को कोई अतिरिक्त अनुमति नहीं दी जाती है।
 और दूसरा उद्देश्य एक वितरित सुरक्षित सहयोगी ढांचा हो सकता है, जो अतिरिक्त संघर्षों को गतिशील रूप से पहचानने और निकालने के लिए केवल स्थानीय जानकारी का उपयोग करता है, इन प्रणालियों के किसी भी प्रकार के ढीले ढंग (loosely coupled )से एक और बड़ी चुनौती है।
 तो, मैं केवल स्थानीय सूचनाओं के साथ गतिशील रूपरेखा कैसे रख सकता हूं? अब मैं क्लाउड प्रदाताओं सीएस सीएसपी 1(CSP 1) में क्लाउड क्लाउड इंस्टेंस सीएसपी 1(CSP 1) में क्लाउड इंस्टेंस (cloud instance) चलने वाला एक संगठन चाहता हूं, किसी अन्य संगठन के सीएसपी 2(CSP 2) ) में एक और डेटा एक्सेस करना चाहता हूं।
 तो, मेरे पास इस बारे में सीएसपी(CSP) या चीजों का अतिरिक्त लेखन की सभी जानकारी नहीं हो सकती है।
 इसलिए, मुझे अपने स्थानीय संसाधनों या स्थानीय सूचनाओं को देखने की आवश्यकता है और अधिकतम सुरक्षा प्राप्त करने की आवश्यकता है।
 दूसरी तरफ जब आपके पास थोड़ी सी चीजें हैं, तो आप सहयोगी में जो कुछ भी हो रहे हैं, वह सभी प्रमाण-पत्र नहीं ले सकते हैं।
 तो, आपके पास एक तंत्र होना चाहिए या वहां एक रास्ता होना चाहिए या वहां से संपर्क किया जाना चाहिए कि मैं इसे देखने के तरीके में कैसे मैप करूँ।
 तो, यहां हमने भूमिकाओं के एक सेट के साथ अनुरोध करने वाले डोमेन सहयोग अनुरोध का प्रयास किया, उपयोगकर्ता सत्रों में कई भूमिकाओं को सक्रिय किया।
 और चक्रीय चक्र उत्पादन के कारण संघर्षों का उपयोग कर सकते हैं।
 यदि, कोई चक्र उत्पादन हो तो वहां पहुंच पहुंच हो सकती है।
 इसका मतलब है, कुछ दस्तावेज एक तरह से मैं किसी विशेष संगठन में अपनी विशेष भूमिका के कारण पहुंचा नहीं पा रहा हूं, जब यह इस तरह की चीजों तक पहुंचने के चक्र में जाता है।
 तो, एक्सेस विवाद हो सकते हैं।
 इसलिए, मुझे एक संघर्ष पहचान और संघर्ष हटाने की आवश्यकता है और फिर मुझे एक संघर्ष मुक्त सहयोग अनुरोध करना चाहिए।
 तो, इस तरह के तंत्र हमें देखने की जरूरत है।
 तो, सहयोग के लिए भरोसेमंद और सक्षम सास (SaaS )क्लाउड प्रदाता का चयन है।
 इसलिए, अधिकांश रिपोर्ट किए गए कार्यों की चुनौतियों को प्रस्तुत नहीं किया गया है।
 इसलिए, सेवा प्रदाता की मॉडल ट्रस्ट प्रतिष्ठा क्षमता की कई चुनौतियों का उद्देश्य है।
 तो, हम 3 घटक, विश्वास, प्रतिष्ठा, क्षमता देख रहे हैं।
 इसलिए, वे बहुत अधिक जुड़े हुए हैं, लेकिन फिर उनके पास कुछ अलग संपत्ति है।
 तो, यहाँ कितना भरोसा है? क्या यह ऐसा करने में सक्षम है? और यह एक विशेष चीजें या सुरक्षा प्रकार की चीजों को करने का अधिकार कैसे है? इसलिए, यदि आप एसएलए(SLA's) को देखते हैं, तो फिर से चुनौतियां होती हैं।
 क्योंकि, कोई तर्क दे सकता है कि एसएलए (SLA's) इसे कवर करने का प्रयास करता है।
 जैसे, अधिकांश क्लाउड प्रदाताओं ने सेवाओं की उपलब्धता की गारंटी दी है।
 उपभोक्ता न केवल गारंटी की उपलब्धता की मांग करता है, बल्कि अन्य प्रदर्शन से संबंधित आश्वासन भी समान रूप से महत्वपूर्ण है।
 इसलिए, मैं न केवल उपभोक्ता के रूप में उपलब्धता को देख रहा हूं, बल्कि यह भी आश्वासन देता हूं कि यह इस प्रकार के समय सीमा में या मुआवजे तक किया जाएगा।
 वर्तमान दिन क्लाउड(cloud) एसएलए (SLA's )के उल्लंघन के बाद आश्वासन और मुआवजे के संबंध में गैर मानक खंड शामिल हैं।
 इसलिए, कुछ गैर-मानक उपस्थिति का पालन करने वाले जुर्माना योजना का मुआवजा है।
 क्योंकि, क्लाउड चीज में कोई मानकीकरण तंत्र नहीं है।
 इसलिए, एक बार फिर क्लाउड एसएलए (SLA)के लिए पैरामीटर का मानक सेट स्थापित करता है, क्योंकि इससे आउटसोर्स सेवाओं की धारणा जोखिम कम हो जाती है।
 इसलिए, धारणा संसाधन को कम करने का तरीका होना चाहिए।
 तो, फिर से हम एक फ्रेमवर्क को देखने की कोशिश करते हैं, कि अलग-अलग ग्राहक हैं या नहीं।
 तो, बातचीत रेटिंग और अस्थायी matrices पूर्ण गणना की जाती है।
 तो, विश्वास अनुमान प्रतिष्ठा अनुमान ट्रस्ट गणना की योग्यता के बाद योग्य जोखिम अनुमान और जोखिम गणना।
 दूसरी ओर हमारे पास सिफारिश और मानक सुरक्षा नियंत्रण है, जो एसएलए(SLA's) के प्रबंधकों को चलाता है और यह सब सेवा प्रदाता के साथ यह एक एसएलए (SLA's), है।
 वे एसएलए(SLA's) के कुछ स्तर की सक्षमता आकलन क्षमता गणना एक तरफ प्रदान करते हैं, कि हम विश्वास की योग्यता की गणना दूसरी तरफ क्षमता, जोखिम अनुमान, विशेष चीजों का जोखिम गणना और जोखिम में रुचियों की गणना करते हैं।
 उसमें से हम विभिन्न सेवा प्रदाता के लिए इन दोनों के बीच बातचीत का पता लगाने की कोशिश करते हैं।
 इसलिए, इनमें से अलग-अलग प्रवाह सेल्ससीएसपी ढांचे (SelCSP framework )हैं, जो कि जोखिम अनुमान है और जोखिम संबंधी प्रत्यक्ष ट्रस्ट अनुमान के समान जोखिम हो सकता है, हम प्रवाह में इसे रखना चाहते हैं।
 दूसरा प्राधिकरण के लिए अनाम उपयोगकर्ताओं (anonymous users) से एक्सेस अनुरोध की सिफारिश कर रहा है।
 तो, एक जोखिम आधारित (risk based) पहुंच नियंत्रण है।
 इसलिए, हालांकि हमने अन्य प्रकार के अभिगम नियंत्रण के बारे में सुना है, मैं भूमिका आधारित अभिगम नियंत्रण करता हूं, जिसे हम जोखिम आधार पहुंच नियंत्रण के रूप में देखते हैं।
 इसलिए, यह किसी विषय तक पहुंच प्रदान करता है, भले ही उन्हें उचित अनुमतियों की कमी हो।
 इसलिए, मेरे पास अनुमतियों का पूरा सेट नहीं है, जो पूरी तरह से युग्मित हैं।
 तो, क्या मैं इसे शामिल करने वाले कुछ जोखिमों के साथ पहुंच प्रदान कर सकता हूं।
 ऐसा नहीं है, कि बाइनरी स्टॉप चालू या बंद है, लेकिन उन चीजों की तरह है।
 पहुंच के बीच लक्ष्य संतुलन सही जानकारी साझा करने के कारण सुरक्षा अनिश्चितता का जोखिम उठाता है।
 बाइनरी एमएलएस (binary MLS) की तुलना में लचीला (Flexible) है।
 तो, यह थोड़ा सा है, क्योंकि हम इसके बारे में बात कर रहे हैं, बाइनरी के बजाय मैं थोड़ा जोखिम का ख्याल रखता हूं।
 इसलिए, सुरक्षा अनिश्चितता की गणना करने वाली चुनौतियों को पूरी तरह से संबोधित सामान नहीं है।
 तो, मैं कंप्यूटिंग सुरक्षा अनिश्चितता(computing security uncertainty) को सही तरीके से कैसे देखूं? जोखिम सीमा और परिचालन आवश्यकताओं के आधार पर मौजूदा जोखिम आधार पहुंच नियंत्रण प्रणाली में प्राधिकरण और परिचालन की आवश्यकता नहीं है।
 मात्राबद्ध करना मुश्किल है, परिचालन जोखिम ने कई अनुरोधों को त्याग दिया है, जो संभावित रूप से जानकारी साझा करने को अधिकतम करते हैं।
 इसलिए, इसे कम करने के लिए हम कई अनुरोधों को त्याग देते हैं, जो साबित करते हैं कि पर्स संभावित (purse potentially) रूप से सूचना साझाकरण (information sharing) को अधिकतम करता है ताकि मेरा समग्र जोखिम नीचे आ जाए।
 इसलिए, जोखिम को कम करने के लिए दूसरे अर्थ में हम सहयोग को कम करने की कोशिश करते हैं।
 तो, यह इसे देखने में से एक है।
 इसलिए, एक वितरित फ्रेम काम (distributed frame work) है।
 क्योंकि, हमने इसे देखने के लिए फ़ाइल फ़ज़ी इनफरेंस सिस्टम (file fuzzy inference system) का उपयोग किया था।
 और यह चीजों का वितरित रैकिंग खोजने की कोशिश करता है।
 अगला वाला स्थानीय भूमिकाओं में अधिकृत अनुमति को मानचित्रण कर रहा है।
 तो, इंटर डोमेन रोल मैपिंग चीज आईडीआरएम (inter domain roll mapping thing IDRM)।
 तो, हमारे पास भूमिकाओं का एक न्यूनतम सेट है, जो अनुरोधित अनुमति सेट को घेर लेता है।
 कोई बहुपद समय समाधान लालची खोज (greedy search ) आधारित हेरिस्टिक्स उप इष्टतम समाधान(heuristics sub optimal solutions) उपलब्ध नहीं हैं।
 वे चुनौतियां हैं, जो कई न्यूनतम भूमिका सेट हो सकती हैं।
 इसलिए, मौजूदा न्यूनतम एकाधिक भूमिका सेट हो सकते हैं, वे यहां मौजूद किसी भी भूमिका सेट नहीं हो सकते हैं, जो सभी अनुमतियों के लिए बिल्कुल सही है।
 इसलिए, विभिन्न प्रकार की समस्याएं या चुनौतियां हैं।
 इसलिए, आईडीआरएम (IDRMs) के 2 प्रकार हैं, जिनमें आईडीआरएम (IDRM) सुरक्षा और आईडीआरएम (IDRMs) उपलब्धता है।
तो, आईडीआरएम उपलब्धता और सुरक्षा एक नॉवल हेरिस्टिक (novel heuristic ) बनाने के उद्देश्य से आईडीआरएम (IDRM) उपलब्धता के लिए बेहतर समाधान उत्पन्न करता है और अनुमति की समस्या को कम करता है।
 तो, यहां भी अगर आप वितरित भूमिका मैपिंग ढांचे (mapping framework)को देखते हैं।
 तो, मेरे पास अनुमति पहुंच अनुरोध हैंडलर का एक सेट है।
 और हमारे पास स्थानीय डोमेन भूमिका सेट रोल अनुमति असाइनमेंट संरेखित है, जो अनुमति सेट करने की भूमिका है।
 इसलिए, जो अनुमतियों और ह्युरिस्टिक (permissions and heuristic) आधारित विचार उपलब्धता समस्या हल करने वाले हैं, जो हम बनाने या प्रस्तावित करने का प्रयास करते हैं और जो भूमिका का एक सेट रखता है और जो न्यूनतम सेट अप भूमिका निभाता है।
 और अंत में, गतिशील पहचान और पहुंच संघर्ष को हटाने का दूसरा पहलू है।
 इसलिए, जब भी हमारे पास कई सहयोग होते हैं, तो यह एक और बड़ी समस्या है।
 तो, एक मौका हो सकता है, कि आप चक्रीय पहुंच चक्र (cyclic access cycle) कर सकते हैं।
 और इससे कुछ ऑब्जेक्ट्स तक पहुंच हो सकती है, जो किसी अन्य विषय को सही तरीके से एक्सेस करने का अनुमान नहीं लगाते हैं।
 जैसा कि आप इस चक्रीय विरासत (inheritance cyclic) को इस दर्शक की तरह संघर्ष करते हैं, इस विशेष चीज को लिखने या संपादक की अनुमति के रूप में अनुमति नहीं है।
 लेकिन, मुझे किसी दूसरे डोमेन तक पहुंच प्राप्त हो सकती है, जिसके पास सही अनुमति है, उनसे अनुमति दी गई एक और संपादन है, जिसमें पढ़ने की अनुमति है।
 तो, दूसरे अर्थ में मैं यह नहीं कर सकता।
 इस विशेष विषय के लिए इस विशेष वस्तु को नहीं लिखा जा सकता है, लेकिन मेरे पास इसका चक्रीय तरीका हो सकता है।
 तो, विरासत चक्रीय रास्ता (inheritance cyclic way) और इसे लिखो।
 तो, दूसरे अर्थ में मैंने एक विरोधाभासी परिस्थितियां की हैं, जो अन्य तरीकों से मुझे नहीं करना चाहिए।
 सोड कांस्टेंट (sod constant) का उल्लंघन हो सकता है।
 तो, सोड कांस्टेंट (sod constant) वास्तव में कर्तव्य को अलग करता है।
 जैसे, कि मैं एक सामान्य सादृश्य कह सकता हूं।
 जैसे, बैंक में मांग करने वाले व्यक्ति को डिमांड ड्राफ्ट जारी करने की मांग नहीं हो सकती है, जैसे कि मैं मुद्दा काउंटर में हूं।
 इसलिए, अगर मैं इस बात को जारी कर रहा हूं, मै एक ड्राफ्ट जारी कर रहा हूं, तो सत्यापन मैं वही काम नहीं कर सकता।
 तो, अलग चीजें होनी चाहिए।
 इसलिए, इन कर्तव्यों को अलग करना है, जो सोड कांस्टेंट (sod constant) के रूप में जाना जाता है, जो कि वे किसी भी सुरक्षा सूचना सुरक्षा तंत्र में हैं।
 तो, यहां भी हम देख सकते हैं, कि सदैव स्थिरता में एक संघर्ष हो सकता है।
 यहां की तरह मुझे अधिकार हो सकता है।
 चीजों पर और मेरे पास इस संपादक पर इस संपादक को लिखने के साथ एक और चैनल हो सकता है, यहां एक संचार है।
 इसलिए, मैं मूल रूप से एक स्थिर स्थिरता के बावजूद कर सकता हूं, मैं एक अलग चैनल के माध्यम से बीच संवाद करता हूं।
 इसलिए, चीजों का उल्लंघन हो सकता है, ये चीजें होती हैं जब भी कई संचार भागीदार(multiple communicating partner) होते हैं और खासकर जब वे कमजोर(loosely coupled) होते हैं, इसका मतलब है, आप अन्य चीजों या अन्य पार्टी की सुरक्षा सेटिंग्स के पूरे सुरक्षा परिदृश्य(security scenario) को नहीं जानते हैं।
 तो, यहां हम एक विशेष वितरित सुरक्षा सहयोगी फ्रेम कार्य के लिए भी प्रयास करते हैं, जो भूमिकाओं का एक सेट लेता है और सहयोग प्रसंस्करण मॉड्यूल के सहयोग के आधार पर, और संघर्ष पहचान और संघर्ष हटानेवाला मॉड्यूल के साथ आता है और यहाँ एक परिदृश्य का सेट है, जो इनको पूरा करेगा।
 इसलिए, डोमेन से एक प्रविष्टि की रोल अनुक्रम इंटरऑपरेक्शन (role sequence interoperation) अनुरोध जोड़ी प्रवेश की भूमिका निभाते हुए सही भूमिका अनुक्रम क्रम सफलता और अस्तित्व की भूमिका से मौजूद है।
 तो, मेरे पास सुरक्षित भूमिका चक्र या असुरक्षित भूमिका चक्र (safe role cycle or unsafe role cycle हो सकता है।
 तो, जैसा कि हम समझते हैं, कि वह एक भूमिका है, जो एक पहचान है, अगर वहां कोई संघर्ष होता है, तो उन्हें पता लगाने की आवश्यकता होती है।
 इसे विरासत संघर्ष का पता लगाना होगा और सोड निरंतर उल्लंघन (sod constant violation)का पता लगाना।
 तो, यह पता लगाने की आवश्यकता है, कि अब और क्या चीजें हैं, जिन्हें हमें हटाने की जरूरत है।
 फिर एक बार पता चला कि उन संघर्षों को हटाने की जरूरत है, तो यहाँ 2 मामले सामने आ सकते हैं, जो इस रोल सेट से मेल खातें है।
 तो, r वापस हाइब्रिड पदानुक्रम (r back hybrid hierarchy) या कोई सही भूमिका सेट नहीं हो सकता है ,जो मैं कर सकता हूं।
 तो, मैं चीजों में एक आभासी भूमिका (virtual role) बना सकतें है।
 तो, मैं एक डमी भूमिका बना सकता हूं और इसे देख सकता हूं।
 अगर आप चक्रीय अनावश्यक(cyclic redundancy) विरासत को देखते हैं, तो चक्रीय विरासत(cyclic inheritance) विवाद हटाने की भूमिका बिल्कुल सटीक मिलान भूमिकाओं के लिए है, जो हम यहां करते हैं।
 तो, इसके बजाय संघर्ष हटाने के बाद हम एक सहयोगी भूमिका निभाते हैं।
 यहां देखें कि मूल रूप से यह इस संपादक में समाप्त होने वाला एक चक्र था, जबकि यहां विरासत संघर्ष को बिल्कुल मेल नहीं मिला।
 इसलिए, क्योंकि इसे देखने की बिल्कुल सटीक भूमिका नहीं है।
 इसलिए, हम एक और उप रोल या एक नया रोल बनाते हैं, जो वापस आ जाता है।
 अब, इस दर्शक को इस विशेष संपादक के पास जाने का कोई तरीका नहीं है।
 इसलिए, कि मैं नहीं जा रहा हूं और कोई संघर्ष नहीं है।
 इसी तरह, संघर्ष हटाने के लिए भी, हमारे पास यहां भी बाधा को हटाने की चीज हो सकती है।
 तो, यह हमारा पिछला परिदृश्य(scenario) था जहां इस संपादक का अधिकार यहां था और इस दर्शक को इस संपादक के पास इन तक पहुंच हो सकती है और अंत में, यह इस संपादक को जाता है और वहां सोड(sod) के रूप में लिया जाता है।
 तो, एक चक्र का एक मौका है, जो इस सोड(sod) का उल्लंघन करता है।
 तो, अगर यहां कोई सटीक मिलान नहीं है, तो हमने एक सहयोगी भूमिका बनाई है।
 इसलिए, यह संपादक 2 की भूमिका का सहयोग करता है।
 तो, संपादक 2 सी (2c) और यह वहां समाप्त होता है।
 इसलिए, संपादक एक और संपादक 2 के बीच कोई गड़बड़ नहीं है।
 तो इसका मतलब है, कि हम ऐसा करने की कोशिश कर रहे हैं।
 हम मूल रूप से एक परिदृश्य (scenario) तैयार कर सकते हैं, जहां यह सुरक्षा उल्लंघनों के बिना चीजों के बीच स्वस्थ सहयोग है।
 तो, यह एक सामान्य दृष्टिकोण है, जिससे हम यह दिखाने का प्रयास करते हैं, कि सास क्लाउड (SaaS cloud) में कितना सुरक्षित सहयोग संभव हो सकता है, और निश्चित रूप से यह एक बहुत ही संक्षिप्त अवलोकन है, लेकिन यह काफी अच्छा है, या यह आपकी मदद करेगा जो इस तरह के इच्छुक अनुसंधान हैं।
 बुनियादी ढांचे की आवश्यकता कम है।
 लेकिन, आप मूल रूप से इस तरह की समस्या पर काम कर सकते हैं।
 तो, एक भरोसेमंद और सक्षम क्लाउड प्रदाता का चयन है और चयन के बाद हमारे पास प्राधिकरण के लिए अनाम उपयोगकर्ताओं से अनुशंसित पहुंच अनुरोध है।
 फिर स्थानीय भूमिकाओं के लिए अधिकृत अनुमति का मानचित्रण, और गति नियंत्रण का पता लगाने के नियंत्रण विवादों का पता लगाने के लिए है।
 जैसे चक्रीय विरासत समस्या संघर्ष (cyclic inheritance problem conflict) हो सकता है, या सोड (sod) प्रकार का संघर्ष हो सकता है।
 तो, हम जो आज कोशिश करते या आज हम चर्चा करते हैं कि सुरक्षा के एक बहुत ही मुश्किल मुद्दे में से एक को देखते हुए जहां सास क्लाउड (SaaS cloud) को एक कम तरीके से सहयोग किया जाता है।
 तो, सामान्य सुरक्षा मुद्दे क्या हो सकते हैं, और उन समस्याओं से निपटने के लिए कैसे संपर्क करें, यह अलग-अलग दृष्टिकोण हो सकते हैं।
 आप साहित्य में पा सकते हैं और यहां तक ​​कि आप अन्य दृष्टिकोणों के बारे में सोच सकते हैं, लेकिन यह इसे देखने का एक सामान्य तरीका है।
 और यह एक समस्या है जो बहुत अधिक है और आज के क्लाउड परिदृश्य(cloud scenario) का सहयोग करने के लिए बहुत सच है।
 धन्यवाद।