在 iOS 客戶端和后端服務器上管理對 AWS 服務的訪問

Question

在設計將與AWS （例如S3 、 CloudFront等）交互的iOS應用程序時，在客戶端和服務器上管理對這些服務的訪問的優缺點是什么？

通過“管理訪問”，我的意思是將私有內容上傳到 S3，通過 Cloudfront 下載私有內容。

當然，處理訪問的任何一方都需要存儲AWS訪問密鑰和訪問密鑰。 安全性是關注的問題之一。

我對這種設計選擇對任一實現的性能和靈活性的影響同樣感興趣。

最后，是否存在實施混合方法的論據，即客戶端和服務器都直接與AWS交互，或者實施通常是其中之一，但不是兩者兼而有之？

Answer 1

雖然通常有很多情況您可能想要以任何一種方式執行此操作，但由於您提到了 ios，因此幾乎沒有任何情況下您想直接從客戶端執行此操作：

通過服務器端將數據上傳到 AWS 的優點：

1. 安全

   正如在另一個答案中已經提到的，如果他們試圖破壞東西，最初對請求進行身份驗證可以為您節省很多麻煩。 如果數據是私有的並且您確實致力於保護隱私，那么如果系統經過身份驗證，任何數據泄漏都會更容易防止。

2. 限速、用戶配額等

   認證系統的附加優勢是您可以對來自特定來源的請求進行速率限制，例如用戶、組、IP 等（如果您打算圍繞同一系統架構構建多個應用程序，則應用程序級別配額）。 當您直接在客戶端工作時，構建這種智能並不容易。

3. 審計追蹤

   如果您需要跟蹤誰上傳了什么內容、何時、從何處上傳以及更多此類信息，如果您直接在服務器上獲得初始請求，那么這將再次更容易跟蹤。

4. 失敗時的異常處理

   在 QA 測試期間很可能會出現您無法輕易預測的故障，或者遺漏了一個關鍵錯誤。 處理這些服務器端效率更高，因為它在您的控制之下。 當客戶端出現任何此類問題時，您只能任由客戶升級應用程序。 如果您正在處理此服務器端，則可以輕松地為許多此類錯誤放置/部署額外的檢查，從而限制錯誤的范圍。

5. 是時候上線了

   同樣，如另一個答案中所述，您的更新可能需要一段時間才能獲得批准。 這大大降低了您對關鍵問題的響應能力，並且在嚴重問題（數據泄漏/隱私泄露）導致重大損失（財務/用戶信任/負面評價等）的情況下可能難以緩解

我認為您希望將數據直接從客戶端上傳到 AWS 的唯一情況是

• 非常非常頻繁地上傳大量數據，無需直接處理。

  如果上傳一次會消耗一定數量的帶寬和網絡資源，則上傳兩次會占用兩倍的資源（一次來自client --> server ，然后來自server --> AWS ）。 因此，如果您經常上傳大量數據（想想每天 TB），那么您最終只會浪費大量資源，只是將數據從一個點復制到另一個點。 在這種情況下，直接推送數據 S3 是有意義的。 但是要使這種方法發揮作用，您節省的成本應該足夠高，可以消除對安全和隱私的擔憂，而對於大多數應用程序而言，情況並非如此。

• 你在圍牆花園里

  基本上，該應用程序僅適用於某些預先確定的用戶，該應用程序根本不適用於其他任何人（假設您正在開發該應用程序供公司內部使用）。 從本質上講，這意味着對最終用戶使用您的應用程序的動機有 100% 的信心。

---

編輯：OP 在評論中詢問

服務器提供簽名的 URL/cookie 怎么樣，客戶端使用這些上傳到 S3 或從 Cloudfront 下載。 客戶端仍然直接與 AWS 交互，但需要由服務器控制的權限。

乍一看，在我看來這是非常可行的。 這篇博文提供了許多關於使用簽名 url 的用例（例如提供通配符簽名的 url 以供閱讀）（盡管示例在.NET ），更多信息可在AWS docs 中獲得。

由於您將處理簽名服務器端，因此您可以輕松處理我之前在我的帖子中提到的每一點（速率限制、用戶配額、審計跟蹤等都是可行的，因為請求最初將轉到服務器）。 正如這個答案所提到的，

簽名 URL 有助於控制誰可以訪問給定文件以及他們可以訪問它多長時間。

總的來說，這應該適用於很多用例。

Answer 2

在您對用戶進行身份驗證后，安全性是我將所有/大部分 AWS 服務身份驗證放在后端的主要原因。

另一個考慮因素是考慮到他們的審批流程，在 Apple Store 上刷新您的應用程序所需的時間。 根據 Apple Store 隊列，您可能需要數天時間才能將更改推送到您的應用程序； AWS 后端的更改可以隨意進行。

此外，在設計與 AWS 服務交互的應用程序時，我始終假設傳輸的任何內容都可能受到損害，並且很可能會被那些解構您的調用並重建自己的調用以滿足他們的需求的人使用。

（例如，在啟動上傳圖像然后應用過濾器的照片娛樂應用程序后不久，我們注意到來自同一 IP 的應用程序中不存在的帶有過濾器 ID 的日志條目。它們沒有成功，因為它們沒有通過身份驗證.)

希望有幫助。

Answer 3

除了其他好的答案之外，我還想補充一點：與網絡應用程序不同，您不能期望所有用戶都擁有您的應用程序的最新版本。 這意味着您的應用程序的任何版本所調用的任何服務器 url 原則上都必須永遠保持有效。 這意味着如果你想改變你的服務器基礎設施（例如從 AWS 遷移到其他雲主機），那么你不能，因為即使你用新的 url 更新你的應用程序，那么仍然會有一些未更新的應用程序會調用舊網址。

您當然可以選擇在應用程序中設置“強制更新”機制，在更新之前您無法使用它（這在多人游戲中很常見，但在其他很多地方並不常見）或者只是不關心少數用戶您的應用程序的舊版本讓您的生活變得悲慘（情節扭曲 - 他們可能會停留在您的應用程序的舊版本上，因為他們的設備無法升級到最新的iOS版本）。

但更好的解決方案 IMO 是將 AWS url 隱藏在您自己的服務器后面，這樣您就永遠不會遇到這個問題。 這是一個你真的不應該泄漏到客戶端的實現細節。

Answer 4

出於安全原因，將您的密鑰保存在無法被篡改的地方很重要：這通常意味着將它們留在服務器上。

以這種方式考慮您的密鑰：它們授予對組織資源的訪問權限。 通過將您的密鑰放在移動設備上，密鑰被盜會影響您在組織級別的資源。 相反，在移動設備上使用用戶級身份驗證通過服務器上的代理授予對 AWS 資源的訪問權限。 這樣，用戶級別憑據的丟失不會導致組織級別的丟失。 撤銷用戶級憑據更容易。

您還提到了上傳到 S3。 AWS 有一個很好的工具，稱為 presigned-post，您的服務器生成一次性上傳憑證，您的移動設備可以使用該憑證將數據上傳到 S3……而無需通過您的服務器代理數據。

# ruby
presigned_post = bucket.presigned_post(key: key, success_action_status: 201, acl: :public_read)