- हालिया ICC (अंतरराष्ट्रीय आपराधिक न्यायालय) प्रतिबंधित व्यक्ति mailbox block घटना से दिखता है कि Microsoft प्रोडक्ट्स पर अत्यधिक निर्भरता में अप्रत्याशित service outage और cost risk शामिल हैं
- जब यह अमेरिकी राजनीतिक कारकों (खासकर sanctions या अचानक policy changes) से जुड़ता है, तो service block की संभावना कम होती है, लेकिन एक बार होने पर नुकसान बहुत बड़ा होता है
- Microsoft जैसे बड़े IT enterprise cloud·SaaS युग में व्यावहारिक रूप से ग्राहक कंपनियों के data और software पर पूर्ण नियंत्रण रखते हैं
- जैसे-जैसे enterprise·institution की IT infrastructure (mail, identity management, files, authentication आदि) MS services पर केंद्रित होती जाती है, service outage होने पर पूरे operations·business के ठप पड़ने का जोखिम बढ़ता है
- risk prevention और alternative infrastructure बनाने के लिए तार्किक investment limit वास्तविकता में बहुत छोटी होती है. risk management सहज नहीं है, और मूल रूप से data तथा cost estimation की सीमाएँ मौजूद हैं
हालिया घटना: ICC (अंतरराष्ट्रीय आपराधिक न्यायालय) के mailbox block पर MS विवाद
- 2025 में अमेरिका ने ICC के एक वरिष्ठ अधिकारी पर प्रतिबंध लगाए, जिसके बाद कई मीडिया रिपोर्ट्स में कहा गया कि Microsoft ने उस व्यक्ति के official mail account तक पहुँच ब्लॉक कर दी
- Associated Press, NL Times आदि ने इसे “Trump administration sanctions → MS blocks some accounts such as the ICC prosecutor’s” के रूप में समझाया
- Politico ने इस बात पर ज़ोर दिया कि यह “पूरे संगठन” पर नहीं बल्कि “व्यक्तियों” पर block था, लेकिन कुछ विशिष्ट व्यक्तियों के block होने के तथ्य से इनकार नहीं किया
- इस घटना ने नीदरलैंड सहित यूरोप में यह बहस छेड़ दी कि अमेरिकी IT कंपनियों पर निर्भरता राष्ट्रीय और सार्वजनिक IT infrastructure के लिए security risk बन सकती है
- MS ने कहा कि “accounts किस route से block हुए, और सटीक details क्या थीं, यह सार्वजनिक नहीं किया जा सकता,” जिससे service block process और responsibility scope की अस्पष्टता सामने आई
क्या ऐसा फिर हो सकता है?
- service block की प्रक्रिया बहुत सरल है: अमेरिकी राष्ट्रपति (सरकार) का sanctions order → MS जैसे अमेरिकी IT enterprises द्वारा service block
- वैधता पर विवाद हो या न हो, एक बार block लागू होते ही तुरंत business impact वास्तविक हो जाता है
- Trump जैसी राजनीतिक decision-making का अनुमान लगाना कठिन है, और कोई भी company एक बयान या issue के कारण target बन सकती है
- अमेरिकी राष्ट्रपति की शक्तियाँ व्यापक हैं, और uncertainty policy risk को बढ़ा देती है
- यह अक्सर नहीं होता, लेकिन MS products पर गंभीर रूप से निर्भर enterprises·institutions के लिए यह एक “black swan” risk बना रहता है
- भले ही लाखों MS customers में सालाना 1–2 मामलों की संभावना मानी जाए, एक बार फँसने पर नुकसान बहुत बड़ा हो सकता है
Microsoft की service block करने की क्षमता
- cloud·SaaS adoption के बाद Microsoft के पास ग्राहकों के software और data पर व्यावहारिक control है
- पहले (1990s–2000s) organizations अपने mail servers और offline authentication का उपयोग करती थीं, इसलिए बाहरी block कठिन था
- अब सभी services (Exchange, Azure, MS 365, Office आदि) centrally operated हैं
- उदाहरण: Python in Excel में सारा Python code local नहीं, बल्कि Azure containers में चलता है
- central control के ज़रिए account block, data access रोकना, और पूरी service बंद करना संभव है
- service block हमेशा नकारात्मक ही हो, ऐसा नहीं; legal requests या public safety जैसे मामलों में यह सकारात्मक भी हो सकता है
- दुनिया भर में 20 लाख से अधिक companies MS 365 products का उपयोग करती हैं, और MS चाहे तो तुरंत service control संभव है
enterprises की Microsoft dependency structure और वास्तविक नुकसान का पैमाना
- आधुनिक enterprise IT infrastructure mail, collaboration, documents, authentication, backup जैसी core functions के लिए लगभग पूरी तरह MS products पर निर्भर है
- MS Exchange, Teams, Sharepoint, Office, Active Directory, OneDrive, Windows आदि
- खासकर email, documents, identity management जैसी चीज़ें real-time work continuity के लिए अनिवार्य हैं
- वास्तविक outage cases
- 2024 Crowdstrike outage से Fortune 500 कंपनियों को प्रति company औसतन 4.4 करोड़ डॉलर का नुकसान हुआ
- छोटे business में भी प्रति मिनट हज़ारों से लेकर दसियों हज़ार डॉलर तक का नुकसान हो सकता है, और बड़े enterprises में प्रति server प्रति मिनट 16,700 डॉलर तक की हानि संभव है (Gartner आदि के अनुसार)
- केवल अल्पकालिक service disruption से भी कामकाज ठप होना, migration·recovery cost, reputation loss जैसी भारी secondary damage हो सकती है
- मान लें कि 2 हफ्तों में नया IT stack बनाया जाए, तब भी यह वास्तविकता में लगभग असंभव है
risk mitigation (Prevention) पर तार्किक रूप से कितना निवेश किया जा सकता है
- ROSI (Return on Security Investment) formula के अनुसार, single incident की संभावना इतनी कम है कि कंपनियाँ जितना prevention budget उठा सकती हैं, वह बेहद छोटा होता है
- single incident cost (उदाहरण: 3.4 करोड़ डॉलर) × annual probability (1/20 लाख) = annual expected loss 17 डॉलर
- भले ही perfect risk avoidance solution बनाया जाए, तार्किक रूप से invest किया जा सकने वाला amount बहुत कम है
- बड़े enterprises (जैसे Walmart) हर साल MS services पर सैकड़ों मिलियन डॉलर खर्च करते हैं, लेकिन अपना cloud·IT stack बनाना, users को दोबारा train करना आदि की switching cost उससे कहीं अधिक है
- service·license cost savings को जोड़कर भी MS को पूरी तरह replace करने की व्यवहारिक investment capacity सीमित रहती है
risk management की मूलभूत सीमाएँ और जटिलता
- वास्तविक risk management में अगर किसी single incident की विनाशक क्षमता बहुत अधिक हो, तब भी उसकी संभावना बहुत कम होने पर alternative investment अतार्किक लग सकती है
- security ROI, incident probability, damage amount—इन सभी variables में uncertainty बहुत अधिक है, और भरोसेमंद data भी कम है
- अनेक assumptions और uncertainty के बीच decisions बहुत अधिक conservative या भावनात्मक दिशा में जा सकते हैं
- “data-driven decision-making” स्वयं कठिन हो जाती है, इसलिए कई बार ग़ैर-सहज और विवादास्पद management·investment decisions सामने आते हैं
- SMEs के लिए एक ही incident “कंपनी बंद होने” तक ले जा सकता है, फिर भी तार्किक मॉडल यह दिखा सकता है कि risk accept करना ही उचित है
- nation-state·public institutions जैसे संगठनों में cost नहीं बल्कि sovereignty, control, data independence जैसे non-financial factors को प्राथमिकता देकर MS से दूरी बनाने की कोशिश की जा रही है (जैसे Denmark)
निष्कर्ष और संकेत
- MS services पर अत्यधिक निर्भरता वास्तव में बहुत दुर्लभ risk है, लेकिन घटना होने पर संगठन के अस्तित्व तक को खतरे में डाल सकती है
- व्यवहारिक रूप से prevention और alternative infrastructure पर लगाए जा सकने वाले resources·budget बहुत सीमित हैं
- फिर भी लाभ नहीं बल्कि मूल्यों को प्राथमिकता देने वाले organizations (जैसे Denmark सरकार) वास्तव में स्वतंत्र विकल्पों पर विचार कर रहे हैं
- कंपनियों और संस्थानों को अपनी परिस्थिति के अनुसार यथार्थवादी risk assessment और short-term·long-term strategy तैयार करनी चाहिए
- IT policy और management strategy के स्तर पर व्यावहारिक response measures हैं
- emergency में alternative IT environment के लिए manual तैयार करना
- critical data backup और cloud/mail services का diversification
- essential services की redundancy और MS-exit scenario के mock drills
- company·institution के आकार, industry, regulatory requirements आदि के अनुसार sovereignty, cost, business continuity जैसे कई factors को साथ लेकर यथार्थवादी risk management strategy बनानी होगी
1 टिप्पणियां
Hacker News राय
पूरी Microsoft को बैन कर देना solution के विकल्पों को बहुत सीमित कर देता है
यह कंपनी बहुत विशाल है और अंदरूनी तौर पर इसकी संस्कृति भी काफ़ी विविध है
.NET, MSSQL, Visual Studio जैसे products के लगभग कोई बराबरी के alternatives नहीं हैं, और खासकर Visual Studio का debugger experience वास्तविक दुनिया की जटिल समस्याएँ हल करने में लगभग अनिवार्य tool है
यही वजह है कि top-tier game engines Visual Studio पर बहुत निर्भर करते हैं
लेकिन Azure और Windows वे क्षेत्र हैं जहाँ Microsoft में समस्याएँ शुरू होती हैं
अगर 95% gamers MacOS इस्तेमाल करते, तो game developers का tech stack बिल्कुल अलग होता
Microsoft लगातार खराब products बनाती है, और कभी-कभी जो चीज़ें ठीक-ठाक थीं उन्हें भी खराब बना देती है
इसलिए जो products अभी अच्छे लगते हैं, उनके लंबे समय तक अच्छे बने रहने की उम्मीद नहीं है
ज़्यादातर लोग AAA game engines नहीं लिखते
औसतन वे Linux या BSD के manpages से बेहतर हैं, और Apple के कुछ hostile documentation से तो काफ़ी बेहतर हैं
हालाँकि bug report submit करने के लिए internal network की अच्छी समझ या यह पता होना चाहिए कि कहाँ पूछना है
JavaScript code editing में auto-indentation लगभग किसी random number generator जैसी बुरी तरह टूटी हुई है
project चलते समय नए files जोड़ नहीं सकते, और context menu से भी बना नहीं सकते
अगर बाहर से file बदल जाए तो यह बस restart करने की सलाह देता है
इसके अलावा भी अनगिनत छोटी समस्याएँ हैं, जिनमें auto-format indentation खास तौर पर बेहद तकलीफ़देह है
यह एक ऐसा single point of failure है जिसे आप नियंत्रित नहीं कर सकते
यही बात Google या YouTube पर भी लागू होती है, और यह मानो एक ही इंजन वाले passenger plane को उड़ाने जितना जोखिमपूर्ण लगता है
लोग आखिर ऐसा जोखिम क्यों लेते हैं, यह सवाल है
यह किसी garage से शुरू हुए 2-व्यक्ति startup से कहीं अधिक सुरक्षित है
contract में service level, liability, expectations आदि पर सख़्त शर्तें तय होती हैं
यह वैसा है जैसे कोई restaurant अपनी सब्ज़ियाँ दोस्त के hobby garden से नहीं बल्कि बड़े farm से ले
व्यावहारिक रूप से multiple failure points बनाना एक निश्चित scale के बाद ही संभव होता है, और इस समस्या पर बहुत ध्यान देने की बजाय अपने business पर focus करना ज़्यादा यथार्थवादी है
असल में ऐसे leadership भी रहे हैं जिन्हें इसकी चिंता थी, लेकिन redundancy की लागत हमेशा business में कहीं और निवेश करने की तुलना में कम असरदार साबित हुई
वे ज़रूरत की हर चीज़ के साथ आसानी से integrate हो जाती हैं
ज़्यादातर लोग वेतन पर निर्भर हैं, और खाना उगाने या emergency के लिए तैयारी करने की उनकी क्षमता भी सीमित है
ऐसी निर्भरताएँ लगातार और मज़बूत हो रही हैं
कम लोकप्रिय service पर जाने से आने वाली परेशानियों को देखते हुए, single point of failure जानते हुए भी मौजूदा service पर निर्भर रहना आखिरकार एक तर्कसंगत विकल्प है
अगर कोई संगठन MS products पर बहुत निर्भर है, तो उसे गंभीरता से सोचना चाहिए: 'क्या यह मेरे साथ भी हो सकता है?', 'ऐसी स्थिति को रोकने के लिए मुझे कितना निवेश करना होगा?'
इस लेख में तथ्यों को समझकर security investment के ROI के नज़रिए से व्यावहारिक ढंग से approach किया गया है
सिर्फ Microsoft ही नहीं, Google, Amazon, Apple भी अमेरिकी सरकार की माँगों को शायद ठुकरा नहीं पाएँगे
ऐसी service को outsource करना जिसका विकल्प नहीं है — असली समस्या वही है
अगर technology को flexible रखा जाए, तो यह जोखिम खत्म हो जाता है
या तो MS को ultimatum दिया जाए कि वह EU के सीधे नियंत्रण वाली स्वतंत्र legal entity बनाए, या फिर कानून के ज़रिए ऐसी संरचना अनिवार्य की जाए
आख़िर में अगर US Microsoft से नाता टूट भी जाए, तब भी EU MS अपने दम पर चल सकना चाहिए; अगर ऐसी संरचना नहीं है, तो अमेरिका-नियंत्रित Microsoft यूरोप के लिए एक गंभीर security risk है
जैसे ही राजनीतिक माहौल बदलता है, अगर उसके लिए तैयारी न हो तो केवल technology से जवाब नहीं दिया जा सकता
कुछ Microsoft products गहराई तक घुस जाते हैं, लेकिन वास्तव में ज़्यादातर कंपनियाँ उसकी बहुत विस्तृत product range का इस्तेमाल नहीं करतीं
ज़्यादातर को बाँधे रखने वाली चीज़ authentication services (Azure AD आदि) हैं
authentication का प्रबंधन तो शायद उल्टा अधिक आसान हो सकता है
अगर Microsoft भविष्य में और ज़्यादा sanctions लागू करने लगे, तो जोखिम असहनीय रूप से बढ़ जाएगा
ऐसे risks को आगे हमेशा ध्यान में रखना होगा
जब कानून अच्छी तरह overlap करते हैं तो स्थिति साफ़ होती है, लेकिन जब ऐसा नहीं होता तो चीज़ें अनिश्चित और कठिन हो जाती हैं
जैसा कि privacy और cookies से जुड़े कानूनों में देखा जा सकता है, यह बहुत जटिल है
network stack, protocols, physical principles जैसी चीज़ों को आम लोग आम तौर पर समझा नहीं पाते
कुछ tech visionaries अपने email servers खुद चलाते हैं, लेकिन email जैसी चीज़ को कोई व्यक्ति अकेले चलाए — इसके लिए परिस्थितियाँ बहुत कठोर हैं
सिर्फ spam की वजह से नहीं, बल्कि बड़े services से trust पाना भी लगभग असंभव के क़रीब है
Excel या Google Sheets के बिना जिया जा सकता है, लेकिन spreadsheet जैसी चीज़ के बिना काम करना बहुत मुश्किल लगता है
business के अचानक ढह जाने की संभावना को सांख्यिकीय रूप से स्वीकार भी किया जाए, तब भी insurance से risk कम हो जाए तो खेल खत्म नहीं होता
Active Directory, Teams, Outlook/Exchange जैसी चीज़ों के लिए वास्तव में कोई व्यावहारिक replacement नहीं है
insurance हमेशा negative expected value होता है, फिर भी कंपनियाँ risk के कारण insurance लेती हैं
इसके अलावा, control cut-off का risk 20 लाख में 1 जितना कम मानना मुश्किल है
उदाहरण के लिए, अगर Trump किसी पूरे देश को sanctions list में जोड़ दे, तो उस देश की सभी कंपनियाँ कट सकती हैं