多雲環境的安全維運 — Part 2
IAM(Identity and Access Management)的實作
相信對雲端運算熟悉的人都知道，IAM是整個雲端運算的核心。因為不論是人員或系統，要對雲端資源進行存取都必須要先過IAM這一關。在本文中，我們將討論如何根據RBAC(Roles Based Access Control)在IAM中進行"身分與行為"管理，如何對人員或系統進行驗證與授權，如何給予最小權限管控。我們也會討論企業常用的Windows AD如何與三大公有雲(AWS/Azure/GCP)來整合。
我們也會針對一些技術術語進行介紹，例如，federation, SSO(Single sign-on)，MFA(multi-factor authentication)，privileged access managementu以及IDaaS(Identity as a Service)。我們會討論以下重點:
- 理解甚麼是IAM
- 使用Windows AD作為我們的集中式的身分驗證系統(現在稱為Microsoft Entra ID)
- 如何針對多雲環境設計我們的IAM
- 探討特權存取管理PAM(Privileged Access Management)
- 在多雲環境中使用account federation
理解甚麼是IAM
IAM就是控制對雲端資源的存取服務，通常都會搭配RBAC模式來進行管控。至於甚麼是RBAC，網路中有非常多的文件在說明這件事，在此就不在贅述。這裡只強調一個重點，每一個Role都只有有最小權限(least privilege)。也就是說不管是人員或系統，權限是可以疊加的(同時有多個Role)。
所以針對IAM，我們有三個層次需要在我們的雲端架構中需要被考量:
- 受控的身份(Managed identities):
在雲端中，不管是甚麼(people/systems/API)都需要有一個身份才能存取雲端資源 - 受控的角色(Managed roles):
正常來說每一個身份都需要有一個角色才能執行需要的動作(技術上來說可以不用，但會造成管理困難)。在這一個層級，我們需要很仔細的定義甚麼角色可以存取甚麼樣的資源 - 受控的存取(Managed access):這是定義甚麼東西或甚麼人有一個正確的權限來存取資源。例如，網路管理者的角色絕對不可以對資料庫進行存取。
而在這三個層級中，我們會有不同的方法/技術/解決方案/工具來對應這三個層級的需求(如下圖)。
第一步要做的就是身份控管。基本上我們需要有一個中心化的身份儲存系統或服務，例如Microsoft Entra ID。
再來是我們要將某一個身份給予一個角色，以便它能做到它需要執行的動作。而這個角色也會伴隨一個正確的存取權限。然而誰有權力分配權限給相關的人員，這得視每個組織的流程/文化/組織架構而定。例如，發配權限其實是ITSM系統給予的，只是在核可的流程中主管需要同意此項權限發配。
使用Windows AD(Microsoft Entra ID)作為我們的集中式的身分驗證系統
我們需要能夠分辨是甚麼是Windows AD與Azure AD。 Windows AD其實是一個很複雜的系統，但就IAM而言我們只需要了解它的基本原理即可。
因為企業使用集中是的身份驗證系統，所以一旦它掛了，全部的系統就可能停工了。企業將無法正常運作。也因為如此保護這一類的系統變得非常重要，通常我們會對它加上額外的保護措施，例如Sailpoint這一類的資安方案。它就會在Windows AD/ IAM之前有一層的防護。
Sailpoint這一類的解決方案提供保險庫(vaults)和一種安全存取系統的方法，例如，通過在加密保險庫中hashing password，這樣用戶實際上看不到密碼，而是通過Sailpoint拿到密碼。 這些方案還可以記錄登錄系統的session，以最大限度地了解環境中的任何動作，通常稱為稽核追踪(audit trial)。
而Windows AD與雲端相關的的主要組件有兩個，分別是 directory與 domain services。 Domain services會包含 domain controller(物件的驗證與授權)，通常是users與computers。而在混合雲中我們最常見到這個組合，Windows AD在地端，需要驗證與授權的物件在雲端。
而這樣的組合我們通常需要在雲端中有一個Domain Controller。而這時就需要AD Federation Service來連結雲端與地端的AD，例如下示意圖:
Windows AD使用了LDAP/Kerberos/DNS這三種組件來提供服務。LDAP進行元件的驗證與相對應的資料儲存。Kerberos用在兩個元件互相通訊的身份證明。至於DNS的功能則是大家都知道了，就不再說明。
對多雲環境設計我們的IAM
之前我們提到了混和雲的驗證方式，也就是驗證服務置放於地端機房。然後使用Federation的方式將身份資料同步到雲端的驗證服務。哪在雲端接收這一類的資料是甚麼呢?如果是在Azure，它們使用的是稱為AAD(Azure Active Directory)的服務。AAD只是一個驗證服務而已，主要的身分驗證系還是置放於地端機房中。微軟將AAD定位成是一個IDaaS。而兩邊的資料同步我們使用稱之為Azure AD Connect的工具。
AAD提供了Application layer與Office 365的SSO整合驗證，它也能整合MFA來使用。也可已透過手機簡訊發送pin code來進行驗整，甚至若手機中有安裝微軟的Authenticator驗證(驗證方式不需要輸入密碼)。
Azure使用了稱為ADFS(Active Directory Federation Service)來達到兩邊(雲端與地端)的身份驗證聯合服務。在Azure，Azure的域名為onmicrosoft.com。
假如我們組織的域名是jasonkao.com並且我們要在Azure中使用到這個域名。在Azure中可能呈現的是jasonkao.onmicrosoft.com。接下來我們在這兩個域名之間建立信任關係。
以上的作法與圖二所示的架構圖也完全套用AWS與GCP，因為Windows AD畢竟還是人家微軟的東西。AWS的Federated Authentication service中也存在ADFS這個組件。在AWS的環境中，使用者要登入AWS Console進行驗證時，ADFS會驗證使用者的資訊將該資訊詢問地端機房的Windows AD，如果Windows AD驗證無誤，ADFS會傳送一個assertion到AWS STS(Security Token Service)。STS會返回一個基於AssumeRoleWithSAML角色的暫時性憑證讓使用者可以登入成功。流程示意圖如下:
上圖中我們可以看到STS發出的是一個SAML(Security Assertion Markup Language)的標準憑證，用於在兩方之間的驗證與授權。這個方式更常用在雲端環境的驗證中，因為不用受微軟的約束。
所以同理可證，GCP一樣使用SAML來做為AD federation。在GCP，這個服務稱為Cloud Identity(用於IAM)。而與地端AD之間的同步，GCP使用稱為 Cloud Directory Sync的服務。
在所有這些概念中，了解組織 AD 的設置方式非常重要。 這個設置需要對應到雲端平台中的 IAM policy。 Windows AD 是一個從forests、tree、domain到OU的階級與邏輯劃分。 Forest是 AD 的最上層，包含root-level domain。 compute和users等objects按域名分群組。 一組domain會形成一個tree。 一個forest中的doamin和tree是相互信任。
在公有雲中，這種forest、tree和domain的劃分大都需要調整才能對應到雲端的組織結構中。 以 GCP 為例，organizations是在 GCP 中持有一群GCP服務的邏輯邊界。 organizations中會階層細分成folder，folder中會包含project。 而這些結構必須對映到 AD 結構，否則federation將失敗，導致無法驗證。
探討特權存取管理PAM(Privileged Access Management)
對資安有認識的人應該都知道latest privilege這一個概念，在此不在再贅述。這一種latest privilege account基本上有兩種型態:
- Standard user account
- Guest user account
不管是哪一種，能執行的動作是有限的。但是如果某一些作業是需要"暫時"的有特權帳號才能執行時，而給予這些特權帳號是具有資安風險的。哪應該怎麼辦呢?這時PAM就可以幫我們減輕這一類的風險。簡單的來說: "PAM 確保提升的權限只能由特定帳戶在特定時間和特定原因用於特定系統"。
PAM背後的原則稱為just-in-time和just enough administration。 根據這一原則，管理員可以決定特定使用者需要特定權限才能在系統上執行任務。 但這些使用者的特別權限是有效期的； 這會違反latest privilege原則。 這些使用者將拿到符合條件的帳號，這意味著當使用者需要執行某項任務時，這樣做的權限將得到提升。
因此，使用者請求允許從特權帳號啟用提升的權限。 給與執行任務所需的小時數的權限。 時間到後，權限自動收回。
雲端平台中的PAM
PAM 只在應用latest privilege原則時才有效：需要哪些特權帳號，以及它們將具有哪些角色。 雲端平台都有一個可以應用的role-based model，支援在不一樣任務的資源上執行足夠細緻度的存取。
CSP只使用幾種內建的通用角色類型：
- 可以在我們中做任何事情的角色
- 可以在我們的某些區域做特定事情的角色
- 以及只能檢視事情的角色。
通過清楚地了解我們的帳戶以及這些帳戶所具有的角色，我們可以在雲端環境中配置 PAM。
在AWS中，AWS的IAM服務就含有PAM的功能。AWS IAM採白名單式管理，也就是沒有特別指定被allow的，最後通通都會被deny。
在多雲環境中使用account federation
由於企業越來越多開始使用SaaS服務，通常如果我們沒有自己的驗證服務而採用SaaS服務的話，哪麼老實說，我們就在使用者的帳號管理上就lose control了。好在這可以用Account Federation加上SSO來解決。
在Account Federation領域，Okta 成為近年來越來越流行的 IAM 解決方案。 為避免混淆，它不是 AD 的替代品。 AD 通常是主要的central directory； Okta 是一種利用 AD 的解決方案，負責使用SSO 與 Web 應用程序的federation。 這就是 Okta 做的是：它幫AD 外加了IAM 和 SSO的功能，。
這也稱為 IDaaS 解決方案 — — 一種支持跨多雲的SaaS身份驗證服務。 這是管理企業身份驗證並提供 MFA 和 SSO 等功能的第三方解決方案。 不過，這些解決方案仍然需要一個central directory，也就是AD。 IDaaS 可以與現有 AD 整合，或者我們可以使用來自 IDaaS 服務商的central directory。 使用後者，我們可以節省費用，因為AD沒有了，但我們也失去了對公司身分/密碼的控制權。下圖為當我們使用IDaaS服務的整合示意圖：
企業如果使用混和雲的架構的話，哪麼Account Federation將是不可避免的。 IDaaS 解決方案可以成為將現有 AD 連接到所有這些不同的on-premises/IaaS/PaaS/SaaS並實現對它們的安全存取管理。
