सार्वजनिक S3 bucket से 86,000 से अधिक मेडिकल रिकॉर्ड और PII उजागर: ‘नर्सों का Uber’ ESHYFT मामला

 (websiteplanet.com)
1 पॉइंट द्वारा GN⁺ 2025-03-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • न्यू जर्सी स्थित HealthTech कंपनी ESHYFT से जुड़े एक सार्वजनिक डेटाबेस में 86,341 रिकॉर्ड और 108.8GB डेटा उजागर हुआ। यह प्लेटफ़ॉर्म 29 राज्यों में हेल्थकेयर सुविधाओं और नर्सिंग स्टाफ को जोड़ता है
  • उजागर सामग्री में प्रोफ़ाइल और चेहरे की तस्वीरें, मासिक शिफ्ट शेड्यूल CSV, प्रोफेशनल सर्टिफिकेट, जॉब असाइनमेंट कॉन्ट्रैक्ट, CV/रिज़्यूमे और अतिरिक्त PII शामिल थे
  • कुछ फ़ाइलें ऐप पर अपलोड किए गए मेडिकल दस्तावेज़ लगती हैं, संभवतः अनुपस्थिति या बीमारी की छुट्टी के कारणों के प्रमाण के रूप में; इनमें डायग्नोसिस, प्रिस्क्रिप्शन और ट्रीटमेंट जानकारी शामिल थी, जो HIPAA के दायरे में आ सकती है
  • शोधकर्ता की जिम्मेदार disclosure सूचना के बाद भी डेटाबेस की पहुंच सीमित होने में एक महीने से अधिक लगा, जबकि नियंत्रण, एक्सपोज़र अवधि और किसी तीसरे पक्ष की पहुंच की पुष्टि नहीं हुई
  • हेल्थकेयर स्टाफिंग प्लेटफ़ॉर्म्स को संवेदनशील डेटा एन्क्रिप्शन, नियमित सुरक्षा ऑडिट, न्यूनतम रिटेंशन और अनामीकरण, संवेदनशीलता के अनुसार अलग स्टोरेज, MFA, और breach response योजना व रिपोर्टिंग चैनल रखने चाहिए

ESHYFT के सार्वजनिक डेटाबेस में मिला एक्सपोज़र

  • साइबरसिक्योरिटी शोधकर्ता Jeremiah Fowler ने पासवर्ड सुरक्षा या एन्क्रिप्शन के बिना एक डेटाबेस खोजा और इसकी जानकारी Website Planet के साथ साझा की
  • डेटाबेस में ESHYFT से संबंधित प्रतीत होने वाले 86,341 रिकॉर्ड थे और उसका कुल आकार 108.8GB था
  • डेटाबेस का नाम और आंतरिक दस्तावेज़ संकेत देते थे कि ये रिकॉर्ड ESHYFT के स्वामित्व में थे, और अधिकांश दस्तावेज़ “App” फ़ोल्डर में थे
  • ESHYFT न्यू जर्सी स्थित एक HealthTech कंपनी है, जो हेल्थकेयर सुविधाओं और मेडिकल स्टाफ को जोड़ने वाला मोबाइल ऐप प्लेटफ़ॉर्म चलाती है
    • लक्षित स्टाफ में Certified Nursing Assistants(CNAs), Licensed Practical Nurses(LPNs), Registered Nurses(RNs) शामिल हैं
    • ऐप Apple App Store और Google Play Store पर उपलब्ध है
    • Google Play Store के अनुसार इसके 50,000 से अधिक डाउनलोड हैं
    • Apple अब उपयोगकर्ता आँकड़े उपलब्ध नहीं कराता

उजागर फ़ाइलें और मेडिकल जानकारी की संवेदनशीलता

  • सीमित सैंपल जांच में कई प्रकार की फ़ाइलें मिलीं
    • यूज़र प्रोफ़ाइल या चेहरे की तस्वीरें
    • मासिक शिफ्ट शेड्यूल लॉग वाली .csv फ़ाइलें
    • प्रोफेशनल सर्टिफिकेट
    • जॉब असाइनमेंट कॉन्ट्रैक्ट
    • CV, रिज़्यूमे और अतिरिक्त व्यक्तिगत पहचान योग्य जानकारी (PII)
  • एक अकेले स्प्रेडशीट दस्तावेज़ में 800,000 से अधिक एंट्री थीं
    • नर्सों के आंतरिक ID
    • सुविधा का नाम
    • शिफ्ट के समय और तारीखें
    • काम के घंटे आदि
  • ऐसे मेडिकल दस्तावेज़ भी मिले जो संभवतः ऐप पर अपलोड किए गए थे
    • ये किसी नर्स के शिफ्ट मिस करने या बीमारी की छुट्टी लेने के कारण का प्रमाण देने वाली फ़ाइलें हो सकती हैं
    • मेडिकल रिपोर्ट्स में डायग्नोसिस, प्रिस्क्रिप्शन और ट्रीटमेंट जानकारी शामिल थी
    • यह जानकारी HIPAA रेगुलेशन के दायरे में आ सकती है

