数据库安全存储：开发人员的完整指南
你在晚上发布一个版本，快速浏览你的警报，注意到一个从私有仓库中永远不应该离开的凭证。也许它是一个数据库密码。也许它是一个具有更广泛权限的云访问密钥。无论如何，问题不仅仅是有人可以登录。问题是数据库安全继续被视为一个登录问题，而实际上它是一个存储生命周期问题。
如果您正在为下一个应用程序解决身份验证问题 记住，身份验证和存储安全解决不同的故障模式。身份验证决定谁应该进入。存储安全限制了当有人进入时或数据通过您没有预期的路径泄露时的损害。对于正在开发客户端应用程序的团队来说，存储决策也值得与邻近的控制项如__CAPGO_KEEP_0__ 应用商店遵从性安全标准 API security standards for app store compliance.
根据 Edge Delta 的数据存储摘要 2020 年全球数据生产量达到 64.2 zettabytes，预计到 2025 年将攀升到 180 zettabytes 在这种规模下，安全存储不再是一种硬化任务，而是成为架构。目录
为什么数据库安全性比仅仅使用密码更重要
数据库安全性不仅仅是密码的问题
一个密码保护了入口点。它并不能保护数据在凭证泄露、快照被复制或内部服务被赋予过高权限后被读取的数据。因此，安全的数据库存储必须是层次化的。
旧的思维模式很简单：将数据库放在防火墙后面，要求强密码，并且阻止外部人士接入。这种模式在云系统、移动后端和现代 CI/CD pipeline 中会破裂。数据在服务之间移动。工程师创建临时导出。分析作业会复制记录。备份系统会在不同基础设施上存储副本。攻击者不需要破坏数据库引擎本身，只要他们可以窃取一个密钥、滥用一个API令牌或找到一个控制较弱的副本。
安全性在平静的路径中失败
最具破坏性的存储失败看起来并不夸张
- 开发者便利性变成了生产风险： 一个共享的管理员凭证被脚本重复使用，因为旋转它会破坏部署
- A复制的数据逃避了管控: 生产记录被克隆到测试环境，以便QA可以重现一个bug。
- A备份成为弱点: 生产环境有强大的控制，但恢复存储桶或快照策略却没有。
实践规则: 如果攻击者只需要一个凭证就能读取数据，那么你并不具备安全存储。你只是有一个单点故障。
防御必须能够抵抗凭证滥用
微软的云指导建议包括在传输和存储中进行加密、最小特权访问控制和监控未经授权活动等，详见其 云数据安全最佳实践。这种baseline是正确的，因为实际事件往往从合法访问中开始被滥用。
在实践中，什么是有效的就是平凡而一致的。加密数据库文件。加密连接。拆分服务角色。去除可以的管理员访问。记录敏感操作。对不符合正常使用模式的访问模式发送警报。这些措施都不是引人注目的，但它们可以防止真正的泄露。
一个有用的思考方式是物理保险箱。保险箱门很重要。同样重要的是隔间锁、摄像头录像、访客登记册和可以打开哪个盒子的政策。安全数据库存储与之类似。密码只是保险箱门。
了解您的数据库威胁模型
在选择控制措施之前，首先要了解系统可能出现的风险。数据库存储的威胁模型不需要是学术性的。它需要告诉您谁可能接触敏感数据、他们如何接触敏感数据以及如果他们成功了会发生什么。
敏感数据通常不仅仅存储在一个整洁的生产数据库中。现代指导强调发现和姿势管理，因为敏感信息经常会被复制到备份、日志和开发环境中，因此失败通常发生在主要数据库之外，如 Sentra 云数据安全和姿势管理概述中所述。因此，应包括供应商暴露和复制数据集等场景在事故规划中。这也是更广泛的响应手册，例如 第三方数据泄露应急响应最佳实践，变得相关。
从资产开始，而不是工具
列出重要的资产之前，先列出产品。
对于大多数应用团队来说，关键资产是明确的:
- 客户记录 例如个人资料、订单历史、支付相关元数据或健康相关内容。
- 身份验证材料 例如密码散列、会话记录、刷新令牌或API密钥。
- 运营数据 例如审计日志、作业队列、管理员笔记和支持导出。
- 恢复资产 例如快照、逻辑备份、点时间日志和加密密钥。
最后一个项目比团队想象的更重要。如果攻击者可以删除备份或访问解密它们的密钥，恢复故事就会崩溃。
最重要的三个威胁类别
我使用开发人员的简单模型有三个类别。
外部攻击者
这是每个人想象的第一个类别。SQL注入、盗取API令牌、泄露云凭证、暴露的管理员面板、脆弱的依赖项。共同的线索是外部攻击者获取数据路径。
Questions to ask:
- Could someone query the database indirectly through the app?
- Can a stolen server credential read more than one service needs?
- Would a copied snapshot be readable on its own?
Insider threats
This includes malicious insiders and well-meaning employees with too much access. A support engineer exports data to solve a ticket. A contractor keeps a local copy. A platform admin can read production rows even though their job doesn’t require it.
What helps here is separation of duties, role-based access, and audit trails that make sensitive reads visible.
If you can’t answer who accessed a customer record, when they accessed it, and why that access was allowed, your database controls are weaker than they look.
Accidental exposure
This is the most common category in fast-moving teams. A misconfigured storage bucket. A staging environment seeded with live data. Debug logs that include tokens or personal information. A restored backup placed in a low-security environment for troubleshooting.
Accidental exposure is why strong storage security has to be operational. You don’t solve it with one setting. You solve it with data classification, guardrails, review, and routine cleanup.
The Core Pillars of Secure Database Storage
A一次性的大失误很少会导致安全漏洞。通常是由一系列普通的错误造成的。备份被复制到错误的账户。服务获得了比它需要的更广泛的权限。一个老的密钥在几个月内保持活跃状态，因为轮换一直被推迟。安全数据库存储必须在几个点上打断这种链条，并且随着系统的变化继续这样做。
我将工作分为四个柱：加密、访问控制、审计和最小化。备份和恢复也很重要，但它们 deserve自己的运营处理，因为恢复的数据通常会成为一个新的暴露路径，如果没有人测试它落地的位置、谁可以读取它以及哪些密钥可以解密它。
加密降低了盗窃数据的价值
加密可以购买时间并降低影响。如果有人获得了磁盘快照、原始备份文件或内部网络上的流量， 加密数据要比普通数据更难转化为客户记录。
在休眠状态下，加密保护了数据库文件、快照和备份艺术品。在传输过程中，TLS保护了应用程序服务器、代理和数据库引擎之间的连接。NIST在其关于存储加密和传输保护的指南中处理了这两个控制，指南是SP 800-111和相关的数据在休眠状态下的建议 SP 800-111和相关的数据在休眠状态下的建议.
安全存储数据库的权衡是实践的，而不是理论的。加密只有在密钥管理与数据路径分离并在时间维度上维持时才会有所帮助。信封加密的工作方式类似于建筑师的主钥匙和锁上的办公室钥匙。密钥管理服务保护主钥匙，而该主钥匙加密用于实际记录或文件的短期数据密钥。这种设计在轮换期间限制了暴露，并使得更容易在一次重写中撤销或替换密钥材料。
团队会陷入麻烦，因为他们只启用了加密一次并就此打住了。检查密钥的存放位置、谁可以使用它们、是否有定期轮换计划以及是否有依赖于被遗忘的密钥版本的旧备份。
访问控制限制了爆炸半径。
权限应该遵循应用程序边界，而不是组织结构图。
The database role for a checkout API should not be able to read payroll data. A background worker should not have schema-altering rights because it was convenient during an early migration. Support tooling should use filtered views or approved procedures instead of broad table access.
一个实际模型看起来像这样：
- Web应用程序角色： 对用户请求后面的表格有有限的读取和写入权限。
- 工作程序角色： 访问它运行的作业所需的记录。
- 分析角色： 对去除直接标识符的已筛选数据集有只读访问权。
- 安全数据库存储 突破玻璃管理员角色：
短期、审批通过的访问权限，具有强大的日志记录和审查功能。 当团队可以使用掩码或减少的数据进行工作时，这个柱子会变得更强大。相比之下，使用完整的生产值会更麻烦。对于受管制的健康数据来说， 脱敏化PHI
是区分有用访问和不必要暴露的关键。 API key security for app store compliance__CAPGO_KEEP_0__
应用商店遵从性中的密钥安全
，尤其是在移动应用和后端服务共享信任边界的情况下。
审计显示控制是否真实存在
一个无法被验证的政策只是一个希望。
- 身份验证活动： 成功登录、失败登录、令牌使用和管理会话。
- 授权变更： 授权、取消授权、角色创建、策略编辑和模式变更。
- 敏感访问模式： 批量读取、大规模导出、异常查询路径和超出预期时间或来源网络的访问。
- 密钥管理事件： 密钥创建、轮换、解密失败尝试、禁用版本和KMS或秘密存储中的策略变更。
保留期和审查也很重要。如果日志在任何人调查之前过期，或者只有在发生漏洞时才会检查权限变更，那么审计系统就存在于纸上而不是实践中。
在实现细节变得过于抽象之前，先看看这个解释：
敏感数据最好不放在无法有效防御的地方
敏化是许多团队在不花费太多工程精力就能获得的最大安全胜利。
减少存储量。存储时间越短越好。减少存储位置。若某功能仅需年龄范围，不必存储完整的出生日期。若支持仅需身份识别码的最后四位，不必暴露完整的字段。若测试环境不需要真实个人数据，不必将生产备份恢复到它们并称之为临时的。
这也是一个运营实践。存储期限需要执行。旧的导出需要删除。下游系统需要审查，因为每次敏感字段被复制到搜索索引、缓存、数据湖、移动存储和临时CSV文件中，风险都会增加。对于Capacitor应用程序 @capgo/capacitor-data-storage-sqlite 并且 @capgo/capacitor-fast-sql 可以提供加密的应用侧持久性，但您仍然需要决定什么不应在本地存储。
这些柱子的目的不是在第一天就达到完美。它是建立一个能够在密钥轮换、人员变动、应急响应、备份恢复和产品增长后仍然可防御的存储系统。那样才是安全数据库存储通常成功或失败的地方。
加密的实践实施模式
并没有一个加密模式适用于每个系统。正确的选择取决于您保护的是什么、谁需要查询它以及您的团队可以支持的复杂度。错误的是选择听起来最强大的模式，然后糟糕地实施它。
TDE 是最快的基线
透明数据加密或 TDE，通常是开始的地方。数据库引擎在磁盘上加密文件，并在引擎读取它们时解密它们。应用程序通常不需要 code 的更改。
这是一个强大的基线，对于：
- 整个数据库的保护
- 存储级的合规要求
- 从被盗的磁盘、快照或原始文件访问中降低风险
TDE 不保护所有内容。如果攻击者获得了有效的数据库访问权限，引擎仍会提供解密的数据。因此，TDE 帮助解决存储安全问题，而不是合法凭据的滥用。
应用级加密保护最重要的字段
应用级加密发生在数据到达数据库之前。您的 code 加密选定字段，然后将密文写入存储中。这对于特别敏感的列，如政府身份证、银行详细信息、恢复密钥或私人笔记等工作得很好。
这种额外的控制权带来了权衡：
- 您拥有的复杂性更大: 密钥选择、加密库、轮换行为和错误处理。
- 查询变得困难: 精确匹配、部分搜索和索引成为设计问题。
- 开发者需要自律: 在迁移脚本中的一条捷径可以绕过您的整个模型。
一个简单的伪代码模式看起来像这样:
| 步骤 | 动作 |
|---|---|
| 1 | 从请求中读取明文字段 |
| 2 | 向密钥服务索取数据加密密钥或使用一个包装的本地密钥 |
| 3 | 在应用程序中加密字段 |
| 4 | 在数据库中存储密文和元数据 |
| 5 | 仅在批准的读取路径中解密 |
对于本地应用程序的持久性，同样的设计问题也适用。如果您在设备上存储离线令牌或敏感的同步状态，不要假设移动存储是安全的。使用像在__CAPGO_KEEP_0__中讨论的那样，针对平台的模式 secure storage for offline tokens in Capacitor.
Envelope加密听起来很吓人，但想法很简单。您用一个密钥加密数据，然后用另一个更好地保护的密钥加密该密钥
想象一下，文件被锁在一个小保险箱里。那个小保险箱的钥匙被锁在一个银行保险箱里。如果有人窃取文件存储层，他们仍然需要访问更高保护的保险箱钥匙才能打开任何有用的东西
典型流程：
为记录、文件或批次生成数据密钥
- 用该数据密钥加密数据 在数据库中存储密文和元数据
- 仅在批准的读取路径中解密 对于本地应用程序的持久性，同样的设计问题也适用。如果您在设备上存储离线令牌或敏感的同步状态，不要假设移动存储是安全的。使用像在__CAPGO_KEEP_0__中讨论的那样，针对平台的模式
- 使用数据密钥 使用KMS或HSM中的主密钥
- 存储加密数据和包装密钥元数据 与记录或对象一起存储
- 仅在授权读取时解包.
建议: 在不暴露长期主密钥给每个应用服务器的情况下，使用封装式加密实现强隔离。这种模式很常见，因为它平衡了性能和控制。应用程序使用短期数据密钥进行实际加密工作，而KMS或HSM保护用于包装和解包它们的主密钥。
加密模式比较
模式
| 实现复杂度 | 性能影响 | Field advice:__CAPGO_KEEP_0__ | 最佳选择 |
|---|---|---|---|
| 磁盘或卷加密 | 低 | 低 | 针对服务器和附加存储的基础设施级保护 |
| 透明数据加密 | 低到中等 | 低到中等 | 以最少的应用程序更改保护整个数据库 |
| 应用程序级加密 | 中等到高 | 根据字段使用和查询设计而异 | 高度敏感的列和严格的分离需求 |
| 信封加密 | 中等到高 | 中等 | 需要更强的密钥隔离和可扩展密钥控制的系统 |
实践规则很简单。从一个强大的基线开始，如TDE或托管的静止加密。然后在数据敏感性和威胁模型有足够理由时，添加字段级或信封加密。
掌握密钥和机密管理
通常，漏洞是由普通的机密处理错误引起的。生产数据库加密，备份存在，访问看起来在纸上是控制的。然后一个CI任务将一个令牌打印到日志中，一个工程师重用一个管理员凭证来支持脚本，或者一个过时的密钥在团队创建它后很长时间仍然保持活跃。
这就是为什么密钥和机密管理是一个运营实践，而不是一个设置任务。
使用不良的密钥处理加密的数据库就像一个锁定的服务器房间，门牌卡挂在门把手上。政府指南也提到了这一点。仅凭加密就无法填补团队忽略KMS或HSM基于的密钥管理、最小特权访问和恢复计划的缺口，如NSA和合作伙伴在《云数据安全指南》中所描述的那样。 团队哪里出了问题.
Where teams get this wrong
这些模式在事件回顾中很熟悉：
- Secrets in source code: 硬编码凭据、嵌入证书或逐渐成为生产依赖项的工具脚本。
- 复制的配置文件中的机密： 文件在笔记本之间传递、存储在共享文件夹中或在紧急修复期间提交。
- 环境变量的弱控制： 方便但经常通过构建日志、shell历史、崩溃报告或广泛的运行时权限暴露。
- 没有轮换所有权： 密钥存在多年，因为没有团队拥有重新发行、发布和回滚计划。
- 共享高权限机密： 应用程序、工程师和自动化使用同一凭据，这使审计和隔离变得更加困难。
如果您正在标准化应用程序和基础设施机密的存储方式，处理 安全环境变量 可以帮助团队远离不规则的机密信息泛滥。
什么样的密钥管理是好的
使用一个 密钥管理系统 当集中化的策略、访问控制、审计日志和定期轮换比自定义硬件控制更重要时。使用一个 硬件安全模块 当风险、合规要求、签名和密钥保护规则要求专用硬件边界时。许多团队并不需要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 中的密钥 而不是将管道凭证视为临时例外。
一个规则很简单。 应用程序 code 应该从可信系统请求加密操作，而不是在环境中携带原始主密钥。
您的堆栈中最强大的加密设计一旦开发者、管道或支持工具将主密钥复制到错误的位置时，就会变得无关紧要。
设计一个可靠的备份和恢复策略
备份是安全数据库存储的一部分，而不是单独的管理任务。如果生产环境受到保护，而备份却没有，那么攻击者会选择更容易的路径。
独立存储指南建议将备份和恢复系统的保护级别与生产环境保持一致，因为勒索软件和恶意软件事件通常会留下安全、经过测试的备份作为唯一可行的恢复路径，根据 Hypertec的安全数据存储指南.
备份需要自己的安全边界
一个可靠的备份设计具有以下几个特性:
- 备份在传输和休眠状态下都被加密。
- 备份凭证与生产凭证分开。
- 删除和保留控制比正常应用访问更难被滥用。
- 恢复目标不应成为弱控制的影子生产环境。
一个常见的故障模式是存储加密的备份，同时允许同样的受损生产角色删除它们。另一个是恢复到一个临时环境中，该环境具有广泛的工程师访问权限并且没有日志。恢复路径应受到与主要路径相同的审查。
恢复测试才是真正的控制
一个未经测试的备份只是希望性的存储
能够顺利恢复的团队不仅仅是验证备份任务完成了。他们证明了恢复工作正常，恢复的数据是可用的，且解密密钥、连接设置和依赖服务都在需要时能够正常工作。
一个实际的恢复计划包括:
- 定期恢复演练 在隔离环境中进行
- 应用程序功能的验证 在数据库恢复后，而不是仅仅是文件恢复
- 密钥可用性的检查 以便可以解密加密的备份
- 恢复系统的访问审查 以防止在事故期间敏感数据变得过于明显
备份并不能救你。成功的恢复才是救命稻草。
如果你只测试备份创建，而不测试在压力下恢复，你就没有验证你的恢复策略。你只是验证了文件可以在某个地方累积。
安全数据库存储开发者清单
这是我希望团队在设计审查、发布审查和后事处理时使用的清单。
设计
- 我们是否已经明确标识了敏感字段: 个人数据、认证材料、财务记录和受保留规则的任何内容。
- 我们是否已经决定不存储什么: 功能不需要的字段，以及下游团队可以避免的副本。
- 我们是否已经绘制了数据将存活的地方的图表: 生产、测试环境、日志、导出、分析系统、备份和客户设备。
實現
- 資料是否在儲存和傳輸過程中進行加密: 資料庫、副本和備份路徑
- 應用程式和服務角色是否被嚴格限制: 沒有共用超級用戶的正常應用流量
- 是否將密鑰和加密金鑰處理在code之外和鬆散的配置中: 具有控制訪問和可追蹤性
- 是否在中央位置記錄敏感訪問和權限變更: 防禦者可以查詢
運營
- 是否將金鑰旋轉和密鑰檢查納入正常運營: 不是年度大掃除
- 我们是否定期测试恢复: 包括解密、应用启动和恢复系统的访问审查。
- 我们是否持续监测数据扩散: 包括测试环境副本、支持导出、开发数据集和遗忘备份位置。
良好的安全数据库存储不是一个项目阶段。它是一个持续的实践。
常见问题
上下文:Capgo Builder / 原生云构建产品页面。角色:部分或页面标题。信息键`native_build_faq_title` (原生构建FAQ标题)。| 首页问题/解决方案部分。角色:部分或页面标题。见于页面premium-support.astro。信息键`ps_faq_title` (PS FAQ标题)。
云提供商的默认加密是否足够好
这是一个强大的基线，但不是一个完整的策略。默认加密可以保护存储介质和托管服务，但它不能解决过度授权访问、复制数据集、弱备份控制或差劲的密钥管理。
加密会不会损害数据库性能
有时是的。影响取决于模式。基础设施和数据库级别加密通常具有较少的应用复杂性。字段级别加密可以为选择的数据提供更强的控制，但会使索引、过滤和搜索变得复杂。请在您的工作负载上进行测量，然后进行广泛的推广。
这是否与关系型数据库和NoSQL系统有所不同
How is tokenization different from encryption?
加密将数据转换为授权系统可以使用正确密钥解密的数据。Tokenization 替换敏感值并将原始数据分开。Tokenization 可以减少应用程序工作流程中的暴露，但它会增加系统设计复杂性，并且不需要强大的存储控制。
Capgo 帮助团队快速将修复发送到 Capacitor 和 Electron 应用程序，具有签名的 Web Bundle 交付、回滚保护和发布可观察性。如果您的应急响应计划依赖于快速发布客户端修复以应对存储、身份验证或 API 错误 Capgo 是值得作为恢复的运营侧面评估的。
