Azure平台上為每個租戶提供了Azure Active Directory服務（AAD），基于AAD提供了大量的内置角色，通過将這些角色配置設定給不同的操作人員來實作在一個租戶内對各類資源操作權限的劃分。然而當這些内置角色無法滿足你的需求的時候，就可以通過自定義角色的方式來實作你的想法了。
（一）基本概念
在進入主題之前，還是先來澄清裡面的概念要點和邏輯關系，當然，熟悉AAD和Azure的老司機可以跳過這段。
AD – Active Directory 活動目錄，即一套辨別/身份管理服務
AAD – Azure Active Directory，簡單了解為AD在Azure雲端的實作，但是這個是多租戶的服務。
Role – 角色， 抽象的身份，對應一個權限集合
RBAC – Role based Access Control，基于角色的權限控制；這種方式已經是在IT平台上最為流行的方式了，就是權限與角色關聯，控制權限實際是控制了角色，使用者被賦予不同的角色，使用者實際權限的展現是由使用者所賦予的角色關聯的權限。
每個 Azure 訂閱都與一個 Azure Active Directory (AD) 目錄相關聯。 該目錄中的使用者、組和應用程式可以管理 Azure 訂閱中的資源。 可以使用 Azure 門戶、Azure 指令行工具和 Azure 管理 API 配置設定這些通路權限。
通過将相應的 RBAC 角色配置設定給特定範圍内的使用者、組和應用程式來授予通路權限。 角色配置設定的範圍可以是訂閱、資源組或單個資源。 配置設定在父範圍内的角色也會将通路權限授予給其中所含的子範圍。 例如，具有對資源組通路權限的使用者可以管理其包含的所有資源，如網站、虛拟機和子網。
（二）内置角色
Azure RBAC 有三種适用于所有資源類型的基本角色：
- 所有者對所有資源具有完全通路權限，包括将通路權限委派給其他使用者的權限。
- 參與者可以建立和管理所有類型的 Azure 資源，但不能将通路權限授予其他使用者。
- 讀者 可以檢視現有的 Azure 資源。
關于内置角色的詳細資訊請參閱：
https://docs.azure.cn/zh-cn/active-directory/role-based-access-built-in-roles。
以備份服務為例（這個東東總是要求不同人有不同權限…..）:
| 備份參與者 | 可以管理恢複服務保管庫中的備份 |
| 備份操作員 | 可以管理恢複服務保管庫中的備份，删除備份除外 |
| 備份讀者 | 可以檢視所有備份管理服務 |
備份讀者的操作：
| 操作 | |
| Micosoft.RecoveryServices/Vaults/backupFabrics/operationResults/read | 讀取備份管理操作的結果 |
| Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/operationResults/read | 在保護容器上讀取操作結果 |
| Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/operationResults/read | 讀取對備份項執行的操作的結果 |
| Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/operationStatus/read | 讀取對備份項執行的操作的狀态 |
| Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/read | 讀取備份項 |
| Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/read | 讀取儲存備份項的容器 |
| Microsoft.RecoveryServices/Vaults/backupJobs/operationResults/read | 讀取備份作業的結果 |
| Microsoft.RecoveryServices/Vaults/backupJobs/read | 讀取備份作業 |
| Microsoft.RecoveryServices/Vaults/backupJobsExport/action | 将備份作業導出到 Excel |
| Microsoft.RecoveryServices/Vaults/backupManagementMetaData/read | 讀取與備份管理相關的中繼資料 |
| Microsoft.RecoveryServices/Vaults/backupOperationResults/read | 讀取備份管理操作結果 |
| Microsoft.RecoveryServices/Vaults/backupPolicies/operationResults/read | 讀取對備份政策執行的操作的結果 |
| Microsoft.RecoveryServices/Vaults/backupPolicies/read | 讀取備份政策 |
| Microsoft.RecoveryServices/Vaults/backupProtectedItems/read | 讀取備份項 |
| Microsoft.RecoveryServices/Vaults/backupProtectionContainers/read | 讀取儲存備份項的備份容器 |
| Microsoft.RecoveryServices/Vaults/extendedInformation/read | 讀取與保管庫相關的擴充資訊 |
| Microsoft.RecoveryServices/Vaults/read | 讀取恢複服務保管庫 |
| Microsoft.RecoveryServices/Vaults/refreshContainers/read | 讀取用于擷取新建立的容器的發現操作的結果 |
| Microsoft.RecoveryServices/Vaults/registeredIdentities/operationResults/read | 讀取對保管庫的注冊項執行的操作的結果 |
| Microsoft.RecoveryServices/Vaults/registeredIdentities/read | 讀取保管庫的注冊項 |
| Microsoft.RecoveryServices/Vaults/usages/read | 讀取恢複服務保管庫的使用情況 |
{這個太占篇幅了，是以就隻能舉一個例子了}
（三）自定義角色
終于到了主題了……如果上述的内置角色不符合你對角色細分的要求，可以建立自定義角色。 自定義角色的建立有三種方式：Azure PowerShell、Azure 指令行接口 (CLI) 和 REST API 建立自定義角色。（絕大部分Azure上的操作都是這樣三種手段，至于用哪一個，看你自己的喜好了，下面用CLI為例）
l 自定義角色與内置角色一樣，可以将自定義角色配置設定到訂閱、資源組和資源範圍内的使用者、組和應用程式。
l 自定義角色存儲在 Azure AD 租戶中，可以在訂閱之間共享。
l 限制：每個租戶可以建立最多 2000 個自定義角色。
角色的三大屬性：
1. 自定義角色的 Actions 屬性指定該角色向其授予通路權限的 Azure 操作。 它是操作字元串的集合，可辨別 Azure 資源提供程式的安全對象操作。 操作字元串遵循格式 Microsoft.<ProviderName>/<ChildResourceType>/<action>。 允許使用通配符 (*) 的操作字元串來授權通路與該操作字元串相比對的所有操作。
2. 要排除受限制的操作可以使用 NotActions 屬性。 通過用 Actions 操作減去 NotActions 操作可以得到自定義角色授予的通路權限。
3. 自定義角色的 AssignableScopes 屬性指定可以配置設定該自定義角色的範圍（訂閱、資源組或資源）。 可以讓自定義角色隻在需要它的訂閱或資源組中進行配置設定，而不影響其他訂閱或資源組。
下面一個操作執行個體來說明如何建立和管理一個自定義角色。
（1） 設計一個自定義角色：
首先需要進行規劃，這個自定義角色用來幹什麼？使用範圍是什麼？比如，我們給運維團隊設計一個初級的備份管理者，這個管理者可以建立備份，但不允許他恢複備份（隻是為了舉例）
（2） 建立角色的JSON描述檔案：
（3） 建自定義角色
azure role create --inputfile \code\sublime\newBackupRole.JSON
（4） 修改自定義角色
要修改自定義角色，使用 azure role show 指令檢索角色。
然後，對角色定義JSON檔案做出所需更改。 最後，使用 azure role set 儲存修改後的角色定義。
（5） 删除自定義角色
同樣，要删除自定義角色，使用 azure role show 指令查到要删除角色的 ID 。 然後，使用 azure role delete 指令通過指定 ID 來删除該角色。
（四）後記
Azure提供了大量的自定義能力，是以在滿足使用者需求方面擁有強大的靈活性。但是實施一個自定義的權限配置設定的根本還是在對權限模型的了解和良好的權限規劃，這樣才不會讓自定義的角色、權限變成負擔。
轉載于:https://www.cnblogs.com/ZQatMS/p/7834377.html