安全策略即代码 | Conjur策略简介

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而言是新来的，你可以开始我们的在线学习平台。