हम एक भूमिका-आधारित अभिगम नियंत्रण मॉडल का निर्माण कर रहे हैं। भाग एक, तैयारी

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

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

एनबी दुर्भाग्य से, रोल मॉडल बनाना कोई परिणाम नहीं, बल्कि एक प्रक्रिया है। या यूं कहें कि कंपनी में एक्सेस कंट्रोल इकोसिस्टम बनाने की प्रक्रिया का भी हिस्सा है। तो लंबे समय तक खेल के लिए तैयार हो जाइए।

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

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

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

यह ध्यान देने योग्य है कि व्यावसायिक संरचना में प्रत्येक पद के कर्मचारियों के लिए सभी आवश्यक अधिकार प्रदान करते हुए, 100% रोल मॉडल बनाना असंभव है। हां, ये जरूरी नहीं है. आख़िरकार, एक रोल मॉडल स्थिर नहीं हो सकता, क्योंकि यह लगातार बदलते परिवेश पर निर्भर करता है। और कंपनी की व्यावसायिक गतिविधियों में परिवर्तन से, जो तदनुसार, संगठनात्मक संरचना और कार्यक्षमता में परिवर्तन को प्रभावित करता है। और संसाधनों के पूर्ण प्रावधान की कमी से, और नौकरी के विवरण का अनुपालन न करने से, और सुरक्षा की कीमत पर लाभ की इच्छा से, और कई अन्य कारकों से। इसलिए, एक ऐसा रोल मॉडल बनाना आवश्यक है जो किसी पद को सौंपे जाने पर आवश्यक बुनियादी अधिकारों के लिए उपयोगकर्ता की 80% जरूरतों को कवर कर सके। और यदि आवश्यक हो, तो वे शेष 20% का अनुरोध बाद में अलग-अलग आवेदनों पर कर सकते हैं।

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

भूमिका-आधारित प्रबंधन का मुख्य लाभ अधिकार जारी करने का सरलीकरण है, क्योंकि भूमिकाओं की संख्या सूचना प्रणाली के उपयोगकर्ताओं की संख्या से काफी कम है। और यह किसी भी उद्योग के लिए सच है।

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

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

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

कई अलग-अलग एक्सेस कंट्रोल मॉडल अब ज्ञात हैं, लेकिन वे तुरंत सामने नहीं आए। आइए उन लोगों पर ध्यान दें जिन्होंने इस क्षेत्र के विकास में महत्वपूर्ण योगदान दिया है।

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

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

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

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

मानक एक भूमिका को "किसी संगठन के संदर्भ में एक कार्य फ़ंक्शन के रूप में परिभाषित करता है, जिसमें भूमिका के लिए सौंपे गए उपयोगकर्ता को दिए गए अधिकार और जिम्मेदारी के संबंध में कुछ संबंधित शब्दार्थ होते हैं।" दस्तावेज़ आरबीएसी के मूल तत्वों - उपयोगकर्ताओं, सत्रों, भूमिकाओं, अनुमतियों, संचालन और वस्तुओं, साथ ही उनके बीच संबंधों और अंतर्संबंधों को स्थापित करता है।

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

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

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

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

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

अब आइए आवश्यक प्रारंभिक चरणों के बारे में बात करें, जिनके बिना एक कामकाजी रोल मॉडल बनाना असंभव है।

चरण 1. एक कार्यात्मक मॉडल बनाएं

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

चरण 2. हम आईटी सिस्टम का ऑडिट करते हैं और एक प्राथमिकता योजना तैयार करते हैं

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

तो आप किसी सिस्टम की गंभीरता का निर्धारण कैसे करते हैं? अपने आप को निम्नलिखित प्रश्नों के उत्तर दें:

