Restic: असममित बैकअप का समर्थन करें

पिछली चर्चा से एक संक्षिप्त पुनर्कथन:

• ईमेल सर्वर के बैकअप या लॉग डेटा के रिमोट बैकअप के लिए उपयोगी है, जब ऐसे सर्वर से छेड़छाड़ की जाती है। सर्वर से कटा हुआ संवेदनशील डेटा बैकअप में मौजूद हो सकता है, और इस तरह के ऐतिहासिक डेटा तक हमलावर पहुंच से इनकार करने में सक्षम होना उपयोगी हो सकता है। साथ ही इस बात पर भी चर्चा की गई कि एक क्षमता प्रणाली के साथ "ब्लॉब नेटवर्क सर्वर" का होना उपयोगी हो सकता है जो आपको उपयुक्त के रूप में केवल-केवल/पढ़ने के लिए/पढ़ने-लिखने की पहुंच को कॉन्फ़िगर करने की अनुमति देता है। असममित क्रिप्टोग्राफी होने से क्षमताओं को जारी करने के लिए सममित कुंजी के _अभी तक_ सेट होने की आवश्यकता को हटा दिया जाएगा, और संभवतः एक क्षमता प्रणाली के कार्यान्वयन को भी सरल बना देगा।
• कई मशीनों के साथ एक सेटिंग में, _one_ बैकअप कुंजी का उपयोग कई बैकअप डेटासेट तक पहुंचने के लिए किया जा सकता है, बिना कई सममित कुंजियों को प्रबंधित किए। यदि एक क्रिप्टोसिस्टम जैसे कि डैनियल बर्नस्टीन के कर्व 25519 का उपयोग किया जाता है, तो ऐसी कुंजी एक पासफ़्रेज़ से ली जा सकती है, जिसका अर्थ है कि आप विभिन्न सुरक्षा डोमेन की (संभावित रूप से बड़ी) संख्या द्वारा बनाए गए बैकअप को प्रबंधित करने के लिए एक मास्टर पासफ़्रेज़ का उपयोग कर सकते हैं। हालांकि कुछ ऐसा ही निश्चित रूप से n सममित कुंजियों और एक एन्क्रिप्टेड कुंजी भंडारण के साथ प्राप्त किया जा सकता है।

@heipei FYI करें आप इस मुद्दे की सदस्यता लेना चाह सकते हैं

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

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

डेटा गोपनीयता ( write-only ) इन परिदृश्यों के लिए असममित क्रिप्टो के कार्यान्वयन के साथ प्राप्त करने योग्य होगी।

