Secure Database Storage: A Complete Guide for Developers

当您晚上推送一个发布，快速浏览您的警报时，您可能会注意到从私有仓库中泄露的凭证。可能是数据库密码。可能是具有更广泛权限的云访问密钥。无论如何，问题不仅仅是有人可以登录。问题是数据库安全性仍然被视为登录问题，而不是存储生命周期问题。

这在现实系统中处处体现。团队一次启用加密，认为他们完成了。他们保留备份，但从未测试恢复。他们为方便创建了一个管理员服务帐户，忘记了它存在。他们锁定生产环境，然后将复制的客户端数据留在测试环境中。如果您正在构建移动或 web 应用，安全数据库存储必须涵盖所有内容：主数据库、副本、导出、日志、备份和控制整个系统的密钥。

如果你也在 解决下一个应用程序的认证，请记住，认证和存储安全解决不同的故障模式。认证决定谁应该进入。存储安全限制了当有人进入时或数据通过您没有预期的路径泄露时的损害。对于正在运营面向客户的应用程序的团队来说，存储决策也值得与邻近的控制如 API 应用商店合规性安全标准.

同步。紧迫性不是理论上的。 全球数据生产量在2020年达到64.2 zettabytes，并预计到2025年将攀升到180 zettabytes ，根据 Edge Delta的数据存储摘要。在这种规模下，安全存储不再是一种加固任务，而是成为架构。

目录

• 为什么数据库安全性比仅仅使用密码更重要
  • 安全性在静默路径中失败
  • 防御必须要能抵抗凭证滥用的攻击
• 了解您的数据库威胁模型
  • 从资产开始，而不是工具
  • 影响最大的三大威胁类别
• 安全数据库存储的核心支柱
  • 加密会降低被盗数据的价值
  • 访问控制会限制爆发半径
  • 审计会显示控制是否真实存在
  • 敏化会将敏感数据从无法有效防御的位置中排除
• 加密的实践实施模式
  • TDE 是最快的基线
  • 应用级别的加密会保护最重要的字段
  • __CAPGO_KEEP_0__是一种安全在安全之中的方法
  • 加密模式比较
• 掌握密钥和秘密管理
  • 团队在这里犯错误的地方
  • 好的密钥管理是什么样的
• 设计一个可靠的备份和恢复策略
  • 备份需要自己的安全边界
  • 恢复测试才是真正的控制
• 数据库安全存储的开发者检查清单
  • 设计
  • 实施
  • 运维
• ["Frequently Asked Questions"]
  • ["Is cloud-provider default encryption good enough"]
  • ["Does encryption hurt database performance"]
  • ["Is this different for SQL and NoSQL systems"]
  • ["How is tokenization different from encryption"]

["Why Database Security Is More Than Just a Password"]

["A password protects an entry point. It doesn’t protect the data after a credential leaks, a snapshot gets copied, or an overprivileged internal service starts reading tables it was never meant to touch. That’s why secure database storage has to be layered."]

["The old mental model was simple: put the database behind a firewall, require a strong password, and keep outsiders away. That model breaks in cloud systems, mobile backends, and modern CI/CD pipelines. Data moves between services. Engineers create temporary exports. Analytics jobs duplicate records. Backup systems store copies on different infrastructure. Attackers don’t have to break the database engine itself if they can steal a key, abuse an API token, or find a replica with weaker controls."]

["Security fails in the quiet paths"]

["Most damaging storage failures don’t look dramatic at first. They look ordinary."]

• ["A developer convenience becomes production risk:"] ["A shared admin credential gets reused by a script because rotating it would break deployment."]
• A copied dataset escapes governance: 生产环境记录被克隆到测试环境，以便QA可以重现一个bug.
• A backup becomes the weak point: 生产环境有强大的控制，但恢复存储桶或快照策略不够.

Practical rule: 如果攻击者只需要一个凭证就能读取数据，那么你没有安全存储，你有一个单点故障.

Defense has to survive credential abuse

Microsoft的云指导建议包括在传输和休眠时进行加密、最小特权访问控制和监控未经授权活动的基线，正如其 云数据安全最佳实践. 实际事件经常从合法访问中开始，使用方式不当.

