0x00 前言

六年前开始在博客记录“架构”相关的知识（参考《放之#安全架构》），三年前做企业安全的思路已经基本成型（参考《我的企业安全观》）。数载春秋，有过犹豫，有过怀疑。正所谓驽马十驾，功在不舍。今天，再来谈谈我对企业安全的一些认知，亦或者说是，作为一个安全架构师的自我修养。

0x01 架构演进中的安全设计原则

应用从单机到分布式。架构也在逐渐的演变，从单体开始，到C/S架构，服务器端做集群。再到分层架构再到SOA，以及微服务和Serverless架构。有的人说是业务需求驱动着架构演进，也有人说是算力变化驱动着技术迭代。至于背后的原因，可能需要亲身经历过的才能知道一二。我没经历过，就不胡乱猜测了。不过这些都不是新的东西，无论是应用的架构还是安全的设计理念。最小化权限（Least Privilege）最早在70年代提出，纵深防御（Defense In Depth）在90年代提出，哪怕是最新的零信任（Zero Trust）在2010年由Google推广出来之前，也早已在1994年被Dr.Stephen Paul Marsh创建出来。

// 注：Application Architecture列既有Architecture Style也有Architecture Pattern，方便对比，此处仅用Application Architecture统一代指。

回到前面，且不谈技术趋势演变的本质到底是什么。对应到编程语言的变化，从以C为代表的面向过程的编程语言到C++开始进行面向对象编程，以及后续的函数式编程（Function Programming）等等。除去早期的AD-HOC的编程，配置（早期应该也没有安全设计概念，起码在检索这些安全设计原则之初没有发现）。当应用从单体架构开始向客户端-服务器（C/S）架构发展的时候，设计原则也开始从关注隔离（Isolation）渐渐的转向最小化权限（Least Privilege）。擅自揣测，则是单体架构时期多是客户端程序（这里是从时间发展线上来看的，并不是指当下依旧存在的单体架构应用），只需要关注好隔离即可，谁能打开电脑谁就能访问。当之后开始出现服务端程序，架构也逐渐编程客户端-服务端的模式。此时不仅需要关注提供服务的端侧隔离，还需要考虑到访问权限的控制，于是出现了最小化权限的原则，同此时期，RBAC的模型等等也被创建起来。感兴趣的可以去维基百科一下。

同样的，后续逐渐出现了针对服务端侧的安全默认（Security By Default）和最小化暴露（Minimal Exposure）原则。再之后，分层架构（Layered Architecture）的引入，使安全设计的概念转向纵深防御（Depth In Depth）。乃至SOA架构和微服务架构时期，安全设计的理念一直遵循在DID（其实已经够用了）进行，直到云化，容器化和云原生逐渐发展，IAAS，PAAS，SAAS，乃至无服务器架构（Serverless Archiecture）也出来了（我曾听过某风控总监认为使用serverless架构就不用关注应用安全的说法）。微服务大规模扩展时，服务间的鉴权成了强需求。零信任（Zero Trust）的模型也终于有了落地的可能。随着应用侧Istio和K8S的出现，基础设施侧Boundary类产品，访问类Zscalar和端侧SASE类产品的出现，整体的零信任架构也算是勉强落了地。国产的平替会在后面讨论，尤其是针对分久必合，合久必分的One Agent类产品。

回到安全产品，再看下这些安全产品是如何支撑安全设计原则的。最初的最初，应该只是手动配置Unix服务器上的文件权限，以实现隔离和最小化权限的原则，后面渐渐的出现了Firewall产品，但是现在看来这些产品可能更多的类似脚本和工具。后面渐渐的出现了各类产品，从Logging到SIEM，从iptables到UFW，从Encryption到KMS，从Nginx WAF到RSAP（此处仅是通过搜索和推断，并未亲历，无实证。期待后续看到乙方前辈的文字记录。）以及云上引出CSPM类产品等等。安全产品有种大爆发的错觉，各类都在垂直领域做专业的事情。但对比国外和国内产品，生态还是相差甚远。尤其是对企业内基础设施的整合和安全产品之间的集成。

