ค้นหาเว็บไซต์

การใช้ Azure Managed Identity กับ Microsoft 365 PowerShell

Azure Managed Identities ใช้ได้กับโมดูล Microsoft 365 บางส่วนแต่ไม่ใช่ทั้งหมด

อัปเดตเมื่อ 15 กรกฎาคม 2023

การใช้ Azure Automation runbooks เป็นวิธีที่ยอดเยี่ยมในการเรียกใช้สคริปต์ PowerShell ตามกำหนดเวลาอย่างสม่ำเสมอ ในบทความก่อนหน้านี้ ฉันได้สำรวจการใช้ runbooks เพื่อประมวลผลข้อมูล Exchange Online การส่งอีเมลต้อนรับไปยังพนักงานใหม่ด้วย Microsoft Graph PowerShell SDK และการสร้างไฟล์ใน SharePoint Online ทั้งหมดนี้เป็นตัวอย่างที่ดีของการใช้ประโยชน์จาก Azure Automation ในบทความนี้ ฉันจะสำรวจการใช้ Managed Identity สำหรับการรับรองความถูกต้องใน Azure Automation runbooks

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

Microsoft จัดทำเอกสารชุดบริการ Azure ที่สามารถตรวจสอบตัวตนที่มีการจัดการได้ แต่ไม่มีเอกสารประกอบสำหรับโมดูล Microsoft 365 PowerShell การประเมินของฉันคือ:

  • Microsoft Graph PowerShell SDK (บัญชีและกลุ่ม Azure AD): ใช้งานได้
  • ทีม Microsoft: ใช้งานได้
  • การจัดการ Exchange Online: ยังไม่รองรับโมดูลการจัดการ Exchange Online (V2) คุณสามารถเชื่อมต่อโมดูล Exchange V1 รุ่นเก่าและใช้กับข้อมูลประจำตัวที่ได้รับการจัดการได้ เราจะกล่าวถึงเรื่องนี้ในบทความอื่น
  • SharePoint Online: มีตัวอย่างของการใช้ SharePoint Online PowerShell กับข้อมูลประจำตัวที่ได้รับการจัดการ (นี่คือตัวอย่างหนึ่งและตัวอย่างที่สอง) โมดูล SharePoint PnP รองรับชุดฟังก์ชันการทำงานที่จำกัดพร้อมด้วยข้อมูลประจำตัวที่ได้รับการจัดการ การแยกวิเคราะห์จุดปลีกย่อยของการใช้ SharePoint Online ด้วยข้อมูลเฉพาะตัวที่มีการจัดการอยู่นอกขอบเขตของบทความนี้ ดังที่เราจะได้เห็นในภายหลัง ในการเขียนข้อความลงในช่องทาง Teams ฉันใช้โมดูล SharePoint PnP

ความประทับใจโดยรวมคือ Microsoft ออกแบบ Azure Automation และจัดการข้อมูลประจำตัวเพื่อจัดการกับทรัพยากร Azure และไม่ได้ให้ความสนใจมากนักในการทำให้ Azure Automation ทำงานได้ดีกับทรัพยากร Microsoft 365 อย่างไรก็ตาม ชีวิต (และไอที) คือการเดินทาง ดังนั้น เรามาสำรวจความเป็นไปได้กันดีกว่า

การสร้างบัญชี Azure Automation

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

สิทธิ์และบทบาทสำหรับข้อมูลประจำตัวที่ได้รับการจัดการ

เอกสารประกอบของ Microsoft อธิบายวิธีการทำงานของข้อมูลระบุตัวตนที่ได้รับการจัดการที่ระบบกำหนด บทความเดียวกันนี้ยังครอบคลุมถึงวิธีการสร้างข้อมูลประจำตัวที่ได้รับการจัดการอีกด้วย สำหรับบทความนี้ ฉันใช้บัญชีอัตโนมัติที่เรียกว่า ManagedIdentitiesAutomation บัญชีนี้จัดเก็บทรัพยากรที่เราจะใช้ในตัวอย่างนี้ โดยส่วนใหญ่เป็นโมดูล PowerShell ตรวจสอบให้แน่ใจว่าก่อนที่คุณจะเริ่มต้น คุณได้โหลดโมดูลกราฟที่มี cmdlets ที่ใช้ใน runbook (เช่น Microsoft.Graph.Authentication และ Microsoft.Graph.Teams) เป็นทรัพยากรสำหรับ บัญชีอัตโนมัติ

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

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

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