डेटा अखंडता थोड़ा अलग जानवर है:
जबकि आप यह साबित करने के लिए कि किसी दिए गए डेटासेट को बदला नहीं गया है, असममित क्रिप्टोग्राफी (और एक बार की हस्ताक्षर योजना) का उपयोग कर सकते हैं, आप इसे पूरी तरह से हटाने या बदलने से नहीं रोक सकते। यह एक ऐसी समस्या है जिसके लिए append-only (और कुछ भागों के लिए read-only ) स्टोरेज सिस्टम की आवश्यकता होती है।
विवेकाधीन अभिगम नियंत्रण के लिए धन्यवाद जो ssh जैसे बैकएंड के साथ *nix पर लागू करने के लिए अपेक्षाकृत सरल है ( chmod , chown , chattr +i , chattr +a जैसे आदेशों का उपयोग करके append-only बैकअप को हमलावरों को पढ़ने से रोकने के लिए एन्क्रिप्ट करने की भी आवश्यकता नहीं है (उदाहरण के लिए, यह rsyslog का हिस्सा है), लेकिन यह अचानक बैकअप सर्वर को एक दिलचस्प लक्ष्य बना देता है, और संवेदनशील डेटा को अधिक उपकरणों पर क्लोन करने डेटा गोपनीयता बनाए रखने की संभावना में सुधार नहीं होता

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

https://github.com/restic/restic/issues/187#issuecomment -101974306 में वर्णित दो मामलों के लिए यह हमारे लिए रुचिकर है। मैं इस पर नजर रखने के लिए इस धागे की सदस्यता ले रहा हूं।

डेटा अखंडता के संबंध में: AFAIK, आप केवल अपने IAM क्रेडेंशियल्स को PutObject और GetObject अनुमतियां देकर, लेकिन DeleteObject रोककर, Amazon S3 पर append-only व्यवहार प्राप्त कर सकते हैं। अनुमति।

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

• पीड़ित की restic कुंजी चुराएं
• पीड़ित के IAM क्रेडेंशियल्स/sftp लॉग इन/... चोरी करें

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

एसिमेट्रिक क्रिप्टो पीड़ित को बैकअप को ऑफ़लाइन पुनर्स्थापित करने के लिए कुंजी को स्टोर करने की अनुमति देकर इसे रोकने में मदद कर सकता है।

डेटा अखंडता के संबंध में: AFAIK, आप Amazon S3 पर केवल अपने IAM क्रेडेंशियल्स को PutObject और GetObject अनुमतियाँ देकर, लेकिन DeleteObject अनुमति को रोककर केवल-केवल व्यवहार प्राप्त कर सकते हैं।

दुर्भाग्य से PutObject आपको पहले अपलोड की गई फ़ाइल को अधिलेखित करने का विशेषाधिकार भी देता है। तो, शायद यह पूर्ण डेटा अखंडता नहीं है?

असममित क्रिप्टो ओपनपीजीपी कुंजी जैसे यूबिकी या तो के उपयोग की भी अनुमति देगा।

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

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

मेरा उपयोग मामला कई सर्वरों के लिए सिस्टम व्यवस्थापक के रूप में है।

एसिमेट्रिक बैकअप एक सर्वर समझौता के परिदृश्य में बैकअप की रक्षा करने का एकमात्र तरीका है जहां एक हमलावर दुर्भावनापूर्ण रूप से सभी डेटा (बैकअप सहित) को नष्ट कर देता है (या रैंसमवेयर एन्क्रिप्ट करता है)।

इसके लिए सर्वर साइड सपोर्ट की जरूरत या तो केवल एपेंड स्टोरेज लेयर या सर्वर डेमॉन के माध्यम से होती है, जिस तरह से rdiff-backup में --restrict-update-only विकल्प होता है। वर्तमान में मैं बैकअप सर्वर (sftp के माध्यम से पहुँचा) पर बैकअप रिपॉजिटरी के केवल-पढ़ने के लिए स्नैपशॉट का उपयोग करके इसके आसपास काम करता हूं।

(शायद प्रासंगिक): फाइलों पर immutable ध्वज के साथ निर्देशिका पर append-only ध्वज (जो अनलिंक करना अक्षम करता है) के माध्यम से लिनक्स में केवल संलग्न किया जा सकता है। उन झंडों को सेट करने के लिए जिम्मेदार कमांड क्रमशः chattr +a /path/to/directory और chattr +i /path/to/directory/myfile01 हैं।

यहाँ मेरा उपयोग मामला #५३३ है - अप्राप्य बैकअप। जैसा कि वहां कहा गया है, असममित क्रिप्टो ऐसा करने का केवल एक तरीका है, लेकिन यह समस्या का पहला स्पष्ट समाधान जैसा लगता है।

ऐसे परिदृश्य में जहां रेपो रिमोट सर्वर पर है - रेपो पर केवल स्थानीय कमांड भूलने/छंटने में सक्षम होना चाहिए।

रेस्टिक बैकअप, उस सिस्टम के लिए केवल पुनर्स्थापना/बैकअप विशेषाधिकारों के साथ एक अद्वितीय कुंजी से कनेक्ट होना चाहिए।

ऐसे परिदृश्य में जहां रेपो रिमोट सर्वर पर है - रेपो पर केवल स्थानीय कमांड भूलने/छंटने में सक्षम होना चाहिए।

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

सर्वर को हैक करने वाले किसी व्यक्ति द्वारा बैकअप डेटा को नष्ट होने से रोकने के संबंध में: रेस्ट-सर्वर ने हाल ही में पीआर https://github.com/restic/rest-server/pull/28 के साथ "एपेंड ओनली मोड" प्राप्त किया है जो वास्तव में इसे रोकता है।

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

मैं जिस सुविधा की तलाश कर रहा हूं वह है "बैकअप" कुंजियाँ जो एक सिस्टम को लिखने (बैकअप) और पढ़ने (पुनर्स्थापित) करने में सक्षम बनाती हैं, लेकिन कोई भी व्यवस्थापक नहीं कर सकती, (जैसे कि प्रून, कुंजियाँ जोड़ें या अन्य के अस्तित्व को भी देखें कुंजियाँ, (उपयोगकर्ता) या स्नैपशॉट जो $backup_key से संबद्ध नहीं हैं)। (हालांकि बैकअप समय की तुलना करके एक साइड-चैनल हमला संभव हो सकता है, यह मेरे लिए कोई मायने नहीं रखता है कि क्या वे डेटा के अस्तित्व को निर्धारित कर सकते हैं, केवल यह कि वे मेरे डेटा को रैंसमवेयर नहीं कर सकते हैं और अन्य उपयोगकर्ताओं को नहीं देख सकते हैं।) मैं उम्मीद करूंगा एक बैकअप धारक-(केवल)-कुंजी अपने स्वयं के पासफ़्रेज़ को आगे रोल करने में सक्षम होने के लिए। तो michbsd के अनुरोध के विपरीत मैं एक गैर-स्थानीय मशीन से एक विशेषाधिकार प्राप्त कुंजी के साथ व्यवस्थापक करने में सक्षम होगा। (वर्षों से SELinux का उपयोग करने के बाद अब मैं MAC की ग्रैन्युलैरिटी का प्रशंसक हूं) पढ़ने के लिए धन्यवाद। (क्षमा करें यदि इसका अपना मुद्दा होना चाहिए।) इस सुविधा के साथ #ResticKillsRansomware

इस फीचर के साथ #ResticKillsRansomware

सामान्य तौर पर, पुल-ओरिएंटेड बैकअप (पुश-ओरिएंटेड वाले के विपरीत) रैंसमवेयर को हल करते हैं, है ना? :)