1. 从隔离到零信任

新的安全设计原则的引进，并不代表着旧的安全设计原则被抛弃。应用架构的演进，使得服务的攻击面发生了较大的变化。从127.0.0.1到0.0.0.0的过程中，业务的复杂度逐渐变高，无论是访问的隔离还是权限的隔离（我把最小化原则视为另一种隔离，即权限的隔离，因为本质上都是减少服务请求方和服务提供方两个Entity之间的最小资源重合）都已经不再能完全满足安全需求。从网络维度，如果依旧通过防火墙的五元组实现隔离，大量耦合业务场景的规则将变得无法维护，同时也阻碍了“敏捷开发”（此时的安全会经常听到业务抱怨：“你们Block了Production的！！”的类似言论）。从应用维度，微服务内部几乎没有任何防护，也不存在所谓隔离。虽然有一段时间听过“微隔离”的概念，但是在我还没搞清这个概念是什么的时候，似乎又销声匿迹了。

隔离，是一种最常见的安全设计原则。从物理维度有独立建筑隔离，门禁隔离，专线隔离，围笼隔离，电磁屏蔽机柜隔离，以及硬件加密机这种专用硬件；从网络维度有VLAN，MPLS，VPN，网络防火墙隔离，还有iptables, ufw等；金融行业在应用和数据的维度上更多的是通过物理和网络维度优先实现隔离，显而易见的在运维运营方面都会出现很大的问题，虽然这在监管优先的情况下并不妨碍业务的正常运转。其次是通过提供认证及鉴权（SSO、MFA、RBAC等），沙箱，虚拟化等提供对应用层面的隔离控制，以及通过提供分段、掩码、加密（使用不同的密钥、同态加密）、多方计算等形式实现数据层面的“隔离”。另外当在实际情况中无法实现理想的隔离时，则往往会以代理的设计模式再辅之以检测和监控的方式进行实现。例如Web防火墙，出向代理（Outbound Proxy），邮件网关，上网行为代理，DLP，堡垒机等。

对于零信任而言，更像是在应用层面接管了物理层面及网络层面的隔离管控措施。例如通过引入ZTA类应用来接管Applicatoin和 Application之间的访问控制，User和Application之间的访问控制，以及User和Machine之间的访问控制。软件定义安全的形式确实更贴近业务。在K8S内部引入Istio来使用mTLS增强Service间的安全认证及鉴权，同时支持加密传输。使用SASE可以通过任何一个互联网接入点，在完成客户端侧的合规检测后，通过使用SSO的方式拨入SASE的网络接入点后内网畅游，通过Citrix完成对内部应用的访问。被访问的应用（包含SASE和Citrix）在做IDP集成时可以配置对应的用户及组的授权。但同时SASE类产品的控制后台也可以管理用户对特定应用的访问权限。

以隔离为代表的设计原则包含ACL，最小化权限。至于到零信任原则的设计，则是一方面细化了授权的场景，一方面增强了认证的强度。从设计模式上看，均是基于代理、单例（Singleton）、责任链模型（CoR/Chain of Responsibility）实现的中心化管控。个人感觉，虽然从应用层面看零信任实现的安全控制确实更加高效，但仍然需要通过基本的隔离进行兜底。例如：基本的物理隔离，相应的Security Zone（在和零信任配合的情况下，Zone的粒度可以适当放宽）

2. 从简单加密到隐私计算

如果继续引用隔离的设计思维，对密钥访问权限的控制本质就是对数据访问的控制。从技术上看，从使用对称加密算法用于静态存储数据（DARE/Data At Rest Encryption）开始，到使用非对称加密算法完成两端之间的数据交互（TLS密钥协商，Data At Transit Encryption），再到PKI体系的发展，开始在要求加密的同时鉴别实体的身份。我们知道即便从RSA逐渐往ECC系列，可能也无法抵抗量子计算下的破解，Kyber的出现，代表着加密算法进入Post-Quantum时代。//尴尬的是，突然发现 IBM Quantum LAB 居然停服了。

