保护源代码，防止核心技术泄密，对于科技创新型企业而言，就是保生存，保前程。
保护得不好，可能活不下去；保护得好，奔向锦绣前程。
1. 研发人员本身才是难点所在
研发泄密向来是企业信息安全管理的重点和难点。
很多公司在投入大量精力之后，依然会因为时有泄密发生而摸不着头脑，或者陷入越监管越抵触而不得抽身。
传统的研发泄密管理或源代码防泄露，要么着眼于信息泄密渠道的封堵，要么以数据类型（或内容）识别为基础进行加密或权限管控，往往忽视了作为管理对象的“人”的因素。
研发泄密难管，难就难在“研发人员”身上。研发泄密管理要保护的是源代码，要管理的却是创造和使用源代码的研发人员。源代码的泄密渠道和数据类型与其他信息并无多大本质上的不同，研发人员才是这个管理话题之中的特殊部分。因此只有理解研发人员的特殊性，才能真正抓住研发泄密管理的关键，为构建正确的解决方案打下基础。
研发人员在安全管理中存在下面三个特殊性：
1.1 有动机
研发人员有泄密动机：
- 为人打工不如自己当老板。既然自己有创新能力，甚至还有几个追随者，为什么要给人打工？为什么不自己去做老板？尤其当想法已经在现在的工作中打磨成熟，准备充分，创业的成本和风险已经极大降低。而且产品方向在市场上起风在即，投资人已经抛来了橄榄枝。—— 想到这些，一些研发人员难免不动心思。他们要做的，就是把手上的源代码和资料整理一下打包带走。只要不被人发现就可以。
- 竞争对手收买。把公司新产品的一些资料、代码模块、甚至是完整的代码库，直接卖给竞争对手。只要稍加小心，神不知鬼不觉。—— 至于买家，公司楼下咖啡店里，常年就有。
- 自己研发不如高薪猎聘。站在竞争与成本的立场来考虑，自研不如猎聘是显然的。高薪挖角招来的研发，带来的不仅是技术能力，更多是开箱可用的源代码，避坑的经验和不需试错的方向。—— 而对于被猎聘的研发来说，带着源代码和资料走，是身价倍增的不二法门。
- 情绪性的冲动。研发都是有个性的。在争执之下，他们可能一时冲动删掉公司的数据库，也可能把源代码上传GitHub并开源发布。或者只是因为执着于自己不被认可的创意或判断，就一直琢磨着把代码带出公司，找个地方自己继续坚持。
- 学习和收集资料的癖好。研发都是善于学习的，而善于学习的人都有收集资料的癖好。时间长了，很多老员工电脑上的资料和历史代码比公司服务器上的都多。项目需要某些资料，还得在群里问才能找到。
- 离职前打包经验。离职之前，把所有自己能够触及的项目库都打包一份。换了工作之后，这些资料可以帮助自己快速在新环境做出成绩，好的模块和经验可以直接复用。
- 开源社区分享，技术交流，或者简单的炫耀。不论是自己同学，还是开源社区中某个素未谋面的朋友，只要他们有需要，就热情伸出援手。
- ……
有调研指出，研发泄密发生的数量和频率都远低于管理和销售部门，但造成的危害和损失却最高。对于企业安全管理而言，只要泄密动机存在，防范的弦就得持续紧绷。而且，越是频次低危害大的威胁，越是广泛存在的动机，就越是意味着更大的压力。
1.2 有权限
研发人员有泄密所需的权限。
总的来说，不论公司采取了怎样的安全措施，分配给研发的，工作所需的，必要的合法权限，就已经足够泄密所需了。而且事实上，在一般公司里，研发人员的权限总是“相对”最高的。依赖技术性的“权限管理”并不足以抵御研发人员“恶意的”或“处心积虑的”泄密。
一个相对常见的比较可以说明这个问题：管理岗容易限制终端权限，研发却非要给足不可。
一般公司里，可以要求办公人员（或管理岗）使用非管理员账户开展工作，甚至限制他们使用的软件的类型。这很容易理解，也容易被员工所接受。但如果对研发人员提出同样要求，哪怕开发工作事实上并不需要系统管理员权限，他们也总是能找到理由来进行抵制。比如“需要使用某个调试软件”，“不能覆盖所有测试场景”……安全管理人员往往没有权限（或责任）做出判断，没有能力判断，或需要付出过高的管理代价。
另一个更典型的问题是：夹带外泄。
夹带外泄在很多企业都是令人头疼的难点，甚至被认为是无解的问题。夹带外泄有很多种形式，但核心特征都是内部人员利用合法渠道以隐蔽的方式带出数据。举例比如：
- 将涉密信息压缩加密后，以对象形式插入可外发的Word文档中，再利用邮件外发权限或经过审批后发到外部。
- 将源代码压缩加密后，以软件资源形式打包到对外发布的软件、升级包或补丁里，再通过合法渠道外发。
- 将源代码或文档压缩加密后，以固件资源形式打包到固件程序、升级包或补丁里，再烧录到硬件设备中，并将设备以合法渠道带出。
- 更专业的情况下，研发利用专业软件来完成夹带行为，或者利用供应链上下游的协作在数据流中嵌入自动化的持续夹带。
- 有些研发有能力采用更高级的嵌入手段。比如视频或音频文件中嵌入水印（容量还是可观的），再比如有些自建外发信道的方法本质上也是夹带。
管理实践中的一个常见误区是：认为通过合理规划研发人员的权限，就可以避免研发泄密，或将研发泄密控制在可以接受的程度之内。
之所以说这种想法存在误区，原因有：
- 尝试去寻找一个合适的权限配置方案，就必然将边界推进到合理与不合理的边缘。最终导致管理工作陷入细节和特例，僵化，和失去客观标准。
- 研发泄密的攻击具有“遇强则强”的特征。如果是技术性的渠道封堵和权限控制，攻击者考虑问题的起点就是技术管控当前的上限。最典型的例子就是：物理空间隔离的管理方法以牺牲效率和尊重换来“绝对的”安全，而管理者却依然很快会陷入“防夹带”的焦虑之中。
- 信息总是需要合法流动的。看似在规划权限方案，其实是在规划信息流动合法与非法的边界。一来安全管理部门缺乏规划信息流动的权威，二来攻击者其实往往只在合法范围内寻找攻击机会。从逻辑上说，规划权限并不会起到决定性的作用。
1.3 有能力
研发人员有泄密所需的能力。
同等条件下，如果都动心起念打算泄露秘密，研发人员在执行能力上显然是最强的。但这其实并不是研发泄密难管的直接原因。或者说，研发泄密难管不是因为研发的技术无可战胜，而是因为研发的技术增加了管理的难度。
技术对抗没有错，但不能忽视安全的“可管理性”
很多企业认为“研发难管”，其实是因为他们寄希望于“安全管理的技术水平要比研发更高”。而既然选择了这个技术对抗的管理思路，自然就会陷入矛盾，反过来以为“研发具备技术攻击能力，所以难管”。比如：
- 如果管控选择了“使用VBA来禁止另存为菜单”，攻击自然就可以尝试“使用VBA来使能另存为菜单”；
- 如果管控选择了“禁止使用或清空剪贴板以防止信息拷贝”，攻击自然也就可以尝试“放开对剪贴板的禁止或禁止对剪贴板的清空”。
上面两例中的攻击方法其实都是“会者不难”的事情。可以说现行的大部分技术管控手段在面对研发自内而外的攻击时，都存在类似的逻辑。
当然，很多安全机制的设计会考虑安全功能本身的健壮，设计一些看护机制来提高攻击难度。但是，在管控点增多的情况下，看护机制需要处理的问题或漏洞会呈指数级增长。而且，看护机制与技术管控一样，并没有脱离“与潜在的攻击者进行技术对抗”的本质。面对有动机、有权限、又有技术能力的内部攻击者，在技术攻击与防御的层层追问之下，最终安全方案的设计者都会陷入矛盾的境地。最后，“我们是防君子不防小人”，“只是管理工具的辅助”，或者“我们采取了安全措施，规避了大部分风险，你说的只是特例”等类似的说法往往会用来结束话题。
囿于技术对抗的管理者，容易陷入两个极端：
- 放弃或躺平：研发就像无所不能的黑客，总有办法找到管控的漏洞，管不了；没有绝对的安全，够用就行。
- 迷信：你能搞定某个技术问题，我就信你；你的技术超出我的理解，我就信你；你牛逼，我信你。
其实，追求技术对抗并没有错。但因此忽略的安全的“可管理性”却是实实在在的陷入了误区。
反思一下下面几个说法，可能有助于理解上述思路在逻辑上存在的缺陷：
- 说“安全够用就行”的时候，我们并没有“够”的衡量标准。
- 说“我信你”的时候，可能仅仅代表“你的技术比我好”，并不能代表“你的技术可以解决问题”。
- 前例中提到的攻击方法并不会被当做“漏洞”来处理。相比于网络漏洞，很少见针对“自内而外攻击的”漏洞响应机制。
- 我们时常会陷入“安全工作的价值如何评估和如何展现”的迷思。
这些问题本身，都反应了我们在安全管理工作，缺少“可管理性”。
什么是安全管理的“可管理性”？
我们提出安全管理的可管理性，简单概述于此。
所谓安全管理的可管理性，主要包括下列内涵：
- 管理者能够以某种方式评估管理效果与管理目标之间的差距。也就是管理者知道哪些是做不到的，即残余的脆弱性。
- 管理者有能力评估差距带来的潜在影响。在安全管理中，就是管理者知道脆弱性带来的风险。
- 管理者有能力针对差距采取弥补或改进措施，并进一步评估改进效果。在安全管理中，就是管理者知道改进方法和方向。
通过前面的分析可见：过渡追逐技术对抗会导致失去可管理性，进而失去管理的客观标准，甚至努力方向。而反之，忽视可管理性，也可能让技术对抗失去节制。
攻击者具备研发能力，更多是增加了获得“可管理性”的难度
这个说法，有的读者会觉得有些难以理解，有些读者会觉得是废话。不得已解释一下：
- 研发能力强，攻击能力更强，自然增加了管理的难度。——从技术对抗角度来说，安全管理变得更加困难。我不否认这个观点。
- 技术对抗是安全管理的必要手段，甚至是安全管理的基础。—— 这个我们也不反对。而且，我们也认为追逐技术进步，应该精益求精，永无止境。
在前述分析的基础上，我们想要强调的是：
安全管理中的技术选择应该考虑可管理性，应该以可管理性为前提和基础来构建完整的安全管理思路。
研发人员作为内部攻击者，他们的研发能力，增加了管理者获得“可管理性”的难度。从两个角度说明：
第一，与已部署安全技术相关的部分。
具备研发能力的攻击者，他在实施攻击之前会做需求分析、POC、方案设计，甚至还可能去学习一点儿新知识。而技术对抗，总是会陷入道高一尺魔高一丈的循环，没有止境。但对抗过程中，攻击者一直处在隐蔽的、后发制人的有利位置。
在现实中，如果结合某个具体产品或安全方案来分析，对抗与防御的逐次推演将会很快导致问题变得过于复杂。当管理者觉得已经无法穷尽所有可能，且处处是漏洞时，他就会放弃对“可管理性”的追求。
第二，与已部署安全技术无关的部分。
假设管理者摆脱了技术对抗的思维陷阱，制定了更加明快清晰的规则。这时具备研发能力的攻击者，可以借口“业务需要”来试图打破规则。博弈过程中，每一个借口和背后的IT诉求，都会被管理者视作一个挑战：规则本身是否能满足需求？规则是否可以变通以适应需要？对规则作出的改变是否导入新的技术陷阱？
在现实中，使用技术来满足“业务需要”，而不是“坚持规则”，对每个管理者都是最轻松，最没有压力的选择。而这恰恰就是管理者失去管理主动的开端。
2. 管理者的尴尬地位
研发人员有泄密的动机、权限和能力，已经够让人头疼了。而考虑到安全管理者与研发人员的关系，就更加让人绝望。
存在两种安全管理者，分别是：
2.1 高层管理或老板
老板有管理的权威，执行力保障和强烈的动机。但一般而言，在安全管理上，老板的尴尬存在于：
- 老板自己作为资源是稀缺的，很难有足够的时间和精力投入到安全管理的细节之中。
- 老板最清楚的是目标，但涉及技术、业务和安全的细节，可能会缺乏判断力。
- 投鼠忌器。毕竟研发产生公司的效益，而老板亲自抓安全，不仅会担心影响效率，更加会担心影响士气。
2.2 职业的安全管理人员
职业的安全管理人员（ESMgr）具有安全管理所需的技术和管理知识，但相比之下，缺乏权威、执行力保障，还可能缺乏动机。
在很多时候，ESMgr处在相对被动的尴尬状态：
- ESMgr可以参与安全管理规范的制定，但在执行中常常不得不做出妥协。
- 说到底，安全是为研发服务的，不能以安全为理由降低研发效率，损害研发的创造力。
- 绝大部分情况下，ESMgr的技术实力不如研发。尤其是在研发自己专长的领域。
3. 小结
这篇文章分析了研发泄密为什么难管的原因。基于本文的分析，有助于管理者理解研发安全管理的深层次需求，做出更加合理的决策。
- 解释了研发在源代码泄密上有动机、有权限、有能力，这三者一起决定了研发泄密管理的困难。
- 解释了研发泄密中最大的一个难点：夹带泄密。
- 提出“可管理性”的视角，并且分析为什么可管理性是比技术对抗更重要的管理因素。
- 最后，简单分析了管理者在研发安全管理中所处的尴尬地位。
言尤未尽。但也必须指出：实际经验告诉我们，研发人员其实往往是一个公司最忠诚、最有创造力、最有价值的群体。研究对研发人员泄密的管理，出发点并非是不信任，而是在信任的基础上研究如何保护大家共同的劳动成果。
