Secret Pattern Scanner: จับ API Key รั่วก่อนถูกใช้โจรกรรม

ยกมือขึ้นถ้าเคยวาง snippet ที่มี API key ติดมาด้วยลงในแชท สไลด์ หรือบทความโดยไม่ได้ตั้งใจ เรื่องแบบนี้เกิดขึ้นบ่อยกว่าที่คิด และเป็นหนึ่งในช่องทางแฮ็กชั้นต้น ๆ ที่ผู้ไม่หวังดีใช้ได้จริง เพราะ credential ที่รั่วแม้เพียงตัวเดียวก็เปิดประตูให้เข้าถึง cloud, database หรือระบบ payment ของคุณได้ทั้งชุด

Secret Pattern Scanner คือเครื่องมือฟรีที่ช่วยจับ secret ที่รั่วไหลก่อนที่มันจะถูกใช้โจรกรรม — เพียงวาง code, ไฟล์ .env หรือ config ลงไป ตัว scanner จะรัน regex patterns ในเบราว์เซอร์ของคุณทันที เพื่อหา AWS access key, GitHub token, Slack token, Google API key, Stripe key, JWT และ PEM private key ที่อาจหลุดอยู่ในนั้น ทุกอย่างทำงานฝั่ง client 100% ข้อมูลของคุณไม่ถูกส่งไปเซิร์ฟเวอร์ใด ๆ เลย

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

ทำไมต้องใช้ Secret Pattern Scanner?

• กันความเสี่ยงก่อนแชร์ไฟล์ — ตรวจไฟล์ .env, config หรือ log ก่อนส่งให้เพื่อนร่วมทีมหรือแนบใน ticket เสมอ เพราะ secret ที่ติดไปกับไฟล์คือประตูบานแรกที่แฮ็กเกอร์มองหา
• เช็คก่อนเผยแพร่บทความหรือ presentation — snippet ในโพสต์ สไลด์ หรือ screenshot ที่จับมาอาจมี key จริงติดมาด้วยโดยที่คุณไม่รู้ตัว
• ประเมินโปรเจกต์ที่รับมา — ก่อนรับช่วงงานโค้ดจากทีมอื่นหรือตรวจ repo ที่ซื้อมา สแกนดูก่อนว่ามี secret เก่าค้างอยู่ไหม
• ทำงาน offline ทั้งหมด — เนื้อหาที่วางไม่เคยออกจากเบราว์เซอร์ จึงเหมาะกับ secret ที่ sensitive จนไม่ควรส่งขึ้นอินเทอร์เน็ตแม้แต่บรรทัดเดียว
• mask ผลลัพธ์อัตโนมัติ — key ที่ตรวจพบถูกปกปิดส่วนใหญ่ไว้ คุณเห็นแค่พอจะรู้ว่าคืออะไรตรงไหน โดยไม่เพิ่มความเสี่ยงรั่วซ้ำระหว่างการรีวิว
• ฟรีและไม่ต้องติดตั้ง — เปิดเบราว์เซอร์แล้วใช้ได้ทันที เหมาะกับการเช็คด่วนที่ไม่อยากลง scanner เต็มรูปแบบใน CI

ฟีเจอร์หลัก

รายละเอียดที่น่าสนใจ:

• patterns ถูกออกแบบตามรูปแบบจริงของแต่ละผู้ให้บริการ เช่น AWS ขึ้นต้น AKIA และ Stripe ขึ้นต้น sk_test ทำให้ false positive น้อยกว่าการหา "ข้อความยาว ๆ" แบบหยาบ ๆ
• รองรับการตรวจ JWT ที่ฝังอยู่ใน config หรือ code ซึ่งมักถูกมองข้ามเพราะดูเหมือน string ธรรมดา
• วางหลายไฟล์ต่อกันได้ในครั้งเดียว เหมาะกับการ audit ชุด config ของทั้งโปรเจกต์

วิธีสแกนหา secrets ที่รั่ว

1. เปิด Secret Pattern Scanner ในเบราว์เซอร์
2. วางเนื้อหาที่ต้องการตรวจลงในช่อง input เช่น ไฟล์ .env, ไฟล์ config, โค้ดบางส่วน หรือ log
3. กดสแกน เครื่องมือจะรัน regex patterns ทั้งหมดในเครื่องของคุณทันที
4. ดูรายการที่ตรวจพบ แต่ละรายการจะระบุประเภท (เช่น AWS access key, GitHub token, JWT) ตำแหน่งที่พบ และค่าที่ถูก mask ไว้
5. อ่านสรุปผลและคำแนะนำ หากพบ secret จริง ให้แก้ตามลำดับ: หมุนเวียน (revoke) key เดิม ออกตัวใหม่, ย้าย secrets ไป environment variables หรือ secret manager และล้าง git history หากเคย commit ไปแล้ว