संभवतः लेकिन वह तब रिमोट एक्सेस देता है और एक और अटैक वेक्टर जोड़ता है। मैंने इसे कैसे डिज़ाइन किया है मेरा बैकअप सर्वर डेटा को संरक्षित करने के लिए है और मेरे उत्पादन वातावरण तक कभी भी इसकी पहुंच नहीं होनी चाहिए। कार्यात्मक डोमेन का स्पष्ट सीमांकन।

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

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

मैं जिस सुविधा की तलाश कर रहा हूं वह है "बैकअप" कुंजियाँ जो एक सिस्टम को लिखने (बैकअप) और पढ़ने (पुनर्स्थापित) करने में सक्षम बनाती हैं, लेकिन कोई भी व्यवस्थापक नहीं कर सकती, (जैसे कि प्रून, कुंजियाँ जोड़ें या अन्य के अस्तित्व को भी देखें कुंजियाँ, (उपयोगकर्ता) या स्नैपशॉट जो $backup_key से संबद्ध नहीं हैं)। (हालांकि बैकअप समय की तुलना करके एक साइड-चैनल हमला संभव हो सकता है, यह मेरे लिए कोई मायने नहीं रखता है कि क्या वे डेटा के अस्तित्व को निर्धारित कर सकते हैं, केवल यह कि वे मेरे डेटा को रैंसमवेयर नहीं कर सकते हैं और अन्य उपयोगकर्ताओं को नहीं देख सकते हैं।) मैं उम्मीद करूंगा एक बैकअप धारक-(केवल)-कुंजी अपने स्वयं के पासफ़्रेज़ को आगे रोल करने में सक्षम होने के लिए। तो michbsd के अनुरोध के विपरीत मैं एक गैर-स्थानीय मशीन से विशेषाधिकार प्राप्त कुंजी के साथ व्यवस्थापक करने में सक्षम होगा। (वर्षों से SELinux का उपयोग करने के बाद अब मैं MAC की ग्रैन्युलैरिटी का प्रशंसक हूं) पढ़ने के लिए धन्यवाद। (क्षमा करें यदि इसका अपना मुद्दा होना चाहिए।) इस सुविधा के साथ #ResticKillsRansomware

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

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

