OpenBao实战指南：构建高可用的动态秘密管理与安全密钥中心

1. 项目概述：为什么我们需要OpenBao？

最近在和一些做后端开发的朋友聊天，发现一个挺普遍的现象：项目初期，为了图快，各种API密钥、数据库密码、第三方服务的Token，要么直接硬编码在配置文件里，要么就散落在各个环境变量里，管理起来一团乱麻。等到项目要上线、要审计、或者有成员变动时，安全问题就成了悬在头上的达摩克利斯之剑。这时候大家才开始到处找方案，什么“密钥保险箱”、“配置中心”之类的词就频繁出现了。其实，这背后反映的是一个核心的工程与安全诉求：如何系统化、安全地管理那些不能见光的“秘密”（Secrets）。

OpenBao，就是在这个背景下你必须了解甚至掌握的工具。它不是一个新概念，你可以把它理解为一个开源的、现代化的“数字保险柜”。所有敏感的配置信息，不再是明文，而是被这个保险柜统一加密存储、精细控制访问权限、并且提供完整的操作审计日志。简单来说，它帮你解决了“密钥放哪、怎么用、怎么管”的核心安全难题。最近社区里关于“session存储安全”、“密钥工具”的讨论很热，这恰恰说明了大家对应用层安全基建的重视程度在提升。无论你是运维工程师、DevOps、还是后端开发者，如果你正在为敏感数据的管理而头疼，或者你的项目正面临合规性要求（比如等保、GDPR），那么深入理解并实践OpenBao，会是你技术栈中极具价值的一环。这篇指南的目标，就是带你从“这是个啥”开始，一路走到“我能用它设计一套生产级方案”，把原理、实操和踩坑经验都讲透。

2. OpenBao核心架构与设计哲学

在动手部署和写第一行代码之前，我们必须先理解OpenBao是怎么思考问题的。这决定了你后续使用它的方式是否“正确”，能否发挥其最大价值。

2.1 核心模型：秘密、引擎与策略

OpenBao的整个世界观建立在几个核心抽象之上，理解它们就理解了它的设计。

1. 秘密（Secret）：这是OpenBao管理的基本单位。它不仅仅是一个密码，可以是任何键值对（Key-Value）形式的数据。比如：

• password=MySuperSecret123!
• connection_string=“host=localhost port=5432 user=admin...”
• 甚至是一个完整的JSON对象，如证书文件内容。 关键点在于，这些数据一旦存入OpenBao，其“数据平面”的传输和存储默认都是加密的。客户端通过API读取时，拿到的是解密后的明文，但过程中OpenBao服务端自身不会持久化明文。

2. 引擎（Secrets Engine）：这是OpenBao最强大的设计之一。引擎是秘密产生、存储或计算的模块。不同类型的秘密，由不同的引擎管理，每种引擎提供特定的API接口。

• KV引擎：最常用，就是个加密的键值存储。分v1和v2版本，v2支持版本化、元数据等高级功能。
• 数据库引擎：动态生成数据库凭据。你无需再手动创建并管理一个长期有效的数据库用户。应用请求时，OpenBao可以按策略动态生成一个只有特定生命周期（如1小时）的数据库用户名和密码。过期自动失效，极大缩小了凭据泄露的风险窗口。
• PKI引擎：全功能的私有证书颁发机构（CA）。可以签发和管理TLS/SSL证书，自动化证书生命周期，解决自签名证书或内部CA管理的麻烦。
• AWS、Azure、GCP等云引擎：动态生成云平台的IAM访问密钥或安全令牌。 这种设计的好处是，将秘密的“静态存储”升级为“动态生成”，按需供应，用过即焚，这是实现“零信任”安全模型的关键一步。

3. 认证方法（Auth Method）：用户或机器如何证明自己有权访问OpenBao？这就是认证方法负责的。OpenBao支持多种方式：

• Token：最基础的方式，一个字符串令牌。但最佳实践是结合其他认证方式动态获取短期Token，而不是使用长期有效的根Token。
• AppRole：最适合机器对机器（服务账户）认证的方式。它通过role_id和secret_id进行认证，非常适合集成到CI/CD流水线或应用程序中。
• Kubernetes：在K8s集群内，Pod可以利用其Service Account Token来认证OpenBao，实现无缝集成。
• LDAP/Userpass：用于用户认证。 认证成功后，OpenBao会返回一个客户端Token，用于后续的API调用授权。

