- डेयजॉन स्थित National Information Resources Service (NIRS) के सर्वर रूम में आग लगने से सरकारी G-Drive cloud डेटा पूरी तरह नष्ट हो गया
- लगभग 7.5 लाख सरकारी कर्मचारियों की व्यक्तिगत कार्य फ़ाइलें स्थायी रूप से मिट गईं
- उच्च क्षमता, कम प्रदर्शन वाले storage architecture के कारण बाहरी backup न होना घातक कमजोरी साबित हुआ
- कुछ मंत्रालयों, खासकर Ministry of Personnel Management को गंभीर नुकसान हुआ, और recovery सीमित है
- डेटा प्रबंधन व्यवस्था को लेकर आलोचना बढ़ रही है और दोबारा ऐसी घटना रोकने की मांग तेज हुई है
NIRS आग से सरकारी cloud storage system नष्ट होने की घटना का सार
- 27 सितंबर को डेयजॉन में National Information Resources Service (NIRS) की मुख्य इमारत में लगी आग से सरकारी G-Drive cloud storage system नष्ट हो गया
- Ministry of the Interior and Safety के अनुसार, 7.5 लाख सरकारी कर्मचारियों द्वारा अलग-अलग संग्रहीत सभी कार्य फ़ाइलें हट गईं
नुकसान और प्रभाव
- आग केंद्र की 5वीं मंजिल के सर्वर रूम में लगी और केंद्रीय सरकारी कामकाज के लिए जरूरी 96 information systems तथा G-Drive platform को गंभीर क्षति पहुँची
- 2018 में शुरू किए गए G-Drive ने सरकारी कर्मचारियों को सभी कामकाजी दस्तावेज़ व्यक्तिगत PC के बजाय cloud में सेव करने के लिए बाध्य किया था
- इसमें प्रति व्यक्ति लगभग 30GB capacity दी जाती थी
अपर्याप्त backup और डेटा के स्थायी नुकसान की वजह
- उच्च क्षमता, कम प्रदर्शन वाले storage architecture के कारण इसे बाहरी backup नहीं करने वाली व्यवस्था के रूप में डिज़ाइन किया गया था
- इसी संरचनात्मक सीमा की वजह से आग के बाद डेटा recovery असंभव हो गई
संस्थानों के अनुसार नुकसान में अंतर
- अलग-अलग संस्थानों में नुकसान का स्तर अलग रहा
- Ministry of Personnel Management ने सभी दस्तावेज़ G-Drive में अनिवार्य रूप से सेव किए थे, इसलिए उसे सबसे अधिक नुकसान हुआ
- Office for Government Policy Coordination जैसे कुछ संस्थानों को तुलनात्मक रूप से कम नुकसान हुआ
recovery की कोशिशें और सीमाएँ
- पिछले एक महीने से हर मंत्रालय व्यक्तिगत PC में सेव फ़ाइलों, email, आधिकारिक दस्तावेज़ों और प्रिंट रिकॉर्ड जैसे वैकल्पिक डेटा के आधार पर सीमित recovery कर रहा है
- आधिकारिक approval और reporting के दौरान बने कुछ दस्तावेज़ Onnara system में भी संग्रहीत हैं, इसलिए उस system की recovery होने पर कुछ डेटा वापस मिलने की संभावना है
डेटा प्रबंधन व्यवस्था पर सवाल
- सामान्यतः अधिकतर systems का केंद्र के भीतर अलग उपकरणों और remote backup facility में रोज़ backup लिया जाता है, लेकिन G-Drive संरचनात्मक कारणों से बाहरी backup के लिए अक्षम था, जिससे यह असामान्य रूप से कमजोर साबित हुआ
- इस घटना के बाद सरकार की data security और management system को लेकर आलोचना तेज हो गई है और दोबारा ऐसी घटना रोकने के लिए उपायों की जरूरत उठी है
1 टिप्पणियां
Hacker News प्रतिक्रिया
बैकअप नहीं था, इस बात पर गुस्सा आता है, लेकिन वास्तव में जिम्मेदारी तय करने से पहले स्थिति के बारे में और जानना चाहूँगा
1990~1991 में जब मैं पहले कंप्यूटर प्रभारी के रूप में काम कर रहा था, तब मेरे मेंटर ने कहा था, "यह सुनिश्चित करना तुम्हारा काम है कि बैकअप ठीक से हो रहे हैं, बाकी सब बोनस है"
उस समय tape backup system क्षमता से भर चुका था, इसलिए मैंने 14400bps modem से दो साइटों के बीच महत्वपूर्ण डेटा replicate करना शुरू किया, और हर महीने काम करने वाले backup system की माँग वाला memo छोड़ता रहा, लेकिन कंपनी ने लागत के कारण उसे नज़रअंदाज़ कर दिया
जब server hard disk खराब हुई, तो समस्या bearing की लग रही थी, इसलिए मैंने hard case खोलकर उंगली से platter घुमाते हुए उसे कुछ हफ्तों तक चलाए रखा; स्थिति की गंभीरता दिखाने के लिए manager को खुद आकर देखने दिया, और आखिरकार नया hard drive खरीदा गया, लेकिन mirroring के लिए अतिरिक्त drive फिर भी नहीं खरीदी गई
मेरे नौकरी छोड़ने के एक महीने बाद server failure हुआ और वे मुझे दोष देने की कोशिश करने लगे, लेकिन मेरे बाद आए व्यक्ति ने मेरे छोड़े हुए memo का पुलिंदा ढूँढ लिया और स्थिति साफ हो सकी
लेख के आखिरी हिस्से में
यह सच है कि LLM तकनीक की मूल जड़ें अनुवाद के उद्देश्य से हुए विकास में हैं
context संभाल सकने वाले model बनाने की ज़रूरत से शोध हुआ, और बाद में वह कई क्षेत्रों में उपयोगी साबित हुआ
translation क्षेत्र में LLM-आधारित तकनीक पहले से ही 5 साल से ज़्यादा समय से अच्छे प्रदर्शन के साथ इस्तेमाल हो रही है
मैं खुद कई सालों से इसी तरह अनुवाद करता आया हूँ; LLM से पहले भी, जिन भाषाओं पर मेरी पकड़ अच्छी है, उनमें पहले machine translation चलाकर उसे edit करना, शुरुआत से खुद अनुवाद करने की तुलना में कहीं तेज़ पड़ता है
(machine translation LLM है या नहीं, यह वास्तविक translation workflow में कोई बड़ा मुद्दा नहीं है)
मुझे अब भी लगता है कि यह पूरी तरह बेकार नतीजा है
यह लेख देखें कि AI ने मेरा translator वाला काम कैसे छीन लिया
संबंधित लिंक साझा किया गया
timeline देखें तो सिहरन होती है
आग लगने वाला वही दिन सरकार के on-site inspection (China/North Korea hacking से संबंधित) शुरू होने की तय तारीख थी
लेख से उद्धरण
इस तरह की chronology पढ़कर सत्ता के सामने सच बोलने का मन ही टूट जाता है
बस डेटा मिटाओ, उपकरण फेंको, और बस पकड़कर किसी दूसरे शहर, दूसरी नौकरी की तलाश में निकल जाओ—ऐसा सोचने का मन करता है
सकारात्मक रूप से देखें तो तकनीकी तौर पर बैकअप होने की संभावना काफ़ी ज़्यादा है (section 1.3 देखें)
समस्या सिर्फ़ यह है कि अफवाह है कि वे बैकअप North Korea या China में हैं
चौंकाने वाली बात है
यह इस लेख की सबसे महत्वपूर्ण बात नहीं है, लेकिन समझ नहीं आता कि लेखकों के अपने account suspend हो जाने के बाद भी वे Proton का बचाव क्यों कर रहे हैं
जबकि एक समीक्षा में कहा गया है कि कोरियाई intelligence agency से जुड़े एक व्यक्ति ने Proton के सुरक्षित न होने की चेतावनी दी थी
चाहे तकनीकी रूप से यह पूरी तरह सुरक्षित हो, यह दिखाता है कि यह कंपनी उतनी नैतिक रूप से स्पष्ट नहीं है जितना लोग समझते हैं
जो सरकारी अधिकारी commercial AWS/GCP/Azure पर भरोसा नहीं किया जा सकता कहते थे, वे शायद कुछ समय तक चुप रहेंगे
"Ministry of the Interior and Safety ने बताया कि Daejeon data center के अधिकांश systems का backup उसी center के भीतर अलग hardware और physically separated backup facility में रोज़ाना लिया जाता है, लेकिन G-Drive की संरचना के कारण external backup संभव नहीं है"
मुझे यह सचमुच बेतुकी स्थिति लगती है
मुझे नहीं लगता कि यहाँ मुद्दा विदेशी कंपनियों का इस्तेमाल न करना है
external storage का दायित्व तय करके भी वास्तव में backup न करना पागलपन भरा प्रशासन है
आग तो सबसे बुनियादी जोखिमों में से एक है; इतनी भी तैयारी न होना अविश्वसनीय कुप्रबंधन है
मैं भी सहमत हूँ कि इतने महत्वपूर्ण system को बिना backup चलाना गलत था
लेकिन फिर भी, मेरा मानना है कि सरकार के स्तर पर महत्वपूर्ण डेटा किसी विदेशी cloud में रखना उचित नहीं है
अगर cloud इस्तेमाल किया गया होता, तो redundancy बनाना आसान होता, लेकिन वही एकमात्र तरीका नहीं था
शुरुआत से ही design concept गलत था, और संरचना में वास्तविक redundancy थी ही नहीं
इसका सीधा समाधान यह था कि कई netapp systems पर snapmirror के साथ secondary backup site बनाई जाती,
या ZFS, DRBD जैसे open source solutions इस्तेमाल किए जाते
आजकल ऐसे विकल्प इतने हैं कि लगभग कोई भी उनका उपयोग कर सकता है
लोग सोचते हैं कि ये कंपनियाँ कभी डेटा नहीं खोतीं, लेकिन lightning strike से data center के नष्ट होने की घटनाएँ भी हुई हैं (संबंधित लेख)
सरकार के नज़रिए से डेटा किसी दूसरे देश की private company द्वारा संचालित environment में नहीं होना चाहिए
यह backup की समस्या से पूरी तरह अलग मुद्दा है
वास्तविकता शायद इससे भी बदतर है
दूसरे लेख के अनुसार G-Drive के पूरे डेटा का कुल आकार 858TB था
हिसाब थोड़ा मज़ाकिया लगे, लेकिन AWS S3 के हिसाब से पूरे backup की मासिक लागत करीब $20,000 (लगभग 2 करोड़ won) होती
अगर इसे “Glacier deep archive” में downgrade किया जाता, तो यह सिर्फ़ $900 प्रति माह पड़ता
backup मौजूद थे, लेकिन वे सभी उसी server room में रखे गए थे (लेख1, लेख2)
प्रति व्यक्ति 30GB को औसत उपयोग मानना सही नहीं है
असल में औसत उपयोग शायद 0.3GB के करीब रहा होगा
लेख की टिप्पणियों से अलग, यह अब भी स्पष्ट नहीं है कि सचमुच कोई backup था ही नहीं
इतना तो निश्चित लगता है कि “external” backup नहीं था, लेकिन “internal” backup हो सकता है
अगर backup की अनुमति दिए बिना सारा डेटा एक ही जगह समेट दिया जाए, तो वह external hacking के लिए लक्ष्य बन सकता है; और आंतरिक तौर पर fire vault जैसी physical backup facilities का इस्तेमाल भी मैंने कई जगह देखा है
बेशक, अगर सच में ऐसी व्यवस्था भी नहीं थी, तो यह बहुत बड़ी गलती है
संदर्भ के लिए, दशकों पुराने paper में भी ऐसे archiving facilities बनाए जाने के उदाहरण मिलते हैं (IBM project paper)
दिलचस्प बात यह है कि कुछ हफ्ते पहले Nepal में भी कुछ ऐसा ही हुआ था
प्रदर्शनकारियों ने कुछ सरकारी इमारतों में आग लगा दी, IT infrastructure भी नष्ट हो गया, और नतीजतन लगभग सारा electronic data गायब हो गया
सोचने वाली बात है कि अगर ये दस्तावेज़ analog रूप में बचे होते, तो क्या नतीजा अलग होता
electronic data का फायदा यह है कि उसका backup लिया जा सकता है, लेकिन सिर्फ़ कागज़ पर काम होता तो भी शायद स्थिति बेहतर नहीं होती
क्या वे anti-authoritarian patriots थे?
Blade Runner फिल्म में भी कुछ ऐसा ही हुआ था
कुछ दिन पहले GKS (Global Korea Scholarship) application site कई दिनों तक inaccessible थी, लेकिन यह जानकर झटका लगा कि शायद पूरा डेटा ही नष्ट हो गया
मुझे लगता है कि अब बेहतर website system बनाने का यही सही मौका है
अभी दक्षिण कोरिया में एक पल में बहुत-सी महत्वपूर्ण जानकारी गायब हो जाने से यह community में बड़ा मुद्दा बन गया है और बहुत लोग इसका ज़िक्र कर रहे हैं
मुझे यक़ीन है कि काफ़ी कीमती डेटा पूरी तरह गायब हो चुका होगा, लेकिन दूसरी ओर यह सोचकर हल्की मुस्कान आती है कि शायद प्रबंधन विभागों में ऐसा संदेश घूम रहा होगा: "अगर किसी shadow IT कर्मचारी ने अनौपचारिक रूप से भी mirror database चला रखा है, तो अभी रिपोर्ट करो, कोई जवाबदेही तय नहीं की जाएगी"
मैंने भी पहले ऐसे हालात में, जब असली critical data का canonical source बार-बार बदलता रहता था या server बंद हो जाता था या गड़बड़ा जाता था, अनौपचारिक रूप से अलग backup बनाया था
बहुत से लोग कह रहे हैं कि अमेरिकी cloud का इस्तेमाल न करना ही समस्या थी, लेकिन मुझे नहीं लगता कि यही मूल मुद्दा है
परिस्थिति के अनुसार अपना infrastructure चलाना पूरी तरह तर्कसंगत निर्णय हो सकता है
लेकिन इस मामले में, security और privacy को प्राथमिकता देते-देते “availability” की बलि चढ़ा दी गई—यही सबसे बड़ी समस्या है
physical disasters (आग, भूकंप) या मानवीय गलती से डेटा खोने का जोखिम हमेशा बना रहता है
ऐसा system जिसे इन खतरों से बचाया न जा सके, उसे कभी deploy ही नहीं करना चाहिए
Ministry of the Interior and Safety के अनुसार Daejeon data center के अधिकांश systems का backup दूसरी जगह है, लेकिन G-Drive में संरचनात्मक रूप से external backup संभव नहीं था
यानी यह जोखिम पहले से जानते हुए स्वीकार किया गया था, और अब उसका परिणाम सामने है