मुझे यह भी पता नहीं था कि अस्तित्व में है। डी:

मैं दो संरचनात्मक चीजें (और थोड़ा अलग हमलावर मॉडल) देखता हूं जिन्हें मैं यहां डंप करना चाहता हूं।

फिलहाल, रेस्टिक (ज्यादातर) "डंब" स्टोरेज (स्थानीय, s3, b2, gcs, azure, --append-only साथ REST सर्वर को छोड़कर) के साथ इंटरैक्ट करता है। यह बैकएंड में डेटा को सेव, लिस्ट, प्राप्त और डिलीट कर सकता है। बैकअप के लिए यह आवश्यक है, इसलिए बैकएंड तक पहुंचने के लिए आवश्यक क्रेडेंशियल्स मौजूद होना चाहिए। उल्टा, रेस्टिक लगभग किसी भी भंडारण का उपयोग कर सकता है, बहुत कम प्रतिबंध हैं। नकारात्मक पक्ष पर, एक बार जब हमलावर एक सर्वर तक पहुंच प्राप्त कर लेते हैं, तो वे बैकएंड और बाकी पासवर्ड तक पहुंचने के लिए आसानी से क्रेडेंशियल निकाल सकते हैं, जिससे उन्हें सभी संभावनाएं मिलती हैं: रिपॉजिटरी से ऐतिहासिक डेटा को डिक्रिप्ट करें, डेटा को संशोधित करें, पूरे रिपॉजिटरी को हटा दें।

जब हम असममित क्रिप्टोग्राफी जोड़ते हैं, तो ऐसी स्थिति में हमलावरों के लिए एकमात्र अंतर यह है कि वे ऐतिहासिक डेटा को भंडार से डिक्रिप्ट नहीं कर सकते हैं। बाकी सब कुछ, विशेष रूप से सभी डेटा को हटाना, अभी भी संभव है। तो "बस असममित क्रिप्टो जोड़ें" पूरी कहानी नहीं है।

दूसरा विचार सीधे "गूंगा" भंडारण तक नहीं पहुंचना है, लेकिन परोक्ष रूप से एक कस्टम सर्वर कार्यान्वयन के माध्यम से। हमने इस विचार के साथ खेला है और REST सर्वर के लिए --append-only विकल्प जोड़ा है , जिसे स्थानीय हार्डडिस्क पर "डंब" स्टोरेज तक पहुंचने के लिए "एडेप्टर" के रूप में देखा जा सकता है। मेरे पास उस विचार पर सुधार करने के बारे में कई विचार हैं, जरूरी नहीं कि REST सर्वर के साथ।

