คุณต้องการนโยบายควบคุมการเข้าถึงแบบใด?

เหตุใดนักพัฒนาจึงต้องการนโยบายควบคุมการเข้าถึงที่ใช้งานได้จริง (ไม่ใช่แค่ทฤษฎี)

หากคุณกำลังอัปโหลดโค้ดหรือดูแลรักษาระบบ pipelineหรือการจัดการรีจิสทรีของอาร์ติแฟกต์ คุณต้องการมากกว่าแค่ทฤษฎี นโยบายการควบคุมการเข้าถึงที่อ่อนแอหรือไม่ชัดเจนอาจเปิดช่องให้มีการปลอมแปลงคลังเก็บข้อมูลได้ CI/CD การล่วงละเมิด และ การรั่วไหลของข้อมูลประจำตัวDevSecOps ต้องการการบังคับใช้ที่แท้จริง ไม่ใช่แค่การตั้งค่าสิทธิ์ที่ซ่อนไว้

เพื่อจัดการนโยบายการควบคุมการเข้าถึงในคลังเก็บโค้ดได้อย่างมีประสิทธิภาพ CI/CD pipelinesและในการจัดการรีจิสทรีของอาร์ติแฟกต์ ทีมงานจำนวนมากพึ่งพาเครื่องมือบังคับใช้แบบอัตโนมัติ เช่น Xygeni โดยการตรวจสอบบทบาท สิทธิ์ และการปฏิบัติตามนโยบายอย่างต่อเนื่อง Xygeni ช่วยป้องกันการเปลี่ยนแปลงสิทธิ์ การเข้าถึงที่ไม่ได้รับอนุญาต และการแก้ไขด้วยตนเอง ทำให้ทฤษฎีการควบคุมการเข้าถึงที่บังคับใช้กลายเป็นการปฏิบัติจริง

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

ประเภทของนโยบายการควบคุมการเข้าถึงที่นักพัฒนาควรรู้

นโยบายการควบคุมการเข้าถึงแบ่งออกเป็นสามประเภทหลัก ซึ่งแต่ละประเภทมีความเหมาะสมแตกต่างกันไป CI/CD ขั้นตอนการทำงาน ต่อไปนี้เป็นการเปรียบเทียบแบบคร่าวๆ เพื่อให้เข้าใจชัดเจนยิ่งขึ้น:

รุ่น	ใครเป็นผู้ควบคุมการเข้าถึง?	การใช้งานทั่วไปใน CI/CD	ระดับความเสี่ยง
DAC (ระบบควบคุมการเข้าถึงตามดุลยพินิจ)	เจ้าของทรัพยากร (นักพัฒนา, ผู้ดูแลระบบ)	การแชร์สิทธิ์การเข้าถึง repository หรือ registry ด้วยตนเอง	สูง (ความผิดพลาดของมนุษย์)
RBAC (การควบคุมการเข้าถึงตามบทบาท)	ระบบจะกำหนดสิทธิ์ตามบทบาท	การปกป้องสาขา GitHub และการเข้าถึงงาน CI ตามบทบาทของผู้ใช้	ระดับปานกลาง (การตั้งค่าบทบาทไม่ถูกต้อง)
MAC (ระบบควบคุมการเข้าถึงภาคบังคับ)	บังคับใช้โดยนโยบายของระบบ	กำหนดว่าใครบ้างที่มีสิทธิ์เผยแพร่ผลงานหรือปรับใช้โค้ด	ต่ำ (นโยบายมีผลเหนือกว่าความตั้งใจของผู้ใช้)

การชี้แจงความแตกต่างระหว่าง MAC กับ RBAC ใน CI/CD บริบท

