華為雲國際帳號購買 國際華為雲OBS子帳號訪問密鑰配置

第一章：為什麼要做「子帳號」訪問密鑰配置

在多團隊、多環境的雲端使用情境裡，把同一把存取憑證交給所有人，通常會帶來兩類問題：第一是風險難以控制，一旦憑證外洩，影響面很大；第二是審計困難，你很難回溯是誰在什麼時間做了哪些操作。

因此，很多人會把「主帳號」作為資源所有者，把「子帳號」分配給不同部門或不同系統，並為每個子帳號配置各自的訪問密鑰。對 OBS（Object Storage Service）這類對象存儲服務而言，正確的密鑰與權限配置，決定了你能否順利上傳、下載與管理桶內物件，同時也決定了你是否能遵守「最小權限」與合規要求。

本文會把重點放在：怎麼建立或使用子帳號、怎麼配置對 OBS 的權限、怎麼生成與管理訪問密鑰，最後再用一套可操作的排查清單處理常見錯誤。你不需要只懂概念；你需要能把它做完、跑起來、且不容易出安全事故。

第二章：理解子帳號與權限邏輯

2.1 主帳號與子帳號的角色差異

在華為雲的體系中，主帳號通常擁有資源的總控能力，而子帳號用於分離身份與職責。你為子帳號授權後，子帳號才能使用 OBS 的 API 或控制台功能完成相應操作。這種設計有兩個好處：一是可以分配不同權限給不同團隊；二是可以在權限出問題時更快定位。

2.2 「訪問密鑰」到底授權了什麼

訪問密鑰在本質上是一種身份憑證。它通常由「Access Key ID」與「Secret Access Key」組成。拿到密鑰後，系統在呼叫 OBS API 時會做簽名，把請求與身份綁定。請求最終是否被允許，不只取決於密鑰是否正確，還取決於你在 IAM 或 OBS 層面配置了哪些權限（例如：允許列舉桶、允許讀取特定路徑、允許上傳指定前綴等）。

換句話說：密鑰讓你「能被識別」，權限才讓你「能被授權」。兩者缺一都不行。

華為雲國際帳號購買 2.3 最小權限原則：不要一開始就放開到最大

很多團隊在早期會直接授予子帳號對所有桶的所有操作權限，目的是省事。可一旦系統變多、流程變複雜，後續收斂權限會非常痛苦，因為你需要重新梳理每個服務到底用到哪些 API。更好的做法是：先按需求列出操作範圍，然後只授予必要權限。

例如：如果子帳號只負責上傳物件，那麼通常只需要具備「寫入/上傳」相關權限，而不必具備「刪除」或「列出所有桶」的能力。若子帳號只處理特定業務資料夾（前綴），也應該把權限限制到該前綴，而不是整個桶。

第三章：配置前的準備工作

3.1 明確你的使用場景

在開始配置之前，建議先回答三個問題：

• 你需要在 OBS 上做哪些操作？例如：上傳、下載、列出桶、列出目錄（前綴）、更新或刪除。
• 你操作的範圍是什麼？是一個桶？還是多個桶？是否只對某個前綴（例如 companyA/、prod/）有權？
• 你的應用運行位置在哪？是伺服器、容器、還是本地開發環境？不同位置對密鑰保存與輪換策略影響很大。

這些答案會直接決定你需要怎麼寫權限與策略，也決定你應該用「哪一種授權方式」。

3.2 檢查桶策略與帳戶策略是否會衝突

OBS 常見會同時涉及帳戶層授權（例如 IAM）與桶層策略（bucket policy）。當你授予了權限，但桶策略又顯式拒絕或沒有覆蓋到對象路徑時，仍可能失敗。反過來也是同樣：桶策略允許，但 IAM 權限不足依然失敗。

因此，準備階段就要確定：你所在的專案採用的是哪一套授權組合，以及桶的策略是否需要調整。

第四章：建立子帳號並分配 OBS 權限

4.1 先建立子帳號或確認已存在

若你的專案已經有子帳號，這一步就跳過。否則，你需要在華為雲中建立子帳號，並確保子帳號能完成後續的身份管理操作。建立過程通常會包含基本資訊與驗證，且要確保你知道後續配置時要用到的子帳號身份標識。

華為雲國際帳號購買 4.2 建立對 OBS 的最小權限集合

在授權時，你可以採用兩種思路：一是直接對子帳號配置一組角色/策略；二是為子帳號綁定特定權限集合。無論採用哪種方式，原則一致：只給必要操作，只限制必要資源。

實務上，你可以把權限拆成三類：

• 資源範圍權限：只對某些桶或特定前綴生效。
• 操作類型權限：上傳/下載/列出/刪除等要逐項確認。
• 附加限制：例如是否允許列出桶（List），是否允許讀取桶的屬性（GetBucketLocation 等）。