从运营上看，更别提自创“加密”算法，自创“SDK”，N个业务方使用同一个固定IV，明文显示的“密钥”，Secret Sharing的不对等防护，证书的错误使用（场景更多），把用户名密码当作Cookie存在前端（这是我写该文章时翻到一篇18年文章里记载的，不可思议！），分不清哈希和加密等等错误的配置及使用。可以牵扯出一系列从根信任（RoT/Root Of Trust）到端到端加密（E2E）过程中遇到的各种沙雕问题。但很明显的是一边是通过在技术层面提高算法强度，一边在通过在运营维度保证私钥安全并缩短轮转的周期（无论是密钥还是证书）来实现对数据存储和传输过程中的加密。

但这些实际都没有解决数据在使用中的安全问题，即便可以通过较高强度的非对称算法去提高对称加密密钥生成时的机密性，但混合加密体系下并未设涉及密文计算。出于密钥和明文具备同等重要性的原则，对数据明文计算的结果是无法脱离密钥这个环节的，但密文数据的计算解除了数据使用过程中密钥和明文数据的耦合。至于隐私计算的技术，类别很多，在两年前也出现过一波出版炒作现象。具体可以参考该篇学习笔记：浅谈隐私计算与数据安全，虽然在实际的落地场景中，并不常见，但整体来说在算力提升和云化的背景下，当存在更多互不完全信任的参与方时，如何确保数据安全情况下满足各参与方的计算需求的安全设计一定会越来越多。 //当然这里涉及到另一个话题，如何衡量合同解决事情的成本和技术解决方式的成本。

3. 从安全默认到安全左移

其实没有太多好说的，只是大家搞清楚概念和落地有点没那么容易。如需详细了解安全默认，和安全左移可以参考以下两篇文章：

从单体架构时代关注配置的安全默认（Security By Defualt），到开始关注应用生命周期管理后提出SDLC，以及后续微服务时代，敏捷开发带来的快速迭代毫无因为疑问的引出了大量的潜在问题，即便在CI/CD中内置了安全扫描工具，但依旧无法避免新的威胁。例如供应链投毒：xshell类基础工具的投毒，pypi源投毒以及docker image的投毒等等。于是开始提出了安全左移（Shift To Left）。此时不仅需要关注安全默认的能力，更希望把安全默认的能力提前。但实际情况是，作为设计原则是好的，而企业中甚至不能把安全默认做好（请思考所谓的安全默认，在流程，工具上覆盖了哪些维度，侵入了哪些业务，亦或基础设施）。更别提左移的理念了。

4. 从记录监控到安全验证

在基础安全的维度去看设计的原则从隔离到零信任，在应用安全的维度看从默认实现到能力提前，以及数据维度的简单加密到密文计算。并未包含运营相关的设计演变，但考虑到实际安全设计在落地之后，运营是必不可少的，因此简单的写一下自己眼中安全运营的变化。

但如果大言不惭的话，国内在做甲方安全的过程，早期应该是不存在整体的安全设计。主打一个安全运营，炫彩夺目又可以输出。外面是光鲜亮丽的牛逼，里面是一线运营的苦逼。这也是我在18年对安全运营“文化”最为反感的时候，因为每个人都在鼓吹安全运营，但实际却是case by case的问题处理和《圈子及圈层》文化，以至于自己极力的想转向数据安全架构方向。当然现在的我早已不再排斥安全运营的话题，喷子状态也改善了很多。因为发现即便是做架构，也是少不了运营的。关于架构的运营可以参考安全架构师的运营一二事