การควบคุมการเข้าถึงตามบทบาทอาจทำให้เกิดความสับสนได้ง่าย (อาร์แบค) ที่มีการควบคุมการเข้าถึงแบบบังคับ (การควบคุมการเข้าถึง MAC) โดยเฉพาะใน CI/CD สภาพแวดล้อม ในขณะที่ CI/CD แพลตฟอร์มอย่าง GitHub และ GitLab ใช้ RBAC ในการจัดการบทบาทและสิทธิ์ (เช่น ใครสามารถผสานหรือปรับใช้โค้ดได้) ซึ่งโดยพื้นฐานแล้วยังคงเป็นการควบคุมตามบทบาท ไม่ใช่การควบคุมการเข้าถึงตาม MAC อย่างแท้จริง

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

ในทางตรงกันข้าม การควบคุมการเข้าถึงแบบบังคับ (MAC access control) จะถูกบังคับใช้ในระดับระบบหรือโครงสร้างพื้นฐาน ผู้ใช้ รวมถึงผู้ดูแลระบบ ไม่สามารถยกเลิกได้ ลองนึกถึงการควบคุมการเข้าถึงแบบ MAC ว่าเป็นนโยบายที่ฝังอยู่ในแพลตฟอร์ม เช่น นโยบาย IAM ในผู้ให้บริการคลาวด์ (เช่น AWS IAM, GCP IAM) หรือเครื่องมือบังคับใช้ระดับระบบปฏิบัติการ เช่น SELinux หรือ AppArmor ในกรณีเหล่านี้ การเข้าถึงจะได้รับอนุญาตก็ต่อเมื่อตรงตามกฎที่กำหนดไว้ล่วงหน้าและไม่สามารถหลีกเลี่ยงได้เท่านั้น

In CI/CDเครื่องมือหลายอย่างจำลองพฤติกรรมการควบคุมการเข้าถึง MAC ผ่านบทบาท IAM ที่จำกัดขอบเขตอย่างเข้มงวด หรือสิทธิ์เฉพาะทรัพยากร แต่สิ่งนี้ไม่ใช่การควบคุมการเข้าถึงแบบบังคับอย่างสมบูรณ์ การบังคับใช้การควบคุมการเข้าถึงแบบบังคับอย่างแท้จริงนั้นต้องอาศัยการควบคุมที่อยู่ต่ำกว่าเลเยอร์แอปพลิเคชัน ในระดับระบบปฏิบัติการ เครือข่าย หรือโครงสร้างพื้นฐานคลาวด์ ซึ่งการเข้าถึงจะถูกควบคุมโดยนโยบายการควบคุมการเข้าถึงที่ไม่สามารถเปลี่ยนแปลงได้ ไม่ใช่การกำหนดค่าโดยมนุษย์

การควบคุมการเข้าถึงตามบทบาท (RBAC)

RBAC จะแมปสิทธิ์การเข้าถึงกับบทบาทที่กำหนดไว้ เช่น “นักพัฒนา” “ผู้ดูแลระบบ” หรือ “ผู้จัดการการเผยแพร่” ซึ่งช่วยให้การจัดการในเครื่องมือต่างๆ เช่น GitHub ง่ายขึ้น GitLabแทนที่จะกำหนดค่าทีละผู้ใช้ ให้กำหนดบทบาทให้กับผู้ใช้แต่ละคน แล้วปล่อยให้ระบบบังคับใช้กฎเหล่านั้น

ตัวอย่าง: ไฟล์ GitHub CODEOWNERS

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

การตั้งค่าบทบาทใน GitLab: กำหนดค่าการเข้าถึงโปรเจ็กต์ใน การตั้งค่า > สมาชิก:

ผู้พัฒนา: สามารถพุชไปยัง feature branches ได้
ผู้ดูแล: สามารถผสานรวมเข้ากับสาขาที่ได้รับการป้องกันได้
แขก: สิทธิ์การเข้าถึงแบบอ่านอย่างเดียว

ตัวอย่างการใช้งาน RBAC ในเวิร์กโฟลว์ GitHub Actions:

การควบคุมการเข้าถึงบังคับ (MAC)

