AAE提供Credentials作为敏感信息的管理模块。
官方说明如下：
这些凭证由 Credential Vault 服务加密，以符合 NIST SC-28 并防止未经授权的访问或凭证泄露。只有加密的凭证从 CR 传输到数据库服务器，并以加密形式存储在数据库中。数据加密密钥使用 FIPS 140-2 1 级验证模块生成的 AES 256 位密钥对所有凭证进行加密，以满足 NIST IA-7、SC-12 和 13 关于对加密模块实施身份验证机制的要求，从而符合适用联邦法律的要求。
在v10，Credential相对简单。只需要创建后直接在AAE客户端套用就可以了。
从v11.x开始混合了RBAC的概念，不同的角色管理不同的密码信息。
保险箱的管理和credential的管理区分开来后应对更加复杂的企业级敏感信息管理。
另外还有Locker Management（保险箱管理）。没有放进保险箱的凭证不允许在客户端使用。
由此，保险箱的创建是凭证管理的第一步。首先要确保Locker权限已经赋予某一个用户。
默认admin没有locker Admin权限，也不允许编辑
image.png
然后，创建locker:
image.png
创建过程中会有Locker管理权限的分配问题：
image.png
有关各种角色拥有的权限如下图：
image.png
这里要注意的是，consumer才是消费Credentials的主体。
机器人或者脚本想要使用凭证就需要保证有这个权限。AAE的设计不允许用户直接成为消费者，一定要以某个角色成为消费者(consumer)。
image.png
创建角色时要考虑的点如下：
- 区分凭证消费者和凭证维护者。
- 是否使用第三方平台通过API完成密码自动更新，可参照。
image.png
创建的consumer角色被locker分配后，我们可以开始创建凭证。
image.png
创建凭证界面如下：
image.png
这里要考虑的点是：
1.密码维护方式：统一凭证信息 vs 不同的bot调用凭证时获取的值是不同的（细节待验证）。
2.安全：掩码是需要的，尤其是密码。This is password(部分AAE11.X)就有些尴尬。因为业务系统设计时不一定严格按照type为password来设计。如果选中这一项就可能导致凭证信息无法在业务系统里使用。
如果不设置，密码信息就可以通过insert Keystroke方式打印出来。多一个安全隐患。
image.png
其他信息可以移步这里，不多写了。
网友评论