PDF内部访问控制
信任但验证。
Geetanjali Sampemane，谷歌
似乎每天都有关于引人注目且备受瞩目的安全事件的新闻，无论是广泛使用的软件（如 OpenSSL 或 Bash）中长期存在的漏洞被发现，还是名人照片被盗并公开。零日漏洞和强大的国家支持的攻击者似乎无穷无尽。面对这样的威胁，尝试保护您的系统和数据还有意义吗？系统安全设计者和管理员可以做些什么？
虽然这些威胁非常真实，但它们并非大多数组织面临的最大威胁。大多数组织不会面临来自敌对政府或旨在窃取用户数据的犯罪分子的定向攻击；他们的系统更有可能因为不合时宜的软件更新或错误配置而不可用。2,3,4
人们往往对恐怖袭击等戏剧性事件反应过度，但他们低估了平凡的威胁。威胁形势不断演变，这使得情况更加糟糕；曾经合理的安全建议变得过时。例如，通常建议用户使用长而复杂的密码，但密码重用导致帐户泄露可能比暴力破解密码更具威胁，因此为不同的站点选择不同的密码比创建复杂密码、记住密码并在所有地方使用它是一个更好的策略。
在早些年，我帮助组织连接到互联网，并且作为该过程的一部分，警告管理员他们现在面临的新威胁。这些对话让我相信，对于大多数人来说，实用的系统安全仍然太难掌握。自那时以来，互联网连接已变得更加普及，但保护系统的方法并未跟上步伐。
本文赞成系统安全设计者和管理员可以使用相对平凡的工具来保护其系统和检测攻击。此处提出的原则是良好的内部访问控制：定期自动监控和验证访问配置，以及审计用户对数据的访问。在谷歌，我们将这些技术用作我们安全策略的一部分，但这些原则适用于任何有数据需要保护的组织。
问题
系统安全管理员比普通用户更有动力把安全做好，但他们的工作很艰巨。随着移动设备的日益普及，以及对随时随地访问的期望增加，只有少数高安全环境可以禁止用户将个人手机或设备带入公司环境。个人机器上的键盘记录器和恶意软件因此可能成为攻击企业系统的途径。这些设备可用于故意或意外地泄露数据。
即使当用户被限制为使用公司拥有和管理的设备进行工作时，他们仍然倾向于在不同的系统上重用密码，这可能提供一个攻击向量。从被入侵的服务器窃取的用户名/密码库可以在其他站点上重试，因此在多个站点上重用用户名/密码的用户可能会导致更大的问题。人们仍然容易受到社会工程或网络钓鱼攻击。改进的身份验证系统（例如，具有第二因素或一次性密码）有所帮助，但绝大多数系统尚未使用这些系统。
因此，假设某些用户帐户将被泄露是合理的，并且设计一个能够对此具有弹性的系统非常重要。这样的系统还具有提供一些针对恶意内部人员保护的好处。内部人员攻击有可能造成巨大损害，因为它们是由具有授权访问权限的人员以及通常了解系统和流程的人员造成的。然而，在不使系统使用起来非常繁琐或让用户感到不信任，从而不配合安全措施的情况下，设计针对内部人员攻击的保护措施可能很困难。
系统的用户通常不理解威胁模型，因此他们最终将安全措施视为他们必须跳过的障碍。更好地解释限制的基本原理可能会使用户更配合，并劝阻他们寻找绕过障碍的方法。
另一个常见问题是配置错误的安全性控制。随着系统和安全软件变得越来越复杂，管理员误解它们的机会也会增加。这可能导致基于诸如被忽视的默认密码或配置错误的防火墙规则等缺陷的成功攻击增加。
为什么要有内部访问控制？
良好的内部访问控制（也称为纵深防御）的理由很容易理解，但在实践中却出奇地难以正确实施。内部访问控制使攻击者更难入侵（不仅仅是防火墙需要被突破），并且如果系统被攻击，则可以限制损害（一个网络钓鱼密码最多只能让攻击者获得该用户有权访问的内容，而不是内部网络上的所有内容）。鉴于系统被攻击的常见方式是通过被泄露的合法用户帐户，限制单个被泄露（或恶意的）用户可以逃脱未被检测到的损害是一个有用的目标。
问题在于系统通常从小规模开始，几乎没有有价值的数据，而内部访问控制似乎是过度之举。一个好的防火墙和（少数）授权用户的无限制访问似乎绰绰有余。人们习惯了这种无限制的内部访问，并且在这种假设下开发了流程和工具，因此随着系统的增长添加内部安全屏障可能会造成干扰，并遭到用户的抵制。删除权限也可能破坏系统，通常以意想不到的方式。将安全性改造到系统中很困难。
大多数组织都有不同种类的有价值的信息需要保护——公司机密代码和文档、客户信息或用户委托给他们的数据（对于云服务提供商而言）。不同的员工需要访问此信息的不同子集，无论是为了开发和调试服务，还是为了提供客户服务，还是为了例行活动（如索引或备份）。组织如何确保人们拥有他们需要的正确级别的访问权限，并且不多不少？
实现正确的权限粒度
在设计访问方案时，管理可用性通常会被忽略。非常细粒度的权限似乎是一个好主意，因为它们可以授予完全必要的访问权限，但它们很容易变得管理工作量过大。太多或太低级别的权限也可能导致混乱，并且难以理解和推理。
另一方面，访问权限过于粗粒度的问题在于，它可能会授予过多的访问权限。授予过多访问权限的更大问题之一不是恶意使用，而是意外使用。许多系统不会根据需要启用权限，而是拥有用户被授予的所有权限；这相当于始终以超级用户身份运行，而不是以普通用户身份运行。同样，问题在于粒度——必须指定每个需要的权限变得很繁琐，因此趋势是只是让权限保持启用状态。
基于角色的访问控制系统1通过对相关权限集进行分组来帮助解决此问题，但执行不同角色的人员最终仍然拥有大量访问权限，并且没有很好的方法来使用尽可能最低权限的访问权限。
对此可以做些什么？尝试充分理解系统以在正确的位置设置访问控制，但也要认识到您有时会犯错，并且会授予超出或低于需要的访问权限。这可能是因为您想简化管理，或者因为您对权限和使用情况的心理模型是错误的。因此，建立一个系统来审查和监控权限，并根据需要更正访问配置非常有用。
监控访问配置
通常，访问请求在授予时被审查，然后就再也没有被审查过。组织中的人员在角色和项目之间调动，但旧的权限并不总是过期。删除未使用的权限似乎很少那么紧急，并且错误地猜测某些东西是否未使用可能会破坏正在运行的系统。未使用的权限只要保持未使用状态就不是危险的，但它们确实使访问配置更难理解。
在谷歌，我们使用定期监控访问配置来识别意外或不需要的权限行为。访问配置监控的原则很像代码的单元测试。与任何类型的验证一样，如果验证使用与配置不同的方法，则此验证最有用——例如，查看实时生产配置中的权限，而不仅仅是查看配置的权限。
管理员指定应维护的关于访问配置的不变性，并且自动化测试基础设施定期验证这些不变性是否成立。如果检测到任何问题，可以发出预配置的警报。
访问配置监控对于以下几个不同的目的很有用
* 捕获静态配置和实时配置之间的差异。 某些访问系统要求配置更改由管理员审查，然后“推送”以生效。有时，更改会被推送到实时系统，而没有更改静态配置，或者配置被更改但没有推送。当长时间运行的系统重新启动时，这种情况可能会导致令人不快的意外。
* 验证配置是否按预期运行。 大多数配置语言都有其怪癖，因此最好进行测试以确认它们正在执行您期望它们执行的操作。一个常见的例子是防火墙规则阻止了过多或过少的流量。
* 类似绊线式的监控，用于通知人们更改。 通常，这些是预期的更改，但这可以捕获未经授权或意外的更改。重要的是这些通知不要太嘈杂，否则收到它们的人会忽略它们。
* 捕获诸如授权人员数量突然（甚至逐渐）增加之类的漂移。 人们经常出于特定原因创建一个 ACL（访问控制列表），并且随着时间的推移，倾向于将其用于其他原因，并且大小会增长。这种监控对于识别组何时增长过大、包含过多权限以及应拆分的情况很有用。
* 验证权限分离是否成立。 例如，您可能希望防止任何一个人拥有某些权限组合（例如，能够更改代码并将其推送到生产环境而无需审查）。
审计以了解访问
审计日志是系统安全的常见组成部分。通常，所有配置更改和对敏感数据的任何访问都会生成难以颠覆的审计日志。这些通常是监管合规性的要求。
然而，许多系统止步于生成审计日志，仅在出现问题时才将其用于事后分析。在这些系统中，“审计”是麻烦的迹象。因此，访问审计应该更加例行化，而不是敌对过程。每当员工执行非例行访问（可能是为了故障排除或调试）时，访问都将被审计。在大多数情况下，这可能只涉及记录访问原因。这培养了一种问责制文化，用户期望必须证明对敏感数据的访问是合理的。
知道所有访问都经过审计使授予权限变得稍微容易一些。将访问权限限制在极少数人身上可能会使系统变得脆弱。如果更多人被授予紧急访问权限，但不必使用它，则系统会更健壮。然而，拥有过度宽泛的权限通常是一个问题。用户可能会因意外或恶意滥用其访问权限，或因此成为社会工程攻击的目标。在使用权限时拥有良好的审计日志可以在一定程度上减轻这种风险，因为不适当的访问不太可能不被检测到。
例行访问审计还有助于识别访问模式，并有助于调整访问配置。如果所有访问都被记录，则可以可靠地识别未使用的权限，并在需要时安全地修剪它们。这可以捕获人们在没有明确放弃权限的情况下调换工作或角色的情况。
审计实际使用的访问权限可以提供对人们完成工作所需的访问权限的可见性。这允许开发更好的工具，有时可以减少特定任务需要授予的访问权限量。
需要好的工具来防止访问审计变成官僚主义的噩梦。例行访问可以根据工作角色或访问历史记录来识别，并且只有不寻常的访问模式可以被标记以进行额外或手动审查。
还值得注意的是，审计访问权限不能替代良好的访问控制；审计只能在不适当的访问发生后才能识别出来，这与访问控制不同，访问控制可以阻止它。然而，正如刚刚描述的那样，审计所有访问权限可以帮助调整访问配置。必须证明访问权限是合理的，这也有助于防止授权用户进行不适当的访问。此外，在发生不幸的不适当访问事件时，审计日志可以帮助管理员评估损害。
结论
虽然备受瞩目的定向攻击将继续存在，但组织可以做很多事情来保护其系统。适当粒度的内部访问控制，结合访问日志记录和审计，可以帮助检测和防止不需要的访问。访问配置会受到“位腐烂”的影响，并且用户经常随着时间的推移积累不必要的权限；因此，定期的监控（类似于代码的单元测试）可以帮助检测不需要的情况。
向系统用户明确安全目标和威胁可能会鼓励他们的合作，而不是让他们将安全视为需要绕过的麻烦。使系统和安全配置易于管理员理解可能会减少配置错误，而精心设计的监控可以捕获任何剩余的错误。最后，使访问审计例行化可以帮助系统管理员了解访问模式并注意到不寻常的访问，无论是由于某些非例行事件还是因为用户帐户已被泄露。
参考文献
1. 计算机安全资源中心。2014年。基于角色的访问控制 (RBAC) 和基于角色的安全性。国家标准与技术研究院，计算机安全部门； http://csrc.nist.gov/groups/SNS/rbac/。
2. Hockenson, L. Facebook 解释了周四早间宕机背后的原因。Gigaom； https://gigaom.com/2014/06/19/facebook-explains-the-cause-behind-its-early-thursday-downtime/。
3. Moscaritolo, A. 2014年。Verizon 计费系统遭受重大故障。《PC Mag UK》； http://uk.pcmag.com/news/33726/verizon-billing-system-hit-by-major-outage。
4. 维基百科。2012年 RBS 集团计算机系统问题； http://en.wikipedia.org/wiki/2012_RBS_Group_computer_system_problems。
喜欢还是讨厌？请告诉我们
Geetanjali Sampemane ([email protected]) 隶属于谷歌的基础设施安全和隐私部门。她的职业生涯始于管理印度第一个互联网连接，然后花了几年时间在联合国开发计划署工作，帮助发展中国家连接互联网。她拥有伊利诺伊大学计算机科学博士学位。
© 2014 1542-7730/14/1100 $10.00
最初发表于 Queue vol. 12, no. 11—
在 数字图书馆 中评论本文
更多相关文章
郭锦楠, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用保密联邦学习的可信人工智能
安全性、隐私性、问责制、透明度和公平性原则是现代人工智能法规的基石。经典的 FL 在设计时非常强调安全性和隐私性，但以透明度和问责制为代价。CFL 通过将 FL 与 TEE 和承诺相结合，弥合了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性和推理期间的模型保护。保密计算（如保密容器和保密 GPU）的最新进展意味着现有的 FL 框架可以无缝扩展，以低开销支持 CFL。
Raluca Ada Popa - 保密计算还是密码计算？
通过 MPC/同态加密与硬件飞地进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您想到的工作负载非常重要。对于简单的求和、低次多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中使用，但对于复杂的 SQL 分析或训练大型机器学习模型等丰富的计算，目前只有硬件飞地方法在许多实际部署场景中足够实用。
Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 保密容器组
此处介绍的实验表明，Parma（驱动 Azure 容器实例上的保密容器的架构）增加的额外性能开销低于底层 TEE 增加的性能开销的 1%。重要的是，Parma 确保了容器组所有可达状态的安全不变性，该不变性以证明报告为根基。这允许外部第三方与容器安全地通信，从而实现各种需要机密访问安全数据的容器化工作流程。公司获得了在云中运行最机密的工作流程的优势，而无需在其安全要求上妥协。
Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
保密计算通过将监管系统移出 TCB，从而减小 TCB 的大小、攻击面和安全架构师必须考虑的攻击向量，从而具有提高通用计算平台安全性的巨大潜力。保密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。保密计算的早期消费者将需要对他们选择信任的平台做出自己的决定。
© 保留所有权利。