雲端身份存取管理挑戰與對策

– 11 分鐘閱讀

雲端環境的彈性與規模化特性，使得身份與存取管理比傳統本地佈署更為複雜。從身份的建立、驗證到不同物件的存取控管，都需要更全面的策略。本文除了探討常見的驗證方法，如密碼雜湊、多因素驗證，也涵蓋了聯合身份驗證和單一登入的實作，並以程式碼示例說明 TOTP 和 SAML 的應用，最後也提醒讀者密碼管理和社交工程防禦的重要性，以確保雲端環境的安全性。

身份與存取管理：雲端環境的挑戰與對策

在雲端運算的世界中，身份與存取管理（Identity and Access Management, IAM）是至關重要的議題。與本地佈署環境相比，雲端環境提供了更多的身份服務選擇，使得身份驗證變得更加複雜。

身份請求與建立

在建立身份之前，需要透過請求流程來建立新的身份。這可能涉及自動化流程或手動操作，例如另一個管理員登入雲端入口網站以建立新的身份並授予其一定的存取許可權。

身份驗證

身份驗證是雲端環境中的關鍵問題。需要區分身份儲存（即儲存所有身份的資料函式庫）和用於驗證使用者身份的協定（如OpenID、SAML、LDAP等）。此外，還需要區分不同的身份驗證物件，包括：

  • 組織員工與雲端服務提供者的驗證（B2B）
  • 組織客戶與自有應用程式的驗證（B2C）
  • 組織員工與自有應用程式的驗證（B2E）

雲端IAM身份

許多雲端服務提供者提供免費的IAM服務，以管理組織中雲端管理員的身份和存取許可權。這可以幫助組織更好地管理其雲端資源的存取許可權。

常見雲端服務提供者的身份服務

| 雲端服務提供者 | 身份服務系統 | |

|

| | Amazon Web Services | Amazon IAM | | Microsoft Azure | Azure Active Directory B2C | | Google Compute Cloud | Cloud Identity | | IBM Cloud | Cloud IAM |

客戶身份管理

除了管理組織內部員工的身份外，還需要管理客戶或外部使用者的身份。有兩種常見的方法：

  1. 使用現有的身份服務（如Facebook、Google或LinkedIn）進行驗證
  2. 使用特定的客戶身份管理服務（如Amazon Cognito、Azure Active Directory B2C等）

常見客戶身份管理系統

| 提供者 | 客戶身份管理系統 | |

|

  • | | Amazon Web Services | Amazon Cognito | | Microsoft Azure | Azure Active Directory B2C | | Google Compute Cloud | Firebase | | IBM Cloud | Cloud Identity | | Auth0 | Customer Identity Management | | Ping | Customer Identity and Access Management | | Okta | Customer Identity Management | | Oracle | Oracle Identity Cloud Service |

多因素身份驗證

多因素身份驗證是保護使用者帳戶安全的重要手段。它要求使用者提供多種驗證因素，例如：

  1. 你知道的東西（密碼）
  2. 你擁有的東西（手機或存取徽章）
  3. 你本身的特徵（指紋或視網膜掃描）

常見的多因素身份驗證實作包括雙因素身份驗證（2FA），它結合了密碼和手機簡訊驗證碼等。

多因素身份驗證的重要性

  • 提高帳戶安全性，防止弱密碼或被竊取的憑證被利用
  • 對高風險操作（如特權存取、敏感資料讀取或修改）進行額外的安全保護
  • 減少憑證被盜用的風險，特別是在雲端環境中

多因素身份驗證的重要性與實施方法

在現代雲端運算環境中，密碼已不再是唯一的防線。為了進一步提高安全性，多因素身份驗證（Multi-Factor Authentication, MFA）變得越來越重要。MFA 要求使用者提供兩種或以上的驗證方式，例如「你知道的東西」（如密碼）和「你擁有的東西」（如手機或硬體令牌），以確認其身份。

常見的第二因素驗證方法

