ทำระบบ License Key เองดีไหม? เทียบ Build vs Buy

ระบบ license ที่ใช้งานได้จริงไม่ได้มีแค่ตาราง keys ต้องมีอย่างน้อย: นับที่นั่งต่อเครื่อง (device fingerprint), จำกัดจำนวน activation, วันหมดอายุ/ต่ออายุ, ระงับ/เพิกถอนคีย์, ตรวจ offline แบบกันปลอม (ลายเซ็นดิจิทัล), heartbeat สำหรับ floating, audit trail, rate-limit, และ API สำหรับออกคีย์อัตโนมัติ — แต่ละข้อมีรายละเอียดให้พลาดได้ทั้งนั้น

1) เก็บคีย์เป็น plaintext. ถ้าฐานข้อมูลหลุด คีย์ลูกค้าหลุดทั้งหมด ที่ถูกคือ เก็บแค่ SHA-256 ของคีย์ แล้วโชว์ค่า plaintext “ครั้งเดียว” ตอนสร้าง (เหมือนที่ KeyThai ทำ — ระบบเองยัง “อ่าน” คีย์ลูกค้ากลับมาไม่ได้)

2) เชื่อ client ฝั่งเดียว / ไม่มีลายเซ็น. ถ้าแอปแค่ยิงขอ valid? แล้วเชื่อคำตอบ คนตั้ง proxy คืน true ปลอมได้ ต้องเซ็น response ด้วยคีย์ที่ client ไม่มี (เช่น Ed25519) เรื่อง crypto นี่แหละที่พลาดง่ายและเจ็บที่สุด

3) ไม่มี audit trail. พอลูกค้าทักว่า “คีย์ผมโดนปิดทำไม” คุณตอบไม่ได้ เพราะไม่ได้บันทึกว่าใครทำอะไรเมื่อไร ทุก mutation ควรเขียน event เก็บไว้

4) ไม่หมุนกุญแจ (key rotation). ถ้า signing key หลุดแล้วหมุนไม่ได้ ต้องออกคีย์ ใหม่ให้ลูกค้าทั้งหมด ระบบที่ดีต้องรองรับหลาย key id (kid) และหมุนได้โดยคีย์เก่ายังตรวจผ่าน

5) ลืม edge case การเงิน. webhook ส่งซ้ำ → ออกคีย์ซ้ำ, ยกเลิก/คืนเงิน → ต้องเพิกถอน, ต่ออายุไม่จ่าย → ต้อง downgrade ทั้งหมดต้อง idempotent

ทำเองได้แน่นอน แต่ “เวอร์ชันที่ปลอดภัยพอจะขายของจริง” มักกินเวลาเป็นเดือน บวกภาระ ดูแลตลอดไป (uptime, การหมุนกุญแจ, แพตช์ช่องโหว่ crypto) ขณะที่เวลาเท่ากันนั้นเอาไปพัฒนา ตัวสินค้าที่ลูกค้าจ่ายเงินให้จะคุ้มกว่า ทางลัดคือใช้บริการสำเร็จรูปแล้วผสานผ่าน SDK ภายใน 15 นาที — ดูตัวอย่าง เพิ่ม license key ให้แอป C#/.NET

มีเหตุผลที่สมเหตุสมผลอยู่: ข้อกำหนดด้านอธิปไตยข้อมูลที่ห้ามใช้บริการภายนอกเลย, โมเดล license ที่แปลกมากจน off-the-shelf รองรับไม่ได้, หรือคุณ คือ คนทำเครื่องมือ developer เป็น ธุรกิจหลัก ถ้าไม่ใช่กรณีพวกนี้ การ “ซื้อ” มักให้ความปลอดภัยและความเร็วที่คุ้มกว่ามาก อ่านแนวคิดความปลอดภัยของเราที่หน้า ความน่าเชื่อถือ หรือดู เอกสารสำหรับนักพัฒนา