Refine框架下敏感数据加密存储与安全传输实战指南

1. 项目概述：为什么Refine应用必须重视数据安全？

最近在做一个内部管理系统的重构，技术栈选的是Refine。项目推进到一半，产品经理突然跑过来问：“咱们这个系统里存的用户身份证号、手机号，还有那些审批的敏感附件，到底安不安全啊？万一泄露了，可不是闹着玩的。” 这一问，直接把我问住了。是啊，Refine框架确实让我们快速搭建了增删改查界面和API，但框架本身并不会自动帮你把敏感数据加密存起来，也不会确保数据在网络上跑的时候是密文。数据安全这道最后的防线，终究得我们开发者自己亲手来筑。

这其实就是“Refine框架下的敏感数据安全指南”要解决的核心问题。Refine是一个优秀的React框架，用于快速构建数据驱动的中后台应用。它提供了数据获取、状态管理、UI组件等一揽子解决方案，极大地提升了开发效率。然而，“效率”不等于“安全”。当你的应用涉及个人隐私（PII）、商业机密、金融数据时，仅仅依赖HTTPS和数据库访问控制是远远不够的。攻击者可能通过拖库（数据库泄露）、中间人攻击、甚至是内部人员误操作导致数据泄露。

因此，这个指南的目标非常明确：在Refine应用架构中，系统地融入加密存储与安全传输机制。它适合所有使用Refine开发涉及敏感数据处理应用的开发者、架构师和安全负责人。我们将不仅告诉你“怎么做”，更会深入拆解“为什么这么做”，以及我在实际项目中踩过的坑和总结的有效策略。你会发现，安全不是某个孤立的环节，而是一套需要贯穿于数据生命周期（产生、传输、存储、使用、销毁）的完整实践。

2. 安全架构设计：在Refine中规划加密与传输的层次

在Refine项目中搞安全，最忌讳的就是“哪里漏了补哪里”。我们需要一个自上而下的架构视角。Refine应用通常遵循前后端分离的模式，前端是React应用，后端通过Data Provider与API通信。我们的安全措施需要覆盖这三个主要区域：前端（浏览器）、传输层（网络）、后端（服务器与数据库）。

2.1 核心安全原则与威胁模型

在动手写代码之前，必须明确我们保护的是什么，以及防范的是谁。这里有几个关键原则：

1. 最小化原则：只收集和存储业务绝对必需的敏感数据。能不存的尽量不存，比如用手机号哈希代替明文手机号进行去重校验。
2. 端到端原则：理想情况下，敏感数据在离开用户设备前就被加密，且只有目标接收方能解密。这能有效防范服务器被入侵导致的数据泄露。
3. 纵深防御原则：不要依赖单一安全措施。即使一层被突破，还有其他层提供保护。

我们的威胁模型主要包括：

• 传输窃听：攻击者在网络节点窃听明文数据。
• 服务器入侵：攻击者获取了数据库访问权限或服务器文件系统权限。
• 内部威胁：拥有数据库访问权限的运维、DBA或开发人员有意或无意查看敏感数据。
• 客户端攻击：通过XSS等漏洞窃取浏览器内存中的敏感数据。

2.2 Refine各层的安全职责划分

基于上述原则，我们来规划Refine各层该做什么：

• 前端层（React + Refine Hooks/Components）：
  • 职责：对需要提交的极端敏感字段（如密码、私钥）进行客户端加密；安全地处理、显示（如部分掩码）和解密来自后端的敏感数据；管理好用于加密的密钥材料（绝不硬编码）。
  • 非职责：执行主要的业务逻辑加密。因为前端代码是公开的，任何加密逻辑和密钥（如果写死在前端）都等同于公开。
• 传输层（HTTPS + 安全配置）：
  • 职责：提供信道加密，防止中间人窃听和篡改。这是基础，但远远不够。
  • 关键动作：强制使用TLS 1.2/1.3，配置安全的加密套件，启用HSTS。
• 后端层（Refine Data Provider + API 服务 + 数据库）：
  • 职责：这是安全的主战场。
  • API服务：验证客户端身份与权限；对接收到的敏感数据进行落地前的加密处理；对返回给前端的敏感数据进行按需解密或脱敏。
  • 数据库：存储加密后的密文。可以考虑使用数据库自身的透明加密（TDE）作为额外防护，但应用层加密是关键。
  • 密钥管理：安全地生成、存储、轮换加密密钥，这是整个体系的基石。

