Google ระงับบัญชี Google Cloud ของบริษัทผมเป็นครั้งที่สาม

• บัญชี Google Cloud ของ SSLMate ถูกระงับเป็นครั้งที่สามโดยไม่มีการแจ้งเตือนล่วงหน้า ทำให้ฟีเจอร์การเชื่อมต่อบริการหยุดทำงานซ้ำแล้วซ้ำเล่า
• เพื่อเชื่อมต่อกับ Cloud DNS และ Cloud Domains ของลูกค้า บริษัทใช้โครงสร้างที่สร้างและมอบหมาย service account ตามเอกสารของ Google แต่แนวทางนี้กลับตกเป็นเป้าการระงับอย่างต่อเนื่อง
• การระงับครั้งแรก (2024) ก่อให้เกิดความสับสนอย่างมากจาก กระบวนการกู้คืนที่ไร้ประสิทธิภาพและสาเหตุที่ไม่ชัดเจน และการระงับอีกสองครั้งหลังจากนั้นก็ยังคงมีเพียง อีเมลอัตโนมัติซ้ำๆ โดยไม่มีการแจ้งล่วงหน้า
• ทางเลือกอย่าง การยืนยันตัวตนด้วยคีย์ระยะยาว มีความเปราะบางด้านความปลอดภัย ส่วน OIDC(OpenID Connect) ก็มีขั้นตอนการตั้งค่าที่ซับซ้อนเกินไป
• ผลลัพธ์คือ ในการเชื่อมต่อกับ Google Cloud มีการเปิดเผย ข้อจำกัดเชิงโครงสร้างที่เลือกได้เพียงสองในสามระหว่างความปลอดภัย ความสะดวก และความเสถียร

---

กรณีบัญชี Google Cloud ถูกระงับซ้ำๆ

• บัญชี Google Cloud ของ SSLMate ถูก ระงับโดยไม่มีการแจ้งเตือนล่วงหน้า ในวันศุกร์สองครั้งติดต่อกันในปี 2024 และ 2025
  • ก่อนหน้านี้ก็เคยถูกระงับแบบเดียวกันมาแล้วในปี 2024 และทั้งสามครั้ง ไม่มีการให้เหตุผลที่ชัดเจนหรือวิธีป้องกันไม่ให้เกิดซ้ำ
• SSLMate ใช้วิธี มอบหมาย service account เพื่อเชื่อมต่อกับบัญชี Google Cloud ของลูกค้า
  • สร้าง service account ภายใต้โปรเจ็กต์ของ SSLMate แยกตามลูกค้าแต่ละราย และให้ลูกค้ามอบสิทธิ์เข้าถึง Cloud DNS และ Cloud Domains ให้กับบัญชีนั้น
  • เมื่อจำเป็น SSLMate จะเข้าถึงโดย สวมรอย (impersonate) เป็น service account นั้น
  • โครงสร้างนี้อิงตามแนวทางที่แนะนำในเอกสารทางการของ Google และเป็น วิธีที่ปลอดภัยโดยไม่ต้องใช้ข้อมูลรับรองระยะยาวและตั้งค่าได้ง่าย

การระงับครั้งแรก (2024)

• ตอนถูกระงับครั้งแรก ฟังก์ชันการเชื่อมต่อของลูกค้าล้มเหลวทั้งหมด และไม่สามารถเข้าถึงคอนโซลได้
  • ทีมสนับสนุนของ Google ตอบกลับ แต่ บัญชีถูกปิดใช้งานจนทำให้อีเมลตีกลับ เป็นต้น แสดงให้เห็นว่ากระบวนการกู้คืนไม่มีประสิทธิภาพ
  • มีการขอ project ID แต่ไม่สามารถส่งให้ได้เพราะเข้าใช้คอนโซลไม่ได้
  • หลังยืนยันหมายเลขโทรศัพท์ มีเพียงบางโปรเจ็กต์ที่ถูกกู้คืน และวันถัดมาก็ได้รับอีเมลอัตโนมัติแจ้งจำกัดการเข้าถึงอีกครั้ง
  • หลังจากอีเมลอัตโนมัติอีกหลายฉบับ จึงกู้คืนได้ครบทั้งหมดในราว 19 ชั่วโมงต่อมา
