डोमेन व्यवस्थापक खाता नीति (PCI ऑडिट के बाद)

Question

हमारे ग्राहकों में से एक टियर 1 पीसीआई कंपनी है, और उनके लेखा परीक्षकों ने हमें सिस्टम एडमिनिस्ट्रेटर और हमारे एक्सेस अधिकारों के संबंध में एक सुझाव दिया है।

हम लगभग 700 डेस्कटॉप / 80 सर्वर / 10 डोमेन नियंत्रकों के उनके पूरी तरह से विंडोज आधारित बुनियादी ढांचे का प्रबंधन करते हैं।

वे सुझाव दे रहे हैं कि हम एक ऐसी प्रणाली की ओर बढ़ें, जहाँ हमारे तीन अलग-अलग खाते हैं:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• जहाँ WS वह खाता है जो केवल WorkStations पर लॉग ऑन करता है, WorkStations पर एक स्थानीय प्रशासक है
• जहां SRV वह खाता है जो केवल नॉन डीसी सर्वर पर लॉग ऑन करता है, सर्वर पर स्थानीय प्रशासक है
• जहाँ DC वह खाता है जो केवल डोमेन नियंत्रकों पर प्रभावी रूप से एक डोमेन व्यवस्थापक खाते में लॉग ऑन करता है

गलत तरीके से लॉगऑन को गलत खाते से रोकने के लिए नीतियां फिर से हैं (जिसमें गैर डीसी मशीनों पर डोमेन व्यवस्थापक खातों के लिए इंटरैक्टिव लॉगऑन को निकालना शामिल है)

यह उस स्थिति को रोकने के लिए है जहां एक समझौता कार्य केंद्र डोमेन प्रशासक लॉगऑन टोकन और डोमेन नियंत्रक के खिलाफ फिर से उपयोग करने का खुलासा कर सकता है।

यह न केवल हमारे दिन-प्रतिदिन के कार्यों के लिए एक बहुत ही दखल देने वाली नीति प्रतीत होती है, बल्कि काफी मात्रा में काम करने वाली भी है, जो यह पता लगाने के लिए है कि एक अपेक्षाकृत अप्रत्याशित हमला / शोषण है (यह मेरी समझ वैसे भी है, शायद मैं इस शोषण की व्यवहार्यता को गलत समझता हूं। ।

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

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

Comments

टियर 1 होने के नाते, मैं वास्तव में हैरान हूं कि उनका नेटवर्क जो सीसी भुगतान लेता है, उसी नेटवर्क पर है जो यह विंडोज इन्फ्रास्ट्रक्चर चालू है और खंडित नहीं है। अनुपालन को बहुत आसान बनाता है।

— क्लेनर

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

— पैट्रिक

मैं यहाँ पीसीआई विशेषज्ञ नहीं हूँ ... वहाँ कुछ मैं हालांकि आसपास देखा है। हालाँकि, मुझे ऐसा कुछ याद नहीं है कि यह एक आवश्यकता है। बनाम सुझाव देना एक बड़ा अंतर है। मैं आपके अंतिम पैराग्राफ में आपके द्वारा कहे गए कामों को पूरा करने के लिए कड़ी मेहनत करूँगा, यह सुनिश्चित करने के लिए उपाय करना कि यह एक वास्तविकता है।

— क्लेनर

सर्वरफॉल्ट.com / questions / 224467 /… के समान अनुभव की तरह लगता है - अनिवार्य रूप से, यह एक अच्छी योजना है, और कुछ बुरा हमलों को रोक सकता है।

— इयान हैलम

Answer 1

मैं एक टियर 1 PCI विक्रेता पर हूँ। हमारे पास जगह में ऐसा कुछ है, कुछ मतभेदों के साथ।

ऑडिटर वास्तव में एक बहुत ही वास्तविक समस्या का वर्णन करने का प्रयास कर रहे हैं, लेकिन निहितार्थ और विश्लेषण की आवश्यकता के बारे में एक अविश्वसनीय रूप से खराब काम कर रहे हैं।

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

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

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

यहाँ मैं नीचता पर विचार करूंगा:

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

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

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

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

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

• अपने कार्य केंद्र से प्रशासनिक कार्य न करें। हार्ड सर्वर या जंप सर्वर का उपयोग करें।

• अपने कूद बॉक्स के रूप में VMs को आसानी से रीसेट करने का उपयोग करने पर विचार करें, जिसे प्रत्येक सत्र के बाद मेमोरी को खाली करने के लिए रीसेट किया जा सकता है।

आगे की पढाई:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

माइक्रोसॉफ्ट खुफिया सुरक्षा रिपोर्ट, खंड 13 जनवरी - जून 2012
http://www.microsoft.com/security/sir/archive/default.aspx

अनुभाग पढ़ें: "पास-ए-हश हमलों के खिलाफ बचाव"।

हार से खौफजदा दर-दर हश्र हमले
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753