注意：一个常见的误区是让前端加密所有数据后传给后端，后端直接存。这只有在“端到端加密”场景下（如私密聊天，服务器不应知道内容）才适用。对于大多数业务系统，后端需要能解密数据以进行搜索、计算或审批，因此加密主要发生在后端。

2.3 技术选型考量

• 加密算法：
  • 对称加密（如AES-256-GCM）：用于加密存储。速度快，适合大量数据。GCM模式还能提供完整性验证。
  • 非对称加密（如RSA-OAEP， ECIES）：用于安全传输密钥或实现前端加密。例如，前端用后端公钥加密一个临时生成的对称密钥（会话密钥）然后传给后端。
  • 哈希算法（如Argon2id， bcrypt）：用于密码存储，必须加盐。
• 密钥管理服务（KMS）：对于生产环境，绝对不要将密钥硬编码在配置文件或环境变量中。应使用专门的KMS（如AWS KMS、HashiCorp Vault、Azure Key Vault）或硬件安全模块（HSM）。它们提供密钥的安全存储、访问审计和自动轮换。
• Refine Data Provider适配：我们需要定制或包装Data Provider，在create、update等操作中插入加密逻辑，在getOne、getList中插入解密或脱敏逻辑。

3. 核心细节解析：加密存储的实战策略

加密存储的目标是：即使数据库内容被完整导出，攻击者也无法直接获得敏感信息的明文。这里我们分场景讨论。

3.1 字段级加密 vs. 整库加密

• 字段级加密：只对特定的敏感字段（如身份证号、手机号、银行卡号）进行加密。这是最常用、最灵活的方式。
  • 优点：粒度细，性能影响小，可以对不同字段使用不同的密钥。
  • 缺点：需要修改业务代码，识别所有敏感字段。
  • Refine中的实现点：在Data Provider的create和update方法中，遍历传入的data对象，对指定字段的值进行加密，再将密文传给真正的API。在getOne和getList方法中，从API拿到包含密文字段的数据后，在返回给UI组件前进行解密。
• 整库透明加密（TDE）：由数据库引擎在存储到磁盘时自动加密整个数据文件、表空间或备份。
  • 优点：对应用透明，无需修改代码，能防护磁盘盗窃等风险。
  • 缺点：数据在数据库内存中是明文的，无法防护拥有数据库查询权限的攻击者。通常作为字段级加密的补充，而非替代。

我们的策略是：以字段级应用层加密为主，TDE为辅。因为防护拥有数据库查询权限的攻击者（包括内部人员）是我们的核心目标之一。

3.2 密钥生命周期管理

这是加密存储中最容易出错也最致命的一环。

• 密钥生成：使用强随机数生成器（CSPRNG）。在Node.js中，使用crypto.randomBytes()。
• 密钥存储：
  • 绝对禁止：将密钥写在代码、配置文件、环境变量（除非是临时测试）。
  • 正确做法：使用KMS。应用启动时，从KMS获取数据加密密钥（DEK）的密文，然后用一个本地临时密钥或从KMS实时解密使用。主密钥（KEK）永远留在KMS中。
• 密钥轮换：定期更换密钥是必须的。但直接更换会导致旧数据无法解密。标准做法是：
  1. 生成新密钥（Key_new）。
  2. 用Key_new重新加密所有数据？不，这在大表上不可行。
  3. 更优方案：使用“信封加密”。每个数据条目用唯一的数据密钥（DEK）加密，而这个DEK本身又被当前的主密钥（KEK）加密后存储。轮换时，只需用新的KEK重新加密所有的DEK即可，无需触碰实际数据。
• 实操心得：在项目初期，如果还没引入KMS，可以暂时使用经过严格访问控制的独立“密钥配置服务”来分发密钥，并记录所有访问日志。但这只是权宜之计，必须尽快规划迁移到专业KMS。

3.3 在Refine Data Provider中集成加密逻辑

假设我们有一个users资源，其中idCardNumber字段需要加密存储。

