身份定义巩固企业安全体系中的薄弱环节

如今的身份验证平台已经不再受限于密码及周边防护机制，转而利用基于上下文的连续智能认证实现安全保护。

　　移动与云技术的出现不仅改变了我们的传统工作方式，同时也带来了重塑IT安全保护机制的迫切需求。

　　传统IT安全立足于这样的概念，即我们将受信用户、设备以及应用程序集中在一起，并在周围建立起防火墙体系。然而，这样的解决方案在如今这个设备日趋个人化的时代下已经无法起效，因为当下应用程序可以通过任意网络实现运行，而且除了内部员工之外，我们还必须通过规模庞大但又恶意满满的互联网支持合作伙伴、承包商以及客户。

　　举例来说，很多员工都会利用自有移动设备来登录到企业资产当中、通过电子邮件访问敏感信息并将企业文件保存在云存储服务当中，这无疑给企业安全留下了诸多显而易见的漏洞。而令形势更为严峻的是，大多数员工并不愿遵循管理者制定的正式IT安全政策。

　　黑客们能够绕过传统边缘安全与防火墙机制，他们会窃取到那些强度较低的密码内容并直接通过网络夺走敏感性个人数据。除此之外，随着越来越多的企业开始采用基础设施即服务方案(即SaaS)，此类威胁在内部部署与云基础设施当中亦有逐步蔓延之势。

　　有鉴于此，企业客户必须将身份识别机制作为新型安全堆栈中的关键性组成部分，从而摆脱单纯关注防火墙及边缘防护的被动局面。

　　显性安全与隐性安全

　　当我们谈论基于身份的安全方案时，我们真正需要关注的其实是显性与隐性安全理念。大家不妨回想十年之前的日常工作方式。如果我们坐在一台PC设备面前，那么隐性安全方案会假定我们已经具通过了使用该设备的验证机制以及用于保护键盘免遭使用的物理保护手段。多年以来，正是此类隐性假设的存在—广泛出现在部署及设计当中—给恶意人士留下了破坏安全的可能性。攻击者们开始努力寻找能够通过未受保护应用突破防火墙并窃取数据的办法，在绕过广受信任的边界保护机制后，他们将得以回避坚实的城墙而大摇大摆地利用那些最为薄弱的安全环节。

　　身份定义安全则属于显性保护手段。授权与访问许可完全针对个人存在，即指向用户当前的数字化互动场景。用户在这类范式当中只有一种身份; 设备身份、网络身份以及用户所使用软件的身份被总体归纳至安全决策当中。在理想状态下，这种基于身份及权限的安全审查机制能够贯穿一切指向数据库及后端服务的使用范畴。

　　从历史角度看，验证系统设计师们通常会假定自己的产品以隔离方式进行运作。如果某位用户在登录屏幕中连续三次输入了错误的密码内容，那么结果非常明确：屏蔽该用户，忽略其登录操作。如此一来，直观风险将得到缓解，管理员也用不着再为资源被滥用而操心费力。然而，在当今这个互联系统无处不在、全球化威胁所在多有的时代下，我们根本没办法拿出一套一劳永逸的解决方案。失败的密码尝试仅仅只属于单一数据点，对于隔离而言根本没有意义。如果攻击者在24小时之内对上百款不同应用程序连续进行密码输入尝试，结果会怎样?也许他们最终还是能够顺利进入我们需要严防死守的业务体系。

　　当身份识别机制进入交互流程，而且我们有能力收集并解释使用趋势时，大家就有可能以更为具体的方式解读用户行为并追踪系统使用情况，并随时间推移掌握企业整体的安全状态。收集小型数据点当中所包含的上下文线索能够帮助我们逐步了解哪些人可能使用哪些资源，而这种趋势将慢慢建立起基于常规使用习惯的安全认知。在新时代之下，上下文异常或者遗失有可能代表着恶意活动的存在。举例来说，双因素登录失败后的密码重复输入可能意味着设备实际拥有人设定的密码内容已经被恶意攻击者获得。

　　不同身份平台之间的差异所在

　　基于身份的安全机制会将全部企业应用程序汇总为单一集中式身份平台。这种集中式平台允许企业使用各类验证政策并借助安全工具的力量，其中包括涵盖全部应用程序的多因素验证机制。这类平台可以包含多种解决方案，并以分层方式代表各类独特的业务需求—而具体方案则可通过SAML或者OAuth 2.0等标准化协议与应用程序进行交互。

　　身份平台的发展也使得整体安全评估变成可能。哪些设备及应用程序正在被使用?用户们到底是通过企业内网还是远程站点进行登录?键盘生物特征识别结果是否与该用户的标准操作模式相符?换句话来说，这套系统将以实时方式持续验证该用户的访问模式以及所处位置等上下文因素，并主动通过各种方式考查用户身份。

　　这种“上下文验证”机制背后的技术演进允许我们在密码内容之外，对用户进行全方位考查。事实上，此类系统能够立足于多因素实时检查，并根据这些上下文检查结果作出允许或者禁止其继续访问的相关决策。

　　举例来说，我们可以利用适当的密码内容作为初始验证来判断是否允许用户建立会话，并根据其随后的操作行为识别其活动是否符合常规模式，例如该用户是否尝试访问机密文件或者在短时间内下载大量数据等。在这种情况下，即使该用户拥有合法的登录资格并从理论上证明了自己的身份，验证平台仍然可以选择撤销该会话或者进一步要求该用户证明自己所宣称的身份。