許多服務提供了多種第二因素驗證（2FA）方法。最常見的「你擁有的東西」驗證方法包括：

  • 簡訊驗證（SMS）：此方法因容易受到SIM卡克隆或號碼轉移攻擊，已逐漸被淘汰。新的實作不應使用簡訊驗證，而現有的實作應盡快轉換至其他方法。
  • 根據時間的一次性密碼（TOTP）：此方法需要在行動裝置上安裝一個初始「秘密」（通常透過二維碼傳輸）。該秘密是一個公式，用於每分鐘計算一次性密碼。一次性密碼只需保持一兩分鐘的安全，但初始秘密可以讓任何裝置產生有效的密碼，因此使用後應妥善保管或遺忘。
  • 推播通知：此方法需要行動裝置上的客戶端應用程式已經透過身份驗證，並與伺服器建立連線。伺服器會在需要時將一次性程式碼推播回客戶端應用程式。只要客戶端應用程式的身份驗證是安全的，此方法是安全的，但需要行動裝置具有網路連線。
  • 硬體裝置：例如符合FIDO U2F標準的裝置，可以在需要時提供一次性密碼。這類別裝置可能會在未來變得無處不在，並與智慧型手機或穿戴式技術（如手錶和戒指）整合，成為低風險交易（如小額支付或存取多數網站）所需的唯一身份驗證方式。

程式碼範例：TOTP 實作

import hmac
import hashlib
import struct
import time

def get_totp(secret_key):
    # 將 secret_key 從 base32 編碼轉換為 bytes
    secret_key = secret_key.upper()
    secret_key_bytes = base64.b32decode(secret_key)

    # 計算目前的時間步數（30 秒為一個步數）
    time_step = int(time.time() / 30)

    # 將時間步數轉換為 bytes
    time_bytes = struct.pack('>Q', time_step)

    # 使用 HMAC-SHA1 計算雜湊值
    hmac_result = hmac.new(secret_key_bytes, time_bytes, hashlib.sha1).digest()

    # 從雜湊值中提取 4 個位元組
    offset = hmac_result[-1] & 0xf
    truncated_hmac = hmac_result[offset:offset+4]

    # 將提取的 4 個位元組轉換為整數
    truncated_hmac_int = struct.unpack('>I', truncated_hmac)[0]

    # 對整數進行模運算，得到 6 位數的 TOTP
    totp = truncated_hmac_int & 0x7FFFFFFF
    totp = totp % (10**6)

    # 將 TOTP 格式化為 6 位數的字串
    totp_str = f'{totp:06d}'

    return totp_str

#### 內容解密：
1. `get_totp`函式接收一個`secret_key`作為引數，用於生成TOTP。
2. 程式首先將`secret_key`從Base32編碼轉換為位元組，以便後續的HMAC運算。
3. `time_step`變數計算目前的時間步數（每30秒為一個步數），用於確保TOTP的有效時間。
4. 使用HMAC-SHA1演算法對時間步數位元組進行雜湊運算，得到一個20位元組的雜湊值。
5. 從雜湊值中提取4個位元組，並將其轉換為整數，用於生成最終的TOTP。
6. 對整數進行模運算，以得到一個6位數的TOTP，並將其格式化為字串傳回。

### 社交工程攻擊的風險

所有這些驗證「你擁有的東西」的方法都容易受到社交工程攻擊，例如假冒成可信任的實體並要求使用者提供一次性密碼。因此，在實施多因素身份驗證的同時，還需要對使用者進行最基本的培訓，以避免他們無意中破壞第二因素提供的保護。

### 密碼管理的最佳實踐

雖然多因素身份驗證大大提高了安全性，但選擇強密碼仍然非常重要。以下是一些密碼管理的最佳實踐：

1.  **避免重複使用密碼**：除非你真的不關心未經授權的使用者存取受該密碼保護的資源，否則絕不重複使用密碼。
2.  **使用密碼管理器**：由於不重複使用密碼會導致你擁有大量密碼，因此使用評價良好的密碼管理器來管理它們。將主密碼或還原金鑰儲存在物理安全的位置，例如保險箱或銀行保險箱。
3.  **生成強密碼**：對於不需要記住的密碼，使用安全的隨機生成器。二十個字元是一個好的目標，但有些系統可能不接受這麼多字元；對於這些系統，盡可能使用多樣化的字元集。
4.  **建立易記的強密碼**：對於需要記住的密碼，例如密碼管理器的密碼，建立一個六個單詞的Diceware密碼，並在每個單詞之間加上相同的非字母字元，如美元符號、等號或逗號。隨機生成幾次，直到找到一個你可以記住的，並透過一些愚蠢的故事來幫助你記住它。