// dataProvider.js import { DataProvider } from "@refinedev/core"; import { encryptField, decryptField } from "./cryptoService"; // 封装的加密解密模块 const customDataProvider = { ...baseDataProvider, // 你原有的基础Data Provider create: async ({ resource, variables }) => { // 1. 在发送前加密敏感字段 const encryptedVariables = { ...variables }; if (resource === "users" && encryptedVariables.idCardNumber) { encryptedVariables.idCardNumber = await encryptField(encryptedVariables.idCardNumber); } // 2. 调用原始API const response = await fetch(`/api/${resource}`, { method: "POST", body: JSON.stringify(encryptedVariables), // ... headers }); const data = await response.json(); // 3. 返回给Refine的数据，通常API返回的是加密后的值，我们需要在UI层按需解密 return { data }; }, getOne: async ({ resource, id }) => { // 1. 从API获取数据（包含密文字段） const response = await fetch(`/api/${resource}/${id}`); let data = await response.json(); // 2. 对敏感字段进行解密（注意：根据业务，可能只在有特定权限时才解密） if (resource === "users" && data.idCardNumber) { // 这里可以加入权限判断，例如只有“人事专员”角色才解密 const hasPermission = await checkPermission('decrypt:idCard'); if (hasPermission) { data.idCardNumber = await decryptField(data.idCardNumber); } else { // 否则，返回脱敏数据或直接返回密文（前端显示为‘已加密’） data.idCardNumber = "***"; } } return { data }; }, // update, getList 等方法同理，需要类似处理 };

关键点：解密操作通常需要结合细粒度的权限控制。不是所有能查到这条记录的人都有权看明文。这需要在getOne和getList中根据当前用户角色动态决定是返回明文、脱敏值还是密文占位符。

4. 安全传输的进阶实践：超越HTTPS

HTTPS是标配，但它只保证了客户端到服务器（或负载均衡器）这一段链路的加密。在微服务架构或服务器与数据库、服务器与第三方服务之间，传输同样需要保护。

4.1 加固HTTPS配置

首先，确保你的HTTPS不是“纸老虎”。在Node.js后端（如Express）中：

import https from 'https'; import fs from 'fs'; import helmet from 'helmet'; // 使用helmet安全中间件 const app = express(); app.use(helmet()); // 设置一系列安全HTTP头 const sslOptions = { key: fs.readFileSync('/path/to/private.key'), cert: fs.readFileSync('/path/to/certificate.crt'), ciphers: [ 'ECDHE-RSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES256-GCM-SHA384', // 禁用不安全的加密套件，如TLS_RSA_WITH_* 和 TLS_1.0/1.1的套件 ].join(':'), honorCipherOrder: true, // 使用服务器端的加密套件优先级 minVersion: 'TLSv1.2', // 最低使用TLS 1.2 }; https.createServer(sslOptions, app).listen(443);

使用像SSL Labs这样的在线工具测试你的服务器配置，确保评级为A或A+。

4.2 实现应用层端到端加密（E2EE）

对于极高安全要求的场景（如医疗健康数据、司法证据），可以考虑E2EE。在这种模型下，数据在用户浏览器端就用其公钥（或一个预共享的密钥）加密，服务器存储的始终是密文，服务器自身也无法解密。只有拥有对应私钥的授权用户才能解密查看。

在Refine中的实现思路：

1. 用户注册/登录时，在浏览器端生成一对非对称密钥（如RSA 2048），私钥用用户密码派生出的密钥加密后存储在本地（如IndexedDB），公钥上传至服务器。
2. 当用户A创建一条敏感记录时，Refine前端用用户A自己的公钥加密该数据，然后将密文提交给服务器。
3. 当用户A要查看时，前端从本地取出加密的私钥，用密码解密获得私钥，再解密服务器返回的密文。
4. 如果涉及共享给用户B，则需要用用户B的公钥再加密一份数据的对称密钥（信封加密模式），并将这个“信封”存储在服务器。用户B访问时，用自己的私钥解开信封得到对称密钥，再解密数据。

警告：E2EE实现极其复杂，密钥丢失（用户忘记密码）意味着数据永久不可恢复。它极大地牺牲了服务器的搜索、计算等业务功能。除非有强制合规要求，否则应谨慎评估。

4.3 服务间通信的安全

如果你的Refine后端需要调用其他微服务或数据库：

