पहचान प्रबंधन - खाता प्रबंधन मूल बातें

आज हम आइडेंटिटी मैनेजमेंट क्लास सिस्टम की चर्चा शुरू करेंगे। जैसा कि आप में से बहुत से लोग जानते हैं, 1 जुलाई को रूसी संघ के संघीय कानून के बल में प्रवेश के लिए समय सीमा 27 जुलाई 2006 को समाप्त हुई।

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

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

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

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

मुझे पूरी उम्मीद है कि इस सामग्री को पढ़ने के बाद, मेरे सहयोगियों ने इस मुद्दे पर स्पष्टता बढ़ाई होगी, और कई प्रोग्रामर या सिस्टम प्रशासक इस क्षेत्र में काम करने वाले कुछ "सितारों" के साथ प्रतिस्पर्धा करने के लिए IDM व्यापार खुफिया शिविर में जा सकेंगे।

आइडेंटिटी मैनेजमेंट क्या है?

पहचान एक व्यक्ति है। एक वास्तविक व्यक्ति के बारे में जानकारी बनाने वाली हर चीज की पहचान है: उसका नाम, लिंग, स्थिति, जन्म का वर्ष, प्रणालियों में उसके खातों की विशेषताएं। कुछ संयोजनों में, एक व्यक्ति के बारे में जानकारी संघीय कानूनों के अधीन है और इसका प्रबंधन किया जाना चाहिए। प्रक्रियाओं और व्यक्तिगत डेटा प्रबंधन प्रणालियों को पहचान प्रबंधन, या IDM कहा जाता है।

कंपनी के कर्मचारियों के बारे में व्यक्तिगत जानकारी कहाँ संग्रहीत है? बेशक, कार्मिक प्रणाली में। और यह भी - सक्रिय निर्देशिका में, कई दर्जन एप्लिकेशन सिस्टम के उपयोगकर्ता कार्ड में, मेल प्रोग्राम के डेटा में, क्लाइंट मैनेजमेंट सिस्टम में, बिलिंग सिस्टम में, सर्विस डेस्क सिस्टम में ... अक्सर यह जानकारी संगत नहीं होती है। एक और एक ही व्यक्ति एक ही समय में एक दर्जन सिस्टम में पंजीकृत हो सकते हैं, और कोई भी गारंटी नहीं देगा कि वह समान और सही तरीके से उन में पंजीकृत है।

IDM के मुख्य कार्यों में से एक प्रबंधन प्रक्रियाओं के आगे विकास के लिए आधार के रूप में व्यक्तिगत जानकारी के एकल और प्रासंगिक कैटलॉग का निर्माण है।

IDM, IAM, RM - WTF?

उपयोगकर्ता खाते और उनकी विशेषताएँ (उदाहरण के लिए, पहुँच समूह) मेल पते, नाम और पदों के रूप में व्यक्तिगत जानकारी का एक ही हिस्सा हैं। सक्रिय निर्देशिका विशेषज्ञ इस बात की पुष्टि करेंगे कि यह सिस्टम डेटाबेस में समान तरीके से संग्रहीत है। तदनुसार, आईडीएम प्रक्रिया के ढांचे में सूचना प्रबंधन (एक्सेस मैनेजमेंट) तक पहुंच प्रबंधन को शामिल करना तर्कसंगत होगा। अक्सर, IDM को पहचान और पहुंच प्रबंधन (IAM) के रूप में समझा जाता है, बस संक्षिप्त नाम IDM लोग अधिक पसंद करते हैं।

आईडीएम के सफल कार्यान्वयन के परिणामों को "स्थिर" और "गतिशील" में विभाजित किया जा सकता है। पहले के परिणाम "क्या बन गए हैं?" और दूसरा "और यह कैसे काम करता है?"

IDM के सफल कार्यान्वयन का स्थैतिक परिणाम उपयोगकर्ता खातों में क्रम है, जिसमें निम्नलिखित शामिल हैं:

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

एक सफल कार्यान्वयन का गतिशील घटक, वास्तव में, एक खाता प्रबंधन प्रक्रिया है जो घड़ी की तरह काम करती है। ऐसी प्रक्रिया के लिए मापदंड का एक उदाहरण इस प्रकार है:

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

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

विभिन्न प्रणालियों में उपयोगकर्ता के अधिकार (विशेषाधिकार) पूरी तरह से और विशेष रूप से उसके आधिकारिक कर्तव्यों पर निर्भर करते हैं। और उसकी जिम्मेदारियाँ जितनी अधिक विविधतापूर्ण होंगी, इन विशेषाधिकारों को निर्दिष्ट करने के लिए सिद्धांतों को निर्धारित करना उतना ही कठिन होगा।

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

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

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

आपदा के पैमाने का आकलन करने के लिए, मैं कुछ आंकड़े दूंगा। मान लीजिए कि एक कंपनी में 1000 उपयोगकर्ता हैं, 10 सिस्टम हैं, और प्रत्येक सिस्टम में 10 अलग विशेषाधिकार हैं। कुछ सिस्टम बंधे हुए हैं, उदाहरण के लिए, सक्रिय निर्देशिका के लिए, और कुछ के पास अपनी प्रमाणीकरण प्रणाली है। इस प्रकार, औसतन, प्रत्येक उपयोगकर्ता के लिए, उदाहरण के लिए, 3 खाते हैं। कुल हमारे पास 3000 खाते हैं। प्रत्येक उपयोगकर्ता के पास अपने सिस्टम में औसतन 5-7 विशेषाधिकार हैं। कुल हमारे पास उपयोगकर्ताओं के लिए 15-20 हजार विशेषाधिकार असाइनमेंट हैं। विशेषाधिकारों के प्रत्येक असाइनमेंट को एक समय में न केवल ऐसा बनाया गया था, बल्कि अर्थ के साथ। और अर्थ में समय के साथ गायब होने का गुण होता है।

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

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

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

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

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

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

निम्नलिखित प्रकाशनों में, हम IDM कार्यान्वयन परियोजना के संगठन को संबोधित करेंगे, साथ ही रोल मॉडल बनाने के लिए विभिन्न व्यावहारिक दृष्टिकोण।

पीएस ने विषय का नाम बदल दिया ताकि यह बेहतर रूप से अपने सार को प्रतिबिंबित करे।
था: पहचान प्रबंधन - व्यक्तिगत डेटा प्रबंधन की मूल बातें
अब: पहचान प्रबंधन - खाता प्रबंधन की मूल बातें