再回到设计视角，企业最开始通过集中式日志中心完成对数据的收集（更早之前应该没有），安全日志的收集既可以独立进行，也可以作为企业内标准基础设施的一部分。此时还没有数据化，自动化的概念。随着SIEM类产品的出现，功能愈发丰富，开始对数据做场景化的分析，针对处置的结果做自动化。形成运营过程的SOP和对外发布的流程制度。这个时期是从手动往自动化过度的过程，期间也形成了对SOC类团队的组织架构需求。进一步要求SOC团队需要做到指标化，针对告警的压降，针对入侵的检出，针对响应时间的缩短，做看板，做IM的告警通知。再到后来一个较大的分割线就是SOAR类的商业化产品成型，摆脱了手工维护自定义脚本的过程（个人认为平台维度要比手工维护更有益）。纵观产品维度就是从SIEM到SOAR再到BAS类产品的研究（但是我感觉BAS类产品并不完全算，因为安全验证的概念实现完全也可以通过自定义的SOAR类脚本实现）。是安全运营逐渐自动化后再到安全设计得以验证的过程。因为设计的落地过程存在着很多灯下黑的问题，需要通过日常运营的结果去校正设计，当然这里又涉及到另一个话题，就是可以信任团队，但又不能完全信任运营的交付结果。

0x02 架构治理中的关键平衡点

在实现Business Goal时，如何平衡Management，Operation，Technology关乎企业发展与否。而在Technology部分，如何实现新的平衡来确保IT和Business相适应也至关重要。套娃的是，Technology的实现过程中需要再次平衡Management和Operation的难度。

考虑到落地的尺度，这一节通过一系列问题来讨论架构治理中的关键平衡点（避免平衡成为一种无限套娃），但是这些问题是没有绝对正确的答案，谁是决策者，谁在运营成本、安全防护和高性能之间选择？对于架构，很大一部分程度上就是平衡的艺术。

1. 基线在哪里？

基线决定了木桶短板的高度，但基线的落地并不能完全通过技术手段，必须要贴合业务场景并通过流程制度和平台工具一同实现。如果从问责制的角度出发，为了关注谁会打破Baseline，就需要首先确定谁是最后一道守门员。是所谓的流程制度，还是关键的职能人员，亦或者是自动化的平台工具？在流程优先，工具支撑的情况下，最后一个守门员是例外审批流程里的就是最后一个节点人。在业务优先的情况下，最后一个守门员是流程制度，记住不是X在为难Y，是流程在这里，虽然此处的本质是流程制度人作为守门员。不过有时候也无法避免为业务让道的结果，但是需要注意的是有一些基线是可以妥协的，而一定有一些是不可以的。比如对外暴露的端点加白名单是可以妥协的，使用通配符证书是可以妥协的，使用HTTP是不可以接受的。

2. 深度在哪里？

纵深防御、零信任一般很难完全落地，理解的不到位，组件/工具的不到位（乙方的产品在专业功能过关但不一定在基础设施的融合上面）。例如前面在《从隔离到零信任》中，隔离从物理维度到应用维度到数据维度有不同的方式，需不需要独立门禁，独立电磁柜，硬件加密机，专线还是IP白名单等等。而对于端到端的零信任应该是什么样的？如何去保护客户端的安全，到网络端呢，到应用侧呢？以及应用之间。从数据的维度，加密是如何进行的？在不信任通信链路的情况下？如果存储也不背信任呢？甚至不信任云上的KMS？对应这些问题，都有对应的技术手段可以解决。但是如何平衡High Performance和Cost Efficieny? 比如能否为K8S引入TEE？有时候触发了监管的policy呢？深度是否应该放弃？就像前面说的，合同确保的数据流动是不是真的就比隐私计算技术差多少？哪些场景下，可以通过流程制度来弥补技术的不足？哪些情境下又必须通过平台工具来提升运营的有效性？或者根本就没有必须？必须二字只是技术人的自我感动？又比如卡发布的操作，如何又要卡发布又要不能影响业务迭代？又比如针对漏洞运营，cvss 9分的漏洞在你的企业内应该增加哪些维度评估？别人没有窗口去修复，是不是就要闹剧了？我们能够自己实现加密库吗？拥有fb这种开发fizz的能力吗？指标的陷阱是不是要避免？还是每天就要扣着工单数和告警数？需要对SAAS类服务逐一进行尽职调查吗？确定哪些自动化之前先确定下哪些不要自动化？但就以这个问题，在实际的场景中，业务方肯定是要安全提供需要自动化的需求是什么，而安全又希望业务方先梳理出已有的场景。在来回扯皮的过程中，只能说谁站在守门员的位置，谁才有资格决断。

