Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP25。

Authorization (授權)指引

基於正確的 Authentication 驗證/識別身份的機制後，授權的流程就是確保該身份是否有取得資訊或資源的權利。所以有可能身份驗證成功，但無法取得資料或無法請求資源(授權失敗)，也就是常看到的的權限不足。

而 Authorization 的概念可分成三個不同的要素：

• Subject: 主體
• Object: 客體
• Action: 控制措施
  組合出各種 Access Control 的模式。

透過 Access Control (AC) 模式可分成以下幾種：

1. 傳統上分成下列三種：

   • DAC(Discretionary Access Control): 自主性存取控制，由使用者(通常為擁有者)決定賦予誰能存取。
   • NDAC(Non-discretionary Access Control): 非自主性存取控制，由控制措施決定賦予誰能存取，使用者不能決定其存取權。
   • MAC(Mandatory Access Control): 強制性存取控制，最典型的強制性存取控制模型就是先前在 EP15 提過的 Bell-LaPaDdula 模型，由控制者強行決定適當的存取權，使用者不能決定其存取權。

2. 新興的方式分成以下兩種：

   • RBAC(Role Based Access Control): 角色為基礎的存取控制，可參考 NIST - RBAC 之解釋。
   • ABAC(Attribute Based Access Control): 屬性為基礎的存取控制，可參考 NIST - ABAC 之解釋。

若要在近一步針對 DAC、MAC、RBAC、ABAC 的完整比較與解釋觀點，可參考以下文章介紹：
https://dinolai.com/notes/others/authorization-models-acl-dac-mac-rbac-abac.html

Credential Management

憑證管理是一個複雜的事情，其中包含產生、驗證、與其生命週期管理。

Differernt forms of credentials

而傳統上大部分認知到的就是管理帳號密碼，但其實晶片卡、認證簽章，也都可以是憑證的一種。

各家平台系統的在裝置進行憑證儲存機制手段有：

• Credential Management API (Windows)
• Keychain (Mac/iOS)
• Keyring/Keystore (Linux/Android)

因此在考慮其運用這些系統各項作業時，要特別注意其儲存機制是否有做好其憑證保護措施。

認真討論前一回所提到的 Single Sign-On (SSO)，也是一種取得 Credentials 的概念，由於透過 SSO 可相當便捷的在不同應用領域或系統當中運用，但也因為如此可能面臨偽冒、單點突破問題的風險，因此適切的控管機制是應該被好好考慮與設計的。

如果要在兩個端點 (其一方稱 "發送者"；另一方稱 "接收者") 傳送資訊，最基本的概念如下：

當然這樣的基本上就是該資訊在傳遞的過程中，可以隨時被 "攔截" 後進行 "竄改" 或 "偽冒" (注意 "竄改" 跟 "偽冒" 是不同的意思)。

因此大概可分成以下兩類加解密方式來處理：

• 對稱式加密：
  

• 非對稱式加解密：
  

在理論上，上述的兩者加解密方式在當代的資訊架構下，都有其可供信任的演算法(對稱: AES、非對稱: RSA)去保證其訊息的機密性。

但無論是上述兩種加解密演算法的哪一種，都只能確保其機密性(Confidentiality)。但無論是對稱式加密，最大的問題是其加解密金鑰的分享性；非對稱式加密，最大的問題是發行公/私密金鑰的信任性，也就是無法確保其完整性 (Integrity) 或稱 不可否認性(Non-Repudiation)。

Digital Certificate

a.k.a "Public Key Certificate", "Identity Certificate" 中文通常翻譯為 "數位憑證"。

其中的一種標準規範為 X.509，通常是可信任的授權單位(Certificate Authority - CA)用來讓 "數位簽章 (Digital Signature)" 中所產生的 "公鑰 (Public Key)" 來進行註冊的認證(Registration Authority - RA)後，發行其 "證書(Digital Certificate)" 以證明該公鑰真正擁有者的身份(所以又稱 Identity Certificate)。

而在 HTTP 的網路通訊，透過在應用層的部分加上了 SSL/TLS 形成 HTTPS 的通訊模式。其中，SSL/TLS 的加密措施，因為非對稱式加解密計算的複雜性過高，是透過非對稱式加密當中的公鑰，來隨機建立臨時性對稱式加密的密鑰，再進行資料交換的加解密措施，概念如下圖：

上圖取自 圖解 HTTPS 文章。

如有興趣了解 HTTPS 的運作過程，可前往 HOW HTTPS WORKS 進一步了解：

• EP1: why-do-we-need-https
• EP2: The Keys
• EP3: The handshake
• EP4: The differences between HTTPS, SSL, and TLS
• EP5: Certificate Authorities

上圖取自 HOW HTTPS WORKS 官網首頁。

再次 強調，憑證 (Certificate) 是憑證；簽章 (Signature) 是簽章，這兩個名詞所指的東西是完全不同，切記。