What works in practice is boring and consistent. Encrypt the database files. Encrypt connections. Split service roles. Remove standing admin access where you can. Log sensitive operations. Alert on access patterns that don’t fit normal use. None of that is glamorous, but it prevents real breaches.

一个有用的思考方式是物理保险箱。保险箱门很重要。同样重要的是隔间锁、摄像头录像、访客登记册和可以打开哪个盒子的政策。安全数据库存储与之类似。密码只是门口。

{"targetLanguage":"Simplified Chinese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["了解您的数据库威胁模型","在选择控制之前，映射系统可能会失败的方式。数据库存储的威胁模型不需要是学术性的。它需要告诉您谁可能触摸敏感数据，如何触摸它们，以及如果他们成功了会发生什么。","一个五步流程图，展示了构建数据安全的全面数据库威胁模型的过程。","敏感数据很少生活在一个整洁的生产数据库中。现代指导强调发现和姿势管理，因为敏感信息经常会在备份、日志和开发环境中复制，所以失败通常发生在主要数据库之外，正如","Sentra 云数据安全和姿势管理概述"中提到的那样。","因此，应急计划应该包括供应商暴露和复制数据集的场景。这也是更广泛的响应手册，例如","第三方违约响应最佳实践"，变得相关。","从资产开始，而不是工具"，"列出重要的资产之前不要列出产品。"

对于大多数应用团队来说，关键资产是明确的："客户记录"

" "" ""

"

"

"

1. " 例如：用户资料、订单历史、支付相关元数据或健康相关内容。
2. 身份验证材料 例如：密码散列值、会话记录、刷新令牌或API密钥。
3. 运营数据 例如：审计日志、作业队列、管理员笔记和支持导出。
4. 恢复资产 例如：快照、逻辑备份、点时刻日志和加密密钥。

最后一项比团队想象的更重要。如果攻击者可以删除备份或访问解密它们的密钥，恢复故事就会崩溃。

最关心的三大威胁类别

我使用开发人员的简单模型有三个类别。

外部攻击者

这是每个人首先想到的类别。SQL注入、盗取API令牌、泄露云凭证、暴露的管理员面板和脆弱的依赖项。共同的线索是外部攻击者获取数据的途径。

需要询问的问题：

• 是否可以通过应用程序间接查询数据库？
• 是否可以通过盗取服务器凭证读取多个服务所需的内容？
• 是否可以在不依赖原始数据的情况下复制快照？

内部威胁

这包括恶意内部人员和过度访问的善意员工。支持工程师导出数据以解决票据。承包商保留本地副本。平台管理员可以读取生产行，即使他们的工作不需要。

帮助这里的是职责分离、基于角色的访问和可见的敏感读取的审计跟踪。

如果您无法回答客户记录被访问者是谁、何时访问以及允许访问的原因，那么您的数据库控制措施就比它们看起来弱。

意外泄露

这是快速移动团队中最常见的类别。配置不当的存储桶。预发布环境中包含活跃数据的环境。包含令牌或个人信息的调试日志。用于故障排除的恢复备份放置在低安全环境中。

意外泄露是为什么强大的存储安全必须是运营化的。您不能用一个设置来解决它。您解决它的是数据分类、防护栏、审查和定期清理。

安全数据库存储的核心支柱

A breach rarely comes from one dramatic failure. It usually comes from a chain of ordinary mistakes. A backup is copied to the wrong account. A service gets broader permissions than it needs. An old key stays active for months because rotation kept getting postponed. Secure database storage has to interrupt that chain at several points, and keep doing it as the system changes.

我将工作分为四个支柱：加密、访问控制、审计和最小化。备份和恢复也很重要，但它们 deserve 他们自己的运营处理，因为恢复的数据通常成为一个新的暴露路径，如果没有人测试它落在哪里、谁可以读取它以及哪些密钥可以解密它。

加密降低了盗窃数据的价值

加密可以购买时间并降低影响。如果有人获得了磁盘快照、原始备份文件或内部网络上的流量， 加密数据要比普通数据难以转化为客户记录。

在休眠状态下， 加密保护了数据库文件、快照和备份 artifact。在传输过程中， TLS 保护了应用程序服务器、代理和数据库引擎之间的连接。 NIST 在其关于存储加密和传输保护的指南中处理了这两个控制，SP 800-111 和相关的数据在休眠状态下的建议 SP 800-111 and related data-at-rest recommendations.

The trade-off is operational, not theoretical. Encryption only helps if key handling is separate from the data path and maintained over time. Envelope encryption works like a building master key and a locked office key. A key management service protects the master key, and that master key encrypts short-lived data keys used for actual records or files. That design limits exposure during rotation and makes it easier to revoke or replace key material without rewriting everything at once.

团队会遇到麻烦，因为他们只启用了加密功能并停止了那里。检查密钥的存放位置、谁可以使用它们、是否有定期轮换计划以及旧备份是否依赖于被遗忘的密钥版本。

访问控制限制了爆炸半径

权限应该遵循应用程序边界，而不是组织结构图。

一个checkout API 的数据库角色不应该能够读取工资数据。一个后台工作程序不应该具有修改数据库架构的权利，因为早期迁移时它很方便。支持工具应该使用过滤视图或批准程序代替对表格的广泛访问。

一个实际模型看起来像这样：

• Web 应用程序角色： 对用户请求后面的表格有有限的读写访问权。
• 工作程序角色： 访问它运行的作业所需的记录。
• 分析角色： 对已清洗的数据集有只读访问权，尽可能去除直接标识符。
• {"targetLanguage":"Simplified Chinese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["","","","","","","","","",""],"translations":["","","","","","","","","",""],"result":["","","","","","","","","",""],"key":"translations"]} {"targetLanguage":"Simplified Chinese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["Break-glass admin role:","short-lived, approved access with strong logging and review.","This pillar gets stronger when paired with data transformation. If a team can do its work with masked or reduced data, give it that version instead of full production values. For regulated health data,","de-identification of PHI","is often the difference between useful access and unnecessary exposure.","Secrets around the database deserve the same discipline. Teams that tighten storage controls but leave machine credentials scattered across CI logs, mobile builds, or support scripts still leave a wide attack path. The same operational habits apply to","__CAPGO_KEEP_0__ key security for app store compliance",", especially when mobile apps and backend services share trust boundaries.","Auditing shows whether controls are real","A policy that cannot be verified is just a hope.","Audit trails answer the questions that matter during an incident. Which identity read the records. Which role changed permissions. Which export job moved data out. Which key was used to decrypt an archive. They also expose slow drift, like a service account that started touching tables it never needed before.","Useful audit coverage usually includes:"]}

targetLanguage:Simplified Chinese protectedTokens:Cloudflare,Capacitor,GitHub,Capgo,code,API,SDK,CLI,npm,bun texts:Break-glass admin role:,short-lived, approved access with strong logging and review.,This pillar gets stronger when paired with data transformation. If a team can do its work with masked or reduced data, give it that version instead of full production values. For regulated health data,,de-identification of PHI,is often the difference between useful access and unnecessary exposure.,Secrets around the database deserve the same discipline. Teams that tighten storage controls but leave machine credentials scattered across CI logs, mobile builds, or support scripts still leave a wide attack path. The same operational habits apply to,__CAPGO_KEEP_0__ key security for app store compliance,, especially when mobile apps and backend services share trust boundaries.,Auditing shows whether controls are real,A policy that cannot be verified is just a hope.,Audit trails answer the questions that matter during an incident. Which identity read the records. Which role changed permissions. Which export job moved data out. Which key was used to decrypt an archive. They also expose slow drift, like a service account that started touching tables it never needed before.,Useful audit coverage usually includes:

translations: API key security for app store compliancekey:translations

translations:["","","","","","","","","",""],"result:["","","","","","","","","",""],"key:translations

translations:["","","","","","","","","",""],"result:["","","","","","","","","",""],"key:translations

translations:["","","","","","","","","",""],"result:["","","","","","","","","",""],"key:translations

translations:["","","","","","","","","",""],"result:["","","","","","","","","",""],"key:translations

• targetLanguage":"Simplified Chinese" protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"]
• texts":["认证活动：","成功登录、失败登录、令牌使用和管理会话","授权变更：","授权、取消授权、角色创建、策略编辑和模式变更","敏感访问模式：","批量读取、巨量导出、异常查询路径和超出预期时间或来源网络的访问","密钥管理事件：","密钥创建、旋转、解密失败尝试、禁用版本和KMS或秘密存储中的策略变更","保留和审查很重要。如果日志在任何人调查之前过期，或者如果没有人查看权限变更，除非已经发生了安全漏洞，审计系统就只存在于纸上而不是实践中","在实现细节变得过于抽象之前，先看看这个解释：","敏感数据最好不要出现在无法有效防御的地方","敏感数据最好不要出现在无法有效防御的地方，很多团队在最少工程努力下获得的最大安全胜利就是这一点"]]} texts.0
• texts.1 texts.2
• texts.3 texts.4

