淺談AWS的權限控管

Amazon Web Services (AWS)是由Amazon公司所建立的雲端運算平台，提供運算能力、資料庫儲存、內容交付及各種企業需要的IT功能，具有高度安全、可靠性、可擴展性、低成本等等特性。AWS的基礎架構遍及世界各大洲，目前已有25個區域(Region)和200個以上的節點(Edge Location)，且有上百萬名的活躍客戶，使用其雲端產品與解決方案來建立具有高度彈性的複雜應用程式。

公有雲的最重要的特色之一，就是客戶不需要擁有並維運IT的基礎架構，但從另一方面來說，客戶的確也無法實際接觸到AWS的實體設施和設備。因此客戶都是透過網際網路，對AWS所提供的各種服務的API端點提出需求，以建立、設定、管理AWS上的各種運算資源。那麼，究竟哪些人可以存取哪些資源呢？一般系統只要有存取控制的機制，基本上至少都會有認證(Authentication)和授權(Authorization)這兩個步驟。簡單的說，認證在確定訪問者的身分(Identity)，授權則是決定該身分可以做什麼(Access)。而存取AWS的第一道關卡就由Identity and Access Management (IAM)這個服務負責，它的名稱已經很清楚的說明了其功能。

客戶可以在IAM裡建立一些「身分」（具體來說有三種：User、Group、Role），然後將權限（通稱Policy）賦予這些身分。權限文件是以JSON的格式撰寫，裡面最主要的元件有四個：Principal、Resource、Action、Effect，其中Effect最單純，只有Allow和Deny兩種情況。用白話的方式說，所謂的權限就是某人(Principal)可不可以(Effect)對某資源(Resource)做某動作(Action)。事實上AWS的權限種類非常多，但受限於篇幅，這邊僅討論套用在這些身分上的權限（即所謂Identity-based Policy）。因為這類權限必定是套用在某個身分上，因此權限文件中的Principal不用寫，意即被該權限套用到的那個身分就是Principal。以下是一個很簡單的範例：

暫且先忽略複雜的JSON格式，從剛剛提到的關鍵字，相信應該很容易看出套用這個Policy的身分，將被「允許」對於「所有S3資源」執行「所有S3動作」的權限（即使我們還沒提過什麼是S3也不影響判讀），其中星號為萬用字元，泛指所有英數字及某些特殊符號的各種組合。

然而同一個Policy文件可以有多個段落分別定義不同的權限，同一個身分可以套用多個不同的Policy文件，同一個User身分可以屬於多個Group身分，甚至某些特定資源也可以設定Policy（即所謂Resource-based Policy），那麼萬一當這些權限同時存在並且彼此有衝突時，結果又會是如何呢？當一個身分沒有被套用任何Policy時，是什麼都不能做的，這個稱為Implicitly Deny。當Policy文件中的Effect為Allow時即為授權，稱為Explicitly Allow，反之當Policy文件中的Effect為Deny時即為禁止，稱為Explicitly Deny。其實邏輯很簡單，將前述的所有Policy文件的內容全部彙整起來，只要有Explicitly Deny一律不允許，接下來才看有沒有Explicitly Allow，有的話就允許；如果什麼都沒提到，就是Implicitly Deny不允許。這個規則也可以很簡單的記憶成：Explicitly Deny > Explicitly Allow > Implicitly Deny。

AWS目前已有上百種服務，對每種服務的資源可能有多達數十種不同的動作可執行，而且服務的種類跟可執行的動作仍在不斷的增加中。在這麼複雜的環境下，如果要做到精確的存取控制，勢必要有更多的細節可以調整，因此光是權限的種類就有很多種，況且授權時還可以考慮各種其他狀況（在Policy文件中稱為Condition），在符合特定條件下才授權。所以AWS上的權限設定遠比本文中所提及要複雜許多，不過這裡所說的基本概念，在絕大多數情況下都是相通的。當然權限並不是獨立存在於服務之外，一定是先存在某些情境，才會出現權限需求。所以如果想進一步了解AWS的權限控管，應該還是要先廣泛的了解各種AWS服務和使用情境，才有可能理解各種權限的設計目的喔！