3. 成本在哪里？

《将心注入》里霍华德把员工当作公司里最核心的资产。无论对于人员还是工具，在落地时都需要考虑成本问题。我在成本场景里有几个典型问题，资源不足是不是先做一期方案，然后再根据资源情况做二期方案？HC快要关闭了，是不是先招一个人来干着？运营的成本是否要算到最佳实践设计里的一部分？换句话说设计一个邋遢方案，运营苦逼，到底是谁的KPI？还是说已经达成了共赢？低成本的方案完成了公司需求，多事件产出完成了运营汇报？当一群软实力过硬，硬实力没有的人聚在一起的时候，最多的不是想解决问题，而是想把发现问题的人解决掉。我不想在成本篇讨论到底哪里错了。但不应该只用人力电池和流程在“又不是不能用”的思维下，得过且过，一再将就。

0x03 安全架构师的自我修养

有一天，我被投诉了，有一天我又被投诉了。我拿着手机和聊天记录给老板看，老板说：“看，就是因为你不知道为啥会被投诉，所以你才会被投诉。” 后来我贴了个【三思而后行】的标签在工位边，我的老板开始说我是【三思而不行】。

《人间词话》里有言，人生需经历三种境界，分别是：“昨夜西风凋碧树，独上高楼，望尽天涯路”，其次是：“衣带渐宽终不悔，为伊消得人憔悴”，最后是：“众里寻他千百度，蓦然回首，那人却在，灯火阑珊处”。此处由此暂借三个问题。独上高楼，冷否？衣带渐宽，悔否？蓦然回首，在否？

1. 独上高楼，冷否？

四年前，我被教导：“对事不对人，从技术的层面就事论事，做好情绪管理好。只要沟通，经验，技术，三者具备两个就能很好的成长下去”。过去一年，老板教导：“保护好内心深处的东西，不要期望也别要求别人和你的准则一样。多多磨炼，Just Do It Later”。两个月前，我停下了内心的钟摆，并用一篇文章纪念这段心路历程。独上高楼，冷，还是冷的，但是要耐的住冷。如有同道中人，则前路不苦。

a. 架构设计驱动安全可行吗？

根据Dr. Werner Vogels（AWS CTO）在今年re:Invent上的演讲，Everything starts with security。那怎么样才能Starts With Security？以身说法的话是，我从正向设计时未曾明显感到Security By Design，反而是见到了更多的失败设计带来的一系列问题，才意识到如果你想保持Starts With Security，一定是Starts With Security By Design。换一种提问就是框架有用吗？经验有用吗？因为好的设计一定是基于最佳实践进行的。另外根据Tesler’s Law（复杂性守恒定律）：对于任何系统，有一定程度的复杂性是无法被降低的，内在的复杂度只能通过产品设计去设法平衡和转移 那么针对系统复杂性的转移，肯定是通过提前做好系统设计的规划，纵观全局，吸取经验完成的。最后的最后，如果做Design的自己都不相信架构设计的作用，那还有什么资格做什么架构设计呢？

b. 如何看待最新的安全趋势?

已经落地了前沿的设计，稳定的运行了一段时间。就可以尝试调研和使用所谓的新安全趋势。对于非常传统的行业，不一定需要绝对关注，因为即便脱离了演变的趋势在最后实际也是可以一步到位进行更替的。

c. 量级变化过程中如何以小见大？

做好简单设计并考虑复杂落地，使架构具备弹性（考虑技术功底），并尽量考虑丰富的场景（考验业务经验）。根据Kidlin’s Law，当把难题清清楚楚地写出来，便已经解决了一半。 因此不要担心量级的变化问题应付不来，掌握了方法，多用系统思维进行分析，也不要觉得某些场景问题荒谬。最后根据系统分析得到的结果去完成设计。

