أفضل الممارسات للاحتفاظ بكلمات المرور في البرامج النصية لـ Shell/Perl؟
https://stackoverflow.com/questions/80612
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد اضطررت مؤخرًا إلى التخلص من مهاراتي في البرمجة النصية لـ Perl و Shell لمساعدة بعض الزملاء.تم تكليف الزملاء المعنيين بتقديم بعض التقارير من تطبيق داخلي بواجهة خلفية كبيرة لقاعدة بيانات Oracle، وهم ببساطة لا يمتلكون المهارات اللازمة للقيام بذلك.في حين أن البعض قد يتساءل عما إذا كنت أمتلك هذه المهارات أيضًا (ابتسامة)، فمن الواضح أن عددًا كافيًا من الناس يعتقدون أنني أمتلكها مما يعني أنني لا أستطيع التخلص منها.
لذا بالنسبة لسؤالي - من أجل استخراج التقارير من قاعدة البيانات، من الواضح أن البرنامج النصي الخاص بي يحتاج إلى الاتصال بالاستعلامات وتشغيلها.لم أتمكن حتى الآن من التوصل إلى حل جيد لمكان تخزين اسم المستخدم وكلمة المرور لقاعدة البيانات، لذا يتم تخزينهما حاليًا كنص عادي في البرنامج النصي.
هل هناك حل جيد لهذا الأمر كتبه شخص آخر بالفعل، ربما كوحدة CPAN؟أم أن هناك شيئًا آخر من الأفضل القيام به - مثل الاحتفاظ بمجموعة المستخدم/كلمة المرور في ملف منفصل تمامًا ومخفي في مكان آخر في نظام الملفات؟أم يجب أن أبقيها مشفرة بشكل تافه لتجنب سحبها من البرامج النصية الخاصة بي باستخدام grep على مستوى النظام؟
يحرر:توجد قاعدة بيانات Oracle على خادم HP-UX.
خادم التطبيق (الذي يقوم بتشغيل البرامج النصية Shell) هو Solaris.
يعد تعيين البرامج النصية لتكون مملوكة لي فقط أمرًا محظورًا، حيث يجب أن تكون مملوكة من خلال حساب خدمة يمكن للعديد من موظفي الدعم الوصول إليه.
تهدف البرامج النصية إلى تشغيلها كوظائف كرون.
أرغب في استخدام مصادقة المفتاح العام، ولكني لست على دراية بالطرق التي تجعل ذلك يعمل مع Oracle - إذا كان هناك مثل هذه الطريقة - فيرجى تنويري!
المحلول
أفضل الممارسات، IMHO، هي عدم الاحتفاظ بأي كلمات مرور في برنامج نصي Shell/Perl.هذا هو الغرض من مصادقة المفتاح العام.
نصائح أخرى
إذا كان البرنامج النصي يعمل عن بعد من الخادم.
- جعل مشاهدات التقارير الخاصة بك
- امنح المستخدم الذي تقوم بتسجيل الدخول إليه حق الوصول فقط لتحديد طرق عرض التقرير
- فقط قم بتخزين كلمة المرور.
وبهذه الطريقة، كل ما يمكن للمستخدم فعله هو تحديد البيانات لتقريره.حتى لو حصل شخص ما على كلمة المرور، فسيكون محدودًا فيما يمكنه فعله بها.
أنا شخصياً أحتفظ بكلمات المرور في ملفات التكوين التي يتم بعد ذلك توزيعها بشكل مستقل عن التطبيق، ويمكن تغييرها إلى الجهاز/البيئة المحددة.في برامج شل النصية، يمكنك الحصول عليها من داخل البرنامج النصي الرئيسي.
ومع ذلك، في بيرل هناك مجموعة متنوعة من الأساليب.قد ترغب في التحقيق Getopt::طويل لخيارات سطر الأوامر (وبالإضافة إلى ذلك Getopt::ArgvFile لتخزينها في ملف تكوين بسيط)، أو انظر إلى شيء مثل التكوين::IniFiles لشيء مع المزيد من القوة وراءه.هذان هما النوعان اللذان أستخدمهما بشكل عام، ولكن هناك وحدات أخرى لملفات التكوين متاحة.
لا يوجد حل جيد.يمكنك إخفاء كلمات المرور قليلاً، لكن لا يمكنك تأمينها.
إذا كان لديك سيطرة على إعداد قاعدة البيانات الخاصة بك، فيمكنك محاولة الاتصال عبر أنبوب مسمى (على الأقل يدعم mysql ذلك) بدون كلمة مرور والسماح لنظام التشغيل بالتعامل مع الأذونات.
يمكنك أيضًا تخزين بيانات الاعتماد في ملف بأذونات مقيدة.
منذ أن قمت بوضع علامة ksh & bash، سأفترض نظام التشغيل Linux.
تكمن معظم المشكلة في أنه إذا تمكن المستخدم من قراءة البرنامج النصي وتحديد الطريقة التي استخدمتها لإخفاء/تشفير الملف، فسيتمكن أيضًا من القيام بنفس الشيء يدويًا.
قد تكون الطريقة الأفضل هي القيام بما يلي:
- أنشئ البرنامج النصي الخاص بك بحيث لا يمكن لأحد سواك رؤيته/قراءته/فتحه.شمود 700 ذلك.كلمات المرور الصلبة بعيدا.
- احصل على برنامج نصي "launcher" قابل للتنفيذ من قبل المستخدم ويقوم بتنفيذ الأمر sudo .
بهذه الطريقة يمكن للمستخدم رؤية البرنامج النصي للمشغل الخاص بك، وفحصه ليرى أنه يحتوي فقط على سطر أوامر واحد.يمكنهم تشغيله ويعمل، لكن ليس لديهم الأذونات لقراءة مصدر البرنامج النصي Sudo'd.
لست متأكدًا من إصدار Oracle الذي تستخدمه.في الإصدار الأقدم من Oracle (ما قبل 9i Advanced Security) قد يكون هناك بعض DBA CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY وحدد REMOTE_OS_AUTHENT إلى صحيح.
قد يعني هذا أن جهاز الشمس البعيد الخاص بك يمكنه مصادقتك كـ SCOTT ومن ثم ستقبل قاعدة بيانات Oracle الخاصة بك هذه المصادقة.
هذه فكرة سيئة.
كما يمكنك تصوير أي نظام تشغيل Windows XP مع مستخدم محلي لـ SCOTT، يمكنه بعد ذلك تسجيل الدخول إلى قاعدة البيانات الخاصة بك بدون كلمة مرور.
لسوء الحظ، هذا هو الخيار الوحيد الذي أعرفه في Oracle 9i DBs لعدم تخزين اسم المستخدم/كلمات المرور في البرنامج النصي الخاص بك أو في مكان آخر يمكن الوصول إليه بواسطة جهاز العميل.
أيًا كان الحل الذي تقدمه، فمن المفيد إلقاء نظرة على Oracle تأمين المشروع قبل الالتزام.
لتخزين كلمات المرور، يمكنك إجراء روتين تشفير من خطوتين، أولاً باستخدام مفتاح مضمن في البرنامج النصي نفسه، واختياريًا مرة ثانية باستخدام مفتاح مخزّن في ملف (والذي يتم تعيينه باستخدام أذونات الملف لتقييد الوصول).
في موقف معين، يمكنك إما استخدام ملف مفتاح (+ مفتاح من البرنامج النصي)، أو إذا لم تكن متطلبات الموقف كبيرة، فيمكنه فقط استخدام التشفير باستخدام المفتاح المشفر في البرنامج النصي.في كلتا الحالتين سيتم تشفير كلمة المرور في ملف التكوين.
لا يوجد حل مثالي لأنه بطريقة ما يجب أن تكون قادرًا على فك التشفير والحصول على كلمة مرور النص الواضح... وإذا كان بإمكانك القيام بذلك، فيمكن لشخص آخر القيام بذلك أيضًا إذا كان لديه المعلومات الصحيحة.
خاصة في الحالة التي نمنحهم فيها نصًا برمجيًا لـ Perl (مقابل برمجية Perl).exe) يمكنهم بسهولة رؤية كيفية قيامك بالتشفير (والمفتاح المشفر)... ولهذا السبب يجب عليك السماح بخيار استخدام ملف مفتاح (يمكن حمايته بواسطة أذونات نظام الملفات) أيضًا.
بعض الأمثلة العملية لكيفية التنفيذ هنا
في UNIX، أقوم دائمًا بإعداد هذه البرامج النصية وتخزين معلومات المستخدم وكلمة المرور في ملف محمي بشدة (شجرة الدليل بأكملها غير قابلة للقراءة/البحث من قبل المستخدمين العاديين والملف نفسه قابل للقراءة فقط من قبل مالك البرنامج النصي) .
احتفظ بها في ملف منفصل، مشفر بشكل تافه، وقم بإنشاء مستخدم منفصل في قاعدة البيانات مع حق الوصول للقراءة فقط إلى الجداول الضرورية.إذا كنت تعتقد أن الملف قد تمت قراءته، فيمكنك إيقاف الوصول إلى هذا المستخدم فقط.
إذا كنت ترغب في الحصول على مظهر مميز، فيمكن لبرنامج SUID التحقق من /proc//exe وcmdline (في Linux)، ثم تحرير اسم المستخدم فقط.
لدي/واجهت مشكلة مماثلة مع المطورين الذين ينشرون كود SQL إلى MSSQL (في الواقع إلى أي قاعدة بيانات على خادم MSSQL، لذلك يجب أن يكون الدور هو SysAdmin) باستخدام ANT من خادم Solaris.مرة أخرى، لم أرغب في تخزين اسم المستخدم وكلمة المرور في ملفات ANT build.xml، لذا فإن الحل الذي أعرفه ليس مثاليًا، هو كما يلي:
- قم بتخزين أزواج الاسم/القيمة لاسم المستخدم وكلمة المرور في ملف نصي عادي
- قم بتشفير الملف (على Solaris) واستخدم عبارة مرور معروفة لبعض المسؤولين فقط
- اترك فقط الملف المشفر على نظام سولاريس
- يقوم ANT build.xml بتشغيل فك تشفير Sudo ويطالب بعبارة المرور، التي يتم إدخالها بواسطة المشرف
- قامت مصادر ANT بفك تشفير ملف تحميل اسم المستخدم وكلمة المرور كمتغيرات لسلسلة SQL
- قام ANT على الفور بحذف ملف النص العادي
- ينشر ANT الكود ويخرج
يحدث كل هذا في غضون ثوانٍ، ولا يمكن الوصول إلى اسم مستخدم وكلمة مرور SQL بشكل واضح على الخادم.نظرًا لأنه يتم نشر التعليمات البرمجية بواسطة المسؤولين المسموح لهم في الإنتاج، فلن يحتاج المطورون أبدًا إلى تضمينها في التعليمات البرمجية الخاصة بهم.
أنا متأكد من أنه يمكن أن يكون أفضل، ولكن...
جي بي
من المؤسف أنني لم أر هذا الموضوع من قبل - فهو يبدو مثيرًا للاهتمام للغاية.سأضيف سنتي لأي شخص يأتي إلى الموضوع في المستقبل.
أوصي باستخدام مصادقة نظام التشغيل على خادم قاعدة البيانات نفسه - REMOTE_OS_AUTHENT لا يزال خطأ.
إذا كنت تستدعي البرنامج النصي من جهاز آخر، فقم بإعداد مفتاح SSH بدون عبارة واستخدم SSH للوصول إلى هناك.يمكنك بعد ذلك إرسال نتائج SQL إلى جهاز الاستدعاء ويمكنه معالجة هذه المعلومات بشكل أكبر.
يؤدي القيام بذلك إلى تجنب الاضطرار إلى ترميز كلمة المرور في أي مكان.بالطبع، إذا قام مسؤول ضار باختطاف المفتاح الخالي من العبارة واستخدامه، فيمكنه أيضًا الوصول إلى حساب المستخدم على مضيف قاعدة البيانات ويمكنه بعد ذلك القيام بأي عمليات يمكن لمستخدم قاعدة البيانات المصادق عليها من نظام التشغيل.للتخفيف من ذلك، يمكنك تقليل أذونات قاعدة البيانات لمستخدم نظام التشغيل هذا إلى الحد الأدنى - دعنا نقول "للقراءة فقط".
إنغو
في نظام التشغيل Windows، قم بإنشاء مجلد وملف بداخله يحتوي على كلمات المرور بنص واضح.قم بتعيين المستخدم الذي سيقوم بتشغيل المهمة المجدولة (البرنامج النصي أو الدفعي) باعتباره الشخص الوحيد الذي لديه حق الوصول للقراءة/الكتابة إلى هذا المجلد والملف.(إزالة حتى المسؤول).إلى كافة البرامج النصية الأخرى، قم بإضافة تعليمات برمجية لقراءة كلمة المرور ذات النص الواضح من هذا الملف المقيد.
وهذا ينبغي أن يكون كافيا لعدد قليل.
الكلمات الدالة:الترميز الثابت لكلمة المرور
هناك حلول تجارية أو أكثر تقدمًا مثل Cyberark AIM يمكن أن تفعل ذلك بشكل أفضل، ولكن عند القيام بذلك مجانًا وخارج الصندوق، فقد قمت بحمل مفتاح SSH العام/الخاص لأنه من المرجح أن أزواج مفاتيح SSH التي تم إنشاؤها بالفعل تتوافق مع مفتاح SSH العام/الخاص. السياسة الأمنية؛ثانيًا، تحتوي أزواج مفاتيح SSH بالفعل على مجموعة من البروتوكولات القياسية لحماية المفاتيح من خلال إذن الملف، أو التعزيز المستمر للنظام (مثل سلك التعثر)، أو تدوير المفتاح.
هذه هي الطريقة التي فعلت ذلك:
قم بإنشاء أزواج مفاتيح ssh إن لم يكن بعد.ستتم حماية أزواج المفاتيح والدليل بواسطة بروتوكول/إذن النظام الافتراضي.سش-كيجن –t rsa –b 2048
استخدم SSH Public Key لتشفير السلسلة وتخزينها في نفس دليل .SSH $ ECHO "Secretword" | Openssl rsautl -Encrypt -inkey ~/.ssh/id_rsa.pub -pubin -out ~/.ssh/secret.dat
استخدم مفتاح ssh الخاص لفك تشفير المفتاح وتمرير المعلمات إلى البرامج النصية/AP في الوقت الفعلي.البرنامج النصي/البرنامج الذي يتضمن السطر لفك التشفير في الوقت الفعلي:سلسلة =
openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat
ملاحظة: لقد قمت بتجربة حل CYBERARK AIM بدون وكيل.إنه نوع من الألم يتطلب تغييرات كبيرة/تغييرات في واجهة برمجة التطبيقات لواجهة برمجة التطبيقات/البرنامج النصي.سوف ابقيكم على علم كيف ستسير الأمور.