सूचना के बाद की कार्रवाई और बाकी अनिश्चितताएँ

  • शोधकर्ता ने तुरंत ESHYFT को जिम्मेदार disclosure सूचना भेजी
  • डेटाबेस पर सार्वजनिक पहुंच एक महीने से अधिक समय बाद सीमित की गई
  • ESHYFT की ओर से जवाब था: “Thank you! we’re actively looking into this and working on a solution”
  • अब भी कुछ बातें पुष्टि से बाहर हैं
    • डेटाबेस का स्वामित्व और प्रबंधन सीधे ESHYFT के पास था या किसी थर्ड-पार्टी कॉन्ट्रैक्टर के पास
    • शोधकर्ता के इसे खोजने से पहले यह कितने समय तक खुला रहा
    • क्या किसी और ने इसे एक्सेस किया
  • अतिरिक्त पहुंच या संदिग्ध गतिविधि की पहचान केवल आंतरिक forensic audit से ही की जा सकती है

जैसे-जैसे हेल्थकेयर स्टाफिंग प्लेटफ़ॉर्म बढ़ते हैं, सुरक्षा का बोझ भी बढ़ता है

  • ESHYFT का कहना है कि यह नर्सों को अपने शेड्यूल के अनुरूप शिफ्ट चुनने देता है और हेल्थकेयर सुविधाओं को सत्यापित W-2 नर्सिंग स्टाफ तक पहुंच देता है
  • यह प्लेटफ़ॉर्म अमेरिका के 29 राज्यों में उपलब्ध है
    • AL, AZ, AR, CA, CT, DE, FL, GA, IL, IN, IA, KS, KY, MD, MI, MN, MO, NE, NJ, OH, PA, RI, SC, TN, VT, VA, WA, WI, WV
  • Health Resources & Services Administration(NCHWA) रिपोर्ट का अनुमान है कि 2027 तक पूरे अमेरिका में registered nurses की कमी 10% तक पहुंच सकती है
  • हेल्थकेयर स्टाफ की मांग बढ़ने के साथ ESHYFT जैसे प्लेटफ़ॉर्म स्टाफ की कमी को भरने में भूमिका निभाते हैं
  • जब ऑफ़लाइन काम करने वाला नर्सिंग स्टाफ भी ऑनलाइन तकनीक के साथ एकीकृत हो रहा है, तब HealthTech कंपनियों के लिए अधिक मजबूत प्राइवेसी सुरक्षा आवश्यक हो जाती है
  • अस्पताल और हेल्थकेयर वर्कर्स जितना अधिक डेटा स्टोरेज, क्लिनिकल मैनेजमेंट और भर्ती के लिए तकनीक पर निर्भर होंगे, पूरे उद्योग पर साइबरसिक्योरिटी का दबाव उतना ही बढ़ेगा
  • अस्पतालों को महत्वपूर्ण इन्फ्रास्ट्रक्चर माना जाता है, और हाल के वर्षों में कई नेटवर्क गंभीर ransomware हमलों का शिकार हुए हैं

