Active Directory (AD) เป็นผลิตภัณฑ์ของ Microsoft ที่ออกแบบมาเพื่อช่วยผู้ดูแลระบบเครือข่ายในการจัดการสิทธิ์ของผู้ใช้ภายในองค์กร โดยจะติดตั้งบน Windows Server ซึ่งจะเปลี่ยนให้เป็นตัวควบคุมโดเมนที่รับผิดชอบในการจัดการสภาพแวดล้อมขององค์กรและดำเนินการต่างๆ เช่น การจัดเก็บข้อมูลทั้งหมด บัญชีผู้ใช้, รหัสผ่านและการอนุญาต และการจัดการการตรวจสอบสิทธิ์ของผู้ใช้
เมื่อเวลาผ่านไป โลกกำลังเคลื่อนไปสู่การนำระบบคลาวด์มาใช้มากขึ้น และ Microsoft เองก็ผลักดันให้องค์กรต่างๆ เปลี่ยนมาใช้สภาพแวดล้อมบนคลาวด์เพื่อให้มีประสิทธิภาพและทันสมัยมากขึ้น การจัดการข้อมูลประจำตัวโซลูชันของ Microsoft สำหรับสภาพแวดล้อมโดเมนบนคลาวด์คือ Entra IDขยายความสามารถของ AD ในสถานที่ไปยังระบบคลาวด์ โดยมอบโซลูชันที่แข็งแกร่งสำหรับการจัดการข้อมูลประจำตัวและการเข้าถึงสำหรับแอปพลิเคชันบนระบบคลาวด์ เพื่อให้สามารถบูรณาการกับระบบเดิมที่รองรับได้อย่างราบรื่น Microsoft จึงได้เปิดตัว Entra ID เชื่อมต่อ เครื่องมือนี้ช่วยให้องค์กรเชื่อมโยงระบบภายในองค์กรของตน Active Directory (AD) สิ่งแวดล้อมด้วย Entra ID, การสร้าง “สภาพแวดล้อมแบบผสมผสานแบบไฮบริด”
ตลอด Entra ID Connect ช่วยให้องค์กรต่างๆ สามารถซิงโครไนซ์ผู้ใช้และข้อมูลไดเรกทอรีจาก AD ในสถานที่ไปยังคลาวด์ได้ ช่วยให้ผู้ใช้สามารถเข้าถึงบริการคลาวด์ได้โดยใช้ข้อมูลประจำตัวเดียวกันกับระบบในสถานที่ คุณลักษณะที่น่าสนใจอย่างหนึ่งคือ Entra ID Connect รองรับการเขียนรหัสผ่านกลับ โดยการเปลี่ยนแปลงรหัสผ่านที่ทำในระบบคลาวด์จะซิงค์กลับไปยัง AD ในสถานที่ เพื่อให้แน่ใจว่าการจัดการข้อมูลประจำตัวมีความสอดคล้องกันในทั้งสองสภาพแวดล้อม โมเดลไฮบริดนี้ช่วยให้มั่นใจได้ว่าองค์กรต่างๆ สามารถรักษาระบบข้อมูลประจำตัวแบบรวมศูนย์ในขณะที่ทำงานบนโครงสร้างพื้นฐานทั้งในระบบคลาวด์และภายในองค์กร
ความแตกต่างในการบริหารจัดการอนุญาตระหว่างแบบดั้งเดิม Active Directory และ Entra ID อาจทำให้เกิดช่องว่างด้านความปลอดภัยในกระบวนการซิงโครไนซ์ระหว่างผลิตภัณฑ์ทั้งสอง
เจาะลึกการจัดการการอนุญาต
การจัดการการอนุญาตใน Active Directory ทำงานในลักษณะที่ในแต่ละสภาพแวดล้อมจะมีกลุ่มความปลอดภัยที่มีสิทธิพิเศษเริ่มต้นหลายกลุ่มพร้อมสิทธิ์ที่ยกระดับเพื่อทำการเปลี่ยนแปลง เมื่อเราต้องการให้สิทธิ์เหล่านี้แก่ผู้ใช้เฉพาะ เราเพียงแค่เพิ่มสิทธิ์เหล่านี้ลงในกลุ่ม ตัวอย่างเช่น กลุ่ม "ผู้ดูแลโดเมน" จะให้สิทธิ์แก่ผู้ใช้ทั้งหมดภายในกลุ่ม อีกวิธีหนึ่งในการกำหนดสิทธิ์สำหรับผู้ใช้หรือกลุ่มคือผ่าน ACL (รายการควบคุมการเข้าถึง) รายการนี้มีอยู่สำหรับแต่ละอ็อบเจ็กต์ใน AD และระบุสิทธิ์สำหรับแต่ละเอนทิตี กลไกนี้ช่วยให้สามารถกำหนดสิทธิ์ให้กับผู้ใช้ทั่วไปเพื่อทำการแก้ไขได้ แม้แต่กับอ็อบเจ็กต์ที่เป็นของผู้ใช้ที่มีสิทธิ์ระดับสูง เช่น ผู้ดูแลโดเมน
อย่างไรก็ตามใน Entra ID (เดิมคือ Azure AD) ไม่มีกลุ่มความปลอดภัยตามค่าเริ่มต้น แต่จะใช้กลไก RBAC (การควบคุมการเข้าถึงตามบทบาท) แทน ซึ่งหมายความว่ามีบทบาทหลายประเภท โดยแต่ละประเภทจะกำหนดสิทธิ์ผู้ใช้ที่แตกต่างกัน นอกจากนี้ คุณยังสามารถกำหนดบทบาทให้กับกลุ่ม และสมาชิกทั้งหมดในกลุ่มนั้นจะได้รับสิทธิ์เดียวกัน แต่ตัวเลือกนี้ไม่รวมกลุ่มที่กำหนดตามค่าเริ่มต้น เช่น Active Directory.
แล้วกลไกทั้งสองต่างกันอย่างไร ใน Entra การป้องกันการปรับเปลี่ยนจะเกิดขึ้นเมื่อผู้ใช้ได้รับสิทธิ์พิเศษตามบทบาทหรือการกำหนดกลุ่ม ใน AD รุ่นเก่า เราพบว่ากลุ่มที่ละเอียดอ่อนบางกลุ่มไม่ได้รับการป้องกันจากการปรับเปลี่ยน ในความเป็นจริง กลุ่มที่ละเอียดอ่อนบางกลุ่มได้รับการปฏิบัติเหมือนอ่อนแอเมื่อต้องจัดการกับปัญหา Entra ID เชื่อมต่อการซิงโครไนซ์
ใน Entra เมื่อใดก็ตามที่ผู้ใช้ได้รับบทบาทที่มีสิทธิพิเศษ พวกเขาจะได้รับการคุ้มครองการปรับเปลี่ยนโดยอัตโนมัติ มีเพียงผู้ใช้ที่มีสิทธิ์ระดับสูงกว่าหรือระดับบทบาทที่เทียบเท่าเท่านั้นที่สามารถดำเนินการเปลี่ยนแปลงได้ โดยป้องกันไม่ให้ผู้ใช้รายอื่นที่มีระดับบทบาทต่ำกว่าดำเนินการได้ ซึ่งหมายความว่าผู้ใช้ไม่จำเป็นต้องเป็นสมาชิกของกลุ่มความปลอดภัยเพื่อรับการคุ้มครอง เพียงแค่กำหนดบทบาทที่มีสิทธิพิเศษให้กับพวกเขา ก็เพียงพอที่จะให้การคุ้มครองในระดับหนึ่งแก่พวกเขาแล้ว ซึ่งต่างจากใน AD
เช่นในลำดับชั้นของ บทบาทผู้ดูแลระบบ ภายใน Entra IDที่ ผู้ดูแลระบบรหัสผ่าน บทบาทนี้ให้ผู้ใช้มีความสามารถในการรีเซ็ตรหัสผ่าน อย่างไรก็ตาม แม้ว่าจะถูกจัดอยู่ในประเภทผู้ดูแลระบบ แต่บทบาทนี้ถือเป็นบทบาทที่มีตำแหน่งต่ำสุดในลำดับชั้นผู้ดูแลระบบ ดังนั้น ผู้ดูแลระบบรหัสผ่านจึงรีเซ็ตรหัสผ่านได้เฉพาะสำหรับ ผู้ใช้ทั่วไป หรือผู้ใช้ที่มีบทบาทผู้ดูแลระบบเหมือนกัน พวกเขาไม่มีอำนาจในการรีเซ็ตรหัสผ่านให้กับผู้ใช้ในระดับที่สูงกว่า บทบาทผู้ดูแลระบบเช่น ผู้ดูแลระบบทั่วโลกหรืออื่น ๆ บัญชีสิทธิพิเศษรักษาขอบเขตความปลอดภัยที่ชัดเจนระหว่างบทบาทผู้ดูแลระบบที่แตกต่างกัน โครงสร้างลำดับชั้นนี้ช่วยให้มั่นใจว่าบทบาทที่ละเอียดอ่อนกว่าจะได้รับการปกป้องจากการเปลี่ยนแปลงรหัสผ่านโดยไม่ได้รับอนุญาต
การซิงโครไนซ์เกิดขึ้นได้อย่างไร?
กระบวนการซิงโครไนซ์ระหว่าง AD ในสถานที่และ Entra ID สามารถแบ่งได้เป็น 2 ส่วนหลักๆ คือ
- การซิงค์ข้อมูลประจำตัวจากภายในองค์กรไปยัง Entra ID
- เขียนรหัสผ่านกลับจาก Entra ID สู่ภายในสถานที่
ส่วนที่ 1: การซิงค์จากภายในองค์กรไปยัง Entra ID
Entra ID การเชื่อมต่อสร้าง บัญชีบริการ ผู้ใช้ที่เรียกว่า MSOL ตามหลัง 8 ไบต์แรกของตัวระบุการติดตั้ง ผู้ใช้รายนี้มีความสามารถอันทรงพลังซึ่งอาจเทียบเท่ากับตัวควบคุมโดเมน สิทธิ์ "ทำซ้ำการเปลี่ยนแปลงไดเรกทอรีทั้งหมด" อนุญาตให้ผู้ใช้ดำเนินการซิงค์ DC และแยกแอตทริบิวต์ทั้งหมดของวัตถุ รวมถึงข้อมูลประจำตัวของไคลเอนต์ กล่าวอีกนัยหนึ่งคือแฮช NT เนื่องจากสิทธิ์ที่มอบให้ผู้ใช้รายนี้ครอบคลุมไดเรกทอรี จึงสามารถเข้าถึงและอ่านข้อมูลเกี่ยวกับผู้ใช้ในกลุ่มที่ได้รับการป้องกันได้ นี่เป็นเพราะสิทธิ์ที่ให้ไว้ทำให้ผู้ใช้สามารถใช้งานด้วยสิทธิ์แบบตัวควบคุมโดเมนได้ ดังนั้น แม้ว่าผู้ใช้จะไม่อยู่ในรายการ ACL ของกลุ่มโดยชัดเจน แต่ผู้ใช้ยังคงสามารถดึงแฮช NT ของสมาชิกกลุ่มได้ สิทธิ์นี้อนุญาตให้ใช้กระบวนการซิงโครไนซ์ภายในองค์กร และได้รับการจัดการโดยใช้โปรโตคอลระยะไกลของบริการการจำลองไดเรกทอรี ซึ่งทำงานผ่านการขนส่ง RPC โปรโตคอลเดียวกันนี้ใช้เพื่อดำเนินการโจมตี DCSync ตัวแทนซิงค์ภายในองค์กรจะส่งข้อมูลและแอตทริบิวต์ของผู้ใช้ทั้งหมดไปยัง Entra ID ผ่านพอร์ต 443 เมื่อ Entra ได้รับข้อมูลดังกล่าวแล้ว จะประมวลผลและกรอกรายละเอียดที่จำเป็นภายในสภาพแวดล้อมของตน เพื่อเสร็จสิ้นกระบวนการซิงโครไนซ์เบื้องต้น
ส่วนที่ 2: การเขียนรหัสผ่านกลับจาก Entra ID สู่ภายในสถานที่
ส่วนที่สองของกระบวนการซิงโครไนซ์จะเกิดขึ้นเมื่อเปิดใช้งาน Password Writeback ใน Entra AD Connect ฟีเจอร์นี้ช่วยให้สามารถซิงโครไนซ์รหัสผ่านจากคลาวด์ไปยังสภาพแวดล้อมภายในองค์กรได้ ดังนั้นเมื่อผู้ใช้เปลี่ยนรหัสผ่านในคลาวด์ การเปลี่ยนแปลงดังกล่าวจะสะท้อนไปยังสภาพแวดล้อมภายในองค์กรด้วย ฟีเจอร์นี้ช่วยให้มั่นใจได้ว่าจะซิงโครไนซ์ระหว่างสองสภาพแวดล้อมได้อย่างแม่นยำ ซึ่งเป็นหนึ่งในเหตุผลหลักในการเชื่อมต่อทั้งสองเข้าด้วยกัน เพื่อให้ผู้ใช้สามารถเข้าสู่ระบบด้วยรหัสผ่านเดียวกันในทุกแอปพลิเคชันและสภาพแวดล้อมภายในองค์กร
เมื่อมีการเริ่มดำเนินการรีเซ็ตรหัสผ่านสำหรับผู้ใช้ใน Entra IDระบบจะค้นหาชื่อผู้ใช้ก่อนเพื่อยืนยันว่ามีอยู่แล้ว Entra IDหากพบผู้ใช้ ระบบจะดำเนินการตรวจสอบสิทธิ์เพื่อดูว่าบุคคลที่พยายามรีเซ็ตรหัสผ่านมีบทบาทที่อนุญาตให้ดำเนินการนี้หรือไม่ หากผู้ใช้มีสิทธิ์ที่จำเป็น Entra ID ส่งชื่อผู้ใช้และรหัสผ่านใหม่ไปยัง Entra Service Bus
ตัวแทนการซิงค์ที่ทำงานภายในองค์กรจะเรียกค้นข้อมูลนี้ เนื่องจากผู้ใช้ MSOL ที่สร้างโดย Entra Connect มีสิทธิ์ DS Sync แต่สำหรับการอ่านเท่านั้น จึงไม่ใช้โปรโตคอล RPC เพื่อรีเซ็ตรหัสผ่าน แต่จะดำเนินการร้องขอ LDAP เพื่อค้นหาผู้ใช้ที่เกี่ยวข้องใน Active Directory และพยายามอัพเดตพาสเวิร์ดโดยใช้การร้องขอโดยใช้การดำเนินการ “IADsUser.ChangePassword”
ในขั้นตอนนี้ การตรวจสอบความปลอดภัยที่สำคัญจะดำเนินการ: เมื่อได้รับคำขอ LDAP โดยตัวควบคุมโดเมน (DC) Active Directory ระบบการอนุญาตจะตรวจสอบว่าผู้ใช้ที่พยายามเปลี่ยนรหัสผ่านมีสิทธิ์ที่จำเป็นในการรีเซ็ตรหัสผ่านสำหรับผู้ใช้เป้าหมายหรือไม่ โดยทำได้โดยตรวจสอบ ACL ของผู้ใช้เป้าหมาย หากผู้ใช้ MSOL ไม่มีสิทธิ์ "รีเซ็ตรหัสผ่าน" เหนือเอนทิตี ข้อผิดพลาดจะถูกส่งกลับไปที่ Entra IDระบุว่าการอัปเดตรหัสผ่านล้มเหลวเนื่องจากสิทธิ์ไม่เพียงพอ หากมีสิทธิ์ "รีเซ็ตรหัสผ่าน" แสดงว่าการเปลี่ยนรหัสผ่านเสร็จสมบูรณ์
ช่องว่างด้านความปลอดภัย
ในระหว่างกระบวนการซิงโครไนซ์ ฉันสังเกตเห็นว่าไม่มีการครอบคลุมอย่างสมบูรณ์ว่าผู้ใช้รายใดเป็นสมาชิกของกลุ่มที่มีสิทธิพิเศษหรือมีสิทธิ์ที่สูงกว่า ดังนั้น ในสภาพแวดล้อม Entra ผู้ใช้เหล่านี้จะไม่ได้รับสถานะสิทธิพิเศษแบบเดียวกับที่พวกเขาได้รับภายในองค์กรโดยอัตโนมัติ ตามค่าเริ่มต้น ผู้ใช้ไฮบริดจะไม่ได้รับการปกป้องแบบเดียวกับบทบาทที่มีสิทธิพิเศษใน Entra ในระหว่างการซิงโครไนซ์เริ่มต้น เว้นแต่ผู้ดูแลระบบเครือข่ายจะกำหนดสิทธิพิเศษและการป้องกันเหล่านี้ด้วยตนเองภายใน Entra ID.
เมื่อเข้าใจความสามารถในการซิงโครไนซ์ระหว่างสองสภาพแวดล้อม และความสามารถในการซิงโครไนซ์ข้อมูลประจำตัวกลับไปยัง Entra ไปยังสถานที่ภายในองค์กร คำถามที่เกิดขึ้นคือ ความเสี่ยงที่อาจเกิดขึ้นมีอะไรบ้าง?
ความเสี่ยงหลักคือการได้รับสิทธิ์ที่สูงขึ้นใน AD ในสถานที่ผ่านบทบาทผู้ดูแลระบบที่อ่อนแอใน Entra ในขณะที่อยู่ใน AD ผู้ใช้สามารถได้รับสิทธิ์ที่มีสิทธิพิเศษแต่ไม่จำเป็นต้องเป็นสมาชิกของกลุ่มที่ได้รับการป้องกัน ซึ่งทำให้เสี่ยงต่อการโจมตี ความเสี่ยงเดียวกันนี้มีอยู่ในขั้นตอนการโจมตีนี้:
เมื่อผู้โจมตีสามารถควบคุมได้ Entra ID ผู้ใช้ที่ได้รับมอบหมายบทบาทผู้ดูแลระบบรหัสผ่านสามารถใช้สิทธิ์รีเซ็ตรหัสผ่านเพื่อยกระดับสิทธิ์ของตนได้ แม้ว่าผู้ใช้อาจไม่มีผู้ใช้ภายในองค์กรก็ตาม การรีเซ็ตรหัสผ่านของผู้ใช้ที่มีสิทธิ์ AD ระดับสูง เช่น ผู้ใช้จากกลุ่มผู้ดูแลระบบ DNS ช่วยให้พวกเขาควบคุมบัญชีได้และอาจเพิ่มสิทธิ์ภายในโดเมนภายในองค์กรได้
สิ่งที่ผู้โจมตีต้องทำคือเข้าสู่ระบบด้วยบัญชีผู้ใช้ที่ถูกต้อง ซึ่งอย่างน้อยต้องมีบทบาทผู้ดูแลระบบรหัสผ่าน Entra ID. ไม่สำคัญว่าพวกเขาจะใช้อินเทอร์เฟซที่ https://entra.microsoft.com or https://portal.azure.comเมื่อเข้าสู่ระบบแล้ว พวกเขาจะเลือกผู้ใช้ภายในองค์กรเป้าหมายและรีเซ็ตรหัสผ่านของตนเอง วิธีนี้จะทำให้ผู้โจมตีสามารถเข้าสู่ระบบในสภาพแวดล้อมภายในองค์กรด้วยบัญชีที่มีการเปลี่ยนรหัสผ่าน
สิ่งสำคัญคือต้องทราบว่าหากผู้ใช้เป้าหมายเป็นส่วนหนึ่งของกลุ่มที่ได้รับการปกป้องในสภาพแวดล้อมภายในสถานที่ การโจมตีจะล้มเหลว
เนื่องจากการจัดการสิทธิ์สำหรับผู้ใช้ที่ได้รับการป้องกันภายในสถานที่จะบล็อกการเปลี่ยนแปลงจากการดำเนินการโดย Entra ID เชื่อมต่อบัญชีกับผู้ใช้ในกลุ่มที่ได้รับการป้องกันเหล่านั้น ในสภาพแวดล้อมภายในองค์กร สามารถระบุกลุ่มที่ได้รับการป้องกันได้โดยการตรวจสอบ adminCount คุณลักษณะของกลุ่ม หาก adminCount แอตทริบิวต์ถูกตั้งค่าเป็น "1" ซึ่งบ่งชี้ว่ากลุ่มได้รับการพิจารณาว่าได้รับการปกป้อง กลุ่มที่ได้รับการปกป้องเหล่านี้ปฏิบัติตามเทมเพลตการอนุญาตคงที่ที่บังคับใช้เป็นระยะๆ ทุกชั่วโมง กลไกการป้องกันใน Active Directory เรียกใช้กระบวนการที่ตรวจสอบว่าสิทธิ์ของกลุ่มใน ACL ตรงกับสิทธิ์ที่กำหนดไว้ในเทมเพลต หากมีความคลาดเคลื่อน กระบวนการจะรีเซ็ตสิทธิ์ให้ตรงกับเทมเพลต
กระบวนการนี้ได้รับการจัดการโดยกลไกที่เรียกว่า ส.ด.พร็อพ (ตัวเผยแพร่ตัวระบุความปลอดภัย) และเทมเพลตการอนุญาตเรียกว่า ผู้ดูแล SDHolder.
สถานการณ์การโจมตีที่ใช้ประโยชน์จากจุดอ่อนนี้
ผู้ดูแลระบบเงา
ผู้ดูแลระบบเงา คือผู้ใช้ที่สามารถรีเซ็ตรหัสผ่านให้กับผู้ดูแลระบบได้ แต่ไม่ได้อยู่ในกลุ่มผู้ดูแลระบบใดๆ เนื่องจากทั้งแบบภายในองค์กร Active Directory และ Entra ID หากปฏิบัติต่อผู้ดูแลระบบเงาเหล่านี้เหมือนเป็นผู้ใช้ทั่วไป (โดยไม่มีการป้องกันพิเศษจากกลุ่มผู้ใช้ที่มีสิทธิพิเศษ) ผู้โจมตีสามารถใช้ประโยชน์จากความสามารถในการรีเซ็ตรหัสผ่านของผู้ใช้ที่มีสิทธิพิเศษใน Entra ได้ ซึ่งหมายความว่าผู้โจมตีสามารถรีเซ็ตรหัสผ่านของผู้ใช้รายนั้นในสภาพแวดล้อมภายในองค์กรได้เช่นกัน
สถานการณ์นี้มอบช่องทางที่ชัดเจนให้ผู้โจมตีในการเพิ่มสิทธิ์และขยายการควบคุมของพวกเขาทั่วทั้งเครือข่าย โดยใช้ประโยชน์จากสิทธิ์ที่ยกระดับของผู้ใช้ที่ถูกบุกรุก
กลุ่มผู้ดูแลระบบ DNS
ตัวอย่างอื่นคือกลุ่มผู้ดูแลระบบ DNS ผู้ดูแลระบบ DNS จัดการส่วนประกอบโครงสร้างพื้นฐานเครือข่ายที่สำคัญ โดยเฉพาะเซิร์ฟเวอร์ DNS เนื่องจากกลุ่มผู้ดูแลระบบ DNS ถูกตั้งค่าเป็นกลุ่มที่มีสิทธิพิเศษโดยไม่มีการป้องกันเพิ่มเติมภายในองค์กร ผู้โจมตีจึงสามารถรีเซ็ตรหัสผ่านของสมาชิกกลุ่มผู้ดูแลระบบ DNS ได้อย่างง่ายดายผ่าน Entra ซึ่งจะทำให้สามารถควบคุมบัญชีนั้นได้อย่างสมบูรณ์ในสภาพแวดล้อมภายในองค์กร
ด้วยการควบคุมบัญชีผู้ดูแลระบบ DNS ผู้โจมตีสามารถขัดขวางการทำงานของเครือข่ายได้อย่างมีนัยสำคัญ พวกเขาอาจแก้ไขระเบียน DNS เพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลภายในเครือข่าย ดำเนินการ ผู้ชายตรงกลาง (MITM) โจมตีโดยการเปลี่ยนเส้นทางการรับส่งข้อมูลผ่านเซิร์ฟเวอร์ที่พวกเขาควบคุมหรือเปลี่ยนแปลงการตั้งค่า DNS เพื่อส่งผู้ใช้ไปยังเว็บไซต์ที่เป็นอันตราย
เจ้าของผู้สร้างนโยบายกลุ่ม
Group Policy Creator Owners เป็นอีกตัวอย่างหนึ่งของกลุ่มที่อาจเป็นกลุ่มที่มีสิทธิพิเศษโดยไม่มีการป้องกันเพิ่มเติม สมาชิกของกลุ่มนี้สามารถแก้ไข Group Policy Objects (GPOs) ที่พวกเขาสร้างขึ้นได้ หากผู้โจมตีได้รับสิทธิ์ในการเข้าถึงบัญชีในกลุ่มนี้ พวกเขาสามารถใช้ประโยชน์จากสิทธิ์ของพวกเขาเพื่อแก้ไข GPO ที่บังคับใช้อยู่ซึ่งอาจมีสคริปต์หรือการตั้งค่าที่เป็นอันตราย เช่น สคริปต์ที่อาจขโมยข้อมูลประจำตัวหรือติดตั้งมัลแวร์
กลุ่มผู้จัดพิมพ์ Cert
ผู้จัดพิมพ์ใบรับรอง กลุ่มเป็นอีกตัวอย่างหนึ่งของกลุ่มที่มีสิทธิพิเศษซึ่งอาจไม่ได้รับความสนใจที่จำเป็นเกี่ยวกับความปลอดภัยเสมอไป สมาชิกของกลุ่มนี้ได้รับอนุญาตให้เผยแพร่ใบรับรองได้ Active Directoryซึ่งมีบทบาทสำคัญในการขับเคลื่อนองค์กร โครงสร้างพื้นฐานกุญแจสาธารณะ (PKI)หากผู้โจมตีได้รับสิทธิ์เข้าถึงบัญชีที่เป็นส่วนหนึ่งของ ผู้จัดพิมพ์ใบรับรอง กลุ่มพวกเขาสามารถออกหรือแก้ไขใบรับรองได้ ซึ่งอาจก่อให้เกิดความเสี่ยงต่อความปลอดภัยที่ร้ายแรง
ตัวอย่างเช่น ผู้โจมตีสามารถเผยแพร่ ใบรับรองที่เป็นอันตรายหรือปลอมแปลง เพื่อปลอมตัวเป็นผู้ใช้หรือบริการที่เชื่อถือได้ ช่วยให้พวกเขาสามารถดำเนินการโจมตี MITM ถอดรหัสการสื่อสารที่ปลอดภัย หรือหลีกเลี่ยง การรับรอง การควบคุม ผู้โจมตีสามารถยกระดับสิทธิ์ได้โดยการออกใบรับรองให้กับบัญชีที่มีสิทธิ์ระดับสูง เช่น ผู้ดูแลระบบโดเมน ซึ่งจะนำไปสู่การบุกรุกโดเมนทั้งหมด
การบรรเทาการโจมตี
1. เมื่อใช้การตั้งค่าการระบุตัวตนแบบไฮบริดที่เข้าร่วม ให้เปรียบเทียบสิทธิ์ระหว่างสภาพแวดล้อมภายในองค์กรของคุณกับ Entra เสมอ นอกจากนี้ โปรดตรวจสอบให้แน่ใจว่าผู้ใช้ที่มีสิทธิพิเศษซึ่งมีอยู่ใน Entra เท่านั้นและไม่มีบัญชีที่เกี่ยวข้องในภายในองค์กรจะไม่ได้รับสิทธิ์ในการรีเซ็ตรหัสผ่าน ซึ่งจะช่วยป้องกันการเข้าถึงจากภายนอกที่ไม่ได้รับอนุญาตและการควบคุมสภาพแวดล้อมของคุณ
2. เมื่อตั้งค่าการซิงโครไนซ์ระหว่างภายในองค์กร Active Directory (ค.ศ.) และ Entra IDสิ่งสำคัญคือต้องตรวจสอบสิทธิ์ที่ได้รับมอบหมายให้กับกลุ่มที่มีสิทธิพิเศษในสภาพแวดล้อมภายในองค์กรของคุณอยู่เสมอ โดยเฉพาะอย่างยิ่ง คุณควรตรวจสอบให้แน่ใจว่ากลุ่มเหล่านี้ไม่มีสิทธิ์ในการเปลี่ยนรหัสผ่านที่ไม่จำเป็น
หากคุณสังเกตว่าสมาชิกของกลุ่มที่มีสิทธิพิเศษสามารถเปลี่ยนรหัสผ่านได้ คุณมีสองทางเลือกในการดำเนินการนี้:
- การลบสิทธิ์ด้วยตนเอง: คุณสามารถปรับเปลี่ยนสิทธิ์ด้วยตนเองสำหรับกลุ่มที่มีสิทธิพิเศษแต่ละกลุ่มเพื่อลบความสามารถในการเปลี่ยนรหัสผ่าน
- ใช้ประโยชน์จากเทมเพลต AdminSDHolder: หรือคุณสามารถปรับเปลี่ยน adminCount คุณลักษณะของกลุ่มที่มีสิทธิพิเศษจะต้องเท่ากับ “1” จึงจะปกป้องพวกเขาได้
AdminSDHolder เป็นเทมเพลตความปลอดภัยใน Active Directory ซึ่งกำหนดและบังคับใช้สิทธิ์การรักษาความปลอดภัยสำหรับสมาชิกของกลุ่มที่ได้รับการปกป้อง โดยการเพิ่มกลุ่มที่มีสิทธิพิเศษลงในเทมเพลตนี้ คุณสามารถลบสิทธิ์ในการเปลี่ยนรหัสผ่านของพวกเขาได้โดยอัตโนมัติ