4. 策略（Policy）：这是OpenBao的授权核心。策略用HCL或JSON定义，精确描述了“谁”（通过某种认证方式获得了一个身份）能“对哪些路径”（引擎内的秘密路径）“执行什么操作”（读、写、删除、列表等）。例如，一个策略可以规定：“通过AppRolebackend-app认证的实体，只能对路径secret/data/application/*进行读操作，不能写也不能列表其他路径。” 权限控制粒度极细，遵循最小权限原则。

2.2 安全基石：屏障、存储后端与初始化

OpenBao服务启动时，其内存中存在一个核心安全组件：安全屏障（Security Barrier）。所有写入持久化存储（如Consul、文件、Raft）的数据，都会先经过这个屏障加密。这意味着，你的存储后端（Storage Backend）里存的全部是密文。即使攻击者拿到了底层数据库或磁盘数据，在没有OpenBao主密钥的情况下也无法解密。

这里就引出了**主密钥（Master Key）和根令牌（Root Token）**的概念。OpenBao服务第一次启动时，处于“未初始化”状态。你必须执行初始化操作，这会生成：

• 主密钥：通常由多个密钥分片（Unseal Key）组成，用于加密安全屏障的密钥。OpenBao使用Shamir秘密共享算法，可以配置为需要M个分片中的N个（如5选3）才能解封（Unseal）服务。这避免了单点故障，是生产环境必须的配置。
• 根令牌：一个拥有系统最高权限的Token，用于初始配置（如启用引擎、创建策略、设置认证方法）。根令牌一旦使用完毕，应立即撤销并安全保存，日常运维绝对不应使用它。

服务启动后，状态是“密封”（Sealed）的。此时安全屏障无法解密数据，服务无法处理任何涉及秘密的请求。必须使用足够数量的密钥分片来“解封”（Unseal）服务，屏障才能正常工作。服务器重启后，会再次进入密封状态，需要重新解封。这个设计确保了即使服务器被入侵，攻击者也无法直接获取到内存中的密钥和解密数据。

实操心得：密钥分片管理把5个密钥分片给5个不同的人保管，或者将其中几个存入安全的硬件设备（如银行保险箱）。绝对不要全部放在同一个地方（比如同一个密码管理器）。初始化时生成的根令牌，最好只用一次来完成初始策略和AppRole设置，然后立即吊销。日常操作应该使用具有特定权限的Token。

3. 生产环境部署与高可用配置

了解了核心概念，我们进入实战环节。单机模式只适合测试，生产环境我们必须考虑高可用（HA）和可靠性。OpenBao通过其存储后端来实现HA。

3.1 存储后端选型：Raft集成存储

早期OpenBao依赖外部存储如Consul来实现HA。现在，强烈推荐使用其内置的Raft集成存储。它基于Raft共识算法，将数据存储在多节点组成的集群中，自动处理领导者选举和数据复制，部署和管理都简单得多。

假设我们部署一个3节点的OpenBao集群。

节点1（初始节点）配置config.hcl：

storage "raft" { path = "/vault/data" node_id = "node1" } listener "tcp" { address = "0.0.0.0:8200" tls_disable = false tls_cert_file = "/etc/vault/tls/vault.crt" tls_key_file = "/etc/vault/tls/vault.key" } api_addr = "https://node1.example.com:8200" cluster_addr = "https://node1.example.com:8201" disable_mlock = true

• storage “raft”：指定使用Raft存储。
• node_id：集群内节点的唯一标识。
• listener：定义API监听地址。生产环境务必启用TLS（tls_disable = false），并配置有效的证书。自签名证书仅用于测试。
• api_addr：客户端访问此节点的地址。
• cluster_addr：节点间通信的地址。
• disable_mlock：在某些Linux系统中可能需要禁用内存锁定，但这会降低一点安全性，需根据系统支持情况调整。

启动节点1并初始化：

# 启动服务 vault server -config=config.hcl # 在另一个终端，设置API地址并初始化 export VAULT_ADDR='https://node1.example.com:8200' vault operator init -key-shares=5 -key-threshold=3

这个命令会输出5个密钥分片和1个根令牌。务必安全保存！此时节点1是集群的唯一成员，但处于密封状态。

3.2 组建Raft集群

现在，在另外两台服务器上准备节点2和节点3的配置，与节点1类似，只需修改node_id、api_addr和cluster_addr。

首先，解封节点1：

vault operator unseal # 输入任意3个密钥分片

然后，从节点1获取加入集群的令牌：

vault operator raft list-peers # 此时应该只有node1自己 vault operator raft join https://node1.example.com:8200 # 这个命令需要在节点2和节点3上执行，但需要先获取加入令牌。 # 更常用的方式是在节点1生成一个临时的peer token： vault operator raft generate-root -otp -decode - | vault operator raft join -leader-ca-cert=@ca.crt -leader-client-cert=@vault.crt -leader-client-key=@vault.key https://node1.example.com:8200 # 简化流程：通常更直接的方式是，在节点2和节点3的配置中，通过环境变量或初始启动参数指定leader地址（非标准做法，建议查阅最新文档）。 # 标准做法是：先启动节点2/3（未初始化状态），然后在节点1上执行`vault operator raft join https://node2.example.com:8200`并输入节点2的服务器证书指纹进行认证。

注意：Raft集群组建的细节步骤在不同版本间可能有细微差异，核心是确保节点间TLS证书互信，并让follower节点知道leader的地址。生产部署务必参考对应版本的官方文档，并先在小规模测试环境验证流程。

成功加入后，在节点1执行vault operator raft list-peers应该能看到三个节点。节点2和节点3启动后也是密封状态，需要分别解封。在Raft HA模式下，你可以在任何一个已解封的节点上执行读写操作，集群会自动将请求转发到leader节点。

3.3 自动解封与监控

生产环境不能每次重启都手动输入密钥分片。OpenBao支持自动解封（Auto-unseal），使用云服务商（如AWS KMS、Azure Key Vault、GCP CKMS）或硬件安全模块（HSM）作为密钥管理服务，来加密存储主密钥。服务器启动时，会自动联系这些服务解密主密钥，完成解封。这大大提升了运维的便利性和可靠性。

监控是另一个重点。OpenBao提供丰富的监控指标（通过/sys/metrics端点），可以集成到Prometheus+Grafana中。关键指标包括：

• vault.core.unsealed：服务是否已解封（1是，0否）。
• vault.token.lookup：令牌查找的耗时和次数。
• vault.expire.num_leases：当前活跃的租约数量。
• 各引擎操作的请求率和错误率。

同时，必须启用审计日志（Audit Log）。OpenBao可以将所有请求（包括成功和失败）的审计日志输出到文件、Syslog或Socket。审计日志是加密的，确保其不可篡改性，对于安全审计和故障排查至关重要。

4. 核心引擎实战与应用程序集成

部署好集群后，我们来看看怎么用它。我们从最常用的KV引擎开始，然后看动态秘密引擎如何改变游戏规则。

4.1 KV引擎：静态秘密管理的最佳实践

首先，启用KV引擎（版本2功能更强大）：

# 启用名为 ‘secret’ 的KV v2引擎 vault secrets enable -path=secret kv-v2

在KV v2中，路径结构是secret/data/<your-path>，写入和读取有一些变化。

写入一个秘密：

vault kv put secret/data/application/prod db_host="prod-db.internal" db_password="s3cr3tP@ss"

读取秘密：

vault kv get secret/data/application/prod

你会得到类似以下的输出，包含了数据和元数据（版本、创建时间等）：

======= Data ======= Key Value --- ----- db_host prod-db.internal db_password s3cr3tP@ss ======= Metadata ======= Key Value --- ----- created_time 2023-10-27T08:12:14.123456Z deletion_time n/a destroyed false version 1

版本控制与回滚：KV v2支持版本。如果你更新了密码：

vault kv put secret/data/application/prod db_host="prod-db.internal" db_password="n3wS3cr3tP@ss"

现在版本号变成了2。你可以读取特定版本：

vault kv get -version=1 secret/data/application/prod

如果需要回滚，可以用vault kv rollback命令。

实操心得：路径规划秘密的路径设计要有层次和逻辑，这直接影响后续的权限策略制定。例如：

• secret/data/infrastructure/aws/access_key
• secret/data/application/frontend/stripe_api_key
• secret/data/database/prod/postgres/credentials避免把所有秘密都堆在根目录下。按团队、项目、环境（dev/staging/prod）、服务类型进行划分。

4.2 数据库引擎：动态秘密的威力

静态密码总有泄露风险，即使它被加密存储。动态秘密的理念是“按需生成，即时失效”。我们以PostgreSQL为例。

1. 启用数据库引擎：

vault secrets enable database

2. 配置数据库连接：我们需要告诉OpenBao如何连接PostgreSQL，并授予它创建/撤销用户的权限。

vault write database/config/my-postgresql \ plugin_name=postgresql-database-plugin \ allowed_roles="readonly, admin" \ connection_url="postgresql://{{username}}:{{password}}@postgresql-host:5432/postgres?sslmode=disable" \ username="vaultadmin" \ password="vaultadminpassword"

这里，vaultadmin是一个在PostgreSQL中预先创建好的超级用户（或具有CREATEROLE权限的用户），OpenBao会用这个账号去动态创建和删除其他用户。

3. 创建角色（Role）：角色定义了动态生成凭据的模板。我们创建一个只读角色：

vault write database/roles/readonly \ db_name=my-postgresql \ creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \ default_ttl="1h" \ max_ttl="24h"

• creation_statements：OpenBao创建用户时执行的SQL。{{name}}和{{password}}是模板变量，会被OpenBao替换为生成的随机用户名和密码。{{expiration}}是过期时间。
• default_ttl：默认租约时间（1小时），过后密码失效。
• max_ttl：最大租约时间，可以续租，但总时长不能超过此值。

4. 应用程序获取动态凭据：现在，你的应用程序不再需要硬编码数据库密码。它只需要有权限访问这个数据库角色。假设应用通过AppRole认证拿到了一个Token，它可以通过OpenBao API获取临时凭据：

# 使用应用的Token export VAULT_TOKEN=<your-app-token> vault read database/creds/readonly

输出：

Key Value --- ----- lease_id database/creds/readonly/abc123... lease_duration 1h lease_renewable true password A1b-2C3d... username v-token-readonly-xyz987

应用就用这个username和password去连接数据库。1小时后，租约到期，OpenBao会自动执行revocation_statements（如果配置了）来删除这个数据库用户，密码即刻失效。即使这个密码被泄露，危害时间窗口也被限制在1小时内。

4.3 应用程序集成模式

应用程序如何安全地与OpenBao交互？有几种模式：

1. Sidecar/Agent模式：在Kubernetes中，可以在Pod内注入一个OpenBao Agent容器作为Sidecar。应用容器通过本地文件或HTTP（localhost:8200）访问Agent，Agent负责认证、Token续租和秘密获取。这减轻了应用逻辑的复杂性。

2. 原生SDK集成：应用使用OpenBao的客户端库（如Go的github.com/hashicorp/vault/api）。启动时，应用通过预配置的认证方式（如K8s Service Account, AppRole）获取初始Token，然后用这个Token去读取所需秘密，并负责在Token到期前续租。这是最灵活的方式，但需要在应用代码中处理认证逻辑和错误重试。

3. 通过环境变量注入：在CI/CD部署阶段，通过脚本调用OpenBao API获取秘密，然后设置为容器的环境变量。这种方式简单，但秘密在容器生命周期内是静态的，且可能出现在日志或/proc文件系统中，安全性稍逊于前两种。

避坑指南：Token生命周期管理应用持有的Token必须有合理的TTL（生存时间）和续租策略。不要使用永不过期的Token。使用周期性较短的Token（如24小时），并让应用在后台自动续租。同时，确保应用在关闭时能撤销自己的Token（如果可能）。OpenBao的Go客户端库就内置了自动续租和关闭时撤销的逻辑。如果应用崩溃，Token最终也会因过期而失效。

5. 策略、认证与权限管控实战

安全的核心是权限控制。OpenBao的Policy系统非常精细。

5.1 编写精细化策略

策略文件使用HCL或JSON。例如，我们为前端应用创建一个策略frontend-app.hcl：

# 允许读取前端应用所需的秘密 path "secret/data/application/frontend/*" { capabilities = ["read", "list"] } # 允许该身份续租自己的Token租约 path "auth/token/renew-self" { capabilities = ["update"] } # 允许该身份查找自己的Token信息（用于检查是否有效） path "auth/token/lookup-self" { capabilities = ["read"] }

这个策略只授予了读取特定路径下秘密的能力，以及管理自己Token的基本能力，无法写入或删除秘密，也无法访问其他路径。

将策略写入OpenBao：

vault policy write frontend-app frontend-app.hcl

5.2 配置AppRole认证（机器身份最佳实践）

对于服务/应用，AppRole是最佳认证方式。

1. 启用AppRole认证方法：

vault auth enable approle

2. 创建一个角色（Role）：

vault write auth/approle/role/frontend-service \ token_policies="frontend-app" \ token_ttl=24h \ token_max_ttl=48h \ bind_secret_id=true

• token_policies：成功认证后，颁发的Token所附加的策略。
• token_ttl和token_max_ttl：控制Token的生命周期。
• bind_secret_id=true：要求使用secret_id进行认证，增加安全性。

3. 获取角色的role_id和secret_id：role_id是相对静态的，可以认为是用户名。

vault read auth/approle/role/frontend-service/role-id

secret_id是动态生成的密码，应该被安全地分发给应用（例如，通过CI/CD工具在部署时注入环境变量，或存放在一个仅有应用能访问的临时文件中）。

vault write -f auth/approle/role/frontend-service/secret-id

重要：secret_id应该定期轮换（比如每次部署时生成新的），并且旧的要及时销毁。

4. 应用使用role_id和secret_id登录：应用在启动时，调用OpenBao的登录API：

curl --request POST \ --data '{"role_id":"xxx", "secret_id":"yyy"}' \ $VAULT_ADDR/v1/auth/approle/login

返回的响应中会包含一个客户端Token，应用后续就用这个Token去访问OpenBao API。

5.3 权限边界与安全建模

设计OpenBao权限体系时，要像设计数据库Schema一样仔细。建议：

1. 以应用/服务为单位创建角色和策略，而不是以人为单位。
2. 遵循最小权限原则：策略只授予完成工作所必需的最少权限。能读就不要给写，能访问特定路径就不要给根路径。
3. 利用命名空间（Namespaces）（企业版功能）：如果你需要为不同部门、不同业务线提供逻辑隔离，可以使用命名空间。每个命名空间相当于一个独立的OpenBao环境，有自己的认证、策略和秘密。
4. 定期审计：使用vault policy read <policy_name>检查策略，使用审计日志分析访问模式，及时发现异常或过宽的权限。

6. 高级特性与生产运维要点

当基础用法掌握后，这些高级特性和运维细节能让你用得更稳。

6.1 证书管理与PKI引擎

自建CA签发内部TLS证书，PKI引擎是神器。启用PKI引擎后，你可以配置根CA或中间CA，然后定义角色来签发证书。

vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki # 调整最大TTL为10年 # 生成根CA证书 vault write pki/root/generate/internal common_name=mycompany.com ttl=87600h # 配置CRL和URL vault write pki/config/urls issuing_certificates="$VAULT_ADDR/v1/pki/ca" crl_distribution_points="$VAULT_ADDR/v1/pki/crl" # 创建一个角色来签发证书 vault write pki/roles/my-service allowed_domains=“mycompany.com” allow_subdomains=true max_ttl=720h # 签发一个证书 vault write pki/issue/my-service common_name=“app.mycompany.com” ttl=24h

这样，微服务可以动态获取短期有效的TLS证书，实现自动化的证书轮换，彻底告别手动管理证书的麻烦。

6.2 租约、续租与撤销

OpenBao中动态秘密（如数据库凭据、证书）都有租约（Lease）。租约到期，秘密自动失效。应用可以在租约到期前续租（Renew）。如果应用崩溃或不再需要秘密，应该主动撤销（Revoke）租约，OpenBao会立即触发相关的清理操作（如删除数据库用户）。

监控租约数量（vault.expire.num_leases）很重要。如果发现租约数量只增不减，可能意味着应用没有正确撤销租约，存在“租约堆积”的风险，最终可能达到OpenBao的存储上限。

6.3 备份、灾难恢复与升级

备份：对于Raft存储，备份就是Raft日志的存储目录（配置中的path）。你可以定期对这个目录进行快照备份。更推荐使用OpenBao内置的Raft快照功能：

vault operator raft snapshot save backup.snap

这个快照包含了所有加密后的数据和集群配置。

灾难恢复：在新集群上，可以先初始化，然后直接恢复快照：

vault operator raft snapshot restore backup.snap

升级：OpenBao集群升级需要谨慎。一般流程是：逐个节点进行，先升级follower，最后升级leader。确保版本间的兼容性，并详细阅读官方升级指南。升级前务必进行完整的快照备份。

6.4 常见问题排查实录

问题1：Error authenticating: error looking up token: Vault is sealed原因与解决：整个集群处于密封状态。检查所有节点状态vault status。使用密钥分片对每个节点执行解封操作vault operator unseal。如果配置了自动解封，检查云KMS或HSM服务是否正常。

问题2：Permission denied当读取秘密时。原因与解决：客户端Token没有对应路径的读取权限。

1. 检查Token对应的身份和策略：vault token lookup。
2. 检查策略内容：vault policy read <policy_name>。
3. 确认你尝试访问的路径是否被策略允许。注意KV v2的路径包含data层。

问题3：数据库动态凭据生成失败，报连接错误。原因与解决：

1. 检查OpenBao中数据库引擎的配置连接信息是否正确，特别是用于管理的username/password是否有足够权限（CREATEROLE,REVOKE）。
2. 检查网络连通性，OpenBao服务器是否能访问到数据库服务器。
3. 检查数据库引擎的角色（Role）配置中的creation_statementsSQL语法是否正确，以及是否在正确的数据库上执行。

问题4：应用程序Token频繁过期。原因与解决：应用的Token TTL设置太短，且应用没有正确实现续租逻辑。确保应用使用了支持自动续租的客户端库，或者定期调用vault token renew。对于AppRole，可以考虑适当增加角色的token_ttl，但需平衡安全性与便利性。

问题5：Raft集群节点失联，出现脑裂风险。原因与解决：网络分区导致。OpenBao Raft集群通常需要奇数个节点（如3或5）来容忍故障。如果少数节点失联，集群仍可工作。如果出现网络分区，可能会产生两个“大多数”。此时需要人工介入，根据Raft日志判断哪个分区拥有最新的数据，然后以该分区为主，重新将其他节点以follower身份加入。预防胜于治疗：确保集群节点间网络稳定，并正确配置cluster_addr。

7. 从开源到企业：生态与进阶考量

OpenBao作为开源项目，覆盖了大部分核心需求。但在超大规模或需要更严格合规性的场景下，你可能需要考虑其企业版特性或周边生态。

企业版特性（如命名空间、监控增强、HSM自动解封、复制等）提供了更强的多租户、可观测性和可靠性支持。如果你的组织有明确的部门隔离需求或全球部署需求，值得评估。

周边生态集成：

• 与Kubernetes的深度集成：除了前面提到的Sidecar模式，OpenBao可以通过CSI（Container Storage Interface）Provider将秘密直接注入为Pod内的卷文件，这是目前K8s社区更推崇的、更云原生的方式。
• 与配置管理工具结合：如Ansible的community.hashi_vaultlookup插件，Terraform的vaultprovider，可以在基础设施即代码中安全地引用秘密。
• 密钥轮换自动化：对于存储在KV引擎中的静态秘密，可以结合OpenBao的Transit引擎（用于加密即服务）和定时任务（如Cron Job），定期自动轮换密钥并重新加密数据。

最后，我想分享一点个人体会：引入OpenBao这样的秘密管理工具，不仅仅是一个技术决策，更是一个文化和流程变革的起点。它迫使团队思考秘密的生命周期、权限的边界和安全的自动化。初期可能会觉得增加了复杂度，但一旦流程跑顺，它会成为整个基础设施中不可或缺的、令人安心的一环。安全不是某个阶段的功能，而是贯穿整个开发和运维过程的基石，OpenBao正是帮你夯实这块基石的优秀工具之一。开始可能只用于管理数据库密码，慢慢你会发现，TLS证书、云服务密钥、API Token，甚至应用特性开关，都可以交给它来统一管理，最终构建起一个真正意义上的安全机密管理中心。