กัน API key หลุดบน GitHub: Push Protection ข้ามไฟล์เกิน 50 MB

หากต้องการกัน API key หรือ token ไม่ให้ถูกส่งเข้า GitHub ให้เปิด Push Protection ทั้งในบัญชีของผู้ส่งโค้ดและใน repository ที่ทีมดูแล การป้องกันทำงานกับรูปแบบข้อมูลลับที่ระบบรองรับ โดยขอบเขตการตรวจของ GitHub ระบุว่าการ push ไปยัง repository สาธารณะที่มีขนาดเกิน 50 MB จะถูกข้ามการสแกน เกณฑ์นี้อ้างถึงขนาดของการ push ทั้งชุด ไม่ใช่ขนาดไฟล์แต่ละไฟล์

ในบัญชี ให้ไปที่รูปโปรไฟล์ → Settings → Code security แล้วดู Push protection for yourself ส่วนผู้ดูแลโครงการไปที่ repository → Settings → Advanced Security เปิด Secret Protection แล้วเปิด Push protection การตั้งค่าระดับบัญชีครอบคลุมการ push ของเจ้าของบัญชีไปยัง repository สาธารณะ ขณะที่การตั้งค่าระดับ repository ใช้กับผู้ร่วมพัฒนาที่ส่งโค้ดเข้าคลังนั้น จึงควรตรวจสถานะทั้งสองระดับก่อนถือว่าทีมได้รับการป้องกัน

เปิดการป้องกันในบัญชีของผู้ส่งโค้ด

Push protection for users บน GitHub.com เปิดเป็นค่าเริ่มต้นสำหรับการส่งข้อมูลลับที่รองรับไปยัง repository สาธารณะ แต่เจ้าของบัญชีอาจเคยปิดไว้เอง วิธีจัดการการป้องกันระดับบัญชี ระบุเมนู Settings → Code security และรายการ Push protection for yourself ไว้โดยตรง การตรวจสถานะก่อนเริ่มงานจึงสำคัญกว่าการสมมติว่าค่าเริ่มต้นยังอยู่เหมือนเดิม

1. ลงชื่อเข้า GitHub ด้วยบัญชีที่จะใช้ push แล้วคลิกรูปโปรไฟล์มุมขวาบน จากนั้นเลือก Settings
2. ในแถบด้านข้างหัวข้อ Security เลือก Code security
3. ใต้หัวข้อ User มองหา Push protection for yourself หากปุ่มที่แสดงคือ Enable ให้กดเปิด หากแสดง Disable แปลว่าการป้องกันกำลังเปิดอยู่

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

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

เปิด Push protection ให้ repository ของทีม

ผู้ดูแล repository เจ้าขององค์กร ผู้จัดการความปลอดภัย หรือผู้มีสิทธิ์ admin สามารถเปิดฟีเจอร์นี้ได้ ขั้นตอนเปิด Push protection ของ repository กำหนดให้เปิด Secret Protection ก่อนหากยังไม่เปิด แล้วจึงเปิด Push protection ในส่วนเดียวกัน เมื่อเปิดแล้ว การบล็อกผูกกับ repository จึงครอบคลุมการส่งของผู้ร่วมพัฒนาที่มีสิทธิ์เขียน และการข้ามการบล็อกจะสร้างรายการแจ้งเตือน

1. เปิดหน้าแรกของ repository ที่ต้องการป้องกัน แล้วเลือก Settings ใต้ชื่อ repository หากไม่เห็นแท็บนี้ ให้เปิดเมนูเพิ่มเติมเพื่อหา Settings
2. ในแถบด้านข้างส่วน Security and quality เลือก Advanced Security
3. ในหน้า Advanced Security มองหารายการ Secret Protection หากยังปิด ให้เลือก Enable และตรวจเงื่อนไขที่ระบบแสดงกับ repository ของคุณ
4. ในส่วน Secret Protection เลือก Enable ข้าง Push protection แล้วกลับมาตรวจสถานะว่าเปิดใช้งานจริง

หากมองไม่เห็น Settings ให้ตรวจสิทธิ์ของบัญชีใน repository ก่อน หากเห็น Settings แต่เปิด Secret Protection ไม่ได้ ให้ตรวจนโยบายขององค์กรและสิทธิ์ใช้ฟีเจอร์ของ repository นั้น เพราะการตั้งค่าระดับ repository อาศัย Secret Protection ส่วนการเปิดระดับบัญชีไม่ได้ทำให้ตัวเลือกนี้พร้อมใช้งานในทุกคลัง การแยกสาเหตุสองกรณีนี้ช่วยให้ขอสิทธิ์จากผู้ดูแลได้ตรงจุด

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

เมื่อการ push ถูกบล็อก ให้แยกคีย์จริงออกจากผลบวกลวง

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

