如何构建和设计以确保 API 的安全性
|
· 授权则被用于授予已识别用户访问某些资源的权限。 在API领域中，OAuth和OpenID Connect是最为常用的机制。它们通过利用现有的IAM架构，并以交换访问令牌的方式，来验证用户的身份，进而保护API的各个端点。通过OAuth和OpenID Connect，我们不需要每次都构建单独的系统，以存储用户名和密码的方式，来匹配用户可以访问的API资源。 OAuth OAuth通常采用不透明(OPAQUE)令牌，来实现委托访问(Delegated Access)的目的。OAuth2.0授权框架使得第三方应用能够获得对于HTTP服务的有限访问权限。通常，用户不应当为了访问某些存储在第三方的受保护数据，而在公网上传输自己的密码。而OAuth恰好能够为用户访问自己的数据，提供了信任凭据的安全保护。 OAuth不是一种身份验证协议，而是授权协议。由于身份验证通常发生在颁发访问令牌之前，因此我们很容易理解为在接受访问令牌时，也进行了身份验证。然而，仅凭拥有访问令牌，并不能证明用户的身份。在OAuth中，令牌被设计为对客户端来说是不透明的，客户端仅能从令牌中获取权限信息，而不会涉及到用户名与密码。 不透明令牌:在许多的具体实现中，OAuth2.0会返回OPAQUE字符串，用以换取被称为访问令牌的用户凭据，而这些令牌将被进一步用于访问各种API的资源。不透明令牌并非用来存储用户身份标识与信息，而是指向了某个数据库里的具体数据项。例如：我们可以用Redis来存储各种键-值(key-value)。而Cassandra之类的NoSQL数据库则非常适合利用内存中的哈希表，根据I/O来查找有效负载。由于用户角色是直接从数据库中被读出的，因此我们可以通过更改后端的角色，来传递并展现给用户。 OpenID Connect OpenID Connect采用ID令牌和访问令牌，来实现用户识别与委托访问。OpenID Connect是进行用户身份验证的标准。由于直接构建在OAuth2.0之上，因此在大多数情况下，OpenID Connect是与OAuth架构一起被部署的。在交付形式上，它还为客户端提供OpenID Connect令牌。该身份令牌是一个已签名的JSON Web令牌(JWT)，它与常规的OAuth访问令牌一起被提交给客户端应用程序。 · JSON Web令牌：JWT令牌实际上是一个完整的JSON对象。它经历了base64编码之后，使用对称共享密钥、或公/私钥的方式进行签名。JWT可以包含诸如：主题、user_id、令牌颁发时间、以及过期时间等信息。通过密钥签名，它可以确保只对拥有授权访问密钥的系统才能生成令牌。不过值得注意的是，系统在对JWT进行签名时，JWT通常不会被加密(当然，您也可以选择对其进行加密)。那么，这就意味着任何拥有令牌访问权限的人都可以读取令牌里的数据。因此，业界的最佳实践是：只把用户标识(如user_id)放在令牌中，而不是个人身份信息(如电子邮件或社会保障号码)。此外，它们应当通过TLS之类的加密通道来进行传递。 · JWT限制：鉴于日常对于用户的禁用、以及添加或删除角色往往需要一段时间才能同步生效，而且由于令牌存储在客户端，即使我们在数据库中对其所颁发的JWT用户进行了禁用标记的话，也无法直接让该令牌及时无效。虽然JWT采取了预定义到期的机制，但是用户仍然需要等待到期。显然这会影响到用户的服务架构，特别是那些电商类的应用。 当然，业界也提供了一些变通的方法。例如：您可以使用带有令牌或user_id的黑名单，但是这需要向数据库引入新的认证机制。因此，一种推荐的方法是：通过黑名单以确保每个令牌都带有一个JTI声明(或带有一个存储在数据库中的JWT Id)。因此，只要您希望注销的令牌数量远小于应用程序中的用户数量，那么操作起来就非常灵活。 可见，对于那些拥有管理员、项目所有者、服务客户经理等多种角色的企业应用来说，切换用户的不同角色并不会对JWT立即生效。例如：管理员修改了某个授权用户的角色，那么只要他不去刷新JWT，也就无法获悉该变更。 下面是OpenID Connect的三种实现用例： · 出栈方向的Web单一登录(SSO)：向企业用户提供对于SaaS应用、以及合作伙伴应用的访问管控，但并不公开本企业的用户名与密码。 · 入栈方向的Web单一登录：允许社交账号/第三方登录，但无需存储外部用户与密码。 · 实现各种本地应用的原生单一登录。 OAuth和OpenID Connect都支持OAuth2规范所指定的四种授权类型，下图描述了其中一种授权流程图。API开发人员可以根据手头项目所需的约束与实现方案，来选用不同的授权类型。 4. 数据保密与屏蔽个人身份信息 众所周知，由于密码、安全令牌和API密钥包含了不同程度的内部信息，它们不应该出现在URL中，或者被Web服务器的日志所捕获。此外，诸如UserID、密码、帐号、信用卡号码等个人身份信息，也应该处于“被打码”的状态，哪怕是在交易和审计日志中。 公共API的安全实践 由于独立于任何用户，因此公共API的设计初衷就是为了公开各种非敏感、以及只读的数据(例如天气类API)，当然也就不必添加任何身份验证与授权环节。不过，我建议您通过如下的方面，来打造能够应对各种威胁与滥用的API： · 在IP地址级别上应用速率限制的相关策略。 · 使用API密钥验证的方式。通过存储在网关上的方式，保证API的密钥不会被公布给任何客户端。因此，当拒绝服务攻击使用无效密钥访问API、或是在其他策略已无法阻断黑客攻击时，API密钥验证方式能够有效地发挥作用。 · 采用配额策略(单个或多种配额机制)，来实现API的使用限制。 · 如果API被用于特定地理区域的服务器进行通信，那么就应当在地理级别上(县/区等)采取IP地址的筛选。 · 开发人员应尽量采用一次性注册的方式，并使用自己的API密钥去调用API。 结论 在企业内部、以及企业之间需要集成不同的应用时，开发人员能够通过API来快速且方便地予以实现。不过，如果没有恰当地保护好API，那么就会让整个企业面临各种风险与威胁。因此，我们需要在开发和实施之前，就对API的安全性进行良好的构建和设计，从而提高企业的整体安全态势。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
