Archery数据查询规范配置实战：从权限收紧到审计闭环

"Archery这平台，做数据库运维的应该都听过。它把SQL审核、查询、执行、慢日志这些零散的活收敛到一个Web界面里，算是开源工具里比较能打的一套。但说实话，最近两年我帮几家团队落地它，发现大部分人都只关注"审核"和"执行"这两个模块，真正决定数据安全的其实是那一块看起来不起眼的设置：数据查询规范配置。今天专门聊聊这块，怎么配、配的时候在防什么、踩过哪些坑。适合正在用Archery或者准备引入SQL平台做访问收敛的DBA、平台运维和研发效能同学参考。"

1. 为什么要给数据查询立规矩？——Archery查询模块的设计逻辑

先别急着点按钮配参数，得先理解Archery的查询模块到底在解决什么。很多人以为它只是"把Navicat换成了网页版"，这个理解误差挺大。Archery的查询功能从设计之初就不是为了替代数据库客户端，而是为了把"谁能查、能查什么、能查多少、查了有没有留痕"这件事全部管起来。理解了这个，后面所有配置项就都有了主线。

1.1 没有查询规范时，生产库通常是什么状态

我在好几家公司见过这样的"裸奔"场景：研发同学要查线上数据，第一反应是找DBA要账号，DBA忙的时候图省事，直接把一个通用账号甩出去，或者干脆把内网访问地址和账号密码贴在Wiki上。结果就是一个账号好几个人用，权限完全没法收敛，离职的人账号也没人回收。

更麻烦的是，这种直达生产库的查询没有任何约束。SELECT *一次拉全表数据的有，忘了加WHERE条件直接扫几千万行的有，甚至有人手滑把查询语句写成了UPDATE还没执行，但权限上是有能力执行写操作的。一旦发生这些问题，排查起来就是一场灾难——没有统一的入口，连"这句话是谁执行的、什么时候执行的"都查不出来。

Archery的设计逻辑就是针对这些痛点来的：把查询入口统一收口到平台，用户不直接接触底层连接串；数据库账号全部托管在平台上，由管理员统一配置；所有查询行为在平台上留审计日志。这样即使出了问题，追责和复盘都有据可查。

1.2 核心权限模型：用户、资源组、实例三层结构

Archery查询模块的权限模型，我的理解是"用户 + 资源组 + 实例"三层结构。第一层是用户，对应统一的登录身份，要查数据先得在平台上发起权限申请；第二层是资源组，它是多个实例的集合，把一个业务域的所有数据库装进一个组里，授权的时候按组授权而不是挨个实例授权；第三层才是真正连接的实例，每个实例在平台里绑定一个专用的查询账号。

这个设计有个很明显的好处：授权粒度从"实例级"提升到了"业务域级"。比如订单相关的库可能分布在两个MySQL实例上，管理员把它们划到"订单核心库"这个资源组里，申请人只需要申请一次，就能覆盖两个实例的全部需要，不用重复申请。权限到期后，管理员也是按资源组统一回收，省事很多。

很多人第一次用Archery时忽略资源组，直接按照实例来给权限，这也能跑通，但实例一多就会很痛苦。我最开始也是这样，接了十几个实例，每个实例单独授权，权限单满天飞，后来痛定思痛把所有实例按业务域重新划了资源组，才彻底解脱。建议各位接入时就把资源组规划好，不要图省事。

1.3 规范化之后，实际换来的是什么

把查询规范配好之后，换来的东西是实打实的。首先是安全层面的收敛：平台接管了查询入口，实际连接账号对普通用户不可见，普通用户拿不到连接串，也就无法绕过平台去连生产库，从根本上堵住了密码泄露后在任意客户端使用的问题。

其次是行为层面的约束：平台层面限制了只能执行SELECT，限制了返回行数、执行超时和并发连接数，即使有人在查询框里写出一句无WHERE条件的DELETE，解析器也会直接拦下来，根本到不了数据库。这个约束从机制上杜绝了"查询变事故"的情况。

再然后是审计层面的留痕：每一次查询是谁发起的、连接了哪个实例、执行了什么语句、用了多长时间，全部记录下来。做合规审计时，或者出了数据泄露事故需要排查时，这些日志就是最有力的证据。规范化不是给业务添麻烦，而是让所有人都在边界内自由行动，出了事有据可查。

2. 查询规范配置的核心拆解：账号、权限、限制、脱敏、审计

