这种架构的安全性如何？
我正在构建一个系统，需要通过安全的网络连接收集一些用户敏感数据，将其安全地存储在服务器上，以便以后自动解密和重用。系统还应允许用户查看受保护数据的某些部分（例如，*****ze）和/或通过网络完全更改它。系统应提供合理的安全级别。
我正在考虑以下基础设施：
应用程序（Web）服务器 1
具有适当 TLS 支持的 Web 服务器 用于安全的 Web 连接。
使用公钥算法（例如RSA） 加密输入的用户敏感数据 并将其发送到App Server 2 单向出站安全通道 （例如 ssh-2）而不存储它 应用服务器 1 或数据库上的任何位置 服务器1。
使用依赖于用户密码的 对称密钥算法进行加密 输入数据的某些部分（例如 最后几个字母/数字）并存储 将其放在数据库服务器 1 上供以后使用 期间由应用服务器 1 检索 用户网络会话。
重复使用步骤 2，由用户通过 Web 修改数据。
DB Server 1
- 存储不安全的非敏感用户 数据。
- 存储部分敏感信息 在应用服务器 1 上加密的用户数据 （请参阅上面的步骤 3）
应用服务器 2
- 不要永远发送任何内容 TO 应用服务器 1 或数据库服务器 1。
- 接收加密的用户敏感信息 来自应用服务器1的数据并存储 在数据库服务器2中。
- 检索加密 来自DB Server 2的用户敏感数据 根据当地的时间表， 使用私钥解密 （参见应用服务器 1，步骤 2）已存储 本地应用服务器 2 并进行适当的密钥管理。
数据库服务器 2
- 存储加密的用户敏感数据（请参阅应用程序服务器 2，步骤 2）
如果应用程序（Web）服务器 1 或 数据库服务器 1 或两者都受到损害，那么攻击者将无法获取任何用户敏感数据（无论是否加密）。所有攻击者都可以访问众所周知的公钥和加密算法。然而，攻击者将能够修改网络服务器以获取当前登录的明文用户密码，并解密存储在数据库服务器 1 中的部分用户敏感数据（参见应用程序服务器 1，步骤 3），但我不这样做。不要认为这是一件大事。攻击者还能够（通过代码修改）在潜在攻击期间拦截用户通过网络输入的用户敏感数据。后来我认为风险较高，但假设攻击者很难（是吗？）在没有人注意到的情况下修改代码，我想我不应该太担心。
如果App Server 2和私钥被泄露，那么攻击者将可以访问所有内容，但是App Server 2或DB Server 2不是面向Web的所以这应该不是问题。
这种架构的安全性如何？我对加密算法和安全协议如何工作的理解是否正确？
谢谢你！
I'm building a system that need to collect some user sensitive data via secured web connection, store it securely on the server for later automated decryption and reuse. System should also allow user to view some part of the secured data (e.g., *****ze) and/or change it completely via web. System should provide reasonable level of security.
I was thinking of the following infrastructure:
App (Web) Server 1
Web server with proper TLS support
for secured web connections.Use public-key algorithm (e.g. RSA) to
encrypt entered user sensitive data
and send it to App Server 2 via
one-way outbound secured channel
(e.g. ssh-2) without storing it
anywhere on either App Server 1 or DB
Server 1.Use user-password-dependent
symmetric-key algorithm to encrypt
some part of the entered data (e.g.
last few letters/digits) and store
it on the DB Server 1 for later
retrieval by App Server 1 during
user web session.Re-use step 2 for data modification by user via web.
DB Server 1
- Store unsecured non-sensitive user
data. - Store some part of the sensitive
user data encrypted on App Server 1
(see step 3 above)
App Server 2
- Do NOT EVER send anything
TO App Server 1 or DB Server 1. - Receive encrypted user sensitive
data from App Server 1 and store it
in DB Server 2. - Retrieve encrypted
user sensitive data from DB Server 2
according to the local schedules,
decrypt it using private key
(see App Server 1, step 2) stored
locally on App Server 2 with proper key management.
DB Server 2
- Store encrypted user sensitive data (see App Server 2, step 2)
If either App (Web) Server 1 or DB Server 1 or both are compromised then attacker will not be able to get any user sensitive data (either encrypted or not). All attacker will have is access to public-key and encryption algorithms which are well known anyway. Attacker will however be able to modify web-server to get currently logged users passwords in plaintext and decrypt part of user sensitive data stored in DB Server 1 (see App Server 1, step 3) which I don't consider as a big deal. Attacker will be able to (via code modification) also intercept user sensitive data entered by users via web during potential attack. Later I consider as a higher risk, but provided that it is hard (is it?) for attacker to modify code without someone noticing I guess I shouldn't worry much about it.
If App Server 2 and private key are compromised then attacker will have access to everything, but App Server 2 or DB Server 2 are not web facing so it shouldn't be a problem.
How secure is this architecture? Is my understanding of how encryption algorithms and secured protocols work correct?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为我无法给出适当的回应，因为我不确定你们系统的目标是否明确。虽然我很感谢您获得有关设计的反馈，但如果没有目的，就有点困难。
不过，我建议您这样做：
首先有力地记录并分析您的威胁模型
您需要列出所有可能的攻击场景的固定强硬列表。本地攻击者等，您要防范谁？您还说了“通过适当的密钥管理”之类的话；但这是最难做的事情之一。因此，不要只是假设你能做对；而是要假设你能做对。充分规划您将如何做到这一点，并具体链接到它将阻止谁的攻击。
您需要建立威胁模型的原因是您需要确定您在哪些方面容易受到攻击；因为将会是这样的情况。
我还建议，虽然理论很好；但在加密领域实现也非常关键。不要仅仅假设您会正确地做事，您确实需要注意随机数的来源以及其他类似的事情。
我知道这有点模糊，但我确实认为至少提出正式且强大的威胁模型将对您非常有帮助。
I don't think I can give a proper response because I'm not sure the goal of your system is clear. While I appreciate you getting feedback on a design, it's a bit hard without a purpose.
I would suggest to you this though:
Strongly document and analyse your threat model first
You need to come up with a fixed hard-lined list of all possible attack scenarios. Local attackers, etc, who are you trying to protect against? You also say things like 'with proper key management'; yet this is one of the hardest things to do. So don't just assume you can get this right; fully plan out how you will do this, with specific linking to who it will prevent attacks by.
The reason you need to do a threat model, is that you will need to determine on what angles you will be vulnerable; because this will be the case.
I will also suggest that while the theory is good; in crypto implementation is also very critical. Do not just assume that you will do things correctly, you really need to take care as to where random numbers come from, and other such things.
I know this is a bit vague, but I do think that at least coming up with formal and strong threat model, will be very helpful for you.
到目前为止，一切都很好。您正在迈向非常安全的架构。还有其他问题需要考虑，例如防火墙、密码策略、日志记录、监控和警报，但到目前为止您描述的所有内容都非常可靠。如果数据足够敏感，请考虑对您的安全进行第三方审核。
So far so good. You are well on your way to a very secure architecture. There are other concerns, such as firewalls, password policies, logging, monitoring and alerting to consider, but everything you described so far is very solid. If the data is sensitive enough, consider a third party audit of your security.
我不建议使用任何形式的公钥从 Web 服务器到应用程序服务器进行通信。如果您控制这两个系统，只需一个常规的秘密加密系统。您知道应用程序服务器的身份，因此确保密钥安全不是问题。如果您需要更改或更新密钥，只需手动执行即可，以防止其通过连接泄漏。
我最关心的是从 DMZ 中的服务器（应该只是您的网络服务器）到网络内部的那些盒子的数据传输方向。合法域被破坏以向访问用户分发恶意软件的情况变得越来越普遍。这很糟糕，但如果恶意软件转向您的网络而不是仅向外转向您的用户，那么您的业务将彻底崩溃。
我也没有看到任何有关防止 SQL 注入或系统强化/修补以防止恶意软件分发的内容。这应该是您首先也是最重要的考虑因素。如果安全性对您来说很重要，那么您的架构应该能够灵活地进行服务器间通信的细微定制和频繁的修补。大多数网站，甚至是主要的合法企业，即使受到威胁也永远不会修复其安全漏洞。如果您希望从一开始就避免受到损害，则必须不断修复安全漏洞并进行更改以防止漏洞出现。
为了防止成为恶意软件分发者，我建议对包含任何类型客户端脚本的媒体服务方式制定严格且快速的规则。客户端脚本可以在 JavaScript、ActiveX、Flash、Acrobat、Silverlight 以及在客户端系统上执行的其他代码或插件中找到。必须存在提供该内容的策略，以便可以立即识别异常代码片段。我的建议是永远不要将客户端代码直接嵌入到浏览器中，但始终引用一些外部文件。我还建议合并志趣相投的媒体，以便为您提供更好的资产控制并节省带宽，例如提供一个大型 JavaScript 文件而不是 8 个小文件。我还建议将所有此类媒体强制放到外部内容分发系统上，该系统在其目录结构中引用您的域。这样，媒体就不会直接从您的服务器提供，如果直接由您提供，您可以快速将其识别为潜在恶意并需要进行安全审查。
I would not recommend using any form of public key to communicate from your web server to your app server. If you control both system just a regular secret system of encryption. You know the identity of your app server, so keeping the key secure is not an issue. If you ever need to change or update the secret key just do so manually to prevent it from leaking across a connection.
What I would be most careful about is direction of data transfer from your server in your DMZ, which should only be your webserver, to those boxes residing internally to your network. It is becoming increasingly common for legitimate domains to be compromised to distribute malware to visiting users. That is bad, but if the malware were to turn in ward to your network instead of only outward to your users then your business would be completely hosed.
I also did not see anything about preventing sql injection or system hardening/patching to prevent malware distribution. This should be your first and most important consideration. If security were important to you then you would be your architecture to be flexible to minor customizations of inter-server communication and frequent patching. Most websites, even major legitimate businesses, never fix their security holes even if they are compromised. You must be continually fixing security holes and changing things to prevent holes from arise if you wish to avoid being compromised in the first place.
To prevent becoming a malware distributor I would suggest making hard and fast rules upon how media is served that contains any sort of client-side scripting. Client-side scripting can be found in JavaScript, ActiveX, Flash, Acrobat, Silverlight, and other code or plugin that executes on the client system. Policies for serving that content must exist so that anomolous code fragments can be immediately identified. My recommendation is to NEVER embed client-side code directly into a browser, but always reference some external file. I would also suggest conslidating like minded media to give you better asset control and save you bandwidth, such as serving one large JavaScript file instead of 8 small ones. I would also recommend forcing all such media onto an external content distribution system that references your domain in its directory structure. That way media is not served from your servers directly and if it served from you directly you can quickly identify it as potentially malicious and necessittating a security review.