安全性在 API 设计过程中的定位

如果你熟悉敏捷开发流程，那么你可能已经了解一些术语和方法。 “左移” 是一个最近越来越受关注的敏捷概念。这个短语指的是软件开发生命周期中常见的从左到右的表示方式——当你在API项目的某个方面“左移”时，你就是在项目的最早期阶段（概念开发和设计阶段）投入资源。资源是有限的，所以在一个领域“左移”可能会让你觉得会影响API项目的其他方面。

当你构建或集成一个新的API时，你可能会听到有人建议你加强安全性。听从这个建议。安全性不是一种取舍——它是必不可少的。当你在API设计过程中尽早融入安全性时，你就打造了一个更加耐用的产品，减少了后续干预的必要性。

将安全性视为一个功能

想象一下，你正在购买一辆新车。它必须能够带你和家人去你们需要去的地方——基本功能是首要的。但虽然像加热座椅和高性能发动机这样的附加功能令人愉悦，安全性却是不可妥协的。如果你知道一家汽车制造商的安全记录远比另一家更强，你的选择就会非常明确。

将你的API视为一种产品，要求你从用户的角度来看待它。就像你在考虑汽车的基本功能之外的内容一样，你的用户也会基于性能、附加功能和安全性来评估你的API。越来越多的API用户意识到，API集成中的安全性就像汽车的安全性一样重要。

当你的开发人员和用户知道安全性和隐私从一开始就被融入到你的产品中时，他们会有更大的信心去创新和构建。在安全性上“左移”是对平稳API之旅的投资。

针对现实世界设计安全性

让我们花点时间考虑一下软件漏洞如何演变为安全事件。一般模式通常是这样的：

• 公司A的开发人员编写了一个存在漏洞的API代码。在代码审查或测试中没有人发现这个漏洞，因此它进入了生产环境。
• 黑客注意到这个漏洞，并意识到它可以用来通过基本的员工授权级别访问安全服务器。
• 黑客发现几家公司都在使用公司A的代码，但注意到公司Z的身份验证程序相对宽松，特别是在通过其在线支持时。
• 黑客将目标锁定在公司Z上，并寻找机会进行一些“社会工程”。最终，黑客成功说服一名支持代表重置一个员工账户的登录信息。
• 一旦进入身份验证屏障，黑客就利用公司A的代码在公司Z的平台上部署了漏洞，从而获取了客户数据和服务器资源。
• 可能公司A和公司Z都不会立即注意到这一漏洞，这意味着同样的攻击可以在使用公司A的API的其他平台上重现。

然而，并非每个使用公司A API的公司都同样容易受到攻击。请注意，在导致这一漏洞的过程中发生了多少次人为错误！事实上，大多数安全漏洞和数据泄露事件都是由于人为错误造成的。

一个在开发周期的“右”端留待处理安全性的API项目通常更容易受到人为错误的影响。当你的安全策略全部基于现实世界的测试和修补时，通常只有在漏洞已经进入实际环境后你才会发现它们。采用“左移”的方法可以让你有时间从头到尾设计全面的API安全性。你的安全策略需要通过以下三种方式来应对人为错误：

• 通过采用最佳实践来减少数据和网络架构的漏洞。
• 实施一个尽可能自动化的开发流程来确保安全性。
• 建立一个以安全为先的文化来加强你的最后一道防线。

我们将在下面更详细地探讨每一点。

优先缩减你的漏洞

为了实现更好的性能和可靠性，你已经在为数据和网络架构做出决策。安全性应该得到同等的关注。在概念开发和设计的早期阶段，你的安全重点应该放在架构上，以减少攻击可能造成的潜在损害。

安全工程的两个核心原则是：较小的攻击面使得攻击更易于防范，而数据隔离使得攻击可能造成的损害不那么严重。对于一个API项目来说，这可能意味着设计两个独立的API来处理不同敏感级别的数据，或者只允许通过防火墙后的某些端点访问。这些都是你希望在设计过程中早期做出的决策，以避免后期代价高昂的重构或不必要的复杂性。

除了“左移”之外，另一个你经常在安全讨论中听到的短语是“零信任”。它是在上述理念的基础上扩展的，基于“永不信任，总是验证”的原则，旨在为每个用户提供最小可能的访问权限。真正的零信任架构在组织层面难以实现，但朝这个方向迈出一步可以最大限度地降低风险。以下是你可以在API中采用的一些关键零信任原则：

• 隔离数据，确保你最脆弱的数据永远不会连接到你使用最广泛的API上。
• 对备份数据实施最严格的协议，将其隐藏在访问受限的防火墙后。
• 对内部和外部用户的访问凭据要求定期更新，即使是对于不太敏感的资源，并采取措施提高密码安全性。
• 在构建网络和数据架构时，以“需要知道”为原则：如果只有三个人需要完全访问你最敏感的数据，那么只有这三个人应该有权限。并且这种访问应定期需要多因素身份验证。