Archery的查询规范配置并不是某一个单独的开关，而是由好几个维度共同构成的。我把它拆成五块：查询账号、权限审批、行为约束、脱敏规则、审计追溯。把这五块串起来，查询规范才算真正闭环。

2.1 实例层面的查询账号配置：最小权限是底线

接入一个数据库实例到Archery时，平台会要求填一个"查询账号"。这个账号是平台真正用来连接你的业务库的，它的权限边界直接决定风险上限。我强烈建议为Archery单独创建一个专用账号，权限只给SELECT，不要拿DBA账号甚至业务账号去填。

比如在MySQL里，可以这样创建一个查询账号并授权：

CREATE USER 'archery_query'@'%' IDENTIFIED BY '这里换成高强度密码'; GRANT SELECT ON `业务库名`.* TO 'archery_query'@'%'; FLUSH PRIVILEGES;

如果你管理的库比较多，还可以做成只读账号统一前缀管理，方便后续轮换和回收。

这里有个很关键的细节：账号的Host范围不要直接填%。我在实际落地时都是把Host限定在Archery服务器的内网IP段，这样即使账号密码意外泄露，外部网络也没有办法直接连上你的数据库。数据库层面做一层IP约束，平台层面再做一层SQL约束，双保险。

还有一个容易踩的点：查询账号的权限范围一定要和业务匹配。有些团队图方便，给查询账号授权了所有库的SELECT，导致用户在Archery上选了其他资源组还是能通过某些方式查到别的库的数据，脱敏和审计都没法按库隔离。建议一个实例如果承载了多个业务库，就按库分别创建查询账号并在资源组里做映射，权限边界才能清晰。

2.2 资源组与查询权限申请：审批流是规范的第一道闸门

查询账号配好之后，接下来是权限审批流程。Archery的做法是：用户要查数据，先在平台上发起"查询权限申请"，说明想查哪个资源组、哪些数据库、什么时间段、查询用途是什么，然后由管理员（或指定审批人）审批。审批通过后，用户才在查询入口看到对应资源组，可以进行查询。

配置资源组本身很简单，就是把实例勾选进一个组里，比如"订单数据组"、"用户中心数据组"。但审批流程的设计值得多花些心思。我建议在平台管理后台把每个部门或业务线的负责人设为审批人，让最懂业务的人去判断该不该授权，DBA只负责兜底把控实例层面的风险。

一个实用的配置建议：审批人不要只配一个。至少配置两个，一个是业务负责人，一个是DBA或安全负责人。单一审批人容易因为出差、请假导致工单堆积，双人审批虽然多了流程，但能确保权限授予不是某个人的一言堂。对特别敏感的核心库，还可以设置更高的审批级别，这是查询规范里最值得花时间设计的一环。

另外，申请时的时间期限建议默认勾选"指定有效期"，比如7天或30天。我之前见过很多团队图省事，审批通过就永久授权，半年后权限彻底被忘干净，这是查询权限管理里最大的黑洞。Arc的权限到期后用户需要重新申请，这个回收机制一定要用起来。

2.3 查询行为约束：行数、超时、并发，一个都不能少

权限给了，不等于可以随意查。Archery在查询行为层面提供了一系列约束参数，这也是"查询规范"这个词里非常实在的部分。我挑几个关联最大、也最容易被业务感知的说。

第一个是最大返回行数。默认可能允许拉取几万行，我落地的时候会把生产环境的默认值调到1000到5000行之间。几千行足够定位问题，再多就是拿平台当数据导出了。限制返回行数背后防的不仅是数据库压力，还有网络和内存层面的风险——一台客户机一次拉个几十万行，网卡和客户端内存首先扛不住。

第二个是执行超时时间。慢查询在业务高峰期是最危险的，一次5分钟的长查询虽然没有写操作那么致命，但连接不释放、线程堆积，最终还是会把数据库拖垮。我一般把查询超时控制在30秒到60秒，超时后平台强制中断该次查询。业务方的感受是“查不出来可以再优化SQL”，这比让DBA半夜被告警叫起来要友好太多。

第三个是并发和会话限制。Archery的会话管理能看到当前平台上有哪些活跃查询，我一般会给每个实例设置不超过3到5个并发查询连接。为什么要限制？因为数据库的连接数是稀缺资源，一个慢查询占住连接不放，后面的人全部排队，严重的会把实例打满。限制并发之后，过剩的连接需求会主动排队，而不是一股脑压到数据库上，稳定性提升很明显。