texts.5

texts.6

texts.7

texts.8

减少存储。减少存留时间。将其复制到更少的位置。如果一个功能只需要年龄范围，不要存储完整的出生日期。如果支持只需要身份证件的最后四位数字，不要暴露完整的字段。如果测试环境不需要真实个人数据，不要将生产备份恢复到它们并称之为临时的。

This is also an operational discipline. Retention schedules need enforcement. Old exports need deletion. Downstream systems need review because risk grows every time sensitive fields are replicated into search indexes, caches, data lakes, mobile storage, and ad hoc CSV files. For example, tools such as Capgo’s SQLite-based storage plugin for Capacitor can provide app-side persistence, but you still need to decide what should never be stored locally at all.

这些柱子的目的不是在第一天就达到完美。它是建立一个存储系统，使其在密钥轮换、人员更替、应急响应、备份恢复和产品增长后仍然可防御。这就是安全数据库存储通常成功或失败的地方。

加密的实践实施模式

并没有一个加密模式适用于每个系统。正确的选择取决于您保护的是什么、谁需要查询它以及您的团队可以支持的复杂性程度。错误的是选择听起来最强大的模式，然后糟糕地实施它。

TDE 是最快的基线

透明数据加密或 TDE，通常是最容易开始的地方。数据库引擎在磁盘上加密文件，并在引擎读取它们时解密它们。应用程序通常不需要 code 的更改。

