TLDR
我正在为工业自动化目的做出休息会话管理解决方案，并需要自动登录设备以执行配置。
Note ：
这些设备的时间占99％，将隔离到专用网络/VPN（即，将没有公共IP）
困境，
我的任务是创建可以存储硬件设备的服务可以进行自动配置（＆amp;指标刮擦）的凭据。所讨论的硬件仅允许通过邮政方法登录列表，该方法将在消息正文中发送用户和（未加密的）密码。这返回了我的服务然后存储（内存）的会话cookie。
所讨论的服务包括：
- linux（ubuntu 20.04）服务器
- fastapi python backend
- sqlite 3嵌入式文件DB
存储凭据？
我的背景不在安全状态，所以这对我来说都是非常新的，但是我似乎应该在我的数据库中存储我的密码的哈希（例如，bcrypt）以进行将来验证，但是会不是是任何将来的验证，因为这都是自动化的。
这使我想到了唯一的解决方案 - 将密码放置，并将其用作盐来加密密码，然后将哈希密码存储在DB中，以稍后进行解密。我知道，鉴于数据库已被妥协，但对于替代解决方案而言，这几乎提供了0个安全性。鉴于数据库已嵌入，也许还有一些额外的保证，即服务器本身必须在DB本身受到损害之前必须妥协？我不知道是否有一种技术“正确”的方法，也许不是，但是如果有人有任何建议，我全都是耳朵。
TLDR
I am making a REST Session management solution for industrial automation purposes and need to automatically log into devices to perform configurations.
NOTE:
These devices are 99% of the time going to be isolated to private networks/VPNs (i.e., Will not have a public IP)
Dilemma
I am being tasked with creating a service that can store hardware device credentials so automated configurations (& metrics scraping) can be done. The hardware in question only allows REST Session logins via a POST method where the user and (unencrypted) password are sent in the message body. This returns a Session cookie that my service then stores (in memory).
The service in question consists of:
- Linux (Ubuntu 20.04) server
- FastAPI python backend
- SQLITE3 embedded file DB
Storing Credentials?
My background is not in Security so this is all very new to me but it seems that I should prefer storing a hash (e.g., bcrypt) of my password in my DB for future verification however there will not be any future verification as this is all automated.
This brings me to what seems like is the only solution - hashing the password and using that as the salt to encrypt the password, then storing the hashed password in the DB for decryption purposes later. I know this provides almost 0 security given the DB is compromised but I am at a loss for alternate solutions. Given the DB is embedded, maybe there is some added assurance that the server itself would have to be compromised before the DB itself is compromised? I don't know if there is a technical "right" approach to this, maybe not, however if anyone has any advice I am all ears.
发布评论
评论（1）
您应该考虑使用硬件安全模块（HSM）。有云替代品（例如AWS Secrets Manager，这是一个基于存储在实际HSM中的密钥AWS KMS中的密钥存储库）。或者，如果您的应用程序未托管在公共云中，则可以考虑购买实际的HSM，但这很昂贵。因此，这一切都取决于您要接受成本的风险。
您还可以考虑建立建筑以正确保护您的秘密。如果您建立安全的秘密商店服务并应用适当的保护（这太广泛了，无法在此处描述答案），您至少可以提供秘密用法的审核，您可以实现访问控制，您可以轻松撤销秘密，您可以监视该组件中的使用模式，依此类推。基本上，您的秘密服务将像一个非常受保护的“ HSM”，尽管它可能根本不涉及专门的硬件。这不能保证秘密（通常是秘密加密密钥）不能像真正的HSM那样从服务中检索，但是它将具有上述许多好处。
但是，请注意，使用适当的保护是其中的关键 - 这根本不是直接的。您可以采用的一种方法是对潜在的攻击者进行建模，列出方式（攻击路径），以损害不同组件的不同方面，然后对这些组件的不同方面进行设计保护，只要在经济上有意义。
You should consider using a hardware security module (HSM). There are cloud alternatives (like AWS Secrets manager, an encrypted secrets repository based on keys stored in an actual HSM, AWS KMS). Or if your app is not hosted in a public cloud, you can consider buying an actual HSM too, but that's expensive. So it all comes down to the risk you want to accept vs the cost.
You can also consider building architecture to properly protect your secrets. If you build a secure secrets store service and apply appropriate protection (which would be too broad to describe for an answer here), you can at least provide auditing of secret usage, you can implement access control, you can easily revoke secrets, you can monitor usage patterns in that component and so on. Basically your secrets service would act like a very well protected "HSM", albeit it might not involve specialized hardware at all. This would not guarantee that secrets (secret encryption keys, typically) cannot ever be retrieved from the service like a real HSM would, but it would have many of the benefits as described above.
However, do note that applying appropriate protection is the key there - and that's not straightforward at all. One approach that you can take is model your potential attackers, list ways (attack paths) for compromising different aspects of different components, and then design protections against those, as long as it makes sense financially.