前言回顧

技能解封中間章程-角色權力保衛戰(Azure RBAC)

已領取技能符石

解封技能樹(Start)

適合的勇者？

曾經遭逢資安事件打擊者。

資安事件觀望者。

資安探索者。

IT過路人。

資安潛水幫。

資安擺渡人。

學完可以帶走甚麼？

種下資安的芽在自己心中讓資安意識更強大。

自己的資安生涯規劃師。

帶走心中的這棵樹，把樹傳出去。

你也可以是小小資安擺渡人。

單挑資安認證更有信心。

瑪瑟爾 vs 迪亞波羅

天使城中的隱形屏障

在幾經波折紛擾後，伊瑟瑞爾決定大動作喚醒來自先烈戰役中奪取的魔界屏障，這一次決定啟動解封，讓這反派的魔物可以藉此保護城中的子民。雖然說限制做法極為強烈，但或許需要規範結界才能抑制少數受到利益薰心的天使不再蠢蠢欲動想著世界之石的歪腦筋進而能保護到人類。

回到人類聽得懂的代名詞"原則"小弟先簡述一下此服務究竟為何？
資安控管驗證自身公司組織間能否透過即具效益的 IT 管理辦法來達成其目標。透過評估其 Azure 資源是否符合所指派的政策規範下進而滿足其公司需求。
Azure Policy 本身也屬 Azure 中的一項政策規範的資安服務，可建立，指派和管理套用其原則。 這些原則會針對你所指定的資源強制執行來達到其所期望之成效，讓 Azure 這些資源可以來符合公司標準和服務等級協定(SLA)的規範。舉例你可能是設定在環境中只允許特定 SKU 等級大小的虛擬機或是只能允取多少台上限的虛擬機器可以被建立。在施行此原則後，會評估新資源和現有資源的合規性。使用適當類型的原則，現有的資源就可以合規。
如果設定失敗請至訂用帳戶的資源提供者檢查

• Microsoft.Authorization registered
• Microsoft.PolicyInsights registered

Azure Policy 和 RBAC 之間的差異？

• RBAC 著重於不同範圍的使用者動作。如：上篇範例可能是被加入資源群組的 Owner 角色中，讓你可以對此資源群組下的資源可以做新增，變更，刪除等動作。
• Azure Policy 則是著重於部署期間對整個範圍的資源屬性的控制情況。

列舉以下幾個重要常用的 Azure 原則：

• 指定儲存體帳戶 SKU - 確定部署的儲存體是否為同一組 SKU 中(如：Blob 儲存體，一般用途v1或一般用途v2) 。
• 僅允許的資源類型 - 定義您可以部署的資源類型。 其效果是拒絕不屬於此定義清單的所有資源。
• 僅允許的位置 - 限制新資源的可用位置。 其效果可用來強制執行您的地理合規性需求。
• 僅允許的虛擬機器 SKU - 指定您可以部署的一組虛擬機器 SKU。
• 強制套用標籤 - 對資源強制執行必要的標籤及其值。
• 受限的資源類型 - 防止部署資源類型清單。

原則參數的建立
降低所必須要建立的原則定義數量，才能大大簡化管理原則。在建立更合適的原則定義時，可定義其參數並針對不同的環境合規需求，重複使用其原則定義，下列是展示內建的原則定義樣貌先讓大家有較深刻的印象。

• 預設內建原則目前有291條，你可以依照您目前環境所需來做套用。
  
• 如剛剛提到舉例你想要限制僅能使用的虛擬機器 SKU，可以透過搜尋關鍵字找到整串相關進而自訂成你所需要的原則定義。
  
• 下列是目前 Azure 針對訪間的資安定義規範下直接做好的定義模板，裡面已經有內涵各種合規的原則在裏頭，如果你有很明確的方向也可以直接套用即可．
  

管理原則的心法

• 一開始請以稽核偵測為主，而非直接透過原則定義對資源直接做強制限制。舉例如你已經有自動調整應用程式指令，但因為設定直接 Deny 而導致影響因為無法自動化調整進而影響原來公司的商業損失。
• 建立定義指派，要以組織階層從高層級建立定義如：管理群組或訂閱帳戶層級。在到下個子層級做指派。如果您在訂閱帳戶建立定義而將指派範圍縮小為特定資源群組。

Azure Policy 原則定義效果

1. Append - 用在建立或更新所要求的資源時，為資源新增額外欄位如：新增一組 Tag，新增一組 IP 等..
2. Audit - 是在建立或更新資源間原則稽核檢查後將資源傳送至資源提供者。並再新增至活動記錄並把判定異常的資源標示為不合規。
3. AuditIfNotExists - 當稽核符合非法條件時如符合 if 條件但沒有 then 更多的被指定的動作，與上述相近。
4. Deny - 強制執行原則阻擋不合規的事件資源。
5. Disabled - 就是不被此原則套用，可以忽略。
6. DeployIfNotExists
7. EnforceRegoPolicy (Preview)

上述兩項的屬性說明參考：

AuditIfNotExists properties
EnforceRegoPolicy properties

原則判斷動作順序

1. 首要檢查是否有 Disabled 來判斷是否應該要繼續比對原則條件。
2. 再著評估 Append。因為 Append 所設置的但書或是附加而外的條件規則有可能再參照後讓原本符合條件產生變數而無法觸發 Audit 或 Deny 的結果。
3. 再來評估 Deny，來可防止想要限制的條件資源。
4. 再來評估 Audit，將判斷後的紀錄傳送給資源提供者。
5. 最後會評估 AuditIfNotExists 和 DeployIfNotExists 來判斷是否需進行後續合規記錄或動作。
6. 此項目為預覽目前沒有任何與 EnforceRegoPolicy 有關的評估順序說明。

實作工坊

而光說不練怎麼行，實驗環境中會把持續關注的你/妳帶到小弟我的 wordpress.com Blog連結內容如下：

技能解封中間章程-城內防禦機關重啟(Azure Policy)

1. Azure Policy 成本計價。
2. Azure Policy Q&A。
3. 簡易實作體驗。(Allowed storage account SKUs 來做為示範，呈現效果如下，想知道的一定要點進去看！)
   

上屆鐵人主題

如果有興趣對您有幫助也請多多支持，歡迎給小弟建議或互相交流!

Google Cloud 勇者的試煉

玩轉 Azure 於指尖隨心所欲