保护 Web 服务器数据的最佳实践答案

【问题标题】：Best practices for keeping the web server data protected保护 Web 服务器数据的最佳实践
【发布时间】：2013-09-02 18:30:36
【问题描述】：

假设我经营一家医疗机构，并且想要一个网站，我的用户/患者可以在其中查找他们的私人记录。对付最常见攻击的最佳解决方案是什么？

即使我使用在某处购买的私人服务器并依赖其监控服务，也很有可能有人会发现安全漏洞并窃取我的数据。我的业务结束。

此类架构的最佳做法是什么？

【问题讨论】：

这个过于宽泛了。没有人可以在回答中向您解释所有网络安全。有多层进入安全网站/数据库/等。
我想知道为什么它还没有关闭并且在“太宽泛”的标志中幸存下来。

标签： security protection medical

【解决方案1】：

首先，您需要确定要尝试和防御的攻击，然后单独解决每个攻击。既然你提到了“最常见的攻击”，我们就从那里开始；这是一个常见的三层服务（client-web-datastore）的快速列表：

输入损坏（手动或fuzzed）
SQL Injection
跨站脚本攻击 (XSS)
猜测：Brute force、dictionary、rainbow tables等
现场（员工）泄密
Social engineering
Man-in-the-middle
跨站伪造攻击 (CSRF)
Replay attacks

一旦发生泄漏或破坏，这些问题会使攻击者更容易受到攻击，因此也应该加以解决：

以纯文本形式存储的数据
弱密码/密钥
弱加密或散列
没有salting
没有服务分离（例如，将数据库放置在与 Web 服务器相同的物理框上）

现在我们来看看常见的缓解措施：

1-3（输入、SQL 注入、XSS） 经常处理不良输入。因此，需要对来自客户端的所有输入进行清理，并且需要执行（以攻击为中心的）测试以确保代码正常工作。

4（猜测） 自动化工具将用于尝试猜测用户的密码，或者如果他们已经拥有数据，他们将尝试强制使用密钥或哈希。缓解措施涉及为加密或散列选择正确的算法。增加密钥的位大小。对密码/密钥复杂性执行策略。使用盐。限制每秒的尝试次数。等等

5（泄漏）如果数据在现场加密，而管理员/员工/管理员没有解密数据的密钥，那么泄漏信息的价值是有限的（尤其是如果# 4正确处理）。您还可以限制访问数据的人员和方式（美国国家安全局刚刚在这里学到了宝贵的一课，并且正在制定政策以确保需要两个人在场才能访问私人数据）。正确记录和记录访问尝试也很重要。

6（社会工程） 攻击者将尝试致电您的支持台、冒充客户，并请求访问特权信息或让支持台更改信息（密码、个人信息等） .他们通常会将多个支持电话链接在一起，直到获得控制帐户所需的所有信息。支持人员需要接受培训并限制他们将提供哪些信息，以及他们可以编辑哪些数据。

7 (Man-in-the-middle) 这是攻击者试图将自己注入通信流的地方，最常见的是通过使用在客户端计算机上运行的 rootkit 或虚假访问点（例如wifi）。基于线路/协议的加密（如 SSL）显然是第一级保护。但是变体（例如浏览器中的人）不会得到缓解，因为它们会在 SSL 数据包被解密后看到数据。一般来说，客户端是不可信的，因为平台本身是不安全的。鼓励用户使用专用/隔离机器是一种很好的做法。限制密钥和解密数据存储在内存或其他可访问位置的时间。

8-9（CSRF 和重放） 与中间人类似，这些攻击将尝试复制（例如捕获）用户的凭据和/或事务并重用它们。针对客户端来源的身份验证、限制凭据有效时的窗口、要求验证交易（通过电子邮件、电话、SMS 等单独的渠道）都有助于减少这些攻击。

正确的加密/散列/加盐可能是公司搞砸的第一件事。假设你所有的其他防守都失败了（就像你说的，他们可能会失败），这是你最后的希望。在这里投资并确保正确完成。确保使用不同的密钥（不是一个主密钥）对各个用户记录进行编码。让客户端进行加密/解密可以解决很多安全问题，因为服务器永远不知道密钥（所以没有人可以窃取它们）。另一方面，如果客户端丢失了密钥，那么他们也会丢失他们的数据。因此，必须在此处进行权衡。

投资于测试/攻击您的解决方案。实现网站/数据库的工程师通常没有能力考虑所有可能的攻击场景。

【讨论】：

