ประกาศด้านความปลอดภัยของ MongoDB

 (mongodb.com)
2 คะแนน โดย GN⁺ 2023-12-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MongoDB Alerts เป็นศูนย์รวมประกาศที่รวบรวม ประเด็นด้านความสมบูรณ์ของข้อมูล การปฏิบัติการ และความปลอดภัย CVE ไว้ในที่เดียว เพื่อให้ตรวจสอบขอบเขตผลกระทบตามเวอร์ชันและ deployment ของ MongoDB ที่ต้องดำเนินการตอบสนองได้
  • รายการด้านความสมบูรณ์ของข้อมูลในปี 2026 ครอบคลุมข้อผิดพลาดของ range query แบบเรียง _id จากมากไปน้อยใน clustered collection, การยอมให้ unique index ซ้ำใน sharded cluster, การตกหล่นของ Relational Migrator และการไม่บังคับใช้ read/write concern เมื่อเชื่อมต่อ shard โดยตรง
  • ในด้านการปฏิบัติการ จนถึงเดือนเมษายน 2026 CA สาธารณะรายใหญ่จะหยุดออก ใบรับรอง TLS ที่มี clientAuth EKU ซึ่งอาจส่งผลต่อการตั้งค่า mTLS และการยืนยันตัวตน X.509 ของ MongoDB แบบ self-managed
  • ส่วนความปลอดภัยให้ รายการ CVE แยกตามผลิตภัณฑ์ เช่น MongoDB Server, Compass, mongosh, driver และ Ops Manager ตั้งแต่ปี 2019 ถึง 2026
  • ผู้ปฏิบัติงานควรเทียบเวอร์ชัน Server, Atlas, Relational Migrator, Compass, mongosh และ driver ตามภาษาที่ใช้อยู่กับขอบเขตผลกระทบ แล้วอัปเกรดเป็นเวอร์ชันแพตช์หรือใช้การตั้งค่า workaround ตามที่ประกาศ

ขอบเขตที่หน้า MongoDB Alerts ครอบคลุม

  • MongoDB Alerts เป็นหน้าที่รวบรวม คำเตือนและคำแนะนำสำคัญ ของ MongoDB
  • รายการบั๊กและคำขอฟีเจอร์แบบครอบคลุมดูได้ที่ MongoDB JIRA
  • ประกาศใหม่มีให้ผ่าน RSS Feed ด้วย
  • หน้านี้แบ่งเป็นหมวดหมู่ดังต่อไปนี้
    • Data Integrity Related
    • Operations Related
    • Security Related: Common Vulnerabilities and Exposures (CVEs)
    • General

