शैल/पर्ल स्क्रिप्ट में पासवर्ड रखने के लिए सर्वोत्तम अभ्यास?

Question

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

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

क्या इसके लिए कोई अच्छा समाधान है कि किसी और ने पहले से ही एक सीपीएएन मॉड्यूल के रूप में लिखा है? या क्या ऐसा कुछ और है जो करना बेहतर है - जैसे कि उपयोगकर्ता/पासवर्ड कॉम्बो को पूरी तरह से अलग फ़ाइल में रखें जो फाइल सिस्टम पर कहीं और छिपा हुआ है? या क्या मुझे उन्हें सिस्टम-व्यापी grep के साथ अपनी स्क्रिप्ट से बाहर खींचने से बचने के लिए उन्हें छोटा रूप से एन्क्रिप्ट किया जाना चाहिए?

संपादित करें: ओरेकल डेटाबेस एक एचपी-यूएक्स सर्वर पर बैठता है।
एप्लिकेशन सर्वर (खोल स्क्रिप्ट चलाने) Solaris है।
केवल मेरे द्वारा स्वामित्व वाली स्क्रिप्ट को सेट करना एक नो-गो है, उन्हें एक ऐसे सेवा खाते के स्वामित्व में होना चाहिए जो एकाधिक सहायता कर्मियों तक पहुंच सके।
स्क्रिप्ट को क्रॉन नौकरियों के रूप में चलाने का इरादा है।
मुझे सार्वजनिक कुंजी प्रमाणीकरण के साथ जाना अच्छा लगेगा, लेकिन ओरेकल के साथ यह काम करने के तरीकों से अनजान है - अगर ऐसी कोई विधि है - मुझे प्रबुद्ध करें!

Answer 1

सर्वश्रेष्ठ अभ्यास, आईएमएचओ, एक खोल/पर्ल स्क्रिप्ट में कोई पासवर्ड नहीं रखेगा। सार्वजनिक कुंजी प्रमाणीकरण यही है।

Answer 2

कोई अच्छा समाधान नहीं है। आप पासवर्ड को थोड़ा सा खराब कर सकते हैं, लेकिन आप उन्हें सुरक्षित नहीं कर सकते हैं।

यदि आपके डीबी सेटअप पर नियंत्रण है, तो आप पासवर्ड के बिना किसी नामित पाइप (कम से कम mysql का समर्थन करता है) से कनेक्ट करने का प्रयास कर सकते हैं और ओएस को अनुमतियों को संभाल सकते हैं।

आप प्रतिबंधक अनुमतियों वाली फ़ाइल में प्रमाण-पत्र भी संग्रहीत कर सकते हैं।

Answer 3

चूंकि आपने ksh & बैश टैग किया है, मैं लिनक्स मानने जा रहा हूं।

अधिकांश समस्या यह है कि यदि उपयोगकर्ता स्क्रिप्ट को पढ़ सकता है और फ़ाइल को छुपाने/एन्क्रिप्ट करने के लिए उपयोग की जाने वाली विधि का पता लगाता है तो वे मैन्युअल रूप से वही काम करने में सक्षम होंगे।

एक बेहतर तरीका निम्न कार्य किया जा सकता है:

1. अपनी स्क्रिप्ट तो यह केवल देखा जा सकता है/पढ़ने/आपके द्वारा खोले करें। chmod 700 यह। हार्डकोड पासवर्ड दूर।
2. एक "लॉन्चर" स्क्रिप्ट है जो उपयोगकर्ता द्वारा निष्पादन योग्य है और एक सूडो करता है।

इस प्रकार उपयोगकर्ता आपकी लॉन्चर स्क्रिप्ट देख सकता है, इसे देखने के लिए जांचें कि इसमें केवल एक कमांड लाइन है। वे इसे चला सकते हैं और यह काम करता है, लेकिन उन्हें स्क्रिप्ट के लिए स्रोत को पढ़ने की अनुमति नहीं है।

Answer 4

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

Answer 5

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

