保護你的 Azure 佇列儲存體

Azure 佇列儲存體提供應用程式元件間的訊息佇列。由於訊息常帶有敏感資源的參考——物件識別碼、回調網址和應用程式狀態——你必須同時保護佇列授權與訊息內容處理。

Note

本文將介紹 Azure 佇列儲存體特有的安全實務。關於帳號層級的安全指引，請參見「保護你的 Azure 儲存體帳號」。

身分識別與存取權管理

將 Microsoft Entra ID 與受控識別搭配用於佇列生產者和取用者：將內建的 儲存體佇列資料訊息傳送者、儲存體佇列資料訊息處理者 和 儲存體佇列資料讀取者 角色指派給每個與佇列互動之服務的受控識別。選擇與操作相符的角色。訊息傳送服務不應該持有處理器權限。欲了解更多資訊，請參閱授權使用 Microsoft Entra ID 存取佇列。
將基於角色的存取控制 (RBAC) 角色指派範圍限定在特定佇列：內建的佇列資料角色支援佇列層級範圍。當服務在含有多個佇列的帳戶中只需要存取其中一個佇列時，應在佇列層級進行指派，而不是在儲存體帳戶層級進行指派。
將 SAS 標記範圍至單一佇列及特定訊息操作：隊列共享存取簽章（SAS）分別支援 add、 update、 process及 read 權限。只給予來電者所需的。會將事件加入佇列的 webhook 接收器應該只接收 add，而不是 process。如需詳細資訊，請參閱使用共用存取簽章委派存取。

訊息在靜態和傳輸中會受到帳號加密和 TLS 設定的保護，但除了隊列層級授權外，並不會被個別存取控制。設計訊息內容以避免敏感資料集中在排隊中。

不要在佇列訊息中放入秘密或憑證：將秘密存放在 Azure Key Vault，並在訊息中放入參考（秘密識別碼）。取用者會在處理時，以自己的身分擷取該秘密。放入訊息中的任何內容，對於在該佇列上具有 process 或 read 權限的所有主體都是可見的，且會寫入儲存體記錄檔。
在應用程式層加密敏感訊息承載內容：對於必須承載敏感資料的訊息，請先使用金鑰保存庫中的金鑰加密其承載內容，再將其加入佇列。這增加一層獨立於儲存端加密的層，並限制消費者被入侵時的風險。欲了解更多資訊，請參閱 Azure 儲存體的用戶端加密。
設定合理的訊息存活時間（TTL）：訊息會持續存在，直到被處理、過期或佇列耗盡為止。長的 TTL 會增加可回收過時敏感資料的視窗。將 TTL 與預期的處理延遲加上安全邊際匹配。

啟用佇列操作的診斷設定：將、 StorageReadStorageWriteStorageDelete 、及類別傳送至 Log Analytics，使個別佇列操作可被稽核。追蹤授權方法（Entra ID、共享金鑰、SAS、匿名）以偵測濫用。欲了解更多資訊，請參閱監控 Azure 佇列儲存體。
將毒訊息移至專用的毒訊息佇列：請將取用者設定為偵測超出取出計數臨界值的訊息，並將這些訊息移至 <queue-name>-poison 佇列，以供離線調查。毒訊息佇列的累積不僅是維運訊號，也是安全性訊號。欲了解更多資訊，請參閱「處理佇列觸發函式中的毒訊息」。
針對有害佇列增長發出警示：針對每個有害佇列中的訊息數設定 Azure 監視器警示，以便在出現非預期增長時觸發調查。
針對異常的取出與刪除模式發出警示：如果來自非預期身分的 DeleteMessage 作業出現暴增，或是出現大量僅取出訊息、卻沒有後續處理的活動，都可能表示攻擊者正在清空佇列以掩蓋活動軌跡。當佇列的流量偏離正常流量模式時發出警示。

此頁面對您有幫助嗎？