คำเตือนด้านความสมบูรณ์ของข้อมูลปี 2026

  • range query แบบเรียง _id จากมากไปน้อยใน clustered collection

    • ประกาศเมื่อ 17 มิถุนายน 2026
    • ใน clustered collection หากใช้การเรียงลำดับจากมากไปน้อยกับฟิลด์ _id และใช้เงื่อนไข range ในรูปแบบ {$lt: A}, {$gt: A}, {$gte: A, $lt: B}, {$gt: A, $lte: B} อาจทำให้ เอกสารตรงขอบเขตถูกใส่เข้ามาหรือถูกตัดออกอย่างไม่ถูกต้อง
    • time series collection, non-clustered collection, clustered collection ที่ไม่ได้ใช้การเรียง _id จากมากไปน้อย และการผสม comparison operator ที่เป็นชนิดรวม/ไม่รวมแบบเดียวกันไม่ได้รับผลกระทบ
    • เวอร์ชันที่ได้รับผลกระทบ:
      • MongoDB 8.0.0–8.0.23
      • 8.2.0–8.2.9
      • 8.3.0–8.3.2
    • SERVER-121822

  • การรับประกันไม่ให้ซ้ำของ unique index ใน sharded cluster

    • ประกาศเมื่อ 14 พฤษภาคม 2026
    • ใน sharded cluster หาก shard key เหมือนกับ index key pattern หรือเป็น strict prefix และ unique index ใช้ non-simple collation อาจ ไม่บังคับใช้ uniqueness ระหว่าง shard
    • ค่าที่ byte ต่างกันแต่เท่ากันตาม collation เช่น "YES" และ "yes" อาจถูกใส่แยกกันใน shard ต่างกันได้
    • เงื่อนไขของปัญหาคือมี shard ตั้งแต่สองตัวขึ้นไป, unique index ที่ใช้ non-simple collation และ shard key เหมือนกับ index key pattern หรือเป็น strict prefix
    • เวอร์ชันที่ได้รับผลกระทบ:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.20
      • 8.2.0–8.2.6
    • SERVER-85346

  • การย้ายข้อมูลของ Relational Migrator ตกหล่น

    • ประกาศเมื่อ 14 พฤษภาคม 2026
    • ผู้ใช้ที่ย้ายข้อมูลด้วย Relational Migrator อาจพบ เอกสารตกหล่น ในการทำ sharded cluster migration เมื่อมี embedded document หรือ embedded array
    • cyclic mapping ที่มี foreign key ที่ถูกยกเว้นอยู่ใต้ embedded array, คอลัมน์ของ source table ที่ใช้ในความสัมพันธ์ composite foreign key หลายรายการ และการเลือก field name ที่ชนกัน อาจทำให้เกิดฟิลด์ที่ตกหล่น ไม่ตรงกัน หรือตั้งชื่อผิด
    • ผลิตภัณฑ์ที่ได้รับผลกระทบคือ MongoDB Relational Migrator ก่อน 1.16.0
    • SERVER-126522

  • read/write concern ไม่ถูกบังคับใช้เมื่อเชื่อมต่อ shard โดยตรง

    • ประกาศเมื่อ 14 พฤษภาคม 2026
    • หากเชื่อมต่อโดยตรงไปยัง shard node โดยไม่ผ่าน mongos อาจไม่บังคับใช้ cluster-wide default read/write concern
    • ในกรณีนี้ write อาจทำงานด้วย {w: 1} แทน concern ที่ตั้งไว้ และหากเกิด rollback อาจสูญเสีย acknowledged write ได้
    • สำหรับ sharded cluster ควรเชื่อมต่อผ่าน mongos เท่านั้น
    • หากจำเป็นต้องเชื่อมต่อ shard โดยตรง ควรอัปเกรดเป็นเวอร์ชันแพตช์ทันที หรือระบุ read/write concern อย่างชัดเจนใน connection string เช่น {w: "majority"}
    • เวอร์ชันที่ได้รับผลกระทบ:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.19
      • 8.2.0–8.2.3
    • SERVER-111031

รูปแบบที่พบซ้ำในคำเตือนด้านความสมบูรณ์ของข้อมูลล่าสุด

  • sharding และ migration

    • รายการเดือนมีนาคม 2026 กล่าวถึงความเสี่ยงข้อมูลสูญหายระหว่าง chunk migration ใน sharded collection ที่มี compound wildcard index ซึ่งรวม shard key prefix
    • ในเดือนพฤศจิกายน 2025 มีการบันทึกปัญหาที่ cross-shard transaction อาจ commit บางส่วนภายใต้เงื่อนไข failover บางอย่าง
    • ในเดือนเมษายน 2024 มีปัญหาที่ sharded multi-document transaction อาจคืนข้อมูลผิดหรือทำ write ตกหล่น

  • time series collection

    • รายการเดือนพฤศจิกายน 2025 แจ้งว่า index key แบบ 2dsphere สำหรับ metric data ของ time series collection ไม่ถูกสร้างและแทรก ทำให้ geospatial query อาจคืนผลลัพธ์ไม่ครบถ้วน
    • รายการเดือนสิงหาคม 2025 กล่าวถึงปัญหาที่ pattern การป้อน metric แบบ double-precision บางแบบอาจทำให้ข้อมูลเสียหาย
    • รายการเดือนมกราคม 2025 ครอบคลุมความเป็นไปได้ที่ข้อมูลใน time series collection จะสูญหายจากการใช้ ordered: false concurrent insert ร่วมกับ retryable writes

  • ความถูกต้องของผลลัพธ์ query

    • ในเดือนมีนาคม 2026 มีการบันทึกปัญหาที่ aggregation query ซึ่งมี $group ถัดจาก $sort และใช้ accumulator $top หรือ $bottom อาจคืนผลลัพธ์ผิด
    • ในเดือนกุมภาพันธ์ 2026 SQL interface อาจคืนผลลัพธ์ผิดเมื่อหนึ่งในเงื่อนไข OR ของ clause WHERE เป็น UNKNOWN และอีกเงื่อนไขเป็น TRUE
    • ในเดือนมิถุนายน 2025 query ที่มี $elemMatch และ string predicate อาจใช้ index ที่ collation ไม่ตรงกัน จนทำให้เอกสารที่ควรถูกนำมารวมตกหล่น