d. 安全团队服务化？

服务化的前提是增加了团队的Visibility，可以对外提供安全内部的产品能力，但服务化不应该以人为消耗单元，应该以工具和平台进行支撑。否则说明此时的安全团队还不具备服务化的能力。

e. 安全架构团队可以做什么？

提供training给Security BP， PM， Peer Team；编写Policy/Strategy；做架构设计(整体安全架构设计，单个产品的解决方案)；架构评审；提供安全咨询等其他安全服务；

2. 衣带渐宽，悔否？

词中的衣带渐宽是人形消瘦，我则愿心宽体胖（注：此处错误使用成语），再添宽衣。以前和朋友讨论职业成长，聊到过“如果有幸能在自己热爱的行业从事工作并获得发展，那真的是幸运非常”。好巧不巧，从事安全工作至今也算是幸运的在自己的热爱中工作。我回头看到之前写的安全架构系列文章发现是从安全设备的运维运营开始，逐步一点点的接触不同安全产品的解决方案架构，之后再到整体的安全架构。在这个过程中，也算是意识到技术驱动从来不应该是一句空话。当大家都不在乎结果的时候，就需要一个人站出来履行自己的职责。当没有人关心安全建设的结果时，就需要安全架构师站出来。这不仅是职责，也是一种职业道德。后面会继续从三个方向提升自己，努力做认为正确的事情。

沟通协作：
Follow Senior Leadership，并向其学习。把在书本中学习到的沟通和情绪管理的东西实践起来，把眼前的格言警示变成内心反思的东西，直到有一天把贴条撕去。永远保持给陌生人一次信任的机会，以此共同建立相互的信任，相互的尊重。但一旦失去，便决不再有重建的机会。

项目经验： 无他，多看，多学，多练，多总结。对待不具备专业背景的人，一定要尽量用对方听懂的语言去解释清楚。

技术变化： 虽然了解整体的设计以及单个产品的解决方案，但也开始发现有时候已经不再能对每个技术细节把握的十分清楚。当然我也发现一些人在处理这种情况下的做法，虽非可取，但可保无锅。但是我决定不采用这种方法，我的想法是通过系统思维快速的分析并且类比迁移应用即可。以及保持内心的谦逊和对更专业人员的信任。

3. 蓦然回首，在否？

五年之后的今天，虽然自觉少了许多锐气、虽然觉得自己在技术和沟通方面都温和了许多，但还是会有人觉得这是个“喷子”。我不知道当年交下的朋友心中，我应该是个多么大的喷子。当我锻炼沟通的时候，种种提示还只是格言浮在眼前；以为锻炼成了，结果只是没遇到。如今事事经历，才明白不是每个Charlie Simms都有Frank为他的十字路口辩护，保护好内心的Integrity何其不易。哪怕同等品质的牛腱子，在冷鲜和冷冻解冻后再做出来的酱牛肉就不是一个味道，不关乎火候也不关乎调味料。虽未变质，味道已经不同。

未来五年，希望自己能够Build一个良好的Security Architecture & Engineering 团队去以设计驱动安全的方式去做企业安全，并关注运营的服务质量，将其作为一个持续的可交付物。做好Security First和Cost Effiency以及High Performance之间的平衡。

0x04 安全架构的未来畅想

分析问题往往需要系统思维，但畅想未来则需要浪漫主义。在过去对学习Machine Learning/Deep Learning的过程，出于对神经网络层数设计的不理解，以及对调参侠的悲观。渐渐只将其作为迁移到安全领域的一些应用工具，例如使用了CNN的webshell分类，带LSTM的WAF等。实际第一次看到机器学习技术在商业化产品的应用是Radware的抗D产品。但随着ChatGPT的发展，动辄B级别的参数模型接替出现。在自己尝试做过一些提问场景的Prompting Engineering之后，愈发开始倾向于安全的未来是以AI-Powered Security的形式进行的。

