ข้อมูลรั่วไหล 11.18 ล้านรายการ: ก่อนให้ AI Agent เข้ามาทำงานในหน้าร้าน ใครควรถือกุญแจข้อมูลสมาชิก | CEO Insights

วันที่ 14 ตุลาคม เป็นวันพุธธรรมดาวันหนึ่ง

วันนั้น 91APP ผู้ให้บริการเทคโนโลยีอีคอมเมิร์ซของไต้หวัน พบว่าฐานข้อมูล Commerce Cloud ของบริษัทถูกโจมตีด้วยระบบอัตโนมัติ ในวันเดียวกัน ระบบภายในของ Zeabur สตาร์ทอัปแพลตฟอร์ม cloud deployment จากไต้หวันก็ถูกบุคคลภายนอกเจาะเข้ามา และย้อนไปอีกหนึ่งวัน Burger King ญี่ปุ่นพบว่าระบบสมาชิกบนแอปถูกเข้าถึงโดยไม่ได้รับอนุญาต ข้อมูลสมาชิกที่รั่วไหลสูงถึง 11.18 ล้านรายการ

สามบริษัท สองตลาด ในสัปดาห์เดียวกัน แต่บทสรุปต่างกันโดยสิ้นเชิง บริษัทหนึ่งประกาศข้อมูลสำคัญต่อตลาด แจ้งความ และเตือนลูกค้าให้ระวังมิจฉาชีพ อีกบริษัทตั้งคณะกรรมการรับมือเหตุการณ์ ส่วนอีกบริษัท สามวันต่อมาประกาศปิดกิจการภายในสิ้นปี

สิ่งที่ผมอยากพูดถึงไม่ใช่ว่าใครโชคร้าย แต่เป็นคำถามที่ใหญ่กว่านั้น: ในวันที่ทุกแบรนด์อยากให้ AI Agent เข้ามารับหน้าที่ดูแลสมาชิก ข้อมูลสมาชิกควรฝากไว้กับใครกันแน่

คำตอบของผมตรงไปตรงมา การให้ AI Agent เข้าสู่หน้าร้านอย่างปลอดภัย ไม่ได้ขึ้นอยู่กับว่าโมเดลฉลาดแค่ไหน แต่ขึ้นอยู่กับ 3 เรื่อง คือ ให้ Agent มีสิทธิ์เท่าที่จำเป็นต่อการทำงานเท่านั้น, API key ทุกดอกต้องมีผู้รับผิดชอบและหมุนเวียนเปลี่ยนเป็นระยะ, และการกระทำสำคัญอย่างการแก้ไขข้อมูลหรือคืนเงินต้องให้คนอนุมัติพร้อมเก็บบันทึกไว้ เหตุการณ์ทั้งสามในสัปดาห์นี้แสดงให้เห็นว่า การรั่วไหลของข้อมูลสมาชิกได้ยกระดับจากเรื่องของฝ่าย IT กลายเป็นเรื่องความอยู่รอดของแบรนด์แล้ว

---

สัญญาณเตือนสามครั้งในหนึ่งสัปดาห์: ข้อมูลสมาชิกรั่วไหลไม่ใช่เรื่องของฝ่าย IT อีกต่อไป

เริ่มจาก Burger King ญี่ปุ่น ผู้โจมตีเข้าออกระบบระหว่างวันที่ 2 ถึง 7 ตุลาคม แต่บริษัทเพิ่งรู้ตัวในวันที่ 13 ข้อมูลที่ถูกนำออกไปมีทั้งชื่อ วันเกิด รหัสสมาชิก อีเมล ที่อยู่ เบอร์โทรศัพท์ และประวัติการสั่งอาหารผ่านมือถือ โชคดีที่ไม่ได้เก็บเลขบัตรเครดิตไว้ แต่สำหรับแก๊งมิจฉาชีพ รายละเอียดอย่าง “คุณสั่ง Whopper ตอนเที่ยงวันพุธที่แล้ว” มีประโยชน์กว่าเลขบัตรเสียอีก

Burger King ไม่ใช่กรณีเดียว ในช่วงหนึ่งเดือนที่ผ่านมา IDCF Cloud ผู้ให้บริการคลาวด์ของญี่ปุ่นถูกโจมตีด้วยแรนซัมแวร์ กระทบลูกค้าองค์กรและหน่วยงานท้องถิ่น 495 ราย แพลตฟอร์มท่องเที่ยว Skyticket และ TEMAIRAZU ทำข้อมูลรั่วไหลรวมกันกว่า 18 ล้านรายการ ส่วน Lawson, Mr Max, Times Car และ Yamaha ก็อยู่ในรายชื่อด้วย