คำเตือนเกี่ยวกับการปฏิบัติการ

  • การเปลี่ยนนโยบาย clientAuth EKU ของ CA สาธารณะ

    • ประกาศเมื่อ 22 มกราคม 2026
    • Certificate Authority สาธารณะรายใหญ่จะบังคับใช้ข้อกำหนดนโยบายที่หยุดออกใบรับรอง TLS ซึ่งมี client authentication(clientAuth) Extended Key Usage ภายในเดือนเมษายน 2026
    • การเปลี่ยนแปลงนี้กระทบเฉพาะ deployment ของ MongoDB แบบ self-managed ที่ใช้ใบรับรอง public CA สำหรับ mutual TLS(mTLS) หรือการยืนยันตัวตน X.509
    • ลูกค้า self-managed ต้องย้ายไปใช้ private PKI infrastructure หรือเปลี่ยนการตั้งค่า MongoDB ก่อนเส้นตายในเดือนเมษายน–พฤษภาคม 2026
    • ลูกค้า Atlas ไม่ได้รับผลกระทบ
    • ขอบเขตผลกระทบ:
      • X.509 Cluster Authentication
      • X.509 Client Authentication
      • mTLS ที่ใช้ใบรับรอง public CA จาก Google Trust Services, Let’s Encrypt, DigiCert, Sectigo
    • ประกาศที่เกี่ยวข้อง

  • mongosh และ autocomplete ของ Node.js REPL

    • ประกาศเมื่อ 30 กันยายน 2025
    • third-party distribution เช่น MongoDB Shell ที่ติดตั้งผ่าน Homebrew หรือ npm package manager อาจได้รับผลกระทบจากบั๊กของ Node.js REPL
    • ระหว่าง autocomplete อาจเกิด side effect ที่ไม่ได้ตั้งใจ
    • ขอบเขตผลกระทบคือ mongosh ก่อน 2.5.8 ที่ใช้ร่วมกับ Node.js 20.19.5–24.7.0
    • MONGOSH-2635

  • FIPS mode และ OpenSSL 3

    • ประกาศเมื่อ 11 กันยายน 2025
    • MongoDB ที่ตั้งค่า FIPS mode บน Linux และใช้ OpenSSL 3 สำหรับ cryptographic operation อาจใช้ cryptographic algorithm จาก non-FIPS provider
    • ในกรณีนี้ client อาจเชื่อมต่อ TLS ไปยัง MongoDB ใน FIPS mode ด้วย cryptographic algorithm ที่ไม่เป็นไปตาม FIPS ได้
    • เวอร์ชันที่ได้รับผลกระทบ:
      • 6.0.0–6.0.25
      • 7.0.0–7.0.22
      • 8.0.0–8.0.12
    • SERVER-109268