尤其是针对前文所述的架构师所提供的一些工作职能，很大一部分程度可以通过设计好Prompt来实现安全咨询类，安全培训类服务工作。

上图我把prompt的设计分为几块（Chatgpt：以上述prompt为例），第一大块是基础设置，这里你可以针对各个基础参数进行配置。第二大块是Prompt本身，分为几个部分：

Instructions （扮演的角色是什么，具备什么能力）
Input （告诉后续的问答里用户可能会输入哪些东西）
Domain/Context （特定场景的上下文 //如果写代码分析的这种具体场景反而更好使一些）
Output（输出的内容和格式）
Tricky（据说增加了卖惨，夸赞类话语，可以获得更加优质的结果）

经常使用之后，就会发现针对特定场景设计好的Prompt，其效率和专业性并不亚于初级的安全架构师，甚至在某些方面要比人工做的更好一些。尤其是在dfrat阶段，可以节省很大的人力。安全架构的未来很大程度会依赖AI，对于一些小型企业可能会有意想不到的效果。同样的，针对AI本身的安全研究也会进入新的阶段。无论是Prompt的Jailbreak防护，私有化模型本身的安全, 训练数据的投毒等等，也会形成一套新的架构方案。例如目前Google的SAIF框架。

0x05 总结

安全服务于业务，实际是对应到安全架构就是，安全架构为业务架构和IT架构服务。但出于种种原因导致业务和IT基础设施无法相适应，与此同时IT和安全也无法相适应。这就意味着曾经存在过一个场景：一些人成功避开了最佳解决方案，并取到了补集。再由此引起新的运营问题，如此往复循环。而纵观架构的形式变化以及安全设计的变化，原理及发展脉络清晰。几乎所有的安全问题都是有技术方案可以解决的，但往往却没有用技术去解决。说明了什么？我之所以总结架构这篇文章（本来打算取名《我的企业安全观二》），是因为在过去的一年里，我对做架构产生了前所未有过的自我怀疑，甚至有一段时间不能说服自己。虽然自己也知道解决问题的办法并不是一种，虽然也知道没几个人真的在乎做的好坏。但也难免颓废，设计到落地之间的GAP在某些环境里真的是离谱到超乎想象。

再说一个沟通的案例，自身经历。在邮件loop中提出了方案，别人直接skip掉你这封邮件，然后继续“讨论”。等你再次replay all，别人的往来回复里只是会继续再次skip掉你的邮件，如此往复，筋疲力尽。虽然我觉得自己尽责了，但是我的leadership也被这一件事中被消耗了个干干净净，一天的精神也变的比较糟糕。我从不排斥学习，无论是学习沟通，还是学习技术。但是当你发现进退之间，未能使得局势缓和，只是对方更加咄咄逼人，倒也不必再退，我愿称之为《三思而不行》。当然我也曾想过，如此昏昏也未尝不可。但不过半天时间，我就又为自己的想法羞耻。那一刻，极度怀疑做架构是不是有意义。往往你以为别人不懂安全技术，但不知人家笑你不懂人情世故。

在简单设计到复杂落地之间的，作为一个架构师，还需要不断修炼。保持谦逊，避免傲慢。一位朋友说：“有时架构做了些看似自觉聪明的设计，其实并没有大的用处”。他将其称之为 “架构杂耍” ，而我用其提示自己，避免杂耍。最后，快下班的时候，我问老板什么是Business-Driven的Report。老板笑了笑🤷：“你为公司省钱了吗？你为公司赚钱了吗？”，后来发现 对于商业公司，不以盈利为目的的商业行为被认为背离了企业的本质和存在的基础。

“there is one and only one social responsibility of business—to use its resources and engage in activities designed to increase its profits so long as it stays within the rules of the game, which is to say, engages in open and free competition without deception or fraud”. —— Milton Friedman

//10月份大纲，12月9号起笔，今日完工。发现还有一份4月的草稿写支付架构的，今年计划里还有两本书没有读完，时间真的是一点不留人，怀念是人变老的标志之一。

安全架构师的自我修炼：从原则到实践