如果你不確定 API 級別需要哪些權限，可以先從你正在使用的 SDK 或工具列出呼叫的 API 清單，再反推要授權哪些操作。這比憑感覺直接放寬權限更可靠。

華為雲國際帳號購買 4.3 授予子帳號以「可用於簽名的能力」

華為雲國際帳號購買 OBS 的請求簽名通常依賴密鑰與正確的權限匹配。你需要確認子帳號被授予了能對 OBS 發起簽名請求的權限（例如允許相關的 OBS 動作）。如果你的策略只允許部分動作，常見表現就是：上傳可以，但列出目錄失敗；下載可以，但更新失敗。

這時候不要直接懷疑密鑰壞了，而是回到權限是否覆蓋到該操作。

第五章：生成子帳號訪問密鑰（AK/SK）

5.1 訪問密鑰的生成與保存

在完成子帳號權限配置後，你就可以在子帳號或對應的 IAM 管理界面生成訪問密鑰。通常你會看到生成密鑰的按鈕，並獲得 Access Key ID 與 Secret Access Key。

這裡最重要的一點是：Secret Access Key 很可能只會在生成當下展示一次。你要在當場立刻保存到安全位置。不要直接複製到筆記或聊天軟體，也不要放進版本庫。

5.2 安全保存密鑰：用環境變數與密鑰管理系統

密鑰最常見的洩漏來源，是「硬編碼」與「不受控的日誌」。實務做法建議如下：

• 在應用端使用環境變數或系統密鑰管理服務注入密鑰。
• 確保程式日誌不會打印 Secret Access Key 或完整簽名資訊。
• 在容器或 CI/CD 中，將密鑰以機密變數（secrets）形式注入。
• 將密鑰權限限制在單一服務或單一子系統，避免「所有人共用一套」。

如果你在本地開發，建議用本機的憑證管理方式，而不是把密鑰寫死在程式碼或配置文件中。

5.3 配置時區、端點與區域：別忽略細節

很多人會把密鑰錯誤當成原因，但實際上是「端點或區域選錯」或「簽名時間偏差」。在使用 OBS SDK 時，你通常需要配置：

• OBS endpoint（區域對應的服務地址）
• 簽名時使用的區域名稱（若 SDK 需要）
• 系統時間必須正確（簽名通常包含時間戳）

因此，密鑰生成完成後，不要急著測試；先確認你的程式設定與目標桶所在區域一致。

第六章：在不同環境中落地配置

6.1 開發/測試環境：可快速驗證但要避免污染

開發或測試環境通常需要頻繁測試上傳與下載。此時建議你使用「測試專用的子帳號與密鑰」，避免用生產憑證反覆操作。即使你做了最小權限，也要降低事故成本。

另外，測試環境常見需求是：臨時讀寫某個前綴。你可以提前規劃一個前綴，例如 dev/、test/，並只把權限授予該前綴，讓錯操作造成的損失被控制。

華為雲國際帳號購買 6.2 生產環境：以輪換與審計為核心

生產環境不能只重視「能用」，還要重視「可持續」與「可追責」。建議你把密鑰管理納入流程：

• 密鑰輪換：定期或在風險事件後輪換 Secret Access Key。
• 審計追蹤：記錄每次訪問與關鍵操作，能回溯是誰在用哪套憑證。
• 限制來源：如果你的服務在特定網段或通道中，配合網路層限制可進一步降低風險。

輪換的關鍵在於：不要一次性全切，最好採用可回滾的方式，確保業務不會因密鑰失效而中斷。

6.3 多服務共用：用「子帳號分工」而不是共享密鑰

如果一個專案同時包含上傳服務、處理服務、下載服務，你可以為每個服務分配不同子帳號與不同權限集合。這樣即使某個服務出現漏洞，也不會直接等同於整套數據都暴露。

在策略設計上，針對每個服務只授予它需要的前綴與操作類型，會比「一套密鑰搞定全部」更可控。

第七章：常見錯誤與排查思路

7.1 簽名錯誤：先查時間與端點

當你遇到類似「SignatureDoesNotMatch」或簽名相關錯誤時，第一步通常不是重做密鑰，而是檢查：

• 系統時間是否正確（NTP 同步）
• OBS endpoint 是否與桶所在區域一致
• 簽名所用的時區與 SDK 設定是否正確

很多簽名問題都源於時間偏差或端點配置不一致。你重生成密鑰也許能「碰巧修好」，但那只是運氣，不是定位問題。

7.2 403 Forbidden：權限或桶策略沒有覆蓋到你要的資源

403 是最常見的錯。它通常代表「已識別身份，但沒有足夠權限」。你可以依序檢查：

