Azure的Blob存儲和安全最佳實踐

Question

在探索Azure存儲我發現訪問存儲容器是通過共享密鑰來完成。我擔心，如果開發人員將這個密鑰用於他們正在構建的應用程序，然後離開公司，他們仍然可以登錄到存儲帳戶並刪除他們想要的任何東西。解決方法是重新生成帳戶的輔助鍵，但是我們必須更改每個使用這些鍵的應用程序中的所有鍵。

是它讓每個應用程序每環境（開發，測試，運行，生產）的整個存儲帳戶的最佳實踐？ 可以保護虛擬網絡後面的存儲帳戶嗎？ 我們是否應該在每個應用程序的基礎上在容器上使用簽名？

任何人都有類似的經歷，並找到了解決這一良好格局？

Answer 1

我有一點不同的場景 - 外部應用程序，但問題是相同的 - 數據訪問安全

我使用共享訪問簽名（SAS）授予對容器的訪問。

在你的情況下，您可以在容器上創建每個應用程序的共享訪問策略，並使用長的到期時間這個存儲訪問策略生成SAS，您可以通過從容器中取出的共享訪問策略在任何時候撤銷它。因此，在您的情況下，您可以撤銷當前的SAS並在您的開發人員離開時生成新的SAS。您無法爲多個容器生成單個SAS，因此如果您的應用程序使用多個容器，則必須生成多個SAS。

用法，從開發商的角度來看，保持不變： 您可以使用SAS令牌創建CloudStorageAccount或CloudBlobClient所以它幾乎像一個普通的快捷鍵。

從長期來看，我可能會考慮創建負責生成SAS和更新他們一個內部服務（內部API）。通過這種方式，您可以擁有完全自動化的系統，並僅通過向主要服務機構披露訪問密鑰然後，您可以通過虛擬網絡，證書，身份驗證等方式限制對此服務的訪問。如果出現問題（編寫該服務的開發人員離開:-)，您可以重新生成訪問密鑰並進行更改，但這次只能在一個地方進行。

幾件事情：

• 每個應用程序（和/或環境）存儲帳戶是一個很好的策略，但你必須要知道的限制 - 每認購最多100個存儲賬戶。
• 沒有選項來限制訪問存儲帳戶與虛擬網絡
• 你可以有一個容器

Answer 2

我不會進入主觀/意見答案最多5個共享訪問策略，但從客觀角度來看：如果開發人員擁有存儲帳戶密鑰，則他們可以完全訪問存儲帳戶。如果他們離開了公司並保留了鑰匙的副本？阻止它們的唯一方法是重新生成密鑰。

你可能會認爲，與不同的存儲賬戶分離的應用程序幫助。不過，請記住這一點：如果開發人員有權訪問訂閱，則他們可以訪問該訂閱中每個存儲帳戶的密鑰。

在考慮密鑰更新時，請考慮知道密鑰本身的應用的總表面積。如果存儲操作僅僅是服務器端操作，那麼更改密鑰的影響是最小的（每個部署中的小應用更改以及更新所使用的任何存儲瀏覽工具）。如果將密鑰嵌入到桌面/移動應用程序中進行直接存儲訪問，則不得不推出更新的客戶端時遇到更大的問題，但無論如何，您已經遇到了安全問題。