这是一个强大的基线：

• 数据库保护
• 存储级别的合规要求
• 从被盗的磁盘、快照或原始文件访问中减少风险

TDE 不保护所有内容。如果攻击者获得有效的数据库访问权限，引擎仍会提供解密的数据。因此，TDE 帮助解决存储性质的安全问题，而不是合法凭据的滥用。

应用级加密保护最重要的字段

应用级加密发生在数据到达数据库之前。您的 code 加密所选字段，然后将密文写入存储中。这在尤其敏感的列如政府身份证、银行详细信息、恢复密钥或私人笔记时非常有效。

这种额外的控制需要权衡：

• 您拥有的复杂性更大: 密钥选择、加密库、旋转行为和错误处理。
• 查询变得困难: 精确匹配、部分搜索和索引成为设计问题。
• 开发者需要自律: 在迁移脚本中的一条捷径可以绕过整个模型。

一个简单的伪代码模式看起来像这样:

对于本地应用程序持久性，同样的设计问题也适用。如果您在设备上存储离线令牌或敏感的同步状态，不要假设移动存储是安全的。使用像在__CAPGO_KEEP_0__中讨论的那样，针对平台的模式来存储离线令牌 secure storage for offline tokens in Capacitor.

信封加密听起来很吓人，但这个想法很简单。您用一个密钥加密数据，然后用另一个更好地保护的密钥加密该密钥

想象一下，文件被锁在一个小保险箱里。那个小保险箱的钥匙被锁在一个银行保险箱里。如果有人偷走文件存储层，他们仍然需要访问更高保护的保险箱钥匙才能打开任何有用的东西

典型流程：

生成数据密钥

