डेवलपर्स से संवेदनशील डेटा सुरक्षित करना

61

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

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

मेरे लिए यह संभव नहीं लगता है क्योंकि यदि एप्लिकेशन के पास डेटाबेस तक पहुंच है तो मशीन और एप्लिकेशन स्रोत तक पहुंच वाला एक डेवलपर हमेशा डेटा एक्सेस कर पाएगा।

server-security

— क्लिंटन बॉश
स्रोत

30

उपयोगकर्ताओं को संवेदनशील डेटा को केवल एन्क्रिप्टेड रूप में संग्रहीत किया जाना चाहिए। अगर डेवलपर्स एन्क्रिप्टेड फॉर्म तक पहुंच सकते हैं, तो एक बड़ी समस्या नहीं होनी चाहिए, जब तक कि मिलान कुंजी उनसे ठीक से परिरक्षित हो।

— 13

3

@ क्लिंटन क्या आपके पास अलग-अलग व्यवस्थापक और डेवलपर टीम हैं? सर्वर व्यवस्थापक हमेशा डेटा को पढ़ सकता है और एन्क्रिप्शन मदद नहीं करता है क्योंकि वे आसानी से कुंजी प्राप्त कर सकते हैं।

— कोडइन्चोस 15

14

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

— maple_shaft

3

सूचना सुरक्षा स्टैक एक्सचेंज पर पूछने लायक हो सकता है। इस प्रश्न

— paj28

23

मनुष्य सर्वर को क्यों छू रहे हैं और कोड को तैनात कर रहे हैं?

— व्याट बार्नेट 15

89

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

जैसा कि यह खड़ा है आपने एक सुरक्षा चिंता का झंडा लगाया है जो एक अच्छा पहला कदम है। अब आपको एक न्यूनतम के रूप में परिभाषित करना होगा: -

आप किस डेटा की सुरक्षा करने की कोशिश कर रहे हैं?
आप उस डेटा को किससे सुरक्षित रखने का प्रयास कर रहे हैं?
कौन वास्तव में करने के लिए उपयोग की जरूरत है क्या (और जब)?
उस डेटा के कानूनी / वित्तीय / व्यावसायिक प्रभाव से क्या समझौता किया जा रहा है?
डेटा तक पहुंच रखने वाले व्यक्ति / समूह के लिए कानूनी / वित्तीय / व्यावसायिक आवश्यकता क्या है?
जब व्यवसाय पहले से ही व्यापार की आवश्यकता नहीं थी, तो "सुरक्षित, सुरक्षित रहें" रणनीति को निर्दिष्ट करने के लिए तैयार बजट क्या बजट है?
डेटा तक सिस्टम की क्या पहुँच है?
यह प्रक्रिया और सिस्टम क्या इस एप्लिकेशन पर निर्भर करता है?
उन वातावरणों को सुरक्षित करने के लिए क्या किया जाता है?
इसे लागू करने और पूरी प्रक्रिया की समीक्षा करने के लिए कौन जिम्मेदार है?

जब तक आप उन सभी को विस्तार से नहीं जानते हैं, तब तक आपके पास काम करने के लिए कुछ भी नहीं है। यह जानकारी परिभाषित करेगी कि उन खतरों के बारे में क्या आप पर लागू होते हैं (और नहीं कर सकते) और क्यों।

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

— जेम्स स्नेल
स्रोत

33

वाह ... जो सुरक्षा ध्वनि बनाता है ... गैर-तुच्छ। (व्यंग्य के लिए खेद है; मैंने इससे बहुत से लोगों को आश्चर्यचकित देखा है।)

— पॉल ड्रेपर

4

मेरा मानना है कि कई लोगों को लगता है कि एक जादू make-application-secureकमांड है जिसे उन्हें बस चलाने की आवश्यकता है।

— TMH

27

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

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

(यह भी ध्यान दें कि ऐसा व्यवसाय मॉडल राजनीतिक रूप से अस्थिर हो रहा है। व्यापार करने वालों को वास्तव में ऐसा करने की कोशिश करने के लिए सुरक्षा सेवाओं द्वारा ऑपरेशन से बाहर कर दिया गया है। मैं समझता हूं कि गोपनीयता की गारंटी देने का व्यवसाय मूल्य है, लेकिन यह संभवतः अधिक नहीं हो सकता है। व्यवसाय में रहने के मूल लक्ष्य की तुलना में व्यावसायिक मूल्य।)

— किलियन फोथ
स्रोत

6

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

— सुपरकैट

5

आप सही हैं, मैं पूरी तरह से शून्य-ज्ञान होस्टिंग के संभावित विकल्प के रूप में लेखा परीक्षा का उल्लेख करना भूल गया । यह हासिल करना कुछ आसान है और व्यावसायिक मामले के लिए अक्सर पर्याप्त है।

— किलिऑन फोथ

आपका अंतिम पैराग्राफ। क्या आप लावाबिट-प्रकार की कहानियों का जिक्र कर रहे हैं? मैं उलझन में हूं।