การควบคุมการเข้าถึงแบบบังคับ (MAC access control) บังคับใช้กฎระดับระบบที่เข้มงวด ซึ่งผู้ใช้และผู้ดูแลระบบไม่สามารถเปลี่ยนแปลงได้ ใช้งานการควบคุมการเข้าถึงแบบ MAC เพื่อควบคุมอย่างเข้มงวดว่าใครบ้างที่มีสิทธิ์อ่าน เขียน หรือใช้งานทรัพยากรที่สำคัญ

ตัวอย่าง: นโยบายการลงทะเบียนสิ่งประดิษฐ์ของ Google (รูปแบบ YAML แบบง่าย)

นโยบายนี้ให้สิทธิ์ในการเขียนเฉพาะกับบัญชีบริการ ci-deployer เท่านั้น เพื่อให้มั่นใจว่าเฉพาะงาน CI ที่มีข้อมูลประจำตัวนี้เท่านั้นที่จะสามารถพุชอาร์ติแฟกต์ได้

ตัวอย่าง: นโยบาย ECR ของ Amazon (รูปแบบ YAML แบบง่าย)

นโยบายนี้ปฏิเสธการดำเนินการ PutImage ใดๆ บนที่เก็บข้อมูล ECR เว้นแต่จะดำเนินการโดยบัญชีบริการ ci-service-account เท่านั้น โดยจำกัดการอัปโหลดรูปภาพไว้เฉพาะบัญชีบริการนี้เท่านั้น

ความเสี่ยงของการแก้ไขด้วยตนเองและวิธีที่ MAC ป้องกันความเสี่ยงเหล่านั้น

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

การควบคุมการเข้าถึงแบบบังคับ (MAC access control) ป้องกันการละเมิดสิทธิ์ดังกล่าวโดยการบังคับใช้นโยบายระดับระบบที่ไม่มีผู้ใช้รายใด แม้แต่ผู้ดูแลระบบ ก็ไม่สามารถหลีกเลี่ยงได้cisไอออนต่างๆ ถูกควบคุมโดยกฎที่ไม่สามารถเปลี่ยนแปลงได้ซึ่งฝังอยู่ในโครงสร้างพื้นฐาน (เช่น นโยบาย IAM บนคลาวด์ หรือโมดูลความปลอดภัยระดับระบบปฏิบัติการ) ซึ่งหมายความว่า:

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

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

2.4 การควบคุมการเข้าถึงตามดุลยพินิจ (DAC)

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

ตัวอย่าง: นักพัฒนาเชิญผู้ร่วมงานภายนอกและให้สิทธิ์การเขียนไปยังที่เก็บโค้ด ผู้ร่วมงานได้ส่งโค้ดที่ไม่ปลอดภัยไปยังที่เก็บโค้ดโดยตรง dev สาขา.

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

วิธีเลือกนโยบายควบคุมการเข้าถึงที่ใช้งานได้จริง Pipelines

การควบคุมการเข้าถึงใน Git

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

ตัวอย่าง: กฎการป้องกันสาขาของ GitHub

ต้องการ pull request ตรวจสอบก่อนรวมไฟล์
ยกเลิกข้อมูลที่ล้าสมัย pull request การอนุมัติเมื่อใหม่ commitมีการผลักดัน
ต้องมีลายเซ็น commits.
หลีกเลี่ยงการใช้ DAC สำหรับ repository ที่มีความสำคัญต่อการผลิต อย่าให้สิทธิ์การเขียนอย่างไม่ระมัดระวัง

Pipeline การบังคับใช้

กำหนดให้มีการควบคุมการเข้าถึงแบบบังคับสำหรับ pipelineโมเดลการควบคุมการเข้าถึง Mac ที่มีประสิทธิภาพจะจำกัดงาน CI ให้เหลือเพียงสิทธิ์ที่จำเป็นเท่านั้น

