今年4月，在微软Office 365 SAML 2.0中发现一个漏洞，该漏洞或可使攻击者绕过该平台的身份验证，最终导致对用户账户的潜在未经授权的访问。这里的根本原因是未能正确验证SAML（安全声明标记语言）对象——用户通过身份验证过程时所提供的声明。虽然这个问题的风险很高，但该问题已较为快速地被修复（在7小时内），微软已发布更新修复这个问题。

这也许并不是非常值得注意的问题或重大事件，因为它很快被修复了，大多数企业甚至没有注意到这个问题。然而，我们仍然有必要来讨论这个Office 365 SAML漏洞：因为它可让企业从云计算客户的角度了解他们所使用的服务提供商以及他们如何对类似事件作出响应。具体来说，这样的事件为企业提供了很好的学习机会，让他们更好地了解自己的安全状态以及确定应该如何改进。企业可从多个方面分析这样的事件，并利用他们所吸取的教训来为未来可能不那么快被修复的问题做好准备。

风险决策取决于需要了解运作情况

企业应该从Office 365 SAML漏洞学习的第一个教训与企业对他们部署云服务的了解程度（例如产品的架构）有关。这可能听起来不像是火箭科学，但请记住，云模式让企业很容易或忽视这一点。云计算非常有价值，部分因为它让企业远距离获取底层维护、支持和技术基础。例如，在SaaS的情况下，从客户的角度来看，7层（应用层）以下大多数堆栈通常是黑盒子。因此，对于应用在技术水平如何运作可以被忽略。在很少的情况下，企业会在不了解架构的情况下发布旧版客户端/服务器或web应用，但他们更有可能在云计算的情况下这样做。

在本文谈论的情况中，问题出在Office 365身份验证过程生成的SAML声明。那么，大多数依靠SAML的云服务客户对这些身份联合机制如何运作的了解程度如何？通常并不是很多，因为他们并不需要这样做才能使用云服务。然而，如果企业想要应对Office 365 SMAL这样的事件，则需要足够了解该服务以做出明智的决策。

例如，企业可能需要确定，在特定问题得到解决之前，是否会影响他们对云服务的使用--这个问题是否足够严重需要采取行动或者无法使用服务是否带来影响。在较小型或不太精通技术的提供商（例如，无法迅速修复问题的提供商）的情况下，如果没有快速修复，企业可能要评估辅助对策。而当企业不了解云服务的运作方式，他们将更加难以做出决策。

这并不意味着企业应该让其员工花费全部时间去详细了解他们部署的每个服务如何运作。相反地，企业可将可靠架构信息源记录在容易访问的地方。例如，如果企业保持着其部署的云服务的清单，则应该同时记录该服务架构文档信息的链接。这可确保可迅速获取这些信息，而不需要匆忙花费数小时去检索。事实上，企业应该要求以及审查这些信息，作为服务提供商整合或审查的一部分。保存这些记录可在出现问题时节省时间；更不用提当服务提供商受到漏洞事件的影响时。

评估通知过程

从微软Office 365 SAML吸取的第二个教训与安全团队如何获知和了解这种情况有关。企业需要认识到，每个服务提供商可能有不同的方法来通知其客户有关漏洞的消息。他们可能会发送维护或安全警报电子邮件，可能会在状态页面或用户论坛发布警报，还有些提供商可能会联系内部人员或者内部联系人。企业是否知道在哪里查看？内部联系人是否合适？这些内部联系人是否知道该怎么办？如果这些问题的答案是否定的或者不确定，那说明企业还有很多工作要做。

同样重要的是，了解服务提供商其警报流程是否针对漏洞或安全事件。同时，这也需要记录在应用清单中--这可能是在部署新服务提供商的过程中已经收集的信息。如果企业还没有收集这种信息，这应该考虑提前做一些考察工作。企业无法对不知道的事情做出反应--除非企业有某种方式确保其可及时得到通知以及测试这些通知流程，否则企业可能没有完全的可视性。

对于企业而言，云服务提供商受到Office 365 SAML等漏洞的影响，这绝不是什么好消息，但这有时候可能给企业带来宝贵的学习机会。