## 身份與存取管理：密碼驗證與聯合身份驗證

在雲端運算和應用程式開發中，身份與存取管理（Identity and Access Management, IAM）扮演著至關重要的角色。其中，密碼驗證和聯合身份驗證是兩個核心概念，直接影響系統的安全性和使用者經驗。

### 密碼驗證的挑戰

密碼驗證看似簡單，但實際上卻存在許多挑戰。最直接的方法是將使用者密碼儲存在資料函式庫中，並在使用者登入時進行比對。然而，這種方法存在重大安全風險：一旦資料函式庫被入侵，所有使用者的密碼都會被洩露。

#### 密碼雜湊的必要性

為瞭解決這個問題，我們需要使用密碼雜湊（Password Hashing）。密碼雜湊是一種單向函式，可以將密碼轉換為一串固定長度的字串，但無法從雜湊值反推出原始密碼。這樣，即使資料函式庫被入侵，攻擊者也無法直接獲得使用者的密碼。

```python
import bcrypt

def hash_password(password):
    salt = bcrypt.gensalt()
    hashed_password = bcrypt.hashpw(password.encode('utf-8'), salt)
    return hashed_password

def verify_password(password, hashed_password):
    return bcrypt.checkpw(password.encode('utf-8'), hashed_password)

# 使用範例
password = "mysecretpassword"
hashed_password = hash_password(password)
print("雜湊後的密碼：", hashed_password)

is_valid = verify_password(password, hashed_password)
print("密碼是否正確：", is_valid)

內容解密：

  1. bcrypt函式的使用：我們使用bcrypt函式來產生鹽值（salt）和雜湊密碼。鹽值的目的是增加密碼雜湊的複雜度，防止攻擊者使用預先計算好的雜湊表（rainbow table）進行攻擊。
  2. 密碼驗證過程：在驗證密碼時，我們使用bcrypt.checkpw函式將輸入的密碼與儲存在資料函式庫中的雜湊密碼進行比對。如果匹配成功，則表示密碼正確。
  3. 安全性考量：使用bcrypt而不是簡單的雜湊函式（如SHA-256）是因為bcrypt設計上就考慮到了防止暴力破解（brute-force attack）。它透過多次迭代和鹽值增加了計算複雜度，使得攻擊者難以快速猜測出正確的密碼。

聯合身份驗證與單一登入

除了密碼驗證外，聯合身份驗證（Federated Identity）和單一登入（Single Sign-On, SSO）也是重要的身份管理機制。聯合身份驗證允許使用者在多個系統中使用同一身份，而單一登入則進一步簡化了登入流程，讓使用者只需登入一次即可存取多個應用程式。

聯合身份驗證的工作原理

在聯合身份驗證中，兩個或多個系統同意使用相同的身份標識（如電子郵件地址）。當使用者嘗試存取某個系統時，該系統會將身份驗證請求重定向到信任的身份提供者（Identity Provider, IdP）。IdP負責驗證使用者的身份，並傳回一個斷言或令牌，證明使用者的身份已經被驗證。

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333

title 聯合身份驗證的工作原理

rectangle "請求存取" as node1
rectangle "重定向" as node2
rectangle "驗證身份" as node3
rectangle "斷言" as node4
rectangle "允許存取" as node5

node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5

@enduml

此圖示展示了聯合身份驗證的流程，使用者透過服務提供者被重定向到身份提供者進行身份驗證，最終獲得存取許可權。

身份與存取管理中的單一登入（SSO）技術

在身份與存取管理的領域中，單一登入（Single Sign-On, SSO）技術是一種讓使用者只需一次登入就能存取多個應用程式或系統的驗證方式。這種技術不僅提升了使用者經驗，也增強了安全性，因為使用者不需要在多個平台重複輸入憑證。

SSO 的運作原理

SSO 的運作依賴於一個稱為身份提供者（Identity Provider, IdP）的第三方服務。當使用者試圖存取某個應用程式或網站（稱為服務提供者，Service Provider, SP）時，SP 會將使用者導向 IdP 進行驗證。使用者在 IdP 處完成驗證後，IdP 會傳送一個包含使用者身份資訊的憑證回 SP，從而允許使用者存取 SP 的資源。

SAML 與 OIDC

目前，最常見的 SSO 技術有兩種：SAML（Security Assertion Markup Language）和 OIDC（OpenID Connect）。

  1. SAML：是一種根據 XML 的標準，用於在不同的安全域之間交換驗證和授權資料。SAML 2.0 是目前的主流版本，自 2005 年以來一直被廣泛使用，特別是在大型企業應用中。

    • SAML 的流程包括：
      1. 使用者存取某個 SP。
      2. SP 將使用者導向 IdP 進行驗證。
      3. 使用者在 IdP 處完成驗證。
      4. IdP 傳送一個包含使用者身份資訊的 SAML 斷言回 SP。
      5. SP 驗證該斷言並允許使用者存取。

  2. OIDC：是根據 OAuth 2.0 的一個身份層，使用 JSON Web Tokens（JWT）進行身份驗證。OIDC 在 2014 年正式確定，並提供了多種流程，如授權碼流程和隱式流程，以適應不同的應用場景。

    • OIDC 的優點包括：
      • 使用者憑證不會被應用程式直接看到。
      • 使用者只需一次登入即可存取多個應用程式。

對舊有應用程式的 SSO 支援

對於不支援 SSO 的舊有應用程式，可以透過在前端新增一個處理 SSO 請求的服務（如反向代理）來實作。這種服務負責驗證使用者身份，並將驗證結果傳遞給舊有應用程式。

例項後設資料和身份檔案

在雲端環境中，系統可以使用特定的端點來取得有關其所在系統的後設資料和身份檔案，這些資訊經過加密簽名，可以用來證明系統的身份。然而，這種方法需要小心管理，以防止低許可權的程式冒充高許可權的系統。

秘密管理

除了使用者身份驗證外，系統之間也需要安全地進行身份驗證，例如應用伺服器與資料函式庫伺服器之間的驗證。這需要有效的秘密管理技術，如密碼管理器，以確保這些憑證的安全。

程式碼例項與解析

以下是一個簡單的 SAML 請求範例，使用 Python 和 requests 函式庫來模擬使用者存取某個 SP 的過程：

import requests

# 模擬使用者存取某個 SP
sp_url = "https://example.com/sp"
response = requests.get(sp_url)

# SP 將使用者導向 IdP
idp_url = "https://example.com/idp"
response = requests.get(idp_url)

# 使用者在 IdP 處完成驗證
# 這裡需要模擬使用者的登入行為
login_data = {"username": "user", "password": "pass"}
response = requests.post(idp_url, data=login_data)

# IdP 傳送 SAML 斷言回 SP
saml_assertion = response.text
# SP 驗證該斷言
verification_url = "https://example.com/sp/verify"
response = requests.post(verification_url, data=saml_assertion)

#### 內容解密：
1. **模擬使用者存取 SP**：首先，我們使用 `requests` 函式庫傳送 GET 請求到 SP 的 URL，以模擬使用者存取該網站。
2. **導向 IdP**：接著，SP 將使用者導向 IdP 的 URL，我們再次使用 `requests` 傳送 GET 請求到 IdP。
3. **使用者登入**：在 IdP 處，使用者需要完成登入。我們透過傳送 POST 請求攜帶使用者的登入資訊來模擬這一過程。
4. **SAML 斷言**：IdP 在驗證使用者後，會傳送一個 SAML 斷言。我們假設這個斷言被包含在 response.text 中。
5. **驗證斷言**：最後，SP 需要驗證這個 SAML 斷言。我們透過傳送 POST 請求攜帶這個斷言到 SP 的驗證 URL 來完成這一步。

這個範例簡化了 SAML 的流程，實際情況會更為複雜，且需要處理加密、簽名等安全相關的問題。
玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。