ประกาศความปลอดภัย CVE ปี 2026

  • ช่องโหว่ของ MongoDB Server

    • CVE-2026-11933 เมื่อ 12 มิถุนายน 2026 เป็นช่องโหว่ use-after-free หลังการยืนยันตัวตนใน server-side JavaScript BSON-to-array conversion และมีคะแนน 8.8
    • เวอร์ชันที่ได้รับผลกระทบคือ 8.3.3 และก่อนหน้า, 8.2.10 และก่อนหน้า, 8.0.25 และก่อนหน้า, 7.0.36 และก่อนหน้า, 6.0.28 และก่อนหน้า, 5.0.33 และก่อนหน้า, 4.4.30 และก่อนหน้า
    • SERVER-128125

  • denial of service ก่อนการยืนยันตัวตน

    • CVE-2026-9740 อาจทำให้เกิด stack overflow ก่อนการยืนยันตัวตนจาก unbounded recursion ของ BSONColumn interleaved-reference และมีคะแนน 8.7
    • เวอร์ชันที่ได้รับผลกระทบคือก่อน 8.3.3, ก่อน 8.2.10, ก่อน 8.0.24, ก่อน 7.0.35
    • SERVER-125063
    • CVE-2026-25611 เป็น denial of service แบบ memory exhaustion ก่อนการยืนยันตัวตน ซึ่งทำให้หน่วยความจำหมดได้ด้วย unauthenticated message และมีคะแนน 8.7
    • เวอร์ชันที่ได้รับผลกระทบคือก่อน 8.2.4, ก่อน 8.0.18, ก่อน 7.0.29
    • SERVER-116210

  • ข้อมูลอ่อนไหวที่หลงเหลือใน log

    • CVE-2026-9735 เป็นปัญหาที่ MongoDB Server อาจบันทึก authentication parameter และ credential ลงใน server log โดย MongoDB Server ก่อน 8.3.3 อยู่ในขอบเขตผลกระทบ
    • SERVER-126506
    • CVE-2026-9751 เป็นปัญหาที่ข้อมูลอ่อนไหวอาจถูกบันทึกใน mongod.log เมื่อ parameter ldapQueryPassword ถูกตั้งค่าด้วย runtime setParameter command
    • เวอร์ชันที่ได้รับผลกระทบคือก่อน 8.3.3, ก่อน 8.2.10, ก่อน 8.0.24, ก่อน 7.0.35
    • SERVER-123370

  • server crash และปัญหา availability

    • CVE-2026-9754 เป็นปัญหาที่ authenticated user with read role สามารถอ่านบางส่วนของ stack memory ที่ยังไม่ได้ initialize ได้ผ่าน command filemd5 และมีคะแนน 7.1
    • CVE-2026-9753 อาจทำให้ server crash เมื่อ malformed binary diff ถูกส่งให้ $_internalApplyOplogUpdate
    • CVE-2026-9752 อาจทำให้ server crash ระหว่าง 2dsphere index key generation เมื่อมี GeometryCollection ที่มี strict-winding polygon
    • CVE-2026-9749 อาจทำให้ server crash เมื่อใช้ MaxKey()

  • driver และเครื่องมือ

    • CVE-2026-9101 เป็น prototype pollution ในการ parse CSV ของ Compass และเวอร์ชันที่ได้รับผลกระทบคือ Compass 1.36.3 ถึง 1.49.5
    • CVE-2026-9100 เป็นปัญหา heap memory out-of-bounds read และ crash ใน legacy GridFS file reader ของ C Driver
    • CVE-2026-6811 อาจทำให้ application crash จาก stack exhaustion ใน MongoDB PHP driver
    • CVE-2026-2303 ทำให้ application crash หรือ information leak ได้จาก heap out-of-bounds read ใน GSSAPI C wrapper ของ MongoDB Go Driver
    • CVE-2026-2302 เป็นปัญหา unsafe reflection ของ Mongoid::Criteria.from_hash ใน MongoDB Ruby Driver

  • Ops Manager RCE

    • CVE-2026-8431 เป็น RCE ผ่าน webhook body ของ Ops Manager และมีคะแนน 9.4
    • หาก administrative user สามารถตั้งค่า webhook ได้ ก็อาจรันคำสั่งตามอำเภอใจผ่านค่าบางอย่างใน payload
    • ขอบเขตผลกระทบคือ Ops Manager 7.0 ถึงก่อน 8.0.23
    • Ops Manager release notes

