चोरी हुई Microsoft key: असर अनुमान से कहीं बड़ा

 (wiz.io)
1 पॉइंट द्वारा GN⁺ 2023-07-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Storm-0558 घटना Exchange Online और Outlook.com breach के रूप में जानी गई, लेकिन विश्लेषण सामने आया कि चोरी हुई MSA signing key का इस्तेमाल Azure AD applications के OpenID v2.0 tokens forge करने में भी किया जा सकता था
  • संभावित प्रभाव का दायरा Microsoft apps तक फैलता है जो personal Microsoft account authentication इस्तेमाल करते हैं, “Login with Microsoft” वाले customer apps, और कुछ शर्तों के तहत multi-tenant apps तक
  • संबंधित public key कम-से-कम 2016 से Microsoft OpenID key list में थी, 27 जून 2023 से 5 जुलाई के बीच बदली गई, और इसका thumbprint Microsoft द्वारा प्रकाशित acquired signing key से मेल खाता है
  • Microsoft ने key revoke करके नए forged tokens को रोक दिया, लेकिन key revoke होने से पहले बने sessions या पुराने public key cache पर भरोसा जारी रखने वाले apps को अलग से जांचने की जरूरत है
  • Forged tokens offline बनाए जा सकते हैं, इसलिए Azure portal में issuance traces नहीं बचते; raw token या kid logs न हों तो breach की पुष्टि बेहद कठिन है

Exchange Online से आगे का प्रभाव दायरा

  • Microsoft और CISA ने Exchange Online और Outlook.com के कई customers को प्रभावित करने वाली security incident का खुलासा किया
  • Microsoft के अनुसार, चीन से जुड़े threat actor के रूप में पहचाने गए Storm-0558 ने MSA key नाम की private cryptographic key हासिल की और Outlook Web Access तथा Outlook.com के लिए access tokens forge किए
  • बताया गया है कि threat actor ने Microsoft की token validation process में मौजूद दो security issues का भी साथ में दुरुपयोग किया
  • Wiz Research के विश्लेषण के अनुसार, compromised key केवल Outlook.com और Exchange Online तक सीमित नहीं थी; इसका इस्तेमाल कई Azure Active Directory applications के लिए access tokens forge करने में भी किया जा सकता था
    • Personal account authentication support करने वाली applications
    • SharePoint, Teams, OneDrive जैसे Microsoft-managed applications
    • “Login with Microsoft” support करने वाली customer applications
    • कुछ शर्तों वाले multi-tenant applications

चोरी हुई key की पुष्टि कैसे हुई

  • 11 जुलाई 2023 को Microsoft ने खुलासा किया कि malicious actor ने MSA consumer signing key हासिल कर ली थी और Exchange Online तथा Outlook.com accounts के लिए access tokens forge कर सकता था
  • Wiz ने Microsoft account और Azure Active Directory applications के लिए OpenID tokens sign कर सकने वाली key की पहचान करने के लिए Microsoft की OpenID token validation official documentation की जांच की
  • उस समय Azure personal account v2.0 applications 8 public keys पर निर्भर थीं, और Microsoft account सक्षम करने वाली Azure multi-tenant v2.0 applications 7 public keys पर निर्भर थीं
  • Internet Archive Wayback Machine से जांच में पाया गया कि कम-से-कम 2016 से list में मौजूद एक public key 2023 में 27 जून से 5 जुलाई के बीच बदली गई
    • यह timing Microsoft द्वारा अपने blog में बताई गई acquired key replacement timing से मेल खाती है
    • पिछला public key certificate 5 अप्रैल 2016 को जारी हुआ था और 4 अप्रैल 2021 को expire हुआ
    • thumbprint वही है जिसे Microsoft ने अपने latest blog में “Thumbprint of acquired signing key” के रूप में प्रकाशित किया
  • Storm-0558 ने जो key हासिल की थी, वह Microsoft के MSA tenant के लिए private key थी, लेकिन विश्लेषण के अनुसार वह कई Azure Active Directory applications के OpenID v2.0 tokens भी sign कर सकती थी

