3. 索引安全：索引数据加密、索引访问控制、索引防注入、索引备份与恢复
索引安全这块，说实话，是很多团队容易忽视的环节。大家往往把精力放在搜索性能和召回率上，觉得索引就是个中间产物，出不了大事。嗯，我以前也这么想，直到有一次在客户现场，他们的索引文件被人直接拖走了……那场面，真叫一个尴尬。
今天咱们就把索引安全的四个核心点掰开揉碎讲清楚。我个人习惯把这四点称为「索引安全的四根柱子」——少一根都不行。
3.1 索引数据加密
索引数据加密，说白了就是给你的索引文件加把锁。你想想看，索引里存的是什么？是原始文档的倒排列表、词频、位置信息。如果这些数据明文存储，别人拿到索引文件，基本就等于拿到了你的全部文档内容。
我建议从两个层面来做加密：
- 静态加密：索引文件落盘时自动加密。比如 Elasticsearch 的磁盘加密功能，或者直接用操作系统的 LUKS、BitLocker。
- 动态加密：索引在内存中也是加密的。这个开销大一些，但敏感场景必须上。
我在项目中遇到过一种情况：客户要求索引数据即使被物理盗取也无法读取。我们当时用的是 AES-256 对每个索引段单独加密，密钥托管在独立的 KMS 服务里。效果不错，但性能损耗大概在 10%-15% 左右。这个代价，我觉得值。
重要提醒：加密不是一劳永逸的。密钥轮换、访问审计、加密算法升级，这些都得跟上。我见过有人加密做得很好，但密钥写死在配置文件里……那还不如不加密。
3.2 索引访问控制
索引访问控制，核心就一句话：谁可以读、谁可以写、谁可以删。
很多搜索引擎默认是「全开放」的，比如早期的 Elasticsearch 版本，没有任何认证。你想想看，一个内网服务，所有人都能 curl 一下删掉你的索引，这多吓人。
我建议至少做到以下几点：
- 角色分离：写入索引的角色和查询索引的角色分开。写入角色只能写，查询角色只能读。
- 字段级权限：有些字段（比如用户手机号、身份证）不应该被普通查询看到。Elasticsearch 的字段级安全（FLS）可以做到这一点。
- IP 白名单：只允许特定 IP 段的机器访问索引服务。
我的小技巧：我曾经在项目中用了一个「最小权限原则」——每个服务只给它能用到的索引权限，多一个都不给。刚开始运维觉得麻烦，后来出了几次安全问题，大家都说这个好。
3.3 索引防注入
索引防注入，这个知识点很多人会忽略。大家觉得搜索引擎又不是数据库，怎么会有注入？
其实不然。搜索引擎的查询语法非常丰富，比如 Lucene 的查询语法支持布尔操作、通配符、模糊查询。如果用户输入没有做过滤，攻击者可以构造恶意查询，导致索引被拖库或者服务崩溃。
常见的攻击手法有：
- 通配符爆炸：输入
*:*或者?*这种查询，让搜索引擎遍历所有文档。 - 布尔注入：利用
OR、AND构造复杂查询，绕过权限限制。 - 正则注入：输入恶意的正则表达式，导致 CPU 飙升。
我建议的做法是：
- 查询参数化：不要直接拼接用户输入到查询语句里。用搜索引擎提供的参数化查询接口。
- 查询超时限制：每个查询设置最大执行时间，比如 10 秒。超过就自动终止。
- 查询复杂度限制：限制通配符数量、布尔子句数量、正则表达式长度。
避坑指南：我曾经遇到过一个问题——用户输入了一个看似正常的查询，但里面藏了嵌套的布尔子句，导致索引服务 OOM。从那以后，我强制要求所有查询都要经过一个「查询沙箱」做预处理。
3.4 索引备份与恢复
索引备份与恢复，这个不用我多说，大家都知道重要。但真正做好的团队不多。
我见过最离谱的情况：某团队每天做全量备份，但从来没测试过恢复。结果真出问题的时候，发现备份文件损坏了……
我建议的备份策略：
| 备份类型 | 频率 | 保留时间 | 适用场景 |
|---|---|---|---|
| 全量备份 | 每天一次 | 30 天 | 灾难恢复 |
| 增量备份 | 每小时一次 | 7 天 | 快速恢复 |
| 快照备份 | 实时 | 24 小时 | 误操作回滚 |
恢复流程上，我个人的习惯是：
- 先验证备份完整性：用 checksum 或者测试恢复到一个沙箱环境。
- 再执行恢复：恢复到独立的集群，确认数据无误后再切流量。
- 最后做数据校验：对比恢复后的索引和原始索引的文档数、字段值。
核心原则：备份不是目的，能恢复才是。我建议每个月至少做一次「恢复演练」，模拟各种故障场景。别等到真出事了才手忙脚乱。
好了，索引安全的四个核心点就讲到这里。说白了，加密是防偷、访问控制是防乱、防注入是防坏、备份恢复是防死。四者缺一不可。下一章咱们聊聊查询安全，那又是另一番天地了。