• 数据库连接：使用SSL/TLS加密连接。在连接字符串中配置ssl=true或sslmode=require。
• 微服务间调用：
  • 双向TLS（mTLS）：服务间相互验证证书，是最安全的方式。
  • API网关与认证：所有内部调用也通过网关，并携带JWT等内部服务令牌进行认证。
  • 网络策略：在Kubernetes或云平台中配置网络策略，只允许特定的服务Pod之间通信。

5. 完整实操流程：从零构建一个安全的Refine用户管理模块

让我们以一个具体的“用户管理”模块为例，串联上述所有知识点。假设我们需要安全存储用户的手机号和邮箱。

5.1 环境与依赖准备

后端（Node.js + Express + Prisma）：

npm install express helmet crypto-json bcryptjs jsonwebtoken npm install -D @types/node @types/express

• crypto-json：一个方便的库，用于对JSON对象的特定字段进行加密。
• helmet：设置安全HTTP头。
• jsonwebtoken：用于API认证。

前端（Refine）：

npm install @refinedev/core @refinedev/simple-rest @refinedev/antd antd

我们使用simple-restData Provider作为起点进行定制。

5.2 后端实现：加密API与密钥管理

1. 密钥管理服务（模拟，生产环境用KMS）：

// services/keyService.js import crypto from 'crypto'; class KeyService { constructor() { // 模拟从“安全的地方”获取密钥，生产环境从KMS获取 // 这里使用环境变量仅用于演示，实际是重大安全隐患 this.encryptionKey = Buffer.from(process.env.FIELD_ENCRYPTION_KEY || crypto.randomBytes(32).toString('hex'), 'hex'); this.algorithm = 'aes-256-gcm'; } async encrypt(text) { const iv = crypto.randomBytes(16); const cipher = crypto.createCipheriv(this.algorithm, this.encryptionKey, iv); let encrypted = cipher.update(text, 'utf8', 'hex'); encrypted += cipher.final('hex'); const authTag = cipher.getAuthTag(); // 将IV和认证标签与密文一起存储，用分隔符分开 return `${iv.toString('hex')}:${authTag.toString('hex')}:${encrypted}`; } async decrypt(encryptedText) { const [ivHex, authTagHex, encrypted] = encryptedText.split(':'); const iv = Buffer.from(ivHex, 'hex'); const authTag = Buffer.from(authTagHex, 'hex'); const decipher = crypto.createDecipheriv(this.algorithm, this.encryptionKey, iv); decipher.setAuthTag(authTag); let decrypted = decipher.update(encrypted, 'hex', 'utf8'); decrypted += decipher.final('utf8'); return decrypted; } } export default new KeyService();

2. 用户模型与加密中间件（使用Prisma）：

// prisma/migrations/..._create_user.sql model User { id String @id @default(cuid()) name String phone String @unique // 存储的是密文 email String @unique // 存储的是密文 createdAt DateTime @default(now()) updatedAt DateTime @updatedAt }

// middleware/fieldEncryption.js import keyService from '../services/keyService.js'; const fieldsToEncrypt = ['phone', 'email']; export async function encryptUserFields(data) { const encryptedData = { ...data }; for (const field of fieldsToEncrypt) { if (encryptedData[field]) { encryptedData[field] = await keyService.encrypt(encryptedData[field]); } } return encryptedData; } export async function decryptUserFields(user) { if (!user) return user; const decryptedUser = { ...user }; for (const field of fieldsToEncrypt) { if (decryptedUser[field]) { decryptedUser[field] = await keyService.decrypt(decryptedUser[field]); } } return decryptedUser; }

3. 用户注册API（/api/users）：