उदाहरण के लिए, मैं बैकएंड के लिए एक प्रोटोकॉल परिभाषित करना चाहता हूं जो फ़ाइल डिस्क्रिप्टर की एक जोड़ी पर बोली जाती है, उदाहरण के लिए stdin/stdout। इसके बाद हम इसे एक प्रोग्राम में कार्यान्वित कर सकते हैं जो रिमोट मशीन पर एसएसएच पर चलता है, जैसे हम एसएफटीपी बैकएंड के लिए करते हैं। सर्वर कार्यान्वयन तब तय कर सकता है कि डेटा को कहाँ संग्रहीत किया जाए (स्थानीय, s3, b2, जो भी हो) और कौन से प्रतिबंध लागू होते हैं (उदाहरण के लिए "केवल पुराने पढ़ें या नया डेटा जोड़ें", फ़ाइलों को लॉक करने के अलावा कुछ भी हटाने की क्षमता के बिना। सर्वर उदाहरण के लिए किसी विशेष उपयोगकर्ता खाते या एसएसएच कुंजी के साथ एसएसएच के माध्यम से लॉगिन पर ForceCommand माध्यम से शुरू किया जा सकता है।

अकेले "नॉन-डंब" स्टोरेज होने से हमलावरों को रिपॉजिटरी से डेटा पढ़ने में मदद नहीं मिलेगी (कम से कम रेपो प्रारूप को बदले बिना नहीं), लेकिन रेपो में सभी डेटा को हटाने से रोकेगा।

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

मैं इस पाठ को इस अंक में पहली टिप्पणी में कॉपी करने जा रहा हूं ताकि इसे ढूंढना आसान हो।

हाँ, इस पर आगे विचार करते हुए, मैं मानता हूँ कि एसिम क्रिप्टो टेकओवर से बचाव के लिए उपयोगी नहीं है - यह अनअटेंडेड बैकअप (#533) के लिए अधिक उपयोगी है।

मूल संचार प्रोटोकॉल होना उपयोगी हो सकता है, लेकिन मुझे यकीन नहीं है कि आप वर्तमान आरईएसटी सर्वर पर उससे क्या हासिल करते हैं - क्या आप उस पर विस्तार कर सकते हैं? अटारी / बोर्ग कि जिस तरह से चला गया: वहाँ एक ग्राहक से सर्वर "स्वामित्व" (के रूप में, बोर्ग विशेष) प्रोटोकॉल है वहाँ और यह ग्राहकों के लिए कुछ प्रतिबंध लागू करने के लिए संभव है। और हां, यह फोर्सकॉमैंड और "बोर्ग सर्व" प्रतिबंधित झंडे पर निर्भर करता है ... इसके बारे में बोर्ग दस्तावेज़ों में कुछ

और निश्चित रूप से, एक समझौता किए गए क्लाइंट से बैकअप की रक्षा करने का सबसे स्वाभाविक तरीका है कि क्लाइंट को केवल बैकअप स्वयं करने की अनुमति न दें, बल्कि इसके बजाय सर्वर को बैकअप से फ़ाइलें खींचे , "बैकुला-स्टाइल" ("यह आता है रात और आपके कंप्यूटर से सार चूसता है", उन लोगों के लिए जो उस आकर्षक वाक्यांश को याद करते हैं)। बोर्ग में ऐसा करने के लिए एक अच्छी तरह से प्रलेखित या सुरुचिपूर्ण तरीका प्रतीत नहीं होता है, अक्सर पूछे जाने वाले प्रश्न https://github.com/borgbackup/borg/issues/900 विषय पर चर्चा के रूप में इंगित करते हैं। यहाँ इसे #299 में ट्रैक किया गया है, जिसका यहाँ अभी तक उल्लेख नहीं किया गया था।

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

1. बैकअप सर्वर को सभी मशीनों पर रूट एक्सेस की आवश्यकता नहीं है
2. फिर भी एक मशीन का समझौता अभी भी पुनर्प्राप्त करने योग्य है, भले ही वे बैकअप के साथ गड़बड़ करने में सक्षम हों

मुझे वास्तव में यह अजीब लगता है कि इस मुद्दे को "मैं क्लाइंट अधिग्रहण के खिलाफ सुरक्षित करना चाहता हूं" में बदल गया था - शायद हम यहां समस्या के समाधान को भ्रमित कर रहे हैं। :)

नमस्ते,

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

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

@dolanor कृपया इस मुद्दे पर नए उपयोग के मामले या प्रश्न न जोड़ें, प्रश्नों के लिए मंच का उपयोग करें। इसके अलावा, कार्यान्वयन विवरण के बारे में बात करना जल्दबाजी होगी।

मैंने पहली पोस्ट में सारांश अपडेट किया है। इस बीच rclone बैकएंड जोड़ा गया है, इसे ऊपर वर्णित अनुसार "एडेप्टर" के रूप में इस्तेमाल किया जा सकता है, और एसएसएच के माध्यम से पहुंचा जा सकता है।

नकारात्मक पक्ष पर, एक बार जब हमलावर एक सर्वर तक पहुंच प्राप्त कर लेते हैं, तो वे बैकएंड और बाकी पासवर्ड तक पहुंचने के लिए आसानी से क्रेडेंशियल निकाल सकते हैं

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

यदि यह सही है, तो मैं आपको स्पष्ट करने के लिए सारांश को फिर से बदलने की अत्यधिक अनुशंसा करता हूं, क्योंकि इस तरह से कहा जाने पर यह निश्चित रूप से खराब दिखता है। :)

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