• Google ไม่เปิดเผยสาเหตุของการระงับ และ ไม่มีอีเมลแจ้งเตือนล่วงหน้า
  • หลังจากนั้น SSLMate จึงเพิ่ม ฟีเจอร์ health check เพื่อตรวจจับอัตราความผิดพลาดของการเชื่อมต่อ สำหรับการตรวจพบตั้งแต่เนิ่นๆ

การระงับครั้งที่สอง (ราวเดือนตุลาคม 2025)

• health check ล้มเหลว และการเชื่อมต่อส่วนใหญ่ส่งข้อผิดพลาด “Invalid grant: account not found”
  • ยังเข้าสู่ระบบคอนโซลได้ แต่ได้รับเพียงอีเมลในแต่ละโปรเจ็กต์ว่า “กู้คืนแล้วตามข้อมูลที่ให้มา”
  • ยังคงไม่ได้รับอีเมลแจ้งการระงับ
  • หลังจากนั้นฟังก์ชันการเชื่อมต่อก็กลับมาทำงานตามปกติ

การระงับครั้งที่สาม (พฤศจิกายน 2025)

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

กรณีลูกค้าที่ยกเว้น

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

ปัญหาการพึ่งพา Google Cloud และทางเลือก

• SSLMate เห็นว่า ไม่สามารถพึ่งพาบัญชี Google ในสภาพแวดล้อมโปรดักชันได้
  • ระบบของ Google มีโครงสร้างที่ทำให้บัญชี โปรเจ็กต์ หรือแม้แต่ GCP ทั้งหมด อาจถูกระงับโดยพลการได้
• ทางเลือก 1: ให้ลูกค้าสร้าง service account เองและใช้ คีย์ระยะยาว (long-lived key) เพื่อยืนยันตัวตนให้ SSLMate
  • ตั้งค่าได้ง่าย แต่มีความเสี่ยงจากคีย์รั่วไหลและ ไม่สามารถหมุนเวียนคีย์ได้ ทำให้ปลอดภัยน้อย
• ทางเลือก 2: ใช้ OpenID Connect(OIDC)
  • เป็นวิธีมาตรฐานที่ใช้ใน GitHub Actions หรือการเชื่อมต่อกับ Azure และให้ การเข้าถึงที่ปลอดภัยโดยไม่ต้องมีข้อมูลรับรองระยะยาว
  • แต่การตั้งค่าใน Google Cloud ซับซ้อนเกินไปถึง 7 ขั้นตอน

ความซับซ้อนของการตั้งค่า OIDC

• หากต้องการใช้ OIDC ต้องทำตามขั้นตอนต่อไปนี้
  1. เปิดใช้ IAM Service Account Credentials API
  2. สร้าง service account
  3. สร้าง Workload Identity Pool
  4. สร้าง Workload Identity Provider ภายใน Pool
  5. มอบสิทธิ์ให้ SSLMate สามารถสวมรอยเป็น service account ได้
  6. มอบ Role ให้กับ service account
  7. ส่ง service account และ Provider ID ที่สร้างแล้วให้กับ SSLMate
• แต่ละขั้นตอนต้องใช้ resource ID จากขั้นตอนก่อนหน้า ทำให้ ลูกค้าทำตามได้ยาก
• ผู้เขียนชี้ว่าขั้นตอนต่อไปนี้เป็น กระบวนการที่ไม่จำเป็น
  • ควรสามารถมอบ Role ได้โดยตรงโดยไม่ต้องสร้าง service account
  • ในกรณีส่วนใหญ่ Pool มี Provider เพียงตัวเดียว จึงถือว่า การสร้าง Pool เองเป็นงานซ้ำซ้อนที่ไม่จำเป็น
  • ควรสามารถมอบ Role ได้โดยตรงให้กับ OIDC issuer URL และ subject โดยไม่ต้องสร้าง Provider

ปัญหาเชิงโครงสร้างและบทสรุป

• ปัจจุบันการเชื่อมต่อกับ Google Cloud เลือกได้เพียงสองในสาม สิ่งต่อไปนี้
  1. ไม่มีข้อมูลรับรองระยะยาว
  2. ลูกค้าตั้งค่าได้ง่าย
  3. ปลอดภัยจากการถูกระงับโดยพลการ
