数据安全的第一道坎

此文源于5月受春哥（李维春，安信证券安全负责人）之邀在深圳一次线下面基时做的分享交流内容。

一、 写在正文前

在进入正题前，一如既往地先说些题外话。

这些天，我正在听魏炜讲商业模式的一些视频课。听课过程中，突然发散了一下思维，总结发现了一个关于安全行业的很有意思的事，就是：国内安全行业中，无论甲乙方，很多人对待各种安全理论框架的态度，似乎都是一种“自下而上“的”套用“，而不是”自上而下“的”沿用“。

“自下而上“的”套用“，多是基于现有的产品、解决方案、技术措施、管控流程等，寻找可以”套“进去的理论体系，来证明自己的可行性、先进性，是有理论指导实践的，再对应的做一些差距补齐。

”自上而下“的”沿用“，讲的是一个事情应该怎么想，应该怎么做，哪些可以做，哪些优先做，是一个逐层解构、逐项分工、滚动落地、持续改进的PDCA过程。这个过程中，理论体系的真正作用，更多是一个内部认可的统一方法论，而非一个功能、流程的映射表。

典型的就有：对IPDRR、CARTA、Kill Chain、ATT&CK、SA&O、ZeroTrust、DSMM等模型、框架、方法论的“套用“所引发的填词运动。还有就是各大会议上见到的，与真实情况有较大差距的各种框架图、概念图。

这种对待理论框架的态度偏向性，导致我们看到的安全产品、工具、管控措施、运营机制、流程制度，甚至是人员的培养…等等，普遍存在很明显的体系化程度低、适应性能力差等问题。甲方安全买了一大堆产品，用了一大堆服务，做了一大堆事，却总是感觉实际成效不可证明、不可解释，最终沦为“救火队员“，还常被乙方吐槽难伺候。

或许在这个快节奏的、习惯了“自下而上”思维的世界，换一个方式来思考和行动，会有更好的结果。

二、 先讲背景，认识困难

虽说题目定的是“数据安全的第一道坎”，实际内容更聚焦于“个人金融信息”这个范畴。

这两年，金融行业监管对个人金融信息的安全管控盯得很严，加上数据安全法的发布，导致数据安全和个人金融信息保护几乎成了各家金融机构的达摩克利斯之剑。于是，怎么保障个人金融信息的安全，在满足监管的合规需要的同时，又能确保自身业务发展不受影响，成了一个考验各家金融机构安全团队的战略规划、组织架构、体系设计、技术选型、实践落地、项目管理、内部协同、人员素质等全方位综合能力的大命题。

作为一个半开放式命题，各家金融机构，以及与之相关的厂商们给的答卷也各不一样，有的写成应用文，有的写成议论文，有的交的是纪实文学，有的则是章回体小说，还有的是散文，亦或者诗歌。从结果和成效来看，难有公论。

在这样的背景下，数据安全，或者说是个人金融信息保护，势必成为甲方安全未来很长一段时间的发展重点，既有挑战，也是机遇。

从企业架构（EA）来看，数据安全与传统的网络安全最大的不同，一是在于数据安全离业务更近，甚至绝大部分时候是跟业务强耦合的，安全要面对的已不再只是运维，而是开发、业务、法务、人事、行政…甚至是外部的合作伙伴和用户。二是在于数据安全的主体不再是底层的基础设施，而是在基础设施上存储、使用、流转的数据，数据海量、多样、变化、实时等特性让传统安全产品和工具的单点“蹲防“机制很难适应。

这两个因对象不同导致的核心不同点，决定了数据安全要做得好，必然是成体系、强内嵌、多关联、重流程、重协同、重运营的。在我看来，这是一个大前提，也应该是数据安全的整体指导思想。

三、 先搭架子，再谈落地

可能是上天的旨意，在写到这段的时候我正好看到了Steve Yegge2011年对Amazon和Google的那篇著名的吐槽（SteveY’s Google Platforms Rant）。直至2021年的今天，他在文中说的“平台派”和“产品派”的斗争，依然无处不在，依然是处于劣势的、少数的平台派VS优势的、自信的产品派（原文是：What we have going on internally is basically a war, with the underdog minority Platformers fighting a more or less losing battle against the Mighty Funded Confident Producters.）。

