การเชื่อมต่อกับ Microsoft Graph โดยใช้ PowerShell SDK

เชื่อมต่อกับกราฟด้วยวิธีที่ปลอดภัยและมีประสิทธิภาพ

อัปเดต: 1 สิงหาคม 2023

ในบทความก่อนหน้านี้ ฉันหารือเกี่ยวกับการใช้ cmdlets จาก Microsoft Graph SDK สำหรับ PowerShell เพื่อแทนที่ cmdlets การจัดการสิทธิ์การใช้งานจากโมดูล Azure AD ก่อนที่จะยุติการให้บริการในวันที่ 30 มิถุนายน 2022 (อัปเดต : Microsoft ได้ย้ายวันที่นี้ออกไปเป็นเดือนมีนาคม 2024) ปรากฎว่าการแปลง Azure AD cmdlets สองสามรายการด้วยการแทนที่ด้วย cmdlets เช่น Get-MgUser และ Set-MgUserLicense นั้นไม่ใช่เรื่องยากเป็นพิเศษ (หากเป็นเช่นนั้น ฉัน จะทำไม่ได้) อย่างไรก็ตาม การแนะนำโมดูลใหม่ให้เป็นการผสมผสานของ PowerShell ที่ใช้ในสภาพแวดล้อมการผลิตมักจะทำให้เกิดคำถามและข้อกังวลบางประการ อย่างน้อยก็คือเรื่องความปลอดภัย

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

กำลังเชื่อมต่อกับกราฟ SDK

ขั้นตอนแรกในการใช้งาน Graph SDK คือการเชื่อมต่อกับกราฟโดยใช้ Connect-MgGraph cmdlet เมื่อคุณเรียกใช้ Connect-MgGraph เพื่อเชื่อมต่อกับกราฟ ก็ควรที่จะระบุตัวระบุของผู้เช่าที่คุณต้องการเชื่อมต่อ

Connect-MgGraph -TenantId "828e1143-88e3-492b-bf82-24c4a47ada63"

หากคุณไม่ระบุผู้เช่า Connect-MgGraph จะเลือกผู้เช่าคนสุดท้ายที่คุณลงชื่อเข้าใช้ในระหว่างเซสชัน (ซึ่งอาจไม่ใช่ผู้เช่าที่คุณต้องการเชื่อมต่อด้วย) ฉันค้นพบสิ่งนี้เมื่อฉันเชื่อมต่อกับกราฟ และพบว่าข้อมูลที่ใช้เป็นของผู้เช่าการพัฒนาของฉัน ฉันสังเกตเห็นแล้ว แต่อาจเป็นไปได้ที่บางคนอาจพลาดสิ่งนี้ไปที่อื่น ดังนั้น สร้างนิสัยในการเชื่อมต่อกับตัวระบุผู้เช่า

เซสชันจะคงอยู่จนกว่าคุณจะเรียกใช้ Disconnect-MgGraph (ดูด้านล่าง) และสามารถเริ่มต้นใหม่ได้หลายครั้งในแต่ละวันโดยการเรียกใช้ Connect-MgGraph เบื้องหลัง Graph SDK จะเก็บแคชโทเค็นที่เข้ารหัสไว้ และจะรีเฟรชโทเค็นตามความจำเป็นเพื่อให้คุณทำงานกับคำสั่งกราฟได้

สิทธิ์

หลังจากทำการเชื่อมต่อสำเร็จ เซสชั่นจะลงชื่อเข้าใช้เป็นบัญชีของคุณ ขอบเขตสิทธิ์สำหรับการเชื่อมต่อมาจากบริการหลัก (แอปองค์กร) ที่ลงทะเบียนใน Azure AD สำหรับ SDK หากคุณไม่เคยลงชื่อเข้าใช้ด้วย Graph SDK มาก่อน SDK จะสร้างแอประดับองค์กรชื่อ เครื่องมือบรรทัดคำสั่ง Microsoft Graph โดยมี AppId เป็น 14d82eec-204b-4c2f-b7e8-296a70dab67e และขอชุดสิทธิ์ที่จำกัด (รูปที่ 1) หากคุณเป็นผู้ดูแลระบบ คุณสามารถให้ความยินยอมสำหรับสิทธิ์เหล่านี้ในนามขององค์กรได้ เพื่อคลายข้อสงสัยอันสมเหตุสมผลของผู้ดูแลระบบที่ระมัดระวัง คงจะดีไม่น้อยหากหัวหน้าฝ่ายบริการแสดงตนว่าได้รับการยืนยันแล้ว แต่นั่นไม่ได้เป็นเช่นนั้นในปัจจุบัน

สิทธิ์ที่ได้รับความยินยอมสำหรับ Microsoft Graph PowerShell SDK นั้นถือเป็นบริการหลักของแอประดับองค์กร

การรวบรวมสิทธิ์ใหม่

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

$RequiredScopes = @("Directory.AccessAsUser.All", "Directory.ReadWrite.All")
Connect-MgGraph -Scopes $RequiredScopes

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

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