• เป็นคีย์ที่ใช้ได้จริง: หยุดการส่ง แยกค่าออกจากไฟล์ที่ติดตามด้วย Git และแก้ทุก commit ที่มีค่านั้นก่อน push ใหม่ หากคีย์เคยอยู่บน GitHub หรือช่องทางอื่นแล้ว ให้เพิกถอนหรือหมุนคีย์กับผู้ให้บริการทันที การแก้ไฟล์ใน commit ใหม่อย่างเดียวทิ้งค่าเดิมไว้ในประวัติที่กำลังส่ง
• เป็นผลบวกลวง: ยืนยันก่อนว่าสตริงนั้นใช้ยืนยันตัวตนไม่ได้ แล้วเปิด URL ที่ GitHub ให้หลังการบล็อกด้วยบัญชีที่ push เลือก It's a false positive พร้อมเหตุผลตรงตามข้อเท็จจริง หาก repository เปิดการป้องกันไว้ GitHub จะสร้างรายการแจ้งเตือนที่ปิดด้วยเหตุผลนี้
• เป็นค่าทดสอบที่ปลอดภัย: ตรวจว่าค่าทดสอบไม่มีสิทธิ์ใช้กับระบบจริงและไม่ได้เชื่อมกับบัญชีที่มีข้อมูลสำคัญ หากจำเป็นต้องเก็บไว้ในโค้ด ให้ใช้เหตุผล It's used in tests แทนการระบุว่าระบบตรวจผิด เพื่อให้ผู้ดูแลแยกข้อมูลทดสอบออกจากผลบวกลวงได้
• เป็นคีย์จริงแต่ต้องการ bypass: ตัวเลือก I'll fix it later ทำให้รายการแจ้งเตือนยังเปิดอยู่ จึงไม่ควรใช้เป็นทางลัดให้การส่งผ่าน ถ้าองค์กรจำกัดสิทธิ์การข้าม ผู้ส่งต้องขออนุมัติจากผู้ตรวจที่กำหนดหรือเอาคีย์ออกจาก commit ก่อน

หากคีย์อยู่ใน commit ล่าสุดที่ยังไม่ส่ง ให้แก้ไฟล์ แล้วใช้คำสั่ง git commit --amend --all เพื่อแก้ commit เดิมก่อน git push อีกครั้ง หากคีย์ปรากฏใน commit ก่อนหน้า ต้องแก้ประวัติสาขา เช่น เลือกแก้ commit ด้วย interactive rebase และตรวจว่าทุกตำแหน่งถูกลบแล้ว การเพิ่ม commit ที่ลบข้อความออกเฉพาะไฟล์ปัจจุบันไม่ช่วย เพราะ Git ยังส่ง commit เก่าที่มีคีย์ไปด้วย

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

สำหรับการข้ามการบล็อกจาก command line ต้องเปิดลิงก์ที่ระบบคืนให้ด้วยบัญชีเดียวกับที่ push แล้วกลับไปสั่ง push อีกครั้งหลังเลือกเหตุผล หากทีมใช้ delegated bypass ผู้ส่งที่ไม่มีสิทธิ์จะเห็นช่องทางส่งคำขอให้ผู้ตรวจอนุมัติ การอนุมัติควรยึดความสามารถของค่านั้นในการเข้าถึงระบบ ไม่ใช่เพียงความเร่งด่วนของงาน เพราะเมื่อส่งสำเร็จ ข้อมูลจะอยู่ในคลังและอาจถูกคัดลอกต่อได้

ขอบเขตการตรวจที่ทำให้คีย์บางชนิดผ่านไปได้

Push Protection จับเฉพาะรูปแบบที่ระบบระบุได้เพียงพอสำหรับการบล็อก แม้ secret scanning จะรู้จักข้อมูลลับหลายชนิด แต่ฟีเจอร์ป้องกันขณะ push ใช้เพียงชุดย่อยที่มีโอกาสเตือนผิดต่ำ token รุ่นเก่าบางแบบและคีย์ที่องค์กรออกเองอาจไม่ตรงรูปแบบที่รองรับ จึงไม่ควรตีความว่าการ push ที่ผ่านเท่ากับไฟล์ไม่มีความลับ

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

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

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

เก็บคีย์นอก Git และตรวจซ้ำก่อนรวมโค้ด

ชั้นป้องกันที่ลดความเสี่ยงได้ตั้งแต่ต้นคือไม่ใส่ค่าจริงในไฟล์ที่ Git ติดตาม ให้เก็บคีย์ของแอปไว้ใน secret manager หรือระบบจัดการข้อมูลลับของสภาพแวดล้อม แล้วให้บริการอ่านค่าเมื่อทำงาน กำหนดสิทธิ์เฉพาะงานที่ต้องใช้ และเตรียมวิธีหมุนคีย์เมื่อผู้ถือสิทธิ์เปลี่ยน การแยกที่เก็บนี้ลดโอกาสที่ค่าจริงจะหลุดผ่าน source code, ไฟล์ตัวอย่าง หรือ commit เก่า

ถ้า workflow ใน GitHub Actions ต้องใช้คีย์ ให้ตั้งค่าเป็น Actions secret ในขอบเขต repository, environment หรือ organization ตามการใช้งาน แล้วอ้างอิงผ่าน secrets context ใน workflow แทนการวางค่าลงใน YAML โดยตรง ตัวแปรธรรมดาใน workflow เหมาะกับค่าที่ไม่ลับ ส่วนคีย์ที่เข้าถึงบริการภายนอกควรอยู่ในช่องทางสำหรับ secrets และจำกัดสิทธิ์ของ workflow ให้เท่าที่ต้องใช้

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

ตั้งการสแกนข้อมูลลับใน CI ให้ตรวจ pull request และหยุดการรวมโค้ดเมื่อพบรูปแบบที่ต้องแก้ โดยกำหนดผู้รับผิดชอบพิจารณาผลบวกลวงและวิธีอนุมัติข้อยกเว้น รูปแบบคีย์เฉพาะองค์กรอาจเพิ่มเป็น custom pattern ของ GitHub หรือกฎในเครื่องมือสแกนที่ทีมใช้อยู่ แล้วทดสอบกฎกับตัวอย่างที่ปลอดภัยก่อนเปิดบังคับจริง เพื่อให้การแจ้งเตือนจับสิ่งสำคัญโดยไม่รบกวนงานปกติเกินจำเป็น

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

อ่านเพิ่มเติม:

• GitHub Actions หรือ GitLab CI: นาทีถูกกว่าอาจสร้างเสร็จช้ากว่า