淺談Azure Storage的安全性

在今天的博文中我們將討論Azure Storage的安全性以及如何使用共享訪問簽名（SAS）和存儲的訪問策略來控制對容器和Blob的訪問。SAS基本上是帶有查詢參數的URI，該查詢參數指定諸如到期時間，權限和簽名等選項。我將在本文后面詳細介紹這些內容。請注意，共享訪問簽名也可以與表和隊列一起使用，但是我將僅在Blob存儲方面進行討論

什么是共享訪問簽名（SAS）
共享訪問簽名（SAS）是URI，它允許使用者在指定時間范圍具有訪問存儲資源（例如blob或容器）所允許的權限。時間跨度和權限可以從存儲的訪問策略中得出，也可以在URI中指定。
可能有得朋友看到這里會提出我使用存儲賬戶密鑰就可以了，為什么要使用此功能？因為這允許客戶端在不知道我們存儲賬戶密鑰的情況下訪問存儲帳戶中的容器和Blob。從安全的角度考慮，如果將存儲帳戶密鑰放在客戶端應用程序中，則它可能會遭到******，并且可能會被他人竊取和使用，甚至會用感染了病毒的文件替換正常的文件。使用存儲帳戶密鑰，對存儲帳戶的訪問沒有限制。在企業中的實際環境中，無限訪問可能不是我們想看到的權限控制場景。

默認的容器權限
在控制對Blob存儲的訪問時，首先要使用容器權限。可以將blob存儲中每個容器的權限設置為如下權限之一：

• Private：禁止公眾訪問Blob或容器
• Blob：Blob的公共讀取權限
• Container：Blob容器和Blob的公共讀取訪問

如果將權限設置為Private，則只有具有存儲帳戶名和密鑰，或者使用共享訪問簽名，才能訪問Blob和容器。
如果將權限設置為Blob，則在容器中具有URL的任何人都可以讀取blob以及blob屬性和元數據。除非他們使用具有適當權限的共享訪問簽名，否則他們將無法編寫Blob或獲取有關Blob所在容器的任何信息，也無法在容器中獲取Blob列表。
如果將權限設置為Container，則容器和Blob是公共可讀的。可以列出容器中的Blob，也可以下載Blob。可以讀取容器屬性和元數據；還可以讀取blob屬性和元數據。請注意，即使擁有此權限，也仍然無法修改，上傳或刪除Blob，如果希望進行修改，上傳或刪除則需要帳戶密鑰或適當的SAS。
這表明我們可以結合使用容器權限和共享訪問簽名來控制對Blob和容器的訪問粒度。

存儲訪問策略
下面是創建SAS URI的兩種方法。首先，可以創建一個臨時的SAS來訪問文件或容器，并指定使用的過期日期和權限。如果這樣做，應該考慮將時間跨度設置為15分鐘之類的小時間跨度，以最小化其他人使用相同URL訪問相同文件的機會。例如，如果我們正在檢索SAS URI以顯示一組圖片，則有人可能在Fiddler中看到uri并使用它們，直到它們過期。當使用SAS URI時，取消訪問權限的惟一其他方法是更改存儲帳戶密鑰，這可能會產生嚴重影響，具體取決于有多少應用程序正在使用該存儲帳戶。

創建SAS URI的第二種方法是為容器設置存儲的訪問策略，并指定名稱、啟動時間、過期時間、權限等。然后，當我們需要一個SAS URI時，我們可以創建它并指定存儲的訪問策略的名稱，而不是URI的特定版本所需的所有參數。在進行授權時，將從存儲的訪問策略檢索信息。另外，與臨時SAS URI不同，如果您想撤銷訪問權限，您可以簡單地更改存儲的訪問策略，從存儲的訪問策略繼承的所有SAS URI將立即被修改，這比更改存儲帳戶密鑰更可取!

需要注意的是一個容器最多可以有5個存儲的訪問策略。每個策略可以由任意數量的共享訪問簽名使用。例如，可以為讀/寫和只讀訪問設置不同的訪問策略，使用不同的過期時間。您可以使用的特定uri的數量沒有限制。

在創建存儲訪問策略時，可以指定啟動時間、過期時間和權限的任何組合。如果在策略上指定它們，則必須從實際的SAS URI中省略參數。或者，可以在存儲的訪問策略中指定其中一些參數，而在SAS URI中指定其他參數。實際上，可以在創建存儲訪問策略時指定SAS URI上的所有參數，但是如果這樣做，則只能使用存儲的訪問策略來撤銷簽名，而不能修改簽名的行為。

共享訪問簽名和存儲的訪問策略必須包含驗證簽名所需的所有字段，并且不能有重復的字段。例如，您不能將存儲的訪問策略設置為具有權限R/W，不能創建SAS URI并指定只讀權限。

通過編寫要使用的策略的完整列表，在容器上設置存儲的訪問策略。如果希望取消對其中一個策略的訪問，可以通過編寫策略列表并排除該策略來刪除它。如果希望更改其中一個策略的權限，則必須使用包含修改后的策略的新列表覆蓋存儲的策略列表。

到目前為止，相信各位已經了解了存儲訪問策略，接下來讓我們來看看共享訪問簽名。

共享訪問簽名

