เหตุการณ์ ‘Uber สำหรับพยาบาล’ ESHYFT: เวชระเบียนและ PII กว่า 86,000 รายการรั่วไหลผ่านบัคเก็ต S3 สาธารณะ
(websiteplanet.com)- ฐานข้อมูลสาธารณะที่เกี่ยวข้องกับบริษัท HealthTech ในรัฐนิวเจอร์ซีย์ ESHYFT เปิดเผยระเบียน 86,341 รายการและข้อมูล 108.8GB โดยแพลตฟอร์มนี้เชื่อมต่อสถานพยาบาลกับบุคลากรพยาบาลใน 29 รัฐ
- ข้อมูลที่รั่วไหลประกอบด้วย โปรไฟล์·ภาพใบหน้า, ไฟล์ CSV ตารางเวรรายเดือน, ใบรับรองวิชาชีพ, สัญญามอบหมายงาน, CV และเรซูเม่ รวมถึง PII เพิ่มเติม
- ไฟล์บางส่วนดูเหมือนเป็น เอกสารทางการแพทย์ ที่อัปโหลดเข้าแอปเพื่อเป็นหลักฐานเหตุผลของการขาดงานหรือลาป่วย และมีข้อมูลการวินิจฉัย ใบสั่งยา และการรักษา ซึ่งอาจเข้าข่ายอยู่ภายใต้ข้อกำกับ HIPAA
- หลังจากนักวิจัยแจ้งการเปิดเผยอย่างรับผิดชอบ การเข้าถึงฐานข้อมูลถูกจำกัดลงหลังผ่านไปกว่าหนึ่งเดือน แต่ยังยืนยันไม่ได้ว่าใครเป็นผู้ดูแล ระยะเวลาที่เปิดเผย และมีบุคคลที่สามเข้าถึงหรือไม่
- แพลตฟอร์มบุคลากรทางการแพทย์ควรมี การเข้ารหัส ข้อมูลอ่อนไหว, การตรวจสอบความปลอดภัยเป็นประจำ, การเก็บรักษาให้น้อยที่สุดและการทำให้ไม่ระบุตัวตน, การแยกจัดเก็บตามระดับความอ่อนไหว, MFA, แผนรับมือเหตุละเมิดข้อมูล และช่องทางรายงาน
การรั่วไหลที่พบในฐานข้อมูลสาธารณะของ ESHYFT
- Jeremiah Fowler นักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์พบฐานข้อมูลที่ไม่มีการป้องกันด้วยรหัสผ่านหรือการเข้ารหัส และแชร์ข้อมูลกับ Website Planet
- ฐานข้อมูลมีระเบียน 86,341 รายการที่ดูเหมือนเป็นของ ESHYFT และมีขนาดรวม 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 ทันที
- ฐานข้อมูลถูกจำกัดการเข้าถึงสาธารณะหลังผ่านไปกว่าหนึ่งเดือน
- คำตอบจาก ESHYFT คือ “Thank you! we’re actively looking into this and working on a solution”
- ยังมีประเด็นที่ยังยืนยันไม่ได้
- ฐานข้อมูลเป็นของ ESHYFT และบริหารจัดการโดยตรง หรือบริหารโดยผู้รับเหมาบุคคลที่สาม
- เปิดเผยอยู่นานเท่าใดก่อนที่นักวิจัยจะพบ
- มีผู้อื่นเข้าถึงหรือไม่
- การเข้าถึงเพิ่มเติมหรือกิจกรรมน่าสงสัยจะระบุได้ผ่าน การตรวจสอบทางนิติวิทยาศาสตร์ดิจิทัล ภายในเท่านั้น
ยิ่งแพลตฟอร์มบุคลากรทางการแพทย์เติบโต ภาระด้านความปลอดภัยยิ่งเพิ่มขึ้น
- 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) คาดการณ์ว่าอัตราขาดแคลนพยาบาลวิชาชีพทั่วสหรัฐฯ จะสูงถึง 10% ภายในปี 2027
- เมื่อความต้องการบุคลากรทางการแพทย์เพิ่มขึ้น แพลตฟอร์มอย่าง ESHYFT จึงมีบทบาทในการช่วยเติมช่องว่างด้านกำลังคน
- เมื่อบุคลากรพยาบาลที่ทำงานออฟไลน์ถูกรวมเข้ากับเทคโนโลยีออนไลน์ บริษัท HealthTech ก็จำเป็นต้องมีมาตรการคุ้มครองข้อมูลส่วนบุคคลที่แข็งแกร่งขึ้น
- ยิ่งโรงพยาบาลและบุคลากรทางการแพทย์พึ่งพาเทคโนโลยีมากขึ้นสำหรับการจัดเก็บข้อมูล การจัดการการรักษา และการจ้างงาน ภาระด้านความมั่นคงปลอดภัยไซเบอร์ของทั้งอุตสาหกรรมก็ยิ่งเพิ่มขึ้น
- โรงพยาบาลถือเป็นโครงสร้างพื้นฐานสำคัญ และในช่วงไม่กี่ปีที่ผ่านมา หลายเครือข่ายถูกโจมตีด้วย ransomware อย่างรุนแรง
ความเสี่ยงที่อาจเกิดขึ้นและมาตรการความปลอดภัยที่จำเป็น
- หากข้อมูลส่วนบุคคลที่ระบุตัวตนได้ของบุคลากรพยาบาลมืออาชีพ ข้อมูลเงินเดือน และประวัติการทำงานรั่วไหล อาจก่อความเสี่ยงต่อทั้งตัวบุคคลและสถานพยาบาลที่จ้างงาน
- หากสำเนาสแกนเอกสารยืนยันตัวตน เช่น ใบขับขี่หรือบัตร Social Security ถูกนำไปรวมกับที่อยู่และข้อมูลติดต่อ อาจถูกใช้ในทางที่ผิดเพื่อ ขโมยตัวตน หรือฉ้อโกงทางการเงิน
- การรั่วไหลของข้อมูลส่วนตัวและวิชาชีพอาจนำไปสู่ ฟิชชิงแบบเจาะจงเป้าหมาย ที่ใช้ข้อมูลจริง
- อาจหลอกเหยื่อด้วยการฉ้อโกงด้านการจ้างงาน หรือทำให้เปิดเผยข้อมูลส่วนตัวและการเงินเพิ่มเติม
- อย่างไรก็ตาม ไม่ได้หมายความว่าข้อมูลของ ESHYFT หรือข้อมูลผู้ใช้ถูกนำไปใช้ในทางที่ผิดเพื่อการหลอกลวงหรือการกระทำทุจริตจริง
- บริษัท HealthTech และผู้ให้บริการซอฟต์แวร์ทางการแพทย์ควรพิจารณามาตรการต่อไปนี้
- โปรโตคอลการเข้ารหัสที่บังคับใช้กับข้อมูลอ่อนไหว
- การตรวจสอบความปลอดภัยเป็นประจำเพื่อระบุช่องโหว่ในโครงสร้างพื้นฐานภายใน
- จำกัดการจัดเก็บข้อมูลอ่อนไหว และทำให้ไม่ระบุตัวตนเมื่อเป็นไปได้
- กำหนดวันหมดอายุให้กับข้อมูลที่ไม่ได้ใช้งานอีกต่อไป
- แยกจัดเก็บตามระดับความอ่อนไหวของเอกสาร
- ในกรณีนี้ ดูเหมือนไฟล์ผู้ใช้ถูกอัปโหลดไว้ในโฟลเดอร์เดียวโดยไม่ได้แยกตามระดับความอ่อนไหว
- ภาพโปรไฟล์ผู้ใช้อาจมีความอ่อนไหวต่ำ
- หลักฐานการตรวจทางการแพทย์อาจมีความอ่อนไหวสูง
- ตามหลักแล้ว เอกสารทั้งสองประเภทไม่ควรถูกจัดเก็บในโฟลเดอร์เดียวกัน
- การแยกข้อมูลอ่อนไหวและการเข้ารหัสช่วยเพิ่มชั้นการป้องกันเมื่อเกิดการเปิดเผยโดยไม่ตั้งใจหรือการโจมตีที่เป็นอันตราย
- แอปพลิเคชันที่เข้าถึงข้อมูลหรือเอกสารอ่อนไหวได้จำเป็นต้องมี MFA
- ทำให้เข้าถึงแอปพลิเคชันหรือแดชบอร์ดผู้ใช้ได้ยากขึ้นทันที แม้ข้อมูลประจำตัวอย่างชื่อผู้ใช้และรหัสผ่านจะรั่วไหล
- บริษัท HealthTech ควรมีแผนรับมือเหตุละเมิดข้อมูลและช่องทางสื่อสารเฉพาะสำหรับรายงานเหตุการณ์ด้านความปลอดภัยที่อาจเกิดขึ้น
- หากมีเพียงช่องทางฝ่ายสนับสนุนลูกค้าหรือฝ่ายขาย อาจทำให้การส่งต่อไปยังผู้รับผิดชอบหลักที่ต้องดำเนินการเมื่อเกิดเหตุละเมิดข้อมูลล่าช้า
- เมื่อข้อมูลอ่อนไหวถูกเปิดเผยต่อสาธารณะ ความล่าช้าในการบรรเทาและกู้คืนอาจร้ายแรง
- หลังเหตุการณ์ด้านข้อมูล ควรมีการแจ้งเปิดเผยอย่างรับผิดชอบต่อผู้ใช้ที่อาจได้รับผลกระทบโดยตรงอย่างทันท่วงที
- ผู้ใช้ควรได้รับคำแนะนำเกี่ยวกับวิธีสังเกตความพยายามฟิชชิงที่เกี่ยวข้องกับแอปพลิเคชันหรือบริการดังกล่าว
- ไม่ได้หมายความว่า Shiftster LLC dba ESHYFT, ผู้รับเหมา หรือบริษัทในเครือมีการกระทำผิดกฎหมาย และไม่ได้อ้างว่าข้อมูลภายในหรือข้อมูลผู้ใช้อยู่ในความเสี่ยงที่ใกล้จะเกิดขึ้น
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
เมื่อไม่นานมานี้ได้ยินมาว่าบริษัทนี้ ก่อนจะเสนอ งาน จะดูจาก รายงานเครดิต ว่าคนคนนั้นมีหนี้มากแค่ไหน หรือพูดอีกอย่างคือจนตรอกแค่ไหน แล้วใช้ข้อมูลนั้นเพื่อ ปรับลด ค่าจ้างรายชั่วโมงที่เสนอ
ถ้าการรั่วไหลครั้งนี้ทำให้เกิดผลเสียอะไรขึ้นมา ก็ดูเหมือนว่าพวกเขาสมควรโดนมากกว่านั้นด้วยซ้ำ
เมื่อถูกเรียกงาน ต้องเปิดแอปติดตามตำแหน่ง และแม้จะเจอรถติดหรือสัญญาณมือถือขาดหายก็จะสะสมคะแนนโทษ ซึ่งคะแนนโทษจะนำไปสู่การลดค่าจ้าง
เรียกได้ว่าเป็นการ นำมาใช้เป็นอาวุธ กับสภาพแวดล้อมการพยาบาลที่แย่อยู่แล้ว ทั้งคนไข้มากเกินไป บุคลากรสนับสนุนไม่พอ และหลังทำงาน 12 ชั่วโมงก็ยังต้องทำบันทึก ภรรยาผมเป็นพยาบาลเลยรู้สึกว่ามันสมจริงยิ่งขึ้น
โดยเฉพาะถ้าเป็นพยาบาลที่มีทักษะ ก็ไม่มีเหตุผลจะใช้แอปแย่ ๆ ที่กดค่าจ้าง และควรจะได้งานแทบจะทันทีในสถานพยาบาลไหนก็ได้ อีกทั้งถ้าเป็น RN ก็ดูเหมือนจะมีตัวเลือกงานแพทย์ทางไกลมากมาย
คนคนนั้นอาจมีคู่สมรส พ่อแม่อาจช่วยจ่ายบัตรเครดิต คนเครดิตไม่ดีอาจไม่ได้สนใจมากนัก หรืออาจมีเงินจากครอบครัวก็ได้
ต่อให้หนี้น้อยก็อาจจำเป็นต้องมีงานอย่างมากได้ เลยสงสัยว่าวิธีนี้ใช้ได้จริงหรือเปล่า
ในส่วน Data Security ของนโยบายความเป็นส่วนตัว ระบุว่าใช้มาตรการคุ้มครองทางกายภาพ การบริหารจัดการ และทางเทคนิค เพื่อเพิ่มความสมบูรณ์และความปลอดภัยของข้อมูลที่รวบรวมและจัดเก็บ แต่ไม่มีความปลอดภัยใดที่สมบูรณ์แบบหรือเจาะไม่ได้ และไม่รับประกันว่าจะไม่มีการรั่วไหล การเข้าถึง การเปิดเผย การแก้ไข หรือการทำลาย
โดยเฉพาะบริการนี้ระบุว่าไม่ได้ออกแบบมาเพื่อจัดเก็บหรือปกป้องข้อมูลสุขภาพที่ได้รับการคุ้มครองตาม HIPAA แต่ก็ไม่รู้ว่าคำว่า “ขอโทษนะ เราไม่ได้ทำให้เป็นระบบที่สอดคล้องกับ HIPAA” จะทำให้พ้นความรับผิดได้หรือไม่
0: https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...
ในบทความดูเหมือนว่าพยาบาลอัปโหลดเอกสารทางการแพทย์ที่มีข้อมูลการวินิจฉัย ใบสั่งยา และการรักษาเข้าแอป เพื่อพิสูจน์เหตุผลของการขาดงานหรือลาป่วย และระบุว่าสิ่งนี้อาจเข้าข่ายข้อมูลสุขภาพที่ได้รับการคุ้มครอง
บริษัทนี้จะอยู่ภายใต้ HIPAA หรือไม่ขึ้นอยู่กับว่าเป็น covered entity หรือ business associate หรือไม่ และดูจากนโยบายความเป็นส่วนตัวแล้ว ดูไม่น่าจะมีการทำ Business Associate Agreement
เพิ่มเติมคือ HIPAA เองก็ไม่ใช่มาตรฐานความปลอดภัยที่เหมาะสมที่สุด บริษัทใหญ่ ๆ จึงส่งข้อมูลสุขภาพที่ได้รับการคุ้มครองจำนวนมากผ่าน Gmail กัน เพียงเพราะ Gmail สอดคล้องกับ HIPAA
0: https://www.hhs.gov/hipaa/for-professionals/covered-entities...
โดยคร่าว ๆ คือผู้ให้บริการทางการแพทย์หรือบริษัทประกันที่รับประกันภัย และผู้ให้บริการทางการแพทย์ที่ไม่รับประกันภัยก็ไม่จำเป็นต้องปฏิบัติตาม HIPAA
ในกรณีนี้ ESHYFT เป็นเพียงบริษัทที่จัดหาแรงงาน จึงดูไม่เกี่ยวข้องกับ HIPAA โดยตรง และไม่ได้ต่างจากบริษัทที่ปรึกษาขนาดใหญ่ที่ให้บริการเสริมกำลังคนมากนัก
อย่างไรก็ตาม ขอบเขตแคบกว่าที่คาด และบทลงโทษก็เบา การที่ Facebook ชวนให้ติดตั้งสิ่งอย่าง tracking pixel แล้วดูดข้อมูลการแพทย์ส่วนบุคคลออกไป ก็มีโอกาสสูงว่าไม่ผิดกฎหมาย และคงเรียกร้องได้แค่กับฝ่ายที่ทำให้เกิดการรั่วไหล
กรณีนี้ก็ดูไม่ง่ายที่จะใช้ HIPAA เพื่อจำกัดความเสียหาย คล้ายกับกรณีที่แพทย์อัปโหลดข้อมูลผู้ป่วยขึ้น Google Drive แล้วข้อมูลรั่วออกไปผ่านผู้รับเหมาช่วงของ Google หรือการแฮ็กมากกว่า
บริการของ ESHYFT ไม่ได้จำเป็นต้องใช้หรือได้ประโยชน์จากข้อมูลที่ HIPAA คุ้มครอง ดังนั้นคงยากที่จะชนะคดีแบบง่าย ๆ ในข้อหาละเมิด HIPAA แต่ความรับผิดชดใช้ค่าเสียหายด้านอื่น ๆ ยังเป็นไปได้
เพราะอำนาจความน่าเชื่อถือที่บุคลากรทางการแพทย์มี จึงทำให้สับสนได้ง่าย แต่最好คืออย่าให้ หมายเลขประกันสังคม กับแพทย์หรือโรงพยาบาลเด็ดขาด
พวกเขาไม่จำเป็นต้องใช้ การตรวจบัตรประจำตัวก็ไม่ได้หมายถึงการสแกนหรือถ่ายรูป
แพทย์ โรงพยาบาล และคลินิกจัดอยู่ในกลุ่มที่ความปลอดภัยข้อมูลแย่ที่สุด แทบไม่มีการอบรม ทำผิดก็มีโทษเบา และข้อมูลแบบนั้นสุดท้ายก็ใกล้เคียงกับการเอาไว้ตามตัวคุณเมื่อไม่จ่ายบิล
สงสัยว่า S3 bucket นี้เก่าแค่ไหน ตั้งแต่จุดหนึ่ง AWS ทำให้ S3 bucket ใหม่เป็นส่วนตัวโดยค่าเริ่มต้น
ถ้าอย่างนั้นก็มีความเป็นไปได้สูงว่าเป็น bucket เก่า หรือไม่ก็เปิดสาธารณะแบบไม่รอบคอบเพราะแอปมือถือ/บริการอัปโหลดหรือดาวน์โหลดไฟล์ไม่ได้
สงสัยว่าทำไมในหัวข้อถึงใช้คำว่า “Uber สำหรับพยาบาล” แทนชื่อบริษัทจริง
สัปดาห์ก่อนโทษ Firebase คราวนี้คงจะโทษ AWS กันหรือเปล่า
ขั้นตอนด้านความปลอดภัยแบบที่ใช้ตอนรีบทำอะไรลวก ๆ ตอนตี 3 เพื่อเอาไปโชว์เพื่อน ไม่ควรถูกนำมาใช้กับผลิตภัณฑ์ที่โฮสต์ ข้อมูลระบุตัวบุคคล แบบเดียวกัน ความปลอดภัยพื้นฐานของข้อมูลเป็นสิ่งที่ผู้ให้บริการต้องนำไปใช้งานเอง
ควรทำให้นักพัฒนา “ตกหลุมพรางแห่งความสำเร็จ” ที่ปลอดภัยได้แม้แค่ทำตามค่าเริ่มต้น
ในกรณีนี้ S3 bucket ควรเป็นแบบไม่เปิดสาธารณะและเข้ารหัสโดยปริยาย และต้องเป็นโครงสร้างที่นักพัฒนาต้องปิดมันอย่างชัดเจนเอง ตอนนี้อาจทำแบบนั้นได้แล้ว แต่ในอดีตไม่ใช่
อุตสาหกรรมการแพทย์พังตั้งแต่ต้นจนจบ และบริษัทเทคโนโลยีรอบ ๆ ก็พลอยดูไร้ความสามารถไปด้วย
โรงพยาบาลราคาถูกที่บริษัทเป็นเจ้าของไม่อยากจ้างพยาบาลเป็นพนักงาน W2 งานพยาบาลจึงถูกทำให้เป็นแบบ Uber และความตระหนี่ของโรงพยาบาลก็น่าจะนำไปสู่การเลือกใช้แอปห่วย ๆ แบบนี้
ผู้จัดการที่อนุมัติอาจได้รับเงินใต้โต๊ะก็ได้ และ ESHYFT สมควรล้มละลายเพราะเรื่องนี้ แต่ดูแล้วมีโอกาสมากกว่าที่จะไม่มีอะไรเกิดขึ้นจริง
ตราบใดที่ผู้บริหารไม่ติดคุก เรื่องแบบนี้ก็จะเกิดขึ้นต่อไป มีความเป็นไปได้สูงว่ามีใครบางคนหาเงินก้อนโตจากธุรกิจนี้โดยไม่ลงทุนด้านความปลอดภัยสารสนเทศ
คนที่จ่ายราคาจากการประหยัดต้นทุนนั้นกลับเป็นคนที่ไม่เกี่ยวกับกำไร และอีกไม่กี่ปีผู้บริหารเหล่านั้นอาจไปบรรยายวิธีสร้างบริษัทที่ประสบความสำเร็จก็ได้
ถ้าการกระทำแบบนี้ไม่มีผลตามมา สาธารณะก็จะต้องจ่ายราคาเพื่อผลประโยชน์ส่วนตัวต่อไป
ระบบการแพทย์ขนาดใหญ่มีพูลพยาบาล float ของตัวเอง หรือระบบเสนอเวรภายในอยู่แล้ว
การเข้าถึงระบบรับมือวันลาและตำแหน่งว่างยังเป็นจุดขายอย่างหนึ่งเวลาถูกโน้มน้าวให้ขายกิจการให้ระบบขนาดใหญ่ด้วย
คนที่รู้ว่ามีความผิดก็คือคนที่ได้รับผลประโยชน์นั้นเอง จึงแทบไม่มีแรงจูงใจให้แก้ไข
ยังจะแกล้งทำเป็นเชื่อว่ามี หน่วยงานกำกับดูแลที่ทำงานได้จริง ซึ่งสามารถดำเนินการกับเรื่องแบบนี้ได้อยู่อีกหรือ
ไม่เข้าใจว่าทำไมเรื่องแบบนี้ถึงเกิดซ้ำแล้วซ้ำเล่า รู้สึกเหมือนทุกเดือนจะมีการรั่วไหลใหม่จาก S3 bucket ที่เปิดไว้
ที่สำคัญกว่านั้นคือมีคนจำนวนมากที่มีแรงจูงใจสูงในการสแกนค้นหาอย่างต่อเนื่องในวงกว้าง ทุกวันนี้การกวาดดู GitHub, IP, โดเมน และอินเทอร์เน็ตทำได้ง่ายมาก และการตรวจหา “การตั้งค่า S3 ที่ผิดพลาด” ก็อยู่ในระดับสคริปต์ที่ใคร ๆ ก็ใช้ได้ ไม่ต้องมีทักษะการเขียนโปรแกรมขั้นสูง
นโยบายนั้นภายหลังอาจไม่เหมาะกับสภาพแวดล้อม production ก็ได้ ไม่ได้บอกว่านั่นถูกต้อง แต่หมายความว่าในความเป็นจริงเรื่องมันเกิดขึ้นแบบนั้น
ถ้าคนที่ทำอินฟราสร้างมันขึ้นมาตอนเหนื่อยเกินไป แล้วตื่นมาตอนเช้าเห็นเรื่องนี้ ก็น่าเห็นใจจริง ๆ