实际在我理解，平台派和产品派之争，很多时候在于：尝试用平台，用架构解决一系列的基础性问题，还是用产品，用工具去解决几个特定场景的问题。

毫无疑问，后一派更受欢迎，因为风险更小，成本更低，场景更聚焦，成功机会自然也越高，这也是越来越受推崇的，所谓的“快速试错、先做后说“的文化：如果失败了，那就快速转向，再试一次；万一成了，产品就成了，做产品的人也成了，那做的就是对的。

而平台派的劣势在于，做一个平台并不会马上给带来成功，平台需要杀手级应用才能体现它的优势，或是等到产品到天花板。

但是，也正如Steve Yegge所想表达的那样，等到各个产品都已经根生蒂固了，再想整合成平台，不单纯是要花十倍的精力，而是要经过剧烈的文化转变和内部博弈（我更想说成是”流血的剧变“，因为必然有人会因此失意或离开），否则不足以打破由产品、工具构筑的业务、数据、应用、基础设施乃至组织、职责等层层壁垒。

因此，当我们团队开始讨论数据安全这事该怎么做的时候，或者说是在平台、产品两个路线之间做抉择时，我就表明了我的态度：不要做博弈，在做具体场景的快速落地的同时，一定也要“先搭架子，再谈落地“：抛开现有的产品、措施和职责，只关注应该做什么，应该达到什么效果，再看怎么取舍，怎么落地。双向验证，双向指导。

四、架子要正，得有思考

既然是“先搭架子，再谈落地“，那么搭架子就成了一个”自上而下“的事。如开篇所说，这是一个逐层解构、逐项分工、滚动落地、持续改进的PDCA过程。

因此，第一层的大框架，或者说在现有理论体系中寻找可以支撑用统一的方法论去指导数据安全落地的基本框架，是重中之重。”上梁不正下梁歪“，这个框架有问题，代表着想法有问题，想法有问题，动作就变形，连锁反应下，自然很难达到预期效果，甚至会离题万里。

因此，经过内部反复讨论，我们确定了数据安全管控的基本框架主要依托两个权威的通用模型：

一个是被教父（Xundi）戏称为“屌丝美眉“的DSMM（数据安全能力成熟度模型），以支撑我们对数据生命周期的阶段定义，和对应的能力分类。显而易见的，各阶段需要达到不同的能力，也需要不同的管控措施。当然，DSMM标准中也提到，有很多能力实际是需要贯穿数据生命周期始终的，是需要统筹考量、统一实现的通用能力。

另一个是NIST 提出的Cybersecurity Framework框架，即IPDRR（识别-保护-检测-响应-恢复）框架。IPDRR框架最大的优势是通用性和可扩展性。在这个框架基础上，我们根据自身做安全大运营（即统一运营）的需要做了变形，变成了EM-IPDRR（E是评价，M是管理），来支撑我们对在每个环节的实际能力的考察与匹配。

值得注意的是，EM-IPDRR各层之间的能力、数据是有一定的继承和关联关系的。举个例子，当你的某项资产识别并不能做到100%的准确和覆盖的时候，你的防护、检测，乃至响应、恢复，必然也会有错误和遗漏，而且会随着逐层的数据流转和处理造成的误差，逐步放大。到最后，基于IPDRR去做运营的管理和评价，必然会影响到最终的安全度量。

所以，真正的体系设计，需要考虑的是各层能力间的数据、流程的关联和交互该怎么做，哪些措施是继承前一层能力的，哪些措施是用来当作补偿措施用的。而不是画一个看似有道理的图就了事的。

借助DSMM和EM-IPDRR，我们做了一个自己的数据安全管控框架，用来定义整体层面的数据安全生命周期、需要管控的对象、需要考虑的管控手段，并逐步归纳我们自己的一套方法论去指导落地实践。而这两套框架的融合，自然而然地就形成了一个如下图所示的数据安全能力矩阵（我们自己简称为DSM，Data Security Matrix）。

DSM矩阵相比原始的DSMM和IPDRR框架，更符合我们自己对实际情况和自身能力的认知，既体现了我们用统一的方法论去尝试解决数据安全问题的一个美好愿景，也充分预留了PDCA做持续改进的空间，还能融合现今已有的产品和能力。比如：

1）我们把每个生命周期阶段的I（识别）能力拆成了资产识别和需求识别两大部分，一个从实际的数据资产角度出发，一个是从可能的需求角度出发（包括业务需求、安全需求和合规需求）；

