นโยบายที่เก็บ Git ที่เชื่อถือได้
การควบคุมการเข้าถึงคลัง Git ใช้กำหนดขอบเขตคลังที่เชื่อถือได้สำหรับอุปกรณ์ Windows และบันทึกการเข้าถึงคลังด้วย Git มาตรฐานที่ระบุได้ เมื่ออุปกรณ์ระบุคลังที่ไม่เชื่อถือ จะพยายามยุติโพรเซส Git ที่เกี่ยวข้อง การตรงกฎ การยุติโพรเซส และการดำเนินการกับคลังเสร็จสิ้นเป็นผลต่างกัน จึงต้องตรวจสอบแยกกัน
ฟังก์ชันนี้ไม่รับประกันว่าครอบคลุมไคลเอนต์ Git คำสั่งหรือวิธีส่งข้อมูลทั้งหมด และไม่ทดแทนสิทธิ์คลัง เครือข่ายหรือการควบคุมความปลอดภัยข้อมูลอื่น
การเตรียมการ
- ใช้บัญชีที่มีสิทธิ์จัดการนโยบายป้องกันข้อมูลรั่วไหลเพื่อตั้งค่า การดูบันทึกที่เกี่ยวข้องต้องมีสิทธิ์ดูที่เหมาะสม และให้ผู้มีสิทธิ์ตรวจสอบได้ ตรวจสอบการเชื่อมต่อและสิทธิ์ใช้งานของอุปกรณ์Windows นำร่อง รวมถึงขอบเขตที่ผู้ดูแลมองเห็น
- รวบรวมที่อยู่ โพรโทคอลและพอร์ตของคลังที่ธุรกิจต้องใช้ แยกการอนุญาตคลังเดียวออกจากทั้งเนมสเปซ อย่าใส่รหัสผ่านหรือโทเคนเข้าถึงในที่อยู่คลัง สิทธิ์บัญชียังอยู่ภายใต้บริการ Git
- เตรียมเป้าหมายทดสอบที่เชื่อถือและไม่เชื่อถือซึ่งได้รับอนุญาต ใช้บัญชีทดสอบและเนื้อหาที่ไม่อ่อนไหว นโยบายอาจขัดจังหวะการพัฒนาหรือสร้างโปรแกรม จึงควรทดลองบนอุปกรณ์ที่กู้คืนได้จำนวนน้อยและเตรียมแผนย้อนกลับ
กำหนดคลังที่เชื่อถือได้
- เปลี่ยนไปที่ DLP เปิดหน้าแอปพลิเคชัน เข้า Git Repository Access Control แล้วเลือกนโยบายคลังที่เชื่อถือได้ ในหน้าภาษาอังกฤษ แท็บนี้ชื่อ Trusted Repository Policies
- สร้างหรือแก้ไขนโยบาย กรอกชื่อ ตรวจเวลาเริ่มมีผลและอุปกรณ์ กลุ่มหรือแท็กที่ใช้ โดยเริ่มจากขอบเขตนำร่อง
- เพิ่มคลังในรายการคลังที่เชื่อถือได้ สำหรับแต่ละกฎให้เลือกคลังแบบเจาะจงหรือเนมสเปซของคลังและกรอกที่อยู่ นโยบายหนึ่งต้องมีกฎที่ถูกต้อง 1 ถึง 500 ข้อ และไม่ควรเพิ่มกฎซ้ำ ในหน้าภาษาอังกฤษ เลือก Add Repository ใน Trusted Repositories แล้วเลือกชนิดกฎ Exact Repository หรือ Repository Namespace
- ตรวจโพรโทคอล โฮสต์ พอร์ตและเส้นทาง สามารถกรอกที่อยู่ HTTP, HTTPS, SSH, Git หรือรูปแบบย่อ SSH ที่ใช้ทั่วไป โพรโทคอลต่างกันไม่ถือว่าเท่ากันโดยอัตโนมัติ และพอร์ตที่ไม่ใช่ค่าเริ่มต้นมีผลต่อการจับคู่
- บันทึกนโยบายทั้งหมดและรอให้อุปกรณ์นำร่องรับ ทดสอบเป้าหมายที่เชื่อถือและไม่เชื่อถือแยกกัน แล้วตรวจผลจับคู่และผลดำเนินการในบันทึกการเข้าถึง เมื่อผ่านการตรวจสอบจึงขยายตามกระบวนการเปลี่ยนแปลงขององค์กร
ที่อยู่ต่อไปนี้เป็นเพียงตัวอย่าง ไม่ใช่ขอบเขตเชื่อถือเริ่มต้น
| กฎ | ตัวอย่าง | ขอบเขต |
|---|---|---|
| คลังแบบเจาะจง | https://git.example.com/team/project.git |
ตรงกับคลังนี้ ไม่ครอบคลุมคลังอื่นของทีมโดยอัตโนมัติ |
| เนมสเปซของคลัง | https://git.example.com/team |
ตรงกับเส้นทางนี้และเส้นทางย่อย ไม่จับคู่ระดับเส้นทางอื่นเพียงเพราะชื่อขึ้นต้นคล้ายกัน |
ตัวอย่างเช่น อย่าสมมติว่ากฎ HTTPS ครอบคลุมที่อยู่ SSH ของโฮสต์เดียวกัน หากธุรกิจใช้ทั้งสองวิธีให้กำหนดและทดสอบแยกกัน เนมสเปซมักมีขอบเขตกว้างกว่าคลังเดียว จึงต้องตรวจว่าตรงกับข้อกำหนดองค์กรก่อนบันทึก
ข้อควรระวังในการจับคู่ที่อยู่: เมื่อโพรโทคอล โฮสต์และพอร์ตตรงกัน การจับคู่จะละ .git ที่ท้ายเส้นทางคลัง ชื่อโฮสต์ไม่แยกตัวพิมพ์ใหญ่เล็ก แต่เส้นทางคลังแยก ตัวอย่างเช่น team/project.git กับ team/project ตรงเป็นเส้นทางเดียวกัน แต่อย่าสมมติว่า team/Project กับ team/project เหมือนกัน ให้ทดสอบกับที่อยู่บริการจริงแยกกัน
ข้อจำกัดและการแก้ไขปัญหา
ขอบเขต: การดำเนินการเครือข่าย Git มาตรฐานที่ระบุได้รวม
clone,fetch,pullและpushคำสั่ง ตัวเลือก ไคลเอนต์และ Git LFS แต่ละแบบต้องทดสอบนำร่องแยกกัน การไม่มีบันทึกไม่พิสูจน์ว่าไม่มีการเข้าถึงระบุเป้าหมายไม่ได้: หากวิเคราะห์เป้าหมายบางแบบไม่ได้ ระบบจะไม่ปิดกั้นโดยจัดเป็นคลังไม่เชื่อถือ ต้องใช้ร่วมกับมาตรการอื่น และไม่ถือว่าฟังก์ชันนี้รับประกันการควบคุมการส่งออกทั้งหมด
การเข้าถึงคลังไม่เชื่อถือไม่ถูกปิดกั้น: ตรวจว่าเป้าหมายจริงถูกระบุหรือไม่ ผลจับคู่และผลดำเนินการของโพรเซส การยุติอาจล้มเหลวหรือโพรเซสอาจออกไปแล้ว แม้ยุติสำเร็จก็ไม่อาจสรุปจากบันทึกว่าไม่มีการสื่อสารหรือส่งข้อมูลก่อนหน้านั้น
คลังที่เชื่อถือได้รับผลกระทบ: ตรวจการส่งนโยบายและโพรโทคอล พอร์ตกับเส้นทางจริง ตรวจการเขียนที่อยู่คลังใหม่และขอบเขตเนมสเปซ หลังปรับให้ทดสอบทั้งกรณีอนุญาตและจำกัด
หาบันทึกไม่พบ: ตรวจสถานะอุปกรณ์และนโยบาย สิทธิ์ ขอบเขตบัญชี เวลาและตัวกรอง รอการรายงานแล้วลองอีกครั้ง หากงานพัฒนาปกติได้รับผลกระทบให้คืนงานตามกระบวนการองค์กรก่อนตรวจขอบเขตนโยบาย
วันที่อัปเดต