Active Directory 暴露的攻击面谁将赢得这场战斗？

Active Directory (AD) 是仍在生产环境中使用的最古老的软件之一，如今在大多数组织中都可以找到。尽管事实上其历史安全漏洞从未得到修正。例如，由于除了检查密码和用户名匹配之外无法应用任何安全措施，AD（及其管理的资源）很容易暴露于使用受损凭证的危险之中。此外，这种暴露并不局限于本地环境。在 AD 和云身份提供商之间同步密码的常见做法意味着任何 AD 漏洞也对 SaaS 环境构成潜在风险。

探讨 AD 固有的安全弱点并检查其范围和潜在影响。然后，我们将了解 Silverfort 的统一身份保护平台如何从根本上解决这些弱点，并为使用 AD 的组织提供所需的弹性，以阻止身份威胁并减轻用户帐户受损的风险。

什么云？为什么 AD 将继续成为混合环境的一部分#

虽然云计算引发了 IT 的结构性转变，但它并没有完全取代本地环境，而是与之并存。大多数组织选择的务实路线是维护混合环境，其中用户对 SaaS 和 Web 资源的访问由专门的身份提供商管理，而 AD 仍然管理本地资源。

从运营的角度来看，这种策略是合理的，因为有多种资源可以迁移到云端或与 SaaS 应用程序交换。然而，重要的是要意识到这种方法意味着 AD 长期被忽视的安全弱点仍然存在。

AD 的致命弱点：无法检测和防止使用受损凭据的恶意访问尝试#

当用户发起访问请求时，AD 只知道如何做一件事：检查用户名和密码是否匹配。如果他们不这样做，AD 会阻止访问；如果他们这样做，则授予访问权限。但是，如果用户名和密码匹配但被获得它们的对手使用，AD 可以做什么？不幸的是，答案是绝对没有。

听起来很奇怪，但从 AD 的角度来看，提供正确用户名和密码的合法用户与做同样事情的恶意对手之间没有区别。两者都被授予相同的访问权限。

那么为什么传统的MFA不能解决这个问题呢？#

此时，您可能想知道为什么不能像 SaaS 应用程序那样简单地将 MFA 添加到 AD 身份验证过程中。不幸的是，答案并不是那么简单。AD 及其身份验证协议（NTLM 和 Kerberos）是在二十多年前构建和设计的——远早于 MFA 甚至存在。因此，与 SaaS 应用程序使用的现代身份验证协议不同，它们根本不支持 MFA。Microsoft 也没有任何计划开放这些协议并重写它们以使其具有此功能。

这意味着我们回到原点，攻击者在 AD 环境中使用受损凭据可以从字面上连接到他们喜欢的任何工作站、服务器或应用程序，没有任何安全措施阻止他们的方式。

AD 漏洞 AD 为对手获取您的云资源铺平了道路#

许多安全利益相关者经常忘记的是，本地和云环境是交织在一起的。事实上，许多寻求访问 SaaS 应用程序的攻击者选择通过破坏本地环境来访问它们，而不是直接通过浏览器攻击它们。这种攻击的常见模式是使用社会工程获得对员工端点的控制，一旦到达那里，就努力破解用户名和密码，以利用它们恶意访问 SaaS 应用程序。或者，如果有联合服务器，攻击者可以像对待任何其他本地资源一样简单地破坏它，并从那里获得 SaaS 访问权限。

不管怎样，重要的是要认识到，当我们谈论 AD 的安全漏洞时，这并不意味着只有 AD 管理的环境处于危险之中，而是整个混合环境及其所有用户和资源都处于危险之中。

Silverfort 统一身份保护：通过实时保护克服 AD 的差距#

Silverfort 率先推出了第一个专为防止身份威胁而构建的平台 - 实时 - 利用受损的凭证访问目标资源。Silverfort 对任何用户对任何资源（本地和云端）发出的每个传入身份验证和访问请求提供持续监控、风险分析和主动策略实施。

通过这种方式，Silverfort 可以通过与 AD 的原生身份验证流程集成，从根本上解决 AD 的安全漏洞，从而为 AD 决定用户在访问资源时是否可以完全信任。

Silverfort 的 AD 保护：原生集成到 AD 身份验证流程中的威胁保护层#

它是这样工作的：

用户想要访问资源，向AD发起访问请求。
AD 不会根据密码匹配自行决定是授予还是拒绝访问权限，而是将此访问请求转发给 Silverfort。
Silverfort 接收访问请求并使用多层 AI 引擎对其进行分析，同时还根据预配置的访问策略评估请求。
如果分析显示可疑的妥协，Silverfort 会连接到 MFA 服务以质询用户以验证其身份。
MFA 服务向用户发送消息并将他们的响应传递回 Silverfort。
根据 MFA 响应，Silverfort 指示 AD 是阻止还是允许访问。
AD 根据 Silverfort 的指令阻止或允许访问。

无代理和无代理技术，与所有协议和访问方法无关#

这种从 AD 实时接收每次访问尝试的独特能力使 Silverfort 能够将缺失的风险分析和 MFA 功能添加到 AD 身份验证流程中。此外，由于 Silverfort 位于 AD 之后并获得其 100% 的身份验证请求，因此无需在单个资源上安装 MFA 代理或在它们前面放置代理。这也意味着使用什么协议或它是否支持 MFA 都没有区别。只要执行了对 AD 的身份验证，AD 就会将其转发给 Silverfort，保护就会到位。

>>>等级保护<<<