• क्या सिस्टम उन परिचालन प्रक्रियाओं से जुड़ा है जिन पर कंपनी की मुख्य गतिविधियाँ निर्भर करती हैं?
• क्या सिस्टम व्यवधान से कंपनी की परिसंपत्तियों की अखंडता प्रभावित होगी?
• सिस्टम का अधिकतम अनुमेय डाउनटाइम क्या है, जिस तक पहुँचने पर रुकावट के बाद गतिविधि को बहाल करना असंभव है?
• क्या सिस्टम में सूचना की अखंडता के उल्लंघन से वित्तीय और प्रतिष्ठित दोनों तरह के अपरिवर्तनीय परिणाम हो सकते हैं?
• धोखाधड़ी की गंभीरता. कार्यक्षमता की उपस्थिति, यदि ठीक से नियंत्रित नहीं की जाती है, तो आंतरिक/बाह्य धोखाधड़ीपूर्ण कार्रवाइयों को जन्म दे सकती है;
• इन प्रणालियों के लिए कानूनी आवश्यकताएँ और आंतरिक नियम और प्रक्रियाएँ क्या हैं? क्या अनुपालन न करने पर नियामकों की ओर से जुर्माना लगाया जाएगा?

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

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



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

चरण 3 एक कार्यप्रणाली बनाएं

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

• सामान्य कॉर्पोरेट आवश्यकताएँ;
• सूचना सुरक्षा क्षेत्रों के लिए आवश्यकताएँ (संगठन की गतिविधियों के क्षेत्रों के आधार पर);
• तकनीकी प्रक्रियाओं के लिए आवश्यकताएँ (निर्देश, एक्सेस मैट्रिसेस, दिशानिर्देश, कॉन्फ़िगरेशन आवश्यकताएँ)।

हमारी वित्तीय कंपनी में, हमें बहुत सारे पुराने दस्तावेज़ मिले; हमें उन्हें लागू की जा रही नई प्रक्रियाओं के अनुसार लाना था।

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

कार्य करने की प्रक्रिया, समय-सीमा, जिम्मेदारियाँ आदि का वर्णन करने वाले दस्तावेज़। - एक गारंटी है कि पोषित लक्ष्य के रास्ते पर, जो पहले हर किसी के लिए स्पष्ट नहीं है, किसी के मन में यह सवाल नहीं होगा कि "हम ऐसा क्यों कर रहे हैं, हमें इसकी आवश्यकता क्यों है, आदि।" और "छलाँग लगाने" या प्रक्रिया को धीमा करने का कोई अवसर नहीं होगा।

चरण 4. मौजूदा एक्सेस कंट्रोल मॉडल के मापदंडों को ठीक करें

हम अभिगम नियंत्रण के संदर्भ में एक तथाकथित "सिस्टम पासपोर्ट" तैयार कर रहे हैं। संक्षेप में, यह एक विशिष्ट सूचना प्रणाली पर एक प्रश्नावली है, जो उस तक पहुंच को नियंत्रित करने के लिए सभी एल्गोरिदम को रिकॉर्ड करती है। जो कंपनियाँ पहले से ही IdM-श्रेणी समाधान लागू कर चुकी हैं, वे संभवतः ऐसी प्रश्नावली से परिचित हैं, क्योंकि यहीं से सिस्टम का अध्ययन शुरू होता है।

सिस्टम और मालिकों के बारे में कुछ पैरामीटर आईटी रजिस्ट्री से प्रश्नावली में प्रवाहित हुए (चरण 2, ऑडिट देखें), लेकिन नए भी जोड़े गए:

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

इस सूची को एक्सेस कंट्रोल प्रक्रिया में शामिल विभिन्न मापदंडों और अन्य वस्तुओं के विवरण के साथ जारी रखा जा सकता है।

चरण 5. अनुमतियों का व्यवसाय-उन्मुख विवरण बनाएं

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