2）我们把P（保护）能力拆成了安全防护和安全控制两部分，因为我们认为防护和控制，在具体落地措施和能力显化、运营上会有不同的设计逻辑；

3）我们正在把D（检测）能力做分拆（当然现在还没有拆，所以图上没有调整），打算拆成监测/检测和审计两部分，因为我们在实际工作中，监测/检测的运营方式、数据分析方法及工具形态，与审计是不太一样的。混合在一起会有很多模糊不清的界限。

4）同时，我们在管理和评价层面，设计了两个统一能力的大平层，就是打算通过统一工作流、统一安全服务目录、统一安全知识库，以及统一的风险指标和运营指标体系等等，结合底层的数据、流程、工具的整合，形成一个可以看得清楚、讲得明白、“风险驱动”的数据安全运营机制。

所以，DSM框架就是这么一个矩阵，横向是数据生命周期各阶段，纵向是安全管控的各种能力域。每个矩阵区块，就是一个可聚焦的能力子域。每个能力子域，与其上下、前后的其他能力子域，在数据、流程、工具等方面必然存在联系和对接需求，也必然存在反馈的要求。

此外，DSM框架给我们带来的最大好处在于，我们终于可以看清我们面对的数据安全管控形势的全貌，也有了一个可以将所有参与者拉到一个统一知识体系下进行讨论的基础。各个具体能力在填入框架时，我们就能主动或被动地去引发内部的讨论，一方面能很快地说清楚为什么需要这些能力，另一方面也能很明确地对这些既定要有的能力做更进一步的拆解，明确其必须要满足的前提条件有哪些，我们的现状是怎样，其输入是什么、处理是什么、输出是什么，现有的产品/工具/流程/运营有无满足要求，其技术的可行性和成熟型，在行内有无落地的可能性，谁来负责落地更合适，需要什么层级的支持，以及需要投入的成本（资源、建设及运营成本）…

这种有的放矢的讨论和推动，即可避免经常发生的那些不在一个点上的、无谓的内部争吵，又可以快速分析和决策具体的落地措施，甚至是路线图，还可以把棘手的问题快速剥离出来，聚焦后再上升到更高层决策。

五、识别下手，先打根基

DSM框架出来后，显而易见的，无论是从数据安全整体考量，还是从敏感信息，或者是个人金融信息的细分领域考量，首要的问题都是要明确治理和保护的对象是谁。因此，识别（Identify）都是基础，而其中的数据资产识别更是基础中的基础，这应该是行业共识。

然而，在我与很多人具体聊到数据资产识别的时候，却发现另一个问题：识别做什么？或者说是识别的对象是什么？大部分厂商，都是基于自身的产品设计来定义识别的对象，总觉得差些什么。而甲方中，也很少明确地说出识别要做什么，更多的是在说具体的识别手段，即我已经做了什么。

而依照DSMM的生命周期，不同阶段都有不一样的数据资产识别要求，看似各有侧重，实际内在是有一定的抽象逻辑的。因此，从识别下手打根基，有必要做统筹考虑。

在我们自己内部的讨论中，对识别的定义，以及识别的对象是什么，也是有过争论的。最终我们内部达成的一个初步共识，是把识别定义为需要做识别的数据资产“长什么样、从哪儿来、在哪儿存、到哪儿去、归谁来管”。这五块，我们认为是整个生命周期的数据资产识别的通用逻辑。

相比于很多厂商将识别只限定在“长什么样”和“在哪儿存”，我们加了“从哪儿来”和“到哪儿去”，可以简单理解为“输入”和“输出”。这么界定，实际是有参考STRIDE威胁建模的一些方法。输入和输出在一定程度上是定义了信任边界和识别的观测边界，可以用来做数据流转的链路跟踪和对应的风险建模（包括资产建模、威胁建模等），同时也可以确定识别和后续管控需要覆盖的范围及能力方向。

所以，一定程度上，如果讲识别，却不讲“从哪儿来”和“到哪儿去”怎么做的，都是耍流氓。

此外，“归谁来管”是最容易被忽视，却是实际工作中必然会遇到的。监管要求谁对数据的安全负责？内部具体的数据认责该怎么做、谁来做和做到什么程度？以及在整个认责体系中，安全的定位到底是怎样？这实际也是识别的重要组成部分。说句实话，认责做不好，定位谈不清，安全想要搞数据资产识别，或是推动数据安全体系落地，那就很容易变成“自嗨”。

