最近在研究通信安全方面的東西，看到七牛這篇文章寫得不錯，轉載一下：
安全機制
數據安全性是雲存儲服務的重中之重。雲存儲的安全機制主要需要考慮以下幾個因素：
-
如何判斷該請求方是否合法，且對目標空間有相應的訪問權限。
-
因爲服務的訪問協議同時支持HTTP和HTTPS，服務端需要判斷收到的請求是否經過篡改。
-
相比上傳新資源，覆蓋文件或刪除已有資源擁有更高的風險。因此對上傳或修改動作，需要確認請求方是否擁有修改或刪除的權限。
在使用七牛雲存儲服務的過程中，需要考慮安全機制的場景主要有如下幾種：
-
上傳資源
-
訪問資源
-
管理和修改資源
這三個場景需要考慮不同的安全因素，因此七牛針對性的提供了三種安全機制：上傳憑證、下載憑證和管理憑證。
因爲憑證的生成需要用到SecretKey，因此該生成動作不應在不受信任的環境中進行。需要注意的是，開發者絕不能將密鑰包含在分發給最終用戶的程序中，無論是包含在配置文件中還是二進制文件中都會帶來非常大的密鑰泄漏風險。
推薦的模型如下所示：
密鑰（AccessKey/SecretKey）
密鑰用於以上幾種憑證的生成。以SecretKey爲參數，配合適當的簽名算法，可以得到原始信息的數字簽名，防止內容在傳遞過程中被僞造或篡改。
密鑰通常爲成對創建和使用，包含一個AccessKey和一個SecretKey。其中AccessKey會在傳輸中包含，而用戶必須保管好SecretKey不在網絡上傳輸以防止被竊取。若SecretKey被惡意第三方竊取，可能導致非常嚴重的數據泄漏風險。因此，如發現SecretKey被非法使用，管理員應第一時間在七牛開發者平臺上更換密鑰。
在具體描述各種憑證的詳細生成過程中我們會看到AccessKey和SecretKey是如何被使用的。
憑證的詳細生成 跳轉鏈接： http://developer.qiniu.com/article/developer/security/index.html
使用場景
七牛推薦客戶將 AccessKey和一個SecretKey 放在服務端，由服務端生成令牌後頒發給客戶端使用。
比如，上傳文件的時候：
-
業務服務器的服務端生成上傳令牌（UploadToken）
-
客戶端程序（iOS、Android 以及 Web）拿到這個上傳令牌之後就可以直接將文件上傳到七牛
錯誤案例
把 AK/SK 放在客戶端 SDK 中來做簽名生成令牌，隨 App 被髮布出去。
這樣做會被人家反編譯之後拿到 AK/SK，之後他們就可以對你的賬號進行操作。
實際上 Web 端 js 也是可以做簽名的，只是你不可能把明文的 AK/SK 放在 Web 端，這樣做更加危險。
將 AK/SK 加密後存放在客戶端，等用戶啓動應用的時候再將 AK/SK 解密出來放在內存中，關閉應用後這對 AK/SK 即消失。
這樣的做法也是不科學的，因爲你的 AK/SK 在 後臺 隨時可以更改，特別是在被泄漏之後建議使用一對新的 AK/SK。如果你寫死在 App 中將其發佈，就只能通過發佈新版本的 App 來更新這對 AK/SK。
最後建議
出於安全考慮，建議您根據自己的場景週期性地更換密鑰。
原文轉自：https://support.qiniu.com/hc/kb/article/112814/