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

——摘自《海龟交易法则》

BU 安全治理

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

以下是一些心得:

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

对于阿里集团来说，具有自己的安全团队 BU 似乎并不多。对于 PayPal 集团来说，似乎是一个比较常见的做法。当然也可能因为是金融业务对本地化有着相应的要求。因此 Paypal 甚至成立了专门去做 BU 安全的团队。

2. 按照做项目的套路来说, 一定要去寻找利益相关者（Stakeholder） 对项目方案进行立项/确认/签字(sign off)，根据预算建立相应的资源池(人力——全职/兼职/外包、Engineer/PM/Ops 等, 物力——软硬件资源)。PM 联系 BU 与集团两边的 POC，调度资源并协助双方完成项目实施。

这一点无论是阿里还是 PayPal 做得都比较好。说明成熟的企业都有一套完善的流程体系去管理资源。相对而言，阿里的效率更加高效。当处在员工位的时候就是一件比较困扰的事情，因为你可能下班时间还会被夺命连环 call。但实际上是不应该这么忙的，忙的没头脑反而容易出错。对于 2 中的一些 task，有些企业是让信息安全 BP 的工程师去做的。似乎滴滴是这样的（非指 BU 安全治理，而是指一些安全建设过程）

3. 安全建设过程中安全侧基础设施提供的能力是否可以快速满足业务增长/变化（比如业务增长，IT 架构变了，那安全产品的性能、容量是不是满足可扩展之类的）, 满足客户需求(安全部门的客户，企业的客户)。

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

4. 在建设的过程中知道什么是你的客户，知道什么是以客户为中心。

以客户为中心首先要知道的一点是不能一致对待所有客户,这不是说要对谁好对谁坏的事情。而是指在交付服务的基础之上，正确识别客户的能力，区别客户的重要性。假装酷一点的说就是 Business is Business. 关于这一块的知识可以参考一本书叫做《Customer Centricity: Focus on the Right Customers for Strategic Advantage》。

5. 建设的目的是为了拉齐安全水位，交付给 BU 一个可运营的安全体系。在建设的时候我们依赖木桶短板原理，建设完成后 BU 就是木桶（集团/生态）里的一个板。尤其是在金融企业中，银行、支付机构和企业之间都是通过特定授权访问的，一旦企业陷落，其实对于支付机构而言就是开了个授信的攻击口子（可能跨系统跨机构跨区域）。

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

6. 到底需不需要统一化？标准化？

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

7. 在一个点不足的时候，以另一个点去补足。权衡长期的解决方案，然后是短期重要的临时方案。

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

8. 在交付可持续运营的安全体系之后呢？BU 已经能够拥有了本地化运营的能力

可以适当的进行周期性的汇报。集团作为虚线进行同步状况。关于汇报仍要提一嘴的是，在建设过程中，是需要每周同步（实施者）以及每月汇报（Stakeholder）

9. 技术方面都是类似的。在不同的安全领域内提供基本的安全管控能力，以及所允许的最低限度安全水平。

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

后记

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

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