这里发散一下。在内部讨论确定了识别的定义后，我们已经非常清楚地意识到：识别这件事，银行安全团队不太可能具备独立完成和承担的能力。

首先，银行安全团队的职责和组织架构层级，大多没达到一个强力一级部门的程度，要想做横跨多个部门、多个领域，推动力不够。

其次，银行的业务复杂度极高，面对的环境极为复杂，老的、新的，啥都有，跟个大历史博物馆似的，加上各类数据有的有特征，有的无特征，还有大量历史遗留问题，安全要做到都能了解，都能掌握，都能适配，都能落地，能力肯定不够。

因此，数据资产识别，必然是个多部门协同的大活。安全在这个事上，可能是牵头的，也可能只是配合的。

所以，在开始做事前，先要摆正心态，我们的核心目标是获得我们想要的结果。基于这个目标，无论我们是牵头的，还是配合的，亦或者就是个纯粹的数据消费方，只要有人站出来把任务领了，而且做好了就行。如果没人愿领，那就需要用其他的方法，去寻找大家在这件事情上的共同利益。用利益驱动，可能是最容易达到目标的方式。

好了，下面言归正传。

在确定识别的定义后，我们接下来就是根据定义和实际情况，来确定用什么手段来实现。由于我们的工作重点在一段时间内会比较聚焦在个人金融信息领域，因此，接下来说的也局限于个人金融信息领域。

六、知易行难，难在落地

首先，无论什么类型的数据，做资产识别的手段大抵可以分为静态和动态两大类。

静态关注的是在一定空间和时间内持续存在的数据，简单理解就是“长什么样，在哪儿存”。

动态则是关注实时/准实时的数据流转，即“长什么样，从哪儿来，到哪儿去”。

至于“归谁来管”，则是根据静态和动态识别的结果，依照统一的认责规则和要求，去确认资产的属主和相关方。

因此，静态个人金融信息识别手段的差异性体现在以下两个方面：

1）数据的类型：即“长什么样”，或者说是有无明确的识别特征。有特征和无特征的数据会用到不同的数据识别手段。典型的就有：姓名、卡号、证件号这些是有特征可以识别的，而收入金额这些就一串无规律的数字的可以认为是无特征的。

2）存在的位置：即“在哪儿存”，或者说数据的存储载体是什么。比如数据中心的数据库，大数据平台，个人办公终端，存储设备，抑或是缓存、消息队列等，会用到的识别技术和手段也会各不相同。

而动态个人金融信息识别手段的差异性体现在以下三个方面：

1）数据的类型：与前面一样，不赘述。

2）数据的来源：即“从哪儿来”，或者说数据的输入来源地是什么。会涉及到数据源、数据链路，以及对应的上游应用、服务、接口等等。

3）数据的流向：即“到哪儿去”，或者说数据的输出目的地是什么。会涉及到数据链路、外发对象，以及对应的下游应用、服务、接口等等。

基于以上对静态、动态识别手段差异性的拆解，我们再对标当下业内的最佳实践和厂商产品，基本能把握住落地的脉络，知道哪些肯定可以做，哪些不确定能否做，哪些肯定做不到。

可以做的就直接推动相应的技术选型和上线，不确定的就在内部和外部咨询可行方案，做不到的搞明白做不到的原因，把对识别的影响分析清楚，写好调研和风险报告，在内部统一认识，等待落地条件成熟。

当然，还有一种情况是已经做了的。对于已经做了的，这时候更多是看有没有达到预期，或者是应该有的效果。比如识别覆盖面、识别率、识别完成率，以及识别工具的运营管理情况等等。 下面就以我们自己正在做的个人金融信息识别工作举几个例子。

七、第一个例子

第一个例子是对数据中心中存储在数据库和大数据平台内的、有特征的、结构化的个人金融信息的静态识别。我们认为这是一个可以做的。

所以，我们根据行里的实际情况，和运维的DBA团队、大数据的数据治理团队一起协作，搭建了一套针对性的数据资产识别系统。

其中，DBA负责根据需要按天推送所有的数据库的库、表、字段信息及对应的表结构变化数据，以及数据样本采集的取数/扫描接口。

