AWS DynamoDB使用基於AWS Cognito和IAM角色的客戶端（Web應用程序）直接訪問的安全漏洞是什麼

Question

直接訪問AWS DynamoDB的客戶端應用程序（使用客戶端JavaScript的Web應用程序）（使用aws-sdk）以及DynamoDB可訪問性由AWS Cognito進行身份驗證。所有用戶都必須使用AWS Cognito登錄才能訪問AWS DynamoDB。

對於上述無服務器（客戶端JavaScript應用程序 - 從瀏覽器訪問），上述應用程序體系結構有哪些安全漏洞？

Answer 1

當你把你的代碼放到你的web應用程序中時，任何具有正確知識的人都可以根據表，索引和鍵名稱察覺到你的後端體系結構。

應用程序安全性的最佳實踐是不要讓任何人都能獲得這種信息。有知識和動力的人可以利用這些內部信息來開發一個載體，試圖利用你的環境。

AWS環境提供安全的體系結構。但是如果你可以保護你的環境對於剝削者來說有點難，也許他們會尋找其他事物或其他環境。

Answer 2

您需要確保通過Cognito授予用戶權限盡可能受限。最明顯的是他們將擁有隻讀權限，否則，用戶將能夠調整您的代碼以刪除，更新或將項目放入您的表格。

另一個風險是用戶將能夠訪問同一個表上的其他用戶的數據。如果您的表格包含您的每個用戶（例如個人資料）的數據，並且您希望允許每個用戶快速檢索其個人資料，則用戶將能夠調整您的代碼以從其他用戶讀取數據。您可以限制使用細粒度訪問控制（http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/specifying-conditions.html），這將允許用戶使用其user_id讀取（或寫入）只有一條記錄。

您可以考慮在用戶和DynamoDB表之間放置AWS Lambda以對輸入進行更多檢查，以及激活DynamoDB流以捕獲對錶進行的每一項更改以從錯誤更改中恢復（甚至具有正確的權限）。

Answer 3

對於小型單用戶（無組和角色）的Web應用程序，您可以使用Cognito和DynamoDB Fine-Grained Access Control爲經認證的用戶提供行級訪問控制，這可以在理想情況下提供安全體系結構。然而，在實際實施安全和其他因素方面有幾個。

• 單個IAM策略更改可能會爲數據訪問創建高風險安全漏洞。
• 經過驗證的用戶可能會因過度使用DynamoDB而損害系統，導致DynamoDB成本大幅增加。
• 無法提供基於角色的訪問控制。
• Dynamodb表架構限制支持Cognito認證用戶的細粒度訪問控制，這可能會限制查詢性能。
• 不能使用在休息加密（在DynamoDB表例如，加密數據使用AWS KMS）

Answer 4

爲了鞏固已經寫了別人，而你一定能夠做到這一點，在大多數情況下，它可以很容易如果你不小心，就讓你暴露。如果您的DynamoDB表包含屬於多個用戶的數據，那麼正確獲取權限可能會非常棘手且容易出錯。

將AWS Lambda函數置於其間的建議可能會有幫助。我想指出的另一個選擇是，您可以直接將DynamoDB與API Gateway結合使用。這有幾個潛在的優勢：

• 您可以使用不同的（甚至沒有），授權方案爲前後調用DynamoDB
• 您之後訪問數據庫
• 您可以在API網關做驗證任務可以更好地利用某些類型的請求緩存（例如，查詢請求通常是通常無法緩存的POST請求; API網關可以將查詢作爲GET請求公開，從而允許將結果緩存到下游）

For more inf請參閱AWS的示例：https://aws.amazon.com/blogs/compute/using-amazon-api-gateway-as-a-proxy-for-dynamodb/