重申关于正确加密/散列/加盐的最后一点：很容易错误地执行这些操作。仅仅因为你“使用 AES”并不意味着你的数据被很好地加密了。安全性差的数据看起来与安全性良好的数据完全一样。如果安全对您的成功至关重要，那么值得雇用或签约具有技术安全经验的人员。 josh 的其他优秀点也需要技术专长来评估和测试。大多数开发人员（即使是优秀的开发人员）都没有这方面的专业知识。
我还应该补充一点，从密钥大小的角度来看，我不想使用小于 2048 位的任何东西。
密钥大小建议很大程度上取决于所使用的算法。 AES 没有 2048 位密钥，因此该建议将转化为“不要使用 AES”，这将是一个糟糕的建议。我假设您的意思是“为了在带有 RSA 的 SSL 中使用，我不想使用小于 2048 位的任何东西”。这对于寿命短于一两年的数据来说是合理的。然而，使用椭圆曲线 SSL，224 位将具有同等强度。 “2048”不是一个通用的数字，很多蛇油厂商卖的垃圾加密“1Mb key size”就好像没问题一样。
@RobNapier，没错，我应该指定算法。选择正确的加密算法比密钥大小更重要，但密钥大小将让您领先于破解技术的进步 (schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html)

【解决方案2】：

您的问题是这种架构的最佳实践是什么？

我喜欢这篇来自 Microsoft Security Best Practices to Protect Internet Facing Web Servers 的文章，它有 11 次修订。尽管其中一些是特定于 Microsoft 平台的，但您可以将许多概念应用于独立于平台的解决方案。

根据请求识别网络流：如果您知道服务器应该接收和发送的常规网络流，那么您可以允许并检查（内容/请求检查）它们，而其他流量/flow 默认会被拒绝（被防火墙）。这是一种网络隔离措施，可降低恶意软件传播（或成功入侵生产网络的风险）
确保您的 DMZ 无法使用类似“source to any”或“source to many”的规则（要仔细检查防火墙/路由器规则）直接访问您的 LAN。
确保无法绕过安全过滤层直接请求您的 Web 服务器。 您的网络服务器应该至少有一个 3 层过滤器：
1. 接受的协议和来源：防火墙（和路由器）。
2. 动态网络流量检查：NIPS（网络入侵保护系统）将检测/阻止恶意网络请求。您可能希望查看 MAPP 以找到 Microsoft 合作伙伴（www.microsoft.com/security/mapp/ 此链接在 TechNet Wiki 外部。它将在新窗口中打开。）。另请注意，NIDS 仅旨在检测而非阻止恶意流量（与 NIPS 相反），但另一方面，它们不会对业务流造成任何拒绝服务风险。
3. 面向应用程序的安全性：WAF（Web 应用程序防火墙），就在 Web 应用程序/站点旁边，可以加强对请求的控制，并收紧过滤器以匹配 Web 应用程序的特殊性。 ModSecurity for IIS7（请参阅：http://www.modsecurity.org/ 此链接在 TechNet Wiki 外部。它将在新窗口中打开。）是可用于 HTTP(S) 事务的稳健审计日志记录和虚拟修补的工具示例已识别的漏洞。与捆绑的 OWASP ModSecurity 核心规则集 (CRS) 一起，它提供了针对应用层攻击和信息泄露的基本保护。
确保客户端不能直接向您的服务器发送请求（从 TCP 的角度来看），否则可能会促进攻击。因此，通过部署 反向代理作为 Web 服务器的前端，确保网络隔离，DMZ 思想。这将允许更轻松地管理可以合法发送到服务器的网络流（包括负载平衡等其他需求）。 Forefront UAG 可以是此类解决方案的示例，也可以是 MAPP 程序中的任何其他示例。请注意，某些反向代理可能会提供高级安全功能。
遵循 ASP.Net 代码的安全最佳做法，以防止代码注入：http://msdn.microsoft.com/en-us/magazine/hh580736.aspx 此链接在 TechNet Wiki 外部。它将在新窗口中打开。和 SQL 注入：http://msdn.microsoft.com/en-us/library/ms161953(SQL.105).aspx 此链接在 TechNet Wiki 外部。它将在新窗口中打开。 .从更全球化的角度来看，请参阅 SDL：http://msdn.microsoft.com/en-us/security/aa570401.aspx 此链接是 TechNet Wiki 的外部链接。它将在新窗口中打开。 .定期审核托管代码。
尽可能强化加密网络通信，同时考虑到您正在运行的 Windows 系统上可用的 SSL/TLS 实现：http://blogs.msdn.com/b/benjaminperkins/archive/2011/10/07/secure-channel-compatibility-support-with-ssl-and-tls.aspx 此链接在 TechNet Wiki 外部。它将在新窗口中打开。 .默认情况下，我们的建议是 TLS 1.1/1.2。请记住，这必须在客户端和服务器端都启用。
确保 DMZ 内的机器未加入常规生产域。 AD 隔离在林层，因此强烈建议不要在 DMZ 中放置生产 AD。请使用另一个林，或部署 AD 轻型目录服务。
实施应用程序的白名单/黑名单，例如通过 AppLocker：http://technet.microsoft.com/en-us/library/ee791890(v=ws.10).aspx 此链接在 TechNet Wiki 外部。它将在新窗口中打开。
确保您拥有所有相关（和必需的？）可追溯链strong>：这意味着防火墙、反向代理和 Web 服务器日志之间可能存在关联。请注意不要只启用“错误”日志记录，例如在 IIS 日志中。最后，请考虑归档日志。
定期创建备份网络服务器数据。
创建系统映像，以整数状态，定期（至少在部署时）。这可能有助于在发生安全事件时尽快恢复生产模式并进行调查。
审核您的设备：定期检查防火墙规则、NIPS 规则、WAF 规则、反向代理设置。
遵循应用层产品、数据库层产品和 Web 服务器层的安全最佳做法。