यदि आप फैंसी प्राप्त करना चाहते हैं, तो एक SUID प्रोग्राम/proc // exe और cmdline (लिनक्स में) की जांच कर सकता है, और उसके बाद ही उपयोगकर्ता नाम जारी कर सकता है।

Answer 6

यदि स्क्रिप्ट सर्वर से दूरस्थ रूप से चल रही है।

1. अपनी रिपोर्ट विचारों
2. उपयोगकर्ता आप ही पहुँच में प्रवेश कर रहे हैं रिपोर्ट पर चयन करने के लिए विचार
3. बस पासवर्ड की दुकान दें बनाओ।

इस तरह, उपयोगकर्ता जो भी कर सकता है, उसकी रिपोर्ट के लिए डेटा का चयन कर रहा है। यहां तक ​​कि अगर कोई पासवर्ड प्राप्त करने के लिए होता है, तो वे इस बात तक सीमित होंगे कि वे इसके साथ क्या कर सकते हैं।

Answer 7

मुझे यकीन नहीं है कि आप ओरेकल का कौन सा संस्करण चला रहे हैं। ओरेकल (पूर्व 9i उन्नत सुरक्षा) के पुराने संस्करण पर कुछ डीबीए CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY होगा और REMOTE_OS_AUTHENT को सत्य पर सेट करें।

इसका मतलब यह होगा कि आपकी रिमोट सन मशीन आपको एससीओटीटी के रूप में प्रमाणित कर सकती है और फिर आपका ओरेकल डीबी उस प्रमाणीकरण को स्वीकार करेगा।

यह एक बुरा विचार है।

जैसा कि आप किसी भी विंडोज एक्सपी को एससीओटीटी के स्थानीय उपयोगकर्ता के साथ चित्रित कर सकते हैं, फिर पासवर्ड के बिना अपने डीबी में लॉग इन कर सकते हैं।

दुर्भाग्यवश यह एकमात्र विकल्प है जिसे मैं ओरेकल 9आई डीबी के बारे में जानता हूं ताकि आपकी स्क्रिप्ट में उपयोगकर्ता नाम/पासवर्ड स्टोर न हो या क्लाइंट मशीन द्वारा कहीं और सुलभ न हो।

क्या करने से पहले ओरेकल के Project Lockdown के माध्यम से आपका समाधान क्या सार्थक है।

Answer 8

मेरे पास एसएसएल कोड को एमएसएसक्यूएल (वास्तव में उस एमएसएसएलएल सर्वर पर किसी भी डेटाबेस पर तैनात करने वाले डेवलपर्स के साथ एक समान समस्या है, इसलिए सोलारिस सर्वर से एएनटी का उपयोग करके भूमिका को SysAdmin होना था)। एक में उपयोगकर्ता नाम और पासवर्ड के लिए

1. स्टोर नाम/मान युग्म: फिर मैं नहीं यूज़रनेम और पासवर्ड चींटी build.xml फाइलों में स्टोर करने के लिए तो मेरे समाधान है, जो मैं जानता हूँ कि आदर्श नहीं है, इस प्रकार चाहता था है सादा पाठ फ़ाइल
2. एन्क्रिप्ट फ़ाइल (सोलारिस) और एक पास वाक्यांश केवल कुछ व्यवस्थापक
3. के लिए जाना जाता का उपयोग सोलारिस प्रणाली
4. चींटी निर्माण पर केवल एन्क्रिप्टेड फ़ाइल छोड़ दें।एक्सएमएल एक sudo डिक्रिप्ट चलाता है और पास वाक्यांश है, जो व्यवस्थापक
5. चींटी सूत्रों decrypted फ़ाइल लोड हो रहा है यूज़रनेम और पासवर्ड एसक्यूएल स्ट्रिंग के लिए चर के रूप में
6. चींटी तुरंत प्लेन टेक्स्ट फ़ाइल
7. चींटी कोड और बाहर निकलता तैनात नष्ट कर दिया द्वारा दर्ज किया गया है के लिए संकेत देता

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

मुझे यकीन है कि यह बेहतर हो सकता है, लेकिन हूँ ...

जेबी

Answer 9

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

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

Answer 10

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

