套用 Azure 儲存體安全性最佳做法
我們檢閱過如何建立和使用共用存取簽章 (SAS)，及其可為儲存體安全性解決方案提供的優點。
請務必了解，在應用程式中使用 SAS 可能導致潛在風險。
如果 SAS 洩漏出去，任何取得它人都可以存取儲存體。
如果提供給用戶端應用程式的 SAS 已過期，且該應用程式無法從您的服務擷取新的 SAS，則應用程式的功能就會受到影響。
請觀看這段影片，深入了解如何保護您的儲存體。 這段影片是以 Azure 秘訣和訣竅 #272 Azure 安全性最佳做法為基礎。
管理風險的建議
以下是一些有助降低 SAS 相關風險的建議。
| 建議 | 描述 |
|---|---|
| 建立和發佈時一律使用 HTTPS | 如果 SAS 透過 HTTP 傳遞時遭到攔截，攻擊者便能使用 SAS。 這些中間人攻擊可能會洩漏敏感性資料，或讓惡意使用者損毀資料。 |
| 盡可能參考預存存取原則 | 預存存取原則提供了撤銷權限且無需重新產生 Azure 儲存體帳戶金鑰的選項。 將儲存體帳戶金鑰到期日設定在遙遠的未來。 |
| 設定非計劃性 SAS 的短期到期時間 | 若 SAS 外洩，您可將 SAS 效期限制在較短時間內，藉此減輕攻擊的影響。 如果您無法參考預存存取原則，此做法非常重要。 短期到期時間也會限制可用的上傳時間，可寫入 blob 的資料量也會因此受限。 |
| 要求用戶端自動更新 SAS | 要求用戶端在到期日之前更新 SAS。 提早更新可在提供 SAS 的服務不可用的情況下提供更多重試的時間。 |
| 仔細規劃 SAS 開始時間 | 如果您將 SAS 的開始時間設為 [現在]，則由於時鐘誤差 (根據不同機器會有不同的目前時間)，前幾分鐘可能偶爾會被視為失敗。 一般而言，請將開始時間設為至少 15 分鐘之前的時間。 或者，您也可不設定特定的開始時間，讓 SAS 在所有情況下立即生效。 相同的條件通常適用於到期時間。 在任何要求上，順逆時鐘誤差可能長達 15 分鐘。 針對使用早於 2012-02-12 REST API 版本的用戶端電腦，不參考預存存取原則 SAS 的持續時間上限為 1 小時。 任何指定更長期間的原則都會失敗。 |
| 定義資源的最低存取權限 | 安全性最佳做法是提供使用者最低需求權限。 如果使用者只須要針對單一實體的讀取存取權，請為該單一實體授予讀取存取權限，無須為所有實體授予讀取/寫入/刪除權限。 這麼做有助減輕 SAS 外洩所造成的損害，因為即便 SAS 落入攻擊者手中，所提供的能力也相當有限。 |
| 了解包括 SAS 在內的用量帳戶計費方式 | 提供受限權限以協助降低惡意使用者可能動作的風險。 讀取和寫入權限可能會導致帳單費用。 使用短期 SAS 來降低此威脅。 |
| 使用 SAS 驗證寫入資料 | 用戶端應用程式將資料寫入您的 Azure 儲存體帳戶時，請留意該資料可能造成問題。 如果您的應用程式需要已驗證或已授權的資料，請在寫入之後進行驗證再使用。 這麼一來，無論是透過正當管道取得 SAS 的使用者，還是濫用外洩 SAS 的攻擊者，都無法將損毀或惡意資料寫入您的帳戶。 |
| 不要假設 SAS 一律是正確的選擇 | 在部分情節中，在 Azure 儲存體帳戶中執行特定作業的相關風險可能大過使用 SAS 的好處。 針對這類作業，請在執行過商業規則確認、驗證和稽核後，建立寫入儲存體帳戶的中介層服務。 另外，有時候以其他方式管理存取權可能比較簡單。 如果您想要讓容器中的所有 blob 都可供公開讀取，則可將此容器設定為 [公用]，而不是將 SAS 提供給每個用戶端進行存取。 |
| 使用 Azure 儲存體分析監視您的應用程式 | 您可以使用記錄和計量觀察驗證失敗的尖峰。 您可能會發現 SAS 提供者服務中出現中斷尖峰，或是預存存取原則中出現意外移除尖峰。 |