הגדרת משרת ראשי של Azure: מדריך לגישה בלתי מגורמת

כשתרצה לאוטומציה של משימות ב-Azure עם תסריטים וכלים, האם תשקול להשתמש בחשבונות שירות או בסוכני שירות של Azure? בדרך כלל אנשים יוצרים חשבון שירות חדש, מוסיפים לו את כל התפקידים המנהליים שרוצים ומשמיטים את התיבה ללא מקורות אימות נוספים.

I know what you’re thinking – “that is a horrible idea”. Of course, it is! And for sure, your IT Sec will give you a lot of grief if you did all that.

אבל מה האלטרנטיבה? איך ניתן להשתמש בסיומת ממושכת עם היתר מוגבל שאין צורך למנוע ממנה אימות רב-גורם (MFA)? אתה מזל טוב כי בדיוק זה שהמאמר הזה ילמד אותך.

במאמר הזה, תלמד על מהו "Azure Service Principal". תלמד כיצד ליצור סוכנים שירות עם סוגים שונים של היתרים, כמו סיסמאות, מפתחות סודיים ותעודות.

קיימים המון כלים ליצירת "Azure Service Principals". כלים אלו כוללים את השימוש ב-פורטל Azure, מרכז הניהול של Azure Active Directory, Azure AD PowerShell, Azure CLI ו-Azure PowerShell. הכלי שישמש כמוקד במאמר הזה הוא Azure PowerShell.

עדיין מעוניין? תמשיך לקרוא ונתחיל!

דרישות

מאחר שזהו מאמר למידה דרך ניסיון, הנה כמה דרישות מראש כדי שתוכל לעקוב אחריו.

• גישה למנוי Azure. יהיה טוב אם תעבוד על סביבת ניסיון. אם אין לך כזו, תוכל להירשם לניסיון חינם.
• גישה למחשב הרץ על Windows 10 עם PowerShell 5.1.
• חייב להיות מותקן המודול Azure PowerShell.

משאב שירות Azure Principal נגד חשבון שירות

כלי אוטומציה וסקריפטים דורשים לעיתים גישה מנהלית או גישה בעלת זכויות מיוחדות. לדוג, הקמת חשבונות אחסון או הפעלה וכיבוי של מכונות וירטואליות לפי קובע. רוב המנהלים ישתמשו כנראה בחשבון משתמש בעל זכויות מלאות (נקרא גם חשבון שירות) כדי להגדיר את דרישות האימות לסקריפטים.

A service account is essentially a privileged user account used to authenticate using a username and password. And, if used with automation, a service account is most likely excluded from any conditional access policies or multi-factor authentication.

מצד שני, ניתן להקים את משאב השירות של Azure כך שישמש שם משתמש וסיסמה או תעודת אימות. חשוב לראות את זה כזהות משתמש ללא השתמשות ממשתמש, אלא כזהות ליישום.

ניתן להקצות למשאב שירות של Azure גישה מספיקה לכמה שפחות של משאבי Azure ספציפיים. לדוג, ניתן ליצור משאב שירות שירות שיש לו גישה על סמך תפקיד למנוי שלם או למכונת וירטואלית יחידה בלבד.

השקפות ראשוניות ליצירת מנהלי שירות Azure

לפני שתיצור מנהל שירות Azure, עליך לדעת את הפרטים הבסיסיים שצריך לתכנן. ייתכן שהפרטים הללו ייראו פשוטים, אך הם יגרמו ליצירת מנהל שירות Azure להיות יעילה וקלה ככל הניתן.

שם התצוגה. הכל מתחיל עם שם, ולמנהל שירות Azure חייב להיות שם. אין כלל כאן, אך ייתכן שיש לארגון שלך הוראות שמציינות את הסדר שבו יש לתת שמות.

• סוג הזיהוי לשימוש. ניתן לבחור ליצור מנהל שירות Azure שישתמש בסיסמה או בתעודת אימות. זה לא אומר שאפשר לבחור רק אחד, ניתן להשתמש בשניים.

במקרה של מנהלי שירות, שם המשתמש והסיסמה מתייחסים בצורה מתאימה יותר למזהה אפליקציה ולמפתח סודי.

• תקופת תוקפנות של הזיהוי(ים). בין אם אתה משמין סיסמה או תעודת אימות, עליך להגדיר תאריכי התקפות התעודה. כמה זמן תוקף יהיה לתעודה בדרך כלל תלוי בתדירות שאתה מוכן לסובל ברובר ולחדש סיסמאות ותעודות.

• היקף הגישה. האם אתה יוצר מנהל שירות Azure שיהיה לו גישה למינוי, קבוצת משאבים או משאבים נבחרים?