संभावित जोखिम और जरूरी सुरक्षा उपाय

  • अगर नर्सिंग प्रोफेशनल्स की व्यक्तिगत पहचान योग्य जानकारी, वेतन संबंधी जानकारी और कार्य इतिहास उजागर हो जाए, तो इससे व्यक्तियों और उन्हें रोजगार देने वाली हेल्थकेयर सुविधाओं दोनों के लिए जोखिम पैदा हो सकता है
  • ड्राइविंग लाइसेंस या Social Security कार्ड जैसे पहचान दस्तावेज़ों की स्कैन कॉपी यदि पते और संपर्क जानकारी के साथ जुड़ जाए, तो उनका पहचान की चोरी या वित्तीय धोखाधड़ी में दुरुपयोग हो सकता है
  • व्यक्तिगत और पेशेवर जानकारी का खुलासा वास्तविक डेटा का उपयोग करने वाले targeted phishing हमलों में बदल सकता है
    • इससे पीड़ितों को जॉब स्कैम के जरिए फंसाया जा सकता है या उनसे अतिरिक्त व्यक्तिगत और वित्तीय जानकारी खुलवाई जा सकती है
    • हालांकि, इसका यह अर्थ नहीं है कि ESHYFT डेटा या यूज़र डेटा का वास्तव में धोखाधड़ी या दुरुपयोग में इस्तेमाल हुआ है
  • HealthTech कंपनियों और हेल्थकेयर सॉफ़्टवेयर प्रदाताओं को निम्नलिखित उपायों पर विचार करना चाहिए
    • संवेदनशील डेटा के लिए अनिवार्य एन्क्रिप्शन प्रोटोकॉल
    • आंतरिक इन्फ्रास्ट्रक्चर की कमजोरियों की पहचान के लिए नियमित सुरक्षा ऑडिट
    • संवेदनशील डेटा स्टोरेज को सीमित करना और जहां संभव हो अनामीकरण
    • जो डेटा अब उपयोग में नहीं है उसके लिए expiry date तय करना
    • दस्तावेज़ की संवेदनशीलता के अनुसार अलग स्टोरेज
  • इस मामले में ऐसा लगता है कि यूज़र फ़ाइलें संवेदनशीलता के आधार पर अलग किए बिना एक ही फ़ोल्डर में अपलोड की गई थीं
    • यूज़र प्रोफ़ाइल इमेज अपेक्षाकृत कम संवेदनशील हो सकती है
    • मेडिकल टेस्ट प्रमाण अपेक्षाकृत अधिक संवेदनशील हो सकता है
    • सिद्धांततः इन दोनों दस्तावेज़ प्रकारों को एक ही फ़ोल्डर में स्टोर नहीं किया जाना चाहिए
  • संवेदनशील डेटा का पृथक्करण और एन्क्रिप्शन आकस्मिक एक्सपोज़र या दुर्भावनापूर्ण हमले की स्थिति में अतिरिक्त सुरक्षा परत प्रदान करता है
  • जिन एप्लिकेशनों में संवेदनशील डेटा या दस्तावेज़ों तक पहुंच संभव हो, उनमें MFA होना चाहिए
    • इससे username और password जैसे credentials उजागर होने पर भी एप्लिकेशन या यूज़र डैशबोर्ड तक तुरंत पहुंचना कठिन हो जाता है
  • HealthTech कंपनियों के पास डेटा breach response योजना और संभावित सुरक्षा घटनाओं की रिपोर्टिंग के लिए समर्पित कम्युनिकेशन चैनल होने चाहिए
    • केवल customer support या sales contact होने पर डेटा breach की स्थिति में जरूरी जिम्मेदार व्यक्तियों तक सूचना पहुंचने में देरी हो सकती है
    • जब संवेदनशील डेटा सार्वजनिक रूप से उजागर हो, तब mitigation और recovery में देरी गंभीर साबित हो सकती है
  • डेटा घटना के बाद सीधे प्रभावित हो सकने वाले यूज़र्स को समय पर जिम्मेदार disclosure सूचना दी जानी चाहिए
  • यूज़र्स को यह भी बताया जाना चाहिए कि उस एप्लिकेशन या सेवा से जुड़े phishing प्रयासों को कैसे पहचाना जाए
  • इसका यह अर्थ नहीं है कि Shiftster LLC dba ESHYFT, उसके कॉन्ट्रैक्टर्स या सहयोगी संस्थाओं की ओर से कोई अवैध कार्य हुआ था, और न ही यह दावा है कि आंतरिक डेटा या यूज़र डेटा तत्काल खतरे में था

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

