แม้แต่ Google ก็ยังตามไม่ทัน ─ ความปลอดภัยในยุค AI กลายเป็นการต่อสู้ "ในระดับวินาที"

แม้แต่ Google ก็เข้าสู่ยุค "วิ่งไปพร้อมกับการป้องกัน"

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

คำพูดของ Francis de Souza, COO ของ Google Cloud ที่รายงานโดย TechCrunch เป็นสัญลักษณ์ของการเปลี่ยนแปลงนี้ เขาเน้นว่าหากบริษัทต้องการนำ AI มาใช้ ความปลอดภัยไม่ควรเป็นสิ่งที่เพิ่มเข้ามาภายหลัง แต่ควรฝังอยู่ในโครงสร้างแพลตฟอร์มตั้งแต่แรก การใช้ AI ภายนอกโดยพนักงานโดยไม่ได้รับอนุญาต, การจัดการข้อมูลที่ข้ามคลาวด์หลายแห่ง, ความสามารถในการตรวจสอบ, การกำกับดูแล สิ่งเหล่านี้ไม่ใช่ปัญหาของแผนกระบบสารสนเทศเพียงอย่างเดียวอีกต่อไป แต่กลายเป็นความเสี่ยงที่ผู้บริหารและคณะกรรมการบริษัทต้องจัดการ

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

การโจมตีเกิดขึ้นใน "วินาที" ไม่ใช่ "เวลา"

de Souza อธิบายว่าเวลาที่เฉลี่ยจากการละเมิดไปยังขั้นตอนการโจมตีถัดไปได้ลดลงจากระดับชั่วโมงเป็นระดับวินาที ซึ่งมีความหมายอย่างมากสำหรับผู้ดูแลความปลอดภัย มนุษย์ต้องดูการแจ้งเตือน, ตรวจสอบสถานการณ์, รวบรวมผู้เกี่ยวข้อง, ตัดสินใจ, และปิดกั้นด้วยมือ ในระหว่างนั้น การโจมตีได้ก้าวไปยังขั้นตอนถัดไปแล้ว

ในกระแสนี้ คำตอบที่ Google Cloud เสนอคือ "การป้องกันที่เน้น AI" แทนที่มนุษย์จะควบคุมทุกอย่างโดยตรง เอเจนต์ AI จะทำการเฝ้าระวัง, ป้องกัน, และตอบสนองเบื้องต้น โดยที่มนุษย์จะทำหน้าที่กำกับดูแล หากการโจมตีเกิดขึ้นด้วยความเร็วของเครื่องจักร การป้องกันก็ต้องเคลื่อนที่ด้วยความเร็วของเครื่องจักรเช่นกัน

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

ปัญหาคีย์ API ของ Gemini แสดงถึงการล่มสลายของ "สมมติฐานเก่า"

สิ่งที่น่าสนใจในบทความของ TechCrunch คือไม่เพียงแค่แนะนำข้อเสนอแนะด้านความปลอดภัยของ Google Cloud แต่ยังพูดถึงปัญหาที่ Google เองต้องเผชิญ โดยเฉพาะปัญหาความขัดแย้งเกี่ยวกับการเรียกเก็บเงินสูงของ Gemini API

ปัญหาหลักอยู่ที่การจัดการคีย์ API ของ Google Cloud ในหลายปีที่ผ่านมา คีย์ API มักฝังอยู่ในโค้ดฝั่งลูกค้าในบริการเช่น Google Maps หรือ Firebase สำหรับนักพัฒนา นี่ไม่ใช่การ "เปิดเผยรหัสผ่าน" แต่ถูกมองว่าเป็นคีย์ที่สามารถเผยแพร่ได้เพื่อการระบุบริการหรือการเรียกเก็บเงิน

อย่างไรก็ตาม เมื่อมีการเปิดใช้งานบริการ AI ที่มีค่าใช้จ่ายสูงเช่น Gemini API ในโครงการเดียวกัน คีย์ API ที่มีอยู่สามารถใช้กับคำขอ AI ได้ หากคีย์นั้นยังคงอยู่ใน JavaScript ของเว็บไซต์เก่าหรือที่เก็บข้อมูลที่เปิดเผย ผู้โจมตีสามารถค้นพบและส่งคำขอจำนวนมากไปยัง Gemini หรือโมเดลการสร้างภาพและวิดีโอ ทำให้เกิดค่าใช้จ่ายมหาศาลในบัญชีเรียกเก็บเงินของนักพัฒนา

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

ความไม่ไว้วางใจใน "ขีดจำกัด" ที่ไม่ใช่ขีดจำกัด

ปัญหาเกี่ยวกับขีดจำกัดการใช้งานและการเรียกเก็บเงินที่เพิ่มความไม่ไว้วางใจของนักพัฒนา รายงานของ The Register แสดงตัวอย่างที่นักพัฒนาของ Google Cloud ได้รับการเรียกเก็บเงินจำนวนมากจากการใช้งาน API ที่ไม่ได้รับอนุญาต มีกรณีที่การใช้งานที่เคยอยู่ในระดับไม่กี่สิบดอลลาร์ต่อเดือนพุ่งขึ้นเกิน 10,000 ดอลลาร์ในเวลาสั้นๆ หรือขีดจำกัดที่ตั้งไว้ที่ประมาณ 250 ดอลลาร์ถูกยกขึ้นโดยอัตโนมัติตามประวัติการใช้งานของบัญชี

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

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

ความโกรธและความกลัวที่แพร่กระจายใน Reddit

