绕过代理访问云服务(如G Suite或Office 365 )有哪些缺陷？

Question

根据微软发布的一个TechNet文章，其建议之一是绕过代理访问Office365。基本前提是注重性能，而不是安全性。

假设绕过代理访问G Suite或Office 365，安全隐患是什么？

上下游的含义是什么？

例如，由于地址是NAT‘’ed的，它是否降低了确定访问站点的内部IP地址的能力？

Answer 1

最大的安全隐患是数据的主要出口窗口的可见性。今天我们知道，超过一半的网络攻击与恶意文件和电子邮件有关，这些文件和电子邮件通常是在网络钓鱼活动中一起发送的。代理是解决这个问题的一个很好的方法。

通过代理发送网络流量，我们可以发现恶意软件进入和保护数据退出我们的网络。结合DLP系统和恶意软件/行为分析，网络管理员可以防止许多不必要的连接发生。没有这一层，任何加密的通信对安全团队来说都是难以理解的。这并不理想。

将其带到Office 365或GSuite。这两个云系统都用于发送和接收各种格式的数据，从文件到电子邮件。作为一项业务，我不希望通过这些服务提取任何IP、PII、PHI或其他数据，除非有明确的许可。同样，如果我们删除将文件从云端读取到数据中心或端点的功能，我也不希望这些服务作为隐蔽的攻击通道流入我的网络。

如果没有其他足够的数据控制，如基于主机的DLP或EDR，绕过代理，可能会导致企业安全网络出现重大漏洞。只需要一个带有恶意宏的docx就可以从您的网络中窃取数据。更糟糕的是，如果攻击者确定您无法读取云系统的进出通信量，他们将被鼓励知道您可能根本无法检测到数据泄漏。

这并不是说，代理人总是需要的。然而，它们是防止数据误用或恶意软件渗透的重要工具。绕过代理程序，没有足够的防御能力防止数据通过云服务丢失，或者无法通过这些服务跟踪下载的恶意软件，这可能是一场噩梦。

在安全方面，可见性可以是一切。

Answer 2

这篇文章写得很差。

有许多不同类型的代理，每种类型的代理都用于不同的目的。本文中的解释只对一种特定类型的代理有意义:缓存代理。

动态web服务实际上并没有从缓存代理中获益，这几乎总是正确的。特别是对于已经通过CDN运行其静态文件的动态web服务，添加缓存代理只会减缓服务的速度，如果代理或web服务配置错误以允许私有内容的缓存共享，则可能会导致安全问题。

除了缓存代理之外，本文中的解释并不真正适用于其他类型的代理。对于几乎所有其他类型的代理，如匿名代理、数据泄漏预防代理、内容过滤代理、数据保护代理、日志代理、地理块避免代理、自动转换代理、调试代理等，本文中的论点都不适用。