เปิด Push Protection ใน GitHub: ปุ่มข้ามต้องมีคนตรวจ ไม่ใช่ทางลัด

ผู้ดูแล repository เปิด Push Protection ได้ที่ Settings → Advanced Security โดยเปิด Secret Protection ก่อน แล้วเปิด Push protection ในส่วนเดียวกัน คู่มือเริ่มต้นของ GitHub แยกการสแกน secret ออกจากการป้องกันระหว่าง push จึงควรตรวจว่าสวิตช์ทั้งสองส่วนเปิดตามที่ต้องการ เมื่อระบบพบ secret ชนิดที่รองรับใน commit ที่กำลังส่ง ระบบจะบล็อก push ก่อนข้อมูลเข้าสู่ repository

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

เลือกทางเปิดตาม repository และแผนบัญชี

Repository สาธารณะใช้ความสามารถด้าน Secret Protection ได้ ส่วน repository ส่วนตัวหรือภายในที่องค์กรเป็นเจ้าของต้องอยู่ในองค์กรที่ใช้ GitHub Secret Protection หรือ GitHub Advanced Security ตามสิทธิ์ของแผน Team หรือ Enterprise Cloud ก่อน ผู้ดูแล repository ส่วนตัวที่ไม่เห็นตัวเลือกจึงควรตรวจสิทธิ์ระดับองค์กรและสถานะการเปิดผลิตภัณฑ์ก่อน การมีสิทธิ์แก้โค้ดเพียงอย่างเดียวไม่ได้ให้สิทธิ์เปลี่ยนการตั้งค่าความปลอดภัย

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

เปิดใน repository เดียว

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

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

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

ใช้ security configuration กับองค์กรและ enterprise

สำหรับหลาย repository ให้ผู้ดูแลองค์กรเข้า Settings → Advanced Security → Configurations แล้วสร้าง custom security configuration หรือแก้รายการเดิม ภายใต้ Secret scanning ตั้ง Push protection เป็น Enabled จากนั้นบันทึกและนำ configuration ไปใช้กับ repository เป้าหมาย การบันทึกอย่างเดียวไม่ครอบคลุม repository ที่ยังไม่ได้รับ configuration จึงต้องตรวจรายชื่อเป้าหมายและสถานะหลังนำไปใช้ด้วย

ในระดับ enterprise เส้นทางเริ่มที่ Settings ของ enterprise แล้วเข้า Advanced Security → Configurations เปิด Push protection ใน configuration ก่อนบันทึกและนำไปใช้กับองค์กรและ repository ที่ต้องการ วิธีระดับบนช่วยให้หลายทีมใช้หลักเกณฑ์เดียวกัน แต่ขอบเขตการใช้ยังขึ้นอยู่กับการมอบ configuration จริง หากองค์กรเพิ่ม repository ใหม่ภายหลัง ผู้ดูแลควรตรวจว่ากฎการนำ configuration ไปใช้ครอบคลุม repository ใหม่นั้นหรือไม่

การเลือกจุดตั้งนโยบาย bypass มีผลต่อผู้ดูแลแต่ละ repository หากเจ้าขององค์กรหรือ enterprise ตั้ง delegated bypass จากระดับนั้น การแก้ตัวเลือก bypass ในระดับ repository จะถูกปิด ผู้ดูแลจึงควรตัดสินใจก่อนว่าทีมรักษาความปลอดภัยส่วนกลางหรือเจ้าของ repository เป็นผู้กำหนดรายชื่อผู้ตรวจ การกำหนดจากส่วนกลางเหมาะเมื่อองค์กรต้องการหลักเกณฑ์เดียวกัน ส่วนการกำหนดราย repository ช่วยให้ทีมที่รู้บริบทของคีย์รับผิดชอบคำขอของตน

กำหนดสิทธิ์ bypass ให้ตรงกับหน้าที่ผู้ตรวจ

