ป้องกันการใช้ API SMS โดยไม่ได้รับอนุญาต

หาก API ส่ง SMS ถูกเรียกโดยไม่ได้รับอนุญาต หรือ API Key รั่วไหลแล้วถูกนำไปใช้ ข้อความอาจถูกส่งจำนวนมาก ยอดเงินถูกใช้เร็ว และชื่อเสียงของช่องทางอาจลดลง EngageLab SMS สามารถจำกัดความถี่ ปริมาณ และขอบเขตประเทศ / ภูมิภาคฝั่งการส่งได้ แต่ทดแทนการปกป้อง secret และจุดเข้าส่งของธุรกิจคุณไม่ได้

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

สถาปัตยกรรมที่ถูกต้อง

ต้องเรียก EngageLab SMS API จากเซิร์ฟเวอร์ของระบบธุรกิจคุณเท่านั้น ห้ามเรียกโดยตรงจากเบราว์เซอร์ ไคลเอนต์ App หรือมินิโปรแกรม

              
              เซิร์ฟเวอร์ระบบธุรกิจ → EngageLab SMS API (พร้อม API Key; การส่งที่เริ่มจากหน้าเว็บให้ส่ง end_user_ip ด้วย)

            

• เก็บ dev_key และ dev_secret ไว้ที่เซิร์ฟเวอร์เท่านั้น ห้ามใส่ในโค้ดฟรอนต์เอนด์ แพ็กเกจแอป คลังสาธารณะ หรือตัวแปร CI แบบข้อความชัด
• ห้ามเปิด URL ของ SMS API และ secret บนเอนด์พอยต์ที่ผู้ใช้ปลายทางเรียกได้โดยตรง
• แนะนำให้ตั้งรายการอนุญาต IP ของผู้เรียกสำหรับ API Key ฝั่งโปรดักชัน ดู API Key

อย่าปะปน IP สองประเภท

หลังจากเปิดการจำกัด «ตามที่อยู่ IP» ใน ศูนย์ความปลอดภัย แล้ว ต้องส่ง end_user_ip ในคำขอ ส่งข้อความ SMS การจำกัดจึงจะมีผล ส่ง IP สาธารณะของอุปกรณ์ผู้ใช้ ไม่ใช่ IP ของเซิร์ฟเวอร์คุณ เมื่อเซิร์ฟเวอร์ส่ง SMS การตลาดหรือแจ้งเตือนเป็นชุดโดยไม่มี IP ผู้ใช้ปลายทาง การจำกัดตาม IP จะไม่มีผลกับคำขอนั้น ให้อาศัยรายการอนุญาต API Key และโควตาปริมาณการส่งเป็นหลัก

การป้องกันฝั่งแพลตฟอร์ม

ตั้งค่าต่อไปนี้ในคอนโซล SMS เพื่อจำกัดความเสียหายหาก API ถูกใช้ในทางที่ผิด

หากต้องการรับการแจ้งเมื่อถึงค่าเตือนหรือโควตา ให้ตั้งค่าอีเวนต์คอลแบ็กใน Webhook ก่อน

เสริมการป้องกันตามประเภทเทมเพลต

ประเภทเทมเพลต ถูกใช้ในทางที่ผิดต่างกัน จุดเน้นการป้องกันจึงต่างกัน

เทมเพลตแจ้งเตือน / การตลาด

SMS ประเภทนี้มักส่งเป็นชุดจากเซิร์ฟเวอร์ตามเหตุการณ์ธุรกิจหรือแผนปฏิบัติการ ความเสี่ยงหลักคือ Key ที่รั่วไหลถูกนำไปส่งจำนวนมาก

• สภาพแวดล้อมโปรดักชันต้องตั้งรายการอนุญาต IP ของ API Key
• ตั้งโควตาการส่งรายวัน / รายเดือนที่สมเหตุสมผลให้แอป เพื่อไม่ให้ยอดเงินหมดในครั้งเดียว
• ให้จ็อบตามเวลาหรือแบบชุดทำงานเฉพาะในสภาพแวดล้อมเซิร์ฟเวอร์ที่ควบคุมได้ ห้ามเปิดความสามารถส่งเป็น HTTP เอนด์พอยต์ที่ไม่มีการยืนยันตัวตน

เทมเพลตรหัสยืนยัน

หากคุณใช้เทมเพลตประเภทรหัสยืนยัน และการส่งถูกกระตุ้นด้วยปุ่ม «ขอ SMS» บนเว็บไซต์หรือ App ให้ป้องกัน API ฝั่งธุรกิจของคุณด้วย

• ทำ human verification (เช่น CAPTCHA รูปภาพ หรือ Turnstile / reCAPTCHA) ก่อนส่ง และตรวจผลที่เซิร์ฟเวอร์
• ตั้งช่วงเวลาก่อนส่งซ้ำสำหรับเบอร์เดียวกัน (เช่น 60 วินาที) และแสดงนับถอยหลังที่ฟรอนต์เอนด์
• จำกัดคำขอต่อบัญชี อุปกรณ์ และ IP ตามนาที ชั่วโมง และวันตามปฏิทิน นับคำขอที่ล้มเหลวด้วย
• «ขอ SMS» ต้องมีสถานะเข้าสู่ระบบ หรือเซสชันที่ถูกต้องในกรณีที่ยังไม่เข้าสู่ระบบ ห้ามเปิดช่องส่งสาธารณะที่ไม่มีบริบท

ใช้รหัสข้อผิดพลาดเป็นสัญญาณความผิดปกติ

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

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

เมื่อ secret รั่วไหล

1. ในคอนโซล SMS ปิดใช้งานหรือหมุนเวียน API Key
2. ใน ศูนย์ความปลอดภัย ใช้การหยุดฉุกเฉินเพื่อหยุดการส่ง SMS
3. ตรวจการส่งที่ผิดปกติใน รายละเอียดข้อความ และคอลแบ็ก
4. ดู การตั้งค่าการแจ้งเตือน ว่ามีการแจ้งยอดเงินหรือไม่ และเทียบการใช้ล่าสุด
5. รัดรายการอนุญาต IP ของ API Key และตรวจว่าโควตารายวัน / รายเดือนเหมาะสมหรือไม่
6. กลับมาส่งอีกครั้งเมื่อความเสี่ยงหมดไปเท่านั้น

รายการตรวจก่อนเปิดใช้งานจริง

• เรียก API จากเซิร์ฟเวอร์เท่านั้น dev_secret ไม่อยู่ในฟรอนต์เอนด์ แอป คลังสาธารณะ หรือตัวแปร CI แบบข้อความชัด
• API Key โปรดักชันตั้งรายการอนุญาต IP ขาออกของเซิร์ฟเวอร์แล้ว
• ศูนย์ความปลอดภัยเปิดจำกัดความถี่ตามเบอร์แล้ว การส่งที่เริ่มจากหน้าเว็บมี end_user_ip
• ตั้งโควตารายวัน / รายเดือนแล้ว รวมทั้งคอลแบ็กที่เกี่ยวกับปริมาณและการแจ้งยอดเงิน
• การส่งประเภทรหัสยืนยันทำ CAPTCHA และจำกัดอัตราฝั่งธุรกิจก่อนเรียก EngageLab
• ทราบลำดับรับมือเมื่อถูกใช้ในทางที่ผิดแล้ว: ปิด Key → หยุดฉุกเฉิน → ตรวจบันทึกการส่ง