import { encryptUserFields } from '../middleware/fieldEncryption.js'; app.post('/api/users', async (req, res) => { try { const userData = req.body; // 1. 加密敏感字段 const encryptedUserData = await encryptUserFields(userData); // 2. 创建用户（Prisma示例） const newUser = await prisma.user.create({ data: encryptedUserData, }); // 3. 返回给前端的数据中，敏感字段应脱敏或返回密文占位符 res.status(201).json({ id: newUser.id, name: newUser.name, phone: '***', // 或 newUser.phone (密文)，前端显示“已加密” email: '***', }); } catch (error) { res.status(500).json({ error: error.message }); } });

4. 获取用户详情API（/api/users/:id）：

import { decryptUserFields } from '../middleware/fieldEncryption.js'; app.get('/api/users/:id', authenticateJWT, async (req, res) => { try { const user = await prisma.user.findUnique({ where: { id: req.params.id } }); if (!user) return res.status(404).json({ error: 'User not found' }); // 根据用户权限决定是否解密 if (req.user.role === 'admin' || req.user.role === 'hr') { // 有权限，解密后返回明文 const decryptedUser = await decryptUserFields(user); res.json(decryptedUser); } else { // 无权限，返回脱敏数据 const { phone, email, ...safeUser } = user; res.json({ ...safeUser, phone: '***', email: '***', }); } } catch (error) { res.status(500).json({ error: error.message }); } });

5.3 前端实现：定制Refine Data Provider

1. 创建定制的Data Provider：

// providers/dataProvider.js import { DataProvider } from "@refinedev/core"; const API_URL = "/api"; export const dataProvider = { getApiUrl: () => API_URL, getList: async ({ resource, pagination, sorters, filters }) => { const response = await fetch(`${API_URL}/${resource}?${/* 构造查询参数 */}`); const data = await response.json(); // 注意：列表接口通常返回脱敏数据，无需前端解密 return { data, total: data.length }; }, getOne: async ({ resource, id }) => { const response = await fetch(`${API_URL}/${resource}/${id}`); const data = await response.json(); // 假设API已根据权限返回了明文（对管理员）或脱敏数据（对普通用户） // 如果API返回的是前端需要解密的密文（E2EE场景），则在此处调用解密函数 // const decryptedData = await clientSideDecrypt(data); return { data }; }, create: async ({ resource, variables }) => { // 对于E2EE，前端需要在此处加密variables // const encryptedVariables = await clientSideEncrypt(variables); const response = await fetch(`${API_URL}/${resource}`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(variables), // 或 encryptedVariables }); const data = await response.json(); return { data }; }, update: async ({ resource, id, variables }) => { // 类似create，处理加密逻辑 const response = await fetch(`${API_URL}/${resource}/${id}`, { method: "PATCH", headers: { "Content-Type": "application/json" }, body: JSON.stringify(variables), }); const data = await response.json(); return { data }; }, // ... 其他方法（delete, getMany等） };

2. 在Refine App中注入：

// App.jsx import { Refine } from "@refinedev/core"; import { dataProvider } from "./providers/dataProvider"; function App() { return ( <Refine dataProvider={dataProvider} // ... 其他配置 > {/* ... */} </Refine> ); }

5.4 前端UI组件的安全考量

在显示敏感数据时，即使是解密后的明文，也要注意：

• 掩码显示：在列表页或非详情页，不要显示完整信息。使用antd的<Typography.Text type="secondary">配合自定义掩码组件。

  const MaskedPhone = ({ phone }) => { if (!phone || phone === '***') return phone; // 显示为：138****1234 return `${phone.slice(0, 3)}****${phone.slice(-4)}`; };

• 复制与下载控制：禁止或记录敏感数据的复制、下载操作。可以通过onCopy事件监听，或渲染为不可选中的文本。
• 剪贴板清理：在包含敏感数据的页面，离开时尝试清理剪贴板（注意浏览器权限限制）。

6. 常见问题、排查技巧与进阶思考

在实际落地过程中，你会遇到各种各样的问题。以下是我总结的一些典型场景和解决方案。

6.1 加密后如何搜索？

这是字段级加密最大的挑战。直接对密文进行LIKE查询是不可能的。有几种折中方案：

方案	原理	优点	缺点	适用场景
应用层解密后过滤	将所有数据取到应用内存中解密，然后在代码里过滤。	实现简单，安全性高（查询条件也可加密）。	性能极差，数据量稍大就不可用。	数据量极小（<1000条）或离线批处理。
可搜索加密	使用特殊的加密算法（如确定性加密、保序加密）或生成额外的“搜索令牌”。	能在密文上执行等值或范围查询。	算法复杂，可能泄露部分模式信息，降低安全性。	对等值查询有强需求的场景，需专业密码学评估。
哈希索引	对需要精确匹配的字段（如身份证号），存储其加盐哈希值用于查询。	性能好，能快速定位精确匹配。	只能用于精确匹配，无法模糊搜索。丢失了数据其他用途。	身份证、手机号等唯一标识的精确校验。
业务侧索引	引入一个不敏感的、明文的业务编号或标签作为索引。	简单高效，不破坏安全模型。	需要业务设计配合，可能无法覆盖所有查询需求。	最推荐的方式，如用“用户编号”代替“姓名+身份证”查询。

我们的实践：对于手机号，我们采用“哈希索引”方案进行精确查找。在用户表中增加一个phone_hash字段，存储手机号+固定盐值的SHA256哈希。查询时，前端提交手机号，后端计算其哈希值，然后去数据库匹配phone_hash字段。这样，数据库里存的依然是哈希，而非明文或可逆密文。

6.2 密钥轮换与数据重加密

当主密钥需要轮换时（如每年一次或安全事件后），如何操作？

1. 准备阶段：在KMS中生成新的主密钥（KEK_new）。确保应用有权限访问新旧两个密钥。
2. 数据迁移：
   • 对于信封加密：写一个后台任务，遍历数据库，用旧的KEK_old解密每条记录的数据密钥（DEK），然后用KEK_new重新加密这个DEK，更新回数据库。这个过程可以低优先级、分批进行，不影响线上服务。
   • 对于直接加密：这是最麻烦的。需要停机或使用“双写双读”的复杂迁移方案：用新密钥加密所有数据，同时保留旧密文，直到所有数据都迁移完毕，再清理旧数据。强烈建议从一开始就采用信封加密模式。
3. 切换与清理：迁移完成后，更新应用配置，只使用KEK_new。观察一段时间后，在KMS中禁用或计划删除KEK_old。

6.3 性能影响与监控

加密解密是CPU密集型操作，会带来额外开销。

• 基准测试：在预发环境对关键API（如用户注册、登录、详情查询）进行压测，对比开启加密前后的QPS和延迟。
• 缓存策略：对于频繁访问且不常变的敏感数据（如用户基础信息），在解密后可以将其明文缓存在内存缓存（如Redis）中一段时间，并设置较短的TTL。务必确保缓存同样有访问控制。
• 监控指标：在加密解密函数中加入性能埋点，监控其耗时。关注数据库CPU使用率的变化。

6.4 调试与日志记录

在加密环境下，调试变得困难。你不能再直接在数据库里看到明文。

• 开发/测试环境：可以使用一个固定的、简单的测试密钥，甚至在某些环境下关闭加密（通过环境变量控制）。但必须确保这些密钥绝不会进入生产环境。
• 日志脱敏：这是铁律。在任何日志（应用日志、访问日志、错误日志）中，必须确保敏感信息被脱敏。在Node.js中，可以使用像pino这样的日志库，并配置自定义的序列化器来过滤或掩码特定字段。

  const logger = require('pino')({ serializers: { req: (req) => ({ ...req, body: maskSensitiveFields(req.body), // 自定义脱敏函数 }), }, });

• 审计日志：必须单独记录一份不可篡改的审计日志，记录“谁在什么时候解密（或访问）了谁的什么数据”。这既是合规要求，也是事后追溯的关键。

6.5 合规性考量

根据你的业务所在地和行业（如金融、医疗、欧盟GDPR），可能有特定的合规要求。

• GDPR：强调“设计隐私”和“默认隐私”，加密是推荐的安全措施。同时要求提供数据可移植性和被遗忘权，你的加密系统需要支持安全的数据导出和彻底删除。
• 等保/网络安全法：要求对个人信息和重要数据采取加密等保护措施，并定期进行风险评估。
• PCI DSS：如果处理支付卡信息，要求对持卡人数据（CHD）在存储和传输时进行强加密。

在项目初期，最好就咨询法务或合规团队，明确需要遵循的标准，并将其作为安全架构的设计输入。

最后，我想分享一点最深的体会：在Refine项目中实施数据安全，最难的不是技术，而是对业务逻辑的深刻理解和持续的安全意识。你需要和产品经理反复沟通，确定哪些是真正的“敏感数据”；你需要说服团队接受因为加密而带来的些许不便（如无法模糊搜索手机号）；你需要在每次新增字段时，都下意识地问一句“这个需要加密吗？”。安全是一个持续的过程，而不是一个可以一劳永逸开启的功能开关。从第一个敏感字段被存入数据库的那一刻起，这项工作就已经开始了。