OpenID signing key breach खतरनाक क्यों है

  • Azure identity platform application type के अनुसार अलग-अलग trusted public key lists प्रकाशित करता है, और Azure Active Directory द्वारा जारी tokens की integrity verify करने के लिए इनका इस्तेमाल किया जाता है
  • AAD applications सही public key list से token signature verify करने के बाद तय करती हैं कि token trusted है या नहीं
  • अगर list में शामिल कोई key compromise हो जाए, तो उस list से verify करने वाली applications कुछ conditions में forged access token को valid token के रूप में स्वीकार कर सकती हैं
  • Wiz ने Microsoft blog से जो निष्कर्ष निकाला, उसके अनुसार Storm-0558 को AAD access token signing और validation में इस्तेमाल होने वाली कई keys में से एक तक access मिला प्रतीत होता है
  • Compromised key personal accounts और mixed-audience, यानी multi-tenant या personal account-targeted AAD applications के OpenID v2.0 access tokens sign करने के लिए trusted थी
  • नतीजतन, सैद्धांतिक रूप से Storm-0558 Microsoft OpenID v2.0 mixed audience और personal account certificates पर भरोसा करने वाली प्रभावित applications में किसी भी user के रूप में authenticate होने वाले tokens forge कर सकता था
  • identity provider की signing key को TLS key से अधिक शक्तिशाली secret माना जा सकता है
    • TLS key leak होने पर भी attacker को प्रभाव बढ़ाने के लिए उस server का impersonation करना पड़ता है
    • identity provider key email inboxes, file services, cloud accounts आदि तक single step में access दिला सकने वाले tokens forge करने में इस्तेमाल हो सकती है
    • यही जोखिम सिर्फ Microsoft नहीं, बल्कि Google, Facebook, Okta जैसे प्रमुख identity providers की signing key leak पर भी लागू होता है

प्रभावित application types

  • प्रभावित targets Microsoft के OpenID v2.0 का इस्तेमाल करने वाली Azure Active Directory applications तक सीमित हैं
  • v1.0 applications compromised key को token validation में इस्तेमाल नहीं करतीं, इसलिए वे प्रभावित नहीं हैं

  • केवल personal Microsoft accounts support करने वाली applications

    • Microsoft v2.0 protocol इस्तेमाल करने और “Personal Microsoft accounts only” support करने वाली Azure Active Directory applications प्रभावित हैं
    • इसमें Outlook, SharePoint, OneDrive, Teams जैसे Microsoft-managed applications और Microsoft Account authentication support करने वाली customer applications शामिल हैं

  • Multi-tenant और personal Microsoft accounts दोनों support करने वाली applications

    • “mixed audience” support करने और Microsoft v2.0 protocol इस्तेमाल करने वाली Azure Active Directory applications भी प्रभावित हैं
    • threat actor personal Microsoft account से login किए हुए application user का impersonation करने वाला valid access token forge कर सकता था
    • Microsoft ने MSA key की organizational accounts का impersonation करने की क्षमता सीमित करने के लिए OpenID protocol extension पेश किया
    • Developers को issuer claim को OpenID public key list के issuer field से compare करके validate करना चाहिए
    • यह validation MSA tenant के अलावा किसी issuer वाले access token पर MSA key के signature को रोकने के लिए है
    • extension Microsoft-specific है और implementation की जिम्मेदारी application owner की है
    • Wiz का मानना है कि कई applications में यह validation procedure नहीं हो सकता, और इसके चलते organizational account impersonation की संभावना भी बची हो सकती है
    • Microsoft blog के अनुसार OWA भी similar issue से प्रभावित था
    • Microsoft ने 12 जुलाई को यह validation feature official Azure SDK में जोड़ा

  • केवल multi-tenant support करने वाली applications

    • अगर multi-tenant application “Organizations” के बजाय common v2.0 key endpoint पर निर्भर रहने के लिए configured है, तो वह प्रभावित है
    • ऐसे configuration को गलत configuration माना जाना चाहिए
    • Microsoft की official documentation यह साफ नहीं करती कि “common” endpoint कब इस्तेमाल करना चाहिए, इसलिए कुछ multi-tenant applications भी प्रभावित हो सकती हैं

  • Single-tenant applications

    • “इस organizational directory के accounts only” support करने वाली single-tenant applications प्रभावित नहीं हैं