参考：http://social.technet.microsoft.com/wiki/contents/articles/13974.security-best-practices-to-protect-internet-facing-web-servers.aspx

【讨论】：

【解决方案3】：

虽然 josh poley 和 Bala Subramanyam 是很好的答案，但我要补充一点，如果您的业务的核心价值是安全，您应该：

聘请最优秀的安全黑客，给他们丰厚的报酬，让他们为为您的公司工作而自豪
聘请最优秀的程序员，给他们丰厚的报酬，让他们为为您的公司工作而自豪
将您的服务器托管到您自己的建筑物中，可能位于不同的经度

黑客和开发人员将是您的主要资产，他们应该知道这一点。事实上，我们可以在此处列出最常见的安全做法，但应用我们的建议不会让您的系统真正安全，只是很容易被黑客入侵。

当安全很重要时，优秀的才能、热情和能力是您唯一的保护。

【讨论】：

【解决方案4】：

这就是我的想法：

所有记录都存储在我的家用计算机中（离线），使用我的个人密钥加密。在这台计算机中，有患者记录以及每个用户的私钥和公钥。这台计算机将新数据作为加密器上传到网络服务器。

网络服务器只包含加密数据。

我将公钥提供给我的用户。无论是使用从其他地方发送的电子邮件，还是使用普通邮件。

Webserver 对每个请求的数据进行解密。因为用户密码是它的公钥，所以只有在会话处于活动状态时才能在服务器上进行解密。

因为存在不对称密钥，我什至可以在网络服务器上插入新的加密数据（用户输入），然后将其提取到我的离线计算机。

缺点：请求新密码需要离线计算机上传重新加密的数据，并以某种方式发送新密码。

优势：降低网络服务器安全问题的相关性。

这是最好的解决方案吗？

【讨论】：

家用电脑如何离线，但仍将新数据上传到网络服务器？
离线即不接受连接，不提供任何容易受到攻击的服务。仅提交通过反向通道加密的新数据。
这是行不通的，因为加密的数据无法使用公钥解密。如果是这样，加密将毫无意义。也许您的意思是您向用户提供他们的私钥？在这种情况下，您应该让用户在自己的电脑上而不是服务器上解密数据。
如果计算机可以访问互联网，则它是在线的。其他程序中的漏洞可能会带来安全风险。

【解决方案5】：

好的，我将尝试在您已经提出的建议的基础上进行一些补充。首先，您可能想研究mega 网站背后的技术；它使用的大概正是你感兴趣的东西。然而，基于 JS 的动态加密仍然存在一些弱点。话虽这么说，用 js 和 html 对记录进行动态解密并不容易，但并非不可能。因此，是的，我会说你的想法通常是正确的。

尽管您必须考虑所有常见的攻击技术和防御措施（网站攻击、服务器攻击等），但这个主题过于广泛，无法在一个答案中完全涵盖。不用说，其他答案已经很好地涵盖了这些内容。

至于“架构”，如果您真的很偏执，您也可以将数据库放在单独的服务器上，该服务器在一个不起眼的端口上运行数据库，并且只允许来自网络服务器的传入连接。

【讨论】：