มาดูที่ Zeabur ปลายเดือนสิงหาคม ผู้โจมตีใช้ API key แบบเก่าอ่านค่า environment variables ของโปรเจกต์ไป และในการเจาะครั้งที่สองเมื่อวันที่ 14 ตุลาคม ก็ได้สิทธิ์อ่านฐานข้อมูลของแพลตฟอร์มไปด้วย ผู้ก่อตั้งยอมรับในจดหมายถึงผู้ใช้ว่า หลังประเมินด้านความปลอดภัย ภาระการดูแลระบบ และเงินลงทุนที่ต้องใช้เพื่อดำเนินงานต่อ จึงตัดสินใจปิดบริการ

เมื่อนำสามเหตุการณ์นี้มาวางเรียงกัน สัญญาณก็ชัดเจน: ข้อมูลรั่วไหลได้ยกระดับจากเหตุการณ์ด้าน IT กลายเป็นเหตุการณ์ของแบรนด์ หรือถึงขั้นเป็นเรื่องความเป็นความตาย เมื่อก่อนเรามองว่าความปลอดภัยไซเบอร์เป็นต้นทุน แต่วันนี้มันเหมือนประกันมากกว่า และเป็นประกันแบบที่ “ต้องเกิดเรื่องก่อนถึงจะรู้ว่าทำไว้ไม่พอ”

---

จังหวะเวลาที่ย้อนแย้ง: AI ยิ่งเก่ง กุญแจก็ยิ่งมีหลายดอก

ที่น่าขันคือ คลื่นข้อมูลรั่วไหลระลอกนี้มาชนกับช่วงที่ AI Agent กำลังมาแรงที่สุดพอดี

บริษัท AI รายใหญ่กำลังแข่งกันชิงงานย้ายระบบเก่าขององค์กร ย้ายฐานข้อมูลสมาชิก ระบบ POS และระบบบริการลูกค้าที่สร้างไว้เมื่อสิบกว่าปีก่อนขึ้นไปอยู่บนแพลตฟอร์มใหม่ ส่วนผู้ให้บริการ CRM รายใหญ่ก็ผลักดัน AI Agent เข้าสู่หน้าร้าน ทั้งตรวจสอบแต้มสมาชิก แนะนำสินค้า รับเรื่องร้องเรียน ไปจนถึงแก้ไขคำสั่งซื้อโดยตรง

ฟังดูดีมาก แต่ลองคิดคำถามง่าย ๆ ข้อหนึ่ง: AI Agent ที่ช่วยพนักงานค้นหาข้อมูลสมาชิก แก้ไขคำสั่งซื้อ และออกคูปองได้ ถือกุญแจไว้กี่ดอก

คำตอบคือ มากกว่าพนักงานคนไหน ๆ พนักงานหน้าร้านค้นข้อมูลได้เฉพาะในสาขาของตัวเอง ในเวลางาน และด้วยบัญชีของตัวเองเท่านั้น แต่ AI Agent ทำงานได้ 24 ชั่วโมง ข้ามทุกสาขา และค้นได้ 10,000 รายการในวินาทีเดียว Agent ยิ่งเก่ง ก็ยิ่งเข้าถึงข้อมูลได้มาก หากผู้โจมตียึด Agent ได้ ก็เท่ากับได้กุญแจผีที่เปิดได้ทั้งบริษัท

นี่คือบทเรียนจาก Zeabur ครั้งแรกเกิดเรื่องเพราะ “API key แบบเก่า” เพียงดอกเดียว ครั้งที่สองผู้โจมตีคลำทางเข้าไปถึงฐานข้อมูล ปัญหามักไม่ใช่ว่าลืมล็อกประตูหน้า แต่เป็นกุญแจสำรองที่ถูกลืมทิ้งไว้ตรงมุมไหนสักแห่ง และเมื่อ AI Agent ถูกนำมาใช้อย่างแพร่หลาย กุญแจสำรองแบบนี้จะยิ่งมีมากขึ้น ไม่ใช่น้อยลง

---