1. 为记录、文件或批次生成数据密钥 使用该数据密钥加密数据
2. 使用该数据密钥加密数据 使用该数据密钥加密数据
3. Wrap the data key 使用 KMS 或 HSM 中的主密钥
4. Store ciphertext plus wrapped key metadata 与记录或对象一起存储加密文本和包裹密钥元数据
5. Unwrap only during authorized reads.

Field advice: 在不暴露长期主密钥给每个应用服务器的情况下，使用强隔离 compartmentalization 时，建议使用 envelope encryption。

此模式很常见，因为它平衡了性能和控制。应用程序使用短期数据密钥进行实际加密工作，而 KMS 或 HSM 保护用于包裹和解包的主密钥。

加密模式比较

translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]}

translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]}

translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]}

translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]}

translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]} translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]}.

translations":["高度敏感的列和严格的分离需求","信封加密","中等到高","中等","需要更强的密钥隔离和可扩展密钥控制的系统","实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型合理化时，只在字段级别或信封加密中添加。","掌握密钥和机密管理","通常是这样：一个普通的机密处理错误引发了一个漏洞。一个生产数据库是加密的，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持一个脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。","这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。","一个用不当处理密钥的数据库加密起来就像一个锁上的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。加密本身并不能关闭差距，如果团队跳过KMS或HSM基于的密钥管理，权限最低的访问和恢复计划，正如NSA和合作伙伴的指南中描述的那样","NSA和合作伙伴的指南","在哪里团队做错了"]}

The patterns are familiar in incident reviews:

• 源代码中的 code: 固定的凭证、嵌入的证书或逐渐成为生产依赖项的实用脚本。
• 复制的配置文件中的机密: 文件在笔记本之间传递、存储在共享文件夹中或在紧急修复期间提交。
• 环境变量的弱控制: 虽然方便，但经常通过构建日志、shell历史、崩溃报告或广泛的运行时权限暴露。
• 没有负责轮换的团队: 因为没有团队负责重新发行、发布和回滚计划，密钥存在了多年。
• 共享高权限的机密: 一个凭证被应用、工程师和自动化使用，这使得审计和隔离变得更加困难。

如果您正在标准化应用和基础设施机密的存储方式，处理机密的实用参考 secure environment variables 可以帮助团队远离不规则的机密信息泛滥.

What good key management looks like

使用一个 KMS 当集中化的政策、访问控制、审计日志和预定轮换比自定义硬件控制更重要时。使用一个 HSM 当风险、合规要求或签名和密钥保护规则要求专用硬件边界时。许多团队并不需要HSM在每个地方。他们需要明确的规则来确定哪些系统可以请求解密操作、哪些人类可以更改政策以及这些操作如何被审查。

Envelope encryption是一种好的思维模型。它的工作原理就像将现金放在一个小锁定的盒子里，然后将该盒子存放在银行保险箱里。应用程序处理短暂的数据密钥用于加密工作。保险箱密钥留在KMS或HSM中，访问它受到严格限制。

预防实际事件的控制措施是运营性的：

• 定期轮换密钥以安全执行： 轮换减少了一个被破坏的密钥的有用寿命，但只有当应用程序、作业和恢复仍然正常工作时才有效。
• 分离职责： 读取客户数据的服务不应也能改变密钥策略或禁用日志记录。
• 记录敏感密钥事件： 密钥创建、旋转、解密请求、访问失败和策略变更应全部可见。
• 测试重新加密路径： 旋转包装密钥通常比重新加密应用程序数据更容易，但两者都需要手册和回滚步骤。
• 故意禁用和退役旧秘密： 留出时间进行切换，然后移除过期凭证以防止它们成为静默后门。

CI/CD应遵守相同的纪律，如生产运行时环境。构建系统通常具有广泛的访问权限和弱的可见性，使其成为秘密泄露的常见地点。那些对此严肃的团队通常会正式化 在CI/CD管道中管理机密 而不是将管道凭证视为临时例外。

一个规则很简单。应用程序code应从受信任系统请求加密操作，而不是在环境中携带原始主密钥。

