建立服務主體和金鑰
既然您已了解服務主體的概念，您可能會想知道其如何向 Microsoft Entra ID 證明身分識別。 在本單元中，您將了解服務主體的驗證流程和認證。 您也將了解如何建立服務主體，並為其提供金鑰。
了解服務主體的驗證方式
當服務主體需要與 Azure 通訊時，則會登入 Microsoft Entra ID。 Microsoft Entra ID 驗證服務主體的身分識別之後，就會發出用戶端應用程式在對 Azure 提出任何要求時所儲存並使用的權杖。
大致上來說，此流程類似於當您以使用者的身分登入 Azure 時的運作方式。 不過，相較於使用者，服務主體可證明其身分識別的認證類型稍微不同。 服務主體會使用兩個主要認證：金鑰和憑證。
注意
請記住，受控識別是在 Azure 內運作的特殊服務主體。 它們具有不同類型的驗證流程，您完全不需要知道或處理認證。
金鑰
金鑰與密碼類似。 不過，金鑰較長且更複雜。 事實上，在大多數情況下，Microsoft Entra ID 會自行產生金鑰，以確保：
- 金鑰會以密碼編譯方式隨機進行。 也就是說，密碼很難被猜到。
- 人們不會不小心地使用弱式密碼做為金鑰。
服務主體通常具有高特殊權限，因此其安全性至關重要。 一般而言，您只需要在第一次設定服務主體和管線時，短暫地處理金鑰。 因此，金鑰不需要好記或是易於輸入。
單一服務主體可以同時具有多個金鑰，但使用者不能有多組密碼。 就像密碼一樣，金鑰具有到期日。 您很快就會深入瞭解。
注意
您可以將金鑰視為非常重要的密碼，類似於儲存體帳戶金鑰。 您應該以相同層級的安全性和照護方式來加以處理。
憑證
憑證是驗證服務主體的另一種方式。 其非常安全，但很難管理。 某些組織需要使用特定服務主體類型的憑證。
我們不會在本課程模組中討論憑證。 但是，如果您使用的是使用憑證驗證的服務主體，就管理和授與管線的權限來說，基本上其運作方式與任何其他服務主體的運作方式相同。
注意
當您可以使用憑證時，憑證是不錯的選擇。 憑證會使攻擊者更難竊取。 並且更難以攔截和修改使用憑證的要求。 不過，憑證需要更多的基礎結構，而且會有一些持續的維護負荷。
使用服務主體的金鑰
當您建立服務主體時，通常會要求 Azure 同時建立金鑰。 Azure 通常會為您產生隨機金鑰。
注意
還記得我們先前討論過的服務主體如何運作嗎？ 金鑰會儲存為應用程式註冊物件的一部分。 如果您開啟 Azure 入口網站，請查看 Microsoft Entra 設定，然後移至應用程式註冊，您也可以在該處建立及刪除金鑰。
當您建立服務主體時，Azure 會顯示您的金鑰。 這是 Azure 為您顯示金鑰的唯一時刻。 之後，您無法再擷取它。 請務必安全地複製金鑰，讓您可以在設定管線時使用。 請勿以電子郵件或其他不安全的方式分享金鑰。 如果遺失金鑰，您必須將其刪除，然後再建立一個新的金鑰。
管理 Azure Pipelines 的服務主體
當您為管線的服務主體建立金鑰時，最好立即將金鑰複製到管線的設定中。 如此一來，您可以避免不必要地儲存或傳輸金鑰。
管線工具包含以安全的方式來指定服務主體的應用程式識別碼和金鑰。 永遠不會在原始檔控制中儲存任何類型的認證。 而是在您使用 Azure Pipelines 時，使用「服務連線」。 在本課程模組中，我們只會討論如何建立服務主體和金鑰。 您將了解如何在後續課程模組中使用金鑰來設定管線。
提示
Azure Pipelines 可以自動為您建立服務主體。 在本課程模組中，您將手動建立及管理服務主體，以進一步了解發生的情況。 在其他課程模組中，為了簡單起見，會使用自動建立的方法。
建立服務主體和金鑰
您可使用 Azure CLI 來建立及管理服務主體。
注意
若想建立及修改服務主體，您必須擁有 Microsoft Entra ID 的相關權限。 在某些組織中，您可能需要管理員為您執行這些步驟。
若要建立服務主體和金鑰，請使用 az ad sp create-for-rbac 命令。 此命令會接受數個引數，並可選擇性地將角色指派給服務主體。 您將會在本課程模組的稍後部分了解此主體。 現在，以下是一個範例，說明如何建立沒有任何 Azure 角色指派的服務主體：
az ad sp create-for-rbac --name MyPipeline
當您執行此命令時，Azure CLI 會傳回具有 password 屬性的 JSON 回應。 這個屬性是服務主體的金鑰。 您無法再次取得此金鑰，因此請務必立即使用，或將其儲存在安全的地方。
注意
此 az ad sp create-for-rbac 命令會在 Microsoft Entra ID 中建立應用程式註冊、將服務主體新增至您的 Microsoft Entra 租用戶，並建立應用程式註冊的金鑰。 另一個命令 az ad sp create，則只會在您的租用戶中 (而不會在應用程式註冊) 建立服務主體。 當您建立管線的服務主體時， az ad sp create-for-rbac 通常是最合適使用的命令。
您可以使用 Azure PowerShell Cmdlet 建立及管理服務主體。
注意
若想建立及修改服務主體，您必須擁有 Microsoft Entra ID 的相關權限。 在某些組織中，您可能需要管理員為您執行這些步驟。
若要建立服務主體和金鑰，請使用 New-AzADServicePrincipal Cmdlet。 此 Cmdlet 會接受數個引數，並可選擇性地將角色指派給服務主體。 您將會在本課程模組的稍後部分了解此主體。 現在，以下是一個範例，說明如何建立沒有任何 Azure 角色指派的服務主體：
$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline
當您執行此命令時，Azure PowerShell 會將服務主體的相關資訊 (包括金鑰) 填入 servicePrincipal 變數：
$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText
您無法再次取得此金鑰，因此請務必立即使用，或將它儲存在安全的地方。
注意
此 New-AzADServicePrincipal Cmdlet 會在 Microsoft Entra ID 中建立應用程式註冊、將服務主體新增至您的 Microsoft Entra 租用戶，並建立應用程式註冊的金鑰。
識別服務主體
服務主體有數個識別碼和名稱，可用來識別及使用服務主體。 您看到的識別碼多半為：
- [應用程式識別碼]：應用程式註冊有一個唯一識別碼，通常稱為 應用程式識別碼，有時也稱為 用戶端識別碼。 當服務主體登入 Azure 時，您通常會使用它做為使用者名稱。
- 物件識別碼：應用程式註冊和服務主體都各別擁有物件識別碼，也就是 Microsoft Entra ID 所指派的唯一識別碼。 有時候，當您管理服務主體時，您將需要使用這些物件識別碼。
- [顯示名稱]：此為人們可讀取的名稱，可描述服務主體。
提示
針對您的服務主體使用清楚、描述性的顯示名稱。 請務必協助您的小組瞭解服務主體的用途，以避免任何人不小心刪除或變更其權限。
警告
顯示名稱不是唯一的。 多個服務主體可能會共用相同的顯示名稱。 當您使用其顯示名稱來識別權限授與服務主體時，要特別小心。 您可能會不小心將權限授與錯誤的服務主體。 使用應用程式識別碼是不錯的做法。
當您建立服務主體時，通常只會設定顯示名稱。 Azure 會自動指派其他名稱和識別碼。
處理過期的金鑰
服務主體不會過期，但其金鑰會過期。 當您建立金鑰時，可以設定其到期時間。 根據預設，到期時間設定為一年。 在此到期時間之後，金鑰將無法繼續運作，而管線也無法登入 Microsoft Entra ID。 您需要定期更新或 輪替 金鑰。
警告
為您的金鑰設定較長的到期時間是很吸引人的做法，但您不應該這麼做。 服務主體只受其認證保護。 如果攻擊者取得服務主體的金鑰，則可能會造成大量損害。 將攻擊時間降到最低的最佳方法，是定期變更您的金鑰。 如果您懷疑金鑰已遭洩漏，則也應該刪除並重新建立金鑰。
若要重設服務主體的金鑰，請使用具有應用程式識別碼的 az ad sp 命令，如此範例所示：
az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"
您也可以先後使用 az ad sp credential delete 和 az ad sp credential reset --append 命令，在兩個不同的步驟中移除並重新建立服務主體的金鑰。
若要重設服務主體的金鑰，請先使用 Remove-AzADServicePrincipalCredential Cmdlet 來移除現有的認證。 然後使用 New-AzADServicePrincipalCredential Cmdlet 來新增認證。 這些 Cmdlet 都會使用服務主體的物件識別碼來識別認證。 使用 Cmdlet 之前，您必須從應用程式識別碼取得此識別碼：
$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id
Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText
提示
單一服務主體可以有多個金鑰。 您可以安全地更新應用程式以使用新的金鑰，同時舊的金鑰仍然有效，然後不再使用舊金鑰時將其刪除。 這項技術可避免從金鑰到期的停機時間。
管理服務主體的生命週期
請務必考慮您所建立每個服務主體的整個生命週期。 當您建立管線的服務主體時，如果管線最後被刪除或不再使用，會發生什麼事？
系統不會自動移除服務主體，因此您必須先稽核並移除舊的服務主體。 移除舊的服務主體很重要，與刪除舊的使用者帳戶的理由相同：攻擊者可能會取得其金鑰的存取權。 最好不要擁有未主動使用過的認證。
最好將服務主體記錄在您與您的小組可以輕鬆存取的位置。 每個服務主體應包含下列資訊：
- 基本識別資訊，包括其名稱和應用程式識別碼。
- 服務主體的用途。
- 誰建立服務實體、誰負責管理服務實體和其金鑰，以及有問題時誰可能有解答。
- 所需的權限，以及其需要的明確理由。
- 何謂預期的存留期。
您應該定期稽核您的服務主體，以確保它們仍在使用中，而且它們已被指派的權限仍然正確。