我有一個 IAM 用戶，該用戶可以通過訪問/密鑰以編程方式訪問 CloudWatch Log API。我正在使用以下策略來限制它僅訪問特定的LogGroup.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "logs:DescribeLogGroups",
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "logs:DescribeLogStreams",
"Resource": "arn:aws:logs:us-west-2:223237870883:log-group:/myappname/dev/client/uwp"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:us-west-2:223237870883:log-group:/myappname/dev/client/uwp:log-stream:*",
"arn:aws:logs:us-west-2:223237870883:log-group:/myappname/dev/client/uwp"
]
}
]
}
密鑰將隨移動應用程式一起發送到 Android/iOS/Windows/macOS 應用程式商店。每個應用程式都有自己的密鑰/策略（以上適用于 UWP 應用程式），將其限制為LogGroup我通過CloudFormation創建的自己的 CloudWatch 。
我的問題是關于鑰匙本身。我可以將它們放在組態檔中，也可以將它們硬編碼到二進制檔案中。我打算對它們進行硬編碼，因為無論如何我都無法在事后更改組態檔 - 如果我想更改它們，無論如何我都需要發布新版本的應用程式。似乎在應用程式中對它們進行硬編碼會使某人更難以嘗試和竊取。
如果它們被盜，更糟糕的情況是它們會用 CloudWatch 日志淹沒我。有什么我可以做的嘗試并防止這種情況發生嗎？我試圖查看 Amplify 以及它如何處理這個問題，但沒有看到任何突出的東西。
我從安全角度采取的方法是否有任何問題，或者這對課程來說是否相當標準？
作為旁注，我最初集成了 Visual Studio App Center 日志記錄，但不想處理構建一個程序來從 App Center 為客戶端和 CloudWatch 為我的后端聚合日志。App Center 似乎以相同的方式作業 - 訪問密鑰/客戶端密鑰沒有真正阻止某人在應用程式之外竊取和登錄。
感謝任何人可以提供的有關您在此類事情上的經驗的任何指導。不是在尋找正確的答案。想看看人們采取了什么其他方法來看看我是否完全偏離了人跡罕至的道路。
uj5u.com熱心網友回復：
是的，您可以通過將憑證隱藏在 API 端點后面來防止傳送憑證，然后您可以對每個應用程式部署進行速率限制、保護、輪換訪問等。
雖然最糟糕的情況是它們可能會用日志淹沒您，但如果您已經有后端 API，那么最好在您和 Cloudwatch 之間有一個專用的日志記錄端點。
但是，我不會太擔心，您授予的權限最小，這是最重要的因素。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/313163.html