ตัวอย่างการทำงาน

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

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

การเชื่อมต่อ การรับรองความถูกต้อง และการอนุญาต

สคริปต์จำเป็นต้องเชื่อมต่อกับตำแหน่งข้อมูล Microsoft Graph และ Microsoft Teams วิธีที่ง่ายที่สุดในการรับโทเค็นการเข้าถึงคือการเรียกใช้ cmdlet Connect-AzAccount คุณสามารถเรียกใช้ Connect-MicrosoftTeams cmdlet ด้วยพารามิเตอร์ Identity เพื่อใช้ข้อมูลประจำตัวที่ได้รับการจัดการ ซึ่งนำไปสู่:

# Connect to Microsoft Graph in Azure Automation
Connect-AzAccount -Identity
$AccessToken = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"
# Connect to the Graph SDK with the acquired access token
Connect-Graph -AccessToken $AccessToken.Token -Scopes AppRoleAssignment.ReadWrite.All
#Define the desired graph endpoint
Select-MgProfile  Beta
# Connect to Teams
Connect-MicrosoftTeams -Identity

Microsoft Graph PowerShell SDK V2.0 (หรือใหม่กว่า) รองรับข้อมูลประจำตัวที่ได้รับการจัดการ ดังนั้นคุณจึงสามารถแทนที่การเชื่อมต่อด้วย:

Connect-MgGraph -Identity -Scopes AppRoleAssignment.ReadWrite.All

โปรดจำไว้ว่า V2 ของ SDK แบ่ง cmdlets ออกเป็นโมดูลที่ใช้งานจริงและเบต้า หากโค้ดของคุณใช้ beta cmdlets อย่าลืมนำเข้าโมดูลเบต้าที่จำเป็น (เช่น Microsoft.Graph.Beta.Users) ลงในบัญชี Azure Automation Select-MgProfile cmdlet ไม่ได้อยู่ใน SDK V2 และควรถูกลบออกจาก runbooks

การตรวจสอบสิทธิ์

ขณะนี้เราได้เชื่อมต่อกับ Graph และ Teams แล้ว แต่โทเค็นการเข้าถึงที่สร้างโดย Azure AD จะไม่อนุญาตให้เราทำอะไรได้มาก เว้นแต่ว่าข้อมูลประจำตัวที่ได้รับการจัดการจะได้รับอนุญาตให้เรียกใช้ cmdlets หรือคำขอ Graph ก่อนที่จะก้าวต่อไป ฉันต้อง:

  • เพิ่มบทบาทการจัดการ Teams ให้กับบริการหลักของข้อมูลประจำตัวที่ได้รับการจัดการ
  • มอบหมายสิทธิ์ Graph API ที่จำเป็นสำหรับงานที่ดำเนินการในสคริปต์ให้กับบริการหลัก

เมื่อดูชุดสิทธิ์ที่กำหนดให้กับข้อมูลประจำตัวที่ได้รับการจัดการในรูปที่ 1 คุณจะไม่เห็นตัวเลือกในการเพิ่มหรือลบสิทธิ์ (ไม่แสดงแบบเต็มหน้าจอ แต่ไม่มีตัวเลือกให้เลือก) ศูนย์การจัดการ Azure AD กล่าวว่า: “ความสามารถในการยินยอมต่อแอปพลิเคชันนี้ถูกปิดใช้งาน เนื่องจากแอปไม่จำเป็นต้องได้รับความยินยอม” ในทางปฏิบัติ หมายความว่าการจัดการสิทธิ์ทั้งหมดจะต้องดำเนินการผ่าน PowerShell

หลังจากตรวจสอบให้แน่ใจว่าบัญชีที่ใช้มีสิทธิ์ Directory.ReadWrite.All และ Application.ReadWrite.All (เพื่ออัปเดต Azure AD และรายละเอียดแอปพลิเคชัน) นี่คือวิธีที่ฉันมอบหมาย บทบาทการจัดการทีมต่อหัวหน้าฝ่ายบริการ:

# Fetch details of the Teams management app
$TeamsApp = Get-MgServicePrincipal -Filter "AppId eq '48ac35b8-9aa8-4d74-927d-1f4a14a0b239'"  
$AppPermission = $TeamsApp.AppRoles | Where-Object {$_.DisplayName -eq "Application_access"} # Create the payload for the assignment
$AppRoleAssignment = @{
    "PrincipalId" = $ManagedIdentity.Id
    "ResourceId" = $TeamsApp.Id
    "AppRoleId" = $AppPermission.Id }
# Assign the role to the service principal for the managed identity.
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

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

$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" # Microsoft Graph
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq  'ChannelMember.ReadWrite.All'}
$AppRoleAssignment = @{
    "PrincipalId" = $ManagedIdentity.Id
    "ResourceId" = $GraphApp.Id
    "AppRoleId" = $Role.Id }
# Assign the Graph permission
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

หากคุณทำผิดพลาดและมอบหมายสิทธิ์ที่ไม่จำเป็น คุณสามารถลบออกได้โดยการค้นหาตัวระบุสำหรับการมอบหมายสิทธิ์ในชุดที่ถือโดยบริการหลัก และเรียกใช้ Remove-MgServicePrincipalAppRoleAssignment cmdlet. ต่อไปนี้คือสิ่งที่ฉันทำเพื่อลบสิทธิ์ TeamWork.Migrate.All

[Array]$SPPermissions = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq "TeamWork.Migrate.All"}
$Assignment = $SpPermissions | Where-Object {$_.AppRoleId -eq $Role.Id}
Remove-MgServicePrincipalAppRoleAssignment -AppRoleAssignmentId $Assignment.Id -ServicePrincipalId $ManagedIdentity.Id

มีสองสิ่งที่อาจเข้ามาในใจของคุณ ณ จุดนี้ ขั้นแรก ขั้นตอนทั้งหมดเหล่านี้ได้รับการจัดทำโดย Microsoft หรือไม่ และประการที่สอง เหตุใดกระบวนการจัดการสิทธิ์สำหรับข้อมูลประจำตัวที่ได้รับการจัดการจึงซับซ้อนมาก มุมมองของฉันคือพื้นที่ขาดเอกสารที่สอดคล้องกัน Microsoft ครอบคลุมพื้นฐานในที่ต่างๆ แต่นำทุกอย่างมารวมกันเพื่อทำให้การจัดการสิทธิ์สำหรับข้อมูลประจำตัวที่มีการจัดการ ดูเหมือนจะไม่เกิดการดำเนินการที่ตรงไปตรงมา ในทางกลับกัน Microsoft ปล่อยให้คนอื่นนำทฤษฎีนี้ไปปฏิบัติ

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

การโพสต์ไปยังทีม

ตามที่กล่าวไว้ข้างต้น ฉันต้องการให้สคริปต์แสดงรายละเอียดของสมาชิกใหม่ในช่อง มีสองประเด็นที่นำเสนอ:

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

ฉันใช้ Azure KeyVault เพื่อจัดเก็บข้อมูลประจำตัวผู้ใช้และข้อมูลอื่นๆ ที่จำเป็นในการเชื่อมต่อกับ PnP การจัดเก็บข้อมูลนี้ใน Azure Key Vault ทำให้ง่ายต่อการเปลี่ยนบัญชีที่ใช้ในการโพสต์ข้อความหรือช่องทางเป้าหมาย ในการโพสต์ข้อความ ฉันใช้โค้ดเดียวกันกับที่อธิบายไว้ในบทความนี้มากเพื่อสร้างส่วนเนื้อหา HTML ที่มีรายละเอียดของสมาชิกใหม่ของช่อง (รูปที่ 3)

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

การเรียนรู้และข้อสรุป

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

การจัดการความเสี่ยงด้านความปลอดภัยทางไซเบอร์สำหรับ Active Directory

ค้นพบวิธีการป้องกันและกู้คืนจากการโจมตี AD ผ่านโซลูชันการจัดการความเสี่ยงด้านความปลอดภัยทางไซเบอร์เหล่านี้

บทความที่เกี่ยวข้อง