Oracle Cloud IAM Service

身分識別與存取管理服務(Identity and Access Management Services, IAM service) , 這是用來做身分識別與權限控管的服務，該使用者隸屬於哪一個群組(group)，擁有對什麼資源(resource)的什麼權限，所有的資源都會有一組Oracle Cloud ID (OCID)，可以在控制台內點入該資源後的頁面找到。

如圖，展示了在身分識別與存取管理服務內主要的組成元件， IAM 架構圖分為兩大分支，左分支身分識別(Identities) 是能夠獲取權限的個體，也稱為原則(Principals)，又分為內含使用者(Users)與實例(Instance)兩支向，而這些原則要能使用圖中間下方的資源，則要透過右分支撰寫權限規則(Policies)，用權限規則來訂定能夠獲取權限的個體擁有對資源的什麼權限請求，而資源則以邏輯方式指派於某個區間，權限規則在撰寫時指令是允許能夠獲取權限的個體在特定區間或租戶對特定資源有什麼動作的權限。

Oracle Cloud IAM Service — 身分識別與存取管理 Oracle Cloud IAM

原則

原則(Principals) 為身分識別的個體(Identities)，分為帳戶與實例原則，原則透過加入已授權不同類型的群組來獲取各種雲端資源。

帳戶與群組

可以透過身分識別與存取管理服務(IAM )建立使用者，帳戶(IAM User)為使用者或應用程式所登入雲端的帳號，於一開始登入的第一個預設帳戶，也就是最高權限的管理者，再以此管理者權限帳戶來建立其他使用者帳戶，群組(Group)則是設計成一群需要相同特定權限帳戶的集合，權限是在群組層級給予的，這就表示當帳戶還未加入任何群組時是沒有任何權限，也可以加入多個群組，而群組也會起碼有一個權限規則指出擁有於哪個區間或租戶的特定權限。

實例原則與動態群組

實例原則(Instance Principal)這是一個讓計算實例(Compute Instance) 與應用程式可以使用API call來呼叫其他服務，不需要再透過使用者的權限調用服務，實例自己就是一種身分識別與存取管理服務內可獲取權限的個體。

動態群組(Dynamic Group) 則是一種特別的群組，有別於前面所提的群組，是由運算實例作為原則的角色而組成的動態群組，使用者可以針對此動態撰寫權限的政策，例如有一支應用程式跑在計算節點上，當這支應用程式需要對物件儲存服務(Object Storage Service)做存取的應用場景

身分識別

身分識別(Authentication)為資訊安全重要的環節，當要存取服務時第一件事情就是確認使用者的身分是否紀載於資料庫當中，是否能夠登入系統，在現實生活中也不乏看到身分驗證的場景，以下分別探討身分識別三個方式來達成識別身分。

1. 帳號/密碼

這是一種常見的方式，使用一組有複雜度的帳號密碼登入OCI的控制台介面，而當第一次登入時我們需要去修改管理員給的的一次性密碼，注意如果用戶等待7天以上才能首次登入，那密碼就會過期需要再請管理員發送建立發送一次性密碼給用戶，用戶之後也可以自行修改密碼，不需要管理員另外授權，但如果連續10次嘗試登入失敗，那該帳戶就會被鎖定，要使用管理員身分來解除鎖定。建議使用以下複雜密碼:

密碼至少包含一個大寫字母
密碼至少包含一個小寫字母
密碼的最小長度為12個字元
密碼至少包含一個符號
密碼至少包含一個數字

2. API簽章密鑰

當我們連接至API使用SDK /CLI的時候，也就是命令行介面來執行指令，我們就會使用API 簽章密鑰(Signing Key)，而這個金鑰是使用RSA key pair非對稱式加密，PEM的格式最小2048 bits，於實驗中我們可以以puttygen的方式產生，在控制台建立一台運算節點時，將公鑰檔案內容貼上，並自己保留私鑰檔案，藉此以非對稱式加密方式達到身分識別，一個用戶一次最多可以擁有三個API密鑰，以資訊安全的角度建議定期更新API ，以下為更新步驟:

生成並上傳新的API密鑰。
使用新的API密鑰更新SDK和CLI配置文件。
使用新密鑰驗證SDK和CLI調用是否正常工作。
禁用舊的API密鑰。使用”ListApiKeys”列出所有活動的API密鑰。