मुझे लगता है कि यह सटीक परिदृश्य पर निर्भर करता है: यदि आप मैन्युअल रूप से पासवर्ड दर्ज कर रहे हैं, तो ठीक है। यदि आप अनुसूचित स्वचालित बैकअप कर रहे हैं, तो दूसरी ओर, "उपयोगकर्ता पासवर्ड" को सर्वर पर कहीं संग्रहीत करना होगा।

और, ज़ाहिर है, एक हमलावर रेस्टिक बाइनरी को एक के साथ स्वैप कर सकता है जो दर्ज किए गए पासवर्ड को लीक करता है और आपके द्वारा इसे दर्ज करने की प्रतीक्षा करता है। आप एक समझौता प्रणाली पर भरोसा नहीं कर सकते।

"उपयोगकर्ता पासवर्ड" को सर्वर पर कहीं संग्रहीत करना होगा।

"सर्वर" से क्या आपका मतलब है "जिस मशीन पर हम चल रहे हैं उस पर हम डेटा सहेजते हैं" या "वह मशीन जो बैकअप से डेटा प्राप्त/स्टोर करती है"?

यह बल्कि अस्पष्ट है, और मेरी चिंता का स्रोत है: मुझे बैकअप क्लाइंट (जिस मशीन का हम बैक अप ले रहे हैं जो रेस्टिक चल रहा है) को क्लीयरटेक्स्ट में पासवर्ड रखने से कोई फर्क नहीं पड़ता: संपूर्ण डेटासेट वैसे भी है यदि इससे समझौता किया गया है, तो डेटा है वैसे भी समझौता किया। लेकिन मुझे यकीन है कि बैकअप सर्वर के पास क्लीयरटेक्स्ट तक पहुंच नहीं है!

"सर्वर" से क्या आपका मतलब है "जिस मशीन पर हम चल रहे हैं उस पर हम डेटा सहेजते हैं" या "वह मशीन जो बैकअप से डेटा प्राप्त/स्टोर करती है"?

जिस मशीन पर हम रेस्टिक चला रहे हैं उसका डाटा सेव कर लेते हैं।

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

सारांश में REST सर्वर के लिए --append-only विकल्प का उल्लेख है। शायद यह केवल एपेंड-ओनली बैकअप की आधिकारिक तौर पर अनुशंसित विधि के रूप में ही रहना चाहिए, लेकिन यह दस्तावेज करना अच्छा हो सकता है कि अन्य दृष्टिकोणों को कैसे सेट किया जाए, यह पता लगाने में मदद करने के लिए सामान्य ऑपरेशन के लिए रेस्टिक में कौन सी फाइलें लिखने योग्य हैं।

मेरा मानना ​​है कि restic backup ठीक काम करेगा यदि data , index , keys , और snapshots फ़ाइल निर्माण की अनुमति देता है लेकिन संशोधन या विलोपन नहीं ( और config को भी संरक्षित किया गया था)। हालांकि, मुझे लगता है कि locks को हटाने की अनुमति देने की आवश्यकता होगी ताकि भंडार स्थायी रूप से लॉक न हो। साथ ही, कुछ एपेंड-ओनली इम्प्लांटेशन (जैसे ext4 और xfs फाइल सिस्टम के लिए विशेषता) पुनरावर्ती नहीं हैं, इसलिए data की 256 दो वर्ण उपनिर्देशिकाओं को पहले पूर्व-जेनरेट करने की आवश्यकता होगी और फिर विशेषता की आवश्यकता होगी उन पर स्थापित हो।

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

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

