Conjur策略简介
每个Conjur工作流都以Conjur策略开始：无论是教程、演练、设置脚本、博客发布指引，其中都包含安全策略。这是因为Conjur中的所有内容都存在于安全上下文中。
安全是人类的概念，需要清晰的沟通工具。MAML（机器授权标记语言）策略是Conjur操作人员用来交流组织如何授予访问权限和维护控制权的主要工具。它就是安全策略即代码（security policyas code）。
为了开始和MAML一起思考，让我们来看看Alice的故事，她是一个大型假设IT组织的高级安全工程师。她负责保护对数据库的访问，并部署了开源Conjur.org，以更好地控制特权数据库帐户。
1. 角色
让我们从最简单的MAML策略开始：单个用户。
---
- !user alice
Alice加载代表其用户的此策略。目前，用户无权访问任何内容，并且该策略没有定义可以授予其访问权限的任何内容。但以后会有。
在Conjur中，用户是基于角色的访问控制（ role-based access control）意义上的角色。每个用户代表一个人，比如爱丽丝。她的角色隐式地具有一个相关的秘密：一个Conjur API密钥。这是爱丽丝唯一需要证明自己身份真实性的秘密。她可以轮换自己的API密钥，还可以选择设置密码。
2. 资源和权限
可以为用户分配访问资源的权限。爱丽丝想把她的生产和管理密码存储在Conjur中，所以她创建了资源来表示它们。她的策略如下：
---
- !user alice
- !variable database-password
- !variable database-admin-password
- !permit
role: !user alice
privileges:
- read
- execute
- update
resources:
- !variable database-password
- !variable database-admin-password
Alice的策略将负责安全的基础设施建模为一组角色和资源，并明确定义了权限。将该策略加载到Conjur中会创建一个功能系统，该系统允许基于身份访问功能（如获取数据库密码的功能）。对于任何请求，Conjur将验证用户的身份，然后根据策略授权请求。
因为Alice对密码具有读取（read ）权限，所以Conjur会将其作为搜索和资源列表的一部分显示出来。当她去获取密码值时，Conjur会检查她的执行（execute ）权限以确保她得到授权。同样，它检查她的更新（update ）权限以授权她轮换密码。
3. 授权
爱丽丝不是一个人工作的。她的同事Bob是一名开发人员，需要对数据库进行生产访问，但他不需要轮换密码或访问管理帐户。她可以根据最小权限原则更新她的策略，给予他适当的访问权。
---
# Roles
- !user alice
- !user bob
# Resources
- !variable database-password
- !variable database-admin-password
# Permissions
- !permit
role: !user alice
privileges:
- read
- execute
- update
resources:
- !variable database-password
- !variable database-admin-password
- !permit
role: !user bob
privileges:
- read
- execute
resource: !variable database-password
改变之处：我们添加了一个新用户和第二个许可证。
4. 机器身份
在与Alice进行的一次安全审查中，Bob提到他自己从未真正使用过数据库密码。相反，是他的应用程序登录到数据库运行查询。他有一个应用程序的部署密钥，他想把它存储在Conjur中。Alice建议他为他的代码使用机器身份（machine identity），而不是共享他的人类凭证。他们修改策略以反映他们的新理解：
---
# Roles
- !user alice
- !user bob
## Bob's Query Runner App
- !host query-runner
# Resources
- !variable database-password
- !variable database-admin-password
- !variable query-runner-deploy-key
# Permissions
- !permit
role: !user alice
privileges:
- read
- execute
- update
resources:
- !variable database-password
- !variable database-admin-password
- !permit
role: !user bob
privileges:
- read
- execute
- update
resource: !variable query-runner-deploy-key
- !permit
role:!host query-runner
privileges:
- read
- execute
resource: !variable database-password
改变之处：我们添加了一个新的主机（host）和一个新的变量（variable）。我们将Bob对数据库密码（database-password）资源的特权授予了 query-runner 角色，并授予Bob获取和轮换其部署密钥的权限。
5. 扩展到更大的人类组织
Bob和Alice认识到他们在Conjur中存储的秘密，对他们组织中的其他人有用，使用MAML策略来描述整个基础设施将是一件好事。
在计划这种扩展时，他们注意到，如果每次有人加入、离开或更改组织中的角色时都必须检查和更新安全策略，那么维护安全策略将是一件很麻烦的事情。
用层（layers）、组（groups）、权限（entitlements）来解决单调乏味的问题。通过创建（主机的）层和（层、用户、其他组的）组，并向这些角色授予权限，而不是直接向用户和主机授予权限，您可以通过更改用户和主机的组成员身份（groupmemberships）轻松修改其权限。
Alice提出这种策略修改，以准备将Conjur推出到更大的用户群：
---
# Roles
- !user alice
- !user bob
## Bob's Query Runner App
- !host query-runner
# Groups and layers
- !group database-admins
- !layer database-users
- !group deployers
# Resources
- !variable database-password
- !variable database-admin-password
- !variable query-runner-deploy-key
# Permissions
- !permit
role: !group database-admins
privileges:
- read
- execute
- update
resources:
- !variable database-password
- !variable database-admin-password
- !permit
role: !group deployers
privileges:
- read
- execute
- update
resource: !variable query-runner-deploy-key
- !permit
role: !layer database-users
privileges:
- read
- execute
resource: !variable database-password
# Entitlements
- !grant
role: !group database-admins
member: !user alice
- !grant
role: !group deployers
member: !user bob
- !grant
role: !layer database-users
member: !host query-runner
改变之处：我们添加了三个新角色：数据库管理员（database-admins）和部署人员（deployers）组，以及数据库用户（database-users）层。许可证现在授予组或层权限，而不是直接授予用户或主机。最后，我们在底部添加了“权限”（Entitlements）部分。
当组织环境发生变化时，不需要更新或审查任何许可证。工作流只要求在适当的组或层中创建并授予新用户或主机成员资格，或者根据情况的要求取消角色的成员资格。
Conjur提供了一些工具来简化授权工作流。例如，可以通过与LDAP或Active Directory服务器同步将用户添加到系统中，并且可以使用主机工厂（hostfactory）以自动方式将主机添加到系统中。
赋予更大的权力
随着Conjur的采用，Alice正在管理越来越多的团队的策略，需要将权力委托给每个团队的安全运营代表。Conjur通过策略分支（policy branches）支持这一点。策略树的根目录可以包含由Conjur admin以外的角色拥有的任意数量的分支，并且这些分支可以依次拥有其他分支，并进一步授权。
Alice使用数据库的一个分支和查询运行程序的另一个分支，重新构造了她的策略。Alice的同事Charlie（另一名安全工程师）将负责审查和管理查询运行程序策略，因此将其所有权委托给他，而Alice仍然是其数据库策略的所有者。
# Roles
- !user alice
- !user bob
- !user charlie
# Policy branches for database andquery runner
- !policy
id: database
owner: !user alice
body:
# Database roles
- !layer users
- !group admins
# Database resources (variables)
- !variable password
- !variable admin-password
# Database permissions
- !permit
role: !group admins
privileges:
- read
- execute
- update
resources:
- !variable password
- !variable admin-password
- !permit
role: !group users
privileges:
- read
- execute
resources:
- !variable password
- !policy
id: query-runner
owner: !user charlie
body:
# Roles
- !group deployers
- !host
# Resources
- !variable deploy-key
# Permissions
- !permit
role: !group deployers
privileges:
- read
- execute
- update
resource: !variable deploy-key
# Entitlements
- !grant
role: !group database/admins
members:
- !user alice
- !user charlie
- !grant
role: !group query-runner/deployers
member: !user bob
- !grant
role: !layer database/users
member: !host query-runner
改变之处：数据库用户（database-users ）和数据库管理员 （database-admins） 组移动到名为database的分支中，因此获得了新名称：database/users和database/admins。database-password 成为database/password 的原因与数据库管理员密码相同。这同样适用于现在属于query-runner策略分支的角色和资源。我们增加了一个新用户：Charlie。以前，Alice是唯一可以更改策略的Conjur管理员，现在她已将对query-runner分支的控制权委托给了Charlie。他有能力更改和更新这个策略分支，但不能更改它之外的任何内容。
将策略拆分为多个分支有一个好处，Alice可以将策略资源的“更新”权限授予安全团队中的另一个人。
从单个用户到一个完整的策略树，Conjur MAML使得建模基础设施、授予访问权限、维护控制变得容易，所有这些都使用人类可读和机器可执行的代码。
扩展阅读
更多有关将MAML策略与Conjur一起使用的操作详细信息，可以阅读完整的Conjur策略文档。我们还提供了一些策略教程，供您学习如何开始编写和使用自己的策略。如果你对于Conjur而言是新来的，你可以开始我们的在线学习平台。
