将 API 安全纳入合规性要求：聚焦六大法规和框架
问：为什么企业会因 API 安全事件而被罚款？
答：因为监管机构逐渐认识到攻击者已在利用的漏洞：暴露或配置错误的 API 非常普遍，很容易遭到入侵，而且往往缺乏必要的安全保护。
只需一个存在漏洞的 API
每次客户、合作伙伴或供应商以数字方式进行业务互动时，后台都会有一个 API ，用于协调数据的快速交换，而这些数据通常是敏感数据。当今的攻击者知道，为了窃取数据，他们并不总是需要采用有很多步骤的复杂方案。相反，攻击者可以绕过中间环节（例如您的应用程序），直接以 API 为目标。
在一份 200 页的规范性文件中，是明确提及、巧妙暗示还是含糊地表明 保护 API 非常重要，会有什么不同吗？其实并没有。因为数据泄露就是数据泄露，无论数据如何泄漏或是在哪里泄漏。只需一个存在漏洞的 API，您的数据就会遭到侵害、被盗或公之于众。
在您坐视不理时数据就会泄露
您能否优先处理监管机构特别指出的勒索软件等威胁，而坐视不理 API 的安全性？很遗憾，不能。随着企业推出新的数字产品和数字服务，API 的数量以及随之而来风险会成倍增加。
在我们调查的企业中，有 76% 经历过 API 安全事件，而且大多数企业没有适当的控制措施或工具来阻止此类事件。同时，当企业有严重不合规的情况时，数据泄露造成的平均代价会增加 12.6%（达到 505 万美元）。
如果您能采取主动方式来找到每个 API，评估其风险，并采取保护措施来防止数据泄露，那么您就能够保护自己的数据，而这正是监管机构想要实现的结果。”
这对您的合规性计划有何影响？
如果您能采取主动方式来 找到每个 API，评估其风险，并采取保护措施来防止数据泄露，那么您就能够保护自己的数据，而这正是监管机构想要实现的结果。
在这篇博文中，我们简要介绍了六项法规和准则，阐明对保护 API 的要求，并通过举例来重点说明如何遵守这些法规。
6 个关键法规和框架
1.《支付卡行业数据安全标准》(PCI DSS) 版本 4.0
PCI DSS 已成为保护支付数据的全球标准。如果您的公司允许顾客使用主流信用卡进行支付，并以电子方式处理、存储或传输持卡人数据，那么您就必须满足合规性要求。
PCI DSS 4.0 第 6.2.3 条要求的核心是企业需要审查其自行开发的应用程序代码，以确保没有漏洞发布到生产环境中。此要求针对 API 提供了指导，以确认企业软件能够安全地使用外部组件的功能（库、框架、API 等）。
需要遵循的几种方法之一：验证 API 在使用中的正常行为和预期行为，并实施控制措施以阻止可疑攻击者滥用您的系统（例如，检查应用程序的行为来检测逻辑漏洞）。
2.《通用数据保护条例》(GDPR)
GDPR 是一项欧盟立法，旨在加强欧盟内部的个人数据保护，确保采取一致的方法。而且 GDPR 不仅适用于欧盟公司；在欧盟提供消费品或服务的所有企业同样需要遵守此条例。
GDPR 第 25 条基于最小权限原则，要求所有公司实施“技术和企业级措施，以确保默认情况下，仅处理每个具体目的所需的个人数据...”反过来，API 开发人员应实施用户身份验证和授权控制措施，以保护通过其 API 传输的敏感数据。
这是一个很典型的例子，说明如何将 API 安全性纳入企业的整体安全性和合规性计划。最低权限等概念不仅与人员相关；API 也应该只有完成其工作的必要访问权限。
3.《数字运营弹性法案》(DORA)
在欧盟范围内，DORA 要求的影响面总计涵盖了超过 2.2 万家金融机构和 IT 服务提供商，其目的是为了帮助各企业抵御网络攻击和从中恢复。
API 安全性如何融入 DORA？让我们探讨一下 DORA 第 3 条的内容，该条款要求企业使用的 ICT 解决方案和流程应能够：
尽可能地减少与数据相关的风险、未经授权的访问和技术缺陷
防止数据不可用、数据丢失以及完整性和保密性违规
确保数据传输安全
鉴于 API 的主要用途是传输数据，因此务必定期测试 API 是否存在漏洞，这包括缺乏身份验证控制措施和意外暴露于公共互联网等情况。通过应用左移方法来测试 API，您可以防止将漏洞引入生产环境。
4.《健康保险流通与责任法案》(HIPAA)
HIPAA 侧重于数据隐私和安全规则，用于保护电子健康记录和医疗保健 IT 系统中的受保护健康信息 (PHI)。任何以电子方式存储或传输 PHI 的美国医疗保健提供商、计划管理机构或票据交换所都必须遵守 HIPAA。
HIPAA 的隐私规则规定，所涵盖的实体“必须制定和实施政策和程序，根据其员工的具体角色，限制对受保护健康信息的访问和使用”。
因此，企业的 API 开发人员必须嵌入技术性保护措施（例如身份验证、唯一用户 ID 和基于角色的访问控制），以确保遵循了最低权限原则。
5.《网络和信息安全指令》(NIS2)
欧盟于 2023 年 1 月采用 NIS 指令的 2.0 版，该指令在原始版本准则的基础上进行了更新，说明如何保护 IT 基础架构和报告事件。
值得注意的是， NIS2 针对保护供应链强调了新的内容：企业现在必须评估风险并保护其 IT 供应链和第三方供应商关系。
由于 API 通常用于集成外部服务（从软件供应商到云服务提供商），因此需要确保 API 的安全，这是向监管机构表明企业在保护其客户数据和更广泛的供应链免遭攻击的关键所在。
6.联邦金融机构审查委员会 (FFIEC)
FFIEC 为联邦监管机构制定指导方针和标准，用以监管美国金融业。这包括美联储和 FDIC。该委员会的使命是保护消费者和投资者免遭欺诈、滥用和不当行为的侵害。
在 FFIEC 的指导方针中，可以清楚地看到 实施 API 保护措施如何帮助企业保护消费者 免遭欺诈和身份盗用。例如，FFIEC 建议企业为需要进行身份验证和访问控制的所有信息系统（包括 API）构建清单。
授权也很重要：FFIEC 建议实施分层安全性；例如，实施监控、日志记录和报告活动，以便识别和跟踪未经授权的 API 访问。
保护 API 还意味着保护信任关系
本博文中讨论的六项法规和准则有一个共同点：保护他人委托给您的数据。
如您所知，伴随 API 数据泄露 而来的风险不仅仅是罚款。在您的客户、员工以及所在行业的监管机构中，您的信任和声誉也会大受影响。监管机构需要确定，您综合采用了各种措施，有合适的人员、流程和工具来阻止发生此类攻击。
了解更多
您是否想更深入地了解本博文中讨论的六项法规的 API 相关要求？