การเข้าถึงเกินขอบเขตของผู้ดูแลระบบ Agent ID: การเข้าควบคุม Service Principal ใน Entra ID

TL; DR

การขอ ไมโครซอฟท์ แพลตฟอร์มระบุตัวตนตัวแทน ((ตัวอย่าง) มอบอัตลักษณ์เฉพาะตัวให้กับเอเจนต์ AI ใน Entra ID (แบบแปลน) (เช่น ข้อมูลประจำตัวของเอเจนต์ ผู้ใช้เอเจนต์) เพื่อให้คุณสามารถกำกับดูแลและรักษาความปลอดภัยได้เหมือนกับหลักการอื่นๆ เพื่อจัดการระนาบควบคุมใหม่นี้ ไมโครซอฟต์ได้แนะนำ ผู้ดูแลระบบรหัสตัวแทน บทบาท ในทางทฤษฎีแล้ว บทบาทนี้จำกัดอยู่เฉพาะวัตถุที่เกี่ยวข้องกับเอเจนต์เท่านั้น

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

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

เราได้แจ้งพฤติกรรมนี้ให้ศูนย์ตอบสนองด้านความปลอดภัยของ Microsoft (MSRC) ทราบแล้ว และทางศูนย์ฯ ก็ได้แจ้งเรื่องนี้ให้ทราบ ได้รับการแก้ไขในทุกระบบคลาวด์บทบาทผู้ดูแลระบบ Agent ID ไม่สามารถจัดการเจ้าของ Service Principal ที่ไม่ใช่ Agent ได้อีกต่อไป

หากคุณคุ้นเคยกับแนวคิดที่อธิบายไว้ข้างต้นแล้ว ให้ข้ามไปยังส่วนถัดไป ตรงจุดที่เส้นแบ่งขาด.

การวิเคราะห์ด้านล่างนี้อ้างอิงจากผลการวิจัยฉบับเต็มของเรา

สิ่งที่คุณจำเป็นต้องรู้

หลักการแอปพลิเคชันและบริการใน Entra ID

การลงทะเบียนแอปพลิเคชันใน Microsoft Entra ID สร้างวัตถุที่เกี่ยวข้องกันสองชิ้นใน ผู้เช่าบ้านซึ่งเป็นผู้เช่าที่แอปได้รับการลงทะเบียนไว้แต่แรก: an วัตถุแอปพลิเคชัน และ บริการหลัก.

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

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

ในบล็อกนี้ เราจะเน้นเฉพาะประเภทนี้เท่านั้น เนื่องจากพฤติกรรมที่อธิบายไว้ในที่นี้ใช้ได้กับ Application Service Principal โดยเฉพาะ

Microsoft ป้อนรหัสตัวแทน

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

กล่าวโดยสรุป แพลตฟอร์มนี้นำเสนอ:

พิมพ์เขียว: แม่แบบที่ใช้กำหนดและสร้างตัวตนของเอเจนต์
หลักการของพิมพ์เขียว: อินสแตนซ์เฉพาะของผู้เช่าของแบบพิมพ์เขียวเมื่อมีการเพิ่มลงในผู้เช่า
ตัวตนของตัวแทน: หลักการบริการพิเศษที่เอเจนต์ AI ใช้ในการตรวจสอบสิทธิ์กับ API และบริการต่างๆ
ผู้ใช้เอเจนต์: นี่คืออ็อบเจ็กต์เสริมที่คล้ายกับอ็อบเจ็กต์ของผู้ใช้ สำหรับเอเจนต์ที่ต้องการ UPN หรืออีเมล และใช้ในกระบวนการตรวจสอบสิทธิ์ในนามของผู้อื่น

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

บทบาทผู้ดูแลระบบรหัสตัวแทน

ไมโครซอฟต์ได้เพิ่ม ผู้ดูแลระบบรหัสตัวแทน บทบาทในการจัดการระนาบควบคุมการระบุตัวตนของเอเจนต์ใหม่ ตามเอกสารระบุว่า มัน ขอบเขตจำกัด:

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

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

ไมโครซอฟต์ยืนยันว่ามีความคลาดเคลื่อนระหว่างส่วนติดต่อผู้ใช้ของ Entra กับเอกสารประกอบ เกี่ยวกับ ตัวบ่งชี้ “สิทธิพิเศษ” จะได้รับการแก้ไข.

ตรงจุดที่เส้นแบ่งขาด

สิ่งที่เราพบคือ: ผู้ใช้ที่ได้รับมอบหมายบทบาทผู้ดูแลระบบ Agent ID สามารถเพิ่มตนเองเป็นเจ้าของ Service Principal นอกเหนือจากข้อมูลประจำตัวที่เกี่ยวข้องกับ Agent รวมถึง Service Principal ใดๆ ก็ได้ใน Tenant จากนั้น พวกเขาสามารถเพิ่มข้อมูลประจำตัวและยืนยันตัวตนในฐานะแอปพลิเคชันเหล่านั้นได้

ขั้นตอนที่ 1: เพิ่มเจ้าของ (ดำเนินการสำเร็จกับผู้รับมอบอำนาจที่ไม่ใช่ตัวแทน คุณสามารถเพิ่มตัวคุณเองหรือผู้รับมอบอำนาจรายอื่นได้):

ขั้นตอนที่ 2: เพิ่มข้อมูลประจำตัว (ใช้งานได้หลังจากที่เราได้เป็นเจ้าของแล้วเท่านั้น):

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

แม้ว่าบทบาทนี้จะมีไว้สำหรับ ตัวแทน ในทางปฏิบัติ อัตลักษณ์สามารถเปลี่ยนกรรมสิทธิ์ได้ ใด หลักการบริการ

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

microsoft.directory/agentIdentities/owners/update
microsoft.directory/agentIdentityBlueprintPrincipals/owners/update

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

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

หลังจากแก้ไขแล้ว การพยายามกำหนดสิทธิ์การเป็นเจ้าของให้กับ Service Principal ที่ไม่ใช่ Agent โดยใช้บทบาท Agent ID Administrator จะถูกบล็อก การดำเนินการดังกล่าวจะส่งผลให้เกิดข้อผิดพลาดดังต่อไปนี้:

เรื่องราว

การเข้าครอบครองบริการหลัก

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

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

ก่อนการแก้ไข บทบาทผู้ดูแลระบบรหัสตัวแทน (Agent ID Administrator) อนุญาตให้กำหนดความเป็นเจ้าของเหนือหลักการบริการ (service principals) นอกเหนือจากข้อมูลประจำตัวที่เกี่ยวข้องกับตัวแทน ซึ่งเป็นการเปิดใช้งานความสามารถที่คล้ายคลึงกับบทบาทต่างๆ เช่น ผู้ดูแลระบบแอปพลิเคชัน (Application Administrator) แต่ไม่ได้จำกัดเฉพาะกรณีการใช้งานของตัวแทน

เมื่อเป้าหมายมีสิทธิ์พิเศษ

แนวทางการเพิ่มระดับความรุนแรงนั้นง่ายมาก: if Service Principal มีสิทธิ์พิเศษ (เช่น บทบาทในไดเร็กทอรี สิทธิ์การเข้าถึงกราฟที่มีผลกระทบสูง) การเข้าควบคุม Service Principal นั้นหมายความว่าคุณจะได้รับสิทธิ์เหล่านั้นไปด้วย องค์กรหลายแห่งมี Service Principal ประเภทนี้

คุณสามารถค้นหาว่าหลักการบริการใดได้รับสิทธิพิเศษ จากนั้นจึงกำหนดเป้าหมายไปยังหลักการเหล่านั้น ในทางปฏิบัติ นั่นหมายถึงการตรวจสอบสองประเภท:

หลักการบริการที่มีบทบาทในไดเร็กทอรีที่มีสิทธิ์พิเศษ: ใช้ Microsoft Graph API (เบต้า, isPrivileged (ในคำจำกัดความของบทบาท) เพื่อแสดงรายการว่าผู้ให้บริการรายใดมีบทบาทระดับผู้ดูแลระบบในไดเร็กทอรี
หลักการบริการที่มีสิทธิ์การเข้าถึงกราฟที่มีผลกระทบสูง: สอบถามการกำหนดบทบาทแอปไปยัง Microsoft Graph สำหรับสิทธิ์ที่ละเอียดอ่อน (เช่น Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Application.ReadWrite.All).

ระบุหลักการบริการพิเศษ

เรียกใช้คำสั่งต่อไปนี้หลังจาก az login. ต้องใช้ jqใช้บัญชีที่สามารถอ่านการมอบหมายบทบาทและการมอบหมายบทบาทแอปได้ (เช่น ผู้ดูแลระบบ Agent ID)

1. หลักการบริการที่มีบทบาทในไดเร็กทอรีที่มีสิทธิ์พิเศษ

BASE="https://graph.microsoft.com"
roles="$(az rest -m GET --url "${BASE}/beta/roleManagement/directory/roleDefinitions?\$filter=isPrivileged eq true&\$select=id,displayName" -o json)"
u="${BASE}/beta/roleManagement/directory/roleAssignments?\$expand=principal(\$select=id,displayName)&\$top=999"
{
  echo -e "SP_NAME\tSP_ID\tROLE"
  echo -e "--------\t------\t----"
  while :; do
    j="$(az rest -m GET --url "$u" -o json 2>/dev/null)" || break
    jq -r --argjson roles "$roles" '
      ($roles.value | map(select(.displayName|test("Reader";"i")|not) | {key:.id, value:.displayName}) | from_entries) as $r
      | .value[]
      | select(.principal."@odata.type"=="#microsoft.graph.servicePrincipal")
      | select($r[.roleDefinitionId] != null)
      | [.principal.displayName, (.principal.id // .principalId), $r[.roleDefinitionId]] | @tsv
    ' <<<"$j"
    u="$(jq -r '."@odata.nextLink"//empty' <<<"$j")"
    [[ -z "$u" ]] && break
  done | sort -t$'\t' -k1,1
} | column -t -s $'\t'

2. หลักการบริการที่มีสิทธิ์การใช้งานแอป Graph ที่มีผลกระทบสูง

BASE="https://graph.microsoft.com"
PERM_IDS='["9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8","06b708a9-e830-4db3-a914-8e69da51d44f","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9","19dbc75e-c2e2-444c-a770-ec69d8559fc7","dd199f4a-f148-40a4-a2ec-f0069cc799ec","50483e42-d915-4231-9639-7fdb7fd190e5","01c0a623-fc9b-48e9-b794-0756f8e8f067","62a82d76-70ea-41e2-9197-370581804d09","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7"]'
PERM_NAMES='{"9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8":"RoleManagement.ReadWrite.Directory","06b708a9-e830-4db3-a914-8e69da51d44f":"AppRoleAssignment.ReadWrite.All","1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9":"Application.ReadWrite.All","19dbc75e-c2e2-444c-a770-ec69d8559fc7":"Directory.ReadWrite.All","dd199f4a-f148-40a4-a2ec-f0069cc799ec":"RoleAssignmentSchedule.ReadWrite.Directory","50483e42-d915-4231-9639-7fdb7fd190e5":"UserAuthenticationMethod.ReadWrite.All","01c0a623-fc9b-48e9-b794-0756f8e8f067":"Policy.ReadWrite.ConditionalAccess","62a82d76-70ea-41e2-9197-370581804d09":"Group.ReadWrite.All","cc117bb9-00cf-4eb8-b580-ea2a878fe8f7":"User-PasswordProfile.ReadWrite.All"}'
GRAPH_SP_ID="00000003-0000-0000-c000-000000000000"
az rest --method GET --url "${BASE}/v1.0/servicePrincipals(appId='${GRAPH_SP_ID}')/appRoleAssignedTo" -o json 2>/dev/null \
  | jq -r --argjson ids "$PERM_IDS" --argjson names "$PERM_NAMES" '
    ["SP_NAME", "SP_ID", "PERMISSIONS"], ["--------", "------", "-------------"],
    ([.value[] | select(.appRoleId as $rid | $ids | index($rid))] | group_by(.principalId)[] |
      [.[0].principalDisplayName, .[0].principalId, ([.[].appRoleId | $names[.]] | join(", "))]) | @tsv
  ' | column -t -s $'\t'

หมายเหตุ เทคนิคเหล่านี้ไม่ได้คัดกรองเฉพาะหลักการบริการที่ไม่ใช่ตัวแทนโดยเฉพาะ

ขั้นตอนการโจมตีแบบครบวงจร

รูปด้านล่างดึง การแจงนับ (สคริปต์ข้างต้น) และ การครอบครอง รวมไว้ในมุมมองเดียว

บันทึกการสาธิต

คลิปนี้แสดงขั้นตอนการทำงาน: ค้นหา Service Principal ที่มีสิทธิ์พิเศษ (ในการสาธิตนี้ เราค้นหาเฉพาะบทบาทในไดเร็กทอรีเท่านั้น) เข้าควบคุม Service Principal นั้น แล้วลงชื่อเข้าใช้

ตัวอย่างสาธิต: ผู้ใช้ทดสอบที่มี ผู้ดูแลระบบรหัสตัวแทน เข้าครอบครองสิทธิพิเศษ ไม่ใช่ตัวแทน ผู้ดูแลระบบหลัก (ที่ได้รับบทบาทผู้ดูแลระบบส่วนกลาง) จะเข้าสู่ระบบด้วยข้อมูลประจำตัวใหม่ ซึ่งเป็นการยกระดับสิทธิ์

การสาธิตคือ จำลอง กับ กราฟเบต้า API; เรา ยังยืนยันอีกด้วย พฤติกรรมเดียวกันของบั๊กบน v1.0.

ภาพสะท้อนจากโลกแห่งความเป็นจริง

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

บล็อกเกี่ยวกับการละเมิดสิทธิ์ความเป็นเจ้าของหลักด้านบริการ - กราฟิกบนหน้าเว็บ - ผู้เช่าที่มีผู้ให้บริการหลักเป็นเอกชน 5 ราย — 99% ขององค์กรมี Service Principal อย่างน้อยหนึ่งรายการ และมากกว่าครึ่งใช้ Agent Identity (ในจำนวนนั้น เกือบครึ่งมีมากกว่า 100 รายการ) ในกรณีที่มีทั้งสองอย่าง ขอบเขตการทำงานของบทบาท Agent ID Administrator จึงมีความสำคัญ

Takeaways

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

ทำไมจึงมองข้ามเรื่องนี้ได้ง่าย

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

แนะนำ

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

การตรวจจับ

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

บัญชีที่ได้รับมอบหมาย Agent ID Administrator

ผ่านทาง Azure CLI: รับงานที่ได้รับมอบหมายในปัจจุบัน:

# Role definition ID for Agent ID Administrator
     az rest --method GET \
       --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=roleDefinitionId eq 'db506228-d27e-4b7d-95e5-295956d6615f'" \
       --query "value[].principalId" -o tsv

ผ่านการวิเคราะห์บันทึก (AuditLogs): สอบถามกิจกรรมการมอบหมายบทบาทสำหรับบทบาทผู้ดูแลระบบ Agent ID (ปรับตารางและช่วงเวลาตามความจำเป็น)

AuditLogs
| where OperationName has "Add member to role"
| where tostring(TargetResources) has "db506228-d27e-4b7d-95e5-295956d6615f" //
Agent ID Administrator
| mv-expand TR = TargetResources
| summarize
    Role = max(iff(TR.type == "Role", tostring(TR.displayName), "")),
    Assignee = max(iff(TR.type != "Role", tostring(TR.displayName), "")),
    AssigneeUPN = max(iff(TR.type != "Role", tostring(TR.userPrincipalName),"")),
    AssigneeId = max(iff(TR.type != "Role", tostring(TR.id), ""))
by TimeGenerated,
   Result,
   Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
                    tostring(InitiatedBy.app.displayName))
| order by TimeGenerated desc

กิจกรรม (การวิเคราะห์บันทึก / บันทึกการตรวจสอบ)

เพิ่มเจ้าของให้กับผู้ให้บริการหลัก: กิจกรรมที่ประสบความสำเร็จ ปรับช่วงเวลาตามความจำเป็น

let AgentIdAdminActors = dynamic(["obj-id1","obj-id2"]);  // principals assigned
Agent ID Administrator
AuditLogs
| where OperationName == "Add owner to service principal"
| where Result == "success"
| where coalesce(InitiatedBy.user.id, InitiatedBy.app.id) in (AgentIdAdminActors)
| order by TimeGenerated desc

เพิ่มข้อมูลรับรองให้กับผู้ใช้บริการหลัก: กิจกรรมที่ประสบความสำเร็จ

AuditLogs
| where OperationName == "Add service principal credentials"
| where Result == "success"
| project
    TimeGenerated,
    OperationName,
    Result,
    Actor = coalesce(InitiatedBy.user.userPrincipalName,
                     InitiatedBy.app.displayName),
    TargetSP = TargetResources[0].displayName,
    TargetSPId = TargetResources[0].id
| order by TimeGenerated desc

ไทม์ไลน์การเปิดเผยข้อมูล

24 กุมภาพันธ์ 2026 – พบช่องโหว่
1 มีนาคม 2026 – ส่งรายงานให้ Microsoft (MSRC)
3 มีนาคม 2026 – คดีความเปิดโดย Microsoft
26 มีนาคม 2026 – ไมโครซอฟต์ยืนยันพฤติกรรมดังกล่าว
4 เมษายน 2026 – การแก้ไขได้เข้าสู่ขั้นตอนก่อนการเผยแพร่แล้ว และไม่สามารถจำลองพฤติกรรมดังกล่าวได้อีกต่อไป
9 เมษายน 2026 – MSRC ยืนยันว่าการแก้ไขปัญหาได้ดำเนินการเสร็จสมบูรณ์แล้ว

ไมโครซอฟต์รับทราบปัญหาดังกล่าวและมอบรางวัลสำหรับผู้ที่พบข้อบกพร่อง (bug bounty) ซึ่งเป็นส่วนหนึ่งของโครงการเปิดเผยข้อบกพร่องของบริษัท

ความคิดของการปิด

ตัวตนของตัวแทน เป็นส่วนหนึ่งของการเปลี่ยนแปลงในวงกว้างไปสู่ระบบระบุตัวตนที่ไม่ใช่มนุษย์ ซึ่งสร้างขึ้นสำหรับยุคของเอเจนต์ AI แพลตฟอร์ม Microsoft Agent Identity Platform เป็นก้าวสำคัญในการที่องค์กรต่างๆ สามารถจัดการและควบคุมระบบเหล่านี้ได้

งานวิจัยนี้เน้นย้ำถึงแง่มุมที่สำคัญของแบบจำลองดังกล่าว นั่นคือ ตัวตนของเอเจนต์นั้นขึ้นอยู่กับส่วนประกอบตัวตนที่มีอยู่แล้ว เช่น หลักการบริการ (service principals) เมื่อมีการนำสิทธิ์การใช้งานบทบาทมาใช้บนพื้นฐานร่วมกันโดยไม่มีการกำหนดขอบเขตที่เข้มงวด การเข้าถึงอาจขยายออกไปเกินกว่าที่ตั้งใจไว้แต่แรก ในกรณีนี้ ช่องว่างดังกล่าวทำให้เกิดการเข้าถึงที่กว้างขึ้น โดยเฉพาะอย่างยิ่งเมื่อมีหลักการบริการที่มีสิทธิพิเศษเข้ามาเกี่ยวข้อง

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

สำหรับคำแนะนำที่นำไปปฏิบัติได้จริงเกี่ยวกับการตรวจสอบและเสริมความแข็งแกร่งให้กับสภาพแวดล้อมของคุณ โปรดดูที่... แนะนำ ภายใต้ Takeaways ส่วนด้านบน