यह अच्छा है अगर पहले से ही कोई व्यवसाय विवरण मौजूद है या यहां तक ​​कि अगर इन अधिकारों का समूहों और भूमिकाओं में संयोजन है। कुछ अनुप्रयोगों के लिए, विकास चरण में ऐसा संदर्भ बनाना सबसे अच्छा अभ्यास है। लेकिन ऐसा अक्सर नहीं होता है, इसलिए हम सभी संभावित अधिकारों के बारे में जानकारी इकट्ठा करने और उनका वर्णन करने के लिए फिर से आईटी विभाग में जाते हैं। हमारी मार्गदर्शिका में अंततः निम्नलिखित शामिल होंगे:

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

चरण 6 हम सिस्टम से उपयोगकर्ताओं और अधिकारों के बारे में डेटा डाउनलोड करते हैं और कार्मिक स्रोत के साथ उनकी तुलना करते हैं

तैयारी के अंतिम चरण में, आपको सभी उपयोगकर्ताओं और उनके पास वर्तमान में मौजूद अधिकारों के बारे में सूचना प्रणालियों से डेटा डाउनलोड करना होगा। यहां दो संभावित परिदृश्य हैं. पहला: सुरक्षा विभाग के पास सिस्टम तक सीधी पहुंच है और उसके पास प्रासंगिक रिपोर्ट डाउनलोड करने के साधन हैं, जो अक्सर नहीं होता है, लेकिन बहुत सुविधाजनक है। दूसरा: हम आवश्यक प्रारूप में रिपोर्ट प्राप्त करने के लिए आईटी को एक अनुरोध भेजते हैं। अनुभव से पता चलता है कि आईटी के साथ समझौता करना और पहली बार आवश्यक डेटा प्राप्त करना संभव नहीं है। वांछित रूप और प्रारूप में जानकारी प्राप्त होने तक कई दृष्टिकोण अपनाना आवश्यक है।

कौन सा डेटा डाउनलोड करना होगा:

• खाता नाम
• उस कर्मचारी का पूरा नाम जिसे यह सौंपा गया है
• स्थिति (सक्रिय या अवरुद्ध)
• खाता निर्माण तिथि
• अंतिम उपयोग की तिथि
• उपलब्ध अधिकारों/समूहों/भूमिकाओं की सूची

इसलिए, हमें सिस्टम से सभी उपयोगकर्ताओं और उन्हें दिए गए सभी अधिकारों के साथ डाउनलोड प्राप्त हुए। और उन्होंने तुरंत सभी अवरुद्ध खातों को अलग रख दिया, क्योंकि रोल मॉडल बनाने का काम केवल सक्रिय उपयोगकर्ताओं के लिए ही किया जाएगा।

फिर, यदि आपकी कंपनी के पास निकाले गए कर्मचारियों तक पहुंच को अवरुद्ध करने का स्वचालित साधन नहीं है (ऐसा अक्सर होता है) या पैचवर्क स्वचालन है जो हमेशा सही ढंग से काम नहीं करता है, तो आपको सभी "मृत आत्माओं" की पहचान करने की आवश्यकता है। हम उन कर्मचारियों के खातों के बारे में बात कर रहे हैं जिन्हें पहले ही निकाल दिया गया है, जिनके अधिकार किसी कारण से अवरुद्ध नहीं हैं - उन्हें अवरुद्ध करने की आवश्यकता है। ऐसा करने के लिए, हम अपलोड किए गए डेटा की तुलना कार्मिक स्रोत से करते हैं। कार्मिक डेटाबेस को बनाए रखने वाले विभाग से कार्मिक अनलोडिंग भी अग्रिम रूप से प्राप्त की जानी चाहिए।

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

जैसे ही हमारे अपलोड अनावश्यक रिकॉर्ड से साफ़ हो जाते हैं और केवल सक्रिय खाते रह जाते हैं, हम एक विशिष्ट सूचना प्रणाली के लिए एक रोल मॉडल बनाना शुरू कर सकते हैं। लेकिन इसके बारे में मैं आपको अगले आर्टिकल में बताऊंगा.

लेखक: ल्यूडमिला सेवस्त्यानोवा, प्रमोशन मैनेजर सोलर इनराइट्स

स्रोत: www.habr.com