觀點 · 資訊分享

AWS Bedrock 護欄可以全組織統一強制：管理帳號設一次，所有成員帳號的 AI 呼叫都受管

AWS 4/3 宣布 Amazon Bedrock Guardrails 的跨帳號護欄正式推出。資安團隊在管理帳號指定一個護欄，就能套用到整個組織每一次 Bedrock 模型呼叫，不用再逐一替每個帳號設定。

一句話看懂：AWS 讓資安團隊在管理帳號設定一個 Bedrock 護欄，就能自動套用到整個組織所有帳號的 AI 模型呼叫，不用再逐一設定。

Bedrock 護欄可全組織強制資訊圖卡：管理帳號設一次，全組織 Bedrock 呼叫都受護欄管

先用白話講：護欄是什麼？跨帳號又是什麼？

想像一家連鎖餐廳，總公司規定「所有分店都不能賣過期食材」。以前的做法是派人去每間分店檢查、貼規定；現在總公司可以直接在中央廚房裝一道檢查關卡，所有分店的食材都得先過關。

Bedrock Guardrails（護欄） 就是替 AI 加上的檢查關卡：檢查使用者送進來的提示詞、也檢查模型回覆的內容，擋掉不該出現的東西。跨帳號 則是把這道關卡從「每個帳號自己設」變成「總公司一次設好，全部帳號都適用」。

AWS 在 4 月 3 日宣布，Bedrock Guardrails 的跨帳號護欄正式推出（GA）：

層級	在哪裡設定	適用範圍
組織層	AWS Organizations 的 Bedrock 政策	組織根、OU 或指定帳號
帳號層	Bedrock Guardrails 主控台	單一帳號在該區域的所有推論呼叫

官方說可以搭配使用：組織層做統一底線、帳號層與應用程式層再補上各部門或各應用的需求。

GA 版本新增的功能：

納入或排除特定模型：決定哪些模型要被強制套用護欄
提示詞防護範圍：系統提示詞與使用者提示詞可選「全面（Comprehensive）」或「選擇性（Selective）」。全面是不管呼叫端怎麼標記都一律檢查，官方稱這是較安全的預設；選擇性則是信任呼叫端標好需要檢查的內容，可減少不必要的處理

設定時要注意：

護欄必須先建立一個固定版本，確保成員帳號無法修改它，並先完成資源型政策（resource-based policy）等前置作業
政策裡的護欄 ARN 與版本要填正確；填錯會造成政策違規、護欄沒生效，成員帳號甚至無法用 Bedrock 的模型做推論
受管的呼叫包含 InvokeModel、InvokeModelWithResponseStream、Converse、ConverseStream 這 4 種 API
Automated Reasoning 檢查目前不支援這個功能
提供區域：所有支援 Bedrock Guardrails 的 AWS 商業區域與 GovCloud 區域

接案時，同一個客戶常常會有開發、測試、正式幾個 AWS 帳號，如果每個帳號都要手動設一次護欄，遲早會漏掉哪一個。能在管理帳號一次設好，對有多帳號架構的團隊真的省事。

不過我會特別留意「填錯會讓整個帳號叫不動模型」這一點。集中管理的另一面，就是一個設定錯誤會影響所有帳號。上線前一定要先拿一個測試用的 OU 或帳號驗證，確認護欄版本、ARN 都正確，再往上推到整個組織。

Bedrock Guardrails 是什麼？

它是 Bedrock 提供的安全護欄，可以檢查送進模型的提示詞與模型的回覆，擋掉有害內容，也能過濾模型的幻覺回答。AWS 宣稱最高可擋下 88% 的有害多模態內容。

組織層與帳號層強制有什麼差別？

組織層是在 AWS Organizations 建 Bedrock 政策，套用到整個組織或指定 OU、帳號；帳號層是在 Bedrock 主控台為單一帳號指定護欄，套用到該帳號在該區域的所有推論呼叫。

要另外付費嗎？

官方說明：每個被強制執行的護欄，依它所設定的防護項目收費，細節請看 Bedrock 定價頁。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。