你在晚上发布一个版本，快速浏览你的警报，注意到一个从私有仓库中泄露的凭证。也许这是一个数据库密码，也许是一个拥有更广泛权限的云访问密钥。无论如何，问题不仅仅是有人可以登录。问题是数据库安全被认为是一个登录问题，而实际上它是一个存储生命周期问题。
这在现实系统中表现得非常普遍。团队在一次性加密后就认为他们完成了。他们保留备份，但从未测试恢复。他们为方便而创建一个管理员服务帐户，然后忘记它存在。他们锁定生产环境，然后将复制的客户端数据留在测试环境中。如果你正在构建移动或web应用，安全数据库存储必须涵盖所有内容：主数据库、副本、导出、日志、备份和控制整个系统的密钥。
如果你也正在解决 为你的下一个应用解决认证问题，记住认证和存储安全解决不同的故障模式。认证决定谁应该进入。存储安全限制了当有人进入时或数据通过你没有预期的路径泄露时的损害。对于正在推送客户端应用的团队，存储决策也应该与邻近的控制如 API 应用商店遵守的安全标准.
的对齐值得考虑。 全球数据生产量在2020年达到64.2亿亿字节，预计到2025年将攀升到180亿亿字节 根据 Edge Delta的数据存储总结. 在这种规模下，安全存储不再是一种硬化任务，而是一种架构
目录
数据库安全性不仅仅是密码问题
密码保护了入口点，但一旦凭据泄露、快照被复制或内部服务读取了它不应该访问的表格时，数据就不再受到保护。因此，安全的数据库存储必须是层次化的。
旧的思维模式很简单：将数据库放在防火墙后面，要求强密码，阻止外部人士接触。这种模式在云系统、移动后端和现代CI/CD管道中都已经破产了。数据在服务之间移动，工程师创建临时导出，分析作业复制记录，备份系统在不同基础设施上存储副本。攻击者不需要破坏数据库引擎本身，只要他们可以窃取密钥、滥用API令牌或找到控制较弱的副本就行。
安全性在平静的路径上失败
最具破坏性的存储失败看起来并不夸张。
- 开发者便利性变成了生产风险： 脚本重复使用了共享管理员凭据，因为旋转它会破坏部署。
- 复制的数据逃避了管辖： 生产记录被克隆到测试环境，以便QA可以重现一个错误。
- 备份成为弱点： 生产有强大的控制，但恢复桶或快照策略没有。
实用规则： 如果攻击者只需要一个凭证就能读取数据，那么你并不具备安全存储。你的系统中存在一个单点故障。
防御必须能够抵御凭证滥用
微软的云指导建议包括在传输和休眠时进行加密、最小权限访问控制和监控未经授权活动等，详见其 云数据安全最佳实践。
实践中有效的方法是乏味而一致的。加密数据库文件。加密连接。分离服务角色。去除可以的管理员访问权限。记录敏感操作。对不符合正常使用模式的访问模式发出警报。这些措施并不是引人注目的，但它们可以防止真正的泄露。
一个有用的方法是将其视为物理保险箱。保险箱门很重要。同样重要的是隔间锁、摄像头录像、访客登记册和可以打开哪个盒子的政策。安全数据库存储与之类似。密码只是门口。
了解您的数据库威胁模型
在选择控制之前，需要绘制系统可能失败的方式。数据库存储的威胁模型不需要是学术性的。它需要告诉你谁可能触摸敏感数据、他们如何做到这一点以及如果他们成功了会发生什么。
敏感数据通常不仅仅存在于一个整洁的生产数据库中。现代指导强调发现和姿势管理，因为敏感信息经常会出现在副本、备份、日志和开发环境中，因此失败通常发生在主要数据库之外，正如在 Sentra 云数据安全和姿势管理概述中所提到的。因此，应将事件规划纳入供应商暴露和拷贝数据集的场景。这种情况下，广泛的应对手册，如 第三方违规应对最佳实践也变得相关。
从资产开始，而不是工具
列出重要的资产之前不要列出产品。
对于大多数应用团队来说，关键资产是明确的：
- 客户记录 例如
- 用户资料 如密码散列、会话记录、刷新令牌或API机密。
- 运营数据 例如审计日志、作业队列、管理员笔记和支持导出。
- 恢复资产 例如快照、逻辑备份、点时间日志和加密密钥。
That last item matters more than teams think. If an attacker can delete backups or access the keys that decrypt them, your recovery story collapses.
最关键的那一项，团队往往低估了它的重要性。如果攻击者能够删除备份或访问解密它们的密钥，恢复计划就会崩溃。
The three threat buckets that matter most
一个简单的模型
This is the bucket everyone thinks about first. SQL injection, stolen API tokens, leaked cloud credentials, exposed admin panels, vulnerable dependencies. The common thread is an outsider getting a path to data.
开发人员使用的简单模型有三个桶。
- External attackers
- 这是每个人都首先想到的桶。SQL注入、盗取__CAPGO_KEEP_0__令牌、泄露云凭证、暴露的管理员面板和脆弱的依赖项。共同的线索是外部攻击者获取数据的途径。
- 复制快照是否可独立阅读?
内部威胁
这包括恶意内部人员和过度权限的员工。支持工程师导出数据解决票据。承包商保留本地副本。平台管理员可以读取生产行，即使他们的工作不需要。
帮助这里的是职责分离、基于角色的访问和可见的敏感读取的审计记录。
如果您无法回答谁访问了客户记录、什么时候访问了它以及允许这种访问的原因，那么您的数据库控制措施就比它们看起来弱。
意外泄露
这是快速移动团队中最常见的类别。配置错误的存储桶。预发布环境中包含活跃数据的环境。包含令牌或个人信息的调试日志。用于故障排除的恢复备份放在低安全环境中。
意外泄露是为什么强大的存储安全必须是运作状态的原因。您不能用一个设置来解决它。您需要用数据分类、防护栏、审查和定期清理来解决它。
安全数据库存储的核心支柱
一次性失败很少会导致漏洞。它通常来自一系列普通的错误。备份被复制到错误的帐户。服务获得比它需要的更广泛的权限。旧密钥在几个月内保持活动状态，因为轮换一直被推迟。安全数据库存储必须在系统变化时在几个点上打断链条，并继续这样做。
我将工作分为四个支柱：加密、访问控制、审计和最小化。备份和恢复也很重要，但它们 deserve 自己的运营处理，因为恢复的数据通常会成为一个新的暴露路径，如果没有测试它落在哪里、谁可以读它以及哪些密钥可以解密它。
加密降低了盗窃数据的价值
加密可以购买时间并降低影响。如果有人获得磁盘快照、原始备份文件或内部网络流量，加密数据要难以转换为客户记录。
在休眠状态下，加密保护数据库文件、快照和备份艺术品。在传输过程中，TLS 保护应用程序服务器、代理和数据库引擎之间的连接。NIST 在其关于存储加密和传输保护的指南中处理了这两个控制，SP 800-111 和相关的数据在休眠状态下的建议 SP 800-111 和相关的数据在休眠状态下的建议.
加密的权衡是运营的，而不是理论的。加密只有在密钥处理与数据路径分离并在时间内维护时才有帮助。Envelope 加密就像建筑师的主钥匙和锁上的办公室钥匙一样工作。密钥管理服务保护主钥匙，而主钥匙加密短暂的数据密钥用于实际记录或文件。这种设计限制了暴露在旋转期间，并且更容易撤销或替换密钥材料而不需要一次性重写所有内容。
团队会遇到麻烦，因为他们只启用了加密一次并停止了。检查密钥的存放位置、谁可以使用它们、是否有定期轮换以及是否有依赖于被遗忘的密钥版本的旧备份。
访问控制限制了爆炸半径
权限应该遵循应用程序边界，而不是组织结构图。
一个checkoutAPI的数据库角色不应该能够读取工资数据。一个后台工作程序不应该具有修改模式的权限，因为它在早期迁移期间很方便。支持工具应该使用过滤视图或批准的程序，而不是广泛的表访问。
一个实用的模型看起来像这样：
- Web应用角色： 对用户请求后面的表格有限的读取和写入访问。
- 工作程序角色： 对它运行的作业所需的记录的访问。
- 分析角色： 对经过精心编辑以去除直接标识符的数据集的只读访问。
- 突破玻璃管理员角色： 短期有效、审批通过的访问权限，具有强大的日志记录和审查功能。
当数据转换与之配对时，这个支柱会变得更强大。如果团队可以使用掩码或减少的数据完成工作，请为其提供该版本，而不是使用完整的生产值。对于受管制的健康数据来说， 脱敏化PHI 通常是有用访问和不必要暴露之间的区别。
数据库中的机密信息应受到同样的纪律。那些仅仅加强存储控制，但将机器凭据散布在CI日志、移动构建或支持脚本中的团队仍然留下了广泛的攻击路径。同样的运营习惯适用于 API应用商店合规的密钥安全
，尤其是在移动应用和后端服务共享信任边界时。
审计显示控制是否真实存在
无法验证的政策只是希望。
通常有用的审计覆盖范围包括：
- 有用的审计覆盖通常包括： 成功登录、失败登录、令牌使用和管理会话。
- 授权变更： 授权、取消授权、角色创建、策略编辑和模式变更。
- 敏感访问模式： 批量读取、大规模导出、异常查询路径和超出预期时间或来源网络的访问。
- 密钥管理事件： 密钥创建、旋转、解密失败尝试、禁用版本和KMS或秘密存储中的策略变更。
保留期和审查很重要。如果日志在任何人调查之前过期，或者只有在发生漏洞时才会检查权限变更，那么审计系统就存在于纸上而不是实践中。
在实现细节变得过于抽象之前，先看看这个解释：
敏感数据最好不存放在无法有效防御的地方
最小化是许多团队在不花费太多工程精力就能获得的最大安全胜利。
存储的数据越少，保留的时间越短，复制的位置越少。如果一个功能只需要年龄范围，不要存储完整的出生日期。如果支持只需要身份验证器的最后四位数字，不要暴露完整的字段。如果测试环境不需要真实个人数据，不要将生产备份恢复到它们并称之为临时环境。
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 Capacitor apps, @capgo/capacitor-数据库存储-SQLite 和 @capgo/capacitor-快速SQL 可以提供加密的应用侧持久性，但您仍然需要决定什么不应该在本地存储
The point of these pillars is not perfection on day one. It is building a storage system that stays defensible after key rotations, staff changes, incident response, backup restores, and product growth. That is where secure database storage usually succeeds or fails.
加密实践指南
There isn’t one encryption pattern for every system. The right choice depends on what you’re protecting, who needs to query it, and how much complexity your team can support. The mistake is picking the strongest sounding pattern and then implementing it badly.
一个图表，展示了三种加密实践：磁盘、数据库透明数据和应用级加密
TDE 是最快的基准透明数据加密（TDE）通常是最容易开始的。数据库引擎会在磁盘上加密文件，并在引擎读取它们时解密它们。应用程序通常不需要任何 code 的更改。
本文是关于：
- 整库保护
- 存储级别的合规要求
- 防止被盗的磁盘、快照或原始文件访问
TDE并不能保护所有内容。如果攻击者获得了有效的数据库访问权限，引擎仍会提供解密的数据。因此，TDE有助于存储安全性，而不是合法凭证的滥用。
应用级别的加密保护最重要的字段
应用级别的加密发生在数据到达数据库之前。您的code会对选定的字段进行加密，然后将密文写入存储中。这对于敏感的列，例如政府身份证、银行信息、恢复密钥或私人笔记等，效果很好。
这种额外的控制权带来了权衡：
- 您需要承担更多的复杂性： 密钥选择、加密库、密钥轮换行为和错误处理。
- 查询变得更加困难： 精确匹配、部分搜索和索引设计成为设计问题。
- 开发者需要自律: 一个脚本迁移的捷径可以绕过整个模型。
一个简单的伪代码模式如下:
| 步骤 | 动作 |
|---|---|
| 1 | 从请求中读取明文字段 |
| 2 | 向密钥服务索取数据加密密钥或使用一个包装的本地密钥 |
| 3 | 加密应用中的字段 |
| 4 | 在应用中加密字段 |
| 5 | 在数据库中存储密文和元数据 |
仅在批准的读取路径中解密 secure storage for offline tokens in Capacitor.
加密的加密是一种安全的保险箱
加密的加密听起来很吓人，但这个想法很简单。您使用一个密钥对数据进行加密，然后使用另一个更好地保护的密钥对该密钥进行加密。
想象一下，这个文件被锁在一个小保险箱里。那个小保险箱的钥匙被锁在一个银行保险箱里。如果有人偷走了文件存储层，他们仍然需要访问更高保护的保险箱钥匙才能打开任何有用的东西。
典型流程：
- 为记录、文件或批次生成数据密钥 使用该数据密钥对数据进行加密
- 使用 KMS 或 HSM 中的主密钥将数据密钥进行包装 存储加密数据和包装密钥的元数据
- 与记录或对象一起存储 __CAPGO_KEEP_0__
- __CAPGO_KEEP_1__ __CAPGO_KEEP_2__
- 只在授权读取期间解包.
Field建议： 使用封装加密，当您需要在不暴露长期主密钥给每个应用服务器的情况下实现强隔离时。
这种模式很常见，因为它平衡了性能和控制。应用程序使用短期数据密钥进行实际加密工作，而KMS或HSM保护用于封装和解包它们的主密钥。
加密模式比较
| 模式 | 实现复杂度 | 性能影响 | 最佳选择 |
|---|---|---|---|
| 磁盘或卷加密 | 低 | 低 | 基础设施级保护服务器和附加存储 |
| 透明数据加密 | 低至中等 | 低至中等 | 整体数据库保护最小化应用程序更改 |
| 应用程序级加密 | 中等至高 | 根据字段使用和查询设计而异 | 高度敏感的列和严格分离需要 |
| 信封加密 | 中等至高 | 中等 | 需要更强的密钥隔离和可扩展密钥控制的系统 |
实践规则很简单。从一个强大的基线开始，如TDE或管理的静止加密。只在数据敏感性和威胁模型要求额外的工程时，才添加字段级或信封加密。
掌握密钥和机密管理
通常，漏洞始于普通的机密处理错误。生产数据库加密，备份存在，访问看起来在纸上控制。然后，CI任务将令牌打印到日志中，工程师重用管理员凭据用于支持脚本，或者过时的密钥在团队创建它后仍然保持活动状态。
这就是为什么密钥和机密管理是运营实践，而不是设置任务。
使用不当处理的密钥加密的数据库，就像锁定的服务器房间一样，门牌卡挂在门把手上。政府指南也提出了同样的观点。仅凭加密就无法填补差距，如果团队忽略KMS或HSM基于的密钥管理、最少特权访问和恢复计划，就像《NSA和合作伙伴关于保护云数据的指南》中描述的那样。 团队哪里出了问题.
事件回顾中熟悉的模式是:
源代码中的机密：
- 源代码中的机密：code 复制的配置文件中的机密：
- 复制的配置文件中的机密： 文件在笔记本之间传递、存储在共享文件夹中，或者在紧急修复期间提交。
- 环境变量：控制较弱： 方便，但经常通过构建日志、shell历史、崩溃报告或广泛的运行时权限暴露。
- 无归属权： 密钥存在多年，因为没有团队负责重新发行、发布和回滚计划。
- 共享高特权密钥： 应用程序、工程师和自动化使用同一凭证，这使审计和隔离变得更加困难。
如果您正在标准化应用程序和基础设施密钥的存储方式，了解处理 安全环境变量 的实用指南可以帮助团队远离随意的密钥扩散。
什么是好的密钥管理？
使用 KMS 当风险、合规要求或签名和密钥保护规则要求专用硬件边界时，使用一个 HSM 防止实际事件的控制措施是运营的：
按您可以安全执行的时间表轮换密钥：
轮换减少了一个被破坏的密钥的有用寿命，但只有当应用程序、作业和还原工作正常工作时才会发生。
- 分离职责： 读取客户数据的服务不应也能更改密钥策略或禁用日志。
- 记录敏感密钥事件： 密钥创建、轮换、解密请求、失败的访问尝试和策略更改应都可见。
- KMS HSM
- 测试重新加密路径： 旋转一个包装密钥通常比重新加密应用程序数据更容易，但两者都需要运行书和回滚步骤。
- 禁用并退役旧密钥： 留出切换时间，然后删除过期凭证，以防止它们成为静默后门。
CI/CD deserves the same discipline as production runtime. Build systems often have broad access and weak visibility, which makes them a common place for secret leakage. Teams that are serious about this usually formalize 管理 CI/CD pipeline 中的密钥 而不是将管道凭证视为临时例外。
One rule is simple. Application code should request cryptographic operations from trusted systems, not carry raw master keys around the environment.
强大的加密设计在堆栈中停止发挥作用，一旦开发人员、管道或支持工具将主密钥复制到错误的位置，就会失效。
设计一个可靠的备份和恢复策略
备份是安全数据库存储的一部分，而不是单独的管理员任务。如果生产环境受到保护，而备份却没有，那么攻击者会选择更容易的路径。
独立存储指南建议将备份和恢复系统保护到与生产环境相同的保护级别，因为勒索软件和恶意软件事件通常会留下安全、测试过的备份作为唯一可行的恢复路径。 Hypertec的安全数据存储指南.
备份需要自己的安全边界
一个可靠的备份设计具有以下几个特性:
- 备份在传输和休眠状态下都被加密。
- 备份凭证与生产凭证分开。
- 删除和保留控制比正常应用访问更难被滥用。
- 恢复目标不会变成弱控制的影子生产环境。
一个常见的故障模式是存储加密的备份，同时允许同样的受损生产角色删除它们。另一个是恢复到一个临时环境中，具有广泛的工程师访问权限并且没有日志记录。恢复路径应受到同样严格的审查如主要路径。
恢复测试才是真正的控制
一个未经测试的备份只是希望的存储
能够恢复得好的团队不仅仅是验证备份作业完成的。他们证明了恢复工作正常，恢复的数据是可用的，解密密钥、连接设置和依赖服务都在需要时齐全。
一个实际的恢复计划包括:
- 常规恢复练习 在隔离环境中进行
- 应用程序功能的验证 数据库恢复后，仅恢复文件并不是
- 检查关键项的可用性 以便加密备份可以解密
- 恢复系统的访问审查 防止敏感数据在事故期间变得过于明显
备份并不能救你。成功的恢复才是救命的
如果你只测试备份创建，并且从未在压力下测试恢复，那么你并没有验证你的恢复策略。你只是验证了文件可以在某个地方积累
安全数据库存储的开发者清单
这是我希望团队在设计审查、发布审查和事故后清理中使用的清单
设计
- 我们是否已经明确标识了敏感字段: 个人数据、认证材料、财务记录以及受保留规则的任何内容。
- 我们是否已经决定不存储什么: 功能不需要的字段，以及下游团队可以避免的副本。
- 我们是否已经映射了数据将存活的地方: 生产环境、测试环境、日志、导出、分析系统、备份和客户端设备。
实施
- 数据是否在存储和传输过程中进行了加密: 数据库、副本和备份路径。
- 应用程序和服务角色是否被严格限定: 无共享超级用户的正常应用流量。
- 是否将机密和加密密钥处理在code之外并且松散的配置: 是否使用受控访问和可审计的方式处理:
- 是否在敏感访问和权限变更时记录: 是否在中央位置记录防御者可以查询的日志:
运维
- 是否将密钥轮换和机密审查作为正常运维的一部分: 是否不需要每年一次的混乱:
- 是否定期测试恢复: 包括解密、应用启动和恢复系统的访问审查。
- 是否持续监测数据扩散: 包括测试环境副本、支持导出、开发数据集和遗忘的备份位置。
安全数据库存储不是一个项目阶段，而是一种持续的实践。
常见问题
是否足够的云服务商默认加密
它是一个强大的基线，但不是一个完整的策略。默认加密可以保护存储介质和托管服务，但它不能解决过度授权访问、复制数据集、弱备份控制或 poor key governance
是否会让数据库性能受损
有时是的。影响取决于模式。基础设施和数据库级别的加密通常具有更少的应用复杂性。字段级别的加密可以为选择的数据提供更强的控制，但会使索引、过滤和搜索变得复杂。请在您的工作负载上进行测量，然后进行广泛的推广
SQL 和 NoSQL 系统是否有所不同
原则保持不变。您仍然需要加密、最小权限、审计、密钥管理和测试恢复。实现细节会因为文档存储、键值存储和关系系统暴露的访问模型和查询行为而有所不同
tokenization与加密的区别在哪里
加密将数据转换为授权系统可以使用正确密钥解密的数据。tokenization 替换敏感值为替代值并将原始数据分离。tokenization 可以在应用工作流中减少暴露，但会增加系统设计复杂性，并且不能消除强大的存储控制的需求
Capgo 帮助团队快速将修复推送到 Capacitor 和 Electron 应用程序中，带有签名的 Web 包传递、发布控制、回滚保护和发布可观察性。如果您的应急响应计划依赖于在存储、身份验证或 API 错误后快速推送客户端修复，那么 Capgo 值得评估作为恢复的运营侧面。 Capgo __CAPGO_KEEP_0__ 是值得评估的恢复的运营侧面。