Token forging संभव होने की conditions

  • OpenID token validation में application developers को verify करना चाहिए कि token इच्छित scope के अनुरूप authorized private key से signed है, और aud field target application scope से match करता है
  • Application jwks_uri नाम के metadata endpoint से signature validation के लिए allowed certificates लाकर token validate करती है
  • threat actor JWT token बना सकता है, victim email address जैसे data भर सकता है, फिर Azure Active Directory public certificate endpoint में registered compromised key से sign करके valid access token forge कर सकता है
  • उदाहरण के तौर पर बताई गई compromised key का kid है 1LTMzakihiRla_8z2BEJVXeWMqo
  • Microsoft guidance के अनुसार token valid होने के लिए iss claim jwks_uri endpoint के issuer field में specified MSA tenant issuer होना चाहिए, और tid claim भी MSA tenant ID 9188040d-6c67-4c5b-b112-36a304b66dad होना चाहिए
  • AAD mixed-audience applications में, जब तक personal account का impersonation किया जा रहा हो, MSA tenant द्वारा Azure AD accounts के लिए signed token valid माना जा सकता है
  • ID Token validation details Microsoft की official guidance में देखी जा सकती हैं

Key revocation के बाद भी बचे जोखिम

  • Microsoft ने compromised key revoke कर दी है, इसलिए Azure Active Directory applications अब उस key से forged tokens को valid token के रूप में स्वीकार नहीं करतीं
  • लंबे expiry time वाले tokens भी applications में reject हो जाते हैं
  • हालांकि अगर key revocation से पहले customer application में session पहले ही बन गया था, तो threat actor application permissions का इस्तेमाल करके persistence हासिल कर सकता था
    • Application-specific access key issuance
    • Application-specific backdoor configuration
    • Microsoft action से पहले Storm-0558 द्वारा OWA के लिए access token forge करके valid Exchange Online access token जारी करने का मामला
  • Microsoft certificate revocation से पहले की AAD public key copies रखने वाली applications भी जोखिम में हो सकती हैं
    • अगर वे local certificate store या cached keys का उपयोग करती हैं और compromised key पर भरोसा जारी रखती हैं, तो वे token forging के लिए vulnerable हैं
    • Microsoft local stores और certificate caches को कम-से-कम दिन में एक बार refresh करने की सलाह देता है

Azure users को क्या check करना चाहिए

  • अपने environment में compromised key usage जांचने के लिए potentially affected applications की पहचान करनी होगी, forged token usage traces ढूंढने होंगे, और Microsoft द्वारा प्रकाशित Indicators of Compromise का उपयोग करके related IP activity check करनी होगी
  • अगर किसी application ने Microsoft OpenID public certificates cache किए हैं, तो cache refresh करना चाहिए
  • Microsoft ने MSA key से organizational accounts में authentication रोकने के लिए additional validation official Azure SDK में जोड़ा है, और उस package के users को latest version पर update करना चाहिए

Detection मुश्किल क्यों है

  • threat actor access tokens offline forge कर सकता है, इसलिए Azure portal में token issuance traces नहीं बचते
  • Cloud customers को key usage जांचने के लिए प्रभावित हो सकने वाली AAD applications के application-specific logs review करने होंगे
  • Wiz द्वारा पहचाने गए प्रभावित targets वे applications हैं जिन्होंने Microsoft v2.0 access token validation के लिए नीचे दिए endpoints इस्तेमाल किए
  • Potentially affected AAD applications की पहचान Azure CLI से उन apps को query करके की जा सकती है जिनका signinaudience AzureADMultipleOrgs, AzureADandPersonalMicrosoftAccount, PersonalMicrosoftAccount है
  • Azure WebApps पर redirect होने वाले AAD apps भी अलग CLI query से खोजे जा सकते हैं
  • Application में इस्तेमाल हुए access token को decode करके JOSE Header के kid field में 1LTMzakihiRla_8z2BEJVXeWMqo string है या नहीं, यह check करने पर compromised key से signed tokens मिल सकते हैं
  • Microsoft के अनुसार compromised key inactive थी, इसलिए इस key से signed सभी access tokens को suspicious माना जाना चाहिए
  • Application-specific logging में standardized practice की कमी है
    • कई application owners के पास raw access tokens या signing key शामिल करने वाले detailed logs नहीं होते
    • इस वजह से events की पहचान और investigation बहुत मुश्किल हो सकती है
  • Personal Microsoft accounts support न करने वाली multi-tenant-only AAD applications में iss और tid claims से forged tokens detect किए जा सकते हैं
    • MSA tenant ID 9188040d-6c67-4c5b-b112-36a304b66dad से signed access token connection attempts compromised key usage का संकेत दे सकते हैं
  • अगर WebApp में HTTP Logs enabled हैं, तो Microsoft blog में दिए गए threat actor-related IP addresses ने application access किया या नहीं, इसे Log Analytics से check किया जा सकता है