除这几项之外，还建议把查询模式锁定为"只读模式"，也就是平台层面直接禁止任何非SELECT语法。这个约束我在后文排查章节会细说，这里先记住一点：查询模块的定位是只读分析，任何写操作都应该走SQL审核工单，不应该出现在查询框里。

2.4 数据脱敏：敏感字段不能裸奔在查询结果里

权限审批和行数限制管的是"能不能查、查多少"，脱敏管的是"查到了能不能看懂"。Archery的查询结果可以做字段级脱敏，这个功能很多人配了但没配全，实际意义非常大：你在查询结果里看到的手机号可能是138****5678，身份证号是脱敏后的固定格式，但原始值依然留在库里。

数据脱敏配置前，先做一次敏感字段盘点。常见的敏感字段不用我说大家也清楚：手机号、身份证号、银行卡号、邮箱、家庭地址、业务合同金额等等。我的建议是和法务、安全的同事一起拉一份清单，明确哪些字段属于敏感字段，再按字段在Archery的实例配置里做脱敏设置。

配置脱敏时要注意脱敏算法和脱敏格式的选择。比如手机号，一般中间四位打码；姓名可以是首字保留，其余打码；证件号保留前三位后四位，中间全部隐藏。不同字段格式不一样，算法不要一刀切。我在实际项目里就见过把邮箱地址整个换成***@***的情况，虽然安全是安全了，但业务方拿到这个结果根本没法做数据分析，最后投诉到我这里来。

还要提一件事情：脱敏不是万能的。用户发起查询权限申请时，如果申请理由合理，比如财务统计需要全量手机号做对账，那么脱敏规则在某些场景下可以给特例放行，但需要更高级别的审批。这个"脱敏例外审批"机制建议从一开始就设计好，否则真到业务急用的时候只能临时开权限，违背了规范化的初衷。

2.5 审计留痕：查询日志不是摆设，是最后一道防线

查询规范的最后一道闭环是审计。Archery的查询审计会把每一次查询操作记录下来，包括查询人、查询时间、目标实例、目标库表、执行的SQL语句、返回行数、执行耗时等。我接手平台运营的时候，第一件事就是养成每周翻一次审计日志的习惯，看看有没有异常的批量导出、非工作时间的查询、或者大结果集操作。

审计日志的价值平时看不出来，一旦出了数据泄露或者账号滥用事件，它就是最重要的排查依据。我经历过一次配合安全同事做数据泄露调查，如果不是平台上有完整审计，完全没法定位到具体是哪个人在哪个时间段、通过哪些SQL把数据拿走的。那一次之后，所有接入Archery的团队都必须开通审计日志定期归档，不能只在平台上存着，最好同步一份到独立存储，防止平台故障时日志丢失。

另外一个容易被忽略的操作是"会话管理"。Archery提供在线会话列表，能看到当前所有运行中的查询。当数据库出现异常负载时，我第一反应就是打开会话列表，定位到慢查询或者异常大查询。必要时可以直接终止该会话来保护数据库。这个能力在规范配置好之后依然需要人工配合，不能完全依赖自动限制。

3. 实操：从接入实例到查询全链路跑通的落地记录

理论拆了一层，接下来把整套流程串起来走一遍。这部分我会按照我自己做的一次完整落地过程来写，从部署平台开始，到添加实例、配置资源组、设置审批、最后验证查询和审计，覆盖你实际操作的每一步。

3.1 部署Archery：Docker方案最省心

Archery本身是Python/Django项目，依赖MySQL（存储平台自身的元数据）和Redis（缓存/会话）。部署方式官方推荐Docker Compose，我自己也用这个方式，省去了环境配置的各种麻烦。基本思路是拉取项目代码，配置好compose文件里的MySQL密码和Redis地址，然后启动容器。

大致命令流程是：

git clone https://github.com/hhyo/Archery.git cd Archery # 打开docker-compose.yml，修改MySQL/Redis初始化密码 docker-compose up -d

容器起来之后，需要执行一次数据库初始化，也就是Django的migrate操作，把平台自身的表结构建出来，然后创建一个管理员账号。这一步不同版本的操作路径略有差异，在容器里执行python manage.py migrate和createsuperuser都是常规做法。初始化完成后，登录管理员界面，首页可以看到实例管理、资源组、工单管理、查询等核心菜单，到这里部署就算完成了。