• แนวทางแบบ service account ของ SSLMate ได้ความปลอดภัยและความสะดวก แต่ยังมีความเสี่ยงถูกระงับ
• แนวทาง service account+key ตั้งค่าได้ง่ายและเสี่ยงถูกระงับต่ำกว่า แต่ความปลอดภัยอ่อนแอ
• แนวทาง OIDC มีความปลอดภัยและทนต่อความเสี่ยงจากการถูกระงับ แต่ตั้งค่ายุ่งยาก
• ข้อสรุปคือ หาก Google ไม่ ทำให้ OIDC เรียบง่ายขึ้นในฐานะวิธีเชื่อมต่อระดับ first-class ก็ยากจะมีการเชื่อมต่อที่ทั้งปลอดภัยและเสถียร

สรุปความคิดเห็นผู้อ่าน

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

[ndrgrd]

"Android developer verification ก็คงจะลงเอยแบบนี้เหมือนกัน ผู้คนจำนวนมากจะถูกแบนจากการพัฒนาแอป Android"

นี่คือความเห็นบน Hacker News ที่ผมจำได้มากที่สุด คิดว่าอีกไม่นานก็คงเกิดขึ้น

[GN⁺]

ความคิดเห็นจาก Hacker News

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

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

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

  • เพราะแบบนี้ฉันจึงพยายามเลือกใช้ บริษัทเล็ก อยู่เสมอ
    เพราะยังคุยกับคนจริงได้ ไม่ใช่แค่แชตบอตธรรมดา
    ตอนนี้ฉันใช้ Tuta Mail อยู่ และชอบเรื่อง การเข้ารหัสทนทานต่อควอนตัม กับสภาพแวดล้อมที่ไม่มีโฆษณา
    อีกทั้งยังสร้างอีเมล alias ได้มากเท่าที่ต้องการบนโดเมนของตัวเอง

• หลายปีก่อนบัญชี YouTube Premium ของฉันถูกแบนเพราะข้อหาสแปม
  ทั้งที่แค่ดูวิดีโอเฉย ๆ บัญชีก็ถูกลบ และยังเข้าไปที่หน้าชำระเงินไม่ได้อีก
  ระหว่างที่ต้องผ่าน กระบวนการอุทธรณ์แบบหุ่นยนต์ ซึ่งทำได้แค่ทุก 3 สัปดาห์ ก็ยังโดนเรียกเก็บเงินต่อเนื่อง
  แม้แต่ซัพพอร์ตแบบเสียเงินของ Google One ก็ไร้ประโยชน์ เพราะบอกว่า “เป็นคนละทีม ช่วยไม่ได้”
  สุดท้ายต้องแก้ด้วยการยกเลิกบัตร และอีกหลายเดือนต่อมาถึงได้รับข้อความว่า “เป็นความผิดพลาด”
  ที่น่าขันคือ WeChat กลับให้คุยกับคนจริงและแก้ปัญหาให้ได้ภายในวันเดียว — จนรู้สึกว่า บริการลูกค้าของรัฐเซ็นเซอร์ยังดีกว่า

• ปัญหาไม่ได้มีแค่ Google แต่รวมถึง โครงสร้างของบริษัทยักษ์ใหญ่ที่พึ่งอัลกอริทึม โดยรวม
  แม้แต่ใน Reddit บัญชีอายุ 20 ปีของฉันก็โดน shadowban โดยไม่มีเหตุผล
  การอุทธรณ์ถูกเพิกเฉย และทั้งโพสต์กับคอมเมนต์ก็ถูกกรองหมด
  Fediverse แสดงให้เห็นโมเดลทางเลือกที่ดีกว่า — หัวใจสำคัญคือชุมชนขนาดเล็กและสัดส่วนผู้ดูแลที่สูง

  • แต่ Fediverse ก็ไม่ได้สมบูรณ์แบบ
    โครงสร้างที่แท็ก #fediblock เพียงอันเดียวสามารถทำให้ถูกบล็อกอัตโนมัติจากหลายร้อยเซิร์ฟเวอร์ ก็เป็นการทำซ้ำของ การเซ็นเซอร์แบบไร้ความรับผิดชอบ
    ในความเป็นจริง Mastodon instance ของเมืองเราก็พังเพราะแบบนี้ และทุกคนก็ย้ายไป Bluesky
  • Google มีเงินทุนมากพอ
    การมีคนสัก 100 คนไว้จัดการ เคสปลายขอบ แบบนี้ไม่ใช่เรื่องยากเลย
    แต่บริษัทไม่ทำ เพราะมันจะลดมาร์จิ้น
  • การที่บริษัทระดับมูลค่าหลายล้านล้านดอลลาร์บอกว่า “นอกจากอัลกอริทึมแล้วไม่มีทางอื่น” เป็นแค่ข้ออ้าง
    ไม่ใช่เพราะไม่มีเงิน แต่เป็นเพราะ เลือกที่จะไม่ใช้

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

  • ถ้าลูกค้าภายนอกสามารถป้อนข้อมูลหรือสร้างภาพได้ ต้องเปิดใช้ เครื่องมือ moderation ในตัว ให้แน่นอน