3.驗證權杖

第三種方式為自動產生的驗證權杖(Authentication Token)，原本的名稱是”Swift passwords”，可以用來驗證某些不支援API 簽帳密鑰的服務，鏈結第三方API。驗證權杖不會過期，用戶同時可以擁有兩個權杖。

權限

權限 (Authorization)主要是透過撰寫權限規則的方式來控管，權限規則是以遵從最小權限規則(Principle of least privilege)所設計，使用者建立後，預設沒有任何權限，所以需要透過設定權限規則的方式，授予可獲得權限的個體所位於的群組權限，建立規則是以正面表列的方式授權，可讀性高，類似指令的格式。因為在雲端上的權限預設是”All-Deny”，所以撰寫的語法只會有”Allow”來授予權限，如表

主詞(Subject) : 為可授權的群組，可為帳戶所屬的一搬群組(Group)，或是實例原則所屬的動態群組(Dynamic Group)。
動詞(Verb) : 動詞有4種，為累加上去的架構。若為檢閱(inspect)則有可以列出資源的權限，讀取(read)則跟檢閱有點像，但為檢閱再加上其他讀取的權限，例如可以得到元數據(metadata)資訊，使用(use)則為讀取再加上例如修改(update)的權限，根據針對的資源類型有所不同，管理(manage)則為所有的權限。根據關聯的資源不同，這四種動詞分別再對應到不同的權限(permission)，舉例使用(use)細分則還有修改(update)、寫入(write)…，反推則是在雲端上面所有的動作都稱為APIs，每個都會去呼叫對應的權限，而要獲得此權限則是透過這四個動詞。
資源類型(Resource-type) : 分為兩種，獨立資源種類(Individual resource type)為特定的資源，若為一群相關聯的資源則為集合資源種類(Aggregate resource type)多為”family”字眼作為資源名稱結尾，增加了在資源授權上的方便性，”all-resource”則為所有的資源，可以使用這種像是基於角色的授權方式，但也可以用獨立資源種類，作為授予較為精細的權限管理功能。
位置(Location) : 為租戶(tenancy)或是於某一個區間(compartment)。
條件(Conditions) : 為進階的權限規則設置，若不符合該條件則結果為”false”，不接受該請求，有兩種對象可指定為”request”與”target”，舉例request.region 代表發出請求須的區域，target.group.name代表定義該policy所影響目標群組，可以使用 = (等於)或是 != (不等於)來控制變數符不符合我們定義的值以下表示: variable =|!= value ，若有一個以上的條件則可以使用all 或any 來代表and 與or : any|all {<condition>,<condition>,…}。

範例: Allow group Administrators to manage all-resource in tenancy

資源控管 – 區間

如前面所探討邏輯上的架構-區間(compartment)，在權限管理上也大有用處，最小化使用者可見的資源，大幅簡化權限管理，例如可以將多種網路資源(虛擬雲端網路、子網路、網路閘道等)建立區間並使只有網路管理員群組擁有該區間資源的特定權限，可以使用區間限額(Compartment quotas)讓管理員更好的控制雲端內的資源使用方式，在使用上類似權限規則，用簡單一句指令語言的撰寫方式，如下圖，以要執行的動作開始，分為以下三個組件:

set – 設置可用於隔離專區的雲資源的最大數量
unset – 將配額重設為默認服務限制
zero – 刪除對隔離專區的雲資源的訪問

接著第二部分為所針對之服務群(Service Family)名稱，例如: block-storage、compute-core、database、DNS等，接著quota 關鍵字後可以指定於服務群內有效的限額名稱，例如block-storage 內有效的限額名稱為:

backup-count : 塊儲存(Block)與啟動卷(boot volume)的備份總數。
total-storage-gb : 塊儲存(Block)與啟動卷(boot volume)最大空間(GB)。
volume-count : 塊儲存(Block)與啟動卷(boot volume)的總數。

接著關鍵字to 多少值(value)再加上關鍵字in 哪一個區間或租戶，此外還可以設置更細的條件，例如where request.region = ‘us-phoenix-1’

權限規則繼承性