需要提醒一个部署细节：Archery平台自身使用的MySQL不要和生产库混在一起，也不要图省事直接用Archery的元数据库去存业务数据。平台自身的库一旦被业务查询拖垮，整个SQL平台的入口就瘫痪了，这个基础环境隔离还是要做扎实。

3.2 添加生产实例并绑定查询账号

平台部署完成后，第一步是把要纳管的数据库实例接入进来。进入"实例管理"，点击新增实例，填写类型（MySQL、Oracle等）、实例名、主机地址、端口。这里就要用到我们前面准备的只读查询账号，把账号密码填到对应的"查询账号"配置里。

添加实例的时候，有几个连接参数值得认真设一下。连接超时我一般设置为5到10秒，避免实例不可达时平台长时间卡在等待；执行超时按前面的建议设置为30到60秒；最大返回行数设置为1000到5000。这几个参数在不同版本的Archery里位置略有不同，有些在实例配置里，有些在全局配置里，我建议都检查一遍，找到能改动的地方。

实例添加完成后，强烈建议先做一个连通性测试。Archery通常提供了测试连接的功能，可以快速验证账号密码是否正确、网络是否通、账号是否具备预期的查询权限。我在上线时发现过不少次因为账号填错或者授权没刷新生效导致后端连不上库的情况，测试连接能替你提前踩掉这个坑。

3.3 规划资源组并配置审批流程

接着是我最推荐认真做的环节：资源组规划。在"资源组"菜单里，点击新增，把业务上关联紧密的实例勾选进去。比如我负责的平台有订单主库、订单从库、订单分析库三个实例，它们属于同一个业务域，就全放到"订单核心数据组"里。划分好后的资源组，会直接出现在查询权限申请的选择列表中。

审批流程在Archery里需要配合"用户管理"来做。我建议先把组织架构建好，按部门创建用户组，把用户拉进组里，再为每个组指定审批人。审批人通常是这个业务域的技术负责人或者DBA。配置完成后，当普通用户发起查询权限申请时，审批人就能在待办列表里看到并处理。

这里有一个我踩过的坑想提醒各位：审批人配置和抄送人配置不要搞混。我一开始以为抄送人就是审批人，结果用户提交申请后，抄送人只收到了一封邮件通知，工单却卡在"待审批"状态没人处理。排查半天才发现审批人根本没设。所以配置完建议立刻用一个普通测试账号发起申请，走一遍流程验证审批链路是否通畅，不要等到业务真正要用才暴露问题。

3.4 全链路验证：申请、审批、查询、审计一气呵成

配置完成不等于配置生效，我会建议用一个虚拟的"测试用户"验证整个流程。第一步，用测试用户登录，在查询页面发起"查询权限申请"，选择提前建好的资源组，库名填想查的库，时间期限选7天，申请理由填写"联调测试"。第二步，切到审批人账号，在待办里同意这个申请。第三步，切回测试用户，进入查询入口，这时应该能看到对应资源组，选择库表执行一条简单的SELECT。

验证查询时，我有三个必测项。第一是只读限制，故意执行一条UPDATE users SET name='test'，确认平台能拦截并报错；第二是行数限制，执行一个不加WHERE条件的查询，确认返回行数被截断在设定值内；第三是脱敏效果，查询包含敏感字段的表，确认返回结果中敏感字段已经按预设格式脱敏。

最后还要回到审计日志，确认刚才那几条测试查询完整记录在案。如果审计里能看到用户、实例、SQL、时间，恭喜你，这条查询链路真正闭环了。测试完成后记得在用户管理里把测试账号停用，避免留下一个没必要的权限入口。

4. 常见问题与排查技巧实录

配置Archery查询规范，踩坑是免不了的。我把这一两年里遇到过且花过时间排查的问题整理了一下，按照"现象、原因、解法"的表格列出来，再挑几个典型的展开说明。这一节内容建议先收藏，等配置的时候再翻出来对号入座。

4.1 高频问题速查表

4.2 三个我踩过且印象深刻的坑

第一个坑是查询账号权限给了UPDATE。当时在数据库侧创建账号时，我图省事直接搜了个现成的授权脚本，把SELECT和UPDATE一起GRANT给了查询账号。其实Archery平台层已经拦了写操作，理论上查询框里执行不了UPDATE，所以这个坑不会直接在Archery上爆雷。但数据库侧的权限过宽本身就是隐患，万一账号泄露，攻击者绕过平台直连数据库，就能绕过所有拦截。后来我把所有Archery查询账号的权限收敛成了只读，这属于机制之外的二次加固。