Patterns เหล่านี้ตรวจจับอะไรได้บ้าง

secret แต่ละประเภทมีลายเซ็นเฉพาะตัว ซึ่งเป็นพื้นฐานของ regex ที่เครื่องมือใช้:

• AWS access key — ขึ้นต้นด้วย AKIA (หรือ ASIA สำหรับ temporary credential) ตามด้วยตัวอักษรและตัวเลข 20 ตัว มักหลุดมาพร้อม secret access key ในไฟล์ credentials หรือ .env
• GitHub token — ขึ้นต้นด้วย ghp* (personal access token), gho* หรือ ghs_ พบบ่อยใน CI config และ script deploy อัตโนมัติ
• Slack token — ขึ้นต้นด้วย xoxb, xoxp หรือ xoxa มักแปะค้างใน webhook config หรือ integration ที่ลืมลบ
• Google API key — ขึ้นต้นด้วย AIza ตามด้วยสตริง 35 ตัว หลุดมากับ frontend code ที่ hard-code ไว้
• Stripe key — ขึ้นต้นด้วย sktest หรือ sklive (และ pktest/pklive) โดย sk_live คือระดับอันตรายสูงสุดเพราะแตะเรื่องเงินโดยตรง
• JWT — ขึ้นต้นด้วย eyJ เพราะเป็น base64 ของ header JSON มักฝังใน config, cookie dump หรือ resource ของ mobile app
• PEM private key — บล็อกที่ขึ้นต้นด้วย -----BEGIN PRIVATE KEY----- หรือ -----BEGIN RSA PRIVATE KEY----- เจอบ่อยใน repo ที่ commit ไฟล์ certificate มาโดยไม่ระวัง

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

ตัวอย่างผลลัพธ์แบบ mask:

AWS Access Key : AKIA****...****Q3FX
GitHub Token   : ghp_****...****k9R2
Stripe Key     : sk_live_****...****Mq8L

ข้อดีของการสแกนแบบ offline คือมันปลอดภัยเชิงตรรกะ — secret ที่ sensitive ที่สุดของคุณไม่ควรถูกส่งไปที่ใดเลยแม้เพื่อการตรวจสอบ เครื่องมือนี้รันทุกอย่างในเบราว์เซอร์ จึงเป็นวงจรปิดที่คุณควบคุมได้ทั้งหมด ต่างจากการอัปโหลดไฟล์ไปสแกนบนเว็บออนไลน์ทั่วไป

เมื่อเจอ secret ที่รั่ว ขั้นตอนแก้ไขคือ หนึ่ง หมุนเวียน key ทันที เพราะเมื่อเคยรั่วถือว่า compromised แล้ว ไม่ว่าจะลบออกจากโค้ดหรือไม่ สอง ย้าย secrets ไปเก็บใน environment variables หรือ secret manager อย่า hard-code ในไฟล์ สาม ล้าง git history หากเคย commit ลง repo เพราะการลบใน commit ถัดไปไม่พอ และสี่ ทบทวน log การใช้งานของ key นั้นว่ามีใครใช้ไปแล้วหรือยัง

กรณีใช้งานจริง

Audit ก่อนเปิดซอร์ส

ทีมกำลังจะเปิด repo ให้สาธารณะ ก่อนกด publish ให้คัดลอกไฟล์ config และ environment template ทั้งหมดมาวางสแกน สมมติว่าเจอ Stripe key หนึ่งตัวที่ฝังอยู่ใน setup script เก่า ๆ การเจอก่อนเปิดซอร์สหนึ่งนาที อาจช่วยกันความเสียหายจากธุรกรรมปลอมที่อาจตามมาทั้งเดือน

รีวิวโปรเจกต์ที่รับมา

คุณเพิ่งรับงานดูแลระบบจากทีมอื่น หรือซื้อ source code มาต่อยอด ก่อน deploy ของคุณเอง ให้สแกนไฟล์ config และ .env ที่ได้รับมาทั้งหมด ถ้าเจอ token เก่าที่ยัง active ก็รีบแจ้งเจ้าของเดิมให้ revoke แล้วเปลี่ยนใหม่ ก่อนที่มันจะกลายเป็นช่องโหว่ที่ตกเป็นของคุณ

ตรวจบทความก่อนเผยแพร่

นักเขียนเทคนิคมักแปะ snippet จริงจากโปรเจกต์ตัวเองลงในบทความ ก่อนกด publish วางเนื้อหาฉบับเต็มลงสแกนสักรอบ ถ้ามี key จริงติดมาใน snippet จะได้เปลี่ยนเป็นค่า dummy ก่อน ไม่ต้องแก้ตัวทีหลังพร้อมกับหมุน key กลางดึก