แยกความลับตามสภาพแวดล้อม
ใช้โทเค็นที่ไม่ซ้ำกันสำหรับแต่ละสภาพแวดล้อม
ป้องกันไม่ให้การดำเนินการด้วยตนเองส่งผลกระทบต่อผลผลิต

ตัวอย่าง: งาน CI นำโทเค็นการปรับใช้มาใช้ซ้ำทั้งในสภาพแวดล้อมทดสอบและสภาพแวดล้อมใช้งานจริง ทำให้เผลอส่งโค้ดทดสอบไปยังสภาพแวดล้อมใช้งานจริงโดยไม่ตั้งใจ

เพิ่มกฎการควบคุมการเข้าถึง Mac เพื่อควบคุมขอบเขตของโทเค็น:

ตัวอย่างการกำหนดขอบเขตความลับ: การใช้งานโทเค็นเฉพาะสภาพแวดล้อม

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

ต่อไปนี้คือวิธีที่นโยบายการควบคุมการเข้าถึงช่วยแยกการใช้งานข้อมูลลับใน GitHub Actions:

สิ่งนี้ยืนยันว่า:

เพียง ผู้พัฒนา บทบาทนี้สามารถเรียกใช้การปรับใช้โดยใช้โทเค็นสำหรับนักพัฒนาบน dev สาขา.
เพียง ผู้จัดการการเผยแพร่ บทบาทนี้สามารถปรับใช้ไปยังระบบการผลิตได้โดยใช้โทเค็นการผลิตบน หลัก สาขา.

การใช้งานความลับในขอบเขตที่จำกัดเช่นนี้ ช่วยลดความเสี่ยงที่โทเค็นจะรั่วไหลไปยังสภาพแวดล้อมอื่นๆ และ บังคับใช้สิทธิขั้นต่ำใน CI/CD pipelines ปฏิบัติตามนโยบายควบคุมการเข้าถึงที่เข้มงวด

การควบคุมการเข้าถึงสิ่งประดิษฐ์

ปิดล็อกระบบจัดเก็บสิ่งประดิษฐ์โดยใช้การควบคุมการเข้าถึงแบบบังคับ CI/CD ระบบควรเป็นผู้จัดการการเผยแพร่ ไม่ใช่นักพัฒนาแต่ละคน

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

ข้อผิดพลาดทั่วไปในการควบคุมการเข้าถึงในเวิร์กโฟลว์การพัฒนา

การเข้าถึงคลังเก็บข้อมูลที่อนุญาตมากเกินไป

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

สิทธิ์การใช้งานร่วมกันระหว่างสภาพแวดล้อมการพัฒนาและการใช้งานจริง

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

การอัปโหลดอาร์ติแฟกต์ด้วยตนเอง

ปัญหา: อนุญาตให้ทำการอัปโหลดไฟล์อาร์ติแฟกต์ด้วยตนเองไปยังรีจิสทรีสำหรับการใช้งานจริง
มันเกิดขึ้นได้อย่างไร: นักพัฒนาข้ามขั้นตอน pipelineสำหรับแก้ไขปัญหาอย่างรวดเร็วหรือแพทช์ฉุกเฉิน
ช่องโหว่ของผู้โจมตี: เครื่องคอมพิวเตอร์ของนักพัฒนาที่ถูกบุกรุกสามารถอัปโหลดมัลแวร์ไปยังพื้นที่จัดเก็บไฟล์โดยตรง โดยไม่ต้องผ่านกลไกการตรวจสอบใดๆ CI/CD การตรวจสอบความปลอดภัย

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

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

ขั้นตอนปฏิบัติเพื่อบังคับใช้การควบคุมการเข้าถึงที่เข้มงวด

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

บทบาทของ Xygeni: การบังคับใช้และตรวจสอบนโยบายการเข้าถึงในเวิร์กโฟลว์ DevOps