• התפקיד. ישנם מספר תפקידים זמינים, כגון תורם, קורא, ו- בעלים, לדוגמה. עליך להגדיר איזה תפקיד הוא "די" למנהל השירות.

יצירת עקרון שירות Azure עם מפתח סודי המוקצה אוטומטית

לב הוא יצירת עקרון שירות חדש ב-Azure הוא הפקודה New-AzAdServicePrincipal. בדוגמה זו, ייווצר עקרון שירות חדש עם הערכים הבאים:

DisplayName: AzVM_Reader

Scope: AzVM1 (מכונה וירטואלית)

Role: Reader

Password: <מוקצה אוטומטית>

תוקף האישור: 1 שנה

קבלת זיהוי הטווח המטרה (מכונה וירטואלית)

כפי שניתן לראות, טווח העקרון שירות החדש הוא רק עבור המכונה הווירטואלית בשם AzVM1. אך, הפרמטר -Scope אינו מקבל רק את השם, אלא את כל הזיהוי של המשאב. לכן, בדוגמה זו, הדבר הראשון שעליך לעשות הוא לקבל את זיהוי המכונה הווירטואלית AzVM1. כדי לעשות זאת, השתמש בקוד שלמטה.

Get-AzVM | Format-Table Name, ID

כאשר אתה מפעיל את הקוד שלמעלה ב-PowerShell, אתה אמור לראות את רשימת שמות ומזהי VM, דומה לצילום המסך למטה.

יצירת עקרון שירות Azure עם מפתח סודי

עכשיו שיש לך את הזיהוי של הטווח המטרה, שהוא זיהוי המכונה הווירטואלית AzVM1, אתה יכול להשתמש בפקודה למטה כדי ליצור את עקרון השירות החדש שיש לו תפקיד reader. מאפייני עקרון השירות החדש יישמרו במשתנה $sp.

$sp = New-AzAdServicePrincipal `
	-DisplayName AzVM_Reader `
	-Scope '/subscriptions/5e252811-b376-4136-b8ae-d3b8abe2c9c3/resourceGroups/ATA/providers/Microsoft.Compute/virtualMachines/AzVM1'
	-Role 'Reader'

כתוצאה מהפקודה למעלה, נוצר עקרון השירות עם הערכים הבאים למטה.

פיענוח המפתח הסודי

עכשיו יש לך את ApplicationID ו-Secret, שהם שם משתמש וסיסמה של הפרטי שירות. אולם, ערך ה-Secret מוצג כ-System.Security.SecureString. תרצה לדעת מהו הסוד. לכך, השתמש בפקודה להמרת הסוד לטקסט פשוט מטה.