กลุ่มผลิตภัณฑ์ที่ปรากฏบ่อยในประกาศความปลอดภัยตั้งแต่ปี 2025

  • MongoDB Server

    • มีการบันทึก CVE ซ้ำ ๆ ที่เกี่ยวกับ server crash, denial of service, privilege escalation, certificate validation, malformed BSON, aggregation, query planner, sharding และ time series
    • เวอร์ชันที่ได้รับผลกระทบแตกต่างกันไปตามประกาศ ครอบคลุมสาย MongoDB 5.0, 6.0, 7.0, 8.0, 8.1, 8.2, 8.3

  • client และ driver

    • C Driver, PHP Driver, Go Driver, Ruby Driver, Rust Driver, Node.js Driver, Java driver, .NET/C# Driver, PyMongo, libbson, js-bson เป็นต้น ปรากฏเป็นผลิตภัณฑ์ที่ได้รับผลกระทบ
    • บางรายการกล่าวถึงปัญหาที่ authentication-related data ถูกเปิดเผยต่อ command listener หรือ connection pool event listener

  • เครื่องมือปฏิบัติการ

    • Compass, mongosh, MongoDB for VS Code, Atlas Kubernetes Operator, Enterprise Kubernetes Operator, Ops Manager, Cloud Manager, BI Connector, Atlas SQL ODBC driver, Database Tools รวมอยู่ในผลิตภัณฑ์ที่ได้รับผลกระทบ
    • มีทั้งการขาดการตั้งค่า ACL ใน MSI สำหรับติดตั้งบน Windows, local privilege escalation, control character injection และการตรวจสอบ input ไม่เพียงพอที่เกี่ยวข้องกับ MITM