@willsALMANJ अच्छे अवलोकन। S3 के लिए मुझे आश्चर्य है कि क्या आपत्ति संस्करणों को किसी दिए गए स्नैपशॉट को पुनर्स्थापित करने के लिए आवश्यक ब्लॉब्स के सुसंगत दृश्य को लाने की अनुमति देने के लिए रिकॉर्ड किया जा सकता है (हालांकि आप उन्हें उनकी सामग्री के आधार पर मान्य कर सकते हैं, इसलिए अति महत्वपूर्ण नहीं)।

पुन: आपका अंतिम पैराग्राफ:

• असममित एन्क्रिप्शन का मुख्य लाभ, आपके द्वारा उल्लिखित "ऐतिहासिक चीजों को डिक्रिप्ट करें" परिदृश्य के अलावा, अलग-अलग कुंजियों को व्यवस्थित किए बिना एक ही बैकअप रिपॉजिटरी में कई स्वतंत्र मशीनों से बैकअप स्टोर करने में सक्षम होना है (जिसके लिए हर बार बैकअप कुंजी को संग्रहीत करने की आवश्यकता होती है। एक नई क्लाइंट मशीन स्थापित करें)। यदि आप एक साझा कुंजी का उपयोग करते हैं तो आपको कष्टप्रद खतरा परिदृश्य मिलता है जहां क्लाइंट 1 क्लाइंट 2 के डेटा को पढ़ सकता है, जो आदर्श नहीं है।

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

मुझे नहीं पता कि मुझे यहां कुछ याद आ रहा है, लेकिन मैं S3 संग्रहण पर इस नीति सेटिंग के साथ रेस्टिक सफलतापूर्वक चला रहा हूं। यह किसी हमलावर को डेटा पढ़ने से नहीं रोकता है, लेकिन यह उसे हटाने से रोकता है।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