大数据的数据治理团队则负责提供大数据平台侧已经做好的元数据信息及识别数据，以及数据认责信息。 这是已有结果，我们不用操心，就安心当个消费者拿来用，最多再做下标准化就是了。

而我们安全团队的工作，一是对接获取这些基础数据，二是设计采样触发器，在出现表结构变化时（库、表、字段的增、删、改），依托DBA给的接口去取样本数据。三是设计识别和分类分级引擎，对有特征的，可用识别规则进行识别的个人金融信息进行自动识别和分类分级。四是提供操作、管理界面，提供诸如人工标记、数据查询、识别规则调整、资产地图等功能，五是把多方都确认或认可的结果作为权威数据，通过数据接口提供给DBA、数据治理、应用安全、合规管理等各团队，在一些需要这些权威数据的风险管控场景和流程（比如生产导数脱敏、DB系列工具的风险操作审计、SDL安全评审、合规审计等等）中去使用。

让我们意想不到的是，这个系统提出来和整个落地过程中，最积极的居然是DBA。后面我们才认识到，DBA为什么急迫需要这类的个人金融信息识别的权威数据，是在于他们需要这些数据来支撑他们对自己DB系列工具的风险操作审计，他们自己不放心怕被滥用，也怕天天会被监管和安全找麻烦。这就是一个共同利益点。

所以，当一件事情，大家都认识到它的价值，或者你能挖掘出来的共同利益点越多，协作就越好谈，推动就越容易。比如我们这个系统，从论证到立项再到上线，前后不到半年，各方间的配合都非常积极、顺畅，效果可期。

八、第二个例子

第二个例子是针对内部数据链路及对应的上、下游应用、服务、接口的动态识别。我们认为这是一个不确定能否做的。因为众所周知这件事的复杂程度。

因此，我们在内外部都做了调研，寻找可能的落地方案。发现业内典型的做法有两类：

一是基于旁路流量识别技术，通过旁路关键区域边界的网络流量，对流量进行协议解析，再对解析后的数据进行敏感数据本身及相关流转链路的识别。

这是一个非常成熟的识别方案，其优点很明显：旁路，无感，对生产环境无影响，技术成熟，可快速获取原始数据，有成熟的商业产品。

而其劣势也很明显：

首先，旁路观测到的原始数据到真正可用的识别结果之间仍有较大的鸿沟，还是“盲人摸象”。

其次，整个方案受制于解析能力和部署位置，识别结果的可用性、准确性、覆盖性仍有问题，且很难覆盖内部的链路和上下游关系。

最后，安全仍是“黑盒”视角，离实际业务/开发的场景和逻辑较远，原始识别的结果仍需要线下介入去确认与沟通，在银行复杂内部环境下的运营成本较高，且很难标准化。

所以，我们认为，此类技术的适用场景应该是：

1）有非常明确的上下游关系的、或是有统一入口/出口的数据链路识别与管控。比如银行与第三方机构之间的统一数据出口。

2）关键安全域边界的未知或异常的数据链路监测与发现。比如核心数据库区、核心应用区。

3）对其他静态或动态识别手段的有效性做反向验证。

而继续深入去看和总结测试的经验，我们还发现，这个解决方案的核心技术基础在于对流量的协议解析，在架构上与其他旁路工具有很高的重合度。因此，有没有可能把流量的协议解析做成统一的，再在后面按需挂接对应的识别模块和链路监测模块。这是一个有意思的话题，当然，短期内暂不考虑。

因此，这类解决方案在这种解析下，就从一个不知道能否做的，变成了一个可以做的事，而且是预期结果很明确的一个事。我们就可以去推动落地了。

二是侵入式agent/SDK识别技术，通过类IAST插桩的方式在应用服务器端部署agent程序，或是通过SDK方式由应用内嵌调用，来收集、监控Web应用程序运行时函数执行、数据传输，基于请求、代码、数据流、控制流综合分析判断，对敏感数据本身及相关的调用链路和服务、接口等进行识别。

这种解决方案从能实现的效果和能力上来说，明显强于前一个旁路方案。其优势在于：方案是嵌入/耦合至应用架构内部的，安全能获得“白盒“视角，且只要达成覆盖，就可以比较完整和准确地识别整个数据流转链路，对对应的上、下游应用、服务、接口实现动态识别。