權限規則繼承性(Policy inheritance)研究中，若擁有權限於父區間(parent compartment) 會有繼承的效果於子區間(Child Compartment)能擁有該權限，如下圖，當區間一包含區間二包含區間三時，若執行 allow group to manage resource in compartment A 那就表示該群組也可以”manage resource”於區間三與區間四，最經典的則為管理者帳戶於租戶有 manage all-resource 的權限，故能管理所有的區間。

權限規則依附性

權限規則依附性(Policy attachment)在創建權限規則的時候一定是依附於租戶或某一個區間，而依附於哪一個區間會有安全性的考量，因為這關係到誰可以對其修改或刪除，假設將此權限規則依附於最高層級的租戶，那麼擁有管理權限規則於租戶的人就可以異動該權限規則，若只擁有較低層級區間權限的群組成員則無法異動，那麼若將權限規則依附於子區間，那麼位於該子區間的管理員就可以異動此權限規則，而不需賦予管理更高層基租戶的權限。

資源控管– 標籤

在資源的控管上可以加入標籤(Tag)使得更方便管理、組織、控制，善用標籤達到批次資源的操作與資源花費成本追蹤且標籤的使用是免費的，值得注意的是並非所有的資源都支援使用標籤，但大多數都是可以支援的，詳細名單請參考甲骨文官方網站以獲取最新資訊或請參考附錄，在使用標籤上包含兩個部分：鍵 (Key)和值 (Values)，例如: “學校”=”交通大學”，”學校”就是鍵而”交通大學” 就是值，透過鍵值與資源結合，標籤種類有分為兩種預定義格式標籤(Defined tags)與自定義格式標籤(Free-form tags) :

自定義格式標籤(Free-form Tags) : 使用者可以自行定義格式，是一種簡單不受任何限制也不含已經定義框架的標籤，只要可以使用資源的使用者都可以使用該種標籤。
預定義格式標籤(Defined Tags) : 標籤管理者建立與管理該種標籤的格式，這些標籤已經有受定義的框架，有利於提高一致性的使用也能避免有使用者建立錯誤的標籤。

與自定義格式標籤相比，預定義格式標籤提供更多的功能，自定義格式標籤依然可以用來過濾資源清單，但只有預定義格式標籤可以應用於撰寫權限規則來做存取控制，在企業應用上仍然建議使用預定義格式標籤。

命名空間 :

不同於自定義格式標籤單以鍵 (Key)和值 (Values) 組成，預定義格式標籤在使用上必須先建立命名空間(Namespace)，可以將命名空間視為一組鍵值的容器，於租戶內為唯一的名稱，不分大小寫，位於命名空間內的標籤名稱也必須是唯一，”Tag Key Definition”為標記的定義架構，包含了命名空間、鍵和值，如圖

使用標籤 :

值也可以支援變數的使用，例如:

Operations.CostCenter = ${iam.principal.name} at ${oci.datetime}

Operations為命名空間，CostCenter為鍵，值的部分則由兩個變數組成。

使用上須授予用戶use 的權限才能應用、修改或刪除標籤，若只是要簡單地查看於區間內有什麼標籤則需要inspect 的權限，如果用戶沒有此權限，則無法在清單中顯示標籤的命名空間列表，如下:

Allow group GroupA to inspect tag-namespaces in compartmentA

訂定權限規則使用標籤來增加安全性，舉例如下

Allow group InstanceLaunchers to use tag-namespaces in compartment A where target.tag-namespace.name=’Operations’

標籤使用限制:

每個資源的標籤數：10個自定義格式標籤和64個預定義格式標籤。
命名空間(Namespace)名稱 : 最高100個字符長度。
鍵(Key)名稱 : 最高100個字符長度。
標籤值(Value) : 最高256個字符長度。

管理標籤默認值

在區間的頁面於左下方可以檢視與使用標籤默認值(Tag Defaults)，使用標籤默認值的功能可以指定在創建特定專區時自動將資源附上標籤，大幅降低管理成本與標籤名稱出錯的可能性。須注意每個區間最多使用5個預設標前值，預設標籤不會朔及既往的標記，若修改現有預設值也不會影響已設置的部分，刪除預設標籤也不會因此將標籤的資源刪除。