当开发者、管道或支持工具将主密钥复制到错误的位置时，无论您的栈中使用的加密设计有多强大，它都变得无关紧要。

设计一个可靠的备份和恢复策略

备份是安全数据库存储的一部分，而不是单独的管理任务。如果生产环境受到保护，而备份却不受保护，那么攻击者会选择更容易的路径。

独立存储指南建议将备份和恢复系统的保护级别与生产环境保持一致，因为勒索软件和恶意软件事件通常会将安全、测试的备份留作唯一可行的恢复路径，根据 Hypertec的安全数据存储指南.

备份需要自己的安全边界

可靠的备份设计具有以下几个特性：

• 备份在传输和休眠状态下都被加密。
• 备份凭证与生产凭证分开。
• 删除和保留控制比正常应用访问更难被滥用。
• 恢复目标不应成为弱控制的影子生产环境。

常见的故障模式是存储加密的备份，同时允许同样的受损生产角色删除它们。另一个是将恢复操作恢复到一个临时环境中，该环境具有广泛的工程师访问权限并且没有日志。恢复路径应受到同样严格的审查。

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

1. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
2. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
3. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__
4. __CAPGO_KEEP_0__ __CAPGO_KEEP_0__

备份并不能救你。成功的恢复才是救命稻草。

如果你只测试备份的创建，而不测试在压力下恢复，那么你并没有验证你的恢复策略。你验证了文件可以在某个地方累积。

安全数据库存储的开发者清单

这是我希望团队在设计审查、发布审查和后续事件清理中使用的清单。

设计

• 我们是否已经明确标识了敏感字段： 个人数据、认证材料、财务记录以及受保留规则的任何内容。
• 我们是否已经决定不存储什么： 功能不需要的字段，以及下游团队可以避免的副本。
• 我们是否已经绘制了数据将存活的地方的图： 生产环境、测试环境、日志、导出、分析系统、备份和客户端设备。

Implementation

• 数据是否在数据库、副本和备份路径中以加密形式存储和传输: for the database, replicas, and backup paths.
• 应用程序和服务角色是否严格限定: 没有用于正常应用程序流量的共享超级用户.
• Are secrets and encryption keys handled outside code and loose config: 秘密和加密密钥是否在__CAPGO_KEEP_0__和松散配置之外处理:
• 并且具有受控访问和可审计性. in a central place defenders can query.

是否在中央位置记录敏感访问和特权更改:

• 防御者可以查询. 运维团队是否将密钥轮换和秘密审查纳入正常运维流程:
• Do we regularly test system recovery: 包括恢复系统的解密、应用程序启动和访问审查。
• Do we continuously audit data sprawl: 包括暂存副本、支持导出、开发数据集和遗忘备份位置。

良好的安全数据库存储不是一个项目阶段。它是一个持续的惯例。

常见问题

云提供商的默认加密是否足够好

这是一个强大的基线，但不是一个完整的策略。默认加密可以帮助保护存储介质和托管服务，但它并不能解决过度授权访问、复制数据集、弱备份控制或差劣的密钥管理。

加密会损害数据库性能吗

有时是的。影响取决于模式。基础设施和数据库级加密通常具有较少的应用程序复杂性。字段级加密可以为选定的数据提供更强的控制，但会复杂化索引、过滤和搜索。

这是否与关系型数据库和 NoSQL 系统有所不同

原则保持不变。您仍然需要加密、最小权限、审计、密钥管理和测试恢复。实现细节会因为文档存储、键值存储和关系型系统暴露的访问模型和查询行为而有所不同。

How is tokenization different from encryption

加密将数据转换为授权系统可以使用正确密钥解密的数据。Tokenization则将敏感值替换为代理值，并将原始数据分离。Tokenization可以在应用程序工作流中减少暴露，但会增加系统设计复杂性，并且不需要强大的存储控制。

Capgo 帮助团队快速将修复推送到 Capacitor 和 Electron 应用程序中，具有签名 Web 包装交付、滚动控制、回滚保护和发布可观察性。如果您的应急响应计划依赖于在存储、身份验证或 API 错误后快速推送客户端修复， Capgo 值得评估作为恢复的运营侧面。