x

【数据安全】采用HashiCorp Vault :第N天

Chinese, Simplified
SEO Title
Adopting HashiCorp Vault ：Day N

存储密钥轮换


存储密钥对存储在Vault中的每个秘密进行加密，并且仅在内存中未加密。 只需向正确的API端点或CLI发送呼叫，即可在线轮换此密钥：

$ vault operator rotate
Key Term        3
Install Time    01 May 17 10:30 UTC

这需要在策略上设置的权限。从旋转密钥的时间点开始，每个新密钥都用新密钥加密。这是一个相当简单的过程，大多数组织每六个月进行一次，除非有妥协。

主钥匙旋转


主密钥包装存储密钥，并且只在内存中未加密。使用自动开封时，主密钥将由密封密钥加密，并且将为某些操作提供恢复密钥。此过程也是在线的，不会造成任何中断，但需要密钥持有者输入其当前的分片或恢复密钥以验证过程，并且它的时间限制。该程序的执行方式如下：

  1. 密钥持有者将其GPG公钥发送给运营商。
  2. 操作员将启动重新键入过程，提供密钥持有者GPG公钥，并从Vault中检索随机数。
  3. 该随机数被移交给主要官员以验证该操作。法定人数的主要官员继续提交他们的钥匙。
  4. 运营商（一旦达到法定人数的关键人员），可以检索使用GPG加密的新密钥，并将其交给关键人员。
  5. 主要官员可以着手验证他们的新共享。

只要钥匙扣长时间不再可用，就应执行此程序。传统上，在组织中与人力资源部门进行一定程度的协作，或者这些程序已经存在于使用HSM的组织，并且可以用于Vault。

该程序的说明可以在下面找到。

除非有妥协，否则此程序通常由组织每年执行。

密封钥匙旋转


这个程序因密封而异。

对于PKCS＃11密封，传统上操作员只需更改key_label和hmac_key_label参数。 在检测到标签已更改且与用于加密主密钥的标签不匹配时，Vault将仅重新包装它：

2018-09-05T11:56:22.892Z [DEBUG] cluster listener addresses synthesized: cluster_addresses=[127.0.0.1:8201]
2018-09-05T11:56:22.892Z [INFO ] core: stored unseal keys supported, attempting fetch
2018-09-05T11:56:22.892Z [DEBUG] sealwrap: unwrapping entry: key=core/hsm/barrier-unseal-keys
2018-09-05T11:56:22.893Z [DEBUG] sealwrap: unwrapping entry: key=core/keyring
2018-09-05T11:56:22.895Z [INFO ] core: vault is unsealed
2018-09-05T11:56:22.895Z [INFO ] core: post-unseal setup starting
2018-09-05T11:56:22.895Z [DEBUG] core: clearing forwarding clients
2018-09-05T11:56:22.895Z [DEBUG] core: done clearing forwarding clients
2018-09-05T11:56:22.895Z [DEBUG] sealwrap: checking upgrades
2018-09-05T11:56:22.895Z [DEBUG] sealwrap: unwrapping entry: key=core/hsm/barrier-unseal-keys
2018-09-05T11:56:22.896Z [TRACE] sealwrap: wrapping entry: key=core/hsm/barrier-unseal-keys
2018-09-05T11:56:22.898Z [DEBUG] sealwrap: unwrapping entry: key=core/keyring
2018-09-05T11:56:22.899Z [TRACE] sealwrap: wrapping entry: key=core/keyring
2018-09-05T11:56:22.900Z [DEBUG] sealwrap: upgrade completed successfully
2018-09-05T11:56:22.900Z [DEBUG] sealwrap: unwrapping entry: key=core/wrapping/jwtkey
2018-09-05T11:56:22.902Z [TRACE] sealwrap: wrapping entry: key=core/wrapping/jwtkey

可以使用HSM工具或pkcs11-list命令验证密钥的存在：

$ pkcs11-list
Enter Pin:
object[0]: handle 2 class 4 label[11] 'vault_key_2' id[10] 0x3130323636303831...
object[2]: handle 4 class 4 label[16] 'vault_hmac_key_1' id[9] 0x3635313134313231...
object[3]: handle 5 class 4 label[11] 'vault_key_1' id[10] 0x3139303538303233...