ใน repository ที่เปิด Push Protection แล้ว ให้ไปที่ช่อง Who can bypass push protection for secret scanning เลือก Specific roles or teams และเพิ่มบทบาทหรือทีมใน Bypass list ผู้ที่อยู่ในรายชื่อนี้มีสิทธิ์ข้ามการบล็อก จึงไม่ควรเพิ่มทุกคนที่มีสิทธิ์ push หากต้องการให้การข้ามต้องผ่านการพิจารณา ให้จำกัดรายชื่อไว้กับผู้รับผิดชอบตรวจคำขอ และตรวจว่าทีมดังกล่าวรู้วิธีตัดสินกรณีคีย์จริง ค่าทดสอบ และผลตรวจผิด

ที่ระดับองค์กรหรือ enterprise ให้ตั้ง Bypass privileges เป็น Specific actors ใน security configuration เดียวกับที่เปิด Push protection เลือกผู้มีสิทธิ์ แล้วบันทึกและนำ configuration ไปใช้ องค์กรยังมอบสิทธิ์ Review and manage secret scanning bypass requests ผ่าน custom organization role ให้สมาชิกหรือทีมที่ทำหน้าที่ตรวจคำขอได้ ผู้ตรวจควรพิจารณาจากชนิดของค่า repository ตำแหน่งใน commit และเหตุผลของผู้ขอ ไม่ใช่จากความเร่งด่วนของงานเพียงอย่างเดียว

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

เมื่อ push ถูกบล็อก ให้ตัดสินจากสถานะของค่า

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

• คีย์จริงที่ยังไม่เคยเข้า remote: นำค่าออกจากทุก commit ที่กำลัง push แล้วเก็บค่าที่โปรแกรมต้องใช้ในตัวจัดการ secret หรือส่งผ่านสภาพแวดล้อม หากค่าอยู่ใน commit ล่าสุด ให้แก้ไฟล์และแก้ commit เดิมด้วย git commit --amend --all ก่อน push ใหม่ หากอยู่ใน commit ก่อนหน้า ให้แก้ประวัติ branch ด้วย interactive rebase โดยเริ่มจาก commit ที่ใส่ค่าเข้ามา ตรวจผลหลังแก้ก่อนส่งซ้ำ
• ค่าจำลองที่ใช้ทดสอบหรือผลตรวจผิด: ตรวจให้แน่ว่าค่านั้นใช้เข้าถึงบริการจริงไม่ได้ และระบุเหตุผลให้ผู้ตรวจประเมินได้ หากจำเป็นต้องเก็บไว้ใน repository จึงค่อยยื่นคำขอ bypass โดยแยกกรณีใช้ใน tests ออกจากกรณีที่สตริงไม่ใช่ secret อย่าเลือกเหตุผลว่าจะกลับมาแก้ภายหลังแทนการพิสูจน์ว่าค่าปลอดภัย
• คีย์จริงที่เคยเผยแพร่แล้ว: ติดต่อเจ้าของบริการเพื่อเพิกถอนหรือหมุนคีย์ จัดการระบบที่ยังพึ่งพาค่าเดิม และตรวจว่ามีสำเนาอยู่ใน branch, fork หรือ clone อื่นหรือไม่ การแก้ commit ที่กำลัง push จะช่วยหยุดการเผยแพร่รอบใหม่ แต่ไม่เรียกคืนสำเนาที่คนอื่นอาจได้รับไปแล้ว

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

ถ้าคีย์เข้าสู่ประวัติ Git แล้ว

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

หากจำเป็นต้องลบค่าออกจากประวัติ ให้ระบุ branch และ tag ที่ได้รับผลกระทบ ประสานผู้ร่วมงานก่อนอัปเดต remote และเตรียมให้ทุกคนจัดการ clone ของตน การเขียนประวัติใหม่เปลี่ยน commit hash อาจกระทบ pull request ลายเซ็น commit และกฎ branch protection ผู้ร่วมงานที่ push ประวัติเก่ากลับขึ้นมาอาจนำ secret กลับเข้าคลังได้อีก จึงต้องวางลำดับงานร่วมกันก่อนดำเนินการ

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

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

• กัน API key หลุดบน GitHub: Push Protection ข้ามไฟล์เกิน 50 MB
• ต่อ GitHub Actions เข้า AWS ด้วย OIDC: จำกัดสิทธิ์ถึง repo และ branch
• DigitalOcean เปิด Managed Agents แต่ Public Preview ยังไม่มี SLA