4、使用基础设施而不是内置开发安全功能
不要直接将API安全策略编码到想要保护的API中。这种做法有以下缺点：
（1）违反职责分离；
（2）代码变得更加复杂、脆弱；
（3）增加额外的维护负担；
（4）不可能涵盖完整的API安全策略中要求的所有方面；
（5）不可重用；
（6）对安全团队不可见。
此外，开发人员可能会提出一种白名单的方法。然而，这些白名单通常范围过于宽泛，它们的使用或管理对安全团队一般不可见。
Gartner在《2018年安全与风险管理规划指南》（2018 Planning Guide for Security and Risk Management）中指出，API网关、WAF和CDN等外部化功能非常适合于实现某些难以实现和维护、效率较低或在应用程序代码中缺乏灵活性的安全功能。目前，API安全领域中出现了许多创新型的初创公司，包括42Crunch、Elastic Beam和Secful等。
因为移动客户端经常被用来调用API，所以攻击者可以通过对移动应用程序进行反向工程来发现其调用API的方式，从而来定位任何调用API。如果API密钥被“嵌入”到应用程序中，这种情况下很有可能会导致API泄漏。实际上，在没有其他形式的身份验证或客户端IP限制的情况下，API密钥不应该单独用于客户端身份验证。
除了API客户端的身份验证之外，许多企业还将客户端绑定到特定的应用程序中或设备上。这种策略可以通过使用应用程序认证解决方案(例如来自Critical Blue的Approov或CA Mobile API网关)，或者使用应用程序屏蔽解决方案来实现。访问管理的工具和服务使用设备内容来作出访问决定的能力日益提高，通过使用访问设备收集的客户端IP地址、地理位置或其他设备内容，从而提供访问管理策略。
5、真正开放的API同样也需要考虑安全性
政府越来越多地使用API来传递数据或与服务提供商集成。这些API通常采用“开放数据”API的形式，来替代传统的以文件形式提供数据集的方式，同时提供实时的数据和信息。人们可能以为这些API的安全性不重要。但是，使用流量限制是非常重要的，这样客户端通过开放API批量下载数据时，不会对其他客户端造成不利影响，不会增加云计算的资源消耗。此外，客户可能被引导通过开发人员门户注册API，然后使用API密钥进行身份验证；请注意，不能仅仅依赖API密钥来保障API安全性，因为攻击者可以通过对客户端应用程序进行反向工程以获取API密钥。
6、采用持续优化的API安全方法
API安全性不是一次性的项目，需要持续优化，具体步骤参照下图4。
第一步 发现
（1）确保安全、质量和开发团队能够访问API报告(例如，通过API管理软件)，从而确保跨团队的可见性。确定应该如何更新组织的变更管理流程，以便在实现新API或修改现有API时通知相关利益者。
（2）持续清点组织提供的API或正在开发的API。组织从第三方获得的API同样应该包括在这个API目录中，这个API目录通常由完整的API生命周期管理解决方案来提供。CDN产品可以用来动态地发现API，对web流量(可能包括API流量)具有可见性。
（3）与软件开发生命周期的集成，特别是应用程序开发生命周期管理，可以预先考虑新API的计划开发工作，或对现有API的更改，而不是在以后才清点上库。这对于DevOps和DevSecOps非常重要，这样在开发API时就可以应用适当的API安全策略。
第二步 监控
（1）测试供应商对API使用中正常和异常行为的识别能力，特别是针对云交付的API。
（2）监控组织使用的外部第三方API。这可以通过一些API管理供应商提供的“反向网关”功能来执行，以将策略应用于API使用(而不仅仅是API交付)。
（3）根据监控API可以访问的数据和应用程序(是否对业务至关重要)及其客户端使用情况，对API进行分类。
第三步 保护
（1）将安全策略应用于API(例如，使用API网关)，但要避免每个API都有特殊的安全策略。相反，可以根据API的分类来实施可重用的策略。从策略本身提取任何特定的API特征(例如URL路径)。
（2）在整个API生命周期中应用API安全性，包括新版本的应用程序安全性测试(AST)。
（3）良好的API安全性还要求在整个应用程序生命周期中进行更改控制。例如，应该只允许某些开发人员对API进行更改，并且在开发过程中，只要API发生更改，就会执行应用程序安全性测试。对API进行无记录的更改也会对整个系统的可用性和安全性产生严重影响(例如，如果API更改，一些保护可能会按照预期停止工作)。
7、使用分布式实施模型来保护整个体系结构中的API，而不单局限在某一点
根据惯例，API安全主要关注API客户端和API本身之间的“南-北”通信。但是，微服务的使用，对微服务之间的“东-西”方向上的安全性提出了要求，即使使用其他API和服务的API，这些API通常不会通端的API网关相互调用。这也从而导致了“微网关”的发展，它可以执行更接近微服务本身的策略。
在图5中，我们看到，不仅必须对端的API网关应用实施安全性，还必须对微服务架构本身内部的流量应用安全性。还要注意，即使微服务可以通过API调用，它们也可能是事件驱动的。
（未完待续）
未经同意，本文禁止转载或摘编。
