遗憾的是，在大多数领域中，真正的行家都寥寥无几。每一个真正的专家都被淹没在大批冒牌专家之中。
这些冒牌专家在行业里占据了一席之地，东拼西凑了不少的知识，在外行人的眼中，他们与真正的专家没什么区别。他们也有作用，但他们并不是真的理解他们所混迹的领域。
真正的专家没有一成不变的法则；他们胸有成竹，所以他们不需要僵化的法则。
—— 摘自《海龟交易法则》

BU安全治理

针对BU安全治理，总结了在两个集团内所做的一些安全工作。一是阿里集团时在本地生活业务中的安全建设，即包含了饿了么(包含饿了么星选，即原百度外卖），口碑（其实隶属蚂蚁集团），客如云。除此之外对其他BU的建设资料很少有看到。二是PayPal集团，主要是GoPay的安全建设。同时参考PayPal在过去几年内整合企业时的BU安全资料。例如:Curv, Honey, Simlity, Venmo, Xoom, Hyperwallet, Braintree等。

以下是一些心得:

对于集团来说，BU安全应该当做一个具有特定周期长度的项目来做，而不是持续投入。反之，对于BU而言，在接手之后开始需要持续投入精力。

对于阿里集团来说，具有自己的安全团队BU似乎并不多。对于PayPal集团来说，似乎是一个比较常见的做法。当然也可能因为是金融业务对本地化有着相应的要求。因此Paypal甚至成立了专门去做BU安全的团队。
按照做项目的套路来说, 一定要去寻找利益相关者（Stakholder） 对项目方案进行立项/确认/签字(sign off)，根据预算建立相应的资源池(人力——全职/兼职/外包、Engineer/PM/Ops等, 物力——软硬件资源)。 PM联系BU与集团两边的POC，调度资源并协助双方完成项目实施。

这一点无论是阿里还是PayPal做得都比较好。说明成熟的企业都有一套完善的流程体系去管理资源。相对而言，阿里的效率更加高效。当处在员工位的时候就是一件比较困扰的事情，因为你可能下班时间还会被夺命连环call。但实际上是不应该这么忙的，忙的没头脑反而容易出错。对于2中的一些task，有些企业是让信息安全BP的工程师去做的。似乎滴滴是这样的（非指BU安全治理，而是指一些安全建设过程）
安全建设过程中安全侧基础设施提供的能力是否可以快速满足业务增长/变化（比如业务增长，IT架构变了，那安全产品的性能、容量是不是满足可扩展之类的）, 满足客户需求(安全部门的客户，企业的客户)。

例如阿里集团19年的时候就已经在提倡全面上云了。饿了么也由4+个线下IDC逐渐缩减，从最开始的流量入口上云，数据回传数据中心。到后面新零售业务整体走阿里技术栈，业务部署弹内（可以简单理解为公有云上的阿里租户，供阿里用户使用）。对应中间件的改造，舍弃，合并等。百度外卖那一套，饿了么原来的一套，新零售一套，口碑走的是蚂蚁技术栈，在蚂蚁的IDC中。在统一上云的过程中，对流量的清洗，指纹的植入，全端全链路的覆盖等等解决方案的设计是必须要考虑到业务变化带来的影响。同样，在PayPal集团，集团一部分是在GCP，也有在AWS的，同时对于一些BU，甚至可能在3-4个云上。以及在IDC的。有的使用的是IAAS服务，有的是使用PAAS服务。还有的直接是以k8s做跨云的部署。不尽相同。安全建设也很大不同。
在建设的过程中知道什么是你的客户，知道什么是以客户为中心。

以客户为中心首先要知道的一点是不能一致对待所有客户,这不是说要对谁好对谁坏的事情。而是指在交付服务的基础之上，正确识别客户的能力，区别客户的重要性。假装酷一点的说就是Business is Business. 关于这一块的知识可以参考一本书叫做《Customer Centricity: Focus on the Right Customers for Strategic Advantage》。
建设的目的是为了拉齐安全水位，交付给BU一个可运营的安全体系。在建设的时候我们依赖木桶短板原理，建设完成后BU就是木桶（集团/生态）里的一个板。尤其是在金融企业中，银行、支付机构和企业之间都是通过特定授权访问的，一旦企业陷落，其实对于支付机构而言就是开了个授信的攻击口子（可能跨系统跨机构跨区域）。

如果BU没有安全团队，那就是直接统一化建设了，所谓的可运营安全体系也是和集团完全相同了。对于BU间没有强生态依赖的集团，应该不存在生态中的短板问题。在交付BU一个可运营的安全体系时更倾向于Site环境（生产业务）的建设，针对Corp（办公网）相关的一般是统一化标准的。包含了账号体系，身份验证，终端保护等等这些应该是统一的。
到底需不需要统一化？标准化？

参照第5点BU是否有自己的安全团队。这个问题在我脑海里持续了很久。依照之前在本地生活的观念肯定是认为统一和标准更有利。可能因为阿里的是文化强势，也可能因为这样可以拉齐水位的同时，在相同的平台上BU安全的同学也能施展自己的能力，把得到的数据和集团互补。但现在我是不这么看的，而且实施起来也没那么容易。集团和BU之间权限过于分明了。现在我的看法是面对不一样的东西，并不是所有东西都一定要标准化，统一化的。如果能够适当的完善的满足现在的场景需求就可以了，因为即便是二次建设，目标也不过是为了满足现在的场景需求。比如有的BU用Fortify，有的用Sonarcube; 有的用Twistlock有的用Aqua; 有的用Safenet HSM，有的用Cloud HSM. 只要满足合规压力的时能够支撑起现有的业务运营，同时符合安全baseline，那就没有必要大费周章去改变。
在一个点不足的时候，以另一个点去补足。权衡长期的解决方案，然后是短期重要的临时方案。

例如金融企业每5年一次的牌照申请和每年一次的牌照更新，如果失败则意味着业务无法继续。那么在这个过程中如果说我们没有自动化的权限管理系统，是不是可以把权重从技术调整向策略+运营（技术，策略，运营三大块），把每个权限的开启通过现有ticket系统进行审批，允许后在对应开启权限部分引入ticket编号。将其作为一个强制策略执行。同样的对于数据而言，如何确保所有的敏感数据都被完全删除了？当以技术手段识别到相应的存储资产并通过不同手段进行擦除时，仍应该同实施方签订具有法律效应的合同/保证条例。
在交付可持续运营的安全体系之后呢？BU已经能够拥有了本地化运营的能力

可以适当的进行周期性的汇报。集团作为虚线进行同步状况。关于汇报仍要提一嘴的是，在建设过程中，是需要每周同步（实施者）以及每月汇报（Stakeholder）
技术方面都是类似的。在不同的安全领域内提供基本的安全管控能力，以及所允许的最低限度安全水平。

例如在应用安全上的要求，数据安全上的要求，基础设施上的要求等等。然后通过技术-管理-运营三方协作落实下去。这个过程有个情况就是建设过程是从0-1还是从1-N，一般来说M&A的企业，怎么着也是有一定的规模。理论上是有安全建设的，无论是成熟度怎么样。但实际上有的企业可能直接依赖了云，而没有自己的核心安全团队。同样，有时候还会面临收购之后打散重来的可能性，例如只是为了这个收购这个产品，以便拥有其对应的用户。在具有成熟BU安全体系时，BU从0-1的安全建设甚至要比从1-N更有效。除此之外还有并购与收购方的情绪问题以及安全团队是否要重新组建的问题

后记

准备写BU安全治理的文章已经有一段时间了。然而落笔时却尤为不易。虽然我自己有过一些从零到一的安全建设经验，也有过被集团赋能的经历（即是被整合的安全侧）。纵观这些相似的过程，不一样的结果。在经过一段时间对这些过程的回顾以及资料的整理后，更加意识到了所学有限，持续学习是一场耐力赛。这也是我为什么摘了一段《海龟交易法则》中的文章放在文首，因为“专家”实在是太多了。

最近读了一些书，也看了一些文章。整理了不少笔记，挺充实的，也很累的。学习要比工作更消耗体力。针对这篇文章，本身是有许多资料的，不过是不能写在这里的。每一个BU安全项目都是一次学习体系化建设的好案例。