ปัญหาไม่ได้อยู่ที่หม้อ แต่อยู่ที่ครัว: ด่านป้องกันความปลอดภัย 3 ชั้นของ AI Agent

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

ขออธิบายคำศัพท์ให้ชัดก่อน AI Agent คือโปรแกรม AI ที่ค้นหาข้อมูล ตัดสินใจ และลงมือทำงานได้เอง ความต่างที่สำคัญที่สุดจากแชตบอตคือ มันไม่ได้แค่ตอบคำถาม แต่ยังแก้ไขข้อมูลในระบบได้จริง

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

หากต้องการให้ AI Agent เข้าสู่หน้าร้านอย่างปลอดภัย ครัวต้องเตรียม 3 เรื่องนี้ให้พร้อมก่อนเป็นอย่างน้อย:

• แบ่งระดับสิทธิ์: Agent ฝ่ายบริการลูกค้าเห็นสถานะคำสั่งซื้อได้ ไม่ได้แปลว่าต้องเห็นที่อยู่และวันเกิดของสมาชิกแบบครบถ้วน นี่คือสิ่งที่วงการความปลอดภัยเรียกว่า “หลักการให้สิทธิ์น้อยที่สุด” (Principle of Least Privilege) คือทุกบัญชีหรือทุกระบบได้รับข้อมูลและสิทธิ์เท่าที่จำเป็นต่อการทำงานเท่านั้น
• กุญแจต้องมีเจ้าของ: API key ทุกดอกต้องมีเจ้าของ มีวันหมดอายุ และมีบันทึกการหมุนเวียนเปลี่ยน กุญแจที่ไม่มีใครรับเป็นเจ้าของ ก็คือกุญแจที่ทิ้งไว้ให้ผู้โจมตี
• การกระทำสำคัญต้องให้คนอนุมัติ: งานค้นหาข้อมูลมอบให้ AI ได้ แต่การแก้ไขข้อมูล การคืนเงิน และการส่งออกข้อมูลจำนวนมาก ต้องมีคนกดปุ่มอนุมัติ และต้องเก็บบันทึกไว้ทุกครั้ง

ด่านป้องกันความปลอดภัย 3 ชั้นของ AI Agent

ทุกครั้งที่ AI Agent อ่านหรือเขียนข้อมูลสมาชิก จะต้องผ่านด่านป้องกันทั้ง 3 ชั้นนี้ตามลำดับ

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

---

แนวทางของ OakMega: พาเชฟ AI เข้าไปในครัว แทนที่จะขนวัตถุดิบออกมา

นี่คือเหตุผลที่ OakMega ผลักดัน FDE (Forward Deployed Engineer) เราไม่ได้ส่งเครื่องมือให้ลูกค้าแล้วจากไป แต่ส่งคนลงไปประจำหน้างาน เพื่อดูให้ชัดว่าข้อมูลสมาชิกของแบรนด์เก็บอยู่ที่ไหน ใครเข้าถึงได้ และขั้นตอนการทำงานเดินอย่างไร จากนั้นจึงตัดสินใจว่า AI Agent ควรได้รับสิทธิ์อะไรบ้าง

เราไม่อยากพูดเรื่องความปลอดภัยแค่ลมปาก จึงขอเปิดมาตรฐานขั้นต่ำของเราให้เห็นชัด ๆ:

• ได้รับการรับรองหลายมาตรฐาน ทั้ง ISO 27001, 27017, 27018 และ CMMC
• รองรับ Multi-cloud และการติดตั้งแบบ Private
• ระบบดูแลการให้บริการตาม SLA

เมื่อนำมาใช้งานจริง ก็คือ Agent ประจำหน้าร้านและ Agent บริการลูกค้าบน LINE ที่ตอบคำถามสมาชิกได้ทันทีและช่วยพนักงานค้นหาข้อมูล แต่ทุก Agent ทำงานภายใต้การควบคุมสิทธิ์ และการกระทำสำคัญอย่างการแก้ไขข้อมูล การออกคูปอง หรือการคืนเงิน ต้องผ่านการอนุมัติจากคนทุกครั้ง

หน้าที่ของ AI Agent คือช่วยประหยัดเวลาให้พนักงาน ไม่ใช่เปิดประตูหลังให้แฮกเกอร์

---

ก่อนนำ AI Agent มาใช้ ถาม 3 คำถามนี้ก่อน