किसी दिए गए परिस्थिति में आप या तो एक कुंजी फ़ाइल (स्क्रिप्ट से + कुंजी) का उपयोग कर सकते हैं, या यदि स्थिति की आवश्यकताएं इतनी महान नहीं हैं तो वह स्क्रिप्ट में हार्डकोड की गई कुंजी का उपयोग करके एंटरपशन का उपयोग कर सकते हैं। दोनों स्थितियों में पासवर्ड कॉन्फ़िगरेशन फ़ाइल में एन्क्रिप्ट किया जाएगा।

कोई सही समाधान नहीं है क्योंकि किसी भी तरह से आपको क्लीयरएक्स्ट पासवर्ड को डिक्रिप्ट और प्राप्त करने में सक्षम होना चाहिए ... और यदि आप इसे कर सकते हैं तो कोई और भी हो सकता है यदि उनके पास सही जानकारी हो।

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

कैसे लागू करने के लिए के लिए कुछ व्यावहारिक उदाहरण here

Answer 11

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

मैं डीबी सर्वर पर ओएस प्रमाणीकरण का उपयोग करने की सलाह दूंगा - REMOTE_OS_AUTHENT अभी भी गलत है।

यदि आप किसी अन्य मशीन से स्क्रिप्ट का आविष्कार कर रहे हैं, तो एक वाक्यांश-कम एसएसएच कुंजी सेट करें और वहां पहुंचने के लिए एसएसएच का उपयोग करें। फिर आप SQL परिणामों को कॉलिंग मशीन पर वापस पाइप कर सकते हैं और यह इस जानकारी को आगे संसाधित कर सकता है।

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

इंगो

Answer 12

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

यह कुछ के लिए पर्याप्त होना चाहिए।

कीवर्ड: पासवर्ड हार्डकोड

Answer 13

पिग्गी ऐसे cyberark AIM के रूप में वाणिज्यिक या अधिक अग्रिम समाधान बेहतर कर सकते हैं, लेकिन मुक्त करने के लिए और बॉक्स से बाहर कर, मैं किया गया है वापस SSH सार्वजनिक/निजी कुंजी है क्योंकि एक के लिए, एसएसएच कुंजी जोड़े जो पहले से ही बनाए गए हैं सुरक्षा नीति को अनुरूप बनाते हैं; दूसरी बात, एसएसएच कुंजी जोड़े पहले से ही फ़ाइल अनुमति, कुंजी सिस्टम सख्त (जैसे ट्रिपवायर), या कुंजी रोटेशन द्वारा कुंजी की रक्षा के लिए मानक प्रोटोकॉल का एक सेट है।

इस तरह मैंने किया है:

1. यदि अभी तक नहीं ssh कुंजी जोड़े उत्पन्न करें। कुंजी जोड़े और निर्देशिका डिफ़ॉल्ट सिस्टम प्रोटोकॉल/अनुमति द्वारा संरक्षित किया जाएगा। ssh-keygen आयकर आरएसए बी 2048

2. स्ट्रिंग एन्क्रिप्ट और समान .ssh निर्देशिका में संग्रहीत $ गूंज "secretword" करने के लिए सार्वजनिक कुंजी का उपयोग करें | openssl rsautl -encrypt -inkey ~/.ssh/id_rsa.pub -pubin -out ~/.ssh/secret.dat

3. कुंजी को डिक्रिप्ट करने के लिए एसएसएच निजी कुंजी का उपयोग करें, और पैरामीटर को स्क्रिप्ट/एपी में पास करें रियल टाइम। स्क्रिप्ट/programe वास्तविक समय में डिक्रिप्ट करने के लिए लाइन में शामिल करने के लिए: स्ट्रिंग = openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat

पुनश्च - मैं CYBERARK AIM agentless समाधान प्रयोग कर रहे हैं। इस तरह के दर्द के लिए एपीआई/स्क्रिप्ट के लिए महत्वपूर्ण परिवर्तन/एपीआई परिवर्तन की आवश्यकता होती है। आपको पोस्ट करेगा कि यह कैसे चला जाता है।