• 子帳號是否被授予對應 OBS 動作（上傳、下載、列舉等）
• 權限是否限制了桶或前綴，而你正在操作的路徑是否在範圍內
• 桶策略是否拒絕了該來源或該操作

一個高效方法是：先用相同操作在控制台或使用最簡單的 API 測試，再對照權限差異。你也可以把操作分解：例如先測 List 前綴，再測 GetObject，避免一次測多個動作導致定位困難。

7.3 404 Not Found：桶名或物件鍵（Key）可能不一致

404 不一定是權限問題。有時只是桶名錯或物件鍵拼接錯誤。尤其在你使用前綴時，常見錯誤是少了或多了一個斜線，例如 companyA/prod/file.txt 與 companyA/prod//file.txt 在實際 Key 上是不同的。

因此排查時要把你上傳與下載時的 Key 完整對照，包括大小寫與分隔符。

7.4 400 Bad Request：請求參數或頭部不符合預期

有些錯誤與密鑰無關，例如 Content-MD5、Content-Type 或某些必填參數缺失。你可以先查看 SDK 或工具的請求參數是否正確，再看是否存在特殊限制（例如桶是否需要特定的加密方式或版本控制狀態）。

第八章：把配置做成「可維護」的流程

8.1 用文件與模板固化配置

配置密鑰與權限不是一次性的事。隨著團隊成員更替、服務擴張、部署環境增加，你需要一套能快速交接的方式。建議你準備至少三份資料：

• 每個子帳號用途說明：負責哪些服務、會操作哪些桶與前綴
• 權限摘要：允許哪些操作，不允許哪些操作
• 密鑰管理規則：何時輪換、誰有權查看、如何回滾

這些文件不必花哨，但要能讓接手的人在一小時內看懂「該怎麼用、出了事先看哪裡」。

8.2 建立密鑰輪換的演練計畫

很多團隊只在出事後才輪換密鑰，輪換時常常伴隨服務短暫中斷。更好的做法是定期演練：在預演環境中替換密鑰，確認應用是否能無縫或低風險重啟完成驗證。

華為雲國際帳號購買 演練時要關注三點：新密鑰是否立即生效、舊密鑰是否仍可用、替換流程是否能避免同時變更太多配置導致定位困難。

8.3 對敏感資料進行額外保護

如果你存放的是敏感數據，除了密鑰與權限外，你還需要考慮：

• 傳輸是否全程加密（HTTPS）
• 是否啟用靜態加密或伺服器端加密策略
• 是否需要對物件設置更細粒度的存取控制

權限是第一道門，其他加密或策略是第二道門。兩道門都做好，才真正把風險降到合理範圍。

第九章：一個實務範例的配置思路（不依賴特定工具）

下面用一個典型案例幫你把流程串起來：假設某公司有三個服務：上傳服務、處理服務、下載服務。三者都只需要操作同一個桶中的不同前綴。

9.1 設計子帳號分工

• 子帳號 A：上傳服務，只允許寫入桶 my-bucket，前綴為 uploads/
• 子帳號 B：處理服務，只允許讀取/uploads/並將結果寫入 results/，不允許刪除
• 子帳號 C：下載服務，只允許讀取 results/，不允許列出整個桶或上傳

這樣做的目的很明確：每個服務的風險面被縮小，且發生問題時可以更快速定位到底是哪個子帳號的憑證或權限出了差錯。

9.2 生成並保存密鑰

為子帳號 A/B/C 分別生成訪問密鑰，並把 Secret Access Key 分別以機密方式注入到對應服務。上傳服務不會拿到下載服務的密鑰，處理服務不會具備刪除權限。

9.3 測試順序：先驗證最小可用能力

• 先用子帳號 A 測上傳一個測試檔案到 uploads/，確認寫入與端點正確。
• 再用子帳號 B 測能讀取該檔案並寫入 results/，確認前綴權限正確。
• 最後用子帳號 C 測能下載 results/ 中檔案，確認只讀權限生效。

你不要一上來就測所有操作混合在一起，因為出錯時你會很難判斷是哪一段權限或參數失敗。

第十章：結語——把「能用」變成「放心用」

華為雲國際帳號購買 國際華為雲 OBS 子帳號訪問密鑰配置的核心不在於一次性把密鑰貼進程式，而在於：你要讓身份與權限邏輯清晰、讓範圍被限制在最小可用集合、讓密鑰可安全保存且能輪換、讓排錯有路徑可依循。

當你能做到這些，你得到的就不只是「上傳成功」，而是一套能支撐長期運維與合規要求的雲端訪問方案。之後新服務接入時，也能沿用同一套流程：先定義前綴與操作，再授權最小權限，最後配置密鑰並走測試與審計。你會發現，雲端權限管理真正帶來的價值，是讓團隊在速度與安全之間找到穩定的平衡。