1 टिप्पणियां

 
GN⁺ 2025-03-14
Hacker News की राय

  • हाल ही में मैंने सुना कि यह कंपनी काम ऑफ़र करने से पहले credit report देखकर यह आँकती है कि किसी पर कितना कर्ज़ है, यानी वह कितना मजबूर है, और फिर उसी जानकारी का इस्तेमाल करके ऑफ़र की जाने वाली hourly rate को नीचे समायोजित करती है
    अगर इस लीक से इन्हें कोई नुकसान होता है, तो उससे भी ज़्यादा मिलना चाहिए लगता है

    • स्रोत याद नहीं, लेकिन मैंने “नर्सों के लिए Uber” जैसी सेवाओं पर एक पॉडकास्ट सुना था, और उसमें कहा गया था कि वे नर्सों के ख़िलाफ़ हर तरह के हथकंडे अपनाते हैं
      शिफ्ट स्वीकार करते ही location tracking app चालू रखना पड़ता है, और traffic jam में फँसने या फ़ोन सिग्नल कटने पर भी penalty points जुड़ते हैं, जो आगे चलकर वेतन घटने का कारण बनते हैं
      यह पहले से ही बुरी नर्सिंग परिस्थितियों—बहुत ज़्यादा मरीज़, कम support staff, और 12 घंटे की ड्यूटी के बाद भी documentation—को हथियार बना देने जैसा है। मेरी पत्नी नर्स है, इसलिए यह और भी वास्तविक लगता है
    • नर्सों के वेतन को दबाने पर प्रस्तुति यहाँ है: https://pluralistic.net/2025/02/26/ursula-franklin/
    • नर्सों की इतनी भारी कमी है, फिर भी नर्सें ऐसी सेवाओं का इस्तेमाल क्यों करती हैं, यह जानने की उत्सुकता है
      ख़ासकर अनुभवी नर्सों को तो ऐसा घटिया app इस्तेमाल करने की ज़रूरत नहीं होनी चाहिए जो उनका वेतन काटे, और वे लगभग किसी भी medical facility में तुरंत नौकरी पा सकती होंगी; RN होने पर telemedicine के विकल्प भी काफ़ी लगते हैं
    • नर्सों की wage estimate करने का यह बहुत ही ख़राब तरीका लगता है
      उनका spouse हो सकता है, माता-पिता उनका credit card bill भरते हों, खराब credit वाले को इसकी परवाह ही न हो, या परिवार के पास पैसा हो सकता है
      कम कर्ज़ होने पर भी नौकरी की सख़्त ज़रूरत हो सकती है, इसलिए संदेह है कि यह व्यवहार में सच में काम भी करता होगा

  • privacy policy के Data Security सेक्शन में लिखा है कि वे एकत्र और संग्रहीत जानकारी की integrity और security बढ़ाने के लिए physical, administrative, और technical safeguards का उपयोग करते हैं, लेकिन कोई security पूरी तरह flawless या impenetrable नहीं होती, और वे breach, access, disclosure, alteration, या destruction को रोकने की गारंटी नहीं देते
    ख़ास तौर पर यह सेवा यह भी कहती है कि इसे HIPAA के तहत protected health information को store या protect करने के लिए design नहीं किया गया है; लेकिन “हमने इसे HIPAA-compliant system बनाया ही नहीं, इसलिए माफ़ कीजिए” कह देने से ज़िम्मेदारी खत्म हो सकती है या नहीं, पता नहीं
    0: https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...

    • HIPAA healthcare provider data पर नहीं, patient data पर लागू होता है
      लेख के मुताबिक नर्सों ने absenteeism या sick leave के कारण साबित करने के लिए diagnosis, prescription, और treatment information वाले medical documents app पर अपलोड किए थे, और यह protected health information हो सकती है
      यह कंपनी HIPAA के दायरे में आती है या नहीं, यह इस पर निर्भर करता है कि यह covered entity है या business associate; privacy policy देखकर लगता है कि इसने शायद Business Associate Agreement नहीं किया होगा
      जोड़कर कहें तो HIPAA खुद भी security standard के रूप में आदर्श नहीं है; बड़ी कंपनियाँ Gmail को HIPAA-compliant मानकर उसमें बड़ी मात्रा में protected health information का आदान-प्रदान भी कर लेती हैं
      0: https://www.hhs.gov/hipaa/for-professionals/covered-entities...
    • HIPAA सिर्फ़ कुछ ख़ास इकाइयों, यानी covered entity, पर लागू होता है
      मोटे तौर पर insurance लेने वाले healthcare providers या insurers इस दायरे में आते हैं, जबकि insurance न लेने वाले healthcare providers को HIPAA मानना ज़रूरी नहीं
      यहाँ ESHYFT सिर्फ़ labor उपलब्ध कराने वाली कंपनी लगती है, इसलिए इसका HIPAA से सीधा संबंध नहीं दिखता; यह staffing augmentation services देने वाली किसी बड़ी consulting firm से बहुत अलग नहीं है
    • HIPAA किसी घटिया terms of service से तय नहीं होता; या तो लागू होता है या नहीं
      बस इसका दायरा उम्मीद से संकरा है और सज़ा भी कमज़ोर। अगर Facebook tracking pixel जैसी चीज़ लगवाकर निजी medical data खींच ले जाए, तो भी शायद यह कानून का उल्लंघन न माना जाए, और दावा शायद उसी पक्ष के ख़िलाफ़ किया जा सके जिसने leak होने दिया
      इस मामले में भी HIPAA के ज़रिए नुकसान सीमित करना आसान नहीं लगता। यह उस स्थिति के ज़्यादा करीब है जहाँ किसी डॉक्टर ने patient data Google Drive पर डाल दिया हो और वह Google के subcontractor या hacking से बाहर निकल गया हो
      ESHYFT सेवा को HIPAA-सुरक्षित data की न ज़रूरत है, न उससे कोई मदद मिलती है, इसलिए HIPAA violation के आधार पर आसानी से जीतना मुश्किल लगता है; हालाँकि दूसरी damages liability अब भी संभव है
    • अगर यह सीधे healthcare provider नहीं है, तो इस तरह की liability disclaimer वाली दलील चल सकती है। इसका मतलब यह नहीं कि मैं उसका समर्थन करता हूँ

  • healthcare workers के पास जो authority होती है, उससे भ्रम हो सकता है, लेकिन डॉक्टर या अस्पताल को Social Security Number कभी नहीं देना बेहतर है
    उन्हें इसकी ज़रूरत नहीं होती। identity verification का मतलब scan या photo लेना भी नहीं होता
    डॉक्टर, अस्पताल, और clinic information security के मामले में सबसे बदतर समूहों में आते हैं, training भी लगभग नहीं होती, गलती पर सज़ा भी हल्की होती है, और ऐसी जानकारी का इस्तेमाल आख़िरकार अक्सर bill न चुकाने पर पीछा करने के लिए होता है

    • अमेरिका में HIPAA व्यवहार में शायद सबसे मज़बूत privacy law framework है, इसलिए healthcare providers जितना data leak होने पर भारी सज़ा पाने वाला कोई और समूह कम ही दिखता है
    • अगर वे कहें कि Social Security Number के बिना appointment ही नहीं देंगे, तो क्या करना चाहिए, यह जानना चाहता हूँ

  • सोच रहा हूँ यह S3 bucket कितनी पुरानी थी। AWS ने एक समय के बाद नई S3 buckets को default private बनाना शुरू कर दिया था
    अगर ऐसा है, तो या तो यह बहुत पुराना bucket था, या फिर mobile app/सेवा में file upload/download काम नहीं कर रहा था और उन्होंने लापरवाही से इसे public खोल दिया

    • हो सकता है किसी web developer ने वेबसाइट पर assets इस्तेमाल करने के लिए इसे खोल दिया हो, और उसी bucket में मौजूद दूसरे sensitive data के बारे में सोचा ही न हो

  • समझ नहीं आता कि शीर्षक में असली कंपनी का नाम लिखने के बजाय “नर्सों के लिए Uber” क्यों लिखा गया

    • लेख के अनुसार नाम ESHYFT है। यह AliExpress पर दिखने वाले किसी electronics brand जैसा लगता है, बस quality उससे भी ख़राब लगती है
    • सिर्फ़ कंपनी का नाम सुनकर जो बात समझ नहीं आती, वह यह है कि यह कंपनी कितनी घटिया है, और यह वाक्य उसे तुरंत साफ़ कर देता है

  • पिछले हफ़्ते Firebase को दोष दिया, तो अब लगता है AWS को दोष देंगे
    जब रात 3 बजे दोस्तों को दिखाने के लिए जल्दी-जल्दी कुछ बनाया जाता है, उस समय की security प्रक्रिया को व्यक्तिगत पहचान योग्य जानकारी host करने वाले product पर ज्यों का त्यों लागू नहीं किया जाना चाहिए। बुनियादी data security operator को खुद implement करनी चाहिए

    • बुनियादी data security implement करना सही है, लेकिन platform को भी जहाँ तक संभव हो मदद करनी चाहिए
      developer अगर सिर्फ default settings का पालन करे, तब भी उसे सुरक्षित सफलता के जाल में फँसना चाहिए
      इस मामले में S3 bucket को default रूप से private और encrypted होना चाहिए, और developer को उसे स्पष्ट रूप से बंद करना पड़े, ऐसी संरचना होनी चाहिए। अभी शायद ऐसा हो सकता है, लेकिन पहले ऐसा नहीं था

  • healthcare industry शुरू से अंत तक टूटी हुई है, और उसके आसपास की tech कंपनियाँ भी अयोग्य लगती हैं
    सस्ते corporate-owned hospital नर्सों को W2 employee के रूप में hire नहीं करना चाहते, इसलिए nursing का Uberकरण हो रहा है, और hospital की कंजूसी ने शायद ऐसे घटिया app के चयन तक बात पहुँचा दी
    हो सकता है approval देने वाले manager को rebate मिला हो, और ESHYFT को इस वजह से दिवालिया हो जाना चाहिए, लेकिन असल में शायद कुछ भी नहीं होगा

    • सिर्फ दिवालियापन काफ़ी नहीं है, आपराधिक लापरवाही भी तय होनी चाहिए
      जब तक executives जेल नहीं जाएँगे, यह चलता रहेगा। बहुत संभव है कि किसी ने information security में निवेश न करके इस business से बहुत पैसा कमाया हो
      लागत बचाने की कीमत उन लोगों ने चुकाई जिनका मुनाफ़े से कोई लेना-देना नहीं था, और कुछ साल बाद वही executives शायद सफल company बनाने पर lecture देते फिरें
      अगर ऐसे व्यवहार का कोई नतीजा नहीं होगा, तो public निजी मुनाफ़े की कीमत चुकाता रहेगा
    • ऐसे app कुछ हद तक स्वतंत्र hospital और healthcare provider को टिके रहने में मदद करते हैं
      बड़े healthcare system के पास अपना float nurse pool या internal bid system होता है
      छुट्टी और vacancy से निपटने की व्यवस्था तक पहुँच होना भी बड़े system को बेचते समय एक persuasive point होता है
    • rebate वाली बात खास तौर पर दिलचस्प है। उस संभावना से सहमति है, लेकिन व्यवहारिक रूप से इसे कैसे जड़ से खत्म किया जा सकता है, समझ नहीं आता
      जो लोग गड़बड़ी जानते हैं, वही लोग उससे फ़ायदा भी उठा रहे होते हैं, इसलिए उसे ठीक करने की प्रेरणा लगभग नहीं होती

  • लगता है लोग अब भी ऐसा दिखावा कर रहे हैं कि इस तरह की चीज़ों पर कार्रवाई करने में सक्षम कोई कार्यशील regulator अभी मौजूद है

    • इस तरह की चीज़ें ढूँढ़ने के लिए सबसे मेहनत करने वाले व्यक्ति को तुरंत निकाल दिया जाता है, तो सरकार ज़रूर ज़्यादा efficient हो जाती है

  • समझ नहीं आता यह बार-बार क्यों होता रहता है। लगता है हर महीने किसी खुले S3 bucket से नया breach निकल आता है

    • कारण हो सकते हैं: अपरिपक्व system वाली startup कंपनियाँ, पुरानी कंपनी में युवा developer का अपने दायरे में अलग से किया गया side work, और खराब default settings
      उससे भी ज़्यादा महत्वपूर्ण यह है कि बड़े पैमाने पर लगातार scan करने की प्रेरणा रखने वाले लोग बहुत हैं। आजकल GitHub, IP, domain आदि के ज़रिए internet खंगालना बहुत आसान है, और “गलत S3 setting” detect करना भी ऐसे script के स्तर की बात है जिसे कोई भी इस्तेमाल कर सकता है, इसके लिए advanced programming skill की ज़रूरत नहीं है
    • S3 और AWS का ज़्यादातर हिस्सा इतना खराब design किया गया है कि नया project शुरू करते समय लोग ऐसा access policy खोजकर उठा लेते हैं जो चलती हुई लगती है
      बाद में वही policy production environment के लिए ठीक न बैठे। इसका मतलब यह नहीं कि वह सही है, बल्कि यह कि वास्तव में चीज़ें ऐसे ही होती हैं

  • अगर infrastructure बनाने वाला व्यक्ति बहुत थका हुआ होकर यह सब setup कर गया हो और सुबह उठकर यह मामला देखा हो, तो वह सच में दुखद होगा