对于以API为驱动的企业来说，其中一些做法特别具有挑战性——因此，API通常成为攻击者的目标。由于API旨在简化数据共享，接近零信任需要一些额外的考虑：

• 使用令牌、加密、签名和其他方式保护所有API。仔细考虑适合你需求的认证和授权解决方案。
• 从“用户类型”的角度思考你的API用户，并允许尽可能少的用户群体访问。
• 在修补程序发布时尽快升级，以解决你使用的API中的安全漏洞。令人惊讶的是，许多攻击都发生在未部署所有可用代码修复的第三方用户身上——不要成为其中一员！
• 在你集成的API中，围绕第三方工具建立防护措施，以避免用户无意中暴露于风险中。
• 重新考虑鲁棒性原则。传统上认为API应该“宽容接受”，但这存在风险。在攻击面方面，攻击者可以查看哪些数据以及他们可以通过你的API端点发送什么数据，这都是需要考虑的。

自动化安全功能

保护API的下一步是将自动化安全工程融入开发流程中。仅靠代码审查是一个糟糕的安全管理方式——它们被证明非常低效，甚至在识别出漏洞时，也会将解决这些问题的过程推迟到开发流程的后期，浪费了大量时间。开发团队往往高估了在开发周期后期修复漏洞的能力，导致带外修补程序发布和破坏性变更。

安全工程在系统层面进行时效果最好，这提高了可靠性，减少了中断。我们上面概述的做法是一种方法；减少攻击面、隔离数据并使隐私成为默认设置，这些都将转化为更少的潜在漏洞。第二步是确保这些做法在你的API项目中始终如一地得到实施。这种方法有时被称为DevSecOps，旨在以“免提”的方式将安全集成到代码生命周期中。

DevSecOps的目标是减少人为错误的可能性。与代码审查依赖个体来识别对高度复杂系统有影响的小细节不同，DevSecOps通过威胁建模、代码分析和代码审查工具、镜像扫描等内嵌在软件开发生命周期中的流程来自动化代码合规性。当你部署这些工具时，你是在构建多层次的审查机制，这些机制应用客观标准、综合的漏洞跟踪和强大的处理能力。

说自动化可以提高API安全性，这并不是对你工程团队的否定——DevSecOps方法允许他们专注于设计和构建出色的产品，并大大降低了漏洞进入生产环境的可能性。DevSecOps方法将最需要深思熟虑的安全讨论推向产品生命周期的早期阶段，然后使用自动化工具在你构建过程中执行你选择的标准。最终结果是更少的破坏性变更和API团队的更少压力。

构建以安全为先的文化

无论你最终为API项目实施何种技术解决方案，必须记住，技术本身是不够的。没有任何技术解决方案是万无一失的，尤其是在安全形势不断变化的情况下。为了跟上变化的步伐，你的组织思维也需要改变。

构建以安全为先的文化并不是要在员工中灌输焦虑。相反，要赋予你的团队知识，吸引他们参与关于风险的透明对话，并创建渠道来揭示和跟踪漏洞。SolarWinds的首席信息安全官Tim Brown因他在2020年处理重大漏洞的方式而备受赞誉。在《每日海浪》的一次采访中，他阐述了自己的理念：“我们可以向行业展示的最大教训之一就是，通过承认所发生的事情并做出恢复，赢得尊重。你不需要隐瞒。”

构建以安全为先的文化是对长期的投资。当你就所有风险管理方面（包括技术和人为）进行公开讨论时，你的员工可以更加自信地开展工作，知道有系统可以减少风险并主动应对问题。如果你能够始终如一地及早解决安全问题，并明确采取行动以减少人为风险，你将增加API产品的稳定性，并减少组织的干扰。

随着成长而调整——一刀切的方法行不通

安全工作永远不会完成。你需要不断重新审视你实施的做法，重新设计解决方案并重新培训员工。不过请记住，安全性是你API项目的一个重要功能。就像你不断迭代产品的其他功能一样，你也需要在API安全性上不断迭代，并将其融入到整个产品生命周期的设计审查过程中。

成功的API安全计划的秘诀在于批判性思维。没有硬性规定，也没有保证的规则。行业最佳实践是很好的指导方针，但它们只是一个起点。努力深入了解影响组织安全需求的独特技术和人为因素。你需要与整个组织中的人员进行互动，从客户支持到财务再到工程。倾听他们的担忧，了解他们如何使用你的API，并观察他们如何处理已知的漏洞。然后建立适合你特定需求的安全实践。

文章来源：Where Security Fits in Your API Design Process