ตรวจสุขอนามัยของไฟล์ .env

ทำให้เป็นนิสัย — ก่อนส่งไฟล์ .env ให้เพื่อนร่วมทีม แนบใน ticket หรือซิงก์ขึ้น shared drive ให้วางสแกนหนึ่งครั้ง มันตอบคำถามง่าย ๆ ว่าไฟล์นี้มีอะไรที่รั่วไม่ได้ซ่อนอยู่หรือเปล่า และยังใช้กับข้อความจาก screenshot ของ terminal ที่จะเอาไปโชว์ใน meeting ได้ด้วย โดยพิมพ์สิ่งที่เห็นในภาพลงไปให้ตรวจ

แนวทางปฏิบัติที่ดี

• หมุนเวียน key ทันทีที่สงสัยว่ารั่ว — อย่าเสี่ยงรอ การ revoke และออก key ใหม่ใช้เวลาไม่กี่นาที แต่การเก็บตัวเดิมไว้อาจแพงกว่ามาก
• อย่าเก็บ secret ในไฟล์ source — ย้ายไป environment variables หรือ secret manager ตั้งแต่เริ่มโปรเจกต์
• เพิ่ม .env ลง .gitignore ตั้งแต่วันแรก — และใช้ไฟล์ .env.example ที่ไม่มีค่าจริงสำหรับแชร์โครงสร้างแทน
• ล้าง git history เมื่อ secret เคยถูก commit — เพราะประวัติยังเก็บค่าเดิมไว้ แม้ลบออกจากไฟล์ปัจจุบันแล้ว
• ตั้ง secret scanning ใน CI ควบคู่กันไป — เครื่องมือนี้เหมาะกับการเช็คจุดเดียวแบบวางข้อความ ส่วน pipeline ควรมี scanner รันอัตโนมัติทุก commit
• จำกัด scope ของ key แต่ละตัว — ให้สิทธิ์เท่าที่จำเป็นตามหลัก least privilege เมื่อไหร่รั่ว ความเสียหายก็ถูกจำกัด

ลองใช้ Secret Pattern Scanner ดูสักครั้ง — ใช้เวลาไม่ถึงนาที แต่อาจเป็นนาทีที่กันเหตุโจรกรรม credential ของคุณได้ทั้งปี วางไฟล์ .env ล่าสุดของคุณลงไปเลย แล้วดูว่ามีอะไรซ่อนอยู่บ้าง

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• JWT Decoder — ถอดรหัสและตรวจสอบ payload ของ JWT ที่พบจากการสแกน
• Hash Generator — สร้าง hash เพื่อเทียบความถูกต้องของไฟล์หรือข้อความ
• Text Encryptor — เข้ารหัสข้อความสำคัญก่อนส่งผ่านช่องทางที่ไม่ปลอดภัย

รักษาความปลอดภัยไว้ให้มั่น!

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

ถ: ข้อมูลที่ฉันวางลงไปถูกส่งไปเซิร์ฟเวอร์ไหม?

ตอบ: ไม่ เครื่องมือรัน regex patterns ทั้งหมดในเบราว์เซอร์ของคุณแบบ offline 100% ข้อความที่วางไม่เคยออกจากเครื่องของคุณ

ถ: ถ้าเจอ secret ที่รั่วแล้วต้องทำอะไรก่อน?

ตอบ: หมุนเวียน key ทันทีโดย revoke ตัวเก่าและออกตัวใหม่ เพราะเมื่อ secret ออกจากการควบคุมแล้วถือว่า compromised จากนั้นค่อยย้าย secrets ไป environment variables และล้าง git history หากเคย commit

ถ: การ mask ผลลัพธ์ทำให้ตรวจสอบยากขึ้นไหม?

ตอบ: ไม่ เพราะ mask แสดงส่วนต้นและท้ายของค่าไว้พอให้ระบุประเภทและตำแหน่งได้ คุณจึงรีวิวและจับภาพหน้าจอได้อย่างปลอดภัยโดยไม่เปิดเผยค่าจริง

ถ: มันแยก JWT ออกจาก API key ทั่วไปอย่างไร?

ตอบ: JWT มีรูปแบบเฉพาะคือขึ้นต้นด้วย eyJ จากการ base64 encode ส่วน header เครื่องมือจึงมี pattern แยกสำหรับ JWT หากต้องการวิเคราะห์เนื้อหาข้างในต่อ ให้ใช้ JWT Decoder

ถ: เครื่องมือนี้แทน secret scanning ใน CI ได้ไหม?

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