前面也和大家提到，SAS是一個URI，它在其查詢參數中包括所有信息，以驗證對Blob或容器的訪問所需的身份。查詢參數可以包括以下內容（實際查詢參數在參數名稱后的括號中）：

• Blob URI：這是Blob的地址。我們應該始終使用HTTPS構造共享訪問簽名。示例：https://sql12bak.blob.core.chinacloudapi.cn
• 存儲服務版本（sv）：指示要使用的存儲服務版本。示例：sv = 2019-02-02這是可選的，如果未指定，它將設置為可用的最新版本。
• 開始時間（st）：這是SAS生效的時間。如果省略，則SAS立即生效。由于計算機之間的時差（時鐘偏斜），因此請務必小心。如果您將開始時間設置為現在，則可能是將來在另一資源上使用5分鐘，并且可能不允許再訪問5分鐘。除非時間不長，否則建議不要設置此設置，或者將開始時間設置為當前時間之前的15分鐘。此文件必須為ISO 8061格式。示例：st=2020-01-19T03:27:10Z
• 到期時間（秒）：這是SAS不再有效的時間。我們應該始終使用它，或者將其與具有此設置的存儲訪問策略相關聯。此文件必須為ISO 8061格式。示例：se=2020-01-19T11:27:10Z
• 存儲資源（sr）：告訴資源是否是blob，隊列等。示例：sr = b，它表示資源是blob，或sr = c，說資源是容器。
• 權限（sp）：這定義了可以對存儲資源執行的操作。示例：sp = rw，它授予讀取（r）和寫入（w）訪問權限。
• 簽名（sig）：用于驗證對Blob的訪問。這是使用SHA256算法在字符串到符號和密鑰上計算的HMAC，然后使用Base64編碼進行編碼。
  示例：sig = Z％2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk％3D

將這些內容放在一起會產生以下URI，它允許對存儲帳戶sql12bak中container進行讀/寫訪問，時間為2020年1月19日11:27:10 AM至2020年1月19日7:27:10 PM
https://sql12bak.blob.core.chinacloudapi.cn/?sv=2019-02-02&ss=bfqt&srt=sco&sp=rw&se=2020-01-19T11:27:10Z&st=2020-01-19T03:27:10Z&spr=https&sig=pOyu%2FIVLKBVeQWydo3vxIJKEi46NXxwk%2FH%2BtXyas5c8%3D

這是一個臨時SAS。通過指定所有必需的查詢參數和Blob的原始URI來訪問Blob時，可以創建此文件。

撤銷權限

臨時SAS URI與使用存儲的訪問策略之間的重要區別與撤銷所允許的權限有關。有了SAS，無論創建了哪個進程，任何獲取URI的人都可以使用它。因此，在前面提到的方案中，如果客戶使用Fiddler捕獲了一個SAS URI，則他可以將其發送給其他人，然后其他人可以訪問存儲帳戶中的文件并上載或下載。

SAS URI與用于創建簽名的帳戶密鑰和關聯的存儲訪問策略（如果有）相關聯。如果未指定任何存儲訪問策略，則撤消共享訪問簽名的唯一方法是更改存儲帳戶密鑰。

通常，SAS可以一直工作到：

已達到SAS的到期時間。
如果使用了存儲的訪問策略，則在達到存儲的訪問策略的到期時間時，SAS將停止工作。發生這種情況的原因是時間實際上已到期，或者因為存儲的訪問策略的到期時間已修改為過去。
如果您使用存儲的訪問策略，并且SAS引用的策略被刪除，則SAS將不再起作用。
將重新創建用于創建SAS的帳戶密鑰。

最佳實踐
創建或分發SAS時，需要始終使用HTTPS。如果通過HTTP傳遞SAS，則可以由執行中間人***的人讀取和使用。

盡可能使用存儲的訪問策略，因為使用它們可以撤消權限而不必重新生成存儲帳戶密鑰。如果需要永久訪問權限，請將過期時間設置為較長時間，并確保定期更新以將其移至更遠的將來。

使用臨時SAS URI時，請使用盡可能小的日期范圍來限制曝光。

如有必要，請客戶端應用程序更新SAS。因此，如果有權訪問映像，并且SAS過期，則應用程序應該能夠對其進行更新，以使客戶端沒有障礙。

如前所述，在設置SAS起始時間時，請務必通過排除起始時間參數或從當前時間中減去15分鐘來解決時鐘偏移問題。

請具體說明需要訪問的資源。如果客戶只需要訪問一個Blob，則不要讓他們訪問整個容器。

在將SAS寫入存儲之后但使用它之前，請驗證使用SAS寫入的數據，以確保它沒有損壞或惡意。

不要總是使用SAS。如果您想對輸入數據的驗證進行更多控制，或者想在身份驗證方面增加額外的安全性，則可能需要創建一個中間層服務來對blob存儲進行讀寫。另外，如果有一種更簡單的方法來提供訪問權限，請使用它。例如，如果您希望容器中的所有Blob對公眾都是可讀的，請使容器公開，而不是為需要訪問的每個客戶端創建SAS。

使用存儲分析來監視我們的應用程序。這將幫助我們發現由于SAS提供程序服務問題或意外刪除存儲的訪問策略而導致的身份驗證失敗。