　　很多消费级站点目前已经开始利用这些验证原则。举例来说，如果大家打算利用自己的信用卡完成某些不寻常的支付操作，银行方面来直接打来电话进行支付确认。但对于企业环境而言，这类验证系统还需要更多时间来发展并走向成熟，并通过最佳实践等方式引导相关行业更好地理解如何利用这些技术将应用程序与身份分析机制加以对接。就目前而言，面向企业的身份平台可以强调各类“被动”因素，例如设备的运行状态、网络接入位置以及实时物理位置等等。这些平台还可以向用户发起主动验证请求，例如进行语音识别或者向智能手机发送验证信息。不过这一切还仅仅是现代安全保障体系的初始发展阶段。

　　相较于通过上下文信息验证来解锁操作权限，传统边缘安全机制往往拥有无状态特性，即验证事件只发生在隔离环境当中。在采用边缘控制型方案的企业当中，用户识别数据通常驻留在每一套系统、而非单纯存在于中央平台之内，而且不同系统所采用的验证方式之间也存在显著差异。这些隔离池将成为恶意人士的理想作案平台，因为他们可以多次尝试用户名及密码组合且不必担心被抓个现形。而当全部应用程序的验证机制都被集中在核心身份平台中后，重复密码侦测模式会将这类可能属于入侵活动的状况快速标记出来。

　　身份定义安全机制在合规性保障方面亦拥有显著优势。这是因为应用程序访问申请会被接入到中央平台处，并在这里得到操作所需要的授权许可。这意味着报告哪位用户访问哪些内容的任务不再由应用程序本身来负担，从而令报告数据内容变得更为统一。除此之外，项目管理者也可以使用各类身份标准，例如跨域身份管理(简称SCIM)，从而保证用户名变更、角色变更或者用户终端等能够一次性完成执行，并立即在应用程序当中得到确认。

　　采用身份平台的企业能够确保每一种技术RFP当中的身份要求得以满足，从而符合供应商所提出的合规性要求。因此，身份定义安全方案已经成为客户选择产品时需要认真考量的关键性因素。

　　身份定义安全机制的实现

　　建立OAuth 2.0、SAML以及OpenID Connect等开放标准允许IT部门从身份平台层面出发对各类变更加以管理，而不再像过去那样立足于应用程序层面。除此之外，IT部门还能够借此更为轻松地将企业控制范畴之外的应用程序纳入管理体系，例如合作伙伴系统或者SaaS应用程序等。举例来说，很多基于云的应用程序都支持SAML 2.0标准以实现Web单点登录，这就使得此类SaaS应用程序能够将用户的浏览器重新指向至企业的身份平台进行验证，而不必把密码内容存储在云端。通过这种方式进行云应用程序连接，用户只需要牢记少数密码，而企业则能够对用户身份的验证方式及时间拥有更全面的把控。

　　API与本地移动应用程序安全在身份定义型安全架构当中同样扮演着举足轻重的角色。将用户名及密码缓存在移动应用程序内部以及利用此类敏感凭证访问API的作法会给攻击者留下可乘之机。身份标准的出现给应用程序及API开发人员提供了更安全也更便捷的备选方案。相较于直接提示用户输入登录凭证，开发人员完全可以将用户重新定向至身份认证平台。这类身份平台会向应用程序返回一个“访问令牌”，专门供通过验证的API使用; 而一旦该令牌被恶意人士所窃取，其也无法被用于完全顶替用户，而只能以该用户的名义执行少量功能。

　　身份定义型安全机制并不需要彻底取代现有传统身份系统，而可以作为综合性枢纽与之相对接。以Web访问管理系统与Windows域为代表的现有解决方案也能够有效实现用户身份验证，但它们往往只作用于单一域之内。这些系统可以轻松成为身份平台的组成部分，并在与联合服务器相匹配的情况下安全地将本地会话以“断言”方式供远程验证并执行。

　　构建一套身份平台的方式可谓多种多样。一部分企业倾向于将所有信息容纳在内部环境在自有数据中心当中。而有些企业则选择将整套身份平台托管在IaaS环境之内。也有一部分企业使用基于云的身份即服务(简称IDaaS)产品。IDaaS目前受到众多用户的欢迎，因为其价格水平更为合理、能够覆盖更多常见用例，而且允许IT部门参与到设计及运维工作中来。混合型架构方案也很常见，在这里企业只需要利用现有身份存储库承担强度较低的身份桥接工作，而大部分负载都在云平台当中进行处理。

　　在最后的分析结论中，我们需要强调一点：网络边界安全机制并不会消失—相反，它应该与身份定义型安全机制并行协作。事实上，边界安全解决方案完全可以成为身份定义型安全体系当中极具价值的数据点之一。我们的最终目标是让每款应用程序都成为传感器与保护政策执行点，从而帮助企业了解用户的使用方式，强化原有安全体系中的薄弱环节并彻底杜绝牵一发而动全身的陈旧保护效果。当合法与非法用户行为模式为企业所了解并熟悉时，管理层就能够制定出更为明智的安全决策，从而更加准确地对企业资产及相关人员加以保护