但在测试过程中，我们发现劣势也非常明显：

首先，开发、运维对安全用强侵入模式做监控和识别有天然的抵触和不信任。

其次，agent/SDK的兼容性（与开发语言强相关、与应用架构/组件强相关）与稳定性保障问题，并没有很好地得到解决。

再次，这套解决方案对安全团队自身架构能力、研发能力和运营能力提出极高的要求。

最后，如果用这套方案，安全将要承担生产稳定的重任，无法享受以往的“旁观者”待遇。

因此，如果依托于外部商业产品，在没解决兼容性、稳定性问题的情况下，这类方案在短期并不具备可落地性。

但是，我们在解析这套方案的核心技术原理后发现，其做法与行内架构团队的应用埋点监控APM非常类似。而APM已经通过比agent侵入性更强的SDK模式，覆盖了绝大部分的应用。所以，换一个角度来考虑问题，是否可以借助架构的力量和架构的APM SDK，植入安全所需的数据识别和链路监控需求来实现？是不是这样就完美地避开了这类方案的种种劣势？这正是我们正在和架构协商，努力推动的事情。

九、第三个例子

第三个例子是对个人办公终端上存储的、有特征的、非结构化的个人金融信息的静态识别。我们认为这是一个已经做的，也就是HDLP。

因为监管要求，HDLP我们很早就部署了，而且做到了全行的统一覆盖，也有日常的监测与审计，定期与不定期结合的检查，以及相应联查联防机制。

然而，从效果上来看，HDLP并未完全达到我们预期的效果。主要在于以下几点：识别的误报率很高。因为需要线下人工确认，很难线上/自动化运营，导致运营成本很高。此外，行为监测能力较弱，这个敏感数据或文件是怎么到的办公终端，说不清楚。

因此，HDLP对于我们的识别而言，只能说是具备了一部分能力，离理想的预期结果还有差距。这种情况下，我们评估的结果是：

1）如果业内的最佳实践和商业产品没有突破性的进展，我们可能只能接受这个结果，等待更好的方案和产品成熟。

2）是否可以考虑利用行内的资源，在一些方面去尝试做些定制化的提升？比如尝试与EDR结合，弥补HDLP对行为监测和审计的不足？或是利用行内开发团队的RPA机器人资源尝试做线上/自动化运营？再或者借助大数据团队在机器学习、内容识别方面的力量，提升对文档、图片这些非结构文件中的敏感信息的识别准确性？这就引发了对一些很有意思的可尝试路径的思考。

十、写在最后

写到这里，基本想说的都说完了。对与不对，任凭评价。这里只说我自己的一些体会：

首先，数据安全不是安全一个领域、一个团队的事情，我们应该把眼界和格局放大一些，学会用DevOps的理念来看问题，把利益相关方拉进来一起协作，找到大家的共同利益，推动一种协同的文化或者共识。至于业绩问题，花开两朵,各表一枝，用结果说话。总而言之，牢记一点：协同事半功倍。

其次，前文所说的体系化的这种做法，与我们现在很多针对具体场景去快速落地的做法并不是冲突的。”自上而下“和”自下而上“不是零和博弈，而是一个凿山修路时”从两端向中间凿进“的标准做法。所以，路线之争是最无聊的，最后搞成零和博弈，于事无益。

再次，从我个人理解来看，如果站在监管的视角，或是高层领导的视角，数据安全这个事，实际是个证明题。从命题的题设出发，经过逐步推理，来判断命题的结论是否正确的过程，这叫做证明。所以，题设（也就是前提条件）、推理过程、结论，缺一不可，少一个都是耍流氓。谁都知道无法做到绝对安全，谁都理解总会有力所不能及的地方，但是你得有清晰的推理过程和结论，来证明某个事的确是个绝对安全问题，或是的确力所不能及。如果搞不清楚这个逻辑，很多时候会落到有苦说不出的境地。

最后，不要低估数据安全这件事的复杂性。一个数据资产识别，就已经有可见的多个难以解决的问题等待我们解决。厂商们在宣传时，还有自己人在做事时，要尊重客观事实，要多换位思考，要对实际环境的复杂性有所敬畏，也要认可用架构思维来解决复杂性问题的必要性。大家一起脚踏实地做事，老老实实做人，努力修成正果。