เมื่อเวลาผ่านไป สิทธิ์ที่ถือโดยบริการหลักของ SDK จะเป็นสิทธิ์ที่ได้รับในช่วงเวลาเริ่มต้นของการยินยอม บวกกับสิทธิ์อื่น ๆ ที่ได้รับในภายหลังในขณะที่ผู้คนทำงานกับไคลเอนต์แบบโต้ตอบ กล่าวอีกนัยหนึ่ง ผู้ให้บริการหลักจะรวบรวมสิทธิ์แบบรวมเมื่อเวลาผ่านไป ด้วยเหตุนี้ จึงไม่แนะนำให้ใช้ Graph SDK cmdlets แบบโต้ตอบ เพราะหากคุณทำเช่นนั้น เมื่อเวลาผ่านไป อาจเป็นไปได้ที่บริการหลักจะได้รับอนุญาตมากเกินไป และดังนั้นจึงกลายเป็นความเสี่ยงด้านความปลอดภัย นี่คือปัญหาประเภทที่เน้นโดย App Governance สำหรับ Cloud App Security (หรือในโซลูชันที่พัฒนาขึ้นเองซึ่งอธิบายไว้ในบทความนี้) นอกจากนี้ คุณควรใส่ใจกับแอปที่ได้รับมอบหมายสิทธิ์ที่มีลำดับความสำคัญสูง เนื่องจากเป็นแอปที่ผู้โจมตีอาจปลูกฝังหรือแสวงหาผลประโยชน์

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

$Sp = Get-MgServicePrincipal -Filter "AppId eq '14d82eec-204b-4c2f-b7e8-296a70dab67e'"
Remove-MgServicePrincipal -ServicePrincipalId $Sp.Id

กำลังเชื่อมต่อกับโปรไฟล์เบต้า

ในบางสถานการณ์ คุณจะต้องใช้โปรไฟล์เบต้าเพื่อเข้าถึงคำสั่งและข้อมูลบางอย่าง ซึ่งเทียบเท่ากับการระบุตำแหน่งข้อมูลเบต้าเมื่อออกคำสั่ง Graph API หากต้องการเลือกโปรไฟล์เบต้า ให้เรียกใช้ Select-MgProfile cmdlet:

Select-MgProfile beta

อัปเดต: V2.0 ของ Microsoft Graph PowerShell SDK ขจัดความจำเป็นสำหรับ Select-MgProfile cmdlet แต่ beta cmdlets จะอยู่ในโมดูลที่แยกจากกันแทน

รายงานการเชื่อมต่อของคุณ

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

$Details = Get-MgContext
$Scopes = $Details | Select -ExpandProperty Scopes
$Scopes = $Scopes -Join ", "
$OrgName = (Get-MgOrganization).DisplayName
CLS
Write-Host "Microsoft Graph Connection Information"
Write-Host "--------------------------------------"
Write-Host " "
Write-Host ("Connected to Tenant {0} ({1}) as account {2}" -f $Details.TenantId, $OrgName, $Details.Account)
Write-Host "+-------------------------------------------------------------------------------------------------------------------+"
Write-Host ("Profile set as {0}. The following permission scope is defined: {1}" -f $ProfileName, $Scopes)
Write-Host ""

Microsoft Graph Connection Information
--------------------------------------

Connected to Tenant a662313f-14fc-43a2-9a7a-d2e27f4f3475 (Office 365 for IT Pros) as account Global.Administrator@office365itpros.com
+-------------------------------------------------------------------------------------------------+
The following scopes are defined: Directory.AccessAsUser.All, Directory.ReadWrite.All, openid, profile, User.Read, email, Group.Read.All, Group.ReadWrite.All 

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

ตัดการเชื่อมต่อเมื่อคุณทำเสร็จแล้ว

เมื่อคุณโต้ตอบกับกราฟเสร็จแล้ว อย่าลืมปิดเซสชันด้วยการเรียกใช้ Disconnect-MgGraph เพื่อลงชื่อเซสชันออกจากกราฟ การยกเลิกการเชื่อมต่อเซสชันจะลบการเข้ารหัสที่เข้ารหัสไว้ แคชโทเค็นและป้องกันไม่ให้เซสชันเริ่มต้นใหม่

Disconnect-MgGraph

การเข้าถึงเฉพาะแอปสำหรับการใช้งานจริง

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

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

อีกทางเลือกหนึ่งคือการใช้ Azure Automation กับข้อมูลประจำตัวที่ได้รับการจัดการเพื่อเรียกใช้สคริปต์ที่ใช้ SDK cmdlets ดูบทความนี้สำหรับข้อมูลเพิ่มเติม

ปัญหาบางอย่างสำหรับ Microsoft ที่ต้องแก้ไข

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

ความจริงของเรื่องนี้ก็คือ ผู้ดูแลระบบผู้เช่าจะลืมเกี่ยวกับปัญหาการสะสมสิทธิ์ เว้นแต่พวกเขาจะตรวจสอบหลักการบริการ มันน่าเศร้าแต่จริงและเนื่องมาจากความต้องการของงานอื่น ผู้คนจะไม่เรียกใช้ Disconnect-MgGraph ด้วยเหตุผลเดียวกันกับที่ cmdlets เช่น Disconnect-MicrosoftTeams และ Disconnect-ExchangeOnline จะถูกละเว้น

Graph SDK เป็นแนวคิดที่ยอดเยี่ยม เนื่องจากแยกผู้ใช้ PowerShell ออกจากความซับซ้อนต่างๆ ที่เกี่ยวข้องกับการใช้ Graph API ยังคงอยู่ในระหว่างดำเนินการ แต่หาก Microsoft ต้องการทำให้ Graph SDK เป็นเครื่องมือที่ผู้ดูแลระบบผู้เช่าไปใช้ พวกเขาจำเป็นต้องแก้ไขปัญหาสิทธิ์ และเร็วๆ นี้ (ก่อนถึงเส้นตายการเลิกใช้งาน!)