如何构建和设计保证API安全的通用安全框架，保护其RESTAPI，保证良好的用户体验。本文为您介绍四种API安全保护方法。管理API安全API安全涉及各种端到端的数据保护，依次包括：客户端的请求通过网络到达服务器/后端，服务器/后端发送相应的响应，响应跨越网络。最后到达客户端，这一系列的过程。因此，API安全大致可以分为以下四种不同的类别，我们将一一详细讨论：(1)数据在传输过程中的安全保护以及客户端与API网关API网关与后端服务之间的动态数据保护（2）访问控制和防御拒绝服务（DoS）攻击（3）身份验证和授权：使用OAuth2.0或OpenIDConnect可靠地识别终端用户信息（4）数据保密和个人屏蔽身份信息（PersonallyIdentifiableInformation，PII）)下图描述了以上类别，以及各种端到端的数据保护方法：1.传输中的数据安全对于所有公开的和未受保护的API，我们必须使用TLS。如今，随着硬件的进步，TLS的实现开销几乎可以忽略不计，而且随着延迟的逐渐降低，越来越多的终端用户出于安全考虑会选择TLS。总的来说，TLS具有以下主要特点：TLS应该在北向和南向端点都实现。确保使用最新版本的TLS并支持客户端、API网关和目标后端。证书密钥和信任凭据的存储应该受到高度保护和加密。只有授权用户才能访问证书密钥和信任凭据。2.访问控制和防御拒绝服务（DoS）攻击（1）网络级防御：如果API网关托管在云端，需要使用云服务商提供的DDoS防御机制，例如:byApigee(Google)ApigeeEdge管理的云平台，GCP（谷歌云平台）和AWS（亚马逊Web），都提供网络级的DDoS防御。(2)内容分发网络：Akamai、Neustar和Rackspace等CDN可用于缓解对API的DDoS攻击。(3)“僵尸”检测：如今各大API管理平台都推出了API网关，检测API流量，识别各种恶意/不必要的请求，并产生告警/阻止恶意请求到达恶意请求。服务。例如：Apigee（谷歌）提供了一种名为“ApigeeSense”的检测服务。它是一种智能数据驱动的API安全产品，可以通过自动识别各种可疑的API客户端行为来提供额外的保护层。同时，管理员也可以在此基础上采取纠正措施，保证用户体验和后台系统的安全。(4)策略执行：我们应该通过在API客户端和客户端后端之间的API代理上执行各种策略来严格控制合法用户对API的访问。以下策略可以在一定程度上保护API免受恶意黑客攻击：API限速：通过限速，我们可以减少大量导致拒绝服务的API请求，抑制暴力攻击和服务滥用。特别是在API代理服务器上，我们可以采用如下限速机制：基于应用或个别API进行限速，保证每个API或应用只能按照固定的请求配额访问相应的服务。速度限制基于GET或POST请求。当然，具体的请求次数可以根据不同时间段的GET或POST数量来设置不同。(5)正则表达式保护：应根据预定义的正则表达式（如DELETE、UPDATE和EXECUTE）评估传入请求的URI路径、查询参数、标头、表单参数、变量、XML有效负载和JSON有效负载。任何匹配预定义表达式的请求都将被视为威胁并立即拒绝。有关如何验证正则表达式的具体信息，请参见OWASP前10名(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#OWASP_Top_10_for_2013)。(6)JSON输入验证：对于PUT/POST/DELETE等请求的负载，我们应该进行JSON验证来指定对各种JSON结构的限制（例如最大深度，最大对象数，最长字符串长度名称，以及数组中允许的最大元素数等）以最小化可能的攻击面。(7)XML输入验证：对PUT/POSTE/DELETE等请求的payload进行XML验证。具体来说，可以使用以下方法检测针对XML负载的各种攻击并根据配置限制监控针对XML的威胁：基于XML模式（.xsd）验证消息基于特定黑名单中的关键字和模式评估消息内容检测损坏或格式错误解析消息之前(8)验证请求验证输入的HTTP动词：适当限制那些允许的动词类别，并为所有其他动词返回适当的响应代码（例如“403ForbiddenError”）。校验headers：“ContentType”、“Accept”、“ContentLength”等headers应根据API支持的功能明确校验。此外，还应针对强制性标头（例如授权和某些类型的API标头）执行验证。验证栈的内容类型：验证PUT/POST/DELETE等传入请求的内容类型（例如：application/XML或application/JSON），以及内容类型的header值。对于内容类型缺失或者内容类型异常的header，直接拒绝，返回“406Unacceptable”的响应内容。验证响应类型：不要简单地将“接受”标头复制到响应内容类型标头中。如果“Accept”头没有明确包含允许的类型，则应直接拒绝该请求，并返回“406Unacceptable”响应内容。Disposeofunsupportedresources：适当限制资源，只开放可以调用的资源；对于所有其他未实现的资源，应返回相应的响应代码，例如“未知资源”。(9)访问控制：通过配置策略，只允许来自特定IP地址、域名或区域的请求。那些不符合这些条件的请求应该被网关直接拒绝。3.认证与授权通常情况下，认证与授权是同时发生的。身份验证通常用于识别最终用户。授权用于授予已识别的用户访问某些资源的权限。在API世界中，OAuth和OpenIDConnect是最常用的机制。他们通过利用现有的IAM基础设施对用户进行身份验证以换取访问令牌来保护API端点。有了OAuth和OpenIDConnect，我们就不需要每次都建立单独的系统来存储用户名和密码来匹配用户可以访问的API资源。(1)OpenID和OAuth的历史(2)OAuthOAuth通常使用不透明（OPAQUE）令牌来达到委托访问（DelegatedAccess）的目的。OAuth2.0授权框架使第三方应用程序能够获得对HTTP服务的有限访问权限。一般而言，用户不应通过公共网络传输其密码以访问第三方存储的某些受保护数据。而OAuth只是能够为用户访问自己的数据提供可信凭证的安全保护。OAuth不是认证协议，而是授权协议。由于身份验证通常发生在颁发访问令牌之前，因此很容易理解，当访问令牌被接受时，它也得到了身份验证。但是，仅拥有访问令牌并不能证明用户的身份。在OAuth中，token被设计成对客户端不透明，客户端只能从token中获取权限信息，不涉及用户名和密码。不透明令牌：在许多实现中，OAuth2.0返回OPAQUE字符串以换取称为访问令牌的用户凭证，这些凭证进一步用于访问各种API中的资源。不透明令牌不用于存储用户标识和信息，而是指向数据库中的特定数据项。例如：我们可以使用Redis来存储各种键值对（key-value）。像Cassandra这样的NoSQL数据库非常适合使用内存中的哈希表查找基于I/O的有效负载。由于用户角色是直接从数据库中读取的，我们可以通过更改后端角色将其传递并显示给用户。(3)OpenIDConnectOpenIDConnect使用ID令牌和访问令牌来实现用户身份识别和委托访问。OpenIDConnect是用户身份验证的标准。由于它直接构建在OAuth2.0之上，因此在大多数情况下，OpenIDConnect是与OAuth框架一起部署的。在交付的形式上，它还为客户端提供了一个OpenIDConnect令牌。身份令牌是一个签名的JSONWeb令牌(JWT)，它与常规OAuth访问令牌一起提供给客户端应用程序。JSONWebToken：JWT令牌实际上是一个完整的JSON对象。经过base64编码后，使用对称共享密钥或公钥/私钥对其进行签名。JWT可以包含诸如：subject、user_id、token发布时间和过期时间等信息。通过密钥签名，它确保只有具有授权访问密钥的系统才能生成令牌。不过值得注意的是，系统在对JWT进行签名时，通常不会对JWT进行加密（当然你也可以选择加密）。那么，这意味着任何有权访问令牌的人都可以读取令牌中的数据。因此，业界的最佳做法是：只在令牌中放入用户标识（如user_id），而不是个人身份信息（如电子邮件或社会安全号码）。此外，它们应该通过加密通道（例如TLS）传送。JWT限制：鉴于每天禁用用户，添加或删除角色，往往需要一段时间才能同步生效，而且由于token是存储在客户端的，即使我们禁用他们发布的JWT用户在数据库，也没有办法及时直接使token失效。JWT虽然采用了预定义的过期机制，但用户仍然需要等待过期。显然这会影响到用户的服务架构，尤其是那些电子商务应用。当然，业界也提供了一些变通办法。例如：您可以使用带有令牌或user_id的黑名单，但这需要向数据库引入新的身份验证机制。因此，推荐的做法是通过黑名单来确保每个令牌都带有JTI声明（或者在数据库中存储了JWTId）。因此，只要您要注销的令牌数量远小于应用程序中的用户数量，它就非常灵活。可以看出，对于那些具有管理员、项目所有者、服务客户经理等多个角色的企业应用，切换用户的不同角色不会在JWT上立即生效。比如管理员修改了授权用户的角色，只要他不刷新JWT，他就不会被告知变化。以下是OpenIDConnect的三个实现用例：出站方向的Web单点登录（SSO）：为企业用户提供对SaaS应用和合作伙伴应用的访问控制，但不泄露企业用户名和密码。入方向Web单点登录：允许社交账号/第三方登录，但不需要存储外部用户和密码。为各种本机应用程序启用本机单点登录。OAuth和OpenIDConnect都支持OAuth2规范规定的四种授权类型。下图描述了其中一个授权流程图。API开发者可以根据手头项目的约束和实现方案选择不同的授权类型。4.数据保密和个人身份信息的屏蔽众所周知，密码、安全令牌和API密钥包含不同程度的内部信息，不应出现在URL中或被Web服务器日志捕获。此外，用户ID、密码、帐号、信用卡号等个人身份信息也应“编码”，即使在交易和审计日志中也是如此。由于公共API的安全实践是独立于任何用户的，所以设计公共API的初衷就是暴露各种非敏感只读数据（比如天气API），当然没有必要添加任何身份验证和授权链接。但是，我建议您通过执行以下操作来构建能够抵御威胁和滥用的API：在IP地址级别应用速率限制的策略。APIkey认证的使用方式。通过存储在网关上，可以保证API密钥不会发布给任何客户端。因此，当拒绝服务攻击使用无效密钥访问API时，或者其他策略无法阻止黑客攻击时，API密钥验证方法可以有效发挥作用。使用配额策略（单个或多个配额机制）来实施API使用限制。如果API用于与特定地理区域的服务器通信，则应在地理级别（县/区等）按IP地址进行过滤。开发者应尽量采用一次性注册的方式，使用自己的APIkey调用API。结束语当企业内部和企业之间需要集成不同的应用时，开发者可以通过API快速方便地实现。但是，未妥善保护的API会使整个企业面临风险和威胁。因此，我们需要在开发和实施之前做好API安全的构建和设计，以提高企业的整体安全态势。原标题：EnsuringtheSecurityofYourAPIs?，作者：VivekYadav