बचे सवाल और practical conclusion

  • कुल प्रभाव शुरुआती जानकारी से कहीं बड़ा है, और cloud trust तथा खास तौर पर cloud के basic component identity layer पर long-term प्रभाव डाल सकता है
  • Potentially vulnerable applications Microsoft apps और customer apps सहित लाखों में थीं, और कई के पास breach का निर्धारण करने के लिए पर्याप्त logs नहीं हैं
  • Application owners को Azure SDK को latest version पर update करना चाहिए और सबसे पहले यह check करना चाहिए कि application cache refresh हो चुका है
  • जिन applications का cache update नहीं हुआ है, वे compromised key इस्तेमाल करने वाले threat actors के लिए अभी भी vulnerable हो सकती हैं
  • मामला अभी जांच में है, और threat actor ने key कैसे हासिल की, ठीक कब हुआ, और क्या दूसरी keys भी compromised हुईं—इन सवालों का जवाब public information से देना मुश्किल है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-24
Hacker News टिप्पणियाँ

  • Identity provider signing key आज के दौर में सबसे शक्तिशाली secret values में से एक के करीब है। उदाहरण के लिए, यह TLS key से कहीं ज़्यादा शक्तिशाली है
    कई मायनों में यह certificate authority (CA) की key के बराबर है, और Microsoft तथा Azure services इस्तेमाल करने वाली संस्थाओं को संभावित प्रभाव का आकलन करना चाहिए
    लगता है लोग पुरानी कहावत “सारे अंडे एक टोकरी में मत रखो” भूल गए हैं

    • अगर ये keys इतनी महत्वपूर्ण हैं, तो समझ नहीं आता कि इन्हें CA key स्तर के security measures के साथ क्यों नहीं संभाला जाता
      यह भी सवाल है कि क्यों दर्जनों, सैकड़ों, शायद हज़ारों servers कुछ ही keys साझा करते हैं
      HSM-आधारित root key, data center-वार intermediate keys, server-वार temporary signing keys, और certificate revocation list कहाँ हैं, यह जानने की इच्छा है
      यह भी सोचने वाली बात है कि ऐसे हमले में bearer token को सुरक्षित रखना वास्तव में संभव है या नहीं, और क्या फिर से उस मॉडल पर लौटना पड़ेगा जिसमें origin service को random value दिखाकर payload सुरक्षित तरीके से लिया जाता है
    • शायद जब यह कहावत बनी थी, तब मुर्गियाँ ज़्यादा से ज़्यादा functionality को एकीकृत करके quality of life बढ़ाने के लिए इतना ज़ोर नहीं दे रही थीं
      यानी अब ऐसी सुविधाएँ बन गई हैं जो तभी काम करती हैं जब सारे अंडे एक ही जगह रखे जाएँ
    • हमारी कंपनी ने भी Office 365, Teams वगैरह सब कुछ पर all-in कर दिया है
      सब ढहने की स्थिति के लिए मैंने popcorn तैयार रखी है, और एक बात पक्की है कि कंपनी खुद को दोष नहीं देगी
    • समझ नहीं आता कि अंडों को आखिर कैसे बाँटना चाहिए
      क्या मतलब बस किसी ऐसे दूसरे vendor का इस्तेमाल करना है जिसने अपनी key नहीं गंवाई हो
    • व्यावहारिक रूप से इससे कैसे बचा जा सकता है, समझ नहीं आता
      अब तो लगता है कि असल में सिर्फ चार tech giants ही बचे हैं

  • निष्कर्ष यह निकला कि “compromised MSA key की मदद से attackers कई तरह के Azure Active Directory applications के लिए access token forge कर सकते थे”
    इसमें SharePoint, Teams, OneDrive, “Sign in with Microsoft” को सपोर्ट करने वाले customer applications, और वे सभी applications शामिल हैं जो personal account authentication सपोर्ट करती हैं, जैसे कुछ शर्तों वाले multi-tenant applications
    उम्मीद है कि Microsoft ने हाल ही में Azure AD का नाम बदलकर Entra ID यूँ ही नहीं रखा: https://devblogs.microsoft.com/identity/aad-rebrand/

    • यह मैंने पहली बार सुना है, लेकिन Microsoft की naming disasters अंतहीन मनोरंजन देती हैं
      जब security product की बात हो तो मैं ऐसे vendor के बारे में नहीं सोचना चाहता जो बुरे actors को बाहर रोकने के बजाय लोगों को अंदर “आने” देता हो। entra, entrar से आया है, यानी enter करना/अंदर आना, इसलिए /s
      स्पेनिश में यह imperative जैसा भी लगता है, यानी जैसे किसी से कहा जा रहा हो: “अंदर आओ!”

  • “मौजूदा public key का certificate 5 अप्रैल 2016 को जारी हुआ था, 4 अप्रैल 2021 को expire हो गया था, और उसका fingerprint उसी key के fingerprint से मेल खाता था जिसे Microsoft ने अपनी नवीनतम blog post में ‘प्राप्त signing key का fingerprint’ कहा”
    अगर मैंने इसे सही पढ़ा है, तो क्या इसका मतलब है कि key expire होने के बाद भी इस्तेमाल होती रही?

    • जिन systems में ये keys इस्तेमाल हुईं, उनमें validity check कैसे काम करता है यह मुझे नहीं पता, लेकिन आम तौर पर key या certificate-आधारित validation में expired key/certificate को संभालने के दो तरीके होते हैं
      Microsoft ने इन keys को जहाँ भी इस्तेमाल किया हो, वहाँ कौन-सा तरीका था यह जानने की उत्सुकता है
      एक TLS validation तरीका है, जहाँ Cn पर Cn-1 का signature होता है, फिर वह … C0 तक जाती certificate chain को check करते समय मोटे तौर पर यह ऐसे काम करता है
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 return NOT_EXPIRED
      हर certificate की expiry को current time के आधार पर check किया जाता है
      दूसरा तरीका code signing में इस्तेमाल होता है, और मोटे तौर पर यह ऐसा है
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      Cn को current time के आधार पर check किया जाता है, और बाकी को ठीक नीचे वाले certificate पर sign किए जाने के समय के आधार पर check किया जाता है
      code signing ऐसा क्यों करता है यह समझ में आता है। मूल रूप से यह digital notarization है, इसलिए अगर बाद में notary अपनी योग्यता खो दे और उसका license expire हो जाए, तो पहले से notarize किए गए document को un-notarized नहीं मान लिया जाना चाहिए
    • जब Microsoft ने ग्राहकों से कहा कि “Storm-0558 ने एक inactive MSA consumer signing key हासिल की,” तब उसे कहना चाहिए था कि “Storm-0558 ने एक expired MSA consumer signing key हासिल की”
      और जब उसने कहा कि “validation issue के कारण इस key पर Azure AD token signing के लिए trust किया जा सकता था,” तब उसे कहना चाहिए था कि “कई validation issues के कारण इस key पर Azure AD token signing के लिए trust किया जा सकता था”
      और जब उसने कहा कि “actors target environment, logging policy, authentication requirements, policies और procedures को अच्छी तरह जानते थे,” तब बेहतर होता कि वह कुछ ऐसा कहता
      “हो सकता है actors ने बस एक दुस्साहसी hit-and-run की कोशिश की हो और policy जैसी छोटी-मोटी चीज़ों पर एक सेकंड भी ध्यान न दिया हो। या फिर actors इतने अनाड़ी रहे हों कि उन्हें यह भी पता न हो कि अमेरिकी विदेश विभाग mailbox access events को विस्तार से log कर पाने वाले privilege के लिए हमें कहीं ज़्यादा पैसे देता है। Boeing ने MCAS के साथ मानो इसका इशारा पहले ही दे दिया था। इसके अलावा actors शायद यह भी नज़रअंदाज़ कर गए कि Chrome 92 को आख़िरी बार 2021 में update किया गया था, और यह उन अमेरिकी विभागीय ICT systems पर हमला करने के लिए काफ़ी खराब user agent choice थी जहाँ latest browser इस्तेमाल होना चाहिए। साथ ही ऐसा भी लगता है कि उन्हें इस बात की लगभग कोई समझ नहीं थी कि अमेरिकी विदेश विभाग के mailboxes को कैसे access किया जाता है, और उन्होंने पूरे यूरोप में बेतरतीब public data centers का इस्तेमाल करके बेहद खराब अंदाज़े लगाए।”
      [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
      [2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
      [3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...

  • इस key के HSM में होने की संभावना बहुत कम लगती है
    जब भी मैं ऐसी ख़बर देखता हूँ कि कोई key, जिसे HSM में होना चाहिए था, चोरी हो गई, तो मुझे हर बार हैरानी होती है

    • HSM में मौजूद keys का इस्तेमाल teams के लिए आसान नहीं होता, network-connected HSM भी होते हैं, लेकिन developers की अक्सर इस्तेमाल होने वाली toolchains के साथ उनका integration अच्छा नहीं होता
      हाल ही में मुझे toolchains और hardware security enclave के बीच की खाई पाटने के लिए एक आदर्श tool खुद बनाने का मौका मिला: https://keymux.com
    • लोकप्रिय HSMs में से एक, Thales Luna Network HSM, प्रति सेकंड 20,000 ECC operations कर सकता है [1]
      Azure AD के scale को देखते हुए भी, signing के लिए Microsoft को बहुत सारे HSMs की ज़रूरत न पड़ती
      लेकिन HSMs को manage करना ख़ास तौर पर आसान नहीं है, इसलिए यह उन कारणों में से एक हो सकता है जिनकी वजह से इनका इस्तेमाल ज़रूरत के मुताबिक़ व्यापक नहीं है
      [1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
    • दो scenarios हैं
      पहला, Microsoft ने JWT signing key को memory में लोड करके इस्तेमाल किया हो, और attacker ने code injection या उस process की memory image तक access के ज़रिए key हासिल की हो
      दूसरा, Microsoft ने वास्तव में HSM इस्तेमाल किया हो, लेकिन key को geographically distribute करना पड़ा हो, और attacker ने उसी प्रक्रिया में key तक पहुँच बना ली हो
      पहला ज़्यादा संभव लगता है, लेकिन दूसरे को भी नकारा नहीं जा सकता
    • HSM क्या है?

  • क्या FAANG कंपनियों को एक-दूसरे के ख़िलाफ़ cyberwarfare/espionage करने की कानूनी अनुमति नहीं दे देनी चाहिए?
    तब शायद वे अस्पष्टता पर निर्भर रहने के बजाय कम से कम न्यूनतम security best practices के स्तर तक तो पहुँचेंगी

    • सभी bug bounty programs चलाते हैं
      जब तक आप वास्तविक नुकसान नहीं पहुँचाते या वास्तविक customer data download नहीं करते, और जो मिला है उसे disclose कर देते हैं, यह पहले से ही legal है

  • Satya को अगली earnings call में इस गड़बड़ी को ढकने के लिए शायद AI शब्द कहीं ज़्यादा बार बोलना पड़ेगा

  • यह कल्पना करना मुश्किल है कि कोई breach उससे बुरा हो सकता है जिसमें कोई विदेशी शक्ति, उसी शक्ति का सामना कर रहे हमारे प्रतिनिधियों के email accounts में घुस जाए
    उम्मीद है कि अमेरिकी सरकार computing को बड़े cloud providers की ओर ले जाने वाली नीतियों की गंभीरता से फिर से समीक्षा करेगी

  • “अंत में, हम Microsoft टीम का धन्यवाद करते हैं, जिसने हमारे साथ क़रीबी सहयोग किया और यह सुनिश्चित करने में मदद की कि यह लेख तकनीकी रूप से सटीक है”
    यह ख़बर शुक्रवार को सार्वजनिक करने का फ़ैसला कैसे लिया गया होगा?

    • summer Friday news dump के बाद की स्थिति देखें तो सोमवार शाम तक भी ख़ामोशी थी
      मैंने Google News में “microsoft” खोजकर पहले 5 पेज देखे और फिर छोड़ दिया, लेकिन इससे जुड़ा ज़िक्र कुल 2 ही मिला
      ज़्यादातर “news” प्रचारात्मक लेख, product promotion, और stock price से जुला शोर था

  • “इस घटना का कुल प्रभाव हमारी शुरुआती समझ से कहीं बड़ा है। यह घटना cloud पर भरोसे और उसे सहारा देने वाले मुख्य घटकों पर, और सबसे बढ़कर identity layer पर, जो cloud में हम जो कुछ भी करते हैं उसका बुनियादी ताना-बाना है, लंबे समय तक असर डालेगी। हमें इससे सीखना और सुधार करना चाहिए”
    सबसे पहले शायद सब कुछ cloud में न डालने से शुरुआत करनी चाहिए
    समस्या cloud ख़ुद नहीं, बल्कि आख़िरकार monopoly, या कुछ बड़ी कंपनियों के cartel को जन्म देने वाली टूटी हुई पूंजीवादी अर्थव्यवस्था है
    लंबी पूँछ वाले छोटे व्यवसायों के लिए बड़ी कंपनियों के products और services का इस्तेमाल करना तर्कसंगत नहीं होता, लेकिन बाज़ार के विजेता को और ताकत देने का नतीजा आख़िरकार इतनी बड़ी कंपनी कि उसे डूबने नहीं दिया जा सके के रूप में निकलता है
    ऐसी बड़ी कंपनियों में एक गलती, एक फिसलन भर से attack surface बहुत बड़ा हो जाता है। ऐसे हादसों का सवाल यह नहीं कि होंगे या नहीं, बल्कि कब होंगे, यही है
    लंबे समय में समाज को बचना है तो थोड़ी सुविधा क़ुर्बान करनी पड़े, तब भी federated services ही जवाब हैं

    • कंप्यूटर क्षेत्र में इसका कारण ज़्यादातर “IBM को खरीदने पर किसी की नौकरी नहीं गई” वाली मानवीय प्रवृत्ति के ज़्यादा क़रीब है
      business leaders ऐसे tech geeks नहीं होते जो बड़े और बेहतर federated services का सपना देखें
      IT आम तौर पर profit and loss statement में भी बड़ा खर्च है, और computer समस्याएँ सीखने, फ़ैसले लेने और उनसे जूझने में लगने वाले समय और पीड़ा के हिसाब से भी
      एक उपमा दें तो, अगर मौसम संदिग्ध होने पर भी आपने Microsoft Airlines चुन ली, तो उड़ान रद्द होने और देर होने पर भी आपके साथ और भी लोग होंगे और सहानुभूति भी ज़्यादा मिलेगी
      इसके उलट अगर आप ट्रेन लेने का अलग रास्ता चुनते हैं, तो train timetable और stations वगैरह समझने का पूरा बोझ आप पर ही आता है। क्योंकि “plane वाला तरीका सब जानते हैं”
      और अगर Microsoft Air सुरक्षित पहुँच गई लेकिन ट्रेन में समस्या आ गई, तो आप रसोई के फ़र्श पर भाप छोड़ते ढेर की तरह अकेले उछलते रह जाएँगे

  • यह बेहतरीन संक्षेप था, और डरावना भी
    विषय जटिल था, फिर भी इसे आसानी से समझ में आने वाला बनाकर समझाया गया था