这个架构有多安全?

时间:2009-09-21 01:33:23

标签: security encryption rsa public-key

我正在建立一个系统,需要通过安全的网络连接收集一些用户敏感数据,将其安全地存储在服务器上,以便以后自动解密和重用。系统还应允许用户查看安全数据的某些部分(例如*****ze)和/或通过网络完全更改它。系统应提供合理的安全级别。

我在考虑以下基础设施:

App(Web)Server 1

  1. 具有适当TLS支持的Web服务器 用于安全的网络连接。

  2. 使用公钥算法(例如RSA) 加密输入的用户敏感数据 并通过发送到 App Server 2 单向出站安​​全通道 (例如ssh-2)没有存储它 App Server 1 DB上的任何位置 服务器1

  3. 使用依赖于用户密码的 对称密钥算法加密 输入数据的某些部分(例如 最后几个字母/数字)和商店 它将在 DB Server 1 上供以后使用 在 App Server 1 期间检索 用户网络会话。

  4. 重复使用步骤2,由用户通过网络进行数据修改。

  5. 数据库服务器1

    1. 存储不安全的非敏感用户 数据。
    2. 存储部分敏感信息 在 App Server 1 上加密的用户数据 (见上文第3步)
    3. App Server 2

      1. EVER 发送任何内容 TO App Server 1 DB Server 1
      2. 接收加密的用户敏感信息 来自 App Server 1 的数据并存储它 在 DB Server 2
      3. 检索已加密 来自 DB Server 2 的用户敏感数据 根据当地时间表, 使用私钥解密它 (请参阅 App Server 1 ,步骤2)存储 本地在 App Server 2 上进行正确的密钥管理。
      4. 数据库服务器2

        1. 存储加密的用户敏感数据(请参阅 App Server 2 ,第2步)
        2. 如果 App(Web)服务器1 数据库服务器1 或两者都受到攻击,则攻击者将无法获取任何用户敏感数据(加密或不加密) )。所有攻击者都可以访问众所周知的公钥和加密算法。但是,攻击者可以修改网络服务器,以明文形式获取当前登录的用户密码,并解密部分存储在数据库服务器1中的用户敏感数据(参见 App Server 1 ,步骤3)认为这是一个大问题。攻击者将能够(通过代码修改)拦截用户在潜在攻击期间通过网络输入的用户敏感数据。后来我认为风险更高,但是如果攻击者修改代码很难(是吗?)而没有人注意到我猜我不应该担心它。

          如果 App Server 2 和私钥被泄露,则攻击者可以访问所有内容,但 App Server 2 DB Server 2 是不面向网络所以它应该不是问题。

          这种架构有多安全?我对加密算法和安全协议的工作原理有何了解?

          谢谢!

3 个答案:

答案 0 :(得分:3)

我认为我不能给出正确的答案,因为我不确定你的系统目标是否清晰。虽然我很感谢你获得有关设计的反馈,但如果没有目的,这有点难。

我建议你这样做:

首先强烈记录和分析您的威胁模型

您需要提供所有可能的攻击方案的固定硬盘列表。当地的攻击者等,你想要防范谁?你也会说'有正确的密钥管理'之类的东西;但这是最难做的事情之一。所以不要只是假设你可以做到这一点;完全规划你将如何做到这一点,具体链接到谁将防止攻击。

您需要制作威胁模型的原因是,您需要确定您将在哪些角度受到攻击;因为情况就是这样。

我也会建议理论是好的;在crypto 实现中也非常关键。不要只是假设你会做正确的事情,你真的需要注意随机数来自哪里,以及其他类似的东西。

我知道这有点模糊,但我认为至少会提出正式和强大的威胁模型,对你很有帮助。

答案 1 :(得分:1)

到目前为止一切顺利。您正在前往一个非常安全的架构。还有其他问题,例如防火墙,密码策略,日志记录,监控和警报要考虑,但到目前为止您描述的所有内容都非常可靠。如果数据足够敏感,请考虑对您的安全性进行第三方审核。

答案 2 :(得分:1)

我不建议使用任何形式的公钥从您的网络服务器与您的应用服务器进行通信。如果你控制两个系统只是一个常规的加密秘密系统。您知道应用服务器的身份,因此保持密钥安全不是问题。如果您需要更改或更新密钥,请手动执行此操作以防止密钥泄漏到连接中。

我最关心的是从DMZ中的服务器(应该只是您的网络服务器)到驻留在网络内部的那些盒子的数据传输方向。将合法域泄露以向访问用户分发恶意软件变得越来越普遍。这很糟糕,但是如果恶意软件转向您的网络,而不是只向外转移到您的用户,那么您的业务将被彻底管理。

我也没有看到任何关于阻止SQL注入或系统强化/修补以防止恶意软件分发的内容。这应该是您的第一个也是最重要的考虑因素。如果安全性对您很重要,那么您的架构可以灵活地进行服务器间通信和频繁修补的微小定制。大多数网站,甚至是主要的合法企业,即使受到损害也从未修复过安全漏洞。如果您希望避免在一开始就受到损害,您必须不断修复安全漏洞并更换物品以防止漏洞出现。

为防止成为恶意软件分发者,我建议对包含任何类型的客户端脚本的媒体服务进行严格而快速的规则。客户端脚本可以在JavaScript,ActiveX,Flash,Acrobat,Silverlight以及在客户端系统上执行的其他代码或插件中找到。必须存在用于提供该内容的策略,以便可以立即识别出异常的代码片段。我的建议是从不将客户端代码直接嵌入到浏览器中,但始终引用一些外部文件。我还建议像志同道合的媒体一样,为您提供更好的资产控制并节省带宽,例如提供一个大型JavaScript文件而不是8个小文件。我还建议将所有此类媒体强制到外部内容分发系统,该系统在其目录结构中引用您的域。这样就不会直接从您的服务器提供媒体,如果直接向您提供服务,您可以快速将其识别为潜在的恶意软件,并且需要进行安全审核。