เหตุการณ์ของ Burger King, 91APP และ Zeabur ไม่ได้มีไว้ขู่ให้ใครเลิกใช้ AI การที่ AI Agent เข้าสู่หน้าร้านเป็นกระแสที่หยุดไม่อยู่ จุดชี้ขาดที่แท้จริงคือ คุณจะสร้างครัวให้เสร็จก่อนแล้วค่อยจ้างเชฟ หรือจ้างเชฟก่อนแล้วค่อยมาซ่อมครัวทีหลัง

หากคุณกำลังพิจารณานำ AI Agent มาใช้ ไม่ว่าจะร่วมงานกับใคร ผมแนะนำให้ถาม 3 คำถามนี้ก่อน:

1. Agent ตัวนี้มองเห็นข้อมูลสมาชิกอะไรบ้าง ให้สิทธิ์เฉพาะเท่าที่จำเป็นต่อการทำงานได้หรือไม่
2. กุญแจทุกดอกในระบบ ใครเป็นผู้รับผิดชอบ เปลี่ยนบ่อยแค่ไหน และเมื่อมีคนลาออกหรือหยุดใช้งาน ใครเป็นคนเรียกคืน
3. การแก้ไขข้อมูล การคืนเงิน และการส่งออกข้อมูลจำนวนมาก สุดท้ายแล้วใครเป็นคนกดปุ่มอนุมัติ และมีบันทึกหรือไม่

ถ้าตอบได้ครบทั้งสามข้อ AI Agent ก็คือผู้ช่วย ถ้าตอบไม่ได้ มันก็คือข่าวถัดไป

โมเดลจะฉลาดขึ้นเรื่อย ๆ เรื่องนี้ไม่ต้องห่วง สิ่งที่ควรห่วงคือ กุญแจอยู่ในมือใครกันแน่

---

คำถามที่พบบ่อย

Q: AI Agent เพิ่มความเสี่ยงที่ข้อมูลสมาชิกจะรั่วไหลหรือไม่

เพิ่ม หากไม่มีการควบคุมสิทธิ์ AI Agent ค้นหาข้อมูลจำนวนมากข้ามสาขาได้ตลอด 24 ชั่วโมง เมื่อถูกเจาะ ผลกระทบจึงกว้างกว่าบัญชีของพนักงานคนเดียวหลายเท่า แต่ถ้าให้สิทธิ์เท่าที่จำเป็นต่อการทำงาน และให้การกระทำสำคัญผ่านการอนุมัติจากคน ก็จะคุมความเสี่ยงให้อยู่ในระดับที่จัดการได้

Q: หลักการให้สิทธิ์น้อยที่สุดคืออะไร

หลักการให้สิทธิ์น้อยที่สุด หมายถึงทุกบัญชีหรือทุกระบบได้รับข้อมูลและสิทธิ์ในการดำเนินการเท่าที่จำเป็นต่อการทำงานเท่านั้น เช่น Agent ฝ่ายบริการลูกค้าตรวจสอบสถานะคำสั่งซื้อได้ แต่มองไม่เห็นที่อยู่และวันเกิดของสมาชิกแบบครบถ้วน

Q: ISO 27001, 27017 และ 27018 ต่างกันอย่างไร

ISO 27001 กำหนดการบริหารจัดการความมั่นคงปลอดภัยสารสนเทศขององค์กรโดยรวม ISO 27017 มุ่งเน้นการควบคุมความปลอดภัยของบริการคลาวด์ ส่วน ISO 27018 มุ่งเน้นการคุ้มครองข้อมูลส่วนบุคคลบนพับลิกคลาวด์ การได้รับครบทั้งสามมาตรฐาน หมายความว่าตั้งแต่ระบบการบริหารจัดการไปจนถึงข้อมูลส่วนบุคคลบนคลาวด์ ล้วนมีมาตรฐานสากลกำกับดูแล

แหล่งข้อมูล

• ระบบ CRM ของ Burger King ญี่ปุ่นถูกแฮก ข้อมูลส่วนตัวของสมาชิกกว่า 11 ล้านรายรั่วไหล | iThome
• ฐานข้อมูล Commerce Cloud บนแพลตฟอร์มคลาวด์ของ 91APP ถูกโจมตีด้วยระบบอัตโนมัติ | iThome
• Zeabur ประกาศยุติการให้บริการ ปิดทั้งหมดก่อน 31 ธันวาคม | INSIDE