解決 AWS S3 HeadObject 錯誤 (403 Forbidden)：詳細指南

當您嘗試在 AWS S3 上處理文件操作（例如讀取、上傳或檢查文件）時，可能會遇到以下錯誤：

Error converting image to webp: An error occurred (403) when calling the HeadObject operation: Forbidden

該錯誤表示當前用戶或角色沒有足夠的權限來執行 HeadObject 操作。

儘管 AWS 不直接提供 s3:HeadObject 的明確權限，它實際上依賴於 s3:GetObject 的許可權。

本篇文章將深入分析該問題的成因，並提供詳細的解決步驟。

HeadObject 是什麼？

HeadObject 是 AWS S3 的一個操作，用於檢查物件的元數據而不下載其內容。

這種操作通常由 boto3 等 SDK 隱式調用，例如在檢查文件是否存在時。

雖然 s3:HeadObject 不是一個獨立的許可權，但它依賴於 s3:GetObject 的許可權。

錯誤的可能原因

當遇到 403 Forbidden 錯誤時，可能由以下幾種原因引起：

1. 缺少 s3:GetObject 許可權：
   HeadObject 操作需要 s3:GetObject 許可權，如果策略中未包含此操作，就會導致權限不足。
2. 資源 ARN 格式不匹配：
   如果策略中定義的 ARN（Amazon Resource Name）不正確，S3 無法正確匹配資源，從而拒絕請求。
3. 其他限制條件：
   • 服務控制策略（SCP） 限制。
   • 跨賬戶訪問未正確配置。

解決方案

以下是逐步解決該錯誤的具體方法：

確保 S3 策略允許 s3:GetObject

您需要在 S3 存儲桶策略中添加 s3:GetObject 許可權，並確保其覆蓋正確的資源。

桶策略範例

以下是一個允許指定用戶（或角色）執行必要操作的策略範例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::xxxxxxxxx:user/xxxxxxx"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::trico-django-bucket/*",  // 指向物件（文件）
                "arn:aws:s3:::trico-django-bucket"    // 指向存儲桶
            ]
        }
    ]
}

策略解釋

• Principal：定義有權執行操作的用戶或角色。替換為具體的 AWS ARN。
• Action：列出允許的操作，包括：
  • s3:GetObject：允許讀取物件（包括 HeadObject 操作）。
  • s3:PutObject：允許上傳物件。
  • s3:ListBucket：允許列出存儲桶中的物件。
• Resource：
  • 指向物件時使用 /*。
  • 指向存儲桶時不加 /。

檢查與驗證 IAM 策略

在解決 AWS S3 403 Forbidden 錯誤時，檢查 IAM 策略是關鍵步驟之一。

然而，有時候問題可能與 AWS 自動應用的限制策略有關，例如 AWSCompromisedKeyQuarantineV3 策略。

這是一種 AWS 自動附加的限制策略，旨在防止疑似洩露或濫用的密鑰繼續操作敏感資源。

為什麼會出現限制策略？

當 AWS 檢測到某個訪問密鑰可能被洩露（例如出現在公共平台如 GitHub），會自動為相關用戶附加限制策略（如 AWSCompromisedKeyQuarantineV3）。

該策略會限制該用戶執行以下操作：

• s3:GetObject：禁止讀取 S3 對象。
• s3:ListAllMyBuckets：禁止列出所有存儲桶。
• 其他高風險操作。

是否可以直接刪除限制策略？

不建議直接刪除，原因如下：

1. AWS 的安全警告：
   • 限制策略的附加是 AWS 的安全響應措施，表明您的密鑰可能已被公開或存在風險。應先解決潛在的安全問題，而不是簡單刪除策略。
2. 無法解決根本問題：
   • 即使刪除了限制策略，AWS 如果再次檢測到密鑰風險，仍可能重新附加該策略。
   • 正確做法應包括禁用或輪換密鑰。

正確的處理方法

1. 檢查是否存在受影響的訪問密鑰

您需要確認限制策略是否由密鑰洩露引起。步驟如下：

1. 登入 AWS 管理控制台：
   • 導航至 IAM > Users > Security credentials。
2. 檢查密鑰狀態：
   • 查看該用戶（例如 trico_user）的訪問密鑰是否標記為“已洩露”或“需要輪換”。
   • 如果密鑰被標記為風險：
     • 立即禁用或刪除該密鑰。
     • 生成新的訪問密鑰。
3. 更新應用程序配置：
   • 將新的密鑰應用到所有使用該密鑰的服務中（如代碼、配置文件或環境變數）。

2. 刪除策略後生成新密鑰

如果您已確認密鑰問題已解決，可以安全刪除限制策略：

1. 刪除 AWSCompromisedKeyQuarantineV3 策略：
   • 導航至 IAM，用戶管理頁面，移除該限制策略。
2. 檢查其他策略：
   • 確保用戶策略或桶策略中沒有其他限制（例如顯式拒絕 s3:GetObject）。
3. 測試操作：
   • 測試是否可以正常執行 s3:GetObject 或 s3:ListBucket 操作。

3. 如果無法確認密鑰是否洩露

如果您不確定密鑰是否洩露，建議聯繫 AWS Support：

1. 提交支持工單：
   • 在 AWS Support 中描述您的問題。
   • 請求 AWS 核實是否有誤標記，並提供解決方案。
2. 尋求具體建議：
   • AWS Support 可以幫助您判斷密鑰是否安全，以及是否可以刪除限制策略。

注意事項與最佳實踐

使用環境變數管理密鑰

避免將 AWS 憑證直接硬編碼到代碼中，建議使用環境變數或 IAM 角色。例如：

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"

在代碼中使用：

import os
AWS_ACCESS_KEY_ID = os.getenv('AWS_ACCESS_KEY_ID')
AWS_SECRET_ACCESS_KEY = os.getenv('AWS_SECRET_ACCESS_KEY')

精簡權限

只分配最小必要權限，避免使用過於寬泛的策略（如 s3:*）。這樣可以減少安全風險。

維護策略一致性

確保存儲桶策略和 IAM 策略不衝突，並且使用相同的 ARN 格式。例如：

• 如果存儲桶策略使用 arn:aws:s3:::my-bucket/*，則 IAM 策略也應一致。

結論

403 Forbidden 錯誤通常由權限不足引起，具體原因可能是缺少 s3:GetObject 權限或資源 ARN 配置不正確。

本指南通過逐步分析與解決方案，幫助您快速排查問題並恢復正常操作。

同時，本文還提供了一些實用的最佳實踐，幫助您優化 AWS S3 的權限管理。