STRIDE 模型提供一個結構化方法識別軟體系統中的潛在威脅，特別適用於評估無伺服器應用程式安全。除了理解 STRIDE 的六種威脅型別外，開發者也需關注供應鏈安全，例如定期更新依賴套件版本並進行漏洞掃描。在無伺服器架構中，執行時更新、SLSA 安全框架和 Lambda 程式碼簽名都是確保安全的重要環節。此外，保護無伺服器 API 免受未授權存取至關重要，Amazon API Gateway 提供的存取控制策略，如 Cognito 和 JWT 授權器，可有效提升 API 安全性。實務上，Lambda 函式可用於實作自定義授權邏輯，尤其在非 Cognito 或驗證 Webhook 訊息場景。多租戶架構和零信任架構的整合，更能強化整體安全策略，確保只有經過驗證的使用者才能存取特定資源。
瞭解STRIDE威脅模型與其應用
STRIDE是一種廣泛使用的威脅模型，幫助開發人員和安全專家識別潛在的安全威脅。STRIDE代表了六種不同型別的威脅：Spoofing（欺騙）、Tampering（篡改）、Repudiation（否認）、Information Disclosure（資訊洩露）、Denial of Service（服務拒絕）和Elevation of Privilege（許可權提升）。透過將STRIDE應用於應用程式中的每個元素，開發人員可以更全面地瞭解其應用程式面臨的潛在安全風險。
STRIDE威脅模型的元素
- 人為因素/外部實體：包括使用者、管理員和其他可能與系統互動的外部實體。
- 過程：系統中執行的各種程式和任務。
- 資料儲存：系統中儲存的各種資料，包括資料函式庫、檔案等。
- 資料流：系統中資料的流動和傳遞，包括網路通訊等。
執行STRIDE威脅模型的步驟
- 識別元素：找出系統中的所有元素，包括人為因素、過程、資料儲存和資料流。
- 識別威脅：對每個元素，根據STRIDE模型識別可能的安全威脅。
- 評估風險：評估每個識別出的威脅的風險和可能性。
- 減輕風險：針對每個威脅，制定相應的減輕措施和解決方案。
保障供應鏈安全
供應鏈安全是指保護軟體供應鏈免受攻擊和漏洞的過程。隨著開源軟體的廣泛使用，供應鏈安全成為了一個重要的問題。開發人員需要注意以下幾點：
- 依賴關係：瞭解所使用的開源軟體及其依賴關係。
- 版本更新：保持依賴軟體的版本更新，以確保獲得最新的安全補丁。
- 風險評估：定期評估依賴軟體的風險，並採取相應措施。
自動化升級和掃描
- 自動化升級：使用工具自動化依賴軟體的升級，以確保及時獲得安全補丁。
- 掃描漏洞：使用安全掃描工具定期檢查依賴軟體中的漏洞。
保障無伺服器供應鏈安全
無伺服器架構雖然提供了許多優勢，但也需要關注其安全性。其中一個重要的方面是供應鏈安全。供應鏈安全涉及確保軟體元件和依賴項的安全，以防止潛在的安全風險。
執行時更新
保持最新的執行時版本對於無伺服器應用程式至關重要。AWS Lambda 提供了自動更新執行時的功能，同時也允許您控制更新的時機。這些控制可以幫助您減少由執行時更新引起的潛在錯誤或相容性問題。
SLSA 安全框架
SLSA（Supply chain Levels for Software Artifacts）是一個安全框架，旨在提高軟體供應鏈的安全性和完整性。它提供了一套標準和控制措施，以防止篡改、提高完整性和保護軟體包和基礎設施。如果您已經達到了一定的安全成熟度，使用 SLSA 框架來衡量和改善軟體供應鏈的安全性可能會很有幫助。
Lambda 程式碼簽名
Lambda 程式碼簽名是一個重要的安全功能，允許您簽署程式碼並驗證其完整性。這可以確保程式碼在佈署過程中沒有被篡改或修改。您可以建立簽署組態檔案並將其應用於您的 Lambda 函式，以啟用程式碼簽名。
保護無伺服器 API
無伺服器 API 的安全性同樣重要。根據 OWASP Top 10 清單，斷開的存取控制是 Web 應用程式面臨的最大威脅之一。雖然無伺服器架構可以減輕一些威脅，但您仍然需要實施適當的存取控制機制。
Amazon API Gateway 提供了多種存取控制策略，包括 Cognito 授權器和 JWT 授權器。您需要根據您的具體需求選擇合適的策略，並確保其與您的 API Gateway 端點相容。
圖表翻譯：
graph LR
A[供應鏈安全] --> B[執行時更新]
A --> C[SLSA 安全框架]
A --> D[Lambda 程式碼簽名]
A --> E[無伺服器 API 保護]
B --> F[自動更新]
B --> G[控制更新時機]
C --> H[防止篡改]
C --> I[提高完整性]
D --> J[簽署程式碼]
D --> K[驗證完整性]
E --> L[實施存取控制]
E --> M[選擇合適的策略]
內容解密：
上述內容介紹了無伺服器供應鏈安全的重要性和相關措施。執行時更新、SLSA 安全框架、Lambda 程式碼簽名和無伺服器 API 的保護都是保障無伺服器應用程式安全性的關鍵方面。透過瞭解和實施這些措施，您可以提高您的無伺服器應用程式的安全性和完整性。
使用 Amazon Cognito 來保護伺服器無法 API
當使用存取管理服務時，Lambda 函式可以用來實作自訂授權邏輯，特別是在使用非 Cognito 或驗證傳入 Webhook 訊息時，無法使用根據使用者的身份驗證。您仍然可以使用 JWT 來授權和驗證 REST API 請求，但需要撰寫自訂的 Lambda 授權函式來驗證傳入的令牌。
Amazon Cognito 簡介
Amazon Cognito 是一種存取管理服務，可以用來保護 REST API。它是 AWS 的原生服務，因此提供最小的額外負擔。要使用 Cognito 來保護 API，需要了解其組成部分和存取控制架構。
使用者池
使用者池是 Amazon Cognito 中的使用者目錄。通常，您會在應用程式中有一個單一的使用者池，用於管理所有使用者。
應用程式客戶端
您可以為每個租戶建立一個應用程式客戶端，並與租戶後端服務分享客戶端 ID 和密碼，以進行機器對機器的身份驗證。
範圍
範圍用於控制應用程式客戶端對特定資源的存取。
應用程式基礎的多租戶架構
多租戶架構是一種身份和存取管理架構，支援在多個使用者群組或租戶之間分享應用程式的底層資源。這種架構也與零信任架構相互補充，需要更細緻的存取控制模型。
Cognito 和 API Gateway
Cognito 授權函式提供了一種完全管理的存取控制整合與 API Gateway。API 使用者可以交換其憑證（客戶端 ID 和密碼）以取得存取令牌，然後將這些令牌包含在 API 請求中，並透過 Cognito 授權函式進行驗證。
保護 HTTP API
如果您使用的是 API Gateway HTTP API，而不是 REST API，則無法使用原生的 Cognito 授權函式。相反，您可以使用 Lambda 授權函式或 JWT 授權函式等替代方案。
flowchart TD
A[API 使用者] --> B[交換憑證]
B --> C[取得存取令牌]
C --> D[包含在 API 請求中]
D --> E[透過 Cognito 授權函式進行驗證]
圖表翻譯：
此圖表示了 API 使用者如何交換憑證以取得存取令牌，然後將這些令牌包含在 API 請求中，並透過 Cognito 授權函式進行驗證。這種過程提供了一種安全的方式來保護 API，並確保只有授權的使用者才能存取特定資源。
import boto3
cognito_idp = boto3.client('cognito-idp')
def get_access_token(client_id, client_secret):
# 交換憑證以取得存取令牌
response = cognito_idp.admin_initiate_auth(
UserPoolId='YOUR_USER_POOL_ID',
ClientId=client_id,
AuthFlow='ADMIN_NO_SRP_AUTH',
AuthParameters={
'USERNAME': 'YOUR_USERNAME',
'PASSWORD': 'YOUR_PASSWORD'
}
)
access_token = response['AuthenticationResult']['AccessToken']
return access_token
def validate_access_token(access_token):
# 驗證存取令牌
response = cognito_idp.get_user(
AccessToken=access_token
)
return response['UserAttributes']
內容解密：
此程式碼示範瞭如何使用 AWS Cognito 來取得存取令牌並驗證其有效性。get_access_token 函式交換憑證以取得存取令牌，而 validate_access_token 函式則驗證存取令牌的有效性。這些函式可以用於保護 API，並確保只有授權的使用者才能存取特定資源。
使用JWT授權器和Lambda授權器保護Serverless API
在Serverless架構中，API Gateway扮演著重要的角色，負責管理API請求和回應。為了確保API的安全性，需要實施適當的授權機制。這裡介紹兩種授權器：JWT授權器和Lambda授權器。
JWT授權器
JWT（JSON Web Token）是一種開放標準，定義了一種緊湊、自包含的方式，安全地在各方之間傳輸資訊。JWT授權器適合於簡單的授權策略，僅需驗證使用者提交的JSON Web Token即可。
使用JWT授權器時，需要先組態授權器，然後將其附加到路由上。CloudFormation資源的組態如下：
{
"Type": "AWS::ApiGatewayV2::Authorizer",
"Properties": {
"ApiId": "ApiGatewayId",
"AuthorizerType": "JWT",
"IdentitySource": ["$request.header.Authorization"],
"JwtConfiguration": {},
"Name": "my-authorizer"
}
}
其中，IdentitySource應該與使用者在API請求中提供的JWT位置相匹配，例如Authorization HTTP標頭。JwtConfiguration應該對應於預期的令牌值，其中Audience是令牌接收者的HTTP地址（通常是API Gateway域），而Issuer是釋出令牌的服務的HTTP地址（例如Cognito或Okta）。
Lambda授權器
Lambda授權器是指附加到API Gateway HTTP API路由的Lambda函式，負責實施自定義授權邏輯。這種授權器適合於需要超出管理的Cognito或JWT授權器支援的存取控制策略的情況。
Lambda授權器支援多種身份源，包括HTTP標頭和查詢字串引數（例如Authorization標頭）。使用者必須在API請求中提供必要的身份源，否則將收到401未經授權的回應，而Lambda授權器將不會被呼叫。
Lambda授權器的回應也可以被快取。根據使用者提供的身份源，API Gateway將使用快取的授權結果，而不是呼叫Lambda函式。
驗證和驗證API請求
除了存取控制機制外，還需要保護Serverless API免受故意或非故意的濫用和請求資料驗證和過濾。API Gateway提供了兩種保護方式：
- 請求保護：API Gateway提供了兩種保護方式：使用計劃和請求限制。使用計劃可以控制存取API階段和方法，並限制請求速率。
- 請求驗證和過濾：API Gateway可以驗證和過濾傳入的請求資料，以防止惡意攻擊。
從系統架構與安全防護的整合視角來看，本文深入探討了保障無伺服器應用程式供應鏈安全的關鍵措施，涵蓋了執行時更新、SLSA安全框架、程式碼簽章以及API 授權等多個層面。分析顯示，執行時自動更新機制雖能有效降低漏洞風險，但仍需審慎管理更新時機以避免相容性問題。SLSA框架的匯入則能提升軟體供應鏈的整體安全性和完整性，但其複雜度較高，更適用於已具備一定安全基礎的團隊。此外，程式碼簽章和API 授權機制則分別確保了程式碼的完整性和API 端點的安全性，是構建安全可靠無伺服器應用不可或缺的環節。然而，在實際應用中，如何平衡安全性和開發效率仍是一項挑戰。展望未來，隨著DevSecOps 理念的普及和自動化工具的發展，預計無伺服器應用程式的安全防護將更加便捷和高效。對於追求高安全性的企業，建議優先匯入程式碼簽章和API 授權機制，並逐步整合SLSA框架，以構建更具韌性的無伺服器應用程式。