— jpmc26

1

@supercat आपको यह भी विश्वास करना होगा कि हार्डवेयर के रचनाकारों ने इसे वही किया है जो उन्होंने कहा था।

— user253751

2

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

— सुपरकैट

15

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

With great power comes great ... opportunity to really, *really* foul things up.

कई डेवलपर्स यह जिम्मेदारी और अन्य नहीं चाहेंगे, बस इसे धारण करने के लिए "तैयार" नहीं होगा, और इसलिए ऐसा नहीं होना चाहिए।

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

क्या आपके पास डेवलपर्स और कंपनी के बीच किसी प्रकार का गैर-प्रकटीकरण / गोपनीयता समझौता है? यह भारी-भरकम है, लेकिन इसमें कुछ योग्यता हो सकती है।

— फिल डब्ल्यू।
स्रोत

जो अभी भी निर्धारित गलत को आवेदन में पिछले दरवाजे को छिपाने से नहीं रोकेगा, लेकिन यह उस अवसर को कम करता है जो चोर बनाता है।

— Jan Hudec

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

— क्लिंटन बॉश

@JanHudec विशेष रूप से कोड जोड़ने के बाद से अनुप्रयोग संस्करण नियंत्रण में निशान छोड़ देता है।

— कोडइन्चोस

@CodesInChaos: अच्छा प्रोग्रामर एक ईमानदार गलती की तरह पिछले दरवाजे को देख सकता है। आप उन पर शक करेंगे, लेकिन आप उनके खिलाफ कभी केस नहीं करेंगे। लेकिन हाँ, यह रक्षा की एक और पंक्ति है।

— Jan Hudec

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

— सिल्वरलाइटफॉक्स

9

समस्या है आपके डेवलपर्स को सिस्टम तक पहुँच की। यदि उन्हें डिबगिंग के लिए उत्पादन डेटा की आवश्यकता है, तो उन्हें एक डेटाबेस डंप दें जहां उस सभी संवेदनशील जानकारी को हटा दिया जाता है। तब डेवलपर्स उस डंप के साथ काम कर सकते हैं।

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

— SpaceTrucker
स्रोत

1

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

— क्लिंटन बॉश

2

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

— स्पेसट्रूकर

4

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

— maple_shaft

6

सुरक्षा का नियम # 1: यदि किसी की जानकारी तक पहुँच है, तो उस जानकारी तक उसकी पहुँच है

वह तनातनी कष्टप्रद है, लेकिन यह सच है। यदि आप किसी व्यक्ति को एक्सेस देते हैं, तो उनके पास डेटा तक पहुंच है। उपयोगकर्ताओं के लिए, इसका मतलब आमतौर पर अभिगम नियंत्रण है, लेकिन डेवलपर्स के लिए ... अच्छी तरह से ... वे हैं जिन्हें अभिगम नियंत्रण लिखना है।

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

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

पैटर्न बाहर की ओर फैली हुई है।

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

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

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

— Cort Ammon
स्रोत

3

एप्लिकेशन के दो परिनियोजन सेट करें जो अलग-अलग डेटाबेस परिनियोजन का भी उपयोग करते हैं। एक उत्पादन परिनियोजन है और एक परीक्षण परिनियोजन है।

परीक्षण परिनियोजन में केवल परीक्षण डेटा होना चाहिए। यह या तो फंतासी डेटा हो सकता है जो उस उद्देश्य के लिए बनाया गया है या उत्पादन डेटा की एक प्रति है जो डेवलपर्स को डेटा के पीछे वास्तविक लोगों और संस्थाओं का पता लगाने से रोकने के लिए अज्ञात था।

— फिलिप
स्रोत

हाँ, यह ठीक ऐसा ही परिदृश्य है जो हमारे पास है। लेकिन किसी बिंदु पर किसी को तैनाती / डेटा माइग्रेशन की सुविधा के लिए उत्पादन वातावरण पर काम करने की आवश्यकता है

— क्लिंटन बॉश

3

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

— क्लो
स्रोत

-1

MongoDB के पास सीमित सुरक्षा नियंत्रण हैं और यह एक सुरक्षित वातावरण पर निर्भर करता है। एक विशिष्ट आईपी और पोर्ट से बाइंडिंग (और 2.2 से ssl), और एक क्रूड ऑथेंटिकेशन, यही वह प्रदान करता है। MYSQL db.t TO GRANT o ON को जोड़ता है ... बाकी पर डेटा एन्क्रिप्ट नहीं किया गया है, और डिफ़ॉल्ट रूप से ssl का उपयोग नहीं किया जाता है। एक बाड़ बनाएँ। डेवलपर्स के लिए एप्लिकेशन से संबंधित लॉग फाइल के लिए आसानी से एक्सेस डिबग करने के लिए पर्याप्त होना चाहिए। एप्लिकेशन जीवनचक्र को स्वचालित करें।

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

— bbaassssiiee
स्रोत