ประกาศความปลอดภัยทั่วไป

  • ส่วน General มีอัปเดตของเหตุการณ์ด้านความปลอดภัยที่เปิดเผยครั้งแรกเมื่อ 16 ธันวาคม 2023
  • รายการวันที่ 28 ธันวาคมและ 29 ธันวาคม 2023 ระบุว่าไม่พบหลักฐานการเข้าถึงโดยไม่ได้รับอนุญาตต่อ MongoDB Atlas cluster หรือ customer data ที่เก็บอยู่ใน Atlas cluster
  • รายการวันที่ 26 ธันวาคม 2023 แจ้งว่าปัญหาการล็อกอินของลูกค้ากำลังเกิดขึ้นจากจำนวน login attempt ที่เพิ่มขึ้นอย่างรวดเร็ว
  • รายการวันที่ 24 มกราคม 2024 แจ้งการเผยแพร่ post event summary ของ MongoDB
  • MongoDB Security Incident Post Event Summary

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-18
ความคิดเห็นใน Hacker News

  • ตอนนี้ถูกล็อกออกจากทั้ง บัญชี Atlas และพอร์ทัลซัพพอร์ต แบบสมบูรณ์
    ใช้การยืนยันตัวตนของ Mongo กับ Okta แต่ความพยายามล็อกอินทั้งหมดล้มเหลวที่หน้าล็อกอินพร้อมข้อความว่า "The request contained invalid data."
    ปัญหาคือพอร์ทัลซัพพอร์ตเองก็ต้องยืนยันตัวตนเหมือนกัน เลยกลายเป็นว่าถ้าจะขอความช่วยเหลือเรื่องยืนยันตัวตนล้มเหลว ก็ต้องยืนยันตัวตนให้ผ่านก่อน
    สงสัยว่าคนอื่นมีปัญหาเข้าแดชบอร์ดเหมือนกันไหม
    เพิ่มเติม: ราว ๆ 17:15 น. ตามเวลา US Eastern การยืนยันตัวตนกลับมาใช้งานได้อีกครั้ง และเข้าแดชบอร์ดได้แล้ว

    • ในฐานะพนักงาน MongoDB ขอบอกว่าปัญหาการล็อกอิน ไม่เกี่ยวกับเหตุการณ์ด้านความปลอดภัย
      หลังส่งการแจ้งเตือนไปยังลูกค้าและผู้ใช้ทุกคนพร้อมกัน ปริมาณความพยายามล็อกอินก็พุ่งสูงขึ้น
      ถ้ายังล็อกอินมีปัญหาอยู่ ลองใหม่อีกครั้งในอีกไม่กี่นาที
      กรุณาติดตามหน้าการแจ้งเตือนต่อไป: https://www.mongodb.com/alerts
    • พอลองล็อกอินแล้วขึ้น upstream request timeout
    • เจอเหมือนกันแม้ใช้ Google SSO

  • ชอบที่ประกาศสั้น กระชับ และตรงประเด็น
    มันบอกชัดว่ายังอยู่ในระยะเริ่มต้น ตอนนี้รู้ขอบเขตแค่ไหน และจะมีอัปเดตตามมาเมื่อมีข้อมูลเพิ่ม
    หวังว่าคนจะไม่ตอบสนองเหมือนลงโทษ MongoDB เพียงเพราะไม่ได้ใส่ข้อมูลให้มากกว่านี้ ทั้งที่การสืบสวนยังอยู่ในช่วงต้นอย่างชัดเจน

    • ในประกาศบอกว่าเพิ่ง ตรวจพบ เมื่อวันที่ 13 และคาดว่าเกิดขึ้นต่อเนื่องมาระยะหนึ่งแล้ว
      แทบจะยังไม่แน่ใจเลยว่าข้อมูลผู้ใช้โดนแตะหรือไม่ แต่ตอนนี้ให้ความรู้สึกเหมือนยังไม่ยอมบอก หรือแค่บอกว่า "ไม่ใช่" ซึ่งต้องการคำตอบที่ชัดกว่านี้
    • เห็นด้วย
      MongoDB โดนวิจารณ์มาหลายอย่างก็จริง แต่การรับมือครั้งนี้ ในแง่ของ ความซื่อสัตย์ ความโปร่งใส และความน่าเชื่อถือ ต้องยอมรับว่าเขาทำได้ดี
      อยากให้บริษัทอื่นทำตามแนวทางนี้ และเมื่อแสดงหลักการแบบนี้ให้เห็นตรง ๆ ก็ยิ่งทำให้อยากทำธุรกิจกับ MongoDB มากขึ้น

  • ในประกาศเขียนว่าให้ regularly rotate their MongoDB Atlas passwords มีบริบทอะไรที่ผมพลาดไปหรือเปล่า?
    หรือว่าทีมความปลอดภัยยุคนี้ยังแนะนำให้ เปลี่ยนรหัสผ่านเป็นรอบ ๆ กันจริง ๆ?

    • การ หมุนเวียนซีเคร็ต สำหรับแอปพลิเคชันเป็นเรื่องที่ดี
      แต่การบังคับให้ผู้ใช้เปลี่ยนรหัสผ่านเป็นประจำไม่ค่อยดีเท่าไร

  • ถ้าได้รับผลกระทบ ก็ไม่รู้เหมือนกันว่าควรเฝ้าดูพฤติกรรมผิดปกติในระบบอย่างไร
    แค่ดูล็อกอย่างเดียว ดูเหมือนจะไม่พอ

  • เรื่องนี้แสดงให้เห็นความเสี่ยงของ การรวมศูนย์สุดขั้ว
    ถึงลูกค้า Atlas จะไม่ได้รับผลกระทบโดยตรง แต่หลังมีประกาศแล้วถ้าเว็บไซต์หรือช่องทางซัพพอร์ตล่มเพราะคนแห่เข้าไปพร้อมกัน ก็เป็นเรื่องธรรมดาที่จะกังวล
    ถ้าอยากให้มีความซ้ำซ้อนจริง ๆ ในกรณีแบบนี้ ก็ควรมีผู้ให้บริการ MongoDB DBaaS อิสระมากกว่านี้ แต่การเปลี่ยนไลเซนส์เป็น SSPL ทำให้ถูกจำกัดไปมาก
    หวังว่า FerretDB จะสร้างทางเลือกที่ใช้งานได้จริงขึ้นมาได้

    • เรียกว่า “การรวมศูนย์สุดขั้ว” งั้นเหรอ รอให้ us-East-1 ล่มก่อนแล้วค่อยมาคุย

  • ประกาศด้านความปลอดภัยที่ได้รับวันนี้ระบุว่า MongoDB กำลังสืบสวน การเข้าถึงโดยไม่ได้รับอนุญาต ต่อระบบภายในบางส่วนของบริษัท และมีการเปิดเผยเมทาดาทาของบัญชีลูกค้าและข้อมูลติดต่อ
    ณ ตอนนี้ บริษัทยังไม่ทราบว่าข้อมูลที่ลูกค้าเก็บไว้ใน MongoDB Atlas ถูกเปิดเผยด้วยหรือไม่
    เขาระบุว่าตรวจพบกิจกรรมต้องสงสัยในช่วงเย็นวันพุธที่ 13 ธันวาคม 2023 ตามเวลา US Eastern และได้เริ่มขั้นตอนตอบสนองต่อเหตุการณ์ทันที โดยเชื่อว่าการเข้าถึงดำเนินต่อเนื่องมาระยะหนึ่งก่อนตรวจพบ
    บริษัทแนะนำให้ลูกค้าระวังการโจมตีแบบ social engineering และ phishing และถ้ายังไม่ได้ทำ ก็ควรเปิดใช้ MFA แบบต้านทานฟิชชิงและเปลี่ยนรหัสผ่าน โดยจะอัปเดตข้อมูลเพิ่มเติมที่ mongodb.com/alerts

    • ผมก็ได้รับอีเมลฉบับเดียวกัน
      โชคดีที่จริง ๆ แล้วไม่ได้ใช้ MongoDB Atlas

  • “ข้อมูลของคุณปลอดภัย เพราะเราไม่เคยเขียนมันลงดิสก์ตั้งแต่แรก”

    • /dev/null ขยายสเกลได้ระดับเว็บ
      https://youtube.com/watch?v=b2F-DItXtZs
    • เป็นคำถามจากเมื่อ 11 ปีก่อนที่ยังอยู่ยงคงกระพัน: "To what extent are 'lost data' criticisms still valid of MongoDB?" - https://stackoverflow.com/questions/10560834/to-what-extent-...
    • พูดกันอย่างเป็นธรรม MongoDB ดีขึ้นมากแล้ว แต่ก็ยังตลกอยู่ดี

  • ไม่เคยใช้ MongoDB มาก่อน เลยสงสัยว่าทำไมคนถึง เลือก MongoDB แทนฐานข้อมูลตัวอื่น

    • มันยืดหยุ่นมาก
      เพราะไม่ต้องพัฒนาตามสคีมาที่ตายตัว เช่น เวลาจะเปลี่ยนฟีเจอร์และข้อมูลอย่างรวดเร็ว ก็ไม่ต้องกังวลเรื่อง migration มากนัก
      สำหรับสตาร์ตอัปที่อยากเคลื่อนที่เร็ว นี่เป็นข้อดีมาก
      คิวรีดูคล้ายโค้ดแอปพลิเคชัน เลยไม่ต้องเปลืองแรงแปลงไอเดียเป็น SQL query มากนัก และจากประสบการณ์ก็นำไปสู่คิวรีที่พังยากกว่า
      เรื่องการโจมตีแบบ injection ก็มีอะไรให้กังวลน้อยกว่า ตราบใดที่ไม่ได้ออกแบบโครงสร้างที่เสี่ยงเองโดยตั้งใจ และมองว่าเขียนคิวรีซับซ้อนให้ง่ายกว่า SQL
      การแปลงชนิดข้อมูลก็ทำในโค้ดได้ แทนที่จะต้องใช้ inline SQL function เฉพาะแพลตฟอร์มอย่าง field_name::timestamp
      มีมาตรฐานเดียวทั้งในคิวรีและแนวทางพัฒนา ไม่ค่อยต้องมาคอยรับมือกับ dialect ต่าง ๆ แบบ SQL
      สำหรับ use case ส่วนใหญ่ มันสเกลได้ดีและค่อนข้างง่าย อีกทั้ง MongoDB ก็มีสายหลักอยู่แบบเดียว เลยมีโอกาสเกิดความสับสนเชิงลัทธิกับสายพันธุ์ย่อยเฉพาะทางน้อยกว่า
    • มันเป็น ผู้เล่นยุคแรก ในช่วงที่ทุกคนคิดว่าฐานข้อมูลเอกสารแบบ NoSQL จะแก้ทุกปัญหาได้
    • MongoDB คือทางเลือก NoSQL ที่เป็นตัวแทนชัดที่สุด
      ถ้าคุณคิดว่า สคีมายืดหยุ่น เป็นเรื่องดี MongoDB ก็ยอดเยี่ยม แต่ถ้าคิดว่าสคีมายืดหยุ่นเป็นเรื่องแย่ ก็คงไม่ชอบ
      สรุปสั้น ๆ ก็มีเท่านี้
    • ใช้งานแบบ on-premise หรือให้แม่นยำคือบน VPS
      มันเก็บและจัดการ JSON document ได้ง่าย
      ถ้าข้อมูลมีลักษณะเป็นต้นไม้ ก็เข้ากับเอกสารขนาดใหญ่ได้ค่อนข้างดี
      ถ้าต้องพึ่งความสัมพันธ์ระหว่างเอกสาร SQL database จะดีกว่า แต่ในหลายกรณี—จริง ๆ คือแทบทุกกรณีทั่วไป—ความสัมพันธ์แบบ SQL ไม่ได้จำเป็นเสมอไป
      MongoDB ก็จัดการความสัมพันธ์ได้เหมือนกัน แต่จะซับซ้อนขึ้นเล็กน้อย
    • เริ่มใช้งานค่อนข้างง่าย
      MQL ก็เข้าใจไม่ยาก และทำให้ MongoDB รู้สึกสนุกในระดับหนึ่ง
      ขอบอกไว้ก่อนว่าทำงานอยู่ที่ MongoDB

  • ทุกวันนี้ยังสงสัยว่าทำไมคนถึงเลือก MongoDB ต่อไปแทน Postgres
    ถ้ามีอะไรที่ผมมองข้ามไปก็อยากรู้จริง ๆ และไม่ได้ต่อต้านข้อมูลแบบ JSON แต่อย่างใด เพราะก็ใช้ ตาราง jsonb ใน Postgres บ่อยเหมือนกัน

    • คนใช้ MongoDB เพราะมันเริ่มต้นง่าย
      มันจัดการทั้ง “งานฐานข้อมูล” และ “การยืนยันตัวตน” ให้
      ผมเลิกสู้กับกระแสนี้แล้ว และตอนนี้ถ้าเห็นใครใช้ MongoDB ตั้งแต่ช่วงแรก ก็จะมองทันทีว่าเป็นสัญญาณว่านักพัฒนายังใส่ ล้อพยุง อยู่