DR推广


将执行DR促销程序以在灾难性故障时继续服务，这将使主集群无法使用。如果主群集正在使用中，则不应执行此过程，因为它可能会产生意外后果。

触发DR促销的可能原因包括但不限于：

  • 主数据中心故障
  • 主群集上的数据损坏
  • 密封键丢失
  • 密封密钥篡改

此程序包括保险柜操作员和主要官员，类似于启封或关键轮换，因为法定人数需要通过提交其关键份额来批准操作。

  • 运营商提交将辅助群集提升为主要群组的请求。这是DR群集可用的唯一端点之一，在正常参数下无法运行。它将检索操作的nonce。
  • 主要官员将继续提交他们的关键碎片。
  • 一旦达到法定人数的关键人员，操作员就可以检索操作密钥。
  • 该操作键是一次性使用，操作员将使用它来开始促销过程。

该过程如下图所示。

政策维护模式


当集中管理策略时，实现管道以维护Vault中的策略添加是非常常见的，以便启用合并批准系统，潜在的消费者可以请求访问，并且运营商和中央安全性都可以允许合并。 Terraform可用于读取策略文件并确保代码和策略之间的符合性。

策略模板还可用作减少维护策略数量的方法，基于来自属性的插值或来自实体的键值对。

例如，从包含“应用程序”键的实体，带有“APMA”值：

$ vault read identity/entity/id/670577b3-0acb-2f5c-6e14-0222d3478ce3
Key                    Value
---                    -----
aliases                [map[canonical_id:670577b3-0acb-2f5c-6e14-0222d3478ce3 creation_time:2018-11-13T13:15:04.400343Z mount_path:auth/userpass/ mount_type:userpass name:nico id:14129432-cf46-d6a6-3bdf-dcad71a51f4a last_update_time:2018-11-13T13:15:04.400343Z merged_from_canonical_ids:<nil> metadata:<nil> mount_accessor:auth_userpass_31a3c976]]
creation_time          2018-11-13T13:14:57.741079Z
direct_group_ids       []
disabled               false
group_ids              []
id                     670577b3-0acb-2f5c-6e14-0222d3478ce3
inherited_group_ids    []
last_update_time       2018-11-13T13:20:53.648665Z
merged_entity_ids      <nil>
metadata               map[application:APMA]
name                   nico
policies               [default test]

可以存在一个策略来访问与已定义键的值匹配的静态秘密装载：

path "{{identity.entity.metadata.application}}/*" {
  capabilities = ["read","create","update","delete"]
}

可以通过Sentinel引入治理导向策略，作为角色或端点管理策略。

应用上线


将新秘密添加到Vault并使新应用程序能够使用它们是Vault中最常规的操作。

每个组织在秘密生成，消费和移交点方面都有自己的指导方针，但一般来说，提前商定以下几个方面：

  1. 什么是消费者参与这个过程。消费者将负责通过Vault进行身份验证，保护令牌，然后获取机密，或者期望存在一定程度的自动化以保证令牌前进。切换点需要事先商定。
  2. 是否有一个团队处理运行时，因此，开发人员没有参与，应用程序外部的工具将用于消耗秘密。
  3. 消费者是命名空间的一部分，因此应该为新应用程序创建角色。
  4. 如果使用静态机密，消费者是否希望将密钥手动存储到Vault中，或者是否会由进程自动刷新。

最常见的是，如前所述，组织首先审核已存储在多个源中的静态密码，并将其存储到Vault中以使其受到管理。从那里，应用程序可以使用上述模式来使用它，并且可以引入过程来管理它们的生命周期，或者有效地将生命周期管理转移到秘密引擎。

否则，入门应用程序的步骤非常通用：

  1. 使用Vault设置身份验证，或者只是创建一个映射到策略的角色（除非使用上面提到的技术之一）
  2. 定义将存储秘密的位置
  3. 设置应用程序以使用它


其他资源

 

原文：https://www.hashicorp.com/resources/adopting-hashicorp-vault#day-n

本文：https://pub.intelligentx.net/adopting-hashicorp-vault-day-n

讨论：请加入知识星球或者小红圈【首席架构师圈】

 

Tags

Article
知识星球
 
微信公众号
 
视频号
 
↑