如何保护和审计企业环境中的出站stream量？

接下来是一个冗长的背景，以下是一个问题：在企业环境中保护出站stream量的行业最佳实践（或者您会提出什么build议）？

背景

我们有一个非常典型的企业环境：在防火墙/路由器/代理之后的不可路由的IPv4地址上的Linux和Windows主机。 除此之外，这些主机运行我们的应用程序和数据库服务器，用于我们公司内部开发的核心服务。 数据库服务器已被相当广泛地locking。 他们的地址不会路由（即使与NAT / PAT）的内部networking。

另一方面，应用程序服务器以及构build和准备应用程序的服务器需要一些与外界的连接。 由于各种原因，这些主机需要访问Internet资源：

• 与公共或私人服务整合，
• 从开放源代码库中提取库，
• 下载平台更新，
• 获取专门的故障排除资源，
• 将统计数据传输给附属监控系统，
• 可能还没有确定的其他用途。

通常，这些互联网资源可以通过主机名或域名进行标识，但通常不能简单地通过目标IP地址来引用。 资源可以是资源的特定子集，例如域（graph.facebook.com）中的应用程序或主机（google.com/a/company）上的path。 我们希望能够尽可能具体地识别资源，以避免过度宽容。

• 如何将所有来自eth1的HTTPstream量路由到Squid代理？ Iptable规则？
• Fortigatepipe理覆盖 – 如何包含所有子域名？
• 缓解DDoS代理攻击
• 设置一个nginx上游服务器的代理
• 大纲鱿鱼服务器 – 用pfredirectstream量

我们的目标是维护一个安全的networking。 特别是，我们要：

• 防止或限制擅自访问系统的聪明的对手泄露数据，
• 监视和logging源自networking内部的活动。

我们关注的是源自networking内部的stream量，并终止在我们的安全环境之外。 此外，我们的目标是尽可能保持权限，根据主机类和源地址来指定源。

无论我们最终使用什么，我们都希望将授权过程作为主机供应过程的一部分机械化。 另一个要求是应用程序开发应该受到最小程度的影响。 该解决scheme应该尽可能地像一个简单的TCP / IPnetworking一样进行授权通信。

为此，我们在桌面上提出了一些build议，其中一些我们已经尝试了，其中一些我们可以评估：

DMZ防火墙

防火墙位于DMZ上，并根据允许的目标主机的白名单路由stream量（networking层）。 它定义了一个IP地址的白名单。 防火墙只是丢弃不符合相应规则的stream量。

优点

• 应用程序可以自然编写而不需要考虑networking。
• 支持HTTP / HTTPS以外的传输。

限制

• 低粒度 – IP名称或地址可以用于许多应用程序，并且几乎总是在该主机上提供多个path。
• 有时可能使用DNS将主机名parsing为IP地址列表，并机械地更新该列表，但更新不会实时发生。
• 被拒绝的stream量与故障networking无法区分。 失败可能是耗时的，需要15-60秒（或更长时间）才能解决失败。
• 由于潜在的滥用/失败，防火墙的机械化是不可取的。

HTTP代理服务器

与防火墙一样，代理服务器驻留在DMZ中，连接到内部和外部networking。 所有出站stream量必须通过代理服务器，其中包含一个由URL或部分URL授权资源的白名单。 它只允许匹配白名单上指定资源的stream量。 代理服务器在HTTP / HTTPS协议级别运行。

优点

• 强大的目的地定义。
• 使用less量的主机configuration，对于许多应用程序来说自然而然地起作
• 被拒绝的stream量通常可以快速识别。

限制（一些特别适用于我们的Stingray设备）

• 应用程序必须知道代理服务器并将stream量引导至该服务器。
• 一些图书馆需要特殊的手持（甚至错误修复）才能在这种环境下正常工作。 通常很难预先知道哪些库会受到影响。
• 规则不能根据源主机类轻松区分。
• 难以机械化。
• 仅适用于HTTP / HTTPS。
• 代理的networking环境可以不同于主机的networking环境，导致难以诊断的情况。 例如，应用程序主机可以parsing主机名，但代理服务器不能，所以代理服务器返回一个404响应，这个响应与预期资源的404响应很难区分。
• 代理无法检查encryptionstream量，因此无法比防火墙更好地过滤encryptionstream量。

先进的Perimiter安全设备

目前我们正在考虑使用Palo Alto Enterprise Perimiter等设备 。 这个设备和其他设备一样，可以过滤stream量。 该设备将对应用级传输进行深度检查。 它可以检查HTTP标题并相应地处理stream量。 它甚至可以拦截和解密安全数据包（SSL）。

优点

• 这是一个商业支持，function丰富的方法。
• 深度数据包检查提供了大量的细节来应用细粒度的权限。
• 以纯文本交换的应用程序不需要知道该设备。

限制

• 对我们来说，这是一个新的投资，也是另一个学习/configuration/pipe理的设备。
• 如果启用了SSL检查，则违反了信任链。 正确configuration高安全性的应用程序会出现问题或失败，因此必须考虑到专用环境。
• 这是一个未知的数量。 目前还不清楚是否会有能够实现我们所期望的机械化的接口。
• 新的资本支出。

问题

什么是行业最佳实践（或者您会提出什么build议）来保护企业环境中的出站stream量？ 根据上面提供的细节，我们的立场是否过于激进（或者太宽松）？ 我们即将投资于这些解决scheme之一（或者另一个），通过开发工具来机械化我们的stream程，所以任何关于最佳方法的深思熟虑的build议都将是最受赞赏的。