第二个坑是资源组和实例绑定后，实例下线了，但资源组仍然引用。有一次团队下线了一个老数据库，实例删了没同步清理资源组，结果用户申请查询权限时还能看到这个僵尸资源组，点击查询直接报连接失败，用户以为平台坏了。排查完发现是资源组里的引用没清理。从此我养成了习惯：每次实例下线，第一件事就是去检查所有引用它的资源组，把相关权限申请也一并关闭。

第三个坑是脱敏配置的字段名大小写问题。MySQL字段名在Linux环境下大小写敏感，我在脱敏规则里填了IDCard，但实际表结构是idcard，导致脱敏一直没有命中。那段时间业务方一直在反馈"身份证号怎么还是明文"，最后是逐字段对比才发现大小写不一致。现在我在配置任何一个敏感字段前，都会先在库里查一下字段的精确写法，再填进规则里。

4.3 排查思路：从日志和会话两头下手

遇到Archery查询相关的疑难杂症，我的排查习惯是两头看：一头看平台自身的日志，一头看数据库会话状态。平台日志一般记录在Archery部署目录的日志文件里，很多查询报错的实际原因能直接在里面找到，比如账号认证失败、超时中断、连接池打满，日志都能给出明确线索。另一头是登录数据库执行SHOW PROCESSLIST，看当前有哪些会话是从Archery服务器发的，每个会话在跑什么语句，耗了多久，是不是有堆积。

这两个方向配合基本能定位绝大多数查询模块问题。我记得有次用户反馈查询特别慢，平台日志里看不出异常，一查数据库侧，发现某个连接正在跑一个几千行的关联查询，典型的索引缺失问题。这时候数据侧的优化思路就要介入，光改平台参数解决不了根本问题。所以Archery规范化配置和数据库本身的质量优化是相辅相成的，平台负责框住边界，数据库负责给性能兜底。

5. 查询规范配置上线后，我建议还做这几件事

规范配置到这里算是落地了，但我的经验是"上线只是开始"。有几步运营动作如果定期做，会让这套规范长期保持坚强。这一节算是我个人的运营心得，不是教程里通常写的那种，但确实是我踩过几轮坑之后换来的体会。

首先是定期权限复核。我会每隔两个月把全量查询权限导出来，清理掉那些长期未使用或者已过期的权限。这个习惯能防止权限越积越多，最终变回原来那种"账号满天飞"的老状态。Archery的审计日志可以用来分析，哪些用户申请了权限但很少查询，这些权限就是优先回收的对象。

其次是敏感字段清单的动态更新。业务是变化的，新的敏感字段会不断出现，比如疫情后很多系统里多了健康状态字段、行程信息字段，这些字段在合规上都属于敏感数据。我建议每季度归集一次新增敏感字段，并在Archery脱敏规则里及时补齐。这个动作技术含量不高，但合规风险全靠它兜底。

最后是异常查询的主动监控。光有审计日志不够，还得有人按周期去翻。我一般每周会花十分钟扫一遍近七天的查询记录，重点看有没有凌晨非工作时间的批量查询、异常大的结果集导出、或者连续多次查询不同核心库表的行为。把主动监控变成习惯，很多风险就能在业务受到影响之前被发现。

另外关于Archery查询入口在团队内的推广，我个人的做法是：一旦规范生效，就要求平台成为唯一直连数据库的入口，原则上不开放其他方式。这看起来有点"激进"，但实际是保护所有人的做法——权限申请有记录、查询有审计、问题有追溯，对DBA和业务研发都是好事。至于数据导出需求，也尽量引导到走审批流程，而不是在查询界面里拖个大结果集出来。

我自己体会最深的一点是：Archery的查询规范配置，表面上是管理员在后台点几下、填几行参数，真正的功夫全在配置之前——梳理实例清单、盘点敏感字段、设计权限审批责任矩阵。这些准备工作做得越扎实，日常运营就越轻松。等这套规范真正跑起来，你会发现团队里的数据访问乱象消失了，出问题时可以很快锁定责任人，业务方申请查询也只需要一次审批就够，不再需要反复找DBA开号，DBA团队的周末也能清净不少。这份安全感，是任何工具本身都替代不了的。