• การยืนยันตัวตนนักพัฒนา Android ก็ดูเหมือนจะไปในทิศทางเดียวกัน
  มีโอกาสสูงที่นักพัฒนาจำนวนมากจะถูก ระงับสถานะนักพัฒนา โดยไม่มีเหตุผล

  • จริง ๆ แล้วตอนนี้ก็หนักมากอยู่แล้ว
    ฉันเคยเห็นกรณีพนักงานของบริษัทเล็กแห่งหนึ่งถูกบล็อกบัญชีส่วนตัวไปด้วย เพราะ “มีความเกี่ยวข้องกับบัญชีนักพัฒนาที่เคยถูกระงับมาก่อน”
  • โดยพื้นฐานแล้ว การพัฒนา Android มีโครงสร้างเหมือน ชาวนาเช่าที่ปลูกบนที่ดินของคนอื่น
    ฉันคิดว่าเป็นเรื่องยากที่จะรักษาความเชี่ยวชาญไว้ได้ในสภาพที่ต้องพึ่งพาแพลตฟอร์มแบบนี้

• บริการของเราก็แค่ใช้ปุ่ม “Login with Google” เท่านั้น แต่จู่ ๆ บัญชีก็ถูกบล็อก
  เหตุผลมีเพียงคำคลุมเครือว่า “ละเมิดข้อกำหนดการใช้งาน”
  ระหว่างที่ยื่นอุทธรณ์และรีบทำทางเลือกการล็อกอินอื่นให้ผู้ใช้ วันถัดมาก็มีอีเมลมาว่า “อนุมัติการอุทธรณ์” แบบกะทันหัน
  สุดท้ายแม้บัญชีจะกลับมาได้ แต่ก็ยังเหลือ ความไม่ไว้วางใจ อยู่

  • ถ้าเป็นฉัน ตอนนี้คงเลิกซัพพอร์ต “Login with Google” ไปแล้ว
  • ฉันคิดว่าแทนที่จะใช้ social login ควรใช้แค่ชื่อผู้ใช้/รหัสผ่าน, MFA, และ Passkey จะดีกว่า

• บัญชี AdSense ของฉันถูกระงับสามครั้งเพราะใส่ เครื่องหมายอัศเจรีย์ ในโฆษณา
  สุดท้ายฉันปิดบัญชีไป แต่ก็ยังรู้สึกว่าคงถูกติดตามในฐานะ “บัญชีที่อาจเป็นการฉ้อโกง” อยู่ดี

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

• ในสถานการณ์แบบนี้ก็อดคิดไม่ได้ว่าควร ฟ้อง Google หรือเรียกร้องให้เข้มงวดด้านกฎระเบียบมากขึ้น หรือไม่

  • แต่แค่เหตุผลว่า “บริษัทปฏิเสธที่จะทำธุรกิจกับฉัน” อย่างเดียว ก็ดูจะเป็นฐานฟ้องร้องที่อ่อน
  • ถึงอย่างนั้น ใน ศาลคดีมูลค่าน้อย ก็ยังพอมีลุ้น
    ได้ยินมาว่าหลายครั้ง Google ไม่มาศาลเอง หรือพยายามอ้าง TOS แล้วกลับทำให้ผู้พิพากษามองในแง่ลบมากกว่าเดิม

• อยากรู้ว่าบัญชีที่ล็อกอินแบบ Passkey เท่านั้น ซึ่งผูกกับอีเมลที่ถูกระงับ จะเป็นอย่างไร
  แทบไม่มีใครน่าจะเคยทดสอบว่า Passkey ที่ซิงก์อยู่ใน Google Password Manager จะยังใช้ได้หลังบัญชีถูกระงับหรือไม่
  หรือสุดท้ายจะกู้คืนอะไรไม่ได้เลยเพราะเข้าอีเมลไม่ได้