ใน r/googlecloud ของ Reddit มีการโพสต์เกี่ยวกับ Gemini API และการเรียกเก็บเงินสูงของ Google Cloud อย่างต่อเนื่อง ผู้โพสต์คนหนึ่งกล่าวว่าบริการ B2B SaaS ของเขามีการเรียกเก็บเงินจาก Google Cloud ที่ปกติอยู่ที่ประมาณ 50 ดอลลาร์ต่อเดือน แต่พุ่งขึ้นเกิน 10,000 ดอลลาร์เนื่องจาก Veo 3 และโทเค็นการสร้างภาพของ Gemini เขาไม่ได้ใช้บริการเหล่านั้นในผลิตภัณฑ์ของเขาและได้ร้องเรียนการใช้งานที่ไม่ถูกต้องไปยัง Google แต่ตอนแรกได้รับคำตอบว่า "ไม่พบหลักฐานการใช้งานที่ไม่ถูกต้อง"

อีกโพสต์หนึ่งกล่าวว่าคีย์ API ของ Google Maps เก่าถูกใช้ในทางที่ผิดหลังจากเปิดใช้งาน Gemini API และเกิดการเรียกเก็บเงินประมาณ 36,800 ยูโร ในความคิดเห็นมีเสียงแปลกใจว่า "ปัญหานี้ควรถูกรายงานแล้ว แต่ทำไมพฤติกรรมยังไม่เปลี่ยน" และ "Google Cloud Console น่ากลัว การถือคีย์ที่สามารถสร้างค่าใช้จ่ายหลายหมื่นดอลลาร์ไม่สามารถไว้ใจได้"

ผู้โพสต์ที่อ้างว่าเป็นบริษัทขนาดเล็กในญี่ปุ่นยังเผชิญกับความเสี่ยงการเรียกเก็บเงินประมาณ 128,000 ดอลลาร์จากการใช้งาน Gemini API ที่ไม่ถูกต้องและกล่าวถึงความเป็นไปได้ของการล้มละลาย ในความคิดเห็นมีการเรียกร้องให้ Google ให้บริการหยุดการใช้งานที่แน่นอนเมื่อถึงจำนวนเงินที่กำหนด ด้วยการแพร่หลายของเครื่องมือการเขียนโค้ด AI ที่ทำให้นักพัฒนาสัมผัสกับ Google Cloud มากขึ้น ข้อสันนิษฐานว่า "ทุกคนสามารถปกป้องคีย์ได้อย่างสมบูรณ์" ไม่เป็นจริงอีกต่อไป

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

ใน Hacker News มีการวิจารณ์ "แนวคิดการออกแบบ" อย่างรุนแรง

ใน Hacker News มีการอภิปรายที่เจาะลึกถึงแนวคิดการออกแบบ ในกระทู้เกี่ยวกับการวิจัยของ Truffle Security มีการวิจารณ์ว่าคีย์ API ของ Google ถูกมองว่าเป็น "ตัวระบุที่สามารถเปิดเผยได้" มานาน แต่ด้วย Gemini กลายเป็นกุญแจสำคัญในการใช้ AI ที่มีค่าใช้จ่ายสูงและการเข้าถึงข้อมูล

ความคิดเห็นหนึ่งกล่าวว่าควรมีขีดจำกัดการใช้จ่ายที่ชัดเจนเช่น 10 ดอลลาร์หรือ 100 ดอลลาร์ต่อคีย์ การจัดการการใช้จ่ายต่อคีย์หรือบัญชีทำได้ง่ายกว่าใน OpenAI หรือ OpenRouter และมีความไม่พอใจที่การแจ้งเตือนการเรียกเก็บเงินของ Google Cloud มีความล่าช้าและไม่สามารถเป็นเกราะป้องกันได้จริง

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

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

ปัญหา "23 นาที" ที่ไม่จบแม้จะลบคีย์แล้ว

การวิจัยของ Aikido Security ได้เพิ่มความกังวลใหม่ การตรวจสอบของบริษัทชี้ให้เห็นว่าหลังจากลบคีย์ API ของ Google แล้ว คำขอบางส่วนอาจยังคงได้รับการยืนยันสูงสุดถึง 23 นาที ในระบบกระจายขนาดใหญ่ การเปลี่ยนแปลงการตั้งค่าอาจใช้เวลานานกว่าจะกระจายไปยังเซิร์ฟเวอร์ทั้งหมด แต่สำหรับการหมดอายุของข้อมูลการยืนยัน ความล่าช้านี้กลายเป็นเวลาการโจมตี

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

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

ข้อเสนอแนะของ Google ถูกต้อง และนั่นคือเหตุผลที่ต้องถาม

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

ปัญหาคือแพลตฟอร์มสามารถให้พื้นฐานที่ปลอดภัยเพียงใดในการดำเนินการตามข้อเสนอแนะที่ถูกต้องนี้ หากบอกบริษัทว่า "อย่าเพิ่มความปลอดภัยภายหลัง" ฝั่งคลาวด์ก็ต้องหลีกเลี่ยงสถานการณ์ที่ "การเพิ่มฟังก์ชัน AI ภายหลังทำให้การออกแบบการยืนยันและการเรียกเก็บเงินที่มีอยู่กลายเป็นอันตราย"

เหตุการณ์นี้ไม่ใช่ปัญหาของ Google เพียงอย่างเดียว แต่เป็นคำเตือนที่ใช้ได้กับผู้ให้บริการคลาวด์ทุกแห่ง, แพลตฟอร์ม AI, และบริษัท SaaS ทุกครั้งที่เพิ่มฟ