# המרת הסיסמה המוצפנת לטקסט פשוט
[System.Runtime.InteropServices.Marshal]::PtrToStringAuto(
    [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR(
        $sp.Secret
    )
)

הפקודה מעלה ממירה את ערך מחרוזת האבטחה של $sp.Secret לטקסט פשוט. ראה את התמונה מתחת להפנייה.

אימות הקצאת תפקיד לפרטי שירות Azure

איך תדע שעבד? ניתן לבדוק את רשימת הבקרת גישה של המשאב באמצעות פורטל Azure. לדוגמה, בתמונה מתחת אפשר לראות כי לפרטי שירות AzVM_Reader כעת יש גישה מסוג Reader למכונת הוירטואלית AzVM1.

בנוסף, ניתן להשתמש בפקודה Get-AzRoleAssignment -ObjectID $sp.id כדי לקבל את הקצאות התפקיד של פרטי השירות Azure. ראה את תמונת המסך מתחת כדי לקבל דוגמה.

יצירת פרטי שירות Azure עם סיסמה

אם ברצונך לקבל שליטה נוספת על הסיסמה או המפתח הסודי שמוקצה לפרטי השירות Azure שלך, השתמש בפרמטר -PasswordCredential במהלך יצירת הפרטי השירות. זה מיועד במיוחד אם הסיסמה חייבת לעמוד בדרישת מורכבות.

בדוגמה זו, פרטי שירות Azure החדש ייווצרו עם הערכים הבאים:

שם תצוגה: ATA_RG_Contributor

היקף: ATA (קבוצת משאבים)

תפקיד: תורם

סיסמה: 20 תווים ארוכה עם 6 תווים לא-אלפא-נומריים

תוקפות האישוש: 5 שנים

קבלת זיהוי של התחום המטרה (קבוצת משאבים)

התחום של פרינסיפל שירות חדש זה מכסה את כל קבוצת המשאבים הנקראת ATA. הדבר הראשון שצריך לעשות הוא לקבל את זיהוי הקבוצת משאבים ATA. כדי לעשות זאת, עליך להשתמש בקוד למטה, אך ורק וודא שתשנה את ערך הפרמטר -שם לשם קבוצת המשאבים שלך.

# קבל את ערך ResourceId של קבוצת המשאבים
$Scope = (Get-AzResourceGroup -Name ATA).ResourceId
$Scope

לאחר מכן, אתה צריך לראות את ה־ResourceID של קבוצת המשאבים שכעת מאוחסן במשתנה $Scope.

יצירת מחרוזת הסיסמה

השלב הבא הוא ליצור את הסיסמה שעוקבת אחרי רמת הקושי 20 תווים ארוכה עם 6 תווים לא-אלפא-נומריים. עבור זאת, אתה יכול להשתמש בשיטת הסטטית .NET GeneratePassword().

# יצירת סיסמה אקראית באמצעות שיטת הסטטית GeneratePassword()
Add-Type -AssemblyName 'System.Web'
$password = [System.Web.Security.Membership]::GeneratePassword(20, 6)
$password

בקוד לעיל GeneratePassword(20, 6), הערך הראשון משמעותו אורך הסיסמה, והערך השני משמעותו מספר התווים לא-אלפא-נומריים לכלול. התוצאה מוצגת בצילום המסך למטה.

יצירת אובייקט כרטיס אישוש

עכשיו שיש לך את מחרוזת הסיסמה, השלב הבא הוא ליצור את אובייקט ה־Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential. אובייקט זה יכיל את מחרוזת הסיסמה שמאוחסנת במשתנה $password ואת תקופת התוקף של 5 שנים. העתק את הקוד למטה והרץ אותו בסשן שלך ב־PowerShell של Azure.

# יצירת אובייקט תעודת סיסמה
[Microsoft.Azure.Commands.ActiveDirectory.PSADPasswordCredential]`
    $PasswordCredential = @{
    StartDate = Get-Date;
    EndDate   = (Get-Date).AddYears(5);
    Password  = $password
}
$PasswordCredential

הרצת הקוד למעלה בפוורשל תצפה ביצירת אובייקט האישור למשתנה $PasswordCredential. התוצאה הצפויה דומה לזו המוצגת למטה.

יצירת העקרונות של שרות ראשי עם סיסמה

עכשיו יש לך את ערכי הפרמטרים הנדרשים ליצירת שרות ראשי ב־Azure. הקוד למטה ייצור את שרות הראשי עם שם התצוגה ATA_RG_Contributor וישתמש בסיסמה שמאוחסנת במשתנה $PasswordCredential.

# יצירת שרות ראשי עם אישור סיסמה
$sp = New-AzAdServicePrincipal `
    -DisplayName 'ATA_RG_Contributor' `
    -PasswordCredential $PasswordCredential
$sp

לאחר הרצת הקוד, יש ליצור את שרות הראשי החדש, והמאפיינים יאוחסנו במשתנה $sp. ראה את התוצאה הדוגמא למטה.

הקצאת התפקיד והתחום

שרות הראשי של Azure נוצר בסעיף הקודם, אך ללא תפקיד ו־תחום. הזאת בגלל שהפרמטרים -Role ו־-Scope לא יכולים להיות בשימוש יחד עם הפרמטר -PasswordCredential. כך שיש צורך בשלב נוסף להקצאת התפקיד והתחום לשרות ראשי.

הקוד למטה משתמש ב־cmdlet New-AzRoleAssignment כדי להקצות את התחום והתפקיד של הסוכן שירות Azure.

# להקצאת התפקיד למשאב היעד
New-AzRoleAssignment -$azSubscription = Get-AzSubscription -SubscriptionName VSE3
$Scope = "/subscriptions/$($azSubscription.ID)"
$TenantID = $azSubscription.TenantID$sp.ApplicationId `
    -Scope $Scope `
    -RoleDefinitionName 'Contributor'

התמונה למטה מציגה את התוצאה הצפויה לאחר שהתפקיד והתחום הוקצו לסוכן השירות Azure.

תמיד ודא שתשמור על סיסמת הסוכן השירות, מכיוון שאין דרך לשחזר אותה אם לא ייתכן לך לשמור עליה או ששכחת אותה.

התחברות ל־Azure עם סיסמת סוכן שירות

עכשיו נכנסים לעסקה עם הסוכן שירות. במקום להתחבר ל־Azure PowerShell באמצעות חשבון משתמש, הקוד למטה משתמש בפרטי הכניסה של הסוכן שירות במקום זאת.

# קבל את המרכז השירותי עם השם לתצוגה ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# קבל את זהות השוכר
$TenantID = (Get-AzContext).Tenant.ID

# קבל את שם המרכז השירותי הראשון
$user = $sp.ServicePrincipalNames[0]

# המרת הסיסמה למחרוזת מאובטחת
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# צור את אובייקט ה-PSCredential
$credential = [PSCredential]::New($user,$secPassword)

# התחבר ל-Azure
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID
# קבל את המרכז השירותי עם השם לתצוגה ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# קבל את זהות השוכר
$TenantID = (Get-AzContext).Tenant.ID

# קבל את שם המרכז השירותי הראשון
$user = $sp.ServicePrincipalNames[0]

# המרת הסיסמה למחרוזת מאובטחת
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# צור את אובייקט ה-PSCredential
$credential = [PSCredential]::New($user,$secPassword)

# התחבר ל-Azure
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID# קבל את המרכז השירותי עם השם לתצוגה ATA_RG_Contributor
$sp = Get-AzADServicePrincipal -DisplayName ATA_RG_Contributor

# קבל את זהות השוכר
$TenantID = (Get-AzContext).Tenant.ID

# קבל את שם המרכז השירותי הראשון
$user = $sp.ServicePrincipalNames[0]

# המרת הסיסמה למחרוזת מאובטחת
$secPassword = $password | ConvertTo-SecureString -AsPlainText -Force

# צור את אובייקט ה-PSCredential
$credential = [PSCredential]::New($user,$secPassword)

# התחבר ל-Azure
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $TenantID

לאחר הרצת הקוד לעיל, אתה צריך להיות מחובר ל-Azure PowerShell באמצעות הכניסה בשם שירות של ATA_RG_Contributor ובאמצעות כרטיס האשראי סיסמה.

יצירת שולחן שירות של Azure עם אישור

למעט כרטיסי אשראי, לשולחן שירות של Azure יש אפשרות גם להכיל אישור באמצעות אישור תעודה. התעודה המשויכת יכולה להיות תעודה שניתנה על ידי רשות תעודות או תעודה שנפתחת עצמית.

בדוגמה זו, שולחן שירות של Azure החדש ייווצר עם הערכים הבאים:

שם תצוגה: VSE3_SUB_OWNER

היקף: VSE3 (מינוי)

תפקיד: בעלים

תקפות תעודה: 2 שנים

השגת מזהה ליעד (מינוי)

ההיקף של שולחן השירות החדש מכסה את המינוי בשם VSE3. הדבר הראשון שצריך להשיג הוא המזהה של המינוי VSE3. כדי לעשות זאת, יש להשתמש בקוד הבא, אך יש לוודא ששינית את הערך של הפרמטר -SubscriptionName לשם קבוצת המשאבים שלך.

# Get the ID of the Subscription scope and the Tenant ID
$azSubscription = Get-AzSubscription -SubscriptionName VSE3
$Scope = "/subscriptions/$($azSubscription.ID)"
$TenantID = $azSubscription.TenantID

לאחר מכן, יש לציין את שם שולחן השירות החדש של Azure ואת תעודת התעודה העצמית שיוצרו.

# שם שולחן השירות החדש של Azure ותעודת התעודה העצמית
$DisplayName = 'VSE3_SUB_OWNER'

יצירת תעודת התעודה העצמית

הקוד למטה יוצר את הסיסמה החתומה עצמית באחסון התעודות האישיות עם השם CN=VSE3_SUB_OWNER. תקופת תוקפו של התעודה מוגדרת לשנתיים. מאפייני התעודה נשמרים במשתנה $cert.

# יצירת תעודת חתימה עצמית
$cert = New-SelfSignedCertificate -CertStoreLocation "cert:\CurrentUser\My" `
    -Subject "CN=$($DisplayName)" `
    -KeySpec KeyExchange `
    -NotBefore ((Get-Date).AddDays(-1)) `
    -NotAfter ((Get-Date).AddYears(2))
$cert

המסך למטה מראה שהתעודה נוצרה.

אם ברצונך לראות את התעודה החדשה בתצוגה ידועה יותר (GUI), תוכל למצוא אותה בתקליטור התעודות (certmgr.mmc). יש להסתכל על התמונה למטה המציגה את התעודה.

השלב הבא הוא לקבל את הערך המוצפן ב־Base64 של התעודה החתומה עצמית ולשמור אותו במשתנה $keyValue.

# לקבלת הערך ב־base64 של התעודה החתומה עצמית
$keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData())

יצירת ה־Service Principal עם תעודה

עכשיו שהתעודה נוצרה, השלב הבא הוא ליצור את ה־Azure service principal החדש. הקוד למטה ייצור את ה־Azure service principal שישתמש בתעודה החתומה עצמית כאישור שלו. תקופת תוקפו של האישור מתאימה לתקופת התוקפן של התעודה.

$sp = New-AzADServicePrincipal -DisplayName $DisplayName `
    -CertValue $keyValue `
    -EndDate $cert.NotAfter `
    -StartDate $cert.NotBefore
$sp

תקבל פלט דומה, כפי שמוצג בתמונה למטה.

השמה של התפקיד והתחום

ה־Azure service principal נוצר, אך לא הוקצו עדיין תפקיד ו־תחום. זה אומר שנדרש צעד נוסף להקצאת התפקיד והתחום ל־service principal.

הקוד למטה משתמש בפקודת New-AzRoleAssignment כדי להקצות את התפקיד של בעלים למנוי VSE3 של הסובייקט שירות.

# להקצאת תפקיד וטווח
New-AzRoleAssignment -ApplicationId $sp.ApplicationId `
    -Scope $Scope `
    -RoleDefinitionName 'Owner'

כאשר הקוד מורץ, בלוח המחוונים למטה מוצג אישור שההקצאת תפקיד בוצעה.

חיבור ל-Azure עם תעודת Service Principal Certificate

עכשיו יש לך סובייקט שירות עם כניסה על בסיס תעודה. זה אומר שתוכל להתחבר ל-Azure בלי להשתמש בסיסמה. במקום זאת, תשתמש בתעודה הזמינה במחשבך כאמצעי אימות.

בדוגמה זו, שם התצוגה של הסובייקט שירות הוא VSE3_SUB_OWNER, ושם התעודה הוא CN=VSE3_SUB_OWNER. הקוד למטה יקבל את טמפלייט התעודה מחנות התעודות האישית וישתמש בו כאמצעי התחברות.

# לקבל את התעודה עם נושא CN=VSE3_SUB_OWNER
$cert = Get-ChildItem Cert:\CurrentUser\My\ | Where-Object { $_.Subject -eq 'CN=VSE3_SUB_OWNER' }

# להתחבר ל-Azure
Connect-AzAccount -ServicePrincipal -CertificateThumbprint $cert.ThumbPrint -ApplicationID $sp.ApplicationID -Tenant $TenantID

בלוח המחוונים למטה מוצג שבאמצעות הקוד לעיל, התחברות ל-Azure PowerShell הצליחה בהצלחה באמצעות ApplicationID, Tenant, ו־Certificate ThumbPrint בלבד.

סיכום

סובייקטי שירות של Azure הם הסובייקטים הבטחוניים שחשוב לשקול כאשר יוצרים אישורים למשימות אוטומציה וכלים שגושרים על משאבי Azure. ניתן לבחור את הטווח והתפקיד שיש ליישם כדי לתת הרשאות גישה "מספיק רק".

במאמר זה, למדת כיצד ליצור את Azure Service Principals באמצעות PowerShell. Azure Service Principals יכולים להיות עם סיסמה, מפתח סודי או אישור מבוסס תעודה. לכל אחת מהאפשרויות הללו של תעודות יש את יתרונותיה הספציפיים והתרחישים בהם הן מתאימות.

Service principals עם תעודת סיסמה או מפתח סודי הם ניידים יותר אך נחשבים פחות בטוחים מאחר והפרטים האישיים עשויים להיות משותפים כטקסט פשוט. מצד שני, תעודות מבוססות תעודה הן האפשרות הבטוחה יותר אך מחייבות מאמץ נוסף לשמירה עליהן.

הטכניקות שלמדת במאמר זה כיסו רק את היסודות כדי להתחיל להשתמש ב-Azure service principals באוטומציה שלך. ישנם עוד הרבה דרכים להגדיר service principals של Azure כגון הוספת, הסרת ואיפוס פרטי אימות. תלוי בך לגלות אותם במהלך העבודה שלך.

תודה על הקריאה!

משאבי למידה נוספים

הנה כמה משאבים שעשויים להיות מועילים להלוואה עם מאמר זה.

• Connect-AzAccount: שערך הגישה ל-Azure עם PowerShell
• Connect-AzAccount: שערך הגישה ל-Azure עם PowerShell
• כיצד ליצור סיסמה אקראית עם PowerShell
• מהו בקרת גישה מבוססת תפקיד Azure (Azure RBAC)?
• שחזור האניגמות של נציגי שירות Azure AD
• כיצד ליצור נציג שירות Azure דרך ה-CLI של Azure 2.0
• איך לשלוט בגישה לשירותי Office 365 עם MFA