ไซเกนี ช่วยให้คุณเปลี่ยนการควบคุมการเข้าถึงแบบบังคับจากทฤษฎีไปสู่การปฏิบัติจริง โดยการแก้ปัญหาความท้าทายในการบังคับใช้นโยบายการควบคุมการเข้าถึงในชีวิตประจำวันใน DevSecOps pipelines.

การแก้ไขปัญหาการเข้าถึง Git ที่มีสิทธิ์มากเกินไป: Xygeni ตรวจสอบ Git repository อย่างต่อเนื่องเพื่อหาการละเมิด RBAC เช่น การกำหนดบทบาทที่ไม่ได้รับการตรวจสอบ หรือการขาดการป้องกันสาขา มันจะแจ้งเตือนเมื่อนโยบายการควบคุมการเข้าถึงเบี่ยงเบนไปจากกฎที่กำหนดไว้ และบังคับใช้การแก้ไขเพื่อหลีกเลี่ยงการรวมโค้ดโดยไม่ได้ตั้งใจ หรือ Pull Request ที่เป็นอันตราย
การปิดเมือง CI/CD Pipelines: บางครั้งงาน CI ทำงานด้วยขอบเขตที่กว้างกว่าที่ตั้งใจไว้ Xygeni จะตรวจจับได้เมื่อเกิดเหตุการณ์เช่นนี้ CI/CD ตรวจสอบให้แน่ใจว่างานที่ได้รับมอบหมายนั้นเกินขอบเขตหรือดำเนินการเกินกว่าบทบาทที่ได้รับมอบหมาย ช่วยระบุการขยายขอบเขตงานและการใช้สิทธิ์โดยมิชอบแบบเรียลไทม์ ซึ่งจะช่วยบังคับใช้หลักการควบคุมการเข้าถึง MAC ภายในองค์กร pipelineโดยการจำกัดการเข้าถึงให้สอดคล้องกับตัวตนและวัตถุประสงค์ของงานอย่างเคร่งครัด
การบังคับใช้การควบคุมการเผยแพร่สิ่งประดิษฐ์: หากนักพัฒนาซอฟต์แวร์ยังคงอัปโหลดไฟล์หรือรูปภาพด้วยตนเอง Xygeni จะหยุดยั้งการกระทำนั้น โดยจะใช้การควบคุมการเข้าถึงแบบบังคับในระดับรีจิสทรี เพื่อให้เฉพาะไฟล์ที่ผ่านการตรวจสอบแล้วเท่านั้นที่สามารถเข้าถึงได้ pipeline ผู้ใช้งานสามารถเผยแพร่ผลงานได้แล้ว ไม่จำเป็นต้องอัปโหลดข้อมูลไปยังระบบจัดเก็บข้อมูลหลักโดยมนุษย์อีกต่อไป
การตรวจสอบการเข้าถึงและการแจ้งเตือนความผิดปกติ: ด้วย Xygeni คุณจะสามารถตรวจสอบได้ว่าใครเข้าถึงอะไร เมื่อไหร่ และอย่างไร ระบบจะติดตามการใช้งานข้อมูลลับ การเข้าถึงที่เก็บข้อมูล และการโต้ตอบกับรีจิสทรีอย่างต่อเนื่อง เพื่อตรวจจับพฤติกรรมที่ผิดปกติ ระบุการตั้งค่าที่ไม่ถูกต้อง และช่วยในการวิเคราะห์หลังเกิดเหตุการณ์

บรรทัดด้านล่าง: Xygeni นำเสนอระบบอัตโนมัติและการบังคับใช้สำหรับนโยบายการควบคุมการเข้าถึง เพื่อให้สภาพแวดล้อม DevOps ของคุณปลอดภัยโดยไม่ทำให้การทำงานช้าลง

คุณต้องการนโยบายควบคุมการเข้าถึงแบบใด? มาดูกันทีละส่วน

สารบัญ

บทความที่ต้องอ่าน

บทความล่าสุดที่น่าสนใจ