5A 原则

5A 原则是由 5 个首字母为 A 的单词构成的，分别是 Authentication（身份认证）、Authorization（授权）、Access Control（访问控制）、Auditable（可审计性）、Asset Protection（资产保护），其含义是当安全设计人员在做安全设计时，需要从这 5 个方面考量安全设计的合理性。如果某一个方面缺失，则在安全设计上是不全面的。

1、身份认证

身份认证的目的是为了知道谁在与 API 服务进行通信，是否是 API 服务允许的客户端请求。在普通的 Web 应用程序中，通常会提供注册、登录的功能，没有注册、登录的用户无法访问某些系统功能。对于 API 服务来说，也是一样的道理。很多场景下的 API 服务，是需要知道谁在请求，是否允许请求，以保障 API 接口调用的安全性。

2、授权

授权通常发生在身份认证之后，身份认证是解决“你是谁”的问题，即对服务来说，谁在请求我。而授权解决的是“你能访问什么”的问题，即通过了身份认证之后，访问者被授予可以访问哪些 API。某些 API 只有特定的角色才可以访问，比如只有内网的 IP 才可以调用某些服务、只有管理员用户才可以调用删除用户的 API。赋予某个客户端调用权限的过程，通常为授权操作的过程。

3、访问控制

访问控制通常发生在授权之后，很多情况下，对于某个角色的权限设置正确，但访问控制做的不一定正确，这也是存在很多越权操作的原因。访问控制是对授权后的客户端访问时的正确性验证。读者可以设想一下，一个普通的 Web 应用系统，用户通常关联角色，角色再对应关联菜单，授权就是用户→角色→菜单这三个实体对象间建立相互关系的过程。如果这个相互关系设置正确，用户是不具备访问这个功能菜单的权限的，但如果用户访问这个功能菜单时，因访问控制没有限制，仍可以访问，这就是访问控制的缺陷。对应于 API 服务，也是如此，不具备访问权限的 API 却可以直接调用，问题就出在访问控制上。

4、可审计性

可审计性是所有应用程序很重要的一个特性，只是很多情况下，系统管理人员过多的关注于功能实现而忽略了可审计的功能。审计的目的对于 API 来说，主要是为了记录接口调用的关键信息，以便通过审计手段及时发现问题，并在发生问题时通过审计日志进行溯源，找出问题的发生点。不具备可审计性的 API 当接口发生问题时将是两眼一抹黑，望 API 兴叹。

5、资产保护

API 安全中的资产保护主要是指对 API 接口自身的保护，比如限速、限流，防止恶意调用，除此之外，API 接口传输的数据也是需要保护的一个重点内容。在现代的 API 服务中，接口间相互传递的数据存在很多敏感信息，比如个人信息相关的手机号码、身份证号，业务相关的银行账号、资金、密码等。这些信息资产，在 API 安全中是特别需要保护的内容，这也是安全设计人员在 API 安全设计中需要考虑的一个方面。

5A 原则重点强调每一层安全架构设计的合理性，是横向的安全防护，强调的是宽度。