Prune/Forget कमांड तब एक विश्वसनीय डिवाइस से चलाए जाते हैं, जिसके पास लिखने की अनुमति होती है। मैं हर रेस्टिक रिपॉजिटरी में दो कुंजियाँ भी बनाता हूँ। एक सर्वर के लिए और एक विश्वसनीय डिवाइस के लिए, ताकि विश्वसनीय डिवाइस एक हमलावर को लॉक कर सके (लेकिन हमलावर ऐसा नहीं कर सकता क्योंकि वह चाबियों/* में हटा नहीं सकता)।

संपादित करें: क्षमा करें, अनदेखा किया गया है कि इस पर पहले ही चर्चा की जा चुकी है। इस धागे को हाईजैक नहीं करना चाहता था।
PutObject वास्तव में ऑब्जेक्ट को ओवरराइट करने में सक्षम है इसलिए यह बैकअप की सुरक्षा का समाधान नहीं है ।

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

@andrewchambers मैं अन्य सामानों के साथ थोड़ा सा

तो, यह समस्या (अंततः) असममित बैकअप को लागू करने के बारे में है, बैकएंड स्टोरेज के लिए कॉन्फ़िगरेशन तक नहीं। धन्यवाद! :)

@ fd0 उम्मीद है कि यह बताता है कि मेरा क्या मतलब है https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : यदि आप अभी तक केवल-लिखने के मुद्दे पर नहीं आए हैं (जिसका आपने अपनी साइट पर उल्लेख किया है), तो यह https://github.com/ncw/rclone/issues/2499 है।

@andrewchambers इसे लिखने के लिए धन्यवाद, मुझे बहुत दिलचस्पी है कि वास्तविक कार्यान्वयन कैसा दिखता है। ब्लॉग पोस्ट ने कुछ दिलचस्प बिट्स को खुला छोड़ दिया :)

मुझे यह पसंद है कि मुफ्त सॉफ्टवेयर बैकअप कार्यक्रमों के क्षेत्र में एक और दावेदार होगा, उपयोगकर्ताओं को अधिक विकल्प देना हमेशा बढ़िया होता है!

तो दो गिट रिपोजिटरी एन्क्रिप्शन तंत्र के साथ एक दिलचस्प समानांतर बनाया जा सकता है।

एक तरफ आपके पास git-crypt है : यह ब्लॉब स्टोरेज और चेक आउट कॉपी के बीच फ़ाइलों को एन्क्रिप्ट/डिक्रिप्ट करने के लिए (क्रमशः) git smudge/क्लीन फ़िल्टर का उपयोग करता है। यह अच्छी तरह से काम करता है और काफी इष्टतम है, लेकिन इसमें एक चमकदार छेद है: गिट खुद को एन्क्रिप्ट नहीं करता है, केवल ब्लॉब्स की सामग्री, जिसका अर्थ है कि फ़ाइल नाम, कमिटलॉग, लेखक, तिथियां और अन्य मेटाडेटा सभी स्पष्ट रूप से स्टोर हैं। यह कई उपयोग के मामलों के लिए नहीं है और केवल तभी प्रभावी होता है जब आपके पास एक सार्वजनिक भंडार होता है जहां (कहें) आप कुछ बिट्स (लेकिन सभी नहीं) एन्क्रिप्ट करना चाहते हैं।

दूसरी तरफ आपके पास git-remote-gcrypt है : जो सर्वर पर भेजी जाने वाली हर चीज को एन्क्रिप्ट करने के लिए git रिमोट हेल्पर्स प्रोटोकॉल का उपयोग करता है। लेकिन यह बहुत अक्षम है, क्योंकि विशेष रिमोट के काम करने के तरीके के कारण, प्रत्येक रन पर संपूर्ण रिपॉजिटरी को फिर से एन्क्रिप्ट किया जाता है।

अब, वे गिट-विशिष्ट कार्यान्वयन चुनौतियां हैं, लेकिन मुझे लगता है कि वे उन समस्याओं में अच्छी तरह से मैप करते हैं जो आपको यहां मिल सकती हैं। हो सकता है कि मैं यहाँ अपनी गहराई से पूरी तरह से बाहर हूँ और यह समानांतर अप्रासंगिक है, लेकिन मुझे लगा कि यह यहाँ रुचि का हो सकता है ...

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

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

क्या होगा यदि हम एक अलग कुंजी निर्देशिका के विनिर्देश की अनुमति देते हैं, जहां कुंजी फ़ाइलें संग्रहीत की जाती हैं? इस निर्देशिका को प्रत्येक मशीन पर स्थानीय रूप से संग्रहीत किया जा सकता है जिसे बैकअप करने की आवश्यकता होती है, और इसे स्वयं एक अलग क्लाउड प्रदाता, या यहां तक ​​​​कि एक क्यूआर कोड (~ 500 बाइट्स क्यूआर-एन्कोडेड होने के लिए बहुत छोटा है) को ठंडे ऑफ़लाइन भंडारण के लिए बैकअप किया जा सकता है। उदाहरण के लिए, एक सुरक्षा जमा बॉक्स में।

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

यह _Restic पर पहले से ही किया जा सकता है_ यदि रिपॉजिटरी की एक स्थानीय प्रति रखी जाती है - बस कुंजी निर्देशिका को rclone चलाते समय अविश्वसनीय रिमोट से समन्वयित होने से बाहर कर दें। यह _cannot_ किया जा सकता है यदि कोई स्थानीय प्रति नहीं है और रेस्टिक सीधे अविश्वसनीय रिमोट के साथ इंटरैक्ट करता है।

मुझे लगता है कि हमें एकल जिम्मेदारी सिद्धांत को लागू करना चाहिए और चीजों को 2 कार्यों में विभाजित करना चाहिए:

1. डेटा को डिक्रिप्शन से सुरक्षित रखें।
2. डेटा को अनधिकृत डिलीट एक्शन से सुरक्षित रखें।

वे डेटा सुरक्षा के 2 अलग-अलग पहलू हैं। तकनीकी रूप से उन्हें एक-दूसरे पर निर्भर होने की जरूरत नहीं है।

(1) के लिए, जाहिर है हम "बस असममित एन्क्रिप्शन समर्थन जोड़ सकते हैं"। (2) के लिए, मेरा मानना ​​है कि कई संभावित समाधान हैं (उदाहरण के लिए, जैसा कि ऊपर बताया गया है, केवल-केवल S3 सेटअप संलग्न करें)।