PDF测试账号：隐藏的风险
您可能会认为这些风险是可以接受的。但是，如果不是，这里有一些避免这些风险的规则。
Phil Vachon
说到永不在生产环境中进行测试这一基本原则，几乎每位软件工程师都曾在职业生涯中的某个时刻违反过这条规则。但这不仅仅是一个最佳实践。它是一个基石价值，旨在保护您的声誉、您的客户和您的理智。
在实时系统上调整配置或部署未经充分测试的修复程序可能会导致停机或数据丢失。开发人员受感染的设备如果可以访问您的生产环境，最终可能成为攻击者窃取数据或将恶意软件引入您公司技术基础设施的便捷途径。总的来说，即使在您自己的开发团队中，也必须嫉妒地守护对生产环境的访问权限。
尽管如此，有时开发人员确实需要接触最终用户体验，以重现问题或在原位测试新功能。有些错误在您的软件交付给最终用户后，会在您的生产环境中轻易显现出来，即使它们在您自己的开发和测试环境中仍然顽固地隐藏着。而且我们都经历过第三方 UAT（用户验收测试）集成与生产实例的行为不太一样的情况。
当然，那些可以帮助您在不跳入生产系统的情况下跟踪这些问题的遥测和跟踪数据，在您真正需要它们时，却不可避免地证明不存在。
随着 NIST（美国国家标准与技术研究院）最近发布了其 SSDF (安全软件开发框架)，NIST 强调了这一最佳实践的关键性。每当开发人员确实需要访问生产环境时，必须采取一切可以想象到的保护措施：监控、数据丢失控制、最小化的访问范围、多方审批、多因素身份验证——仅举几例。这并非有争议，大多数企业已经发展到实施一些控制措施来保护其生产环境，或者利用一些商业产品来提供相同的保护。
那么，您为什么要以不同的方式对待应用程序中的生产测试账号呢？一种常见的策略是创建少量测试用户账号，并根据需要与开发人员共享。但是，您很快就会失去对谁在使用哪个账号以及他们被允许做什么和测试什么的跟踪。这意味着您正在有意引入生产保护方面的差距，即使这仅仅意味着授予与您的客户可能已经拥有的相同级别的访问权限。
但有时代价可能会更高。共享凭证有可能消除您围绕产品构建的业务控制。这可能会影响您维护监管义务的能力，甚至可能使您的整个业务面临巨大的风险。
真正的风险是什么？
首先要考虑的是为您的产品创建账号所涉及的内容。如果该产品旨在被大众广泛使用，并且任何人都可以轻松创建账号，那么（也许）您的风险主要在于声誉。当然，任何可能损害或破坏您品牌信任度的东西都可能是有问题的。第三方绝不能冒充您的公司或员工。毕竟，品牌就是一切。
某些类型的企业有不同的风险需要考虑。如果您的产品附带复杂的监管要求或法律义务，例如金融科技和传统金融领域中的那些，那么管理不当的测试账号可能成为绕过必要的 KYC（了解您的客户）控制的便捷途径。生产测试账号可能很快就会找到新的用途，成为洗钱的帮凶，或成为绕过贵公司已实施的任何制裁执行控制的手段。在这种情况下，您必须仔细考虑允许员工不受限制地访问任何真实账号的所有潜在风险，并且您必须找到方法来确保在 KYC 检查后禁用敏感功能，以避免棘手的法律情况。
您不仅必须考虑您的开发人员访问生产环境中的账号可能会造成的损害，还必须考虑恶意第三方如果窃取该账号可能会造成的损害。这种分析应该告知您需要采取多么严格的方法，以及您应该进行哪些投资来保护您的环境。
谁在那里？
各种规模的公司都在努力始终了解主体（例如用户、开发人员或高管）的身份。这是通过多种机制实现的——通常是在服务中的本地账号或贵公司管理的来自企业目录的联合身份。如果做得正确，知道您的目录中存在身份可以使您确信它所代表的主体是真实的。这些身份是在某些明确定义的时间创建的。例如，您在员工入职第一天之前或客户注册服务并完成入职流程时为他们创建身份。
仅仅声明身份是不够的。您还必须使用用户名、密码和其他因素对主体进行身份验证，提供身份验证证明。如果这些都匹配，您就可以确信声称是该主体的人很可能就是他们声称的那个人。然后，授权系统将主体的身份映射到一组策略，这些策略有助于确定用户执行某些操作或一组操作的权限。这些代表用户根据职位、雇佣状态，甚至可能是一天中的时间有权执行的活动类型。
最小权限原则指出，用户应该只拥有完成其工作所需的足够权限，仅此而已。此原则的延伸是要求来自他人的额外身份证明或批准，以添加更高级别的权限——减少环境特权的实例。例如，要求更高级别的领导批准访问关键系统，以确保身处世界另一端的办公室的孤身员工不能仅仅决定访问敏感资产。
大型组织中的职位流动性意味着人们的角色可能会经常变化。随着他们的责任发生变化，他们有权访问的功能也必须随之改变。对于任何组织，无论大小，解雇员工都应意味着立即撤销所有访问权限。SaaS（软件即服务）使这个问题尤其尖锐，因为被解雇的员工可能会滥用对服务的访问权限，在您甚至不知道的情况下清除敏感材料。拥有员工访问 SaaS 产品的终止开关是必须的——无论是对于测试账号还是其他账号。
另一个需要考虑的重要因素是您的员工执行的 SoD（职责分离）。这确保了个人的权限设置旨在确保他们不能绕过欺诈保护、制裁或合规控制。当两个不同的权限来源使员工能够绕过保护公司免受重大业务风险的控制时，就会发生有毒的权限组合。
例如，银行的政策可能禁止程序员创建新账号。仅此一项控制就可以防止多种欺诈行为。但是，程序员仍然可能能够访问包含账号信息的数据库，并有能力修改其内容。测试账号可能是恶意程序员绕过欺诈控制所需的全部，只需调整后端数据库中与其关联的属性即可。
限制范围
PAM（特权访问管理）是基础设施技术的营销流行语，它提供额外的控制层，以确保管理访问难以被滥用。PAM 为在任何时间点使用管理访问权限的人员的身份提供额外的保证。
典型的 PAM 解决方案引入了额外的身份验证步骤、多方批准以及对敏感资源或数据访问请求的时间限制。PAM 解决方案可以限制使用特权访问权限可以执行的操作，将该访问权限限定于特定资源或站点，此外还允许仅对这些资源执行某些操作。大多数 PAM 解决方案还可以记录特权用户在使用敏感系统时执行的操作。通过这种方式，除了主动保护您的系统免受滥用之外，如果/当有人选择滥用其访问权限时，您还可以获得他们采取的任何操作的纸质记录。
一个简单的策略是，任何给定的测试账号只能由特定的开发人员用于特定的目的。对此测试账号的访问权限必须以相同的方式进行控制。当这种策略得到执行时，只有那些需要测试某些给定功能的开发人员才应该能够使用此账号。对这些账号的访问权限也必须是时间限制的、受限制的，并且需要其他员工的批准才能防止滥用。PAM 可以帮助满足这些要求中的每一项。
最后，测试账号应该易于撤销。只需单击一下即可禁用其中一个账号。更重要的是，如果没有人有权访问该账号，则应易于删除——或者，至少，生成一个警报，指示该账号已被遗弃。此外，通过定期重新认证来确保至少有一位开发人员仍然需要访问该账号，这进一步简化了减少废弃测试账号数量的过程。
遥测永不停歇
关于测试账号的另一个担忧与了解何时以及如何使用它们，以及使用它们做了什么有关。虽然这些账号是必要的恶，但它们绝不能免于正常的遥测收集。您基于正常客户使用情况生成的相同遥测数据——包括行为模式或该行为和访问中的异常——应该始终到位。（它们确实到位了，对吧？）
您应该始终知道哪些用户账号是测试账号，并跟踪它们。当开发人员使用测试账号时，尤其是可能绕过关键安全或业务控制的测试账号时，这应该值得一些增加风险的通知。在测试计划和其他保护性控制的上下文中，大多数测试账号使用警报可以被认为是良性的。但是，异常情况，例如在没有测试计划的情况下，可能表明正在发生一些不正当的事情。您可以通过为您的安全和风险运营团队提供尽可能多的背景信息，来帮助他们识别潜在风险。
遥测也有利于审计测试账号。了解哪些账号是测试账号以及它们上次使用的时间——以及由谁使用——可以轻松跟踪正在发生的事情，以及主动停用任何长时间未使用的测试账号。部署这样的系统相当于为您的测试账号实施另一种易于实施且主动的风险控制。
永不冒充客户
有时，让开发人员承担客户的身份似乎是通往成功的捷径。也就是说，当开发人员能够在生产环境中充当用户时，这似乎是重现某些类型错误（以及客户是如何找到最奇怪的错误的？）的最简单方法，因为开发人员可以像客户一样使用应用程序。但是，如何确保充当客户的员工不会做一些客户不希望做的事情呢？
冒充很难做好，如果实施不当，它可能会增加混乱的副手问题的风险。这是一种在以下情况下出现的错误类型：当权限更高的系统或服务（权限较低的用户可以与之交互）能够执行一些绕过其他安全控制的操作时。即使您限制冒充客户时可以执行的操作范围（例如，通过强制执行只读状态），仍然可能存在副作用，例如这些控制的工作方式中的错误，甚至只是授权检查中的普通旧式实施错误，这些错误可能会使开发人员有能力造成很大损害——即使只是意外。这根本不值得冒险。
那么，该怎么办？
创建测试账号，或少量测试账号，然后在您的团队中共享它们是很诱人的。创建账号，设置密码，将密码放在白板上（或至少放在共享密码管理器中），您的团队就可以开始工作了。或者，也许您的控制措施使您的开发人员可以轻松创建他们自己的测试账号，他们可以根据需要使用这些账号。
这两种情况都是问题。在许多人之间共享的测试账号可以被任何碰巧拥有密码的人使用。这留下了一系列管理不善或无人管理的账号，只会增加您的攻击面。测试账号可能是信息宝库，甚至可以泄露有关内部系统详细信息的信息。如果您真的需要采取这种方法，请为您的开发人员提供他们自己的测试账号，然后教育他们了解滥用这些账号的风险。此外，如果您可以定期过期——并轻松续订——这些账号，那就更好了。
请记住，共享凭证违反了最小权限原则。任何拥有该凭证的人都可能做超出其职位能力范围的更多事情。更重要的是，他们可以以一个实际上无法归因于他们身份的用户的身份来做到这一点！
最终，是否接受这些风险取决于您来决定，因为只有您才能回答这个问题。但是，如果可以避免它们，您就应该避免。
Phil Vachon (Twitter 上的 @pvachonnyc) 是彭博 CTO 办公室的基础设施主管。在这个职位上，他领导着一个由才华横溢的架构师、工程师和产品经理组成的部门，开发安全、可扩展和可靠的基础设施技术。在彭博之前的职位中，Phil 构建了安全的嵌入式生物识别系统以及硬件安全模块等。此前，他共同创立并担任一家销售高速数据包捕获和分析平台的初创公司的 CTO。在他的职业生涯早期，他广泛从事合成孔径雷达数据处理和分析以及运营商路由器数据平面工程。版权 © 2024 由所有者/作者持有。出版权已授权给 。
最初发表于 Queue 第 22 卷，第 4 期—
在 数字图书馆 中评论本文
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习实现可信赖的 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典的 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 增加的开销的百分之一。重要的是，Parma 确保了容器组在证明报告中扎根的所有可达状态上的安全不变量。这允许外部第三方与容器安全地通信，从而实现各种需要机密访问安全数据的容器化工作流程。公司获得了在云中运行最机密工作流程的优势，而无需在其安全要求上妥协。
Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算通过将监管系统从 TCB 中移除，从而减小 TCB 的大小、攻击面和安全架构师必须考虑的攻击向量，从而具有提高通用计